2

JUAN BRAVO C.

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 durante 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

4 © JUAN BRAVO CARRASCO, 2008

JUAN BRAVO C.

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, jbravo@vtr.net 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 Revista de Responsabilidad social (www.evolucion.cl).

EDITORIAL EVOLUCIÓN S.A. www.evolucion.cl, info@evolucion.cl Alameda 171 Of. 307, Fono 6389717

Santiago de Chile

MODELANDO UNA SOLUCIÓN DE SOFTWARE

5

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

6

JUAN BRAVO C.

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

7

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

8...................8 JUAN BRAVO C......................................................................................................... MODOS DE PROCESAMIENTO ........... Corba .................................................................................................. 166 2..................................................................1.................................. 165 2................................................................... Tick IT ..................... Simplicidad ................................................................................. Integridad de la información ..................................................................... Auditoría computacional .................................................................................. 142 2..................................... Batch-Interactivo ................ 185 2........................................... 186 3............................................................................................... 168 2................................................. 189 9.... Diseño de niveles de menús ........................................... Técnica de prototipos ......................................................... MARCO TEÓRICO DE LOS MODELOS .................................. 190 11............................. Desarrollo incremental ............................................... SOA ....... Mantenimiento de la solución de software ................ 175 CAPÍTULO 3................................................ TEORÍA DE MODELOS APLICADA ............................................................... MDA............................. Diseño estructurado.................................................................................. En tiempo real................................... 183 2............... Armonía entre el modelo y la realidad ......................................... 176 3................ 163 5........ Concepto de caja negra ...................................................................................................................... 172 4......... Seguridad de la información ... ONCE CLAVES DE LOS MODELOS COMPUTACIONALES........................................................................ 151 4.................................. 170 1............. Directrices para el diseño de interfaces humanas .................................... 162 4............. 187 5............... Ciclo de vida clásico . 145 2......................................... 191 ................... DISEÑO DE INTERFACES .......... 173 5......................................... 166 1.......................................................................................................................... 174 7........................................... Transacciones presentes ...... CMM ............. APOYO DEL DISEÑO EN LA EXPLOTACIÓN DEL SISTEMA ................................................. 145 1.................5...................... 190 10........... 164 6................... 188 6... 178 2.............................. Concepto de homomorfismo ..6.................. 159 3.................... Pruebas del software por el programador..................... Iteración.... Totalidad .................................................. 188 7............................................................................................................................. 167 3.......... 179 3............................................. 157 2.......... 155 2.................... Operación del sistema ......................... 157 1............................. 184 3............... 173 6..2.................................................................................................... 171 3................................................................................................... Intuición ............................................................................................. Programación extrema (XP) ....... 187 4........ 5........................................................... NORMAS Y ESTÁNDARES APLICADOS A LOS MODELOS TI .......................................................................................................... ISO 9000 .................... Recuperación de la información ....... 141 6...................................................................... Leyes para lograr una mejor interfaz humana ...................................................................................................................................................................... 178 1. 171 2................................. 183 3.................. Orientación al cliente .................................................................................................3.................................................................................. Contribución del diseño a la protección de la información .................................................................................. 182 1................................................ ITIL .........7................................................... Independencia de la implementación tecnológica ............................................................................................................................................. 185 1.. En línea .......................................................................... MÉTODOS PARA LA PRODUCCIÓN DE SOFTWARE ............................................................................................................................................. 189 8....................... Fluidez ... Generalización ... 147 3.........................................

................................. 218 4.................................. Estructura relacional ................................................................................... Resolución de problemas simples .. ENFOQUE DE BASES DE DATOS ............................ 247 2..................................... 196 4.. 265 . Concepto de máquinas abstractas ............................. Elementos del enfoque de bases de datos ................... 217 3............. 202 3. DEFINICIONES SOBRE EL MODELO DE DATOS .......................................................................................... 230 3........................................................................ 238 4............................................. Relaciones entre entidades ..5.................. MODELAMIENTO DE FUNCIONES ...................... Modelar bien a la primera .............................................................................................. 262 3................... DEFINICIONES SOBRE ORIENTACIÓN A OBJETOS . Arquitectura de sistemas de bases de datos ....................................................2.............................................................................. 220 5........................................................................................ 201 2................................................... 240 CAPÍTULO 5.... 193 1.......................................................... CONCEPTOS DE LA ORIENTACIÓN A OBJETOS ........................................ Encapsulamiento.. Condición de existencia ................................................................................................. CRITERIO CURSO NORMAL DE LOS EVENTOS .......................... 243 5.......... Clase .................................... 212 CAPÍTULO 4....................................3................................................................. MODELAMIENTO DE DATOS ............ Visión histórica funcional .................... 214 4.............................................. 205 1............ Eliminación de grupos repetitivos ............................. 257 3..................................................... Incorporación de nuevas tecnologías ............................................................................................................... FUNDAMENTOS DEL MODELAMIENTO DE FUNCIONES ...... 195 3....... 261 1......1............................ 235 2................................................................................................................................ Eliminación de dependencias parciales.... 251 5.......................................................................................................... 216 2.......................................... 235 1................................................... Objeto ...................................................................................................MODELANDO UNA SOLUCIÓN DE SOFTWARE 9 3.......... 198 3...................... 248 3.................................... 255 1......................................................................... 193 2.. Funciones asociadas a una entidad ........................................ Función ................................................... Descomposición funcional ................................. Relaciones propias (RP) ...................... 255 2..........................3....................... Tabla de traducción ............... FUNDAMENTOS DE LA ORIENTACIÓN A OBJETOS ..................................................... Tipos de entidades ................................................................. Aplicado al flujograma de información ............................. Mayor eficiencia ........ 249 4...............6............................................................ ORIENTACIÓN A OBJETOS ........................ Reglas del negocio .................... 261 2..................................................................................... Características estáticas y funcionales de campos ................................... 259 5............................................................. Visión de bases de datos ... 246 1...................2............... 236 3......... 258 4................ Visión de los datos ... 263 4..................................... 227 1................ 228 2. 233 4...................... 205 2.. 252 5............................................................................................................................ 201 1................................................... La orientación a objetos ............................................................................................................ 202 3................................................................................... Relación de pertenencia ......1........................... Definiciones preliminares .............. Representación de una entidad ......................... Relación del FI con la técnica UML ............................................................................................................................................. CRITERIOS BÁSICOS DE NORMALIZACIÓN DE DATOS ..................................... 222 4.............................................................. Relaciones funcionales entre dos entidades ...............................4............... 216 1........................ Convenciones de diseño ............

.................................................................................................................................. UNA PIRÁMIDE DE SOLUCIONES .......................................................................................3......... 312 2......................................... 304 2............. 285 CAPÍTULO 6........................................................................... 267 8.......... 314 5........... HERRAMIENTAS DE USO ESPECÍFICO .............. 293 2........................................................................................................ 302 6.......................................................... Herramientas integradas para automatización de oficinas ........................................................ Groupware ................................6....................... 299 6................................ 321 .................. Diagrama de diseño de clases ........... Caso de uso de alto nivel ................... Diagrama de secuencia del sistema ........ PROCESO DE GENERALIZACIÓN .............................. 275 3...... Identificación de clases.............................. 293 1....................................... Las nuevas herramientas .............................................................................................................................................................. 320 7...............3.....1....10 JUAN BRAVO C.. 274 2........................................................................................................................ Herencia ....... Workflow ................ HERRAMIENTAS DE LA TECNOLOGÍA DE INFORMACIÓN ................. 315 7.................................................... 309 1................................................................... 295 3........... Personalización del objeto............................................. 282 5............................................ 279 5...................... UNIFIED MODELING LANGUAGE (UML) . 276 4.............................................. 306 7...................................................................2........................................................ 319 2................................. Visión externa ......................... 268 5................................................................ 266 7......................... Casos de uso ... Visión dinámica del sistema ........................................... Lenguajes de máquina ............ 319 3.................................................................................1............................................. Construcción de un modelo de objetos ..................... 305 CAPÍTULO 7................................................................ 312 3......................................................................... 5............. Uso de herramientas ..................................... EVOLUCIÓN DE LOS LENGUAJES DE COMPUTADOR .........4. La cuarta generación de lenguajes .............. Modelo conceptual.................................................. Diagrama de colaboración ......................... Diagrama de casos de uso ......................... FASES DE LA ORIENTACIÓN A OBJETOS................................................................................................................. 318 1................................................................................................................................................................................................................................................. Lenguajes de alto nivel .................. 274 1........... Independencia ......................................... MODELOS DE UML................................................... 284 3.............. 265 6............. 301 8....... APLICACIÓN DE LOS MODELOS UML EN LA ETAPA DE ANÁLISIS ...... 290 1....................................................................................................................................................... Lenguajes simbólicos .......................................................... INCORPORACIÓN DE LA TECNOLOGÍA DE OBJETOS . Enfoque sistémico ......... 297 5............................................................................. 287 6.................. 269 2....... 292 6...................................................................... Reutilización de código................. Identidad de instancias de objetos ................................. APLICACIÓN DE LOS MODELOS UML EN LA ETAPA DE DISEÑO ......................... 295 4............................... Mensaje .......... 269 1.. Visión interna.......................... 291 2.............................................................2.............................................................................. Diagrama de estado ............ 300 7................. Caso de uso expandido . Interfaz humana .................................................... 304 1................ Modelamiento de la información ............ 283 1........................................................................... 283 2.. Contratos .............................5................................................................................................................................................................................. 272 5......... 313 4........... Obtención de clases ............................................................

..................................... 351 BIBLIOGRAFÍA... 339 Sistemas de información gerenciales ....................................................... 331 CONCLUSIONES......................... 349 AD/Cycle .... 332 ANEXO 1.. Herramientas tipo UPPER CASE ............................. Data Warehouse .................................................................................... 371 .................................................................. 344 ANEXO 4........... 333 Definición del negocio .............................................................................................................................. 341 ANEXO 3.......................................................................................................................................................................................... RELACIÓN CAUSAL............................ BI .................................... ANEXOS Y BIBLIOGRAFÍA .............. 326 3..........................................................................................................................................4............................... 322 5.................................................................................................................................................................. Motor de base de datos ............. 346 ANEXO 5.................. 324 1................................. 326 2.............. Herramientas de productividad en ambiente cliente servidor ................................................MODELANDO UNA SOLUCIÓN DE SOFTWARE 11 1............... Herramientas tipo LOWER CASE ......................................................................................................................................................................................................................................... 322 4.............................................................................................................. 323 6.......................................................... AD/CYCLE Y RUP..................................... 323 7.................................................................................................................................................. 337 Factores críticos del éxito ................................. HERRAMIENTAS DE APOYO PARA LA PRODUCCIÓN DE SOFTWARE ...................................... CASO COMPRAS CON UML ......................... 349 RUP .................................................................................................................... DESARROLLO EN ESPIRAL DEL PROYECTO ..................... 334 Destino de la organización ... ERP ................... 348 ANEXO 6...................... 321 2.......... 350 ANEXO 7........................................................... MÉTODO DE ACCIÓN RÁPIDA (MAR) ................................................. SRM ........................................................................ ALINEAR INTERESES .................................................................................. 322 3............................. CRM ....................................................................................... INTRODUCCIÓN A LA PLANIFICACIÓN ESTRATÉGICA............................. 338 Mediciones ............. 329 CONCLUSIONES.................... 339 ANEXO 2.......................

Definición de menús como una clase 174 Figura 3-1. Totalidad del método GSP 45 Figura 1-2. Mapa de proyectos con relaciones para reubicar personas 48 Figura 1-4. Esquema de aproximaciones sucesivas 197 Figura 3-9. D. Reconversión de programadores 119 Figura 2-3. Flujograma de información de control de cambios 85 Figura 2-1. Mapa de Sistemas Computacionales 51 Figura 1-7. Concepto de caja negra 186 Figura 3-2. Ejemplo de grosor de la piel de las crías de osos 155 Figura 2-7. F. Esquema de una mantención 208 Figura 3-15. Adaptación del método a cada tipo de proyecto 57 Figura 1-8. D. Ejemplo de D. Mapa de necesidades con problemas y soluciones 47 Figura 1-3. Relación del FI con la técnica UML 220 Figura 4-1. TABLA DE ILUSTRACIONES Figura 1-1. Esquema de una selección 207 Figura 3-14. Representación gráfica de una entidad 227 Figura 4-3. F. Concepto de descomposición funcional 202 Figura 3-10. Modelo orientado a las funciones del sistema 188 Figura 3-5. Componentes de una entidad 226 Figura 4-2. Ejemplo de flujograma de información despacho inmediato 214 Figura 3-16. Ejemplo de diagrama de contexto 158 Figura 2-8. 159 Figura 2-9. Armonía entre técnica y comunicación 137 Figura 2-5. Flujograma de información 74 Figura 1-12. Diagrama de flujo computacional 217 Figura 3-17. nivelado 159 Figura 2-10. Infinitas visiones de una realidad 189 Figura 3-7. Mapa de retroalimentación para replicar o evitar 50 Figura 1-6. Mapa de procesos 72 Figura 1-11. Esfuerzo estimado por etapa en el método GSP 63 Figura 1-9. Mapa de procesos de Fabrica de Electrodomésticos Linhogar 49 Figura 1-5. Diseño general de la interfaz 76 Figura 1-13. Modelo orientado al objetivo principal del sistema 187 Figura 3-3. Esquema de una extracción 207 Figura 3-13.12 JUAN BRAVO C. Tabla comparativa para disminuir tiempo de respuesta 143 Figura 2-6. Planificación estratégica en informática 122 Figura 2-4. Eliminación de grupo repetitivo usando número correlativo externo 238 . Las tres dimensiones del diseño 190 Figura 3-8. Ejemplo de relaciones funcionales 204 Figura 3-11. Clasificación de materias para perfeccionamiento en TI 111 Figura 2-2. Estructura general de un D. El modelo de negocios como una mesa 70 Figura 1-10. Modelo orientado al flujo de transacciones 189 Figura 3-6. Modelo orientado a los datos 188 Figura 3-4. Esquema de una actualización 206 Figura 3-12.

Ejemplo de un caso de uso de alto nivel 304 Figura 6-2. Ejemplo de relaciones funcionales estructuradas 262 Figura 5-4. Caso de uso de expandido Ingresar orden de compra 309 Figura 6-5. Interacciones entre objetos 258 Figura 5-2. Ejemplo de eliminación de dependencias parciales 241 Figura 4-6. Forma de un contrato por operación 316 Figura 6-12. Ejemplo de herencia en un sistema de ventas 283 Figura 5-14. Ejemplo de Interfaz visual detallada 310 Figura 6-6. Modelo de datos generalizado 287 Figura 5-17. Herramientas Upper CASE y Lower CASE 340 Figura A1-1. Diagrama final de la generalización 282 Figura 5-13.MODELANDO UNA SOLUCIÓN DE SOFTWARE 13 Figura 4-4. Gráfico de incorporación de nuevas tecnologías 263 Figura 5-6. Herencia múltiple 284 Figura 5-15. Caso de uso de alto nivel Ingresar orden de compra 308 Figura 6-4. Ejemplo de modelo conceptual sistema de compras 311 Figura 6-7. Representación de un objeto 275 Figura 5-9. Ejemplo de diagrama de secuencia 313 Figura 6-9. Ejemplo de contrato en dar OK ingreso línea 316 Figura 6-13. Ejemplo de definir una clase de transacciones de sueldos 281 Figura 5-12. Ejemplo de estructura de un mensaje 277 Figura 5-10. Ejemplo de modelo conceptual con atributos 312 Figura 6-8. Enfoque de bases de datos 250 Figura 5-1. Modelo de datos simplificado de inventarios 286 Figura 5-16. Clasificación de lenguajes de computador 325 Figura 7-2. Ejemplo de diagrama visión dinámica del sistema 314 Figura 6-10. Modelo funcional generalizado y detallado 289 Figura 5-19. Esquema de planificación estratégica 349 Figura A4-1. Esquema tradicional de diseño 260 Figura 5-3. Eliminación de grupo repetitivo usando campo interno 239 Figura 4-5. Arquitectura de bases de datos 245 Figura 4-7. Una pirámide de soluciones 335 Figura 7-3. Visión interna de la clase ingreso de transacción 292 Figura 6-1. Ejemplo de diagrama de colaboración 318 Figura 7-1. Nomenclatura de la orientación a objetos 266 Figura 5-7. Ejemplo de diagrama de diseño de clases 317 Figura 6-14. Visión interna de la clase productos 291 Figura 5-20. Relación de pertenencia 269 Figura 5-8. Modelo funcional generalizado 287 Figura 5-18. Ejemplo de transacciones de sueldos con objetos 281 Figura 5-11. Ejemplo de orientación a objetos 262 Figura 5-5. Ejemplo de diagrama de estado 315 Figura 6-11. Ejemplo de gráfico de Ishikawa 362 . Ejemplo de un diagrama de casos de uso 307 Figura 6-3.

p. no sólo por el imperativo de trabajar con calidad sino que también como una forma de crear riqueza en toda la sociedad a través de la transferencia de conocimiento. sino también ponerse en la delantera en algunas áreas puntuales. pp. 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. los países en desarrollo buscan entre sí las ideas y la colaboración”.14 JUAN BRAVO C. el libro es presentado por los Premios Nobel de Economía Joseph Stiglitz y Amartya Sen. Lo importante es que podemos lograrlo. Goldin y Reinert señalan (2007. 344): “La transferencia global de ideas en forma de tecnología es uno de los procesos de desarrollo más importantes. aprender a modelar un software o trabajar con método. India y Sudáfrica han demostrado que pueden no sólo salvarla. La mayoría de las personas se sentirán contentas con los resultados de un proyecto planificado con precisión. 237-8) Este libro responde a una búsqueda de lograr mayor productividad en las organizaciones de Latinoamérica. Es importante. todo ello en el contexto de aplicar un método completo para la gestión del proyecto. China. en congresos. los países en desarrollo líderes como Brasil. ya sea aplicar calidad. Debido en parte a estos adelantos. McCONNELL (1997. Hemos aprendido que se puede hacer lo que es debido para salir del subdesarrollo. . seminarios y formación de postgrado en Chile y el exterior. 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. Universidad Católica y Universidad Técnica Fe- 1 Entre otras personalidades. el abismo en aparente crecimiento entre los países desarrollados y los países en desarrollo ha despertado inquietudes acerca de una brecha tecnológica. • Los cursos sobre análisis y diseño que he dictado a alumnos y profesionales en la Universidad de Chile. En años recientes. En su reconocido1 libro Globalización para el desarrollo. PRÓLOGO La presión irrazonable en la planificación puede hacer que los desarrolladores pierdan el respeto a sus directivos. en una intensa investigación acerca de las mejores prácticas para modelar buenas soluciones de software. Durante décadas.

una respuesta natural. Gestión de Proyectos de Procesos y Tecnología. elegante. 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). En relación al desarrollo de software. el cual incorporé en mis desarrollos y documenté en un nuevo libro en el 2006. construí una herramienta CASE a fines de los 80’s. propias y normalizadas. Hacia fines de los 90. mi propia evolución se fue orientando desde el perfeccionamiento de métodos tradicionales.A. productiva. La búsqueda siguió hasta desembocar a mediados de esa década en la orientación a objetos. además de talleres en muchas empresas desde hace ya dos décadas. expuestos en revistas especializadas a comienzos de la década de los 90.MODELANDO UNA SOLUCIÓN DE SOFTWARE 15 derico Santa María. hacia la búsqueda de fórmulas cada vez más productivas. quienes podrán conocer la terminología básica para interactuar con los especialistas. • En mi experiencia como desarrollador de varios cientos de sistemas computacionales destinados a diferentes organizaciones. incluso. Lectores del libro Esta nueva publicación se orienta a especialistas en informática. publicado a fines de la década de los 80. amistosa y simple para modelar soluciones de software. como el método de cuarta generación y el modelamiento de datos y funciones. hago referencia dentro de la lectura a mis libros relacionados con el tema2: 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. reflejados en el libro Desarrollo de sistemas de información. 2 . a docentes y estudiantes de carreras afines a la computación quienes requieren conocer métodos para aumentar su productividad y efectividad. ensayando variadas formas de diseño y construcción. Ese aprendizaje quedó reflejado en el libro La Nueva Visión. También a usuarios de la tecnología. una visión práctica. Esos avances fueron profundizados en el libro Modelamiento de sistemas de información. Diseño y Construcción de Sistemas Computacionales. la orientación a objetos se transformó en un estándar de hecho en la forma del lenguaje de modelamiento UML.

donde convergen todas las otras ideas menores. nuevamente ha realizado otro gran esfuerzo. A. ideas y conceptos actualizados al día de hoy. Tienen en común estar a cargo de áreas de informática. como afluentes a un río mayor. es decir. diseño y construcción de sistemas computacionales porque todos sus contenidos relevantes para efectos de modelar soluciones de software están incorporados en esta nueva obra. a quien conozco por muchos años. Mi amigo Juan Bravo. que el tener sistemas computacionales no constituye ninguna ventaja sobre la competencia. autor de un gran número de libros del área de la Tecnología de la Información (TI) aplicada a los negocios. esta entrega orienta y prepara a las pequeñas y medianas empresas. 3 Gerente de Sistemas en Empresas Hites S. Prólogo de Gerentes de áreas de sistemas Algunos estimados amigos me han otorgado el privilegio de agregar algunas palabras. ¿Dónde radica la importancia de este libro para los profesionales de TI? A mi juicio. En su particular manera de escribir. Ratificando una vez más. • • • • • • • • Desarrollo de sistemas de información.16 JUAN BRAVO C. nos ofrece esta nueva entrega literaria: un libro que versa alrededor de una idea: el modelar soluciones de software. sistemas que son construidos con métodos estándares de construcción y calidad. 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. . en concebir los sistemas computacionales como un commodity. Con metodologías que aseguran un resultado predecible en las operaciones diarias de los diferentes procesos comerciales. 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. las cuales están insertas en organizaciones de diferente tamaño y sector. por la búsqueda de conceptos e ideas nuevas que se desarrollan y plasman alrededor de una idea “maestra”. para entregar estos nuevos conocimientos. Christian Andrews3 Todo libro conlleva un gran esfuerzo del parte del autor.

están dispuestos a desarrollar productos de software por una fracción del ingreso medio de un país medianamente desarrollado. rescatar lo medular de cada nuevo conocimiento del último tiempo. botando muros “políticos”. 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. la gran fábrica de software del mundo está en India. lo encapsula. cada mañana debemos comenzar a correr rápido si queremos sobrevivir. La tierra es plana postula Thomas Friedman. miles de ingenieros de software con conocimientos actualizados y metodologías. como un eslogan que interpreta el impacto de la globalización en el mundo moderno. De ahí. destacado periodista americano. . 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 sobrevivir. día tras día. Hoy por hoy. el no tener estos sistemas constituye una clara desventaja competitiva. En su libro. sólo podemos pensar que. que no estamos en el África. 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. lo simplifica y lo entrega como un método simple a seguir por sus alumnos y profesionales que siguen sus libros. Entonces. Cada mañana la gacela piensa que debe correr más rápido que el león más rápido para poder sobrevivir”.MODELANDO UNA SOLUCIÓN DE SOFTWARE 17 muy por el contrario. ¿cómo competir en este mundo más bien adverso? Pues actualizándose permanentemente en los diferentes avances que se van liberando en el mundo desarrollado. más que en otro lugar de este mundo. Quizás hoy más que nunca es relevante actualizar los conocimientos con la mayor prontitud posible. quien nuevamente se esfuerza en descubrir. Desventaja que erosiona gravemente los márgenes de ingreso. sin importar en cual industria participe y compita. Para nosotros. la importancia de este libro de Juan Bravo. que permiten acercar y hacer “local” casi cualquier bien o servicio. Thomas Friedman cuenta una historia que es atingente: “En el África. tendiendo expeditos puentes comerciales sobre los diferentes océanos. en todas estas empresas sin los sistemas computacionales. no importa si somos león o gacela.

a este libro. especialidad cuya formalización le ha tenido de cabezas por un par de décadas. una obra que sirve a los especialistas en construcción de software.18 JUAN BRAVO C. de haber trabajado en muchas empresas chilenas. de su cariño por la Ingeniería de Software. Mi humilde opinión es la que presento ahora a ustedes: El creativo. ha logrado que el hecho de modelar una solución de Software. Juan tiene la ventaja de conocer el medio local. Para ambos. de haber enseñado en él. conozco de su trabajo. por lo general no considerados en este ejercicio. . que compita o se compare con cualquier otro editado en Estados Unidos o en otro país. la cual está apoyando el desarrollo y desempeño de casi todas las áreas en el mundo del siglo XXI. el cariño por su profesión. Limbi Ortiz Neira5 Cuando el doctor Juan Bravo Carrasco. Deseo firmemente que su libro no sea uno más. Rodrigo Collado4 Conozco a Juan desde hace muchos años. y luego de unos segundos de respirar profundo. le respondí que lo haría. tal como visión sistémica. me embargó la emoción por el gran honor que esto significa para mí. me llamó para pedirme que le escribiera un prólogo a este libro. de haber intercambiado sus puntos de vista y sus sueños con tantos. Agradezco el empeño de Juan. pero también a los que están más lejos del diseño de software. de sus anteriores libros y. un concepto que nos abre la mente a ver nuestro software como parte de un en4 5 Gerente de Desarrollo en BancoEstado. debemos buscar la forma que el libro se desmaterialice y llegue a las salas de clases y a las empresas. Para los “legos”. novedoso y entretenido enfoque que le ha dado el doctor Juan Bravo C. Para los “iniciados”. Y es clave en muchos casos. Siendo tan relevantes y amplios estos mensajes. He leído su nuevo libro “Modelando una solución de software”. el mensaje es claro: abandonemos la artesanía y hagamos ingeniería. su amor por el estudio de esta especialidad y su coraje en la búsqueda de la impecabilidad en el modelamiento de buenas soluciones de software. entre los que me cuento. sea un desafío que nos obliga a considerar diferentes aspectos. tomar conciencia de la necesidad y prisa de trabajar conforme a los postulados de la Ingeniería de Software. es la oportunidad de conocer la complejidad de una disciplina que aún no alcanza la formalidad de otras especialidades. sobre todo. Directora de Sistemas en la Municipalidad de Melipilla.

Un acierto. sencilla y sin abandonar la formalidad de la Ingeniería de software. 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 aprendiendo. y haberme permitido dar mi opinión. agradecerle su confianza en mí. técnicas y herramientas que allí aparecen. la cual se describe brevemente en la introducción y se detalla en la etapa de análisis (sección 1. parte de la cual he tenido la suerte de escuchar y aprender. el cual nos aclara conceptos tan utilizados como desconocidos hoy en día. procesos.4). al cual ha dedicado muchísimas horas de trabajo y el resultado ha sido excelente.MODELANDO UNA SOLUCIÓN DE SOFTWARE 19 torno rico en posibilidades. quisiera felicitar al doctor Juan Bravo por hacernos partícipes a todos de este libro. Finalmente. Asimismo. . así tambié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. te estimula a continuar investigando. es uno de esos libros que por ser tan interesantes. considerar también el diseño orientado a objetos. En este libro. ha sido el hecho de que el doctor Bravo ha logrado explicar de manera simple. estructura y tecnología). una visión sistémica del análisis y diseño orientado a objetos. con UML y herramientas TI”. que destaca dentro de la claridad de este libro. Te desafía a utilizar todos los conceptos. no quieres que se termine y te entusiasma. las cuales tienen tal importancia que ellas siete se traducen en los respectivos capítulos del libro. se plasma mucho de la gran experiencia adquirida en ésta área por el doctor Bravo. en el cual necesariamente debemos considerar “la mesa6”. “Modelando una solución de software. el modelo de negocios en el cual estamos trabajando. es decir. las competencias necesarias para modelar una solución de software.

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. pero al sumergirme en el tema específico 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 informática es comenzar a desarrollar sin tener los planos. bueno. Tengo la suerte de trabajar en una empresa constructora y sería un suicidio comenzar un proyecto sin tener los planos. Juan dice en el prólogo de este libro que lo que buscamos finalmente es una mayor productividad de nuestras empresas. no olvide que hay personas que van a vivir dentro de ese sistema y va a ser su casa en forma permanente. no podemos comenzar a construir el sacro edificio si no tengo planos arquitectónicos hechos y bien hechos. en informática los planos del sistema podemos dibujarlos con alguna nomenclatura estándar como UML o alguna propia. no comience el desarrollo sin planos.20 JUAN BRAVO C. 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. pero ese es el punto. 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. acá es lo mismo. 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. De pronto me siento repitiendo algo que escuché por primera vez en mis inicios. . 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. es verdad que los costos de improvisar son muy altos y pueden duplicar fácilmente cualquier presupuesto de tiempo y costo con el consiguiente impacto negativo en el negocio. les tengo malas noticias. cuando programaba mi primer software.

Bueno. eso es todo. . 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 21 cual se implementa y esta reducción debe pagar la inversión comprometida para generar utilidades en el tiempo. no estamos hablando de modelar por modelar.

Enami Ventanas (actual Codelco). Luis Cavieres Rojas. Santiago Macías Huenchullan. NCR y Weisselberger y Cía. AT&T Chile. Eugenio Díaz González. Polygram Chile Ltda. José Labra Molina. entre otras. 41) Mi especial reconocimiento a quienes tuvieron la gentileza de revisar borradores de este texto y compartir tanto de su sabiduría: Limbi Ortiz Neira. ideas. Liliana Gajardo Campos. p. Aquacultivos. Luis Méndez Reyes. Empresa Portuaria de Valparaíso. Luis Cid. Francisco Méndez Sanhueza. Rolec.. IST y ACHS. Juan Carlos Soto Trucido. Miguel Sáez. Marcos Merino. También de las organizaciones donde he tenido el privilegio de participar como asesor o relator de seminarios: CMP. Francisco Medina. Sota y Nicoletti Comunicaciones. Bernardo Cienfuegos Areces. Jorge Stein Blau. Christian Andrews Villagra. Sonia Esturillo Herrera. Agencia de Aduanas Jorge Stein. Eugenio Díaz González. Rodrigo Collado Lizama. Muchas ideas y motivación han surgido de las conversaciones con Liliana Gajardo. Diseño y Construcción de Sistemas Computacionales (1996). Termosistema. Daniel Kanonitsch. Estoy agradecido de las empresas donde me acogieron como colaborador de tiempo completo: Empremar. Alexis Cifuentes Barra. motivación): Rolf Achterberg Neüman. Ricardo Cahe Cabach. Derek Hyland. David Medina Avilés. Este libro es heredero de dos textos anteriores: Modelamiento de Sistemas Computacionales (1994) y La Nueva Visión. Dagoberto Cabrera Tapia y Cristian Rubilar Utillano. Especial mención requieren las empresas con las cuales hemos trabajado en la última década: BancoEstado. Carlos Reyes Rubio. José Leiva Olmedo. Ignacio Castro Escobar. Rolf Achterberg Neüman. Gerardo Cerda Neumann. Francisco Guerrero Novoa. Editorial Televisa. Kotter (2004. Giancarlo Gandolini Ambrosoli. Rodrigo Baldecchi. Carlos Parra Bustos y Raúl Prado Baldratti. Carlos Toloza y Enrique Jorquera (mis disculpas por las eventuales omisiones). así es que reitero en éste los agradecimientos a quienes aportaron de una u otro forma en aquellos (revisiones. Integramédica. Víctor Silva Ballerini. no la sustituye. Mauricio Arancibia Pino. Jeannette Caballero Pinilla. AGRADECIMIENTOS El liderazgo complementa a la gestión. . Ricardo Baeza Yates. Manuel Videla Abarca. Hugo Osses Bravo.22 JUAN BRAVO C. Francisco Ramírez. Gloria Arellano Mundaca.

El diseño de la portada es obra de Juan Pablo Bravo Zamora. su cercanía ha sido un estímulo en la realización de esta obra. los cursos acerca de procesos y de tecnología. Juan Bravo C. mi hermana. destacar actividades abiertas de capacitación.MODELANDO UNA SOLUCIÓN DE SOFTWARE 23 En cuanto al ámbito académico. Un reconocimiento especial a mi esposa e hijos. por ejemplo. . • Revista Gerencia. el magíster en gestión y tecnología. una vez más fue muy valiosa en todo tipo de apoyo logístico. en la forma de múltiples seminarios de un día de divulgación de estos temas. en particular los cursos de gestión de proyectos de procesos y de tecnología en el formato de dos días. • Pontificia Universidad Católica de Chile. La colaboración de Silvia. A todos agradezco sus aportes y libero de cualquier responsabilidad por algún error en el texto. El diploma realizado por varios años en análisis y diseño de sistemas. • Universidad de Chile. • Universidad Santa María en Ecuador. a través de: • Universidad Técnica Federico Santa María en Viña del Mar y Santiago.

modelar soluciones de software con técnicas normalizadas. utilizando sus propios métodos y herramientas de trabajo. Lo más probable es que la realidad deseada se encuentre vagamente escrita y que principalmente esté en la mente de las personas. KENDALL y KENDALL (2005. que de otra forma resultaría muy difícil de transmitir. La función del modelamiento es hacer tangible y aclarar esa realidad para que luego se pueda implementar. p. buscando simplicidad. ¿Por qué modelar? Porque es necesario representar formalmente una realidad deseada. más como un deseo difuso que como un requerimiento. eficiencia y adaptabilidad al cambio. en el contexto de un proceso general de desarrollo que permita trazabilidad y productos repetibles. diera vida a una creación única e irrepetible. Es importante que los miembros de los subsistemas se den cuenta que su trabajo está interrelacionado… Los problemas surgen cuando cada gerente tiene un concepto diferente de la importancia de su subsistema funcional. Problema Solución Implementación Necesidad Realidad deseada (difusa) Modelos de la solución . Este es el desafío. ¿Será posible profesionalizar conservando la creatividad? ¡Sí! y de esta forma los métodos y herramientas van a recibir el aporte de muchas personas. Por esta razón. Si esa realidad deseada da respuesta a una necesidad por una parte y por otra los modelos de esa realidad son factibles de implementar. tal como si a un artista le encargaran una obra (requerimientos) y él. Modelar soluciones de software puede ser arte y tecnología a la vez.24 JUAN BRAVO C. entonces la probabilidad de éxito es alta. Eso es lo que quiere mostrar la siguiente figura. 30) Modelar una solución de software es una labor bella y creativa. frecuentemente se obtienen muy buenos productos que son verdaderas “obras de arte”. en este caso una solución de software. 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 posible que no requiera los modelos. 4. Sin embargo. Un método completo para la gestión de proyectos y así situar el modelamiento de soluciones de software en su contexto. en este texto se presentan en la forma de capítulos: 1. una selección de los modelos más relevantes de una solución de software. En muchos casos el número de soluciones es prácticamente ilimitado”. cables de electricidad y todo lo demás). 3. habilidades y actitudes necesarias para modelar aplicaciones computacionales (o soluciones de software). 5. Contenido del libro Lo primero sucede en esta misma introducción. Entonces. construir sin planos) y aplicar los nuevos conocimientos sobre teoría de modelos. En el software es igual. 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). si usted sólo quiere extender una pared interior de 2 metros. La profesionalización de conocimientos que aporta la ingeniería de software para comprender todos los aspectos técnicos de los modelos. si quiere construir su casa necesitará de maquetas y muchos planos (obra gruesa. en particular el modelamiento de funciones y el criterio curso normal de los eventos. Los múltiples aportes de la nueva teoría de modelos. ¿Siempre es necesario modelar la solución antes de implementar? Depende. normalización (tal como orientación a objetos y UML) y construcción con herramientas CASE. 226): “Se utiliza la especificación de requerimientos para definir el problema. . p. las normas y estándares que existen. 2. puede contratar un experto y sólo darle instrucciones verbales. Las competencias son conocimientos. El indispensable modelamiento de datos. tal vez le resulte y ahorre tiempo y dinero. La idea es superar la construcción artesanal de software (por ejemplo. Los necesarios conocimientos de la orientación a objetos. 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 25 Shari Pfleeger explica en su libro Ingeniería de software (2002. cañerías de agua. toda aplicación desde un costo de algunos miles de dólares ya hace necesario un modelar formalmente. podemos declarar que algo es una solución a un problema si satisface todos los requerimientos planteados en la especificación.

es decir. Ese es el sentido de esta introducción. se van perfeccionando mediante borradores sucesivos. INGENIERÍA DE SOFTWARE CAPÍTULO 1. tal como se aprecia en la siguiente figura.26 JUAN BRAVO C. Las herramientas de la tecnología de información. . El estándar UML. Seguimos la idea de una doble espiral que se traslapan parcialmente: la primera del análisis y la segunda del diseño. produciéndose un avance que parece una pirámide. tal como vemos en la figura. 6. HERRAMIENTAS TI CAPÍTULO 6. Es recomendable contar cuanto antes con un boceto de todos los modelos que se considerarán para cada etapa de la aplicación particular. profundiza en la competencia correspondiente. ORIENTACIÓN A OBJETOS CAPÍTULO 4. CAPÍTULO 7. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales 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. 7. El camino para dibujarlos es iterativo. Cada capítulo. MODELAMIENTO DE DATOS CAPÍTULO 3. UML CAPÍTULO 5. TEORÍA DE MODELOS CAPÍTULO 2. Análisis Diseño 8 En el capítulo 1 veremos el método completo. una primera versión destinada a lograr una visión de conjunto. en el mismo orden.

procesos. Incluir como plan de acción de RS Mapa de proyectos 10p Tiempo Problemas detectados: 1. proyectos. Trabajadores fuman en sector atención clientes 1p = Libera = Neutro = Requiere 7p Mapa de necesidades Procesos Estratégicos Gestión de Personas Gestión de Procesos Gestión de Proyectos Gestión de Calidad Control de Gestión Gestión de Contratos Analizar cargos Reclutar Inducir Mapa de procesos Desarrollo Planificación Estratégica RS Evaluar Formar Diseñar carrera Proceso del Negocio Comercializar Proyectar ventas Conocer la demanda Visitar Clientes Estadísticas internas Emitir O/C Almacenar Traspasar Comprar Recibir Distribuir Planear cada local Emitir traspaso Ordenar Preparar cada local Presentar Coordinar merchand. Alinear con la estrategia 2. Bienestar Productividad Calidad Costo Responsabilidad Social 2p Soluciones propuestas: 1. Pago tardío a Proveedores 2. retroalimentación y sistemas. Son los mapas de necesidades.MODELANDO UNA SOLUCIÓN DE SOFTWARE 27 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. Vender al detalle Vender Postventa Atención al cliente Medición y seguimiento Servicio de garantía Cotizar Recepcionar Despachar Cuadrar Procesos de Apoyo Adquisiciones Servicios Básicos Finanzas Contabilidad Legal Transporte Remuneraciones y bienestar Tecnología y Mantención Meditación Cobranzas Buen trabajo en equipo Devolución Liderazgo sistémico Ventas Alcance poco claro Retroalimentación de eventos destacados Demora en entrega final Dificultades para coordinar entrevistas con usuarios Facturación Compras Bodega Entrega = Experiencias para evitar = Experiencias para replicar Recepción Mapa de retroalimentación Mapa de sistemas computacionales .

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. Cada empresa debe tener su propia ruta metodológica e incluso adaptada según tipos de proyectos. En la siguiente figura se aprecia el objetivo y actores de cada una. Qué Análisis Cómo Diseño Constructor Cliente Usuarios y Analistas Modelos de la etapa de análisis La siguiente selección de modelos no pretende ser exhaustiva. la etapa de análisis se orienta a definir el qué y la de diseño el cómo. dependen del método y nivel de madurez de cada organización. Se presentan los modelos ordenados según las etapas de análisis y diseño. se incluye con el único objetivo de lograr una visión global. Una vez que el diseño está completo. los cuales tienen la características de contextualidad. se envía al constructor (aunque sea el mismo analista en otro rol). no se explican aquí porque el detalle de cada uno está en los capítulos del libro. Todo el modelamiento está orientado al cliente (externo. . en ambas participan analistas y usuarios. La visión de conjunto es vital en la visión sistémica. cosmovisión que guía todo el trabajo de este libro.28 JUAN BRAVO C. es decir. El detalle de cada uno se puede apreciar en el capítulo 1. tanto en los mapas como en los siguientes modelos. quien paga). Los modelos que se presentan a continuación para análisis y diseño son sólo una muestra de las posibilidades del modelamiento.

En esencia: corresponde decidir Qué hacer. comenzando por la cubierta de la mesa (detalle de la figura en el capítulo 1). los modelos siguen la lógica del método GSP. GD: Guía de Despacho . la cubierta es la estrategia (alineando la de la empresa y la de del proyecto. con cinco elementos que se representan con la metáfora de una mesa. incluye responsabilidad social) y las 4 patas son: personas (incluyendo ambiente). estructura (organizacional y física) y tecnología (de todo tipo). procesos. los cuales se observan en la siguiente figura (detalle en los capítulos 1 y 3 respectivamente). Estrategia Personas Procesos Tecnología Estructura Luego se comienza a trabajar en la pata de los procesos: levantamiento detallado y propuestas de cambio. Vender al detalle PROCESO DESPACHO INMEDIATO CLIENTE OE BODEGA ADMINISTRATIVO DE BODEGA FINANZAS DESPACHADOR Vender Despachar Cuadrar PROCESOS VENDER Reservar y emitir GD GD4 GD3 GD2 GD1 GD’s Buscar producto Al Contado A Crédito Inmediato A domicilio GD4 OE Rebajar saldo Cliente recibe y firma recepción Programar Entregar GD2’ GD1’ GD3’ PROCESO CUADRAR Mapa de procesos OE: Orden de Entrega. En esta etapa todo el trabajo se centra en el modelo de negocios de la solución. Se emplean principalmente los modelos mapa de procesos y flujograma de información. en la empresa corresponden a los contenidos del proceso de desarrollo de software que ésta se haya dado.MODELANDO UNA SOLUCIÓN DE SOFTWARE 29 En este caso.

30 JUAN BRAVO C. es necesario profundizar en los requerimientos principales de la solución de software. . en tal caso. comenzando por cualquiera de ellos). se puede emplear esta serie de modelos (una buena técnica es por borradores sucesivos. 2 y 3). Lo cual está descrito en el capítulo 1. Desde aquí surgirán definiciones para las otras patas de la mesa: personas. El objetivo es decidir qué incluye el modelo de negocios (detalle en los capítulos 1. Para definir el alcance de la solución de software en la etapa de análisis. Clientes Pedidos y devoluciones Costos Gerencia Niveles Compras Devoluciones Entradas Traspasos Ventas Artículos y factura Artículos y guía Control del stock Salidas Devoluciones Traspasos Control de stock Despacho de artículos Peticiones Proveedores Orden de compra y devoluciones Sala de ventas Diagrama de contexto Maestros Modelo orientado al objetivo principal del sistema Clientes Artículos Proveedores Transacciones Proveedores Cuentas Contables Historial Ventas Historial Compras Ventas Compras Devolución ventas X X Compras Clientes X X X X X X X X X X Artículos Ventas Modelo orientado a los datos Cotizador Modelo orientado al flujo de transacciones Terminales del área de Adquisiciones Cotizar Aprobar cotización Ingresar O/C Aprobar O/C Enviar O/C O/C = Orden de Compra Jefe de Adquisiciones Administrativo de Adquisiciones Diseño general de la interfaz Diagrama de casos de uso Una vez lograda la decisión respecto a los qué. la recomendación es trabajar con estos nuevos modelos (detalle en los capítulos 5 y 6). estructura y tecnología.

Detalle de transacción C/E Mensajes 4 y 5 Productos L. vea caso de uso “Corregir Correlativo”. Verifica existencia del producto.. La O/C queda disponible para ser enviada al proveedor luego de la aprobación electrónica por el jefe de adquisiciones Resumen: (el mismo del caso de uso de alto nivel).MODELANDO UNA SOLUCIÓN DE SOFTWARE 31 Terminal en bodega Terminal del Administrativo de Adquisiciones Administrativo de Adquisiciones Ingresar O/C Administrativo de Adquisiciones Ingresar O/C Ingresa la Orden de Compra a partir de los documentos de cotización a proveedores. Verifica que proveedor exista. obtiene y despliega nombre y fono en (E) y (F) 6…. producto en (H) obtiene y despliega la descripción y el precio en (I) y (J) 9.* contiene * existe en 1 existe en * almacena 1 Bodega Productos contiene * existe en 1 Proveedores Caso de uso de expandido Encabezado de O/C Nº O/C Fecha compuesta por contiene existe en * 1 Proveedores Rut Nombre Líneas de la O/C Líneas de la O/C Unidades Precio contiene existe en * 1 Productos . Ingresar Nº O/C en (A) 3. Recepción RUT Proveedor Dirección Proveedor Comuna C - Encargado Recepción Razón Social Proveedor D F Nº Guía Recepción Fecha Recepción e-Mail A B Encabezado de transacción C/E Mensaje 1 Ingresar transacción Personas E I G Ciudad M H Fax J Fono K N Precio L O Valor Neto Guía de Despacho de Proveedor Nº Fecha G/ D. Para cada línea: Para cada línea: 7. Modelo conceptual de datos Modelo conceptual con atributos Interfaz de Entrada Guía Interna de Recepción por Compra Código Enc. Ingresar Rut en (D) 5. Dar OK a la línea 11…. Tomar la O/C desde el archivador 2. 2… Incluye interfaces detalladas de E/S Caso de uso de alto nivel Encabezado de O/C compuesta por se asocia a 1 1.. Código Descripción Cantidad LL P Q R S T Modelo funcional generalizado Cerrada Anulada W Y Cerrar X Anular Z XX Salir V Grabar Total acumulado U Interfaz visual detallada . Funciones relacionadas: Curso Normal de los eventos Acción del actor Respuesta del sistema 1.. Verifica correlativo y envía respuesta en (B) 4. existe en * almacena 1 Bodega . Si el número de O/C ya existe. Ingresar las unidades en (K) 10. Calcula el subtotal y despliega en (L) 10.. Excepciones: 1. Proveedor Nº de O/C. Ingresar el código de 8..

Modelos de la etapa de diseño De la misma forma que la etapa de análisis. Mensaje 5 Crear proveedor y artículo si no existen. clase Ingreso de transacción Atributos Funciones Indicar stock del producto Deben cuadrar totales.32 JUAN BRAVO C. detalle y totales según formato 1 Aceptar datos 2 Cuadrar totales C/E Ingreso de transacción Encabezado. • Se actualizó el contador de líneas en el encabezado. Repetir hasta que no haya más productos Ingresar cantidad Dar OK a la línea Diagrama de secuencia Contrato . es decir. Ingresar Nº de O/C Ingresar código de prod. Mensaje 4 Modelo funcional generalizado y detallado Administrativo Sistema Visión interna de la clase ingreso de transacción con la tabla de objetos Contrato Identificación: Dar OK al ingreso de la línea Responsabilidades: con cada ingreso de línea los conceptos deben ser consistentes. 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). sin mayores problemas de volver a veces a la etapa de análisis. Cuadrar totales para referencia. Enviar solicitudes para actualizar el stock • Rut Nombre Dirección Teléfono 1 Agregar 2 Consultar 3 Imprimir Detalle de transacción • Nº documento • Código artículo Costo Cantidad 1 Cálculo total Productos C/E Mensajes 4 y 5 • Código artículo Tipo artículo Descripción Último costo Saldo 1 Agregar 2 Consultar 3 Imprimir 4 Sumar saldo 5 Restar saldo Objeto Ingreso de ventas Ingreso de compras Tabla de objetos. stock mayor a unidades por vender. Tipos de datos: afecta a los conceptos Encabezado de O/C y Detalle de O/C. Referencias cruzadas: no hay Notas: nada especial Excepciones: la no existencia de la línea en el sistema ya fue validada con el ingreso de O/C. mediante borradores sucesivos y la técnica de desarrollo en espiral (ver anexo 3) se avanza en el diseño. detalle y totales según Formato de pantalla adjunto Aceptar datos y actualizar línea a línea cada producto. Encabezado de transacción • Nº documento Fecha Rut persona 1 Agregar 2 Consultar 3 Imprimir C/E Mensaje 1 Personas Ingreso de transacción Encabezado. Ambos deben existir. Enviar mensajes para verificar Existencia de personas y artículos. • Se actualizó la asociación entre encabezado y detalle de O/C. Poscondiciones: •Se creó una línea en el concepto detalle. Salida: no hay Precondiciones: no existe la línea.

1: Crear (cod.. 1 Bodega . Proveedores Encabezado de O/C Nº O/C Fecha Crear línea Imprimir compuesta por 1 contiene * existe en 1 Rut Nombre Crear proveed. pre) Encabezado de O/C 1. cant... pre) Líneas de la O/C Diagrama de colaboración .MODELANDO UNA SOLUCIÓN DE SOFTWARE 33 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). cant.. pre) Terminal del administrativo 1: Crear línea de O/C (cod. Modificar Rut Modificar nombre se asocia a 1. Diagrama de diseño de clases Operación: Dar OK al Ingreso de la línea de O/C Ingresar producto (cód.* contiene * existe en 1 existe en almacena * Líneas de la O/C Unidades Precio Agregar línea Productos .. cant.

tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). HERRAMIENTAS TI CAPÍTULO 6. porque se refiere a entender la totalidad de la gestión de proyectos. conducción de calefacción. TEORÍA DE MODELOS CAPÍTULO 2. etc. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales .34 JUAN BRAVO C. 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. Análogamente. BOOCH. independiente de que su foco estará en las etapas de CAPÍTULO 7. no sólo en el ámbito tecnológico. CAPÍTULO 1. fontanería. INGENIERÍA DE SOFTWARE CAPÍTULO 1. electricidad. ORIENTACIÓN A OBJETOS CAPÍTULO 4. Esta es la primera competencia considerada para apoyar la elaboración de modelos de una solución de software. UML CAPÍTULO 5. Esto permite a un constructor ver una imagen completa antes de que comience la construcción. servicios. la arquitectura en el sistema de software se describe mediante diferentes vistas del sistema en construcción. Es necesario que el analista conozca la totalidad de pasos de un proyecto para insertar su aporte. con “visión de procesos”. JACOBSON y RUMBAUGH (2000. p. El edificio se contempla desde varios puntos de vista: estructura. 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. MÉTODO PARA LA GESTIÓN DE PROYECTOS Capítulo 1. Podríamos decir que es un conocimiento de tipo horizontal. MODELAMIENTO DE DATOS CAPÍTULO 3.

responsabilidad social. de apoyo o estratégicos. Veremos: • Trabajar metodológicamente • Claves de la implantación de método • Adaptación y profesionalismo • Etapas genéricas • Prácticas transversales Por habilidad organizacional entendemos una “competencia” que adquiere la empresa mediante una solución de software. señalado en el prólogo. gestión de riesgos. retroalimentación. comunicación. Por otra parte. La visión global. Tanto las etapas como las fases se pueden traslapar en los límites. Trabajar metodológicamente es una competencia indispensable para todo profesional del área de proyectos y para todo tipo de proyectos. trazabilidad. continuidad operacional. gestión de la calidad. ya sea que estén orientados a procesos del negocio. diseño. 9 . herramientas de apoyo. Las etapas están agrupadas en tres fases: estudio. kill time. es decir. entrevistas. equipo de trabajo. cuidar la solución anterior. plan de la etapa. 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. Son 28: dirección del proyecto. despliegue y operación. También existen prácticas transversales a las etapas. toda organización debe contar con un método para la gestión de sus proyectos. control de cambios. plan de recursos físicos del proyecto. Las etapas son los grandes bloques que aporta el método GSP: concepción. exposición de los planes. orientación al cliente. Quick wins. ahora puede vender a través de Internet o tener su contabilidad al día. desarrollo y mejora continua. costos y duración. por ejemplo. que ofrece un método es indispensable para entender la totalidad que surge de necesidades concretas en la empresa que los proyectos ayudarán a resolver creando una habilidad organizacional9. sistémica. factibilidad. capacitación. aplican en algunas o en todas las etapas del método. técnicas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 35 análisis y diseño. gestión del cambio y gestión de proveedores. inserción. seguimiento. implementación. Al método que presentamos en estas páginas le hemos llamado GSP (Gestión Sistémica de Proyectos). informes. sensibilización. análisis.

Fundamento conceptual: la visión sistémica 4. 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. p 82): “Un proyecto es un conjunto de acciones y recursos que tienen un objetivo no recurrente y un plazo o un costo fijos… para ejecutar un proyecto en que intervienen personas y recursos físicos. En la gestión de proyectos TI han bastado sólo 40 años para que la situación cambiara drásticamente. Una definición de la gestión de proyectos hace Alejandro Covacevich (1994. con iniciados que conocían los secretos del arte y que parecían estar juramentados para no revelarlo. hacer zapatos o construir catedrales. Hoy sabemos cómo hacer gestión de proyectos y ese conocimiento está al alcance de todos en la forma de métodos de alcance bastante amplio. De la misma forma comenzó el desarrollo de proyectos tecnológicos. visualizar el inicio y el fin de los procesos en que participa.36 JUAN BRAVO C. Sin embargo. que generalmente será más compleja mientras más recursos y personas intervengan”. Las mejores prácticas 3. . 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. ¿Qué es método? Antes de continuar. se necesita un ejecutivo que planifique. ¿Qué es método? 2. organice. Todas esas acciones configuran la gestión del proyecto. la incorporación a un oficio. TRABAJAR METODOLÓGICAMENTE En la Edad Media.1. 1. tal como ocurrió con la mayoría de los oficios de la Edad Media. Método GSP 1. era una iniciación en un gremio muy cerrado. ubicar su aporte en el contexto del proceso completo y trabajar en equipo con los demás participantes del proceso. controle y coordine. no ha sido necesario que transcurrieran 400 años para que ese arte se transformara en tecnología. Veremos: 1. dirija.

Las mejores prácticas El método presentado surge de revisar y ensayar con las propuestas de lenguajes. Es un método genérico porque la idea es conocer y seleccionar del medio las mejores técnicas (causa-efecto. 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. mapa de procesos. indica que. Un estudio realizado por Thompson y Perry usando un gran número de proyectos del Banco Mundial. rediseño e innovación sobre esa secuencia. De 42 proyectos controlados. Campero y Alarcón en su libro Administración de Proyectos Civiles señalan (1999. Refiriéndose a la buena gestión de proyectos. 3. ITIL. 2. de 1.627 proyectos revisados. normas de calidad y herramientas que el mercado ofrece. flujograma de información. pp. Las prácticas que adquieren las personas con la competencia método se pueden 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. aceptación del caos y de la complejidad. UML. lo cual aplica para todo tipo de procesos y proyectos de cambio organizacional. creatividad. quienes deben trabajar metodológicamente. 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. aprendiendo de tales opciones e incorporando las mejores prácticas para aplicar en las organizaciones de Latinoamérica.MODELANDO UNA SOLUCIÓN DE SOFTWARE 37 Se desprende de la definición que método está asociado con personas. también conocida como pensamiento sistémico. PMI. Fundamento conceptual: la visión sistémica El modelamiento de soluciones de software tiene su base conceptual en la visión sistémica10. de 1. el 70% de ellos no alcanzó a la tasa interna de retorno (TIR) esperada”.778 proyectos revisados. en el 63% de los casos el costo final superó el presupuesto. el 88% terminó con atraso. visión aérea. 10 El libro Análisis de sistemas se refiere en su totalidad a visión sistémica. donde podemos profundizar en trabajar con calidad y excelencia. . orientación a objetos y otras) avanzando hacia las estandarizaciones formales o de hecho.

148): “La clave del pensamiento sistémico es la palanca: hallar el punto donde los actos y modificaciones en estructuras pueden conducir a mejoras significativas y duraderas. 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. La visión sistémica nos ayuda a “ver” el todo. la autoorganización. 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. Conviene conocer algo de la visión sistémica porque nos ayuda a entender por qué hemos organizado el mundo tal como lo conocemos. El pensamiento 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. la irreversibilidad del tiempo. Tradicionalmente 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. la “inteligencia” de los sistemas y nuestra responsabilidad con el bien común. 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 cooperación de quienes modelan es vital. en volver a unir las partes de los rompecabezas que hemos creado. en fragmentos. p. Pero esos esfuerzos a lo sumo. todas las cuales aportan a una visión más amplia. A la vez. la energía presente y descubrir sus características distintivas. mejoran la situación en el corto plazo. apreciar sus interacciones. También nos ayuda a pensar en integralidades. sociología. acepta la complejidad que nos excede. pedagogía. Peter Senge provee algunas claves en su libro La quinta disciplina (1992. aquellas que son propias del conjunto y que no existen en las partes. Este nuevo paradigma tiene su propio campo de conocimientos y se nutre desde otras disciplinas: antropología. buscando el lugar donde los mejores resultados no provienen de esfuerzos en gran escala sino de actos pequeños y bien focalizados. y la empeoran en el largo plazo”. buscando especialización. psicología. y orientado a su interior. .38 JUAN BRAVO C. ¿Qué es un sistema? No existe una definición generalmente aceptada para un “sistema”. A menudo la palanca sigue el principio de la economía de medios. Por ejemplo. ubica el sistema en su entorno.

en el sistema circulatorio o en el sistema digestivo. pasando por todas las etapas de su ciclo de vida: concepción. con etapas genéricas. de sistemas monetarios.MODELANDO UNA SOLUCIÓN DE SOFTWARE 39 Dice Idalberto Chiavenato (2000. El plan de proyecto es una totalidad con contenidos mucho más allá de la carta Gantt. amplio uso de técnicas del medio. La sociología habla de sistema social. la administración. justificación de la necesidad y mucho más según veremos en la etapa de factibilidad en la sección 1.4. método. Es un método abierto. implementación. siendo fácil seguir el avance del proyecto durante el desarrollo… Un buen plan incluye los siguientes items: alcance del proyecto. El plan deja por escrito las necesidades del cliente. la economía. Además. Y en este texto lo estamos aplicando a modelar soluciones de software… 4. 135): “Para comunicar a los clientes el análisis y la gestión del riesgo. así como lo que se espera hacer para satisfacerlas. en especial. El Método GSP es parte de un modelo integral para la gestión de la innovación en la organización que contempla las definiciones estratégicas. despliegue y operación. En la actualidad. cro- . y así sucesivamente. el cronograma y la organización. Método GSP El Método GSP (Gestión Sistémica de Proyectos) es una guía para el desarrollo completo de un proyecto. p. diseño. 769): “El concepto sistema pasó a dominar las ciencias y. Si se habla de astronomía. de sistemas atómicos. cálculos financieros. el plan de proyecto contempla dos líneas de trabajo paralelas. formación de las personas. la física. apoyo de herramientas existentes y aplicación de las mejores prácticas. si el tema es fisiología. se piensa en el sistema solar. incluye también la historia del proyecto. creación de estructura organizacional y apoyo tecnoló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. El cliente puede remitirse al plan para tener información sobre las actividades del proceso de desarrollo. se piensa en el sistema nervioso. factibilidad. el enfoque sistémico es tan común en administración que no se nos ocurre pensar que estamos utilizándolo en todo momento”.4). usualmente se escribe un documento denominado plan de proyecto. como las vías del ferrocarril: • Etapas del proyecto • Prácticas transversales Shari Pfleeger señala (2002. p. análisis.

organización del equipo de trabajo. de riesgos. descripción técnica del sistema propuesto. estándares del proyecto. nograma. dee recursos y muchos otros. tales como plan de aseguramiento de calidad. En la figura 1-1 se presenta la totalidad del método GSP.40 JUAN BRAVO C. Totalidad del método GSP . Método GSP Etapas del método genérico (CFADIDO) Concepción Factibilidad Análisis Diseño Implementación Despliegue Operación Prácticas Transversales Dirección del proyecto Plan de la etapa Gestión de riesgos Retroalimentación Capacitación Entrevistas Comunicación Informes …y las otras 20… Figura 1-1. La lista se extiende hasta los planes específicos para las prácticas transversales. procedimientos y técnicas y herramientas propuestas”.

Circularidad Clave 1. no existe todavía una forma normalizada de cada mapa. CLAVES DE LA IMPLANTACIÓN DE MÉTODO Son claves que guían el trabajo en la implantación de método. Previo. completo. su propia base de datos y el registro de cambios. Así efectivamente es una visión de conjunto. tampoco se puede internalizar mediante pastillas (ni disponemos todavía de la tecnología de la película Matrix. es decir. Se recomienda por su gran efectividad. Clave 1. Siendo tan reciente la aplicación de la visión sistémica en el modelamiento. también aplican para los proyectos que utilizarán el método en la organización. retroalimentación y sistemas. en la forma de un mapa territorial. Método tiene que ver con el desarrollo de competencias de las personas. Por supuesto. Los mapas deben estar disponibles para toda la organización en dos formatos: • En digital. como una máquina. proyectos. A esto le llamamos mapa global. con un trabajo arduo de generar estándares internos y sumarse a normas externas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 41 1. así es que eso puede ser una buena alternativa de flexibilidad para seguir experimentando. la visión de conjunto se apoya en cinco mapas globales: necesidades. • En papel.2. que puede estar pegado en la pared. es necesario sincerar lo que realmente hace la organización con método y lo que está dispuesta a aplicar. los cuales veremos en las siguientes páginas. Hemos detectado 4 claves. es vital mantener una versión actualizada de cada uno de ellos. Cinco mapas globales para la visión de conjunto Además de ver el método en su totalidad. son recursivas. según las herramientas elegidas por la organización y que sean de fácil acceso para todos. Mínimo indispensable Clave 3. Cinco mapas globales para la visión de conjunto Clave 2. Método no es algo que solamente se compra y usa. Participación de todos los actores Clave 4. aquella donde Neo aprendía rápido mediante un tubo conectado directamente al cerebro). . procesos. Cada mapa debe tener una documentación de apoyo con los atributos de cada componente. No hay problema que tenga varios metros de largo.

. Bienestar Productividad Calidad Costo Responsabilidad Social Tiempo Soluciones propuestas: 1. Estos mapas deberían crearse como parte de la implantación del método. Cada vez que se detecta una necesidad genérica se incluyen causas y soluciones. Esta es una gran oportunidad para resolver a nivel de problemas genéricos y hacer que la organización como un todo sea más inteligente. dos estudios para responsabilidad social. Pago tardío a Proveedores 2. a) Mapa de Necesidades Señala las necesidades genéricas de la organización que se están estudiando y resolviendo.42 JUAN BRAVO C. Trabajadores fuman en sector atención clientes Figura 1-2. aunque adaptando según la cultura y el nivel de avance previo de la organización. En la figura 1-2 se muestra. como ejemplo. El conocimiento que hemos adquirido es que las causas de fondo de los problemas tienden a ser parecidas. Alinear con la estrategia 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. Incluir como plan de acción de RS Problemas detectados: 1.

Mapa de proyectos con relaciones para reubicar personas Un mapa de proyectos tiene múltiples aplicaciones. ayuda a evitar despedir personas que quedan liberadas de procesos obsoletos. Lo mismo es válido para los recursos de la empresa: espacio físico. desde el punto de vista de responsabilidad social. ellos pueden aportar en otros proyectos. En el mapa de la figura 1-3 se usa para establecer un sistema de vasos comunicantes entre proyectos. 11 . equipamiento. 10p 2p 1p = Libera = Neutro = Requiere 7p Figura 1-3.MODELANDO UNA SOLUCIÓN DE SOFTWARE 43 b) Mapa de Proyectos Muestra todos los proyectos que se están realizando en la empresa y permite establecer relaciones entre ellos. el otro tercio requiere y el último es neutro. uno que libera personas y otras que las requieren11. etc… Hemos visto que más o menos un tercio de los proyectos libera personas y recursos. por ejemplo.

Procesos Estratégicos Desarrollo Planificación Estratégica RS Gestión de Procesos Gestión de Proyectos Gestión de Calidad Control de Gestión Gestión de Contratos Gestión de Personas Ana lizar cargos Recluta r Inducir Evaluar Formar Diseñar ca rrera Proceso del Negocio Comercializar Proyectar ventas Conocer la demanda Visitar Clientes Estadísticas internas Emitir O/C Almacenar Traspasar Comprar Recibir Distribuir Planear cada local Emitir traspaso Ordenar Preparar cada local Presentar Coordinar merchand. Mapa de procesos de Fabrica de Electrodomésticos Linhogar El mapa de procesos es una gran contribución de la gestión de procesos12 porque permite que cada levantamiento y rediseño de procesos aporte al mapa global y viceversa.44 JUAN BRAVO C. . evitándose la práctica tan cara de repetir el levantamiento de un cierto ámbito en cada aplicación de software. En este caso se muestra para la empresa comercial e industrial Linhogar (nombre ficticio por supuesto). Nótese en la figura 1-4 que la práctica es ubicar arriba los procesos estratégicos. ya sean estratégicos. Vender al detalle Vender Postventa Atención al cliente Medición y seguimiento Servicio de garantía Cotizar Recepcionar Despachar Cuadrar Procesos de Apoyo Adquisiciones Servicios Básicos Finanzas Contabilidad Legal Transporte Remuneraciones y bienestar Tecnología y Mantención Figura 1-4. del negocio o de apoyo. c) Mapa de Procesos Quedan reflejados todos los procesos de la organización. al centro los del negocio y abajo los de apoyo. en proyectos de gestión de calidad o cualquier otro. 12 Ver libro del mismo nombre.

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. Así se puede capitalizar la retroalimentación.MODELANDO UNA SOLUCIÓN DE SOFTWARE 45 d) Mapa de Retroalimentación Lleva registros de eventos enriquecedores al finalizar los proyectos. . Meditación Buen trabajo en equipo Liderazgo sistémico Alcance poco claro Retroalimentación de eventos destacados Demora en entrega final Dificultades para coordinar entrevistas con usuarios = Experiencias para evitar = Experiencias para replicar Figura 1-5. Mapa de retroalimentación para replicar o evitar Es fundamental que el mapa este a la vista y siempre actualizado. Nótese que se evitó la distinción “positiva” o “negativa” de experiencias porque todas las vivencias sirven en la medida que haya una buena retroalimentación y que efectivamente se use en proyectos futuros. Hay lugares donde se hace retroalimentación en un informe de fin de proyecto que luego queda archivado y nadie lo lee. En la figura 1-5 se usó la forma de un mapa mental. Conviene conocerlos ya sea porque son experiencias que es bueno replicar o porque hubo sucesos que queremos evitar.

. este mapa de sistemas computacionales es vital para modelar la solución de software.46 JUAN BRAVO C. En la medida que se considere necesario. sobre la línea se pueden indicar las entradas y salidas. e) Mapa de Sistemas Computacionales Indica las aplicaciones que existen en la organización y las relaciones principales entre ellas. se avanza hacia un esquema de componentes. Al proporcionar las entradas y salidas y que además estén visibles para todos los analistas y constructores. Cobranzas Devolución Ventas Facturación Compras Bodega Entrega Recepción Figura 1-6. como en un diagrama de contexto. estándares y conceptos (UML. Mapa de Sistemas Computacionales Junto con el mapa de procesos y el modelo conceptual de datos de la organización. En la figura 1-6 se consideraron algunos sistemas tradicionales. SOA y otros que veremos en los capítulos de este libro). tal como proponen las nuevas normas.

porque su orientación es simplicidad. • La alta dirección. Se pueden identificar usuarios ejecutivos y usuarios operativos. Aplica aquí la ley de los pocos críticos y muchos triviales de Vilfredo Pareto. sino por reflexión o toma de conciencia. 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 respecto a lo que se considere mínimo para la organización particular. flexibilidad y aplicabilidad. 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. • Profesionales de proyectos forman el equipo de trabajo: gerente de proyecto. especialistas en procesos y tecnología. El mínimo indispensable significa un método flexible y preciso. para que realmente sea utilizado en las organizaciones latinoamericanas. además de consultores. por ejemplo: • El cliente es el cliente. Clave 3. él paga los sueldos de todos y es a quien sirven los proyectos en definitiva. se debe validar cada proyecto a la luz de sus intereses. no por imposición. Participación de todos los actores Implantar un proceso de gestión de proyectos en la organización es una tarea de todos. Está fuera de la organización. • El usuario es quien hace uso de los sistemas para servir a los clientes. habitualmente es una combinación de sensibilización. . independiente que alguien lo administre. El método que se decida no puede ser propiedad de una parte de la organización. bien adaptado a la realidad de la organización y de cada proyecto particular. Mínimo indispensable Se trata de negociar el alcance de la implantación del método bajo el criterio del mínimo indispensable. Lo primero es identificar los actores. es decir. capacitación y coaching. Por lo tanto. el mínimo que todos los interesados se comprometen a cumplir. Por ejemplo. pertenece a toda ella. Es importante considerar que este mínimo indispensable estará influido por la cultura de la organización en cuanto a disciplina y estandarización.MODELANDO UNA SOLUCIÓN DE SOFTWARE 47 Clave 2. 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. gerencia u otra autoridad se encarga de la toma de decisiones respecto al proyecto.

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. Circularidad Implantar un método puede seguir la forma de desarrollo en espiral. a partir de negociaciones respecto a lo que realmente las personas quieren y pueden hacer. ¿dos años? ¡Demasiado! podría decir la comunidad.48 JUAN BRAVO C. Debemos asegurarnos que lo nuevo es efectivamente mejor. donde aplica todo lo indicado en este texto. La gradualidad es el concepto de fondo. sin el encandilamiento transitorio que tanto daño provoca. Con el desarrollo en cascada la implantación puede ser larga. Justamente una de las ideas centrales de este método es el buen manejo del cambio. Clave 4. muy larga. es decir. Así. . donde se plantea que un sistema en buen funcionamiento es una joya que debe tratarse con mucho cariño. implantar sobre la base de avances sucesivos. Es interesante observar que solamente difundir el método es un proyecto en sí mismo.

Adhesión a estándares y normas de calidad El método GSP existe para la buena gestión de proyectos y tiene una complejidad que no puede ser reducida artificialmente. Una buena idea es un programa del tipo paperless (sin papel) que están impulsando muchas organizaciones. Estructura para la gestión de proyectos 4. Son temas relacionados con la calidad de la información y la habilidad de representar adecuadamente el flujo de los procesos. . CMM. normas ISO. porque corremos el riesgo de simplificar demasiado. UML. normas de calidad y aprendizajes del medio (tal como los aportes del PMI). actualización permanente. el método GSP es abierto y se enriquece trabajando con estándares formales o de hecho. SOA. Además de cumplir con la normativa interna y externa obligatoria. orientación a objetos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 49 1. flexibilidad para abordar todo tipo de proyectos y negociación para tener una estructura organizacional adecuada. ITIL. Además. Por profesionalismo aplicado al método entendemos la conducta ética y visión global que todo profesional debiera tener. Adhesión a estándares y normas de calidad 2. flujogramas de información con el criterio curso normal de los eventos. ADAPTACIÓN Y PROFESIONALISMO Entendemos la adaptación del método en varios sentidos: incorporar estándares. PMI y otros (todas estas siglas y los conceptos asociados son tratadas dentro del texto). Veremos: 1. tales como: mapas de procesos globales.3. evitando digitaciones. Aportes del PMI 5. Ética y visión global del profesional 1. 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. trabajar todo lo posible en formato digital. así es que incluimos algunas palabras al respecto. Actualización y adaptabilidad del método 3.

Tenemos que aprender a elaborar buenos planes y mantenerlos actualizados. sin darles el mismo espacio visual que el curso normal de los eventos. confiable. completa. 13 . si queremos que la aplicación tenga éxito. de calidad y con la profundidad necesaria. en esto debe existir armonía con la realidad. van como texto fuera del modelo cuando son relevantes. Actualización y adaptabilidad del método El concepto es que se planifica al comienzo y se continúa planificando durante todo el proyecto. relevante para el cliente. Lo veremos en detalle en el capítulo 3 (teoría de modelos). fallará”. considerar los riesgos. 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 abandona la antigua. menos. rápidamente pierde sentido por la dinámica de la realidad. donde lo más habitual aparece más y lo menos. Es lo que veremos a continuación. prevenir y confeccionar planes de contingencia. por la imperiosa necesidad de mantener actualizadas las definiciones. Se aplica especialmente en flujogramas de información y casos de uso expandidos. Es bueno tener presente la conocida afirmación de Murphy: “si algo puede fallar. Es que la confiabilidad pertenece al sistema y la credibilidad al usuario. sino además parecerlo. 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. peyorativa e inútil pretensión de “construir sistemas a prueba de tontos”. creíble13. debemos actuar con pragmatismo y adaptar el método según el tipo de proyecto.50 JUAN BRAVO C. En el método GSP se reconoce la importancia de la información y sus atributos: oportuna. Por lo tanto. por eso decían: la mujer del César no sólo debe ser virtuosa. porque si sólo existe el plan inicial. 2. Las excepciones se definen aquí como situaciones indeseables que perturban el flujo. Un dato puede ser confiable pero no creíble. La idea general es tratar las excepciones como excepciones.

. 21–23). Jeff Davidson.MODELANDO UNA SOLUCIÓN DE SOFTWARE 51 Pragmatismo Pragmatismo es hacer lo mejor que se pueda hacer para lograr los objetivos de un proyecto. reescritura de software existente. como en el yin y yang (la armonía de los opuestos. Hay problema cuando el motivo es porque la etapa anterior no se hizo correctamente. pp. por ejemplo: primer proyecto de su tipo. Es lo que explica Alfredo Weitzenfeld en su libro acerca de ingeniería de software (2005. es lo opuesto al fundamentalismo. 35): “Una creencia común. aunque sin llegar a saltarse etapas. p. aunque equivocada. No hay problema en la medida que sea por adaptación a nuevas circunstancias. Es darse cuenta que en un momento del tiempo hay una bifurcación mejor a la “establecida”. más bien sería el complemento. variación de un proyecto. Adaptación según tipo del proyecto La idea es adaptar el método a cada tipo de proyecto según su tamaño. A propósito. nivel de avance y otras condiciones. creación de software reutilizable y proyecto de mejora o mantenimiento”. segundo proyecto de su tipo. No es sinónimo de improvisación ni de liviandad en seguir un método. 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. el justo medio que proclama Confucio). es la existencia de un solo modelo de proceso aplicable a cualquier proyecto. Se puede negociar las actividades que incluiría y el alcance de las prácticas transversales. pues el modelo de proceso depende del tipo particular de proyecto. en su libro La Gestión de Proyectos (2001.

000 • Proyecto grande: más de US$ 1.000. . Esa es la idea de la figura 1-7. como estas. En el caso del tamaño del proyecto lo primero es definir que se entiende por tamaño. controles y cantidad de participantes. Debería hacerse un esfuerzo metodológico especial. aumentando un orden de magnitud cada vez (aceptando que los límites entre tramos son difusos): • Proyecto pequeño: hasta US$ 100.52 JUAN BRAVO C. por ejemplo. aunque.000 • Proyecto mediano: más de US $ 100. una posibilidad es trabajar con distinciones simples. 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.000 Más allá son proyectos muy grandes para la realidad de Latinoamérica y más bien escasos. Desde la gestión de procesos sabemos que el tamaño determina nuevas formas de hacer las cosas.000 y hasta unos US$ 10. Adaptación del método a cada tipo de proyecto Por ejemplo.000.000 y hasta US$ 1. Método de la Organización Adaptación Aplicación a un tipo de proyecto Figura 1-7. puede llevar a tener una especie de Fast Track (vía rápida) en el caso de proyectos prioritarios por alguna contingencia o por necesidades estratégicas. por supuesto. la prioridad.000. donde el método de la organización es una base de conocimiento que se adapta a cada tipo de proyecto particular. mantiene un tronco común.

2. Eventualmente las áreas de metodología y de UTP pueden ser áreas diferentes y que trabajan coordinadamente. es decir. para cada mapa se indica el área más adecuada: • 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. se incorpora aquí una labor más bien operativa. a) Área de metodología o UTP En el área de metodología trabajan los responsables del método. 14 Es la primera clave de la implantación de método de la sección 1. Por ejemplo. Esto es lo que se denomina “incorporar” a la organización. “hacer carne”. llevar al cuerpo. También se le llama PMO (Project Management Office). 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. sumar a la estructura organizacional. es decir. Estructura para la gestión de proyectos La buena gestión de proyectos también tiene que ver con una serie de instancias de estructura organizacional o funciones. 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. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 53 3. quienes lo actualizarán y difundirán.

Se centra en las etapas de análisis. 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).54 JUAN BRAVO C. Por supuesto. c) Área de desarrollo Aquí se modelan e implementan los proyectos interna o externamente. cada uno cuenta con un plan de proyecto. el desafío es organizar un equipo de personas que actúen con efectividad y mística en la toma de decisiones. El área de desarrollo se hace cargo de los proyectos aprobados y listos para concretarse. Es un área que ayuda a generar mucha rentabilidad a la organización. la figura del Comité de Proyectos (CP) introduce una mirada sistémica y de negocios. implementación y despliegue del método GSP. En el fondo. así como definir la forma de toma de decisiones en casos de emergencia. el CP requiere una fórmula simple para administrar los compromisos vigentes e históricos. Una exigencia es que el área de desarrollo se coordine con un área de aseguramiento de calidad. Uno de los principales entregables de esta área son los planes de proyectos cuando ya se cuenta con la autorización de desarrollo. d) Comité de Proyectos15 Considerando que los proyectos sirven a procesos estratégicos. Se centra en las etapas de concepción y factibilidad del método GSP. diseño. También recibe la retroalimentación de los proyectos en desarrollo. Con este u otro nombre. b) Área de estudios El área de estudios se dedica a procesar propuestas para necesidades y soluciones. . del negocio y de apoyo en la organización. Al finalizar el proyecto. porque deja en evidencia la gran cantidad de proyectos que se pueden realizar. ayuda a aprovechar el gran potencial que existe en la mente de todos los integrantes de la empresa y que generalmente se pierde. 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.

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. riesgo y adquisiciones. El informe lleva la firma de todos los actores relevantes. costo y otras variables respecto al plan.com ó www. se definen nueve áreas de conocimiento: integración.cl ó www. uno de los más relevantes es el PMBOK. alcance.pmi. Tick IT y otras. Son grupos de criterios generales para la buena gestión y administración de proyectos. recursos humanos. Corba y MDA. Además de estándares formales o de hecho tales como ITIL.pmi. costo. Aportes del PMI PMI son las siglas del Project Management Institute.MODELANDO UNA SOLUCIÓN DE SOFTWARE 55 cómo se comportaron el plazo.org. gestión de la calidad y sistemas. son llamados “Capítulos”. e) Áreas relacionadas En la gestión de proyectos se trabaja con áreas cercanas. 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 recopilación de las mejores prácticas) y es conveniente conocerlo16. calidad. 16 Así como deben ser conocidas las normas CMM.pmi. 4. Más en www. Todos ellos los veremos en el capítulo segundo. comunicaciones. . tales como gestión de procesos. una organización de clase mundial que recoge las mejores prácticas para la realización de proyectos y las presenta en documentos. Existe una organización local en la mayoría de los países de Latinoamérica. ISO 9000. Esto es independiente de los entregables por cada etapa cuya aprobación depende de la estructura que el mismo CP aprobó. 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. tiempo.

12-13): “Deben comportarse de una forma ética y moral responsable si es que desean ser respetados como profesionales. • La Planificación de la calidad identifica qué estándares de calidad son relevantes para el proyecto y luego determinar como satisfacerlos. 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. especialmente en dos aspectos: comportamiento ético y visión global. • El Aseguramiento de la calidad incluye todas las actividades. Ian Sommerville señala (2005. • El Control de Calidad implica verificar los resultados específicos del proyecto para determinar si estos cumplen con los estándares de calidad relevantes e identificar maneras de eliminar las causas de los resultados insatisfactorios. 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. No basta con decir que usted debe poseer estándares normales de honestidad e integridad. Ética y visión global del profesional Un aspecto central de la totalidad que representa la GSP es la integridad del profesional. contempla: planificación de la calidad. planificadas y sistemáticas. pp. Algu- . 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. implementadas en el marco del sistema de calidad. Comportamiento ético Respecto a la ética de los profesionales. por ejemplo. 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”. ambos considerados dentro de trabajar metodológicamente.56 JUAN BRAVO C. Sin embargo. Gestión de calidad en proyectos Es un tema fundamental abordado por todos los métodos existentes. aseguramiento de la calidad y control de calidad. requeridas para brindar confianza en que el proyecto va a satisfacer los estándares de calidad relevantes. 5.

Aconseja Davidson (2001. procesos y estructura organizacional. 17 Ver libro Análisis de Sistemas. p. es vital definir y conocer lo que se quiere lograr.MODELANDO UNA SOLUCIÓN DE SOFTWARE 57 nas de estas son: confidencialidad. derechos de propiedad intelectual y uso inapropiado de los computadores”. todos los actores del proyecto deben tener claridad en objetivos. Tener la vista puesta en el destino ayudará a darle sentido a todas las actividades del proyecto. . Un analista de sistemas debiera tener la capacidad de trabajar en “la mesa” completa. En tal caso puede ocurrir que no existan otros profesionales para desarrollar la estrategia y los demás elementos del modelo de negocios: personas. Más allá de los entregables por etapa. 33): “Al tener una idea clara del final deseado. todas las decisiones que se tomen respecto al proyecto irán en el mismo sentido con más probabilidad de lograr ese final deseado”. el para qué Por otra parte. no falsificar su nivel de competencia. al menos en el mínimo indispensable. resultados y propósito alineado. Otra opción es que el analista avise de esta situación para que otras personas se encarguen de cubrir lo que falta del modelo de negocios. Pasión por conocer la finalidad. los objetivos finales. la práctica ha sido que los mismos analistas encargados del desarrollo computacional del sistema de información se encarguen del desarrollo completo del modelo de negocios. Para ello es vital una formación lo más completa posible17. 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.

el entregable es un plan de proyecto. El acróstico es CFADIDO. En la figura 1-8 (como una punta de flecha) se aprecia el esfuerzo promedio estimado de cada una18. ETAPAS GENÉRICAS Ya vimos que las etapas son las distinciones principales del trabajo en el proyecto. Incluye las etapas de análisis. diseño. • Desarrollo: donde el plan se materializa. 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. Factibilidad. obtenido desde la duración estimada de las etapas en proyectos exitosos. Diseño. implementación y despliegue. . 18 Este promedio es parte del método GSP. lo cual también debería estar estimado en el plan de proyecto. la más extensa y que existe mientras dura la vida útil de la solución. 1. Implementación. Hemos identificado siete: Concepción. Análisis. Estudio Desarrollo MC C F A D I D O Figura 1-8. Como todo promedio. Incluye las etapas de concepción y factibilidad. Contiene solamente la etapa de operación.58 JUAN BRAVO C. Nótese que a partir de la etapa de diseño se expande el trabajo incorporando la especialización de otros actores.4. • Mejora continua: donde la solución ya en operación se mantiene y perfecciona. El entregable es la solución completa y en explotación. además de los informes para trazabilidad. Despliegue y Operación. es solamente un punto de referencia y no aplica a casos particulares. Lo habitual es que cada fase sea realizada por equipos y áreas diferentes.

Es preferible no comenzar si no se cuenta con la aprobación correspondiente. • Revisar al inicio de la etapa que los documentos de entrada están vigentes. hace un diseño detallado. Generalmente esta actitud es un ejemplo más de la enfermedad “ejecutivitis” de una jefatura que quiere todo “para ayer”. viene la fase de desarrollo. Es similar al desarrollo de un nuevo producto: alguien lo gesta y luego define el producto. alguien lo concibe y hace una evaluación del proyecto (como en las etapas de concepción y factibilidad). que en el método GSP sería equivalente a las etapas de implementación y despliegue. conductos eléctricos.) similar a los cómo que detalla la etapa de diseño en el desarrollo de software. una vez aprobado. la creación de un nuevo producto o el rediseño de la estructura organizacional? Todos aplican el ciclo de vida de un proyecto. donde: • Se hace arquitectura. lo que trae muchas dificultades a la larga y no es profesional. sin embargo. Aunque todo proyecto tiene las mismas etapas. El objetivo es evitar errores que producirán dificultades cada vez mayores en los siguientes pasos. Después. construye y da servicio postventa. su alcance puede diferir según las condiciones particulares del proyecto. • Se realiza la ingeniería de detalle. una solución creativa que se representa en maquetas y que resuelve los grandes qué del edificio. Luego viene la construcción. puede ser necesario actualizarlos (eventualmente rehacer la etapa anterior). etc. Esto puede parecer evidente. tal como veremos que ocurre en la etapa de análisis para las aplicaciones de software. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 59 ¿Qué tienen en común la construcción de un edificio. es increíble la cantidad de acciones que se inician sin estar formalmente aprobadas. porque es posible volver a etapas anteriores en un proceso de retroalimentación producto de las necesidades del proyecto. es decir. Es fundamental cumplir todas las etapas del método para lograr éxito en el proyecto. Antes de construir un edificio. el usuario líder u otra autoridad. • Entre cada etapa es necesario lograr la autorización de inicio por el Comité de Proyectos. tanto de la obra gruesa como de todos sus componentes (ascensores. el desarrollo de un sistema computacional. Que esto no se confunda con rigidez. en ambos casos. los planos detallados del edificio. es decir. Son importantes algunos aspectos comunes a todas las etapas: • Revisar las prácticas transversales más relevantes para la etapa. sigue la operación y las mejoras.

hay muchos síntomas difíciles de interpretar. Análisis 4. Factibilidad 3. definido como una distancia. El problema de fondo nace desde la causa raíz de la confusión. Es necesario aclarar la confusión para obtener un enunciado validado. la confusión lleva implícita una oportunidad. Entonces. Concepción Entrada: síntomas o definiciones estratégicas Entregable: una necesidad validada. más los entregables de las etapas anteriores. 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. . dolor o dificultad. porque es necesario conservar la trazabilidad del proyecto y es seguro que será necesario realizar cambios en modelos que fueron resultado de una etapa anterior. Implementación 6. Una estimación de este esfuerzo debe estar contemplada en la autorización de inicio por parte de la autoridad. Diseño 5. o un problema. Veremos: 1. Decimos que es una confusión porque no sabemos realmente cuál es el problema de fondo. Operación 1. puesto entre comillas porque al comienzo resulta pretencioso llamarle así. Por supuesto.60 JUAN BRAVO C. más bien lo que se tiene es una confusión o una sensación de molestia indefinida. Concepción 2. a eso le llamamos Problema. El objetivo de esta etapa es concebir una necesidad. La confusión es un conjunto de síntomas que toman forma de inquietud. • La entrada a una etapa es el entregable de la etapa anterior. la solución de la confusión es el problema. Despliegue 7. 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). entre donde estamos y donde queremos estar. hablamos genéricamente de “Problema”.

Aquí debiera hacerse un análisis estratégico desde el punto de vista de las necesidades ¿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 necesidades estratégicas (recuérdese que todavía no hablamos de soluciones).MODELANDO UNA SOLUCIÓN DE SOFTWARE 61 Yendo a los fundamentos conceptuales. antes de hablar de las soluciones. Esta salida también puede provenir desde las definiciones estratégicas o desde el mapa de necesidades de la organización. el comité de estudios decide principalmente dos caminos: a) Solicita un estudio más detallado de la necesidad. la visión sistémica tiene especial predilección por invertir tiempo en la adecuada definición de los problemas. b) Solicita el cierre de la etapa de concepción con el entregable que corresponda. por ejemplo. ¡la solución está incluida! Nos podemos ayudar en esta etapa con una serie de técnicas. Pareto. en ambos casos. De hecho. una noche de sueño y otras. ¿Resultado? sobre el 70% de las empresas prefirió cerrar. el de fondo. porque igual es necesario cuantificar19 y dar un formato común para pasar a la siguiente etapa.2. Suena utópico. sin embargo. tomemos una situación real: la obligatoriedad de la incorporación de una norma de calidad a todas las empresas de capacitación de Chile en el 2006. meditación. no más de una página). una opción es que el dueño de la empresa decida cerrarla. es preferible no saltarse la etapa aunque la necesidad sea obligada. tercera y cuarta parte. en teoría de sistemas se dice que cuando uno descubre el verdadero problema. se pueden encontrar mayores alcances acerca de la importancia de la participación y de su impacto positivo en los resultados. Durante la concepción tiene uso predominante el mapa de necesidades (ver sección 1. 19 Además. claves de la implantación de método). nunca la decisión es “obligada”. 20 En el libro Análisis de Sistemas. los siete por qué. desde el mapa de necesidades o desde la obligatoriedad de implantar una norma? No. ¿Es posible saltarse esta etapa cuando una necesidad proviene de un proceso de planificación estratégica. se le considera una “necesidad”. por ejemplo: causa efecto de Ishikawa. . Si se aprueba esa detección. Todo integrante20 de la organización puede detectar necesidades (ojalá en un formulario sencillo o una pantalla simple en el computador.

viene dada desde la etapa de concepción. p. La toma de decisión sería después de realizar cada una de estas acciones: En el libro Análisis de Sistemas se trata extensamente acerca del énfasis en el problema. 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. Aunque no permanezcan todo el día allí. que Isaac Getz y Alan Robinson. páginas 50 a 58. Factibilidad Lo que da origen al trabajo en la etapa es una necesidad de la organización. • Á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. a veces les bastan unos minutos para tener una idea útil”. Suponemos un Comité de Proyectos (CP) en lo que sigue. Un buen apoyo es el libro Desarrollo de sistemas de información. Quinta parte. afirman (2005. Un informe típico de esta etapa debería incluir los siguientes puntos. 22 21 . 30): “Los empleados de primera línea. están mejor situados que los directivos o los ingenieros para detectar los problemas y encontrar las soluciones. 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. en su libro Tus ideas lo cambian todo.62 JUAN BRAVO C. que trabajan en la frontera. También el libro Análisis de Sistemas. Es tan importante la detección de problemas y la consiguiente generación de ideas de los colaboradores de terreno. se accede al siguiente después de la toma de decisión por parte de la autoridad correspondiente. En ambos caminos recurre a profesionales especializados de dentro o fuera de la organización. una visión práctica.

Este plan considera el programa de actividades (carta Gantt). p. 32 ): “Deducimos que es la diversidad de conocimientos suficientes en una multitud de campos. . legal y económica. la evaluación comparativa. Se exploran amplias posibilidades de solución al problema hasta decidir por la fórmula que se considere más apropiada. También la integralidad en el conocimiento es importante. Usamos la palabra solución porque es más amplia y representativa que indicar solamente rediseño de procesos o aplicación computacional. el impacto estratégico. c) El plan de Proyecto de la alternativa seleccionada. en cualquiera de esas acciones. el VAN interno y social. por supuesto. Además. tal como señalan Getz y Robinson (2005. ¿Qué técnica es buena para la invención? Además de las técnicas indicadas en la etapa de concepción. b) Una evaluación comparativa de alternativas de solución seleccionadas. el equipo de trabajo por etapa. lo más probable es que la solución seleccionada resulte de una combinación de varias alternativas. estructura y tecnología. 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. su historia. con diferente énfasis en cada una. la descripción. Creatividad aplicada En esta etapa es vital la creatividad e inventiva aplicada en la búsqueda de soluciones.1). Por supuesto. Así evitamos la rigidez paradigmática que se produce cuando desde el principio alguien cree que tiene “la solución”. el CP puede solicitar replantear el estudio. la evaluación técnica. Cada una incluye acciones respecto a las personas. se puede mencionar: tormenta de ideas. y no el conocimiento excepcional en un solo campo lo que contribuye al surgimiento de grandes ideas. y esto a través de asociaciones inesperadas”. procesos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 63 a) Una investigación creativa de muchas soluciones y propuesta de alternativas a estudiar. Se revisa que cada alternativa evaluada esté alineada con la estrategia de la organización. búsqueda bibliográfica y consultoría. seis sombreros para pensar. comparación con otras organizaciones. el análisis de riesgos. Pueden presentar este formulario los evaluadores designados para ello por el CP y que cuenten con las competencias necesarias.

logística. Kanban. completitud. producción flexible. por ejemplo: cadena de valor. Getz y Robinson agregan (2005.64 JUAN BRAVO C. salir del pensamiento dicotómico. flujos tensados. riesgos. armonizar las economías de escala con otras opciones. nuevas reglas del juego. un sistema de gestión de iniciativas y muchas otras. p. Por otra parte. existe un amplio abanico de técnicas23 que pueden ayudar a generar soluciones. costo objetivo. costos. . 53): “Un sistema de gestión de ideas transforma el potencial creativo en acción creativa y despierta esa fuerza formidable que frecuentemente está dormida y desaprovechada en la empresa”. 23 24 Detalladas en el libro Gestión de Procesos. plazos. Recuérdese que cada una aborda aspectos fundamentales de los proyectos: incorporación del cliente y de los proveedores. just-in-time. son 28 en total. 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. En el libro Responsabilidad Social se profundiza en este tipo de análisis. comunicación.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 65 3. tal como se muestra en la figura 1-9. ingeniería conceptual o arquitectura de la solución. El Qué. Recuérdese la metáfora de una mesa: la cubierta es la estrategia y las 4 patas son: personas. Análisis Lo que da origen a esta etapa es el plan de proyecto aprobado. Debe estar bien sustentado en la estrategia de la organización. El modelo de negocios como una mesa . 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. estructura organizacional y tecnología. procesos. Es el inicio de la ejecución del proyecto. Estrategia Personas Procesos Tecnología Estructura Figura 1-9. El objetivo es plantear el modelo de negocios de la solución y los requerimientos correspondientes. El modelo de negocios es la visión integral de la solución y se apoya en un concepto o idea fuerza. Estas definiciones ya están avanzadas desde la etapa de factibilidad. También es llamada ingeniería básica. Desde aquí surgen las definiciones respecto al modelo de negocios de la solución.

forma de interacción. Puede ser que sólo un analista y un usuario conciban el modelo. lo que veremos a continuación respecto a los elementos del modelo de negocios. visión. es decir. decían ¿Se te apareció marzo? Cuando alguien estaba tranquilamente en un bote terminando sus vacaciones y se le aparecía una persona (marzo). Se requieren planes orientados al equipo de trabajo. 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). formación. empoderamiento. participación. información. forma de interacción y otros. como en la campaña para ofrecer créditos de un banco en Chile. anticipación. a) Estrategia Es la estrategia del proyecto. más bien general y destinado principalmente a cuantificar el volumen y tipo de trabajo. el cual fue vital en la etapa anterior para darle el pase al proyecto. incluso de los clientes si es necesario (por ejemplo. la transparencia en una solución arquitectónica o personificar con humor. participación. 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: sensibilización. en el análisis se profundiza hasta decidir los qué de la solución.66 JUAN BRAVO C. También puede ser que se requiera un equipo de trabajo de decenas de personas donde cada uno tiene la visión del todo. esta vez aplicadas al proyecto. A diferencia del trabajo en la etapa de factibilidad. También orientados a los usuarios de la solución. con algunos contenidos como estos: • Misión. Tal como la integralidad en el caso de la solución Vendedor Integral de grandes tiendas. ambiente de trabajo. El modelo de negocios es una totalidad que debe ser conocida por todos los integrantes del equipo de proyecto. ambiente de trabajo. por ejemplo: selección. capacitación. • Un concepto o idea fuerza que guíe la solución. imagen y demás definiciones que se presentan en el anexo 1. valores. El trabajo con las personas considera dos aspectos vitales: . Es importante destacar que la estrategia del proyecto debe estar sustentada y alineada con el plan estratégico formal de la compañía.

tradiciones. el mapa de procesos del ámbito venta al detalle se vería como en la figura 1-10. Las técnicas principales que se emplean son el mapa de procesos y el flujograma de información. más allá de los aspectos de estructura. Mapa de procesos . ya sean del negocio o de apoyo. para una empresa comercial. comunicación. Por ejemplo. creencias y mucho más. sonidos. Vender al detalle Vender Despachar Cuadrar Al Contado A Crédito Inmediato A domicilio Programar Entregar Figura 1-10. aromas. involucrados en el ámbito de trabajo del proyecto. • Los detalles del ambiente (lo que se ve): tal como colores. un zoom de una parte del mapa de procesos global (ver figura 1-4). c) Gestión de Procesos Se requiere la descripción del nuevo flujo de trabajo y de los procesos relacionados.MODELANDO UNA SOLUCIÓN DE SOFTWARE 67 • La cultura de la organización (lo que no se ve): formas de relación. y texturas. en directa relación con la estrategia (ver anexo 1).

para quienes debería ser autoexplicativo. Flujograma de Información (FI) Junto con el mapa de procesos se emplea la técnica flujogramas de información —la cual veremos con cierto detalle en el capítulo 3— para describir los procesos operativos de la organización. el cambio ha sido grande en esta materia). Vender al detalle y Servicio postventa. se abre a su vez en dos procesos. 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.68 JUAN BRAVO C. ya indicados. digamos desde el año 2000. Utilizaremos como ejemplo el proceso Despacho inmediato en el siguiente modelo. es conveniente una nueva inmersión. Inmediato. Más detalle en el libro Gestión de Procesos. 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). Una de los macroprocesos. Luego el macroproceso Vender al detalle se abre en otra cadena donde hay otros macroprocesos y procesos operativos y así sucesivamente. capítulo 11 (si usted sabía acerca de procesos pero no ha renovado su conocimiento. el flujograma de información. Un ejemplo se muestra en la figura 1-11. • No es un diagrama de flujo computacional. más tres macroprocesos: Comprar. principalmente a los usuarios operativos. 25 . • Tiene temporalidad • Está orientado a seres humanos. Despachar. Se aprecia en la figura 1-10 que el macroproceso Comercializar incluye un proceso operativo: Proyectar ventas. • 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. y otro macro: A domicilio. uno operativo.

OE: Orden de Entrega Figura 1-11.MODELANDO UNA SOLUCIÓN DE SOFTWARE 69 PROCESO VENDER A CRÉDITO CLIENTE ÁREA DE VENTAS VENDEDOR CAJERO BODEGA Vender Aprobar en SC CC Formalizar CC’ Emitir OE CC’ OE PROCESOS DESPACHAR SC: Sistema de Créditos. CC: Comprobante del Crédito. El mapa de procesos debería estar construido desde el principio y solamente se realizarían perfeccionamientos en cada vuelta de la espiral. . Válido para formularios manuales o computacionales. Se debe realizar el diseño de formularios asociados al detalle de los flujogramas de información. 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. Flujograma de información Si se está utilizando el desarrollo en espiral. el detalle a nivel de los flujogramas de información podría ser parte de cada iteración.

Los cambios van más allá de sólo crear o eliminar cargos (agregar. Kanban y SCM26. donde lo relevante es el esquema general de diseño de la interfaz. despacho. Un aspecto importante que debe quedar planteado en la etapa de análisis es el diseño general de la interfaz visual. contratos. 26 Supply Chain Management. movimiento automatizado de carga. telefonía interna y mucho más. los cuales pueden ser planteados mediante la técnica UML (la conoceremos en el capítulo 6). Debiera incluir precisiones de propuestas. 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. el que luego se aplicará a cada pantalla particular. Hemos acuñado el dicho: “un pterodáctilo no es una mariposa grande”. más o menos supervisión.70 JUAN BRAVO C. mover o sacar cajas del organigrama). JIT. Luego. construcción. trabajo en equipo. capacitación y en general. tal como se observa en el ejemplo de la figura 1-12. en el sentido que tienen una estructura muy diferente y apropiada a su tamaño. formas de implementación. del rubro y de otros factores. e) Tecnología En cuanto a la tecnología. su estructura depende del tamaño. alcanzan también a: planes y propuestas de externalización. d) Estructura organizacional Se refiere a la definición de la nueva estructura organizacional desde la mirada que aporta el modelamiento de los procesos. empoderamiento. 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. . se requieren planes para incorporar o adaptar tecnologías consideradas en el proyecto: comunicación. hasta la cadena que llega al cliente final. automatización de oficinas. entre otros. almacenamiento. delegación. en la medida que se requiera una aplicación computacional. se procede a la ingeniería de requerimientos tecnológicos. transporte. asimismo debe ocurrir con la organización.

Esto es necesario incluso en proyectos pequeños. conocimientos requeridos. El objetivo es obtener el detalle de la solución que propone el modelo de negocios. Diseño general de la interfaz 4. Diseño Entrada: el modelo de negocios con los requerimientos principales Entregable: el modelo de negocios con el detalle de requerimientos y la forma de implementar El diseño detallado consiste en dibujar planos. definir el espacio físico. procesos. dimensionar los recursos financieros. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 71 Figura 1-12. preparar modelos. especialmente personas. Es el Cómo. identificar los encargados. interacciones con el entorno. elaborar licitaciones y contratos. También se denomina Ingeniería de Detalle a esta etapa. estructura organizacional y tecnología. Diseño Lo que da origen a esta etapa es el modelo de negocios de la solución con los requerimientos principales.

Nótese que “se trabaja con” y no “se entrega o delega el trabajo a especialistas”. Se incorpora formalmente en esta etapa el aporte de los especialistas en la forma de trabajo conjunto con los analistas del proyecto. estructura organizacional y tecnología. además. Principalmente lo relacionado con personas. Más importante que una supercreación tecnológica. Un buen profesional no hace alarde de sus conocimientos y tiene la capacidad de explicar materias complejas con simplicidad. una vez que el especialista se retire. de estructura o de flujos de procesos. 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. • Conserve la visión de conjunto y asegúrese que los equipos de trabajo dedicados a diferentes partes de la solución estén plenamente coordinados. procesos. esencialmente 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 . Trabajo conjunto con los especialistas Durante esta etapa se trabaja con profesionales especialistas en cada ámbito de la solución. usted deberá seguir manteniendo la solución. porque se trata de un trabajo conjunto. las sofisticaciones o la especialización. Algunas sugerencias: • Trabaje en conjunto con el especialista hasta obtener el resultado deseado. En esta etapa normalmente se recurre a la asesoría especializada. • Evite la dependencia total y no se deje amedrentar por la erudición. es desarrollar armónicamente la solución. porque habrá mucha labor de perfeccionamiento sucesivo. probablemente empleando terminología más precisa.72 JUAN BRAVO C. porque hay que ir al detalle.

personas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 73 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. Implementación Esta etapa nace desde el diseño de la solución. . 5. procesos. • Se instala la aplicación de software. tal como se plantea en el capítulo 5 y mediante el uso de UML. Implementar significa “llevar a la realidad” el diseño. La participación de todos los interesados. plan de capacitación. así como el manejo del cambio son vitales en esta etapa. aunque en carácter piloto. estructura y tecnología). 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. tal vez en máquinas diferentes. Implementar también implica retroalimentar el diseño sobre aspectos no contemplados con anterioridad. formularios. Es necesario asegurar paso a paso que la solución cumple su objetivo. • Se implementan las nuevas definiciones de los procesos. flujos de información. una política acerca de las personas o el diseño de una estructura organizacional. El objetivo es llevar a la práctica (también construir o realizar) la solución detallada que propone el modelo de negocios. La flexibilidad es fundamental para efectuar los ajustes necesarios sobre el plan original. ya sean planos de un edificio. Se trata de “implementar” el diseño en una aplicación real. • Se aplica la nueva estructura organizacional. apoyo computacional. tal como se indica en el capítulo 6. armonizando todas sus partes (estrategia.

En particular. . intercambiando y buscando nuevas posibilidades creativas. espacios físicos que el analista sabía que tendría. Una forma de mitigar este problema es acortar el tiempo de ciclo de los proyectos. cambiaron las condiciones previstas en el diseño o la aplicación es difícil de usar. Es importante aclarar que negociar los compromisos no significa permisividad ni tolerar el incumplimiento de las tareas. ¿Cómo mitigar estos riesgos? La respuesta general es trabajar metodológicamente. • Capacitar por niveles en forma oportuna. En fin. Se corren riesgos importantes en esta etapa. escuchando. Otra forma es negociar con base en la nueva realidad. sucede que personas con que el analista contaba están destinadas a otras labores urgentes. ¿por qué negociar algo que ya está comprometido? Porque la experiencia indica que este es un factor crítico de éxito. • Comunicar el avance a todas las personas relacionadas con el cambio en los procesos.74 JUAN BRAVO C. Justo cuando es necesario llevar los planes a la práctica. Se requiere dimensionar el tiempo de cada integrante del equipo. Para este tipo de supuestos debieran existir planes de contingencia. Una forma de motivar la capacitación es fomentando el equilibrio de costos entre todos los factores de incidencia en un proyecto. por muchos motivos la implementación puede fracasar. ¿cómo? reiterando la actualidad de los objetivos que dieron origen a los compromisos asumidos. cuidando de no recargar a las personas. debido a que el proyecto no contemplaba gastar en capacitación. el tiempo de implementación es muy largo. Especial relevancia tienen en esta etapa las siguientes acciones: a) Negociar los compromisos Parece un contrasentido. asegurar la participación del usuario y mantener la continuidad entre el diseño y el uso de la aplicación. Hay empresas donde se han efectuado inversiones de cientos de miles de dólares en equipamiento que ha quedado abandonado. por ejemplo: el usuario ya no está comprometido con el sistema. Otras actividades de esta etapa son: • Completar la documentación. Supongamos además que todo ello está bien justificado. sino que se trata de la simple adaptación a las contingencias del mundo. puede ser a través del desarrollo en espiral. no los tiene o un equipo computacional prometido no llegó.

• Tener la flexibilidad para resolver con rapidez los inevitables problemas que se producirán. mejor). una de las prácticas transversales— con la precaución de no abusar de esa vía rápida porque el grueso del rediseño y del apoyo computacional tiene que seguir el método (el desarrollo en espiral es recomendado). es simplemente responder con variedad a la variedad natural del medio. considerando un período de prueba integral con datos reales y en la práctica. el equipo asesor en metodología. • Contar con la dedicación completa del líder28 y de los demás integrantes del equipo de trabajo. Por ejemplo. el equipo de trabajo de tecnología. c) Instalar el piloto Una actividad vital de esta etapa es comenzar a operar la solución en carácter piloto. los usuarios. • Mostrar resultados pronto para mantener el nivel de entusiasmo —por ejemplo. a través de los quick wins. la dirección de la empresa y proveedores especializados de elementos de comunicación o infraestructura. Es crítico en la relación con el usuario mantener 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. 27 28 El libro Análisis de Sistemas aborda el tema de la complejidad de los sistemas. entre otros actores. El autor tuvo el privilegio de asesorar en una conocida empresa minera en un proyecto de renovación tecnológica.MODELANDO UNA SOLUCIÓN DE SOFTWARE 75 b) Implementar los procesos y la tecnología Algunas recomendaciones para la implementación: • Mantener comunicación con todos los actores involucrados. especialmente en la atención a los usuarios (puede ser rotativa a diversas horas). es ideal tener una persona o un equipo “de acción rápida” 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. aquella difícil de predecir. • Aplicar la estrategia tenaza. cuidar el corto plazo (la solución preexistente) y el largo plazo (el nuevo proyecto) a la vez. buenos resultados se han logrado con una reunión semanal breve con los consultores que apoyan el rediseño. . 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.

Es importante la dedicación completa de estas personas al proyecto. 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. Taylor) se refiere a la formación en los procesos específicos en que trabaja la persona. W. 29 De acuerdo lo indicado en el libro Gestión de Procesos. Al mismo tiempo se avanza en: • Capacitación de usuarios piloto. El entrenamiento (el training de F. El objetivo es expandir la solución generada hasta ser bien utilizada por todos los usuarios previstos en el plan de proyecto. Despliegue La etapa de despliegue nace desde la implementación piloto de la solución. Desde el punto de vista de la TI. Esto implica que: • Los usuarios se capacitan. El prototipo es para que el usuario vea un boceto de lo que quiere o para probar aspectos específicos de la funcionalidad. lo que llevaría a modificar el proyecto. Despliegue Entrada: el piloto de la solución en buen funcionamiento Entregable: la solución completa en buen funcionamiento y el informe correspondiente Se trata de instalar la solución completa que propone el modelo de negocios en todos los puntos donde fue requerida. Y si lo nuevo no se usa. • Comunicación del avance. se hace una distinción entre capacitación y entrenamiento. luego se desecha (en el caso más usado del prototipo del tipo usar y botar). La capacitación se orienta al desarrollo de competencias generales. quienes luego pueden hacer de instructores para los demás usuarios. Una recomendación es asegurarse que efectivamente se usa lo nuevo.76 JUAN BRAVO C. la etapa contempla instalar el sistema en alguna 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. entrenan29 y reubican si corresponde (la sensibilización ya debería estar lograda). 6. . tal vez sea por razones fundamentadas.

b) Incorporar a cada usuario Aquí es necesario considerar al menos los siguientes elementos: • Instalar en forma personalizada en cada máquina. visitas en terreno y todo lo que se acostumbra en este caso. Se requiere una mesa de ayuda. al igual que los instructores. • Programas detallados de capacitación según tipo de usuarios. • Definir cuales elementos del sistema se instalan en el computador del usuario y cuales en el servidor. de software y de comunicación. • Disponibilidad de dispositivos de comunicación. • Una base de datos con las respuestas a preguntas típicas del despliegue. • Disponer de un mapa de instalación.MODELANDO UNA SOLUCIÓN DE SOFTWARE 77 • Los procesos rediseñados son implementados. con opciones de soporte telefónico. del sistema o ayudas en línea. Acerca de la capacitación: • Programas detallados de capacitación de usuarios piloto y monitores. . Intranet. • Disponibilidad de licencias del software . • Disponibilidad del software necesario. • El software se instala en las plataformas correspondientes. • Asegurar que los dispositivos de comunicación funcionan. para conocer configuraciones físicas. • La nueva estructura organizacional se pone en marcha. • Contar con la dedicación de los ejecutivos para facilitar el despliegue. • Disponibilidad de equipamiento computacional. 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. quizá el mismo usuario pueda ingresar y detallar su solicitud. • lograr la dedicación prevista de analistas. • Comunicación directa con los proveedores de tecnología. en todo sentido. Son tantas las facetas de la aplicación que se requiere toda su dedicación. Conviene enfatizar los aspectos de comunicación. También de cada atención a usuarios.

por ejemplo: • Revisar y actualizar el material (el cual debería estar preparado desde las etapas de diseño e implementación). Un desarrollo impecable puede fracasar porque el especialista en informática no sabe transmitir el uso del software. • Reuniones ampliadas de los gerentes dando la partida al proceso. • Desarrollar algún video explicativo cuando corresponda. . 7. Operación La etapa de operación nace cuando la solución generada está siendo bien utilizada por todos los usuarios previstos en el plan de proyecto. El buen funcionamiento de la solución debe lograrse en todo el modelo de negocios (estrategia. 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 tendencias en un sistema computacional. • Utilizar Internet. estructura y tecnología). la mejora continua opera en cada uno de sus elementos. 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. Por ejemplo. sobre todo si se trata de llegar a cientos o miles de usuarios. La mejora continua es una actividad central. Hay amplias experiencias positivas con el uso de esta técnica para la preparación de cajeros y de muchos otros tipos de usuarios operativos (mejora cuando se complementa con algún porcentaje presencial). a través de e-learning los usuarios se conectan libremente y existen niveles de evaluación. Por lo tanto. Para realizar el despliegue debemos recurrir a muchas instancias de comunicación rápida y efectiva. procesos. También “capacitar a los capacitadores” y cuidar los elementos pedagógicos. personas.78 JUAN BRAVO C. Requiere de la documentación generada en todas las etapas.

Es decir. 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. Ciclo PDCA (Plan Do Check Act) 12. . Estandarización interna y externa 6. Kanban (sistema visual) 8. Círculos de calidad 15. una visión práctica hay alcances adicionales bajo el título “Sistemas en Actividad”. Diagramas de Pareto (ver anexo 4) Además de una amplia gama de técnicas cercanas a la estadística. Flujograma de Información 5. 4. Las 5-S 13. mientras la solución está en desarrollo existe la infraestructura para abordar el cambio mayor y menor.MODELANDO UNA SOLUCIÓN DE SOFTWARE 79 Cuando la solución está en operación comienza la mejora continua. Las 3C 2. 31 Se presentan aquí solamente como una muestra de la profundidad de la mejora continua. El momento de la verdad 10. capítulo 15. la cual es compatible con el rediseño programado30. Tormenta de ideas 14. Seis Sigma 11. Mientras se trabaja en una vuelta del desarrollo en espiral (suponiendo que se emplea esa técnica). Efecto paraguas (el ejemplo personal) 7. 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. Benchmarking 3. 30 En el libro Desarrollo de sistemas de información. Compensadores de complejidad 9. Diagramas causa-efecto (ver anexo 4) 16. están detalladas en el libro Gestión de Procesos.

2. Control de cambios Se trata de establecer un procedimiento de aceptación de requerimientos menores en el ámbito de la TI. Un ejemplo de procedimiento se presenta en la figura 1-13 y a continuación como texto.80 JUAN BRAVO C. El jefe de informática la recibe y asigna a un analista 3. Flujograma de información de control de cambios Detalle del procedimiento de control de cambios menores: 1. PROCESO: EMITIR UNA SOLICITUD DE CAMBIO MENOR EN APLICACIONES COMPUTACIONALES USUARIO AUTORIZADO ÁREA DESARROLLO DEPARTAMENTO DE INFORMÁTICA JEFE INFORMÁTICA ANALISTA SUBCOMITÉ CAMBIOS SC Asignar Analista Estudiar impacto Casos de uso Emitir informe II Abreviaturas: SC: Solicitud de Cambio II: Informe de Impacto PD: Plan de Desarrollo Plan de Desarrollo II ’ PD ’ PD SC II’ PROCESO IMPLEMENTAR PD ’’ Figura 1-13. 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 . es indispensable seguir el procedimiento general del área de sistemas en cuanto a requerimientos menores. Ya sea obtención de nuevos informes o consultas. Un usuario autorizado emite una solicitud de cambio menor.

bibliotecas. Por lo menos contempla: • Participación del usuario en forma continua • Actualización de documentación • Búsqueda de programas. 6. escriben la experiencia relevante para efectos de retroalimentación y proponen perfeccionamientos al proceso. 4. el jefe de informática y el analista que realizó el estudio de impacto. desde análisis hasta despliegue. El subcomité de informática. documentación • Ordenamiento de manuales • Control de versiones de programas y de bases de datos • Análisis. de acuerdo con las indicaciones del subcomité de informática.MODELANDO UNA SOLUCIÓN DE SOFTWARE 81 • Entrega informe al subcomité de informática (encargado de los requerimientos menores). diseño e implementación • Pruebas • Reentrenamiento 8. aunque a una escala menor. incluyendo lo mismo indicado en las secciones anteriores del ciclo de desarrollo. incluyendo equipo de trabajo y costos. con la participación especial del usuario. 5. Se le envía la solicitud con las indicaciones al mismo analista que hizo el estudio. El jefe de informática aprueba. El analista presenta el plan de desarrollo detallado del requerimiento al jefe de informática. El área de desarrollo realiza el trabajo. toma alguna decisión de cambio. Todos los actores involucrados en el cambio se reúnen física o virtualmente. 7. .

comenzando por aquellas que indudablemente deben estar presentes en todas las etapas. 1. Definir una política por cada práctica Cuando hay una rutina de realizar proyectos y existe un proceso para el desarrollo de proyectos en la organización. El resultado no señala precedencia. 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. 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. es vital en ellas. Ese es un resultado concreto de aplicar las prácticas transversales. como una política. surgirán múltiples acciones a realizar que deberán incluirse en la carta Gantt. la revisión es más general. porque es lo que verdaderamente aplicará la organización Llevar a la Carta Gantt Fruto del análisis de cada práctica. la práctica “definir herramientas para la etapa” estará definida como estándares corporativos o. en este caso. al menos. . Muchas de estas acciones influyen en algunas o en todas las etapas del proyecto. en tal caso. porque cada una tiene su espacio y quizá aunque su uso sea acotado a pocas etapas. Este criterio de ordenamiento no pretende juzgar niveles de importancia de cada práctica. • La participación de todos es vital en el contenido de las políticas.5. la forma de trabajar con las prácticas transversales estará indicada en el método. • La política de cada práctica debe estar siempre actualizada. Estas prácticas se aplican en la fase de estudio y luego deben quedar incorporadas en el plan de proyecto.82 JUAN BRAVO C. Por ejemplo. Es un efecto sinérgico. A estas acciones que se repiten en diferentes etapas y que han demostrado su efectividad en los buenos proyectos les llamamos: prácticas transversales. PRÁCTICAS TRANSVERSALES La administración del proyecto considera una gran cantidad de acciones bien coordinadas que ayudan a lograr el todo. un proyecto exitoso.

• Tasa de descuento y plazo para evaluación de proyectos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 83 Por ejemplo. Veremos: 1. Comunicación 8. También en esta base de datos deberían incluirse estándares como estos: • Plazo máximo de proyectos. 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. • Valor hora promedio de los ejecutivos. Informes 9. Entrevistas 7. la recomendación del método es multiplicar sólo por 2 para efectos de obtener un costeo conservador. cuando incluir la inversión. por eso es necesario disponer de una base de datos de estándares numéricos. ¿Podría llegar a ser el 20% del presupuesto para los cambios? Puede ser. Dirección del proyecto 2. • Valor hora de los clientes (hemos usado US $ 4 promedio en experiencias de público masivo. por ejemplo. independiente de que el cambio se realice o no. Técnicas 10. El equipo de trabajo 6. En todo caso. de los profesionales. • Forma de un flujo de caja. 32 . depende de la organización. es unas 5 veces la renta líquida. para el tiempo de negociación de un cambio. en el control de cambios es necesario contemplar el tiempo de negociación del jefe del proyecto con el usuario. mando medio y personal operativo para efectos de cuantificar las propuestas. • Costos de movimientos internos y externos de mercaderías. tal como un hospital público). Herramientas de apoyo Cada uno de nosotros es contratado en la organización por el valor que agrega respecto a cumplir sus fines. Plan de la etapa 3. en particular el ahorro que se puede generar (recordar multiplicar por un factor también estándar respecto al valor que cada persona agrega32). por ejemplo. Exposición de los planes 4. conservadoramente. Este valor. Retroalimentación 5.

Gestión de riesgos 15. • Gestión de los riesgos. • Espíritu de equipo y el profesionalismo de su gente. Cuidar la solución anterior 23. Dirección del proyecto La dirección del proyecto es. Gestión de proveedores 1. realmente liderar el equipo de trabajo. Gestión de la calidad 16. eficacia. particularmente en calidad. plazos y costos. eficiencia. Inserción 18. Continuidad operacional 24. Quick Wins 13. Capacitación 21. Kill time 26. • Apoyo de la alta dirección. satisfacción del cliente. Orientación al cliente 19.84 JUAN BRAVO C. Control de cambios 27. La dirección del proyecto es una visión y acción de todas las actividades necesarias para cumplir con lo prometido. 11. comunicar. Algunos facilitadores del trabajo del líder en el proyecto: • Dedicación completa y visión clara de los objetivos del proyecto. tal vez. • Competencia en trabajo en equipo y liderazgo. Gestión del cambio 28. Trazabilidad 12. . Costos y duración 14. La dirección del proyecto también considera buscar formas para superar las expectativas y reconocer las mejores prácticas relacionadas. nivel de autonomía adecuado y facilidad para acceder a la toma de decisión fluida con relación al proyecto. por eso le hemos dedicado algunas líneas más que a las siguientes. Plan de recursos físicos del proyecto 25. Contempla motivar. la práctica más relevante para el éxito del mismo. Sensibilización 20. Seguimiento 22. Responsabilidad social 17. alinear intereses y sobre todo.

coaching. difíciles y arrogantes. una poética para el gerente del tercer milenio. y en el peor. empáticas y capaces de sintonizar con los demás. apreciados e inspirados. distantes. • Reencantar cada cierto tiempo a su equipo. Los peores. El éxito del equipo resulta de la “consonancia” • . 393): “Los mejores jefes son personas confiables. directivo. al menos en parte. Siendo el liderazgo lo más representativo de la dirección del proyecto. el gerente no quiere y tantas otras. en su libro Inteligencia social señala (2006. 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. resentidos”. que nos hacen sentir más tranquilos. se aclara a sí mismo y gana en retroalimentación. 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. El alto involucramiento vía team building es similar al modelo de orquesta sinfónica y sus características son: la existencia de un director o coach. El simple acto de fijar una meta desafiante pero alcanzable y de medir periódicamente el desempeño contra la meta establecida parece eficaz para motivar a los individuos. podemos citar a Daniel Goleman. en el mejor de los casos. del tipo: no se puede. • Cambiar las creencias limitantes en el equipo de trabajo. Reinhard Friedmann. compenetrarlos en la tarea y dirigir la realización de la obra (dar el tiempo y marcar el compás). doctor por la Universidad de Heildelberg. Un estimado amigo.). 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. De acuerdo a la etapa de desarrollo del equipo tendrá que elegir el estilo de conducción (participativo. p. cada miembro tiene una posición fija. p. quien. uno de los mejores expertos en relaciones humanas. Kendall y Kendall en su libro Análisis y Diseño de Sistemas explican (2005. integrando a todo el equipo de trabajo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 85 Comunicar el proyecto con frecuencia dentro y fuera de la empresa. etc. Éstas constituyen el material sonoro de la composición. involucrándolos en la fijación de metas. hacen que nos sintamos. Así perfecciona el mensaje. 66): “Los miembros de un equipo se pueden motivar. compara la labor del líder del proyecto con la de un director de orquesta. Las metas sirven como imanes para atraer a los individuos a la consecución de estas”. define (2007. cada miembro coordina su parte con el resto del equipo y exige una partitura que requiere mucho ensayo para su correcto funcionamiento”. pp. en su libro Arte y gestión. mal. consultor y autor de reconocidos libros.

es necesario revisar y detallar el plan de la misma (duración. los mejores improvisadores son profesionales que estudian mucho. encargado. por ejemplo. de los diversos elementos (sinergia). Un mensaje de fondo es que se puede aprender a improvisar. 2. porque luego sale a escena el Jazz. asegúrese que lo definido en la etapa anterior sigue siendo válido. Una recomendación. no situaciones que eran predecibles y que se encuentran tratadas en los métodos de gestión de proyectos. Aunque en estricto rigor es una improvisación educada. Cualquier desajuste (misfits) marca errores y pérdidas de eficiencia”. porque todavía no hay proyecto. Incluso. costo. donde. porque siempre aparecerán contingencias en los proyectos. vale decir: de su buena orquestación. especialmente si pasó mucho hasta la siguiente. Contingencias de verdad. a diferencia de la sinfonía. si se detectó algo no considerado o si hubo un cambio relevante en el entorno para el par problema-solución. Agrega que así pueden: “vivenciar en carne propia que la armonía de un equipo sólo se da cuando cada uno de los integrantes conserva su individualidad y. Y sus aportes no terminan aquí. . documentos de licitación que será necesario construir. Se hace una programación detallada de la etapa. La conclusión de los aportes de Reinhard es armonizar la preparación de la sinfonía con la improvisación del Jazz. 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. Plan de la etapa Una vez que está decidido realizar una etapa. a la vez. como en la concepción y factibilidad. de hecho. tal vez sea necesario replantear el plan general del resto del proyecto Son reestimaciones a la luz del avance. el plan de la etapa debe ser aprobado por autoridad. sabe coordinar y comunicarse armónicamente con el resto de los integrantes del equipo”. El plan de la etapa puede ser el único que existe.86 JUAN BRAVO C. Del director se exige la habilidad de escucha activa para detectar eventuales disonancias y corregirlas a tiempo. entre otros). con fechas precisas e incluso horarios en algunos casos. Por supuesto. lo que se privilegia es la improvisación. Es conveniente considerar que en cualquier etapa se puede cancelar el proyecto o volver a una etapa anterior.

. 5. 3) buena dicción. viste o entona. Retroalimentar es una práctica que debe incluirse tanto al término de cada etapa como al completar el proyecto. reflexionar. habla. sino. 5) manejo del tiempo. 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. 2) presentación personal.MODELANDO UNA SOLUCIÓN DE SOFTWARE 87 3. Retroalimentación Se trata de revisar el resultado logrado respecto a lo planeado para la etapa. 7) cumplir los tiempos. al interior y exterior del equipo de proyecto para ayudar en la coordinación del proyecto. aprender y seguir. lo más importante es la retroalimentación que se logra. Se comunican los resultados al resto del equipo y las conclusiones quedan disponibles para toda la organización. mueve. personales en cuanto a desarrollar un mensaje y técnicas en cuanto al uso de herramientas. Son competencias de comunicación. manteniendo un núcleo de participantes “permanentes” durante el proyecto. Para comenzar: hay que disfrutarlo. El espíritu de este punto es detenernos. El equipo de trabajo La práctica más habitual es formar un equipo de trabajo en cada etapa. Aquí tienen especial relevancia las competencias del equipo de trabajo para exponer a un grupo de personas en forma clara y precisa. la pasión y la energía al transmitir el mensaje. un proyector o un puntero láser. La exposición es uno mismo. 4. Al comienzo la atención está puesta en cómo uno se ve. es el efecto de la primera impresión. Exposición de los planes Exponer el plan de trabajo a todos los actores relevantes. tal como un software tipo PowerPoint. ¿cómo lo haríamos? ¿Qué cambios introduciríamos? También contempla preguntarnos si se están resolviendo las necesidades originales actualizadas. En el fondo. Es conveniente porque surgirán muchas sugerencias para lograr éxito en el proyecto. 4) lenguaje formal. gesticula. ¿para qué estamos ahí? Es indispensable la fuerza. Algunas recomendaciones: 1) preparación del tema. 6) llegar al menos media hora antes.

6. Al comenzar la etapa debe elaborar el plan de entrevistas. Una faceta del equipo de trabajo es que debe funcionar realmente como un equipo y aquí juega un rol fundamental el líder. se siente aislado y amenazado”. informática. La finalidad principal es levantar información útil al proyecto y se complementa con otras técnicas (encuestas. El usuario líder trabaja coordinadamente con el jefe del proyecto. Vital es la buena ejecución y el análisis posterior para incorporar las conclusiones al proyecto y cumplir los compromisos adquiridos. qué va a preguntar y qué es lo que a su juicio hará que esta entrevista tenga éxito. La participación de los ejecutivos es vital. Luego debe preparar cada entrevista. Kendall y Kendall agregan (2005. un clima de confianza con una actitud serena que surge de la puntualidad. Debe estar claro quién es el director del proyecto. 66): “Necesita pensar detalladamente en las entrevistas antes de hacerlas. p. Entrevistas Una práctica frecuente en los proyectos es la realización de entrevistas a usuarios. Durante la entrevista lo principal es crear ambiente. En las interacciones de baja calidad. Dice Goleman (2006. preparación y presentación (las tres P de las entrevistas). el subordinado siente la atención y la empatía de su líder. es decir. 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. Visualice por qué las va a hacer. En los intercambios de gran calidad. ejecutivos y personas de fuera de la organización. Asimismo. informes de consultoría o de auditoría). anticipando lo que se pueda utilizar. . Se trata de formar un equipo integrado por especialistas en rediseño de procesos. p. debe pensar cómo logrará que la entrevista sea satisfactoria para el individuo al que entreviste”. su apoyo y su actitud positiva. una mirada externa fresca—. Es necesario incorporar a clientes y proveedores en este equipo de trabajo. Lo más probable es que en cada etapa cambien integrantes del equipo de trabajo según sus competencias.88 JUAN BRAVO C. usuarios ejecutivos y consultores —se gana el “efecto consultor”. Normalmente se designa un usuario líder (representante de los demás usuarios) y usuarios clave de cada área a rediseñar.

Es necesario establecer un modelo de documentación de las aplicaciones. ortografía y capacidad de síntesis. evitando postergar. la variedad es tan amplia que la organización debe definir algunas. 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). sin embargo. 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 competencias mínimas en el equipo de trabajo (que es preferible no dar por adquiridas). es una actividad completamente transversal. . Se puede comunicar en el ámbito de problema o de la solución. la habilidad de leer. realizar la ingeniería de requerimientos con UML. Es conveniente comunicar mucho.MODELANDO UNA SOLUCIÓN DE SOFTWARE 89 7. 8. Por supuesto. debiera documentarse al mismo tiempo que se avanza en la etapa. Esta sola actividad implica disponer de horas de especialistas en comunicación. Comunicación Se trata de comunicar el proyecto al interior y exterior de la empresa. 9. Hoy ya sabemos que técnicas emplear en cada etapa de un proyecto. Técnicas Se trata de seleccionar las técnicas a emplear en cada etapa del proyecto. utilizar mapas de procesos globales o flujogramas de información con el curso normal de los eventos. con dedicación parcial o total según la envergadura del proyecto. Informes Cada etapa tiene uno o más entregables que deben quedar registrados en informes. por ejemplo: redacción. Incluye la formación de diferentes tipos de mesas de ayuda según la etapa del proyecto. Al menos. por ejemplo. para efectos del análisis.

donde se sigue la pista a la actualización de los datos. por ejemplo. Se pueden emplear diferentes herramientas de apoyo en cada etapa. fertilizantes y suelos. Rational o ERWIN. interfaz visual. Z4. incluyendo la generación de código cuando corresponda. modelo conceptual y cualquier otro modelo. Pueden ser ayudas en la construcción de un prototipo. M1. Corporate Modeler de Case Wise. Aris. 33 MS Project y Visio de Microsoft.90 JUAN BRAVO C. su actualización y la trazabilidad. 11. b) Trazabilidad del desarrollo. Una aspiración de las herramientas de apoyo es que actúen a nivel del ciclo completo. . existe una tendencia a unificar en una sola o en un pequeño conjunto de herramientas bien integradas. Corporate Modeler. M1 y Rational de IBM. por ejemplo. Se usan transacciones formales y presentes desde la creación de un dato. donde el cliente de un supermercado en Europa puede saber que el durazno que adquirió viene de Chile (importador. la ventaja es la facilidad para acceder a los modelos. quien lo gestó y por qué. Aris de SAP. como se ha movido el saldo de la cuenta corriente de un cliente. como fue diseñado. la evaluación que lo aprobó. exportador o puerto) y de un lote específico con detalle del packing. entre otras posibilidades. Trazabilidad Trazabilidad se entiende en dos sentidos: a) Trazabilidad de las transacciones. Herramientas de apoyo Se trata de seleccionar herramientas de apoyo a las técnicas que se usarán en cada etapa. 10. ERWIN Data Modeler de Computer Associates. Visio. Sin embargo. caso de uso. Lo importante es que la organización tenga una definición al respecto. de tipo33: MS Project. Es como la trazabilidad de la fruta. esa es hoy la realidad. el análisis que le dio forma. Z4 de Tuxpan. También llamadas CASE (desarrollo apoyado por computador). flujo de un proceso. donde se sigue la pista a cada requerimiento implementado. el control de costos y la evaluación financiera. También para cooperar en la planificación estratégica.

análisis y diseño. Se calculan costos cada vez más precisos del proyecto en tres etapas: factibilidad.. No es cambiar por cambiar sino que adaptar el avance del proyecto a la realidad de hoy (imposible de predecir en su totalidad cuando se elaboró el plan de proyecto). atrasos.. Es importante y valiente ver la realidad de lo que está sucediendo y reestimar si es necesario. el objetivo es terminar bien el proyecto. Lo opuesto es cerrar los ojos y tratar de cumplir un plan que tal vez no tiene sentido. entre otros. la negociación con la dirección y las exposiciones de avance. no se puede abusar de estas ganancias rápidas. en la concepción: ¿conviene abordar el problema? A veces el sentido común (y los amplios estudios de Maturana. La solución no termina ahí. 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 proyecto. Por ejemplo. . Echeverría. 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. Gestión de riesgos Se trata de detectar riesgos y elaborar un plan para mitigarlos y/o traspasarlos. verifique que los fondos para el proyecto existen. tecnología difícil de implementar. especialistas escasos. Son entregables de acción rápida. incumplimiento de proveedores. generalmente acciones simples que quedaron en evidencia desde las primeras conversaciones. Varela y otros) indica que el solo hecho de señalar un problema ya crea una expectativa. ¿Es el momento adecuado? ¿Y si no se llega a una conclusión? ¿Y si excede los plazos o costos? Cada etapa tiene sus propios riesgos que deben ser atendidos: una tecnología difícil de obtener. cambio de prioridades. renovándose la motivación y manteniendo la atención en el proyecto. 14. 13. las reuniones de coordinación. Costos y duración Se calculan costos y duración tanto de la etapa como del proyecto completo. Ah. costos excedidos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 91 12. Es necesario incluir costos ocultos tales como la misma planeación de la etapa. además. Por supuesto.

Todos cooperan con el cambio necesario y la empresa no despide por motivo de estos proyectos. 15. • Aplicar o definir estándares de gestión y determinar como se cumplen. También ofrece un límite a la inversión en el riesgo para mitigar o traspasar. lo mínimo es tener formas de detectar. 16. Gestión de la calidad Cada etapa del proyecto debe llevar el sello de la gestión de la calidad. Existe todo un aporte de la gestión de calidad aplicada a proyectos. Es necesario manejar bien el temor de las personas de que este tipo de proyecto las dejará sin empleo. No es justo ni necesario despedir sólo porque queremos hacer las cosas de otra forma. traducida como aseguramiento de la calidad. Establecer un pacto social o una alianza estratégica con los colaboradores es un excelente camino que han aplicado empresas exitosas.92 JUAN BRAVO C. Se puede evitar generando vinculaciones con otros proyectos en un esquema de vasos comunicantes porque hay infinitas iniciativas que se pueden 34 35 En el libro Gestión de Procesos hay un análisis de la gestión de riesgos. Quality Assurance. transferir y/o neutralizar. aseguramiento y control de calidad. al menos en: • Planeación. con una planificación. para verificar el proceso de producción y validar los entregables de cada etapa. 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. Se han identificado más de cien riesgos asociados a los proyectos. La magnitud del riesgo (R) se obtiene multiplicando el costo si ocurre (C) por la probabilidad de ocurrencia (P). . Una fórmula para priorizar riesgos34 es: R = C x P. control y seguimiento. usuarios que no desean el nuevo proceso. Responsabilidad social Veremos algunos elementos de la Responsabilidad Social (RS) aplicada a proyectos. apego irrestricto al plan o simple agotamiento.

empresa o industria— para comprender y alinear los intereses. tanto de los profesionales internos como de contratistas. no basta con un buen promedio general. 18. quien paga a todos en la organización. La RS alcanza a todas las interacciones internas y con el medio: integrantes. evitando discriminar entre ellos. 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 recursos. alinear intereses. Ya indicamos que por cliente hablamos del cliente externo. Cada interacción debe ser aprobada. Inserción El problema y la solución deben insertarse en un todo mayor —área. Es vital escuchar y apreciar lo que es realmente importante para el cliente. Se debe monitorear la contribución actualizada de la finalidad del proyecto a la estrategia de la organización. Por supuesto. clientes. hacernos responsables. en lugar de nuestra habitual tendencia a la autorreferencia. cuando creemos saber lo que el otro quiere. que debe dar positivo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 93 desarrollar. trabajar con eficiencia. es cuestión de unir una cosa con otra. el medio ambiente y la naturaleza del negocio. . 17. otra aplicación de visión sistémica. en capitalizar toda la creatividad de las personas. una parte libera recursos y la otra requiere recursos. cuidar el entorno y la comunidad. proveedores. organizar el trabajo seguro y el buen trato. comunidad. prevenir en todo los riesgos y calcular el VA (Valor Actual) social. optimizar adquisiciones y manejar el aspecto político en cuanto al mejor momento de plantear el cambio. Orientación al cliente Ya sea en el problema o la solución. Se requiere mantener al menos el nivel de servicio previo al inicio del proyecto mientras este dure. generalmente nos equivocamos. Destaquemos dos en especial. En esto el método GSP puede apoyar especialmente con el énfasis en la gestión de las ideas. la orientación al cliente es central para lograr la conclusión exitosa del proyecto. gobierno y muchas otras. evitar la improvisación. el cual debe ser de útil a la sociedad. alinear intereses. que refleja el efecto del proyecto en el medio.

satisfacción de usuarios. relator. es una excelente oportunidad para lograr acuerdos en los múltiples detalles de la necesidad y del proyecto. lo que ya sabemos de armonizar las variadas dimensiones del ser humano: espiritual. objetivos. por usuarios que actúan como monitores. etc. La capacitación de los usuarios es vital en el proyecto. Internet. es diferente según tipos de usuarios y puede tomar variadas formas (la recomendación es una combinación de posibilidades): • Puede ser realizada por relatores profesionales. plazos. • Puede comenzar en etapas tempranas del proyecto. participación.. 19. hitos. Capacitación La capacitación del equipo de proyecto debiera ser continua durante todo el proyecto. etc. intelectual. lápices. videos. El diseño de la actividad es muy importante: lugar. etc… • Puede emplear variados medios creativas: Intranet. En especial. 21. . extensión y muchos otros aspectos deben estar bien pensados. aunque se complementa con esas prácticas. aunque sí bien realizada. emocional y corporal.) 20. Es diferente a comunicar y capacitar. teleconferencia. Seguimiento Realizar seguimiento es llevar control del avance del proyecto completo y en cada etapa. Además. Sensibilización Es el manejo del cambio en relación a la emoción. calidad) Desde este punto de vista tiene relación con el diseño de indicadores. por sicólogos preparados en los mensajes del proyecto. Se monitorean variables críticas del proyecto (costos. duración. Por supuesto. El objetivo es encantar a los “afectados”. por el equipo de proyecto. Se aplica mediante anticipación. talleres —ver práctica Quick Wins—y otras formas creativas (poleras. se programa en detalle en cada etapa. No tiene que ser extensa..94 JUAN BRAVO C. e-learning. por ejecutivos. clases presenciales. La idea es aplicar lo aprendido acerca de encantar a todas las personas de dentro y fuera de la organización que tienen relación con el proyecto. con preparación en pedagogía de quienes van a capacitar.

Continuidad operacional Se refiere a incorporar en el proyecto los mecanismos que permitan la continuidad de las operaciones cuando el proyecto esté en funcionamiento. • Asegurar a los clientes la protección de sus intereses y mantener la buena imagen de la empresa. • Agilizar la restauración de los servicios y reiniciar operaciones críticas en un tiempo breve. La continuidad operacional está relacionada con la seguridad de las operaciones y la calidad de la información. escritorios. 23. Plan de recursos físicos del proyecto El plan de recursos físicos se refiere a disponer oportunamente de los elementos que se requerirán en el proyecto: equipos computacionales.MODELANDO UNA SOLUCIÓN DE SOFTWARE 95 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. . Objetivos del plan de continuidad operacional: • Crear conciencia en el equipo de trabajo y en los usuarios acerca de la prevención y de las implicancias de una contingencia en la continuidad de los productos y servicios. Un trabajo bien hecho en materia de recursos físicos tendrá su nivel de influencia en la moral del equipo de trabajo y en los plazos. La idea de fondo es evitar la contingencia. espacio físico. baños. 22. • Minimizar interrupciones a las operaciones del negocio y limitar la severidad de la interrupción. redes. se aplica alguna forma de continuidad de lo existente. más allá de sólo tener planes de contingencia. Cuidar la solución anterior Cuidar la solución anterior significa que al mismo tiempo que se trabaja en la nueva solución. En algunas experiencias incluso se designa un gerente de continuidad. comedores y otros. prevenir. • Minimizar pérdidas financieras. licencias. al mismo tiempo que otro gerente se encarga del proyecto de cambio. Incluso se sigue realizando mejora continua de la antigua solución. 24.

porque si el proyecto gasta mucho más del presupuesto o su duración es excesiva. Gestión del cambio Esta práctica se refiere a la gestión del cambio en las personas. lo más probable es que el costo llegue a ser prohibitivo para la organización o que nunca termine. Taylor en su administración científica. se define que el proyecto se cancelará si se consume el presupuesto completo más un 20% o si la duración excederá en un 25% al tiempo asignado. 25. Es decir. bajo qué condiciones conviene cancelar el proyecto.4 se presentó un proceso de control de cambios. 26. Está hacia el final porque varios de los elementos de la buena gestión del cambio están contemplados en las prácticas anteriores. tal como dirección del proyecto. Kill time Un Kill time se define como “momento de cancelación del proyecto”. Por ejemplo. Asumir a tiempo la pérdida acota el efecto a un nivel soportable por la organización. tipo Coaching diríamos hoy— distinto a la capacitación masiva. Durante la operación se refiere a un procedimiento para cambios menores que incluso puede enlazar con la mejora continua de la solución36. Control de cambios El control de cambios tiene dos interpretaciones: durante el desarrollo y durante la operación. Durante el desarrollo del proyecto son cambios en las especificaciones. W. 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. Esperar puede poner en riesgo su existencia. sensibilización. Vital es incorporar en forma personalizada a todos los actores relevantes —tal como señala F. Es sabio.96 JUAN BRAVO C. 36 En la etapa de operación descrita en la sección 1. exposiciones. entrevistas y responsabilidad social. . capacitación. lo cual queda definido en el plan de proyecto y se revisa al inicio de cada etapa. 27. 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. en el contexto de que no hay un cambio importante en las reglas del juego de una inversión.

. por ejemplo. 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 volverá contra la misma empresa. donde se maximiza el interés de la empresa y de los proveedores. erróneamente. incluso aportando ideas y siendo parte de la solución. Su propia predisposición al cambio ayudará en la moral de los usuarios.MODELANDO UNA SOLUCIÓN DE SOFTWARE 97 La coherencia del equipo interno es vital. Es indispensable una buena gestión con ellos para el éxito del proyecto. condiciones igualitarias para trabajadores propios y de contratistas y requerimientos precisos. Gestión de proveedores Cada vez es más frecuente que en los proyectos participen personas y empresas externas a la organización. Se trata de lograr la mayor armonía en los intereses buscando aplicarse todos con el mayor entusiasmo y creatividad al éxito del proyecto. Una verdadera gestión de proveedores va por el oro. 28. A veces se malentiende la gestión de proveedores y de subcontratistas. mucho más allá de pagos justos y oportunos o buenas condiciones laborales. como se enseña en los buenos cursos de negociación. claridad de los objetivos de su trabajo.

98 JUAN BRAVO C. CAPÍTULO 2. INGENIERÍA DE SOFTWARE .

Es necesario que el analista conozca acerca de la ingeniería de software para que inserte su aporte en el contexto de esta disciplina. TEORÍA DE MODELOS CAPÍTULO 2. No se refiere a la producción en serie. tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). Roger S. Es una competencia de tipo vertical. técnicas y herramientas conocidas. INGENIERÍA DE SOFTWARE CAPÍTULO 1. Durante los últimos 20 años. MODELAMIENTO DE DATOS CAPÍTULO 3. donde se aumente la calidad y la productividad y se disminuyan los riesgos del proyecto mediante una excelente planificación y modelamiento. el desarrollo de software. HERRAMIENTAS TI CAPÍTULO 6. sino a la obtención de un producto creativo y personalizado. hacia productos de programación normalizados. ellos mismos no han aplicado estas técnicas. muchos ingenieros de software han sido “los hijos del zapatero”. ORIENTACIÓN A OBJETOS CAPÍTULO 4. Aunque estos profesionales han construido sistemas complejos que automatizan el trabajo de otros. UML CAPÍTULO 5. Pressman El objetivo más importante de la ingeniería de software es lograr la producción profesional de software. 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. porque se profundiza en una especialización. CAPÍTULO 7. con documentación . MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales Se trata de avanzar desde aplicaciones computacionales que son “obras de arte únicas”.MODELANDO UNA SOLUCIÓN DE SOFTWARE 99 Capítulo 2. Esta es la segunda competencia considerada para apoyar la elaboración de modelos de una solución de software. desarrollado con método.

La ingeniería de software incluye la producción de otros productos de software. Hay que desmitificar la producción de software. Usuarios calificados son profesionales y ejecutivos que poseen entrenamiento formal en tecnología de la información. es hacia la producción de software que apoye directamente los procesos de la organización teniendo siempre al cliente como norte (al cliente final. fáciles de construir y de mantener. con una finalidad revolucionaria: permitir que los usuarios calificados puedan participar activamente en todo el ciclo de desarrollo. 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 .100 JUAN BRAVO C. transformándola en una actividad mucho más amistosa. Éstos siguen patrones parecidos a la producción de software administrativo e incluyen algunos aspectos más especializados. automatizada. como sistemas operativos. a través de la aplicación de técnicas simples y herramientas poderosas. sobre herramientas de la tecnología de información. el que paga). herramientas de productividad o de automatización de oficinas. No hay una contradicción entre obtener productos creativos trabajando metodológicamente. como el énfasis 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. quienes conocen su problema y saben como estructurarlo. para lograr aumentos de productividad de los desarrolladores de software. La orientación del capítulo y de todo el libro.

cambios en productos y mercados o desmantelamiento de estructuras especializadas. trataremos sobre la necesaria educación y discutiremos sobre la real necesidad de construir software con el objetivo de asegurarnos de trabajar en proyectos plenamente justificados. Consideramos que cumplir plazos y costos está incluido en “alta calidad”. amistosos y rápidos en la ejecución. 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. de alta calidad. ¿Desarrollar un buen software o solucionar el problema? 3. trabajo de equipo. Veremos: 1. económicos (costo / beneficio positivo). Esfuerzo de educación 4. Definiciones de la ingeniería de software 2. redefinición de procedimientos. p. económicamente. Fritz Bauer: “El establecimiento y uso de sólidos principios de ingeniería. En las siguientes secciones precisaremos la definición de ingeniería de software. que son desarrollados y modificados a tiempo y dentro de un presupuesto definido”. es decir. por ejemplo: externalización. 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 producción sistemática de productos de programación. rediseño organizacional.MODELANDO UNA SOLUCIÓN DE SOFTWARE 101 2. software que sea fiable y funcione eficientemente sobre máquinas reales”. a través de proponer métodos completos que permitan obtener buenos productos de software. automatización de oficinas. 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. 6): “La ingeniería del software 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 sistema hasta el mantenimiento de éste después de que se utiliza”. Tecnología de información 1. Es lo que plantea Ian Sommerville (2005. .1. orientados a obtener.

– Realmente hacer ingeniería y buscar otras alternativas de solución al problema. Consideremos la productividad del desarrollo. • Contratar desarrollo externo. Pressman: “La ingeniería del software surge. ¿Desarrollar un buen software o solucionar el problema? La ingeniería de software nació como respuesta a variadas necesidades relacionadas con el desarrollo de software: fiabilidad. Comentarios de Roger S. 2. lo cual es consistente con estudios que señalan que hasta la mitad del software construido en Chile nunca debería haberse hecho. de la ingeniería de sistemas y del hardware. sobrepasándola. Por ejemplo. externalización. porque existían otras soluciones mejores que ni siquiera fueron exploradas. bajo una filosofía predominante de coordinación.102 JUAN BRAVO C. Todo. por nombrar algunas. se puede explorar: • Hacer ingeniería y buscar alternativas de solución no computacionales al problema. • Adquirir software de uso generalizado. control. Veamos estos puntos con mayor detalle: 1. hay instalaciones donde se incrementó la productividad del desarrollo y aún así los usuarios no están satisfechos. Se espera que el incremento en la productividad permita satisfacer las demandas pendientes. Sin embargo. tal como vimos en el capítulo primero. La situación es que se requieren nuevas aplicaciones que los especialistas no alcanzan a construir. ¿No será que comenzamos por el lugar equivocado? ¿Será necesario desarrollar la aplicación? Es que el interés del usuario es solucionar su problema. herramientas y procedimientos. . eficacia. aplicar just in time. normalización y productividad. lo cual no implica necesariamente el desarrollo de una solución de software. Con esto es posible resolver tal vez el 50% de los casos. 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 productiva. control y gestión”. • Preparar a los usuarios para que ellos mismos resuelvan parte de sus necesidades. ampliar o reducir mercados. Abarca tres elementos clave: métodos. 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 productos con dificultades de ventas que se pensaba controlar más en detalle con un sistema computacional. Por ejemplo. no computacionales.

Si requiere efectuar cálculos y presentar gráficos. Resulta evidente que esta opción se aplica cuando el tamaño y complejidad del requerimiento lo permiten. Significa que todas o algunas etapas se pueden contratar externamente. Tiene mucha relación con el esfuerzo de educación. Esta opción y otras creativas resuelven la última tajada de los requerimientos originales (el otro 12. puede ocupar Microsoft Access o alguno de los módulos de consulta que proveen los sistemas administradores de bases de datos. las planillas electrónicas le ayudarán a resolver su problema. En el mercado existe una amplia gama de excelentes soluciones para todo tipo de plataformas. Cualquiera de estas opciones soluciona el problema del usuario sin recurrir al desarrollo interno. Si requiere interactuar con grandes bases de datos para extraer información. tales como: contabilidad. estudiar si la aplicación existe en el mercado para adquirirla a una empresa especializada. la cual es una opción que debiera quedar abierta sólo para casos excepcionales. remuneraciones. . comenzando por los productos ERP (que veremos en el capítulo siete). inventarios. Tal como se aprecia en la evolución de la construcción de software. Por ejemplo.5% de los casos). activo fijo y facturación. Esto resuelve una parte de las situaciones que no pudieron ser resueltas con software normalizado (digamos el 12.– Si no hay software de tipo generalizado y el usuario no lo puede resolver. más que construir ellos mismos. es posible recurrir al desarrollo externo. realizar internamente el análisis y el diseño y contratar la construcción del sistema.– Si el camino es de índole computacional. el equipo interno principalmente coordina y hace gestión de calidad. El costo de este software genérico es equivalente a una pequeña fracción del costo del desarrollo. 4. lo puede hacer hasta con un procesador de texto.MODELANDO UNA SOLUCIÓN DE SOFTWARE 103 2. Con capacitación y herramientas apropiadas puede resolver su requerimiento en menos tiempo del que le hubiera tomado explicárselo a un especialista.5% de los casos).– Estudiar la posibilidad que sea el mismo usuario quien resuelva su problema. Si se trata de la creación de bases de datos simples. 3. Es posible que esto dé respuesta a la mitad de los requerimientos computacionales (25% de los casos). Hoy es una locura desarrollar aplicaciones típicas.

comenzando por los ejecutivos de mayor nivel. se pueden extraer algunos temas de la clasificación de materias presentada en la figura 2-1. . menos prejuicios. ella está indudablemente supeditada a los mayores intereses de la educación.104 JUAN BRAVO C. la cual es solamente un ejemplo del tipo de materias en cada categoría. ganador del premio Deming a la calidad. Para diseñar el programa de enseñanza. se incrementa la capacidad individual. 3. un “aprender a pensar” y luego cambiar la forma de pensar. Este tema es de tal trascendencia que. refiriéndose al control total de calidad. 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. Utilizamos la palabra educación porque ella es consecuencia del proceso de aprendizaje y reflejo de ser una persona culta. 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. 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áticamente en técnicas y herramientas uniformes para el desarrollo de sistemas. uno de los cuales es la tecnología de información. dar mejores respuestas a los desafíos del medio y atreverse a hacer cambios. Otra faceta es el Training (traducido como entrenamiento) destinado a formar a las personas en los procesos específicos en que participa. Este es un principio sistémico. ¿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 personas. debiera destinar una cantidad equivalente de horas a los temas de su entorno. La educación implica una mentalidad abierta. Kaoru Ishikawa. el Dr. es indispensable hacerlo si queremos producir software efectivo y de calidad. Si un ejecutivo destina a su labor especializada varios miles de horas de perfeccionamiento. mejora el funcionamiento de equipos de trabajo y se refuerza la motivación. el equilibrio entre especialización y generalización. dice: “la calidad comienza con educación y termina con educación”. Sin embargo. Siendo la actividad de capacitación de fundamental importancia en la empresa. Se refiere a una conducta “educada” y no a una acumulación de títulos. Adicionalmente. Está relacionada con una sistematización del conocimiento.

los ejecutivos y profesionales podrán apreciar su organización desde un punto de vista más amplio. computacionales o no. 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. organización y administración Ambiente de Calidad 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 Tecnología De Información 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 Figura 2-1. Parte de este esfuerzo de educación es conocer en profundidad los alcances de la tecnología de información y sus implicancias. con las materias propias del área informática. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 105 La empresa en la comunidad Planificación estratégica Adaptación al cambio Liderazgo. orientado a los eslabones más altos del manejo de información y la tecnología de información. 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. De esta manera.

arte organizado. tecnología sería un cuerpo de conocimientos organizado que consta de métodos y herramientas en rápido progreso. sustento de las nuevas definiciones de inteligencia. con redes internacionales de especialistas que comparten su saber. ella proviene de la raíz latina techne = arte y logy = organización. traspasable. susceptible de ser compartido. la observación y la experiencia. Podríamos agregar que los datos se encuentran hoy en computadores que los procesan para obtener. es decir. esa información que a su vez es la base del conocimiento. observación y experiencia. directamente relacionado con el aumento de la calidad de vida. Esto ha sido en gran medida lo que originó la revolución industrial y ahora la revolución del conocimiento. La formación de un conocimiento objetivo. ese procesamiento involucra muchos recursos de hardware. Sabemos cómo hacerlo.106 JUAN BRAVO C. 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. es lo que produce tecnología. la adaptación al cambio. Es el entendimiento el que nos lleva al desarrollo. aquélla que nos hace cambiar y pensar por nosotros mismos. Tal vez resulte más conveniente no extraer aquel petróleo desde el fondo del lago. el entendimiento es hijo de la reflexión y de la verdadera educación. ¿Qué es la tecnología de información? La palabra tecnología ya nos dice mucho. Es un tipo de conocimiento medible. Aunque no basta con el conocimiento. hay cientos de libros que la tratan desde todo punto de vista. en contraposición al simple chispazo de la techne. estudiado y completado. en resumen. Si el conocimiento es fruto de la información. actualizado y perfeccionado. está entrando en el colegio y en el hogar. a partir de la información. Tecnología de información La Tecnología de Información (TI) está revolucionando nuestra sociedad más rápidamente que cualquier otra disciplina. 37 . Sobre la información. Esta visión de sistema social es la base de una habilidad fundamental en nuestros días. nos ayudará también a nosotros. pero decidimos no hacerlo. Por supuesto. gota a gota. personas altamente capacitadas. de rápida formación. software y sobre todo. también es indispensable el entendimiento37. penetró profundamente en la empresa moderna. 4. porque el costo de la contaminación y de la pérdida de agua potable sean mayores que el eventual beneficio. esto es comprender que cualquier problema que alguien tenga. La nueva visión de la organización es la de un sistema social caracterizado por la interdependencia. nos afectará a nosotros de una u otra forma. Y lo que a él le beneficie.

pero sólo con educación sabremos dónde.MODELANDO UNA SOLUCIÓN DE SOFTWARE 107 Es que la implementación de cualquier tecnología debe armonizar conocimiento y entendimiento. Con capacitación podemos conocerla. cuándo y por qué aplicarla. La tecnología de información avanza velozmente y cambia su contenido en períodos cada vez más breves. . Esto es profesionalismo. no cabe duda. en la dirección del desarrollo social y del incremento en la calidad de vida.

debe estar de acuerdo con el plan estratégico global. Por supuesto. La nueva tecnología informática ofrece más rapidez. imposiciones de centros de poder con intereses contrarios a los de la organización. hubiera sido preferible no construirlos. Incluso. ¿Cuál es la causa? Hay varias: construcción apresurada. este aspecto estratégico debería estar contemplado en el método que la organización adopte. Veremos: 1. es más.108 JUAN BRAVO C. no es caro probar opciones. Si este no existe. es más amistosa y generalmente la relación costo–beneficio es claramente conveniente. el contenido de esta sección es profundizar en la parte del método referida a la estrategia. fue construido en forma apresurada en algunos retiros de fin de semana o se encuentra desactualizado. muchas veces resulta más económica una equivocación que esperar. estaríamos en presencia de problemas mayores cuya solución comenzará cuando se cuente con el plan estratégico de la organización. Por lo tanto. Las empresas que hacen cambios en forma sistemática logran mejores resultados. Para efectos de ofrecer luces respecto a lo que debe incluir el plan estratégico es que se incluyeron los dos primeros anexos. Es que resulta vital desarrollar una visión estratégica. porque el costo para la organización resultó ser más alto que mantener el problema original. se considera especialmente relevante la carencia de una visión estratégica. falta de perfeccionamiento de los colaboradores. por ello es que se incluye este capítulo y los anexos 1 y 2. de tecnología o cualquier otro tipo. La opción más cara es mantener los esquemas tradicionales.2. etc… Entre las causas. Por otra parte. sesgo informático. 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. tal como vimos en el capítulo 1. PLANIFICACIÓN EN INFORMÁTICA Una realidad a simple vista es que muchos sistemas computacionales no respondieron de acuerdo con las expectativas. Desde este punto de vista. todo proyecto de la organización. Cabe agregar que el plan informático debería ser parte de ese plan global. Algunas directrices sobre la tecnología de información 2. respectivamente. 2. acerca de estrategia y alinear intereses. Reconversión de la informática . desarrollo informal.

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. si de alguna forma se tiene “institucionalizado” probar alternativas para seleccionar aquélla que mejor les parece. Estas decisiones estratégicas deben ser tomadas en reuniones conjuntas de la alta gerencia con sus especialistas y preferentemente con apoyo externo no comprometido con alguna opción en particular. se obtiene un subproducto de gran proyección: la adaptación al cambio38. Método de planificación estratégica en informática 5. Cambio cultural de la organización 6. Así. Resumen de la planificación estratégica en informática 1. 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 desintegración de la industria. Si en la empresa se ha vencido el temor a ensayar opciones. flexibilidad y disposición al cambio. 30 de julio de 1995) algunas de las causas del éxito de Acer. Esta clase de estructura maneja mejor los cambios y en esta industria el cambio es constante. toque local”. Ahora hablamos de mentalidad. 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. La idea es ensamblar el PC en el punto de ventas y fabricar las piezas en otra parte.MODELANDO UNA SOLUCIÓN DE SOFTWARE 109 3. 38 Stan Shih. hacia un conjunto de directrices cuya implementación significa tomar decisiones estratégicas que están más allá del ámbito informático. emprendieron el proceso de la reingeniería de acuerdo con tres grandes estrategias: El modelo de “comida rápida”. La estructura organizativa de “cliente–servidor”. tenemos que buscar el retorno y cómo podemos construir competitividad… innovación no sólo en el producto. fundador y presidente de Acer. expone (El Mercurio. en un viaje a Chile realizado para sostener conversaciones con la subsidiara local. La idea de “marca global. Nuevas formas de organización informática 4. algunos productos de software y un método de desarrollo. . Para adaptarse. en Chile se ve qué clase de productos gustan y a esos se les da prioridad… Queremos tener socios en cada país a través de sociedades anónimas abiertas. entonces la resistencia al cambio es muy baja. 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. Como consecuencia. por ejemplo. también en la administración. Dice: los gerentes son también inversionistas… hacemos mucha capacitación… las unidades toman sus propias decisiones… no buscamos tamaño. La tendencia de la tecnología de información se estaría orientando hoy.

• Orientación a objetos. Es creciente la velocidad de introducción de las técnicas de orientación a objetos. Incluso. ventanas. • Participación creciente del usuario ejecutivo en la formulación de modelos corporativos. • Búsqueda de código reutilizable. . ayudas en línea. • Software cada vez más amistoso con uso intensivo de “factores humanos”: simplicidad. Lo cual es hoy una realidad con múltiples herramientas disponibles en el mercado. • Desarrollo y procesamiento descentralizado. • Fuerte énfasis en perfeccionamiento y educación. cada unidad de negocios administrará su propio presupuesto de informática. Algunas de las nuevas directrices son: • Áreas de sistemas orientadas al cliente (el cliente de la organización. al menos en la gestión de su propia demanda de requerimientos. • Apoyarse en herramientas de productividad en todo el ciclo de desarrollo. pero todavía falta un mercado de código reutilizable). • Alineamiento cada vez mejor entre la tecnología de la información y las necesidades estratégicas de la organización. • Utilización creciente de prototipos para ensayar interfaces visuales (pantallas e informes) y funcionalidad (ingreso de datos o selección). Implica que los profesionales de informática conocen y aplican la estrategia de la organización. dejando de lado la producción artesanal del software. procedimientos y herramientas que la organización se haya dado. En particular. el que paga) filtrando cada requerimiento en función de si le agrega valor o no a éste. 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. con alta eficacia y eficiencia en la obtención de resultados. este aspecto es una ventaja competitiva a nivel profesional. que representen la realidad de la empresa. También en resolver sus propias necesidades simples: informes y consultas de toda índole. La idea es automatizar sobre la base de métodos formales. • Generación automática de código. UML y otros estándares en lugar de diseño estructurado. íconos o idioma nativo del usuario. Promesa que con la orientación a objetos está comenzando a ser cumplida (es ya una realidad al interior de algunas organizaciones.110 JUAN BRAVO C. • Incorporación del usuario (o cliente interno) al proceso de desarrollo de sistemas.

sólo comparables a las enormes reconversiones que significaron . Una variable a tomar en cuenta por desarrolladores y ejecutivos del área informática. La idea es vivir la experiencia. se puede “pasear” virtualmente dentro de la casa que uno quiere comprar. Los segundos debieran ser cuidadosos en que los costos del proyecto no se disparen. • Importantes avances en la tecnología de tratamiento de imágenes. Intranet y Extranet. es que las rentas de especialistas bien preparados en cualquiera de esos temas son mayores al promedio. sino que por el grado de satisfacción del usuario. tacto. Visual Basic. Uno mismo puede establecer como desea que sean sus aplicaciones. Powerbuilder. • Uso intensivo de Internet. • Integración total. • Fuerte demanda de especialistas preparados en métodos y herramientas modernas: Gupta. etc. 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). métodos y esquemas organizacionales. imagen. Hoy. movimiento. existen experiencias exitosas en importantes organizaciones.). Reconversión de la informática La tecnología de información. están provocando profundos cambios en el perfil de los especialistas en computación. software. También redes neuronales e interconexión con clientes y proveedores. Por ejemplo. ya se habla en Terabytes (TB) para los dispositivos de almacenamiento y en Gigabytes (GB) para las memorias. • Fuerte expansión de la multimedia (sonido. • Mayor calidad y cantidad de aplicaciones. lo que a su vez significará la adquisición de más hardware y software. Informix y muchas otras. 2.MODELANDO UNA SOLUCIÓN DE SOFTWARE 111 • Estrategia de la organización e informática permanentemente reformulada. Ingres. junto con la masiva incorporación del usuario. De hecho. las revoluciones del hardware. Progress. • Nuevos criterios de evaluación de programadores: ya no será por líneas de código o menor cantidad de errores. • Equipos PC cada vez más poderosos y económicos. Sybase. cambiarle colores o hacer transformaciones. Los primeros pueden ver esto como una real oportunidad profesional. Oracle. a fines de la primera década del segundo milenio.

• Los programadores pasarán a ser analistas-programadores. Tanto en el diseño como en la construcción de sistemas deben apoyarse en las herramientas de productividad. proveedores o competencia. para aumentar permanentemente la productividad. • Los analistas de sistemas pasarán a desempeñarse como consultores internos. a partir del diseño de la aplicación. su preparación debe incluir conocimientos sobre todas las nuevas herramientas de apoyo integral a la organización: estrategia. información y adaptación al cambio. pues ya tiene conocimientos actualizados y aplica las nuevas tecnologías. El 25% restante tiene poca tolerancia al cambio. el cambio del ferrocarril a vapor por la locomotora eléctrica y del carbón por otras fuentes de energía. pero pueden pasar a desempeñarse como apoyo en departamentos usuarios. trabajando en pequeñas unidades de informática descentralizadas o directamente en funciones propias del quehacer de otras áreas. en consecuencia. en lugar de desarrollar sistemas computacionales. el nuevo nombre que usamos es Gerente de Sistemas. liderazgo o inteligencia competitiva. sino de toda la empresa. aunque la mayoría de ellos puede subirse a este nuevo mundo con perfeccionamiento en la medida que su predisposición personal sea positiva. Su misión principal será la interacción con el medio: clientes. tal como se muestra en la figura 2-2. gestión de procesos. ellos deben proveer de soluciones informáticas completas. la calidad y el servicio al cliente no sólo de su área. El nuevo rol del analista ya es solucionar problemas. . También el cambio se aprecia en la evolución del nombre del cargo. 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. • 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. Más o menos el 25% de los actuales programadores no requiere entrenamiento especial. 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. benchmarking. especialmente en innovaciones.112 JUAN BRAVO C. El 50% deberá ser reentrenado y puede seguir desempeñándose sin mayores dificultades. aprovechando su conocimiento sobre la organización.

centralizada y como parte de cada área usuaria autónoma. en la organización debieran existir funciones de manejo de la información. Para que un área sea viable. Así como existe una fuerza aérea nacional y una rama aeronaval de la armada. compatibles entre sí: Equilibrio entre centralización y descentralización Significa conservar un centro de información a nivel de la empresa.MODELANDO UNA SOLUCIÓN DE SOFTWARE 113 25% Ya poseen los nuevos conocimientos 25% No tienen tolerancia al cambio 50% Pueden ser reentrenados Figura 2-2. . Analizaremos aquí algunas posibilidades de organización informática. de personas. La autonomía en esta materia tiene su base en los principios sistémicos de viabilidad y recursividad. en el marco de las normas convenidas y administradas por el centro de información. La recursividad dice que estas funciones esenciales se encuentran a nivel de la empresa y de cada área viable. debe poseer funciones esenciales de sobrevivencia: manejo económico. Nuevas formas de organización informática El diseño organizacional del área informática es parte integrante de las definiciones estratégicas respecto a la ingeniería de software. dando a cada área usuaria autonomía en el manejo informático. dirección y tecnología. Reconversión de programadores 3. entre otras.

infraestructura física y uso de otros recursos generales: contabilidad. En otras palabras. lo cual ya es poco probable. Rightsizing derivó del término downsizing. aun cuando el servicio interno resulte más económico que ser contratado externamente. por lo estándar de los PC’s.114 JUAN BRAVO C. Esto agrega el gran beneficio del ahorro de tiempo en interacciones innecesarias al interior de la empresa. porque. entonces ese es el tamaño correcto. en particular el equipamiento. todavía muy en boga para efectuar una reducción del tamaño de la infraestructura. con la ventaja extra de la arquitectura abierta. Es frecuente obtener más rendimiento a través de microcomputadores por el mismo costo de mantener un mainframe. según el enfoque sistémico. Externalización (outsourcing) Significa contratar externamente el servicio de informática. etc. porque generalmente resulta de más bajo costo subcontratar que proporcionarse uno mismo el servicio. entonces ese es el tamaño apropiado. Desde los puntos de vista económico. servicios básicos. 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. . 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 relación con la informática: • Es más económico. incluyendo en el costo interno las rentas de las personas. el cual probablemente es mayor al costo directo. • Es más natural. porque ha venido sucediendo que el desarrollo exponencial de los computadores personales está dejando obsoletos los mainframes o equipos grandes. un especialista en información. teniendo el cuidado de mantener internamente algún interlocutor con amplios conocimientos de informática y de administración. la máxima potencia de una organización se logra cuando está totalmente concentrada en su misión. 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. la cual desatiende al destinar tiempo y recursos en atender a la autogeneración de servicios que puede tomar del medio. Si es posible satisfacer al cliente interno subcontratando el desarrollo de sistemas y la única infraestructura centralizada es un especialista en información.

el profesional de informática —y lo mismo es válido para contadores.MODELANDO UNA SOLUCIÓN DE SOFTWARE 115 En esto debemos ser cuidadosos. externalizó a mediados de los 90 gran parte de los servicios administrativos —pago de remuneraciones. las innovaciones tecnológicas son definitivamente ventajas competitivas. los supermercados y muchos otros que necesitan el procesamiento en tiempo real y el manejo de grandes volúmenes de transacciones. ya no es un “patito feo”. entre muchas otras posibilidades. los cuales fueron provistos por una . • Es más humano. 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. porque. como parte de su política corporativa. existen serias dificultades de comunicación con el resto de la empresa. no hay mayores incentivos para innovaciones. Ripley y Almacenes París en Chile— los bancos comerciales. uno podría plantear que su negocio es tecnología. porque hay organizaciones con misiones que dependen totalmente de la tecnología. debemos estudiar cada caso en forma individual para su eventual aplicación. Un plan de externalización debería incluir el destino de los especialistas en informática. Este aspecto debe ser analizado en la gerencia con la mayor atención debido al impacto que tiene sobre la motivación de todas las personas. porque no se aprecian los cambios creativos debido a lo especializado de su área. sin embargo. IBM de Chile. de común acuerdo con ellos. Cuando el profesional de informática se desempeña en una organización de informática. su evolución profesional es más lenta porque solamente conoce la realidad de la empresa. Es el caso de las grandes tiendas por departamentos —tal como Falabella. incluso. sus contribuciones son comprendidas y apreciadas. la renta se va incrementando según su rendimiento y se produce un ambiente motivador que ayuda a incrementar la productividad. En estos casos. Además. 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. Esta es la regla general. contabilidad y otros—. La prudencia indica que debemos reconocer muy bien la misión de la empresa. cobradores. Por ejemplo. porque ahora puede comunicarse con sus pares. generalmente. Su campo de desarrollo profesional se amplía. guardias y otras personas de servicios internos— tiene menos posibilidades de desarrollo en una empresa dedicada a otra misión: su renta queda rápidamente estancada.

En la figura 2-3 vemos un esquema de planificación informática. La planificación informática fija el marco para priorizar los proyectos informáticos y obtiene un plan que debe mantenerse actualizado. tipo de producto para . Planificación Estratégica Procesos del negocio Realidad actual: Definiciones estratégicas Aplicaciones Conjuntos de datos Proyectos en desarrollo Definiciones estratégicas: Organización Equipamiento Bases de Datos Métodos Herramientas de productividad Normas Participación del usuario Conjuntos de datos En los procesos Referencias cruzadas Procesos vs datos Modelo conceptual de datos Evaluación Estrategia Informática Prioridades de desarrollo. empresa de 30 ex-empleados que. a poco andar. plan de equipamiento. se trabaja en las definiciones estratégicas del área informática: organización de la función informática. definiciones estratégicas y plan de implementación 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. 4.116 JUAN BRAVO C. 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. tuvo que hacer muchas contrataciones adicionales. modelo de datos.

sino que se trata de un subproducto de la planificación estratégica de la organización. infraestructura. En paralelo con las definiciones estratégicas se puede ir avanzando en definir los procesos del negocio de la organización. podría adelantarse en ver ¿con qué contamos? Es decir. Conciliar el interés particular y general es de suma importancia en esta etapa. Después. Considerando que las personas son lo importante. Es posible obtener en esta planificación el modelo conceptual detallado. orientados al cliente y a objetivos internos. Con todos estos antecedentes se realiza una evaluación junto con los usuarios. el aspecto perfeccionamiento es de primera importancia en este plan. Para definir las prioridades se consideran: importancia del proceso. La forma de trabajar en estas materias es mediante un equipo interdisciplinario donde también participan especialistas en información. Luego. métodos de la tecnología de información. tienen algún grado de avance. Para evaluar. debemos conocer las aplicaciones en funcionamiento. entre otros factores. Es importante destacar que esta planificación no es aislada. respectivamente. herramientas de productividad para los usuarios y el desarrollo de sistemas computacionales. construimos una matriz con todos los procesos y conjuntos de datos. principales y secundarios. con todos los datos y relaciones. También en paralelo. artículos u órdenes de compra. comunicaciones o hardware. identificamos los conjuntos de datos que se manejan en cada proceso: clientes. El objetivo es darle prioridad a aquellas aplicaciones que se perciben importantes y que. capacitación. las definiciones estratégicas reformuladas a la luz de los nuevos antecedentes aportados durante el desarrollo del estudio y el plan de implementación definido para llevar a cabo los diferentes proyectos. El plan informático que obtenemos como resultado incluye las prioridades de desarrollo. proveedores. software. la cual generalmente está apoyada con consultoría externa. determinar cuál es la realidad actual de las definiciones estratégicas indicadas en la segunda columna de la figura 2-3. La coordinación a alto . los conjuntos de datos ya formados y los proyectos en desarrollo. el objetivo es obtener referencias cruzadas y determinar la importancia relativa de cada conjunto de datos para comenzar a formar un modelo de datos conceptual de la organización. es indispensable dimensionar los requerimientos de personas. acuerdos de normalización en múltiples aspectos y grado de participación de los usuarios.MODELANDO UNA SOLUCIÓN DE SOFTWARE 117 administrar las bases de datos de la empresa. además. Adicionalmente. un modelo de los conjuntos de datos y sus relaciones. grado de desarrollo previo y tamaño.

productos CASE y bases de datos. algunas empresas chilenas han buscado que el software obligue a responder. Al igual que con cualquier normalización viable. el desarrollo de la planificación estratégica en informática debe tener las siguientes características: consensual. Es preguntarse. se logra mediante talleres de planificación estratégica en tecnología de información. flexible. que no han aumentado en nada la productividad. porque la mayoría de la personas no tiene el hábito de contestar un mensaje. ¿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. todo cambio externo debe ser compensado con un cambio interno equivalente.118 JUAN BRAVO C. pero sí el costo. en el sentido de que sea aceptable para la alta gerencia. El cambio cultural de la organización tiene relación directa con un principio sistémico: para que la organización conserve su viabilidad. . todos mantuvieron sus hábitos. Los usuarios siguieron sin comprometerse. ¿Por qué? Porque no cambió la cultura de la organización. Lo cual no ha sido necesario en el país de origen del producto. Cambio cultural de la organización La incorporación exitosa de cualquier nueva tecnología requiere un cambio cultural previo de la organización. ¿cuál es el ambiente en donde esta tecnología tiene su mayor potencialidad? Por ejemplo. Para intentar solucionar el problema. de lo contrario. nivel. En Estados Unidos sí ha tenido éxito. el sistema corre el riesgo de romperse. reiterar la necesidad de liderazgo. equivalente a devolver una llamada con la anterior tecnología. porque la mayoría de las personas tiene el hábito de contestar los mensajes. Hemos visto casos de incorporación de excelentes herramientas. En otras palabras. actualizada y vendible. 5. en lugar de desnaturalizar una herramienta. gerencia general y jefaturas funcionales. los programadores 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. en muchas organizaciones chilenas no se han obtenido los resultados esperados de los correos electrónicos y herramientas tipo Groupware.

. esto produce un desgaste que atenta contra el mejor desempeño global. se revisa. . Aquí las buenas soluciones que aparecen se ven ahogadas en el medio.Normalización externa: en este caso las soluciones son compatibles con el medio. con planes comunes. así la organización se inserta en su comunidad y evita desgastarse creando métodos y herramientas particulares para contabilidad. Aquí hay un alto grado de acuerdo y compromiso al interior de la organización.Normalización interna: también llamado folklore nativo. Generar normalizaciones internas particulares ajenas a su negocio no es la misión de la organización. . porque. la organización prueba nuevas opciones. comenzar por ubicarse en uno de los siguientes niveles de evolución de tolerancia al cambio: 1. normalización y comunicación. se comparten los resultados y se analiza su eventual incorporación. cuando ellos se van. informática o finanzas.Anarquía: significa que las diferentes áreas son como feudos. El perfeccionamiento de las personas es vital. . aunque pareciera que mantienen una situación artificial. como un todo. En este nivel comienza a notarse la importancia del perfeccionamiento de las personas de la organización. todo vuelve a la “normalidad” anterior (es como empujar “murallas de goma”). aquí ya se aprecia un fuerte compromiso de la empresa. se aplican métodos y herramientas normalizadas. Es como si en la empresa textil se desarrollara una herramienta de mayor productividad para informática.Adaptación a la dinámica del medio: sobre la base de la normalización externa. 2. . aunque pobre en rendimiento. Cada vez que una tecnología se ve interesante para la empresa. Con esto se vence la resistencia al cambio y la organización es permeable a las buenas ideas del ambiente. 3.MODELANDO UNA SOLUCIÓN DE SOFTWARE 119 Para la incorporación exitosa de la tecnología es indispensable la preparación de la organización. En este ambiente surgen “llaneros solitarios” que logran mejorar su área a costa de mucho esfuerzo personal. aunque basada en soluciones particulares o debido al esfuerzo de algún miembro con poder que ha logrado imponer su visión. con el nuevo enfoque. con escasa coordinación entre ellas y sin normalización ni planes comunes. Es el caso del comportamiento autocrático. 4. Toma del medio las tecnologías que necesita y acude al mercado laboral para proveerse de personas entrenadas. indudablemente mejor que la anarquía. Este último nivel permite cuestionar y renovar las normas de la organización.

educación. personas. 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 incorporada (como en el modelo de negocios del capítulo 1. porque las distinciones entre un nivel y otro no son rígidas.120 JUAN BRAVO C. quienes introduSe refiere al ranking de la revista homónima con respecto a las 500 empresas de mayores ingresos y rentabilidad. En un ambiente de amplia uniformidad y consenso está razonablemente garantizado que la decisión de incorporar una nueva tecnología no es producto de la impulsividad de una persona. dictado en Santiago en Octubre de 1992) indican que el 87% de las organizaciones de ese país caen en la primera categoría. capacitación y herramientas de apoyo. estructura y tecnología). como parte del proyecto de cambio. En tal caso. el resultado de incorporar nuevas tecnologías es tiene alta probabilidad de ser un fracaso más. Resumen de la planificación estratégica en informática Este resumen no pretende ser una receta para realizar planificación en informática sino solamente servir de guía para profesionales. 6. En esta clasificación —por cierto flexible. exige que la cultura de la empresa esté en los niveles tercero o cuarto. que incluya infraestructura. Si la organización está en los niveles anárquico o de normalización interna. aunque es sintomático que la mayoría de las empresas Fortune39 500 estén en el cuarto nivel. la implementación exitosa de los métodos y herramientas de la tecnología de información. comparaciones formales y mucha reflexión. Sólo en ese suelo fértil se puede cosechar el fruto de la productividad. Si ya está en el nivel 4. un 12% en el segundo nivel y sólo el 1% llega a los niveles tercero y cuarto. Es interesante conocer que estudios realizados en Estados Unidos (señalados por Edward Yourdon en su curso Análisis y orientación a objetos. 39 . en transición desde el segundo al tercer nivel. sino que se trata de orientaciones generales— cada nivel incluye las características evolutivas del anterior. Luego se establece un plan de trabajo para pasar al siguiente nivel. Cuando menos. el cambio debe realizarse en toda la mesa: estrategia. Concretamente. Es indispensable la generación de un plan de implementación. procesos. sino resultado de estudios. es indispensable que la organización invierta previamente en el cambio cultural. como podría ser en los niveles anárquico o de normalización interna. pruebas.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

121

cirán cambios y realizarán las adaptaciones necesarias para atender cada situació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

122

JUAN BRAVO C.

Plan de implementación Perfeccionamiento En conclusión • La TI por si sola no aporta valor, está al servicio del propósito de la organizació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.

FO

FD

VC

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 ventaja competitiva. En las debilidades es preferible no desgastarse, mejor externalizar 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 valores que percibe el cliente.

40

Ver libro Gestión de procesos.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

123

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 sistema 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 armonioso 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 computacionales es un factor diferenciador para el éxito del negocio. Obviamente, esto no es gratis, pues exige una inversión que debería ser asumida como un proyecto, comparando beneficios versus costos, incluyendo el costo vigente de la falta de información para la toma de decisiones. La inversión, además de dinero, incluye tiempo, disposición y esfuerzo de los interesados. Es más, si la organización como conjunto no está dispuesta a comprometerse, 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 software, sólo puede ser modificado por una solución con variedad equivalente. Esa

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.

41

124

JUAN BRAVO C.

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 advertencia: 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 factor. Por ejemplo, tal vez no elijamos la herramienta más moderna, pero nuestra selección se lleva bien con el hardware que empleamos, es fácil de aprender 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 Weitzenfeld 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 discuten 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, confiabilidad, 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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

125

énfasis en aspectos de calidad, control de riesgos e incorporación de las competencias 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 producido. Este concepto se aplica generalmente a implementar la aplicación en diferentes 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 aplicaciones, 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 componentes, 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 organización y las herramientas de apoyo al desarrollo de software (CASE).

126

JUAN BRAVO C.

Algunos ejemplos de herramientas son: simuladores, administradores de bases de datos y generadores de aplicaciones. En el capítulo 7 se describen algunas herramientas.

4. Hardware
Mucho se habla sobre el extraordinario avance en el rendimiento de los computadores y el acierto de Gordon E. Moore con la conocida ley que lleva su apellido, dice que cada 18 meses se duplica la capacidad de los computadores, originalmente aplicada a los grandes equipos, se popularizó para los 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 rendimiento 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 infraestructura. 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 “estaciones 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.

Sorprende al autor el rápido avance, en 1980 estaba a cargo de una instalación con equipamiento 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, Planificación en Informática, se describió este concepto.

43

MODELANDO UNA SOLUCIÓN DE SOFTWARE

127

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 mucho más profundo… la adaptación al cambio. A veces el usuario no sabe exactamente lo que quiere, aún así, eso no es motivo 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 construcción de un sistema de información no significa una “imposición de cambios” 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 comprensión que tiene el usuario de su propia necesidad45 y de la calidad de la informació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 principios 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 embargo, 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 identificación, el sistema me dirá si usted dice la verdad, ¿lo hago?” El infractor contesta: “Prefiero pagar”. El Juez tiene clara su necesidad.

se gana tiempo disminuyendo el overhead administrativo. Se le llama también costo de transacción o de administración. 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. ¿Cómo influye la amistosidad de las herramientas en el aumento de la productividad? Se entiende la característica de amistosidad en un sentido amplio. . Hay que ser cuidadoso con no abusar de esta descentralización porque la autonomía del usuario podría interferir con la necesidad de tener sistemas centralizados e integrados. desde el punto de vista de la rapidez. se obtiene un subproducto que aumenta en mucho la productividad: la reducción de las interacciones innecesarias con otras personas. de integración del usuario e incluyendo el concepto de interfaz intuitiva. proveedores) y… los usuarios están aprendiendo. voz e íconos. existe una importante infraestructura de apoyo (departamentos de sistemas.128 JUAN BRAVO C. consultores. con una planilla electrónica o con la contratación del servicio externo directamente por el usuario. debería destinar unas 100 ó 200 horas al perfeccionamiento inicial en tecnología de información y luego unas 40 horas anuales. se considera la característica de amistosidad como parte de la productividad. Por ejemplo. en el marco de un equilibrio entre especialización y generalización. porque ésta puede aumentar casi al doble si los usuarios comienzan a resolver una porción de sus propias necesidades. hoy todos los elementos son más amistosos (hardware. Cuando el usuario soluciona sus propias necesidades menores. Desde un punto de vista técnico. 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. en el cual se trata de dar al software el máximo de naturalidad a través del uso de imágenes. Esto es hoy una realidad para aplicaciones muy simples que se pueden resolver. muchas herramientas y métodos). La solución del conflicto es materia de un proceso de negociación interna. Sin que el usuario afecte su especialización dentro de la organización. Es el tiempo invertido en la definición y control del acuerdo. Desde este punto de vista. por ejemplo. En el caso del desarrollo de software. Naturalmente. estimándose que ellos puedan absorber sin problemas casi la mitad del desarrollo —lo cual significa que se libera la mitad del trabajo de los especialistas— particularmente la de aquellas aplicaciones que demoran más en explicarse que en hacerse. el cual se podría definir como el tiempo improductivo destinado a una labor productiva.

sería más preciso distinguir entre dos tipos de usuarios: • Los emprendedores. hacer una cosa a la vez. Ellos se han visto “arrastrados” al proyecto por imposición de la alta gerencia o por otras razones. al procesar en forma multiusuario es posible que los dos procesos terminen de ejecutarse en 4 horas. • Los dependientes. profesionales que luchan por el proyecto como si fuera algo personal. realmente. ¿Cómo influirá en este efecto la nueva generación de equipos multiprocesadores? Ya se verá. porque la suma de los tiempos en modalidad monousuario es de 2 horas. debe ocupar tiempo para guardar el estado de la tarea anterior. si tenemos dos procesos que demoran una hora cada uno en modalidad monousuario. bien representados como empresarios o intraempresarios. Por supuesto. . el overhead habría sido del 100%. Ya sabemos que la probabilidad de éxito del desarrollo es baja en este caso. será como procesamiento en diferentes equipos y un procesador debería atender una tarea a la vez. ingeniería el procesamiento monousuario es más eficiente que el manejo multiusuario. Por ejemplo. inicializar variables y “administrar” el cambio de tarea. Todo analista experimentado sabe que generalmente eso no es cierto. entre los emprendedores y los dependientes hay infinidad de situaciones intermedias. Este profesional debiera tener amplios conocimientos de planificación estratégica. conscientemente. en todo caso.MODELANDO UNA SOLUCIÓN DE SOFTWARE 129 produce cuando una persona pretende hacer 2 ó 3 tareas a la vez. Más que una generalización en este sentido. desconociendo nuestra limitación natural de que sólo podemos. el procesador 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. proyectos. De esta manera se optimiza el uso del tiempo y se obtienen mejores resultados. En tal caso. porque él debiera conocer mejor que nadie su propio problema. ¿Cuál es la causa? Al procesar concurrentemente. porque el procesamiento de dos tareas en paralelo demora más que la suma de los tiempos de ejecución de las mismas tareas procesadas en serie. Ellos son intraempresarios o “empresarios al interior de la empresa”. Son los menos. Aunque estamos haciendo una suposición peligrosa: que el usuario sabe lo que quiere. buscan a toda costa evitar comprometerse y quieren ver funcionando un sistema “perfecto” antes de firmar un papel. quienes participan en el proyecto por obligación. participan y se comprometen con su proyecto. quienes gestan. En algunas empresas está comenzando a implementarse una alternativa interesante: contratar a un especialista en información. Son bien conocidas las dificultades para que usuarios intermedios se comprometan y ayuden a completar la definición de sus propios requerimientos.

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. 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. entre otros temas que le permitan comunicarse bien con usuarios y especialistas en informática. actitudes y habilidades. ¿Cómo influye la habilidad? Existen estudios que señalan diferencias de productividad de hasta 30 veces entre programadores. Es fácil observar en cualquier organización las diferencias de rendimiento. en el 10% del potencial. Incluso. verá que generalmente en una muestra superior a 10 personas la relación entre el menos y el más productivo comienza a pasar de las cinco veces.130 JUAN BRAVO C. 6. un importante elemento de motivación para el programador es trabajar en un ambiente donde esté en constante aprendizaje. las personas aprenden en un medio exigente y con colegas de categoría. tal como los castillos de los señores feudales durante la Edad Media. e informática. donde se aprecia que la productividad es producto de la armonía entre esos factores. Es interesante sensibilizar que si aumentamos 1 en la técnica. como en la gestión por competencias. Sobre todo. tal como se muestra en la figura 2-4. El extremo de la especialización podría llevar a la incomunicación. Es decir. el producto será 12 y si aumentamos 1 en la comunicación. Resulta evidente nivelar hacia arriba con un esfuerzo de investigación que descubra causas asociadas al conocimiento. Una situación difícil de creer y lamentablemente reiterativa. con lo cual el producto es 10. el producto es 15… . Las mediciones que hemos realizado en empresas muestran que en promedio estamos en 5 en especialización y en 2 en comunicación interpersonal. Habilidad del desarrollador La habilidad es algo que se obtiene principalmente con la buena experiencia y una capacitación puede acelerarla notablemente. Trabajar en técnica y comunicación Hemos aprendido que se requiere trabajar en dos líneas a la vez: especialización y comunicación interpersonal. quieren seguir atrincherados en su inexpugnable y aislado reducto. Esto puede llevarlo a proponer cambios drásticos en la aplicación a su cargo.

las herramientas de software. 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. sin las grandes variaciones entre los esquemas particulares de cada especialista. 7): “Todas las nuevas tecnologías prometen reducir los tiempos de desarrollo y aumentar la tasa de éxito de los proyectos. Normalización externa Es indispensable realizar un sostenido. p. debido a que cada persona tiene más gente con quien comunicarse”.MODELANDO UNA SOLUCIÓN DE SOFTWARE 131 Especialización 10 100% de potencialidad (máxima productividad) 0 0 10 Comunicación Interpersonal Figura 2-4. . 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. los métodos de desarrollo. A esto se refieren Stevens y Pooley (2002. 7. este más se atrasará. pero los ingenieros de software experimentados tienden a ser justificadamente escépticos al respecto. Así. Es sabido que mientras más gente sume a un proyecto atrasado. la documentación. Cuanto mayor es el proyecto. cada una de las etapas del desarrollo de software se realizará uniformemente. ser ejecutado por el responsable de informática y supervisado por el comité de informática. coherente y planificado esfuerzo de normalización al interior de toda la organización y con el exterior. el entrenamiento. especialmente en proyectos grandes. ¿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. Este esfuerzo debería estar considerado en el plan informático. ¿Qué debe normalizarse? Todo: el hardware. Armonía entre técnica y comunicación Es vital el factor comunicación.

• Puede seleccionar del medio las mejores y más productivas tecnologías. De alguna manera dejar una ventana abierta a la exploración de nuevas posibilidades. la normalización interna debería dejar espacio para la creatividad. esquemas de organización. Sin ser una receta. sin distraerse en materias ajenas. Si estamos en un hospital. 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. a veces se dice que el 90% de los requerimientos debieran canalizarse por las vías normalizadas y el 10% por vías alternativas más innovadoras. métodos de trabajo y herramientas de apoyo. infraestructura y otra serie de servicios menos conocidos. obligándose en este caso a efectuar grandes esfuerzos de entrenamiento. insumos.. tal vez podría ser el 10% de menor impacto en la organización. • Puede solicitar personas capacitadas externamente.. el surgimiento de nuevas soluciones y el ensayo de nuevos métodos y herramientas. El concepto existente detrás de la normalización es la total integración con el medio. a diferencia de cuando la tecnología es particular. No obstante. Las normas permiten acumular experiencia transmisible. 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 diferentes áreas. • Hay independencia de individuos que monopolicen y manipulen con el conocimiento específico interno. Si nuestra misión es producir o vender prendas de vestir. sin que la organización corra el riesgo de perturbar la satisfacción de sus necesidades de información. Frecuentemente. entre los cuales se cuentan tecnologías. • Es más sencillo subcontratar servicios específicos. su negocio es ayudar a recuperar la salud de los pacientes y no el desarrollo de nuevas técnicas de modelamiento o la construcción de hardware sofisticado.132 JUAN BRAVO C. . Veamos algunas de ellas: • Le permite centrarse en su misión. probablemente lo vamos a hacer muy mal si nos desgastamos en crear e introducir métodos particulares de desarrollo de software. La normalización externa otorga múltiples ventajas a la organización. son reglas de sentido común para la organización que van siendo parte de la inteligencia colectiva.

no debieran exceder la decena de páginas. métodos. preparada solamente por consultores o unidades especializadas de la empresa. Por ejemplo. Es preparada . • Orientada a toda la empresa: la normalización también debe darse al interior de la empresa. • Conocida por todos los interesados: se recomienda crear un sistema de información destinado a enviar oportunamente un ejemplar de la normalización o de su actualización a todos los interesados. la normalización también podría ser corregida frente a situaciones excepcionales. La buena normalización garantiza el funcionamiento regular de la institución. las innovaciones son bienvenidas y pueden desarrollarse con amplia colaboración. • Simplicidad: una normalización larga y compleja. debiera ser breve y precisa. sobre métodos. para asegurar la implementación. según una “base de usuarios” actualizada y con mecanismos apropiados para eliminar las copias anteriores obsoletas. Las principales características de la normalización son: • Siempre actualizada: a través de reuniones periódicas destinadas a su revisión. herramientas. tecnología y todo aquello que facilite la comunicación. dejando espacio para el desarrollo permanente de nuevas ideas. se toman del medio esquemas probados para no distraer la atención de los verdaderos intereses de la organización. sino que son varias y cada una atiende un asunto específico. • Permite las innovaciones: la normalización no significa “ahogar la empresa” con reglamentaciones. consultores u organismos especializados de la empresa. de tal forma que todos sus estamentos normalicen políticas. • Consenso: las diferentes normas debieran ir surgiendo como resultado de consenso entre todos los interesados. como la implementación de un nuevo sistema o la integración de otra persona a la organización. existiendo en el medio buenos métodos que podrían satisfacer sus necesidades de manera simple y económica. Para incrementar las posibilidades de que se respete. está fuera de época y es poco práctica. las pautas referidas al área informática.MODELANDO UNA SOLUCIÓN DE SOFTWARE 133 Tómese como ejemplo la anarquía en el desarrollo de sistemas computacionales al interior de muchas organizaciones. Naturalmente. • Atiende materias específicas: no existe “la normalización” de la empresa. idealmente una vez por semana. En este contexto. Muy por el contrario. herramientas. hardware y software básico. Cuando las pautas son impuestas por la jerarquía. las posibilidades de que sean respetadas son menores.

particularmente en la línea de ser más empresario que administrador. • Alineamiento del plan TI con el plan de negocios de la organización. por ejemplo. 8. Con amplia participación. Ya vimos en el capítulo 1 la especial relevancia que tienen el liderazgo y el trabajo en equipo. Esta serie de factores de contexto podrían resumirse en la búsqueda de la excelencia en la gestión. silencio y otros elementos ambientales tienen un importante rol que jugar en la productividad de los profesionales de sistemas y de toda la organización. en el sentido de su reformulación permanente y conocimiento de ella por parte de todos los integrantes de la empresa. Algunos factores de contexto son: • Calidad de la planificación. cumplimiento de los acuerdos y un ambiente de colaboración. • Permeabilidad de la empresa a la innovación tecnológica. por quienes están dedicados a la materia. tranquilidad. • Respuesta a la competencia y permanente conocimiento de lo que el mercado ofrece. Si son positivos pueden ayudar a aumentar la productividad más allá de las 10 veces señaladas al comienzo de esta sección acerca del Sistema de productividad en el desarrollo de software. en la normalización informática participan analistas. . • Capacidad de la gerencia. • Ambiente físico: temperatura. producción. • Participantes experimentados: así aumenta la eficiencia y la probabilidad de éxito del proyecto. ventilación. Otros temas se orientan a mantención.134 JUAN BRAVO C. Factores de contexto Hay otra serie de factores que también debemos tomar en cuenta. • Conocimiento del problema: es vital la participación del usuario y decisivo para el éxito del proyecto de software. comodidad. • Conocimiento del entorno donde se insertará el producto desarrollado. administración o secretaría. • Motivación de las personas. programadores y usuarios.

Criterios anticuados de desarrollo de software 2. 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. La aplicación de esta pauta dio origen a modalidades de construcción de sistemas que retrasaban el desarrollo. Criterios anticuados de desarrollo de software Antiguamente enfrentábamos el desarrollo de sistemas con el siguiente criterio de optimización: Mínimo uso de espacio en disco. tanto que.4. Son las llamadas “ingeniosidades”. perturbaban la mantención y dificultaban la actualización de la documentación. como éstas: • Diseño del sistema en forma muy particular. Mantenimiento de la solución de software 1. ¿Construir sistemas computacionales sin programar? 5. la idea de publicar esta obra nace del gran cambio producido en la forma de enfrentar el diseño de una aplicación computacional. El programa grande es consumidor de recursos. finalmente. sólo son conocidos por el especialista. independiente de la implementación tecnológica. Se definen repositorios de datos y programas en forma muy particular para la aplicación. con el riesgo de que aun a él se le olviden las particularidades. Pruebas del software por el programador 6. Se supone que tienen la “ventaja” de “cargar” sólo un programa que resuelve muchas funciones. • Construcción de programas grandes que resuelven varias funciones. Veremos: 1. no posee una buena estructu- . difícil de construir y de mantener. Habitualmente incorpora elementos extraños como switches (marcas o “banderas” que ayudan a condicionar bifurcaciones) e instrucciones sofisticadas del lenguaje. memoria principal y tiempo de procesador. Mitos del desarrollo de software 3. CRITERIOS DE DESARROLLO DE SOFTWARE En gran medida. en lugar de varios programas que se irían llamando según se requieran. Con esa filosofía se presentan a continuación antiguos criterios.MODELANDO UNA SOLUCIÓN DE SOFTWARE 135 2. Nuevos principios para el desarrollo de software 4. nuevos mitos y algunos principios para un nuevo esquema de desarrollo de software.

El costo de esta solución es US$ 500. 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. la información pasa a ser parte del código. Con el abaratamiento de los medios de almacenamiento y la mayor velocidad de los procesadores. pero no deberían utilizarse a menos que sea realmente indispensable porque el contenido del vector o matriz queda invisible para la organización. Nada hay que complique más la mantención que la incorporación de rutinas complejas dentro de un programa. el 00 y el 99 se usaban como “banderas” o condiciones de diferente tipo. pero cada consulta demora hasta 10 segundos y él requiere la respuesta en un máximo de 3 segundos. Como muestra. todavía hay mucha mantención de sistemas antiguos). en la mayoría de los casos el problema que da origen a la rutina compleja podría haberse enfrentado de otra manera en el diseño.136 JUAN BRAVO C. Construir rutinas complejas para resolver problemas del mismo tipo ¿no es como reinventar frecuentemente la rueda? • Utilización de matrices en programas. sin embargo. Es más. • Definición de rutinas complejas. Una complicación adicional fue que los datos estaban dentro del programa (por ejemplo. Se plantean dos alternativas de solución: • Adquirir un equipo más poderoso. de mayor rapidez y capacidad de almacenamiento. Además. los cuales representan una excelente instancia de optimización. que hacer al llegar cierta fecha) y no como parámetros. También podrían utilizarse rutinas prehechas o generadas con herramientas de cuarta generación. ración y más bien está construido con una desagregación muy poco funcional. Por ejemplo. con enormes dificultades para su actualización (hoy con la introducción masiva de las bases de datos es menos frecuente en nuevos sistemas. Es típico de programas muy complejos hacer uso indiscriminado de vectores o matrices. . el criterio de optimización quedó obsoleto. De esta forma el computador “entendía” que pasaba desde 99 a 00 y entonces bajaba de año en vez de subir. Siempre es posible simplificar y modularizar las rutinas. la cual funciona bien. considerando lograr algún ingreso con la venta del PC antiguo. véase el siguiente ejercicio: Un usuario de un PC necesita mejorar el tiempo de respuesta de su aplicación.

donde hay otros factores que también inciden. Ampliar hardware US$ 500 US$ 100 2 días 1 día alta Optimizar código US$ 400 US$ 600 1 mes 1 semana nula Factor de comparación Costo inicial Costo de mantención Tiempo de implementación Tiempo del usuario Utilización en otras aplicaciones Figura 2-5.MODELANDO UNA SOLUCIÓN DE SOFTWARE 137 • Contratar un programador para optimizar el código de los programas. . asciende a US$ 1. Otros factores serían: ¿cuánto es el costo de oportunidad al retrasar la solución en un mes. 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. ampliarían todavía más la brecha. el cual puede elevarse varias veces cuando el programa no está bien documentado o los métodos de programación han sido anárquicos. considerando la mantención del código.000 en el caso de codificar y a US$ 600 en el caso de ampliar el hardware. en el caso de optimizar código? y ¿cuánto cuesta el tiempo del usuario. Lo mismo es válido para variadas formas de externalización. 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. Este ejercicio se puede extrapolar a problemas mayores en las instalaciones. En la figura 2-5 se muestra el ejemplo de una tabla comparativa entre las soluciones propuestas para un período de tres años. El presupuesto es de US$ 400. El objetivo ha sido destacar que la simple renovación del hardware resuelve automáticamente un cierto rango de problemas. si se cuantifican en dinero. Es claramente conveniente ampliar el hardware y esto sin considerar los otros factores de comparación que. se ha valorado conservadoramente el costo de la mantención.

138 JUAN BRAVO C. • Desarrollo por prototipos es la solución. en lugar de atender los nuevos requerimientos del negocio. 2. Así llegamos a tener usuarios desesperados porque todavía no obtienen lo que necesitan. produciéndose las llamadas “islas de automatización”. • Ciclo de desarrollo excesivamente largo. • Una correcta especificación evitará la mantención. 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. con lo que aumenta más aún la confusión. • Las herramientas de cuarta generación serán la solución. manteniéndose los clásicos problemas de: • Colas de “desarrollo pendiente” que alcanzan a varios años. 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 antiguas. a veces de más de un año. el costo para la organización aumenta geométricamente (se reduce 3 aumenta 9) a raíz de la mantención del código. • Automatizar el máximo de funciones administrativas. sin evaluar que en un gran porcentaje de los casos. una oferta total de trabajo creciente para especialistas preparados en apoyar a los usuarios. en la realidad se está produciendo el fenómeno contrario. apoyándose en variadas herramientas y olvidando considerar que cada línea de código deberá ser mantenida. Este mito se alimenta a veces de algunos pocos ejemplos de externalización (outsourcing) donde se han despedido programadores. desconociendo que el 80% de la mantención se debe a cambios y el 20% a errores. nuevos mitos han tomado el lugar de los antiguos criterios de desarrollo. • Dedicación predominante a la tarea de mantención. • Cesantía de programadores. incluso algunos han optado por seguir su propio camino. Mitos del desarrollo de software En algunos departamentos de sistemas. Algunos de los nuevos mitos en el desarrollo de software son: • Desarrollar rápidamente. aplicándolo en sistemas computacionales donde su aporte es escaso y descuidando la necesaria definición previa de requerimientos. .

se dio inicio a un proceso de profesionalización que efectivamente ha producido un avance en la calidad del software. Una vez que el problema ha sido resuelto en forma simple e independiente de la implementación tecnológica. siempre es posible dividir un problema complejo en un subconjunto de problemas más fáciles de resolver. A través de métodos y herramientas normalizadas para producir software de calidad. simple. Fue un esquema difícil de entender. en plazos convenidos y dentro del presupuesto asignado. Es en el mismo período cuando comienza la aplicación del análisis y diseño estructurado. se debe estudiar si es realmente necesario aplicar fórmulas de optimización. por lo tanto. Un problema frecuente ha sido el alto grado de dependencia de la aplicación respecto del especialista que la desarrolló. mantener y . • Resolver sólo problemas simples. portable. pero tuvo el gran mérito de llamar la atención sobre la importancia de los datos. • Evitar las particularizaciones producto de una optimización innecesaria. lo que finalmente se resuelve son problemas simples. Es en este contexto que se plantean algunos principios para un nuevo esquema de desarrollo de software: • Lograr la producción profesional del software. 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. más el énfasis en trabajar metodológicamente. económico. • Independencia de la aplicación respecto al especialista. aunque manteniéndose la visión de conjunto. 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 objetos—.MODELANDO UNA SOLUCIÓN DE SOFTWARE 139 3. con el surgimiento de estándares como la orientación a objetos y UML. porque podrían introducir sofisticaciones indeseadas en el modelo. En los noventa. personalizado. Aplicando los criterios de modularización y de descomposición funcional. rápido y amistoso. engorroso de implementar y excesivamente caro. Lo que ahora se busca es permitir que otros especialistas y usuarios calificados puedan también entender. porque el objetivo era la optimización de algoritmos para economizar tiempo y memoria debido a la limitación de recursos de hardware. En los años 80 se dio una importancia desproporcionada a los sistemas administradores de bases de datos (muchos especialistas pensaron que era la tan anhelada panacea) con énfasis en las estructuras de datos.

informes. o de programación. Esto facilita la participación del usuario y se motiva al especialista a resolver el problema en un nivel de modelo conceptual. Hoy está consolidado su aporte en la construcción de los elementos más normalizados: definición de pantallas. “Sin programar” significa más bien “sin programación tradicional”. 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). significa que la programación es una actividad poco natural. de miles de instrucciones en lenguaje de alto nivel. lo cual es posible aplicando los conceptos de productividad de la sección anterior. menús y otras partes de la aplicación.140 JUAN BRAVO C. más que a nivel físico. mediante 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. al menos. para ser incluidas en la base de conocimiento o en un diccionario de funciones de la herramienta con la cual se estaría trabajando. 4. Por ejemplo: . En todo caso. continuar el desarrollo de la aplicación frente a la salida del primer desarrollador. si el porcentaje de la población con esa aptitud es tan bajo. un equipo de desarrollo previamente debería haber construido las clases). ¿Construir sistemas computacionales sin programar? Es plenamente factible construir software sin necesidad de programar. Cierto que cualquier aplicación compleja incluye en definitiva alguna cantidad de programación. la cual relativamente pocas personas son capaces de hacerla correctamente. Una dificultad en la producción de software es la estructuración manual de lógica o programación. Quienes no tienen esa aptitud natural y necesitan programar. 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. deben tener una larga formación hasta lograrlo. esos programas largos. cada nuevo desarrollo de sistema será una inversión en inteligencia para la organización. Se requiere elevar la productividad de los especialistas en. también es válido que el apoyo ofrecido por las herramientas de productividad va en aumento y es posible que en algún momento represente un porcentaje cercano a la aplicación completa. Una forma de reducir el impacto de este problema es mediante un buen diseño implementado con la ayuda de una herramienta de productividad. difíciles de construir y de mantener. un orden de magnitud (de 1 a 10 veces). • Incrementar la productividad. De esta manera.

realizar un cambio en una rutina de 30 líneas es cuestión de minutos. esa actividad.MODELANDO UNA SOLUCIÓN DE SOFTWARE 141 SI campo existencia ES MENOR O IGUAL QUE campo nivel mínimo. 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. quienes pueden acceder a técnicas y herramientas que les simplificarán su labor. Pruebas del software por el programador Un concepto que aporta el método es probar al tiempo que se construye por el mismo programador. la dificultad disminuye proporcionalmente al tamaño de los programas. además de mucha más destreza. señaló. que su función era codificar. En resumen. Sobre todo. 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. como al construir un edificio. exaltado. En gran medida.500 líneas requiere varios días. era para alguien de inferior categoría… . ENTONCES emitir orden de compra. Lo primero lo puede hacer en pocos días. porque impactan aspectos sicológicos y de ordenamiento del programa que hacen muy difícil el trabajo en un programa grande. Para mantener el código. el mismo cambio en un programa de 1. Explicó. esta deficiencia se producía por la separación en dos etapas del proceso codificar-probar47. Esto. modelar bien. no probar el resultado de las rutinas. que construir un programa de 1500 líneas de código. 5. No es lo mismo escribir 50 reglas del negocio de 30 líneas cada una. donde podemos apreciar que se va probando inmediatamente lo construido. 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 construir. por ejemplo. en tanto que para lo segundo requerirá de varias semanas. tarea destinada a especialistas en informática. señalarle por escrito los errores y entonces él procedía a efectuar las correcciones que luego seguían el mismo ciclo. Aunque en ambos casos debe actuar un especialista. en las aplicaciones complejas sigue existiendo la necesidad de aportar código. Es que probar es más que verificar la efectividad de una programa de computador.

la cual postula que una predicción puede tener una alta probabilidad de certeza solamente en el corto plazo. porque depende de pequeños cambios en las condiciones iniciales que hoy día nos parecen insospechadas… por ejemplo: se fue un empleado clave.142 JUAN BRAVO C. .. Luego. Esto significa que la planificación debe agregar la condición de reformulación permanente. porque las variables ambientales se movían más lentamente. Respecto a pruebas con altos volúmenes de datos. porque se trabaja construyendo un prototipo que se va transformando poco a poco en la aplicación final. el cual comienza en el momento de terminar la implementa48 Cuando comenzó la computación este replanteamiento no era tan indispensable. aunque en la forma de un piloto. Podrían llegar a ser tan simples como ensayar con datos de prueba o equivalentes a un paralelo. lo que es equivalente a tener la aplicación en funcionamiento normal. esa alta probabilidad de ocurrencia significa sólo algunas semanas. Cualquiera estimación de años. es prácticamente inútil. de ahí la palabra “caos”. sobre mantenimiento de la solución de software. la dinámica del medio y de la propia empresa48 hacen que todo sistema esté en permanente mejoramiento. nuevos métodos y herramientas con una velocidad sorprendente. el dueño de la empresa tuvo un conflicto matrimonial. se enfermó el gerente de finanzas. tema que veremos más extensamente en el siguiente punto. Es indispensable comenzar a aplicar al desarrollo de aplicaciones el concepto de mejora continua. tal como vimos en la etapa de implementación del método. irreemplazables en aplicaciones grandes. verificar si se cumplen los requerimientos actualizados. 6. lanzamos un producto menor con un éxito sin precedentes. La creciente competencia obliga a mantener un muy alto nivel de flexibilidad y de adaptación a todo tipo de cambios. a través de perfeccionamientos sucesivos. aparecen productos diferentes.. también se cuenta con apoyo semiautomático. Mantenimiento de la solución de software Cada vez en mayor medida. la palabra mantenimiento está siendo reemplazada por perfeccionamiento en el contexto de la tecnología de información. porque ya se está haciendo general que las herramientas CASE provean generadores de datos de prueba. Hoy. Existe amplia flexibilidad para la realización de las pruebas. En el ambiente organizacional. Las herramientas CASE apoyarían la verificación de consistencia y documentación. Las últimas pruebas son en ambiente real. Entonces. mientras que en el mediano y largo plazo la predicción no tiene ninguna validez y se obtendrá un comportamiento errático. Porque el problema inicial podría haber variado mientras se diseñaba o programaba. Este es el contexto de la teoría del caos. desde el principio hay que mantener intacta la capacidad de desarrollo continuo de una aplicación. Estados Unidos aumentó su tasa de interés.

evitando juntar todas las pruebas para el final. • Búsqueda de programas. • Pruebas. de integración del proyecto. ojalá con el apoyo de alguna herramienta de productividad. También debiera disponerse de apropiados recursos de hardware y software. Sabemos que este período es de alto nivel de cambios. • Un alto grado de participación y compromiso del usuario.MODELANDO UNA SOLUCIÓN DE SOFTWARE 143 ción y aun dentro del período de garantía que todo sistema computacional debe tener. los principales esfuerzos de mantenimiento se destinan a: • Modificación o reconstrucción de programas. Ahora el mantenimiento del sistema significa realizar cambios sobre el diseño. entre otras cosas: • Disponer de documentación actualizada en todo momento. 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. es de simple responsabilidad estar preparados… Hablar sobre desarrollo continuo de un sistema computacional significa. En una instalación tradicional. de regeneración de estructuras frente a cambios. Es un tiempo convenido. la especificación o las reglas del negocio y rehacer parte de la aplicación con la ayuda de alguna herramienta de desarrollo. bibliotecas y documentación. • Generar automáticamente o usar código reutilizable en un alto porcentaje de la aplicación. Aquí hay una diferencia notable respecto al método tradicional. en el cual. . versiones de programas y cambios en repositorios de datos. El período de garantía es el equivalente a la marcha blanca del desarrollo tradicional de sistemas. • Actualización de documentación. ojalá los mismos que se emplearon durante la construcción. • Reentrenamiento. • Ordenamiento de manuales. En esto puede ayudar la técnica de desarrollo en espiral que se presenta en el anexo 3. • Resolver en forma automática los problemas de consistencia. al igual que un edificio o un nuevo artículo. • Ir probando cada estructura o función que se construye. por lo tanto.

Sin pretender profundizar en esta materia. esto es. la operación regular de la aplicación destinada a satisfacer el requerimiento para el cual fue construida. 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 . Se estima que este solo concepto permite elevar la productividad de los especialistas en un departamento de sistemas al menos en 100 %. Junto con el mantenimiento de un sistema computacional se realiza su explotación. porque unos dos tercios de las actividades regulares de los centros de computación están destinadas a mantenimiento.144 JUAN BRAVO C.

Diseño lógico: su objetivo es determinar qué se requiere. Diseño estructurado 4. Ciclo de vida clásico 2. 3. apunta hacia el desarrollo administrativo de la alternativa seleccionada. se analiza este método en todo detalle.5.MODELANDO UNA SOLUCIÓN DE SOFTWARE 145 2. 2. .. debido a su importancia. • 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. les dedicamos los capítulos 5 y 6. la cual apoya especialmente las etapas de ingeniería y diseño y el diseño estructurado. la técnica de prototipos. 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. Todos han tenido su cuota de contribución en las definiciones que estamos logrando. se presentan algunos ejemplos de métodos de apoyo: el ciclo de vida clásico. principalmente en 49 En el libro Desarrollo de sistemas de información. Generalmente se han clasificado en dos grandes grupos: • Sobre la gestión del proyecto: donde se proponen métodos para planificación y control del proyecto de software. Veremos: 1.Diagnóstico: su objetivo es identificar el problema y situarlo en su medio. que abarca todas las etapas del desarrollo de sistemas. Consta de las siguientes etapas: 1.. una visión práctica. Programación extrema (XP) 1.. En lo que sigue. MÉTODOS PARA LA PRODUCCIÓN DE SOFTWARE Los métodos de desarrollo apuntan a “cómo” construir técnicamente el software.Factibilidad: su objetivo es plantear y evaluar alternativas de solución al problema identificado. Técnica de prototipos 3. diseño o implementación. representa un todo armonioso dirigido al desarrollo de sistemas de información49. No se incluye aquí la orientación a objetos ni UML porque.

• Aplicaciones poco flexibles.Mantención: su objetivo es dar respuesta a cambios sobre el sistema después de su implementación.. 6. la etapa de implementación viene seguida de una redefinición de requerimientos y de un nuevo proceso de desarrollo. La demora en los ciclos de desarrollo provoca una desactualización de los requerimientos iniciales. 4. diseño de funciones. se definen los conjuntos de datos. • Especificaciones poco adaptadas a la realidad. e invisibles. de usuarios que aún no comunican ese requerimiento. cuanto a departamentalización.146 JUAN BRAVO C. Estas siete etapas del ciclo de vida clásico se aplican en la modalidad tipo cascada. retardándose excesivamente la etapa de explotación. producción de la documentación del sistema. 7. prácticamente cada especialista tiene su propia forma de desarrollar sistemas.Implementación: su objetivo es la puesta en marcha del sistema mediante pruebas generales.. . justamente por el excesivo tiempo de respuesta del área de informática. que están en la planificación de actividades. flujos de información. entrenamiento de las personas. Así. diseño del sistema de codificación y diseño del modelo de datos (modelo de información).Programación: su objetivo es construir y probar los programas especificados en la etapa de diseño físico. poblamiento de las bases de datos y procesamiento en paralelo. es decir. diseño de formularios.. la organización del sistema y se especifican los programas. definición de los procesos del negocio. organización general. • Largas colas de espera de aplicaciones por desarrollar: visibles. • Dificultad de comunicación entre especialistas y usuarios. 5. • Aplicación anárquica del método.Diseño físico: su objetivo es el diseño computacional del sistema.. 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. Se estima que esta tarea consume tanto tiempo y recursos como unas tres veces todas las etapas anteriores (con el riesgo de que se eternice).

los cuales seleccionaban secretamente a los futuros miembros y los “iniciaban” en los secretos del oficio. Si ya se requiere un gran esfuerzo de formación para el desempeño de tareas netamente intelectuales. También complementa algunos métodos de diseño con excelentes resultados. entonces. se construye un producto concreto que se perfecciona mediante aproximaciones sucesivas realizadas en múltiples contactos de prueba con la realidad.MODELANDO UNA SOLUCIÓN DE SOFTWARE 147 Y sin considerar los problemas de la mantención y documentación. donde se utiliza mucha simbología (escritura y cálculos) y un cierto nivel de abstracción. Técnica de prototipos La idea del prototipo de un sistema computacional es la misma que el prototipo de un avión o de un automóvil: a partir de una idea original. 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. como el trabajo administrativo. La técnica de prototipos es una ayuda en cualquier etapa del ciclo de desarrollo. porque permite aclarar un problema o visualizar una solución. aunque al principio (desde los años 60) era sólo para “iniciados” siendo muy escasa su difusión. 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. . Aunque es posible aplicar desarrollo en espiral. 2. tedioso e inútil. El ciclo de vida clásico ayuda a resolver esta situación. porque así se ha hecho siempre. En el mismo período. ¿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. porque los requerimientos quedarán incompletos. Pese a lo necesaria que puede resultar para este tipo de tareas. Se utiliza el término “iniciados” haciendo una comparación exagerada con los gremios de la Edad Media. confusos y errados. generalmente el método de ciclo de vida clásico usa el esquema tipo cascada. ¿Por qué debieran enfrentarse usuarios y especialistas a este esfuerzo poco natural? Simplemente por inercia. la capacidad de abstracción no está suficientemente desarrollada en el ser humano. 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.

pensar una solución.148 JUAN BRAVO C. escalonado. desarrollarla y probar. Sin embargo. cada error que se produce es una alternativa que se prueba. es decir. ampliamente utilizada en la naturaleza. Un prototipo no es el sistema final. se estima que en unas 4 generaciones ya deberían haberse extinguido totalmente. 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 exhaustiva 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. . a la cuarta generación la población de osos es superior a la que llegó inicialmente. al igual que muchas otras especies). la piel de estos osos es mediana y no está adaptada a los rigores de las bajas temperaturas. Los segundos son específicos y a estos nos referimos principalmente en este punto. por lo tanto. El desarrollo por prototipos tiene su base en la técnica de prueba y error. Existen prototipo evolutivos y de usar y botar. si sirve queda. Así funciona: supóngase que una manada de osos se traslada hasta el Polo Norte50. como cuando llega un nuevo sistema en el cual no han participado. Esta técnica está adaptada a lo natural para el ser humano: tomar decisiones según el método de prueba y error. Los primeros siguen un proceso de avances sucesivos bien controlado que poco a poco van perfilando una solución. en lugar de excesivos estudios y planeamientos. 50 (Esperemos que seamos capaces de detener el calentamiento global para que los osos de este ejemplo conserven su habitat y puedan sobrevivir. 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%. ¿Cómo influye el error en el crecimiento? En la naturaleza. si no sirve se descarta. ¡eso no sucedió!. Se hace esta aclaración porque a veces entran en explotación sistemas incompletos que nacieron como prototipos. quienes no ven alteradas sus rutinas de un momento a otro. pero hay que terminarlo. adaptado a las necesidades reales y no traumático para usuarios. Es importante señalar que en este caso el cambio es suave. Eventualmente un prototipo puede ser la base de un sistema concreto. lo que se puede apreciar a simple vista al observar la adaptación al cambio y el crecimiento de las especies.

. se mueva la curva de normalidad desde piel mediana a piel gruesa. Cuando nacen con piel más gruesa no sólo aumentan sus probabilidades de sobrevivencia. apliquemos esto al grosor de la piel. en los extremos de la curva y equivalente entre sí. Una menor probabilidad. Esto es el método de prueba y error que emplea la naturaleza y es la base para plantear el método de prototipos. además. se da para que nazcan oseznos con piel más delgada o con piel más gruesa. pueden transmitir ese “error” a un mayor número de crías. sino que. producto de una planificación o de un “supercerebro”?… ¡No! Simplemente es otro “error” de la naturaleza que resultó ser apropiado en ese ambiente y aumentaron las probabilidades de supervivencia y de reproducción de los ejemplares que nacieron con el “error” de una piel más gruesa. ¿Por qué? ¿Tal vez la piel se fue haciendo progresivamente más gruesa como respuesta al medio. muy parecida a la de su ascendencia. es decir. lográndose que. independiente del medio. . las probabilidades de sobrevivir en el frío son escasas. Cuando nacen con piel más delgada..MODELANDO UNA SOLUCIÓN DE SOFTWARE 149 pero. 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 generación se da para que la piel de una cría sea “normal”. poco a poco. tal como se muestra en la figura 2-6. la mayoría tiene una característica diferente: su piel es más gruesa que la de los osos de la primera generación. ¿Cómo funciona? Puesto que la naturaleza está siempre cometiendo errores. Población de osos En el Polo Norte Primera generación Cuarta generación Piel delgada Piel normal Piel gruesa Grosor de la piel Figura 2-6.

Así también con los prototipos. el usuario desearía ver un bosquejo de lo que desea antes de hacer una definición en detalle. sin mayores prejuicios. pantallas de ingreso de datos. hace todos los intentos necesarios para cumplirla. de nuestros limitantes “debe ser así”.150 JUAN BRAVO C. • Revisar interfaces visuales: son los más habituales y se confeccionan para repasar el formato. por ejemplo. aún está exenta de nuestros patrones de conducta. teniendo claro los objetivos. Por lo tanto. En las primeras iteraciones con el prototipo se utilizan datos de prueba. Dependiendo de cada problema. las primeras alternativas que practica son las que le proveen de mayor información. Para la mejor comprensión del método de prototipos. el rumbo principal de una aplicación queda definido en las primeras iteraciones con el prototipo. formularios. aunque . proporcionan valiosa información para realizar correcciones y decidir la nueva ruta. para apreciar cómo. el control del stock en un sistema de inventarios o el formulario de liquidación de renta mensual en un sistema de remuneraciones. la presentación y la secuencia de menús. puede observar el juego de un niño. así aprende por cuales caminos seguirá después. Se podrá observar que la forma de seleccionar alternativas que el niño emplea. hasta llegar a trabajar con los datos reales. una vez que se plantea una meta. Cuando el niño ensaya opciones. informes y todo lo relacionado con la interacción con el usuario. aprende de sus errores y no se cuestiona personalmente por cada “fracaso” que tiene. en tal caso. debe estudiarse la real conveniencia de aplicar la técnica de prototipos. cada iteración y especialmente las primeras. Los prototipos se aplican habitualmente a: • Definir requerimientos: significa efectuar una presentación preliminar de formularios y procesos para acotar y aclarar el requerimiento. ojalá menor de 7 años. ella es especialmente útil en problemas administrativos donde cuesta definir todos los requerimientos o los mismos son muy cambiantes. • 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. Generalmente el prototipo es desechado después de cumplir con su objetivo. Puede realizarse entonces una comparación contra el funcionamiento manual del sistema o alguna solución de software anterior. luego se va introduciendo información más consistente. También se puede apreciar la libertad que usa para buscar soluciones a su problema.

porque aun cuando un programa estuviera bien estructurado y documentado. lo más fuerte posible. comenzando por una visión de alto nivel que se va detallando en niveles cada vez más profundos. cuentas corrientes y contabilidad. no son aplicables los prototipos para el desarrollo de sistemas de uso generalizado. 3. eso simplificaría la construcción y la mantención. • Modularidad: significa identificar módulos completos. de un gran programa.MODELANDO UNA SOLUCIÓN DE SOFTWARE 151 esto en la práctica ha resultado difícil. Tampoco estaba bien desarrollado el concepto de modelo de datos. cuentas por cobrar. Supuestamente. tipo top down. en un contexto tecnológico totalmente distinto al que conocemos hoy. • Descomposición funcional: es el concepto detrás de la modularidad. junto con el diseño estructurado se ocupaba la programación estructurada. más precisamente. Estudios sicológicos demostraron que eso es prácticamente imposible. Diseño estructurado El diseño estructurado responde a una visión funcional del sistema. En aquellos días era fundamental la economía de espacio en disco y de memoria. con la mayor independencia entre sí. bien definidos y con las interfaces entre ellos. porque muchas de las facilidades que se obtienen con las herramientas de apoyo no existían antes. Antes. Cada módulo tiene una función precisa sobre una estructura de datos. apenas comenzaba a considerarse en grandes instalaciones. Se sugiere que sea lo más débil posible. Nació en los años 60. Algunos conceptos asociados al diseño estructurado son: • Estructura jerárquica: significa modelar el sistema desde arriba hacia abajo. con la idea de que los módulos definidos a nivel del diseño pudieran ser parte de un programa. Se aplican aquí los siguientes criterios: o Acoplamiento. equivalente a traspasar información entre rutinas. tales como inventarios. Porque el objetivo de la modularidad era incluir una gran cantidad de módulos en cada programa. significa tener funciones atómicas. lo cual . Una característica deseable es que un módulo puede servir a otra aplicación. Es preferible que la empresa adquiera ese tipo de sistemas en el mercado y reserve el desarrollo interno para los sistemas computacionales directamente relacionados con su negocio. que resuelvan solamente una necesidad. • Concurrencia: significa que existen varios procesos que pueden ser activados en forma simultánea. o Cohesión interna del módulo. En general. se aplica en contraposición al sistema secuencial.

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.D.D.152 JUAN BRAVO C.D. Ejemplo de diagrama de contexto En la figura 2-7 el círculo señala el sistema y los rectángulos indican las entidades con las cuales se relaciona.F. 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 cuales proveen o reciben información del sistema. departamentos o personas relacionadas con el sistema. perdiéndose los supuestos beneficios del enfoque51. Las entidades —también llamadas fuentes— son empresas. veremos cada una de ellas. Esta herramienta se divide en dos partes: diagrama de contexto y D. y la mini especificación. El diagrama de contexto muestra la ubicación del sistema respecto al medio donde se encuentra. Las principales herramientas del diseño estructurado son: Diagrama de Flujo de Datos (D. Los flujos de información se muestran con Una experiencia interesante ha sido que el diseño estructurado no obliga a tener programación estructurada.).F.) y mini especificaciones en pseudolenguaje. 51 . nivelado. hasta llegar al nivel elemental o atómico. En la figura 2-7 podemos apreciar un ejemplo: el diagrama de contexto de un sistema de control de stock. Clientes Pedidos y devoluciones Costos Gerencia Niveles Artículos y factura Control de stock Artículos y guía Despacho de artículos Peticiones Proveedores Orden de compra y devoluciones Sala de ventas Figura 2-7. es de por sí casi una utopía. más el D. Diccionario de Datos (D. 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.D. así como la orientación a objetos no obliga a emplear programación orientada al objeto.

nivelado Veamos algunas de las características del D. F. donde la relación entre ambos procesos (1 y 2) se da a través de un almacenamiento o archivo. D. datos y repositorios de datos. nivelado El diagrama de flujo de datos nivelado permite describir un sistema en sus componentes y en su flujo. D. D.MODELANDO UNA SOLUCIÓN DE SOFTWARE 153 líneas rectas continuas terminadas con una cabeza de flecha. D. como el de la figura 2-9. Comienza con un diagrama de nivel 1 o superior. traspasos y Despachar devoluciones Unidades Artículos Figura 2-9. F. Vendrían a ser depósitos de datos temporales o permanentes.D. Datos Datos Datos Proceso Proceso Datos Archivo Figura 2-8. Posee la estructura general que se muestra en la figura 2-8. Estructura general de un D. una o dos barras. se relacionan procesos. la que señala la dirección del flujo. con diferente notación en cada caso. nivelado: • No es necesario volver a indicar las entidades externas. • Los archivos (o tablas) son conjuntos o repositorios de datos. Ejemplo de D. ya que es suficiente con la línea de flujo de datos. F. traspasos y devoluciones 1 Recibir Unidades y costo 2 Ventas.F. Compras. respectivamente. tal como vemos en la siguiente figura: . como una guía de despacho o una factura.

Veamos algunas de sus características: .1.3 recibir traspaso..1. El DFD comienza con un primer grado de abstracción. Archivo = Archivo temporal Archivo = Archivo permanente • Los procesos indican una transformación de los datos para lograr un propósito bien definido.154 JUAN BRAVO C.. es una línea con dirección en la cual se señala un paquete de información conocida. incluye: • Descripción y componentes del flujo de datos.3.2.).1.1. ingresar o despachar. Generalmente. periodicidad.D. prioridades y tipo de procesamiento. 1. 1. Para esto se usa pseudolenguaje. el nombre del proceso es un verbo en modo infinitivo. • Los datos fluyen dentro de un Flujo de Datos (F. • Descripción de repositorios de datos. Si fuera necesario un mayor nivel de detalle. por ejemplo. • Cualquier otra definición. Cada proceso puede generar otros DFD en forma jerárquica. 1. generalmente representado con un dígito. el próximo nivel tendría la numeración: 1. Cada proceso tiene asociado un diccionario de datos (DD) y una mini especificación en pseudolenguaje. • Descripción de las primitivas funcionales (ver mini especificación). el proceso recibir de la figura 2-9 incluiría tres subprocesos en el siguiente nivel: 1.. por ejemplo. características y estructura de datos. como los procesos 1 y 2 de la figura 2-9. 1. tamaño de repositorios de datos. Diccionario de datos El diccionario de datos es el apoyo detallado de los DFD.. y así sucesivamente.1 comprar.2 recibir devolución. respetando la numeración correspondiente según cada estrato de profundidad. el cual es equivalente a español estructurado. en un mismo instante del tiempo (si diferentes datos van en momentos distintos. por ejemplo: frecuencia de un proceso. sería necesario agregar otra línea). Mini especificación La mini especificación consiste en detallar lo más fielmente posible la funcionalidad del proceso. . Se les llama niveles elementales a los últimos niveles de descomposición.

la descomposición funcional que provee. porque el grado de flexibilidad que posee la receta es absolutamente distinto de la rigidez y cuidadosa estructuración del pseudocódigo. Su refinamiento mediante pasos sucesivos. la autodocumentación y la facilidad para efectuar cambios en el modelo han sido vitales para su adopción generalizada en el ambiente profesional. en un nivel inferior. tal como: incrementar. buscar. La programación extrema es más bien un concepto que lleva al extremo las mejores prácticas del desarrollo. usando el estilo jerárquico hacia abajo. XP (Extreme Programming) y es también llamada metodología ágil de desarrollo de software. o top down. No obstante las limitaciones indicadas. durante los noventa se presentaron nuevas versiones refinadas. “como el diseño de una casa” se ha dicho. ¿se imagina si hiciéramos lo mismo con un programa de computador? Los resultados serían aleatorios y el desastre seguro. Incluso. han resultado “duros” para el usuario típico y han desalentado la participación. Significa que cada frase puede ser expandida en un pseudocódigo más detallado. Sin embargo. esos diagramas.D. o nivel del proceso en el D. Programación extrema (XP) La programación extrema es más conocida por su sigla en inglés. la práctica demuestra que esa comparación es un mito. entonces. • Permite reemplazar los diagramas de flujo. • Puede ser utilizada a cualquier nivel de abstracción. mientras. completa y normalizada de modelar la realidad para efectos del desarrollo de un sistema computacional. Se puede aplicar con variados métodos. más el diccionario de datos y la mini especificación. • Se construye el flujo de control del proceso. Una supuesta ventaja del diseño estructurado es la presentación gráfica a través de los DFD’s. el diseño estructurado fue hasta los años 80 prácticamente la única forma coherente. como el Análisis y diseño estructurado mejorado que Edward Yourdon presentara en 1994. .F. sino. También se emplean verbos. 4. Cualquiera de nosotros puede seguir una receta sin mucha rigurosidad y lograr un objetivo más o menos aceptable. 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. repetir. Sin embargo. fin. extraer.MODELANDO UNA SOLUCIÓN DE SOFTWARE 155 • Se ocupan palabras clave: si. generalmente se le compara con una receta de cocina. como muestra de simplicidad y secuencia. Cuando se enseña sobre pseudolenguaje.

aunque todos necesiten ser desarrollados tan rápido como sea posible”. La actividad de escuchar al cliente y otros programadores y analistas es fundamental”. En el fondo. Explican Kendall y Kendall (2005. Cuando estas cuatro variables de control se incluyen de manera apropiada en la planificación. la mejora no será instantánea. y el desarrollo de software no lo es. Además. programación extrema es hacer bien las cosas. Requerirá tiempo y esfuerzo. e incrementar también su productividad. Para evitar caer en la tentación de considerarla una panacea (o bala de plata) veamos lo que dice Steve McConnell (1997. En fin. ese es uno de los mensajes de este libro. . hay consenso en que la receta es trabajar duro y con método. El desarrollo rápido de software es aún menos simple”. el coste. podrá hacerlo sin alterar la calidad.156 JUAN BRAVO C. 122): “Diferentes proyectos tienen diferentes necesidades de desarrollo rápido. la codificación es esencial en cualquier proyecto de software. y no la alcanzará cogiendo simplemente el paquete de la estantería. 68): “Las cuatro variables que un desarrollador de sistemas puede controlar son el tiempo. 4-5): “Si trabaja en una organización normal y sigue los métodos descritos en este libro. pp. Las pruebas de funcionalidad. p. desempeño y conformidad son obligatorias. Podrá reducir significativamente su tiempo de desarrollo. probar. no la obtendrá a partir de una única y nueva herramienta o método. 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. 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. escuchar y diseñar. lo cual es lo que mejor permitirá un desarrollo ágil. la calidad y el alcance. Pero las soluciones simples tienden a funcionar sólo con problemas sencillos. puede que hasta la mitad. Por supuesto. También me gustaría tener cinco millones de dólares. el costo. el rendimiento o la facilidad de mantenimiento. Sin embargo. Hubiera deseado tener una solución sencilla para el problema de la velocidad del desarrollo.

Operación del sistema Entendemos la operación como el conjunto de tareas que permiten el buen funcionamiento de la aplicación. El diseñador del sistema debería conocer algunas tareas técnicas propias de la operació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. Seguridad de la información 5. Contribución del diseño a la protección de la información 4. Integridad de la información 6. Es importante este cambio de concepto. es deseable ejecutar cada proceso de la forma más automática posible.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. 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 . Operación del sistema 2. Recuperación de la información 1. Es sabido que tomando algunas precauciones en la etapa de diseño de la aplicación que luego se implementen. la explotación mejora en mucho. 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. Auditoría computacional 3. fechas u opciones de menú. En sistemas mayores hoy es una labor de conjunto y en sistemas pequeños los usuarios pueden realizar todas las labores. A diferencia de cuando se pretende incorporar ayudas para la operación y auditoría del sistema durante la construcción o en la misma explotación.MODELANDO UNA SOLUCIÓN DE SOFTWARE 157 2. Veremos: 1. realizadas por especialistas y usuarios. evitándose el ingreso de parámetros. Para obtener una aplicación amistosa.

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). cuando. 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 diferentes partes del proceso (por ejemplo. las que podrían disminuir el rendimiento. • • • • procesos. en algunos casos será necesario reconstruir periódicamente la base de datos. Reconstrucción de bases de datos: dependiendo del sistema operativo del computador.158 JUAN BRAVO C.. más allá de los planes de contingencia. Este tipo de tareas no implica particularizar el diseño ni romper la uniformidad. significa preguntarse cómo apoyar la operación. ¿Qué pasa si?. • Organizar el uso de la impresora para economizar papel.. se saturen las líneas o una tabla se dañe. La mayoría de las verificaciones de este tipo podrían haber sido consideradas en el diseño e informadas en forma automática al presentarse diferencias (o un simple “término normal” si todo está bien). para equilibrar la carga del computador. • Estudiar las secuencias de control para evitar duplicidades en procesos u ordenamientos. Esto significa: • Estudiar el tamaño de bases de datos para dimensionar dispositivos. con el fin de reorganizar las claves y recuperar el espacio ocupado por registros eliminados. por ejemplo. el concepto es la continuidad operacional. • Borrar los archivos temporales o tablas intermedias • Dosificar el procesamiento del sistema para evitar las fluctuaciones innecesarias en el uso de procesador. es buscar permanentemente minimizar el uso de recursos. son parte del conjunto de normas del área de informática. se corte la luz. etc… • Evitar la impresión automática de informes. 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. . cumplir con entregas de tipo periódico y por seguridad. número de registros leídos igual a la cantidad de artículos impresos) y que estén de acuerdo con promedios históricos. obtener los informes en el mínimo de tiempo. Uso de recursos: una importante tarea que también podría estar parcialmente incorporada en el diseño.

Además del logro de la normalización. sin que resulte crítico para la instalación. incluyendo la parte administrativa de los sistemas de información que de allí se generan y más en particular. En un esquema de organización centralizada. En un esquema de organización descentralizada.MODELANDO UNA SOLUCIÓN DE SOFTWARE 159 2. en especial. las principales áreas usuarias debieran tener la libertad de desarrollar en forma interna o externa. Es más. A propósito. el auditor computacional debe ubicarse fuera del departamento de sistemas. Auditoría computacional Dado el carácter contralor de la auditoría. en autonomía. respetando la normalización y uniformidad que se haya dado la organización y lo más importante. colaboración y relaciones basadas en confianza. ésta tiene tuición sobre todas las áreas de la empresa. se encarga del control sobre la protección de información. En general. generados en forma independiente de cualquier otro emitido por el área de computación. la auditoría computacional controla toda la gestión del centro de computación. lo cual se podría conseguir con una apropiada difusión de los resultados. fue necesario crear una nueva rama: la auditoría computacional. asegurando y capacitando en el uso de la normativa interna. Para cumplir con su labor contralora. Generalmente el departamento de auditoría computacional es parte de contraloría o auditoría interna. adicionalmente la auditoría computacional apunta a realizar controles sobre cada área computacional de los departamentos usuarios. normalmente en un departamento de auditoría computacional. una administración eficiente también significa resolver el problema de la adaptación al cambio. porque el énfasis debiera ser puesto en el desarrollo de las personas. Una de ellas es el área computacional. . las áreas de control de la organización debieran ser pequeñas. a cuya jefatura debe hacer llegar los informes de sus auditorías. todos los interesados de la empresa deberían aprender y beneficiarse con las pruebas. Esto implica dejar espacios para la innovación y para probar otros esquemas. ocupando su propio presupuesto. área que su vez depende directamente del directorio de la compañía. donde. debido a su alto grado de especialización. En esos “espacios de libertad” la auditoría computacional tendrá que ser muy flexible para no ahogar la creatividad.

• Instalaciones físicas. • Seguridad de las instalaciones. Como ya fue indicado. a los siguientes aspectos: • Organización del departamento de sistemas. los cuales agrupan a un conjunto de profesionales de tipo multidisciplinario. • Administración de los profesionales de informática. principalmente en lo que se refiere a funciones incompatibles. por ejemplo: en ciertas organizaciones y para determinados tipos de sistemas un operador no debería ser programador al mismo tiempo. como el comité de informática. • Protección de la información. 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. • Plan de recuperación de desastres. la cual sería prácticamente imposible de realizar manualmente. • Formación de grupos de trabajo. entre otros. • Presupuesto del departamento de sistemas. se pueden efectuar minuciosas revisiones. • Contratación de personas y evaluación de funciones. porque deben ser especialistas en computación y en auditoría interna. Debido a esto. con múltiples programas de apoyo. donde ha desaparecido en gran parte el respaldo manual de los movimientos. inconsistencia evidente desde donde surge la necesidad de entrenar a los auditores en materias computacionales y crear departamentos de auditoría computacional. • Presupuesto de protección. La necesidad de la auditoría computacional es particularmente evidente en instalaciones con sistemas de tiempo real. Pero también la auditoría ha salido beneficiada con el advenimiento de la computación. el centro de computación debe asumir su propio control interno. Los sistemas de tiempo real provocan dificultades insalvables para la auditoría tradicional en el seguimiento de las operaciones. • Entrega de los productos pactados en cada etapa del desarrollo • Implementación de sistemas. • Evaluación de necesidades y selección de equipos. .160 JUAN BRAVO C. como la tarea de verificar la totalidad de la información disponible en el computador respecto de un problema. • Plan general de informática. las posibilidades de la auditoría computacional son muy amplias y los controles alcanzan. • Método de desarrollo de sistemas y controles incorporados. Hoy.

Cuando las sugerencias se realizan sobre un sistema en explotación. es absolutamente exigible esta normalización. Tales controles se aplican de acuerdo a estándares. sus observaciones podrán ser consideradas para su incorporación a nivel del diseño de la aplicación. donde se evalúa el cumplimiento de lo que está detallado en los respectivos procedimientos. mediciones y estimaciones internas. Puede parecer burocrático mantener normas para todo tipo de aspectos que tienen que ver con el desarrollo y la operación de sistemas. una de las labores de la auditoría computacional sería aplicar controles para verificar el correcto cumplimiento de las normas aquí definidas. . son los países más estudiados a nivel mundial por su habilidad en la creación de riqueza. puede cooperar realizando una labor educativa de los colaboradores y de mejora continua de las normas. • Esta documentación y normalización sobre la forma de hacer las cosas se está transformando cada vez más en una exigencia. entonces.. como lo demuestran los siguientes argumentos: • Tanto Japón como Alemania mantienen típicamente esquemas muy normalizados en sus instalaciones y. Las empresas que desean optar a la certificación en las normas ISO 9000 o CMM deben someterse a normas más rigurosas que las que hemos visto aquí. En este sentido. Por ejemplo. el incorporarlas tiene un costo mucho mayor. • En el ámbito de la calidad total. como la cuantificación de riesgos para determinar el costo de cada posible amenaza. De esta manera. Es deseable que el rol del auditor sea de tipo creativo más que punitivo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 161 • Lugar de funcionamiento del departamento de sistemas. 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. Es aparente. ayudando a dar más riqueza al método. • Plan de perfeccionamiento. Una opción es que en todo grupo de desarrollo participe un auditor computacional. Tal como en las auditorías de las normas ISO o CMM.. la cual es cada vez más importante dentro de la estrategia competitiva. • Cumplimiento de las normas acordadas. si todo lo expuesto en los capítulos de este libro fuera aceptado como la metodología de trabajo para un departamento de sistemas. • Rendimiento (evaluación costo/beneficio) del departamento de sistemas y de sus profesionales.

se obtendrá cuál es el costo aproximado de cada riesgo. • Integridad: es un concepto que se refiere a la calidad de la información almacenada. • 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. Para reiniciar el procesamiento se ejecutan programas especiales o los programas originales si tienen mecanismos de recuperación. . • Reiniciación: corresponde a la culminación del restablecimiento. La protección de información abarca la seguridad. cuantificar cada uno de ellos y estimar la probabilidad de ocurrencia en un cierto período. 3. previo a la reanudación del procesamiento normal (determinar la transacción en proceso. Para proteger la información debe hacerse un estudio preciso de todos los posibles riesgos. cuando se pone nuevamente en marcha el sistema después de una “caída”. ya sean accidentales o deliberados. hurto o destrucción de la información. la labor de protección se ha venido haciendo progresivamente más importante. la que debe ser siempre consistente y estar protegida de invalidaciones accidentales o deliberadas. temas inseparables de la labor de diseño. lo que permitirá establecer un presupuesto para el plan de protección. alteración. conocer el “estado” de los registros de maestros. • Restablecimiento: son las operaciones realizadas después de una “caída” del sistema. • Recuperación: es el conjunto de tareas destinadas a poner nuevamente en marcha el sistema una vez que éste se ha “caído”. traer respaldos o reordenar bases de datos). 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 autorizados.162 JUAN BRAVO C. integridad y recuperación de los sistemas. Hoy es indispensable incorporar las condiciones de seguridad que exige el medio. 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úmero de terminales y PC’s en poder de usuarios. • 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. Así. tales como un problema eléctrico o un comando equivocado. ya sea a raíz de fallas o errores.

Para esta identificación existen. toda vez que existan datos reservados. documentos faltantes. a modo de ejemplo. fenómenos externos como un corte de energía eléctrica o errores en la estructuración de lógica. Las causas más comunes de destrucción accidental de la información corresponden a fallas en el hardware. Los dos primeros problemas pueden ser enfrentados con el apoyo de los proveedores y el tercero con la ayuda de herramientas de productividad y mucho. autentificación y de control de acceso. sino otro funcionario infiltrado en el sistema. descuadraturas. lo cual significa demostrar que el usuario es quien dice ser. La investigación subsiguiente demostró que la autorización no la dio él. 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 incendios. Sólo entonces se procede a autentificar su identificación. 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. 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). La primera vez quedó en espera y al segundo intento el ejecutivo dijo sí a un cheque robado y con orden de no pago. mucho orden. máquinas lectoras de tarjetas preimpresas que ayudan a resolver el problema. La seguridad de la información en el computador se puede perder en forma accidental o deliberada.MODELANDO UNA SOLUCIÓN DE SOFTWARE 163 4. • Mecanismos de control de acceso a la información: en este caso los derechos de los usuarios deben quedar explícitamente establecidos. Respecto de los intentos de infiltración deliberada. etc. • Procedimientos administrativos: fugas por errores en el diseño lógico. quien conocía la clave del ejecutivo. • Privacidad de la información: consultar o alterar información privada. 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. por ejemplo. Los mecanismos de mayor uso son: . la principal forma de evitarlos es mediante mecanismos de identificación.

• Verificaciones de consistencia a través de “revalidar” la información en maestros. como la sustitución. protegerlos contra invalidaciones accidentales o deliberadas. • Cerrojos: cada conjunto de datos posee una clave de acceso. Hoy. • Verificación de claves. donde se altera el orden de los caracteres. También es un error la pérdida de información. donde cada elemento especifica el nivel de acceso (lectura. la mayoría de los sistemas administradores de bases de datos traen incorporados estos y otros mecanismos. . grabación o modificación). • Errores: son registros de datos o partes de programas. errores y “caídas del sistema”. 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. de rango de valores. Una falla podría generar errores. donde se reemplazan los caracteres por otros. y la transposición. es decir. dígito verificador y comparación entre campos. conjuntos de datos. • Criptografía: consiste en una serie de operaciones reversibles que cambian el contenido de un registro. • 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. • Matriz de control de acceso: usuario vs. Integridad de la información El problema de integridad es asegurarse que los datos de las tablas en el computador sean exactos en todo momento.164 JUAN BRAVO C. 5. • Fallas: se presentan por un mal funcionamiento en el hardware o en el software o por una mala operación de las personas. es necesario definir los términos fallas. 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. almacenados o transmitidos en forma incorrecta. Para hacer más comprensible esta descripción. por ejemplo. tipo de datos.

6. al menos. inundación u otros. Es aconsejable mantener un mínimo de 3 juegos de respaldos completos (Abuelo-Padre-Hijo) y uno de ellos fuera de la instalación. se trata de asegurar el respaldo con una revisión diaria automática. Algunas técnicas de respaldo más sofisticadas llegan hasta mantener duplicados del computador original. para incorporar a los maestros las transacciones realizadas desde la fecha del último respaldo. La reconstrucción total es válida no sólo para sistemas batch. 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. previa al funcionamiento normal. sino también para sistemas en línea. Todo esto sin contar las facilidades que hoy proveen los sistemas administradores de bases de datos y la externalización del servicio. Recuperación de la información La recuperación de la información está muy influida por el diseño del sistema. habitualmente una vez por semana y respaldar los movimientos ingresados al sistema en forma diaria. recuperación y de las facilidades de las herramientas de apoyo. o cada ciertas horas si la frecuencia de fallas es alta. En otros casos. el sistema de respaldos consiste en copiar y archivar fuera del equipo toda la información del sistema en forma periódica. La alternativa más habitual de recuperación de información es la reconstrucción total. Para realizar la reconstrucció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. donde se debería tener preparado un programa actualizador. aunque esta posibilidad se encuentra directamente relacionada con el sistema de respaldos utilizado. . tipo batch. sin olvidar que este tema es inseparable de los conceptos de seguridad. Desde un punto de vista práctico. Podría existir recuperación automática en cada función computacional. es la fórmula más sencilla y simple de operar. Los respaldos de transacciones diarias debieran mantenerse. desde la misma fecha del respaldo completo más antiguo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 165 • Verificación de reiniciación. todos ejecutando en paralelo los mismos procesos. para prevenir riesgos de incendio.

DISEÑO DE INTERFACES Actualmente. Gran cantidad del esfuerzo en el desarrollo del software está invertido en el diseño.7. A pesar de esto. Veremos: 1. Diseño de niveles de menús 3. 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. 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 utilizará el software. Debe ser una placentera experiencia de navegación. existe un área que ha sido descuidada hasta el momento: el diseño y construcción de la interfaz del usuario. el usuario se frustrará y se sentirá incómodo cuando tenga que interactuar con el programa. todos los participantes conocerán el mismo entorno y la organización habrá dado un paso más hacia la normalización externa. colores o ventanas. informes y menús: es de importante ayuda trabajar con un prototipo de las interfaces visuales. la mayor parte del esfuerzo de desarrollo se concentra en la interfaz humana de la solución de software. • Preparar el esquema de pantallas según normas: como las del ambiente windows de MICROSOFT u otro. Directrices para el diseño de interfaces humanas 2. Es lo que plantean Cerda y Guzmán (2004. Si ésta es difícil de utilizar. en la construcción de la base de datos y en el código necesario para manipularla. 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. . el cual podría ser desarrollado en paralelo con las fases anteriores de la orientación a objetos. De esta manera. Leyes para lograr una mejor interfaz humana 1. Es fundamental. p. 2. 1): “Si bien la Ingeniería de Software ha mejorado la calidad y confiabilidad del software. Se refiere a definir interfaces intuitivas con íconos. lo único que ve el usuario final es la interfaz. Sin embargo. ayudas en línea. no importará toda la calidad que posea el resto del software. además de las comunicaciones necesarias para que estos datos se puedan accesar.166 JUAN BRAVO C.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 167 • Diseñar las interfaces según el tipo de usuario: empleados o ejecutivos. Si todavía hubiera usuarios con temor a usar el computador. para aprender a tomar. principiantes o expertos. • Ordenamiento de procesos: corresponde a la definición previa de secuencias de procesos. si el diseño de la interfaz no es el adecuado se estará obligando al usuario a aprender a utilizar complejos instrumentos para sacar provecho al software (imagínese que se obligara a los pasajeros de un vuelo a tener conocimientos aeronáuticos para poder abordar un avión)”. informes y diferentes procesos del sistema. los conjuntos de datos serían accesos a los diferentes objetos y las funciones generalizadas permitirían acceder a las consultas. p. ojalá. Gerente de sistemas—. ¿será necesario mantener todavía los manuales? ¿Usted realmente los usa? ¿Están actualizados? A estas alturas sería preferible que los usuarios aprendieran a navegar dentro de buenas ayudas en línea52. baja o alta especialización. • Diseñar la jerarquía de opciones: significa realizar el ordenamiento de opciones según la normalización. Sin embargo. 2): “El usuario quiere utilizar un software que sea lo más simple posible. Diseño de niveles de menús La definición de diferentes niveles de menús es un importante componente de la interfaz humana. tal como se aprecia en la figura 2-10. Una primera aproximación podría ser considerar cada menú como una clase que representa a todo el diseño. 52 . en un ambiente donde la tecnología computacional está ya totalmente consolidada. por ejemplo: incorporar primero las opciones de uso más frecuente ordenadas según la secuencia de ejecución de tareas. En este caso. les pide jugar al buscaminas para aprender a posicionar el mouse en un punto y luego al solitario. generalmente agrupados bajo una opción de menú. No le interesa entender el por qué del funcionamiento si no solamente cómo lo debe utilizar para sacarle provecho. no sea necesaria la existencia de los manuales. “La idea es simple” asegura Gerardo Cerda (2002. 2. • Ayudas en línea eficientes: de tal forma que. Ambos juegos vienen incluidos en el sistema operativo Windows. un amigo —Rolf Achterberg. Estamos a fines de la primera década del 2000. agruparlas de 3 en 3 y con una profundidad de no más de tres niveles en la jerarquía de opciones. mover y soltar.

pp. • 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. uso masivo de la voz e interfaces inteligentes que pueden anticiparse a algunos requerimientos del usuario. la fecha del registro debe ser propuesta por el software y el usuario solo la confirma. Para la misma situación aparecen mensajes diferentes o a la inversa. los autores presentan sus recomendaciones en la forma de “leyes”. Menú Conjuntos de datos Funciones generalizadas Figura 2-10. para presentar una ruta de acceso expedita cuando hay un requerimiento frecuente. A modo de ejemplo. los cual aportarían “inteligencia”. Para darle énfasis. Leyes para lograr una mejor interfaz humana Este punto es un extracto del artículo ya citado de Cerda y Guzmán (2004. • Ley 4: El mínimo esfuerzo: el usuario de la interfaz solo debe digitar el mínimo indispensable. En caso de que sea . lápices con microprocesador que reemplazarían al teclado. para situaciones distintas se utiliza el mismo mensaje. • Ley 2: Retroalimentar convenientemente a los usuarios: se debe partir del supuesto que los usuarios se equivocarán (aún los más expertos). Todo esto incrementará la tendencia hacia el perfeccionamiento de la interfaz humana. por ejemplo. 3. Por este motivo los mensajes del software deben ser lo más claros posibles (evitando la costumbre de poner la palabra ERROR). Una promesa que puede ayudar más adelante serán las pantallas con visión tridimensional. Definición de menús como una clase Cada clase tendría también objetos menús. 3-9).168 JUAN BRAVO C. denominados agentes. • Ley 3: Mantener un estilo definido: cuando un software ha sido hecho por distintas personas el usuario se da fácilmente cuenta. En este sentido resulta muy importante mantener un estilo gráfico consistente. tal como avisar las actividades del día.

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. que permite al producto o servicio impactar e influenciar directamente sobre la productividad. y con ello. on y off line. Con respecto a los mensajes. Ley 8: Personalización. es decir que no toque la interfaz personalizada. concepto orientado a la programación de los entornos gráficos. los captions de los botones. este término es más conocido como “Look and Feel”. Ley 9: Usabilidad. 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 responsabilidad. que cumpla con “No tocar”: se refiere a que el programa no cambie las modificaciones hechas por el usuario. generando así un mínimo porcentaje de error y un alto porcentaje de rendimiento y satisfacción. 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). botones y títulos de las ventanas. que cumpla con la “Intuitividad”: usabilidad es una mezcla entre intuición y facilidad. El ideal es que se brinde toda la funcionalidad “a un click de distancia”. Además es importante recordar de que los programadores van a tender siempre a codificar una interfaz que a ellos les sea más cómoda o más fácil de usar. Ley 7: Accesibilidad. rentabilidad y eficiencia de un negocio. en lo posible términos relacionados con el rubro de la organización. . A fin de cuentas es entregarle al usuario la cantidad justa de pasos a seguir para sacar provecho de la interfaz. Entonces. Es demasiado fácil asumir que otra persona en el equipo de desarrollo solucionará cualquier dificultad de interfaz que surja. tales como JAVA. ¿qué mejor si es el usuario quien define como verá sus aplicaciones? Obviamente no podrá tener acceso a las partes preestablecidas o inalterables. esto es: trabajar en un entorno grato y conocido. lo ideal es que se usen tecnicismos acorde con el ambiente en el cual se va a insertar el sistema. 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. Ahora bien. La opción de impresión debiera tener en forma predefinida el papel y la calidad de impresión que se utilizan más frecuentemente. Con esto se avanza un paso más en entregar lo que el usuario desea.MODELANDO UNA SOLUCIÓN DE SOFTWARE 169 • • • • • necesario la cambia por otra digitándola. la experiencia de usuario en general.

ISO 9000 y/o Tick IT. Más que nada para presentarlas y apreciar estudios que es necesario realizar. de la implementación y muchos otros. muchas compañías de éxito en la India53 se han adherido a una o más de estas normas). ISO 9000 5. API’s y MDA. Tick IT 6. tales como: CMM del SEI. donde hasta 1998 se habían certificado 89 de las 250 compañías “top” en la producción de software . p. Luego (ibid. de la certificación a veces. CMM 4. MDA 3. Se revisarán brevemente las normas CMM.170 JUAN BRAVO C. el 10%. 2. 139) se precisa que la certificación es según normas reconocidas internacionalmente. Corba 2. 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. p. 140) se aprecia el impacto de tecnologías como CMM en la India. Veremos propuestas de la OMG tales como Corba. 53 . 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. otras 136 estaban en proceso de certificarse y sólo 25 compañías. no tenía planes al respecto. Un aspecto común a las normas y estándares es el costo: del aprendizaje. Veremos: 1. SOA En OECD (2000.8. ITIL 7. Revisaremos también algunas normas de calidad desde las cuales aprender buenas prácticas. de la infraestructura. ISO 9000 y Tick IT (como ejemplo.

El aporte del concepto MDA es que el traspaso entre modelos conceptuales y físicos se pueda llevar a cabo utilizando herramientas automatizadas. 55 API (del inglés Application Programming Interface. En la misma línea del modelamiento visual del software (UML. siguiendo a su vez otros estándares de la OMG. Corba CORBA (Common Object Request Broker Architecture. MDA MDA (Model-Driven Architecture. También permite agregar funcionalidad para seguridad. se definen nuevos modelos que se acercan cada vez más a la implementación en la plataforma correspondiente. lo veremos en el capítulo 6). OMG. arquitectura común de intermediarios en requerimientos a objetos). en español. Luego. arquitectura guiada por modelos) es una propuesta de la OMG que proporciona un conjunto de guías para crear especificaciones en la forma de modelos. Se establecen las APIs55 y las comunicaciones que permitan interactuar a varias aplicaciones (consideradas como componentes. comentaremos acerca de esta organización en el capítulo 5 (orientación a objetos). en español. permitiendo su uso mediante el protocolo de comunicación. 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. en español es el grupo de administración de objetos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 171 1. 54 . CORBA es otro producto del Object Management Group (OMG)54. CORBA “empaqueta” la aplicación en un componente que conoce las funciones que puede utilizar y cómo se accede a ellas. 2. los cuales pueden haber sido construidos en plataformas distintas). bitácora de uso y otras. La idea con MDA es que los modelos que representan la funcionalidad del sistema sean independientes de la plataforma en que se implementará. 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. en español.

producido conforme a plazos y dentro de un presupuesto. traducido como “Modelo de Madurez de Capacidades”. 3. Se trabaja “apagando incendios” con esfuerzos heroicos. Incorpora todo un sistema de mediciones a la madurez de la organización respecto de las capacidades del desarrollo de software. La misión del SEI es: Promover y avanzar en la práctica de la Ingeniería de Software. Nivel Inicial (Initial): por omisión todas las empresas están en esta categoría. porque el software de calidad.172 JUAN BRAVO C. CMM surgió en 1993 de una iniciativa del Software Engineering Institute (SEI)56. CMM provee un detalle exhaustivo de cada nivel de madurez y no es difícil de interpretar. existen técnicas y normas comunes. Existe inmadurez en el desarrollo. Cumple esta misión promoviendo la evolución de la 56 . Aquí se describe la pseudoanarquía presente en el desarrollo. Nivel Gestionado (Managed): los procesos están bajo un nivel de control donde la predicción de plazos y costos es posible. Nivel de optimización (Optimizing): se incorpora el mejoramiento continuo de los procesos. Nivel Repetible (Repeatable): en este nivel el proceso se puede repetir. por intermedio de la Oficina del Subsecretario de Defensa para la Adquisición. fue adjudicado por licitación pública a la Universidad Carnegie Mellon en Diciembre de 1984. No existe visibilidad acerca del proceso de desarrollo ni de los resultados del producto de software (tiempos. 4. es un componente crítico para los sistemas de defensa de Estados Unidos. 2. 5. plazos y funcionalidad en los procesos. estandarizado e integrado. hay seguimiento de costos. es la norma preferida en el desarrollo de software. El Software Engineering Institute (SEI) es un Centro de investigación y desarrollo — financiado con fondos federales— patrocinado por el Departamento de Defensa de Estados Unidos. lo cual facilita los procesos de evaluación. Tecnología y Logística. Los niveles de madurez que señala CMM son cinco: 1. El contrato del SEI para la investigación aplicada en el tema de la metodología de software. Nivel Definido (Defined): el proceso de desarrollo de software está documentado. Tiene niveles cada vez más exigentes que la organización candidata debe ir certificando. costos o errores). El proceso de desarrollo es prácticamente inexistente. CMM CMM (Capabilitiy Maturity Model). con toda una historia anterior que incluyó estudiar una amplia cantidad de compañías de éxito en el desarrollo de software. 3.

En estas nuevas normas la gestión de calidad tiene un enfoque más integral y sistémico y se incorpora la mejora continua. Tick IT Surgió en Gran Bretaña por las carencias que se detectaron en las normas ISO 9000 orientadas a la industria del software. así como su gestión. ISO 9000 ISO corresponde a la Organización Internacional de Estandarización. Incluso la gestión de procesos fue considerada en la nueva redacción de normas ISO. 5. la principal diferencia con las normas de la versión 1994 es la introducción del concepto de gestión por procesos interrelacionados. tales como difícil interpretación y aplicación. Actualmente el encargado de Tick IT es el DISC. El encargado de realizar los estudios y patrocinar la nueva norma fue el Departamento de Industria y Comercio (DTI: Departament of Trade and Industry). Esta es una ventaja de la aplicación de las normas. vi): “Para que una organización funcione de manera eficaz.MODELANDO UNA SOLUCIÓN DE SOFTWARE 173 4. . junto con la identificación e interacciones de estos procesos. 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. 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. puede denominarse como «enfoque basado en procesos»”. inexistencia de aspectos críticos del desarrollo y de implementar en la forma de un proceso evolutivo. De hecho. Destaca que el sector informático fue uno de los más reacios en adherirse a ellas. oficina dependiente del British Standards Institution (BSI) Standards Division. 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. Dice la nueva Norma ISO 9001:2000 (p. Típicamente. 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. La serie de normas ISO 9000 son bastante conocidas. su amplitud. en las denominadas normas ISO 9001:2000. Un punto de encuentro se está produciendo con la masiva incorporación de la gestión de procesos al desarrollo de software.

6. especificando las inspecciones. integración interna. 2. Todo surge de los bajos estándares de servicios TI en el Reino Unido (similares a los de otras latitudes). control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de problemas potenciales. Planeación. Establecer políticas y objetivos de calidad generales de la organización que sirvan para alinearla en todas sus actividades. principalmente los que se refieren a los servicios a usuarios durante la etapa de operación (más del 80% del total). información de gestión. revisiones y pruebas requeridas durante el desarrollo. la cual poco a poco ha ido ganando terreno como referente en el campo de los servicios TI. . ITIL ITIL (Information Technology Infrastructure Library) se traduce como “Biblioteca de Infraestructura de Tecnologías de Información”. control de calidad. Así es que se encargó al CCTA (Central Comunications and Telecom Agency) una propuesta. 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 calidad de los servicios TI: existencia de pre-requisitos mínimos. capacidad de proceso. Planeación de la calidad del proyecto. Análisis y especificación de los requerimientos del sistema asegurando que sean revisados y acordados con el cliente. Implantar y mantener un sistema de aseguramiento de calidad. integración interna e interfaz. 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. 5. productos. procedimientos y políticas específicas. El objetivo es la mejora en la atención de los clientes y usuarios y la reducción de costos y riesgos. La respuesta fue ITIL. intento de gestión.174 JUAN BRAVO C. 3. 6. 4.

Al evitar construir de nuevo los servicios. tal como en la orientación a objetos. También se enfatiza la reusabilidad y que los equipos de trabajo se mentalicen en esta línea de compartir. principalmente en el mundo virtual (webservices). es posible aprovecharlos en el diseño de nuevos procesos de negocios. arquitectura orientada a los servicios) es más un concepto que una herramienta porque su objetivo principal es aprovechar las funcionalidades de aplicaciones computacionales antiguas sin necesidad de intervenirlas. se economiza tiempo y dinero. es posible aplicar SOA mediante cualquier tecnología basada en servicios. Al conocer y dejar disponibles los servicios que otorgan. 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. hardware y documentación. requiere las mismas formalidades que el desarrollo tradicional en cuanto a planificación. SOA SOA (Service Oriented Architecture. calidad y uso de método. La aplicación de SOA permite “recuperar” para su uso global sistemas creados con cualquier lenguaje y tecnología. 7. incluyendo su estado y relaciones. Al igual que la orientación a objetos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 175 Son propuestas de amplio sentido común. tal como la de administrar una base de datos de elementos de configuración: software. en cualquier lugar. Sobre todo. en español. Por supuesto. orientación a objetos). se facilita el intercambio de información y se hace más factible la externalización. base a su vez del análisis de incidencias y problemas. Está de lleno en dos aspectos esenciales de los nuevos modelos: la integración y la modularidad en la forma de componentes. Se logra “empaquetándolas” y relacionándose con ellas en términos de entradas y salidas. Además. Es una mirada amplia desde los procesos de negocios que facilitan esas aplicaciones. . se reducen errores al evitar reinventar innecesariamente la rueda.

176 JUAN BRAVO C. CAPÍTULO 3. TEORÍA DE MODELOS APLICADA .

ORIENTACIÓN A OBJETOS CAPÍTULO 4. HERRAMIENTAS TI CAPÍTULO 6. UML CAPÍTULO 5. En este caso. TEORÍA DE MODELOS CAPÍTULO 2. INGENIERÍA DE SOFTWARE CAPÍTULO 1. no existen problemas de sistemas que no hayan sido primero del negocio. MODELAMIENTO DE DATOS CAPÍTULO 3. Teoría de modelos aplicada Sin importar el tipo de empresa. p.MODELANDO UNA SOLUCIÓN DE SOFTWARE 177 Capítulo 3. CAPÍTULO 7. en particular el criterio del curso normal de los eventos. 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 . tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). Esta es la tercera competencia considerada para apoyar la elaboración de modelos de una solución de software. 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. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales Los aportes de visión sistémica y de la gestión de procesos. Sería un error distinguir entre problemas del negocio en sí y de sistemas. Senn (1987. el analista trabaja en problemas comerciales. o dicho de otra forma. 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. son claves en esta misión.

1. Variables de entrada Caja Negra Variables de salida Figura 3-1. . Con ellos se pretende obtener un mínimo de base conceptual para el desarrollador. se avanza hacia conocer la información que utiliza. Por ejemplo. tal como se muestra en la figura 3-1. Concepto de caja negra También un sistema de información puede abordarse según el concepto de caja negra. Veremos: 1. hasta identificar los procedimientos y reglas de negocio. entradas y salidas. 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. 3. Comenzando por el entorno. La forma de abordar estos sistemas es observando sus entradas y salidas. no conocemos el comportamiento de la economía. Concepto de homomorfismo 1. utilizando dos conceptos tomados de la teoría de sistemas: caja negra y homomorfismo. 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. Así se puede construir un modelo del sistema que entregue respuestas lo más aproximadas a la realidad. Concepto de caja negra 2. para determinar qué estímulos en las variables de entrada producen cambios en las variables de salida. pero hemos observado que un aumento en la tasa de interés produce menor actividad en la economía o que un tipo de cambio alto incentiva las exportaciones.178 JUAN BRAVO C. MARCO TEÓRICO DE LOS MODELOS Se presenta este breve análisis sobre teoría de los modelos.

Concepto de homomorfismo Un homomorfismo es una representación simplificada del objeto real. • El sistema de frenos. el control del stock. En resumen. Un modelo de sistemas es una de las visiones que tienen diferentes personas respecto a un mismo objeto. desde diversos ángulos. También corresponde a los diferentes “puntos de vista” con que una persona intenta reconocer ese objeto. por ejemplo. lo mejor es enfrentar el estudio construyendo diferentes modelos. Primera. porque los diferentes componentes dificultarían una correcta apreciación. • El impacto del roce a diferentes velocidades. por ejemplo. Tal vez sea realizar un estudio sobre las características aerodinámicas del automóvil. por ejemplo. Por ejemplo. • El sistema eléctrico. Incluso. ¿cómo se puede superar la complejidad para estudiar un automóvil? Un mal método sería intentar reconocerlo todo de una vez. diagramas detallados sobre: • La carrocería. los modelos deben construirse de acuerdo con los fines que persigue el diseñador. En los sistemas de información. los modelos que se construyan deben ayudar a ese objetivo. podría construirse rápidamente un prototipo para observar la operación del sistema en función del cumplimiento de ese objetivo. los modelos se construyen para comprender la realidad y efectuar un diseño correcto. Por supuesto. entonces. según el objetivo principal: por ejemplo. las siguientes cuatro perspectivas de un sistema de inventarios. Modelo orientado al objetivo principal del sistema . Las transacciones actúan sobre actualizar el stock de los productos en el inventario. por lo tanto. tal como se aprecia en la figura 3-2. ¿tal vez una fotografía? • La carrocería. deberíamos preguntarnos acerca de la finalidad que perseguimos con este estudio. Este modelo obliga a plantearse cuál es el objetivo vital del sistema.MODELANDO UNA SOLUCIÓN DE SOFTWARE 179 2. sobre: • La apariencia externa. Compras Devoluciones Entradas Traspasos Ventas Control del stock Salidas Devoluciones Traspasos Figura 3-2.

Proveedores Compras Clientes Artículos Ventas Figura 3-3. según la funcionalidad: se establecen. un proveedor puede suministrar varios artículos y un artículo puede ser suministrado por varios proveedores. Segunda. Un cliente puede tener varias ventas y una venta sólo puede tener un cliente. A su vez. Modelo orientado a los datos Tercera. Una venta puede incluir varios artículos y un artículo puede estar presente en varias ventas. las reglas del negocio que vemos en la figura 3-4.180 JUAN BRAVO C. Modelo orientado a las funciones del sistema . Función Ingreso de datos Compras Artículos Función Actualización de compras Reglas Mover último costo Sumar las unidades adquiridas al stock Figura 3-4. por ejemplo. Este modelo cumple una misión parecida a la del diseño estructurado. Las funciones de ingreso y actualización de compras actúan sobre el stock y el costo de los productos en el inventario. Un proveedor puede tener varias compras y una compra sólo puede tener un proveedor. tal como se observa en la figura 3-3. separa las entidades y las funciones. Una compra puede incluir varios artículos y un artículo puede estar presente en varias compras. según el modelo de datos: se modelan los conjuntos de datos del sistema y las relaciones entre ellos. de ahí el sentido de las flechas.

artículos y proveedores. Infinitas visiones de una realidad Para efectos del software.MODELANDO UNA SOLUCIÓN DE SOFTWARE 181 Cuarta. sino que hay solamente visiones subjetivas. funciones y flujo de transacciones. según el flujo de transacciones: se muestra en este modelo que las transacciones “atraviesan” (actualizan) horizontalmente los maestros. la variedad de visiones es tan amplia como la variedad de puntos de vista respecto a una realidad57. Es una matriz con entidades permanentes y transitorias. En la figura 3-6 se muestra este concepto de infinitas visiones que se obtiene como subproducto del concepto de homomorfismo. tal como vemos en la figura 3-5. por ejemplo: ventas del día. Cada uno sirve de diferente manera a los propósitos del diseñador. Modelo de funciones Modelo de datos … … … Prototipo visual Objetivo del sistema Flujo de transacciones Figura 3-6. modelo de datos. En el fondo. por ejemplo: clientes. Abriendo levemente la puerta de la filosofía. distinción más conocida como maestros y transacciones. Maestros Transacciones Clientes Artículos Proveedores Cuentas Contables Historial Ventas Historial Compras Ventas Compras Devolución ventas X X X X X X X X X X X X Figura 3-5. importa consensuar los modelos más adecuados y decidir cuáles serán parte del método que la organización adopte. Modelo orientado al flujo de transacciones Cada modelo representa una visión particular sobre el problema: objetivos. Las transacciones fluyen. Los maestros son los pilares. avalando la afirmación con estudios sicológicos que demuestran que la percepción del entorno es siempre personalizada. compras y devoluciones de ventas. respectivamente. porque tiene que atravesar el filtro de las abstracciones personales obtenidas de nuestras experiencias particulares. 57 . hay quienes plantean que no existe una realidad objetiva.

2. Sin embargo. Las tres dimensiones del diseño En general. 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. Cualquier variación substancial de alguna de ellas provocará un cambio de modelo. Veremos: . Las diferencias no son gratis. Por eso hablamos de las tres dimensiones del diseño. Si la información se requiere procesada al mismo tiempo que se genera el dato —por ejemplo. la cual está directamente relacionada con el modo de procesamiento. Datos Funciones Tiempo de respuesta Figura 3-7. es poco conocido hablar de un cambio en el modelo cuando varía el tiempo de respuesta requerido del sistema. entonces será necesario modificar el diseño. 3. porque mientras más pronto es el tiempo de respuesta. tal como se aprecia en la figura 3-7. 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 tres dimensiones del diseño son: datos. entonces el modo de procesamiento batch-interactivo sería la solución. mayor el tiempo de implementación y el costo sube. tal vez el esquema en línea sea la solución. dar a conocer esa tercera dimensión del diseño. funciones y tiempo de respuesta. más complejo es el diseño. ese es el objetivo de esta sección. Si el requerimiento se puede satisfacer dentro de 24 horas. se entiende que si el modelo de datos sufre cambios notables o si las funciones a realizar con ellos varían significativamente.182 JUAN BRAVO C.

• Informe: se imprimen todos los datos de la entidad de transacción. A muchos usuarios se les vendió el procesamiento en tiempo real sin haber sido una necesidad para ellos. modificar o totalizar datos. En este último tiempo se ha producido una revalorización del procesamiento batch. 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. se elimina la tabla de transacciones del período actualizado (más bien se respalda fuera de línea).MODELANDO UNA SOLUCIÓN DE SOFTWARE 183 1. 2. Podría ser un buen comienzo para usuarios y especialistas principiantes. La actualización de la información es diferida respecto al ingreso. ya sea en el departamento de sistemas o en el punto de generación del dato. ya sea en el departamento de sistemas o en el punto de generación del dato. Batch-Interactivo En este caso los datos se ingresan en forma diferida respecto a su generación. La actualización de la información es simultánea al ingreso. rápido y seguro para el primer prototipo de una aplicación. el área de despacho de una bodega. El objetivo de este informe es revisar manualmente los datos del último período de ingreso. En tiempo real 1. es como volver a la sencillez original. Batch-Interactivo 2. • Actualización: con las transacciones del último período de ingreso se actualizan una o varias tablas para agregar. podrían haber resuelto su problema con información diferida algunas horas e incluso días. Esto trajo como consecuencia un nivel de complejidad y costos innecesariamente altos. Además. Habitualmente los movimientos de un día. En línea 3. la caja de un banco. • Inicialización: después que los datos del último período de ingreso fueron efectivamente actualizados. Por punto de generación del dato entendemos el lugar donde se origina la información: el escritorio de la vendedora que atiende a un cliente. . En línea Se ingresan los datos en forma diferida respecto a su generación. representa un punto de partida fácil.

3. hardware y de comunicación que se requieren. porque implica ingresar y actualizar la información en el momento y desde el lugar donde se genera la transacción.184 JUAN BRAVO C. Este es un método de procesamiento relativamente nuevo y trascendental. es necesario cuantificar los recursos de software. se activan mensajes para realizar las actualizaciones de maestros. . 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. por lo tanto. Aquí la característica principal es que se procesa transacción a transacción. Al terminarse el ingreso de una transacción. Este es el esquema predilecto en Internet. uno de los cuales será un registro de las transacciones del día. o del período de ingreso considerado.

En la organización. de la misma manera como las aguas de un río buscan su cauce natural. Fluidez 2. Independencia de la implementación tecnológica 6. Simplicidad 4. Transacciones presentes 11. Iteración 7. 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.3. portabilidad. Desarrollo incremental 10. Intuición 3. son independientes de la implementación. Armonía entre el modelo y la realidad 1. Por lo tanto. Son 11 claves orientadas a enriquecer los modelos de aplicaciones computacionales.MODELANDO UNA SOLUCIÓN DE SOFTWARE 185 3. Se supone que ellas son conocidas. pero ¡la naturaleza viene en ayuda de la organización! Y ese flujo se desborda y busca sus caminos naturales: ¿cuántos manuales de procedimientos reflejan la realidad? Es fundamental que el diseñador no pretenda forzar la realidad. Veremos: 1. impersonalidad y factibilidad. Orientación al cliente 5. Totalidad 8. Generalización 9. a veces el flujo de datos queda atrapado en una reglamentación obsoleta. sino que la capture lo más fielmente posible en pocos modelos dinámicos. como por ejemplo: abstracción. no hay una indicación en la forma de “pasos a seguir”. Son diferentes a las características universales del diseño de productos y servicios. de algún hardware específico y de las herramientas de software que apoyan el desarrollo. Fluidez El modelamiento del sistema debe mantener abiertos los cauces por donde fluyen libremente los datos de la organización. . flexibilidad. Asimismo. amistosidad.

¡hágale caso a su intuición! Probablemente descubrirá que su percepción era correcta. Es simple. 2.186 JUAN BRAVO C. pp 51-52): “La capacidad para extraer conclusiones a partir de una pequeña selección de datos significativos no es un don exótico. sino de procesos biológicos que recién se comienzan a estudiar científicamente. Es esa sensación de incomodidad. Intuición El modelamiento es una tarea eminentemente creativa. por lo tanto. tal vez algo cambió en la realidad o existe un problema de enfoque que es mejor atender. Es una parte central de lo que significa ser humano. Lo que plantea Gladwell es que esos pocos datos relevantes son simples observaciones de la realidad detectadas con mayor rapidez. la intuición juega un rol preponderante. Lo hacemos siempre que conocemos a una persona o tenemos que entender algo con rapidez o nos encontramos ante una situación nueva. aunque no sea más que durante uno o dos segundos. el subconsciente es bastante más rápido que la reflexión por una cuestión de sobrevivencia. Lo hacemos porque tenemos que hacerlo y llegamos a depender de esa capacidad… en muchas situaciones en las que prestar una atención minuciosa a unos pocos datos reveladores. ¿Qué es la intuición? Hay quienes dicen que es una de las voces de la conciencia. puede darnos muchísima información”. No es quien aplica la técnica más moderna o usa los productos más sofisticados. Si un modelo cumple con todas las reglas. 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 explica bien Malcolm Gladwell en su documentado libro Inteligencia Intuitiva (2006. esas son solamente herramientas que aplican los especialistas. ¿tal vez percibimos que no deberíamos hacer el sistema computacional 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 estamos hablando de algo místico. Esto se puede interpretar como de acuerdo con el sentido común o percepción. de que algo sobra o algo falta en el modelo. pero a usted algo le incomoda. 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. .

porque siempre existe una doble responsabilidad. es circunstancial otorgar un servicio interno. pero es una excelente inversión. sin ser toda la fuente para una toma de decisión consciente. “Simple como un anillo”. la elegancia va de la mano con la simplicidad. ¿Cuál es el cliente del área de RRHH? El Cliente. La simplicidad también se refleja en mantener una solución limpia. 3. lo más importante es cómo ese servicio impactará en el cliente (el negocio de la organización). sobre todo si se trata de personas preparadas que han educado su intuición con información cada vez más relevante. todos en la organización deben estar orientados al cliente (las personas que pagan nuestro sueldo. especialmente el usuario y cuando se siente que es simple. ¿Cuál es el cliente del área de informática? El Cliente. la intuición tiene un rol que jugar en la validación de los modelos. Es más. También se le llama “Visión de procesos”. se podría plantear la siguiente regla: si el modelo se ve complicado.MODELANDO UNA SOLUCIÓN DE SOFTWARE 187 Entonces. aunque sea redundante). Orientación al cliente Desde el punto de vista de proyectos de negocios. Simplicidad Habitualmente. metáfora que sólo agrega confusión cuando algunas personas creen que es suficiente con realizar bien su función). 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. 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. hágalo otra vez. sin particularizaciones para efectos de la implementación tecnológica. lo cual puede llevar esfuerzo. En ambos casos y en muchos otros. no el “cliente interno”. Existe simplicidad en el modelo cuando lo entienden los demás. la función individual y asegurarse que funcione el proceso completo del cual nuestra función es parte. Sólo hay que darse por satisfecho cuando el modelo es y se ve fácil de entender. dice Pablo Neruda en su famoso Poema 15. Por . 4.

Se puede realizar iteración de varias formas. Esto es verdadera educación. buscando en cada nueva “versión” perfeccionar la anterior. antes amarrado a los recursos disponibles en el momento y ahora con libertad para modelar lo más fielmente posible la realidad. Es equivalente a diseñar los edificios con independencia de los tipos de maquinaria o métodos de construcción y por supuesto. 5. para construir prototipos. eso es que cuando no lo hacemos o pretendemos tomar en cuenta sólo nuestro interés. más propios del entorno que de un proyecto específico. Lo único que realmente debiera afectar al modelo son los cambios en la realidad o los requerimientos. Las iteraciones no son infinitas. dentro de parámetros generales de factibilidad técnica y financiera. el modelamiento del sistema debe ser independiente del hardware y del software. Este es un giro trascendental en la forma de visualizar el modelamiento. aplicar desarrollo incremental por módulos o desarrollo en espiral (ver anexo 3). alguna señal nos envía la conciencia. porque podemos apreciar que generalmente las primeras versiones resuelven los aspectos de mayor importancia y las siguientes son perfeccionamientos cada vez menores. Iteración El modelamiento final se obtiene después de varias iteraciones. Más precisamente. 6. porque ambos aspectos son tan dinámicos que podrían variar desde cuando se concibe la aplicación hasta su explotación. 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. tal como se muestra en la figura 3-8. .188 JUAN BRAVO C.

Esto significa buscar el “metaproblema”. Una aplicación es el mapa de necesidades que vimos en el capítulo 1. aquél que representa a todos los problemas del mismo tipo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 189 Figura 3-8. 8. aunque algunas partes sean incorporadas sólo para conservar la visión de conjunto. Así se hace inversión en inteligencia. Totalidad El modelamiento de la aplicación debe considerar todos los elementos. Tener a la vista la totalidad ayuda a comparar y priorizar. sin llegar a un nivel de detalle. apropiadamente planteado. Generalización Cada problema. el uso del diagrama de casos de uso es un buen ejemplo. Esquema de aproximaciones sucesivas 7. porque los nuevos problemas particulares que se vislumbran ya estarán resueltos. La totalidad responde a la necesidad de una visión holística del problema. no es más que un caso particular de un problema general más fácil de resolver. Lo importante es captar completamente la realidad y llevarla al modelo. Desde el punto de vista de la ingeniería de requerimientos. Es un signo de inteligencia no resolver siempre los mismos problemas. .

190 JUAN BRAVO C. general y de la mayor relevancia respecto al problema. En el capítulo cuarto se analiza en detalle. Desarrollo incremental Consiste en dar una solución simple. Por supuesto. por ejemplo. porque. identificar aspectos comunes e inventar clasificaciones. ¿Y las bicicletas. 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. es una plataforma que funciona bien. 10. separar los vehículos de transporte terrestre entre automóviles. por agregación de módulos se va gestando un sistema final personalizado. Esto tiene muy altos costos. Para aplicar generalización es necesario hacer uso intensivo de las técnicas de clasificación. todos los arreglos efectuados a mano no se podrían reproducir 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. 9. si fuera necesario reprocesar a raíz de una “caída del sistema”. ¡bueno!. . Luego. pero el sentido común dará la pauta de hasta adonde llegar. motos. Significa ordenar los elementos con características similares. ¿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 involucrados. éstos van modificando sus datos en la medida que las transacciones los afectan. camiones. trenes y vehículos anfibios? Es una tarea que requiere mucha prolijidad y creatividad. el desarrollo incremental es esencialmente iterativo. por ejemplo. no existe la clasificación perfecta. sin contar con que se transgreden normas elementales de control y auditoría. buses. significa intervenir directamente el resultado en el maestro. camionetas. Por supuesto. porque es necesario descubrir afinidades. incrementar el inventario en dos unidades. por eso es cara y engorrosa esa solución. Transacciones presentes La forma más usual de procesamiento de datos es mediante transacciones que actualizan maestros. 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. Generalmente.

especialmente de una realidad deseada. . Además. la anulación de la factura errónea y su reingreso correcto. ¿qué sucede si la anulación está incorrecta? No se continua con un juego infinito de contra-transacciones. Es lo mismo que el criterio curso normal de los eventos que veremos en la sección 3. Por ejemplo. sino que se hace una transacción de ajuste. Cuando en el modelo se le da importancia desproporcionada a situaciones indeseadas. Es una aplicación de una de las prácticas transversales del método GSP. una transacción presente que revierta la anterior. En Chile se dice: se deja la caída. es como si tácitamente tuviera permiso para dejarse llevar a la situación indeseada.MODELANDO UNA SOLUCIÓN DE SOFTWARE 191 La solución formal y elegante es aplicar una contra-transacción. el efecto es que se aumenta la probabilidad de ocurrencia de esas situaciones. Lo que queremos enfatizar aquí es que esta clave de armonizar el modelo y la realidad aplica a todos los tipos de modelos de la solución de software. sin embargo. Nótese que visualmente se le estaría dando una importancia equivalente a las dos salidas. incluso. lo que estamos modelando es como queremos que sea la realidad. la trazabilidad. la factura versus notas de crédito y débito. por eso los documentos legales no se pueden enmendar y cada uno tiene su opuesto. El efecto psicológico es que cuando un operador del proceso observa el rombo. Ahora. 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. Armonía entre el modelo y la realidad Los modelos son representaciones de la realidad. Esto significa definir el siguiente juego de operaciones: transacción original. en el ejemplo. 11. una ocurre en el 99% de los casos y la otra en el 1%. sin esas situaciones indeseadas. se da una línea continua en el tiempo y nunca se “vuelve al pasado”. Así.6 aplicados en los flujogramas de información y en los casos de uso del lenguaje UML. una situación indeseada es que el producto no se encuentra y esto ocurre en el 1% de los casos. contra-transacción y ajuste. Sí y No. al buscar un producto en una bodega. es un principio contable. La aplicación de transacciones que revierten otras es lo habitual en la realidad. Por ejemplo.

Así es que antes de conocer esta clave. de hecho. En una entrevista a la conocida humorista chilena Gloria Benavides (2006). 58 . Por ejemplo. en Chile se ha hecho costumbre fomentar el uso de lenguaje grosero en la TV. El resultado fue que las ausencias llegaron a un 40% al momento de la prueba. los alumnos interpretaron la bifurcación de no presentarse a la evaluación como una opción válida. Por supuesto. el modelo que ofrece la TV es muy fuerte en este sentido. La cuatro. Al conocer este efecto. En cursos a profesionales en una reconocida universidad. En Estados Unidos. ocurría que al momento de la evaluación siempre faltaba uno o dos alumnos de un grupo de 25. para explicar al curso las acciones en caso que alguien no se presentara a la evaluación. A propósito. en los siguientes cursos se aplicó armonizar el modelo con la realidad y las ausencias para la evaluación volvieron al nivel anterior. Una experiencia del autor. dice: “Me llama la atención el lenguaje que ocupa la gente [en la TV]. dibujó un diagrama de flujo. Aunque no le damos el mismo espacio visual que lo deseado58. Supuestamente la televisión siempre ha enseñado. con rombos. 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”. Como en el criterio normal de los eventos. todo se aclaró. estos son escritos y analizados en los talleres de formación en el proceso. no cerramos los ojos a los eventos indeseados.192 JUAN BRAVO C.

Descomposición funcional El objetivo es identificar funciones computacionales atómicas que actúan sobre una o dos entidades. extracción de información. frenos. actualización. .4. Funciones asociadas a una entidad 4. En ese sentido es “atómica”. incluso. sino que trae una gran base predefinida: motor. cálculos. puede llegar a ser inconveniente o absurdo. Por ejemplo. selección y extracción. MODELAMIENTO DE FUNCIONES Una función computacional da respuesta a un requerimiento de usuarios. La parte pública es generalizada y la parte regla del negocio es propia de la misión de la organización. La idea es tomar como un todo la necesidad del procesamiento de datos y buscar la funcionalidad común que tienen la mayoría de las aplicaciones: ingreso de datos. selección y otras. en funciones asociadas a una entidad tenemos ingreso. El automóvil no se reinventa cada vez. informes. 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. radio. etc. tipo de caja de cambios y colores interiores. Veremos: 1. La función computacional es la mínima unidad que se obtiene al “dividir” un sistema computacional. carrocería. Reglas del negocio 3. Se puede hacer una comparación entre parte pública y regla del negocio con las partes generalizada y opcional de la compra de un automóvil. otro para calcular la valorización y el tercero para acumular el total de unidades vendidas en el día. Adicionalmente. Descomposición funcional 2. más conocida como regla del negocio. se plantean procesos reutilizables.MODELANDO UNA SOLUCIÓN DE SOFTWARE 193 3. es cuando ya no se obtiene beneficio al seguir fraccionando. por ejemplo. Esta situación se da. En dos entidades: actualización. informe y cálculo. sistema eléctrico. Relaciones funcionales entre dos entidades 1. respectivamente. Con esa funcionalidad común. lo cual. Para cumplir su objetivo incluye una parte pública y otra que depende del requerimiento. En el contexto del modelamiento tradicional. existe la posibilidad de efectuar una personalización mediante algunas elecciones: tapiz.

La atomicidad depende del nivel en el cual estamos hablando: en el análisis pueden ser procesos del negocio. casi). Es más preciso entender la descomposición funcional comparando con la forma como se establecen las fronteras de los países en la figura 3-9. definido siguiendo el orden natural de las cosas. eso sería te a la descomposición funcional. bueno. En el caso A las fronteras están definidas considerando dominio cultural. La idea es llevar el concepto de descomposición funcional desde el ámbito de un programa de computador hacia el de un sistema. separaciones naturales (cordilleras. ríos) y mucha negociación. historia. Con las aplicaciones . 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 normalización de datos. Concepto de descomposición funcional En la figura 3-9 queda de manifiesto que cada país es la “unidad atómica” del mapa. supongamos que los países surgen de una división artificial y rápida basada en las coordenadas geográficas (paralelos y meridianos) creando caos y confusión (cualquier similitud la actual situación de África es mera coincidencia.194 JUAN BRAVO C. en el diseño objetos y dentro de un objeto funciones que actúan sobre los datos. 0º 20º 40º Caso A: Separación natural Caso B: División artificial Figura 3-9. ¿Cómo se llega a determinar una función computacional atómica? Aplicando el concepto de descomposición funcional. En el caso B. 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.

Por otra parte. que se activan según las secuencias de procesamiento. Reglas del negocio Cada función incluye reglas del negocio que actúan sobre los campos de las entidades relacionadas. igual debe cuidarse su claridad. tal vez no mayor a 100 líneas. . La idea es que sobre el modelo de datos se sobreponga el modelo de funciones. definiéndose ahora relaciones funcionales entre las entidades. la que permite ejecutar varias funciones en un orden predeterminado.MODELANDO UNA SOLUCIÓN DE SOFTWARE 195 computacionales es similar. es decir: 1 Función atómica = 1 Programa En cada programa. 2. esto depende también del tamaño y complejidad de la aplicación. Para efectos de la ejecución de las funciones. En todo caso. el código fuente aportado por sobre la normalización de la función probablemente sea muy poco. para generar automáticamente los programas. sencillez y elegancia. cada una puede ser simplemente una opción de un menú o parte de una Función mayor. 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 vendidas en el mes. porque la descomposición funcional ubica finalmente “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. por ejemplo. la implementación puede simplificarse con un generador de código que tome directamente los modelos de datos y funciones. Ya lo veremos en el capítulo 7 (Herramientas TI). donde los recuadros indican entidades y las líneas señalan funciones. tal como se muestra en la figura 3-10.

3. Si se trabaja con alguna herramienta.. extracción o selección de información.196 JUAN BRAVO C. modificar y eliminar registros de una entidad. o ambas. la presentación de la pantalla podría ser proporcionada por omisión. Ejemplo de relaciones funcionales Una relación funcional puede corresponder a cualquier función entre dos entidades. Es el caso de la actualizació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 propias.Actualizar saldo de crédito disponible del cliente 3.Actualizar stock de artículos desde ventas 2.Actualizar stock de artículos desde mermas Veremos a continuación algunos tipos de funciones atómicas sobre una y entre dos entidades. sean alteradas. 1 3 Ventas Actualizar stock Actualizar saldo de crédito del cliente Artículos Actualizar stock Mermas 2 Clientes Figura 3-10. con la característica de que una de ellas. También el formato de la pantalla debiera ser proporcionado por omisión y con posibilidades de ser alterado. Funciones asociadas a una entidad Algunos tipos de funciones donde se trabaja con una entidad. son los siguientes: • Ingreso: se realizan las operaciones de consultar... En la figura 3-10 se puede apreciar una secuencia de procesamiento de varias funciones: 1. agregar.

Es el mismo caso en relación a tablas. • Inicialización: es una función que permite crear una entidad antes del ingreso de datos. • Cálculo: se realizan diferentes operaciones sobre algunos campos de una entidad para obtener. por ejemplo. el nombre de cada sucursal. Es una validación relacionada con ese campo específico y no interfiere con la función computacional. campos que se imprimen. que es lo que nos interesa. tablas e índices que permitirán cumplir con las funciones indicadas. encabezado de página y pie de página. para regrabar los índices y ordenar los datos. indicándose: ancho del informe. en este caso. de un determinado número de factura en la entidad “detalle de factura”. Es deseable poder realizar operaciones matemáticas. valorización de stock o corrección monetaria. el maestro de artículos aparece únicamente cuando se activa la funcionalidad asociada al campo código del artículo. Tomemos como ejemplo el ingreso de un artículo en la entidad “detalle de la factura”. ¿Significa esto que hay dos entidades en el ingreso de datos? Sí. saltos de página. de implementación y construcción. la sumatoria de unidades por valor. . es lo mismo que un archivador. el cual tiene que existir para poder guardar documentos. A este nivel solamente hay una entidad: el detalle de la factura. dividir. estadísticas y financieras. Además de las operaciones básicas: sumar. Las asociaciones de campos con su funcionalidad. se aplica una condición de existencia sobre la entidad “maestro de artículos”. promediar y mover valores fijos. pero no a nivel del modelamiento. por ejemplo. es una lista que puede continuar extendiéndose. formato de impresión. Se ha utilizado con éxito esta tipificación en múltiples aplicaciones reales. desde el modelo de datos. ordenamiento. definidas en el diccionario de datos. por ejemplo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 197 • Informe: se obtiene desde una entidad. a nivel físico. definida en el modelo de datos. restar. Una entidad puede tener asociadas. • Cálculo selectivo: significa realizar operaciones entre campos de diferentes registros de una misma entidad. totalizaciones. • Reconstrucción: es una función que permite reconstruir una entidad. otras entidades. multiplicar. al digitarse el código del artículo. para lograr la traducción automática de un código a un texto. servirán para validar condiciones de existencia. presentar la información extraída desde las entidades asociadas o efectuar cálculos. obtener el total neto. No obstante.

porque luego. extracción. veremos que realmente toda función actúa sólo sobre una entidad. como mover o sumar campos. Por lo tanto. en la orientación a objetos. Los registros que se agregarán no deben existir en la entidad de maestro. . Actualización Una entidad de transacción actualiza una entidad de maestro. Si se trata de una actualización donde hay una transacción y dos maestros. por criterios de eficiencia ya obsoletos. para efectuar sobre él operaciones de actualización. Relaciones funcionales entre dos entidades La función computacional atómica se obtiene cuando participan dos entidades (cuando hay más. primero se actualiza un maestro y luego otro. Veremos a continuación algunos tipos de funciones entre dos entidades: actualización. sumar y restar Maestro Figura 3-11. ¿para qué las tres entidades? Tal vez. aplicando el concepto de encapsulamiento. cuando las ventas del día rebajan el stock de los productos vendidos en el maestro de artículos. • 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. por ejemplo. Los registros especificados deben existir previamente en la entidad de maestro. llevar las ventas del día a un historial de transacciones. Esquema de una actualización Generalmente. por ejemplo.198 JUAN BRAVO C. tal como se muestra en la figura 3-11. 4. Nota: La definición de funciones entre dos entidades tiene aquí carácter provisorio. la actualización puede tomar alguna de estas formas: • Sólo se agregan nuevos registros: se llevan registros a la entidad de maestro a partir de los registros de la entidad de transacción. sino que por turnos). Mover clave de maestro Transacción Operaciones entre campos: Mover. selección y mantención. no interactúan todas a la vez. como se explicó en el primer capítulo.

con o sin condiciones Destino Figura 3-13. para luego efectuar sobre él operaciones tales como sumar o multiplicar campos. cada vez que aparece por primera vez una sucursal se crea uno y después se va acumulando sobre ese registro cuando la sucursal aparece otras veces. luego. Clave A Datos solicitados B Figura 3-12. el maestro de totales no tiene registros. si no existe. Por ejemplo. el registro se crea en forma automática con todos sus campos en blanco o en cero. Esquema de una extracción Selección Esta función permite seleccionar información desde una entidad ORIGEN para llevarla a una entidad DESTINO. Extracción Es una función que permite a la entidad A pedir uno o varios datos a la entidad B. cuando se quiere obtener la venta total por sucursal: al principio.MODELANDO UNA SOLUCIÓN DE SOFTWARE 199 • El registro se crea si no existe. Obsérvese que los registros que serán actualizados o agregados podrían existir o no en la entidad de maestro. En la figura 3-12 se muestra el esquema de una extracción. Aquí se busca un registro específico en la entidad B según la clave formada con los campos de la entidad A. tal como se observa en la figura 3-13. de forma similar a trabajar con herramientas tipo QUERY (en relación a consultas no estructuradas sobre la base de datos). Origen Operaciones de mover. 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. donde también deben estar definidos. El traspaso se realiza aplicando condiciones de selección fijas o variables. Esquema de una selección . para extraer uno o varios campos que serán regrabados en la entidad A.

En la selección. la condición: “obtener los artículos con stock < 0” puede ser la opción de un menú. donde se almacenan todos los movimientos. por ejemplo. por ejemplo. Mover clave de maestro Transacción Agregar.200 JUAN BRAVO C. porque es muy posible que la entidad de transacción sea inicializada si el procesamiento fuera de tipo batch-interactivo. etc… Mantención Esta función permite mantener una entidad de maestro a través de transacciones que quedan registradas. refrigeradores. todos los cambios quedan registrados en una entidad histórica de transacciones. evitándose que el usuario ingrese parámetros al ejecutar la aplicación. Una alternativa de mayor flexibilidad y necesaria en estos tiempos. modificar y eliminar registros. el usuario indica el tipo de artículos que desea obtener: lavadoras. Esta función es de fundamental importancia porque muchas veces se hace mantención directa sobre un maestro sin que quede ningún rastro. Esto es importante. Esquema de una mantención Permite agregar. Toma la forma que se muestra en la figura 3-14. . es que los parámetros se almacenen en tablas. Respecto a las condiciones variables. las condiciones fijas debieran quedar incorporadas al programa. evitando que sean parte del código. En este caso. tipo de artículos = ??. modificar o eliminar Maestro Figura 3-14. el usuario ingresa los valores requeridos al momento de la ejecución de la aplicación.

Resolución de problemas simples Siempre es posible dividir un problema complejo en un conjunto de problemas simples.5. También se obtienen algunos subproductos: • Uniformidad. Resolución de problemas simples 2. • Realizar trabajo de grupo con otros colegas y con usuarios. en la actualización se puede encontrar que en la mayoría de los casos se trata de mover. Modelar bien a la primera 3. más aun con el apoyo de las herramientas para la producción de software. algunas son: • Tener un modelo antes de construir. porque los problemas simples tienen la importante característica de ser muy similares entre sí. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 201 3. Concepto de máquinas abstractas 1. si los problemas son simples. FUNDAMENTOS DEL MODELAMIENTO DE FUNCIONES ¿Por qué es modelar las funciones? El modelamiento de funciones tiene bases sólidas. • Tener la posibilidad de aplicar herramientas de productividad o código reutilizable. Es equivalente a preguntar sobre los planos de un edificio. • Economizar mucho tiempo y dinero al resolver gran parte de los problemas en abstracto. donde la extensión y profundidad de los modelos va en directa relación con la envergadura de la obra. antes de llevarlos a la construcción de código. debemos reconocer que cada solución obtenida es un caso particular de un problema general más fácil de resolver. • Simplificar la relación con el usuario al conversar su requerimiento en la forma de modelos. lo cual sería imposible sin un modelo previo. Por ejemplo. entonces automatizar las soluciones es el siguiente paso. Este es un importante principio asociado al concepto de descomposición funcional. Además. Veremos: 1. cada uno de los cuales será más fácil de resolver. sumar o restar campos entre dos entidades. similares y uniformes. • Automatización.

simple. sobre el tema de si los programadores debían usar instrucciones de salto incondicional (GO TO) en los programas. 3. rapidez. buscando modularidad en los programas de computador. De aquí nacieron también los conceptos de la programación estructurada. también importante impulsor de la programación estructurada. Incluso se facilita el indispensable perfeccionamiento continuo que tiene lugar después de la implementación. fue físico teórico y trabajó para Burroughs Corporation en los años 70. 2. Modelar bien a la primera El problema debería ser resuelto con un buen modelo. el Dr. en lugar de tener pocos programas gran- Dijkstra (1930 – 2002). 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). Concepto de máquinas abstractas Este concepto comenzó a aplicarse en los años sesenta. Edsger W. Así. Edsger W. La propuesta de este texto es aplicar el concepto de máquinas abstractas a nivel de la aplicación completa. en Estados Unidos. En 1968.202 JUAN BRAVO C. Uno de los principales investigadores en esta materia fue el Dr. De esta forma se reduce el riesgo de incorporar particularidades difíciles de programar y mantener. Dijkstra envió una carta a la Asociación para máquinas de computación. él define que una máquina abstracta consta de una entrada y una salida. elegante y lo más estándar posible. Así se evita en la implementación hacer correcciones innecesarias. Promovía utilizar estructuras de control en los programas de computador y fue firme partidario de evitar en ellos la instrucción GO TO. con base en el concepto de máquinas abstractas de la teoría de sistemas. parchar o incorporar ingeniosidades. estética o seguridad. Ya sea que se trate de la eficiencia en el espacio. 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 recuperar y disponer de su obra en Internet. Realizó reconocidos aportes a la naciente ciencia de la computación y recibió el Premio Turing en 1972. Sus aportes son tan relevantes. Dijkstra59. Ahí propuso la disciplina de secuenciamiento riguroso para evitar los saltos incondicionales. 59 . porque todo lo necesario quedó resuelto en el modelo.

Algunos beneficios de este enfoque: • Permite reducir el tamaño y la complejidad de los programas. las cuales pueden ser administradas por alguna herramienta apropiada. obtendríamos lo siguiente: 1 Entrada Función Atómica 1 Salida Una función computacional atómica tiene sólo una entrada y una salida. si es que se mantienen intactas las interacciones. es posible reemplazar una función computacional atómica por otra sin afectar al resto del sistema. Está suficientemente demostrado que el nivel de complejidad de un programa aumenta geométricamente respecto a su tamaño.MODELANDO UNA SOLUCIÓN DE SOFTWARE 203 des cada uno con muchos módulos. por lo mismo. administraremos las funciones computacionales atómicas que componen una aplicación en la forma de componentes. hoy de bajo costo en el mercado. sería de gran eficiencia ocupar el código generalizado que ya existe en el mercado en lugar de reinventarlo. fáciles de automatizar y mejorar. Además. aceptar y validar datos— que puede ser aportado con herramientas de productividad o mediante código reutilizable. Entonces. lo cual no tiene que ver con su tamaño. Podemos concluir que la función computacional se compone de una gran cantidad de código generalizado y de alguna porción de reglas del negocio. podemos tener un programa de ingreso de datos de 1000 instrucciones y solamente 100 de ellas corresponder a lógica del negocio propiamente tal. si estamos trabajando para una organización cuya misión no es la informática. Bajo estos conceptos la única preocupación en cuanto a código serían las reglas del negocio. Por ejemplo. 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. A propósito. . • Las interacciones entre las funciones computacionales atómicas son totalmente conocidas y estructuradas. porque lo importante es el código aportado para responder a las reglas del negocio. el resto es estructuración típica de código —manejar pantallas. La implementación de este concepto se cumple a cabalidad cuando un programa responde solamente a una función atómica.

204 JUAN BRAVO C. • 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.

Por ejemplo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 205 3. que ya hemos comentado. Es un tipo de diagrama de flujo de información que proporciona amplia visión acerca de variados aspectos del proceso: flujo. El flujograma de información describe el curso normal de los eventos. 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. estructura y tecnología. no se indica gráficamente qué pasa si no lo aprueba. Relación del FI con la técnica UML 1. La Estructura queda representada por columnas. no se indica que sucede si la rechaza. Aunque menos habitual. Aplicado al flujograma de información El Flujograma de Información (FI) describe y representa una guía de las actividades del proceso. si el manejo de la excepción tiene cierta complejidad. sin darles el mismo espacio visual que el curso normal de los eventos. Se describe el curso normal de los eventos. si se requiere que un supervisor apruebe un documento. Tiene sus raíces en la ley de los pocos críticos de Pareto.6. menos. mensajes. en esto debe existir armonía entre el modelo y la realidad. Por ejemplo. El FI es la secuencia y temporalidad. la rutina. Las Actividades quedan especificadas por cargos o roles. en la nueva generación de flujogramas de información. no se incluyen las excepciones. también llamado el “camino feliz”. La Tecnología se indica en las actividades que tendrán algún nivel de apoyo tecnológico. . donde se describe gráficamente el esquema habitual. Aplicado al flujograma de información 2. Los Mensajes son el medio de comunicación. también se puede construir un modelo especial para ella. comunicaciones electrónicas u orales. señalando las acciones correctas de un proceso o relato. como parte de un texto complementario. La idea general es tratar las excepciones como excepciones. CRITERIO CURSO NORMAL DE LOS EVENTOS El criterio curso normal de los eventos es un nuevo aporte de la teoría de modelos y aplica en varios tipos de modelos. Las excepciones se incluyen aparte. o si un bodeguero debe recibir mercadería. donde lo más habitual aparece más y lo menos. Veremos: 1. pueden ser documentos. Son excepciones a la regularidad del proceso que se narran en hoja anexa. actividades.

entre otras acciones dirigidas a las personas. PROCESO DESPACHO INMEDIATO CLIENTE OE BODEGA ADMINISTRATIVO DE BODEGA FINANZAS DESPACHADOR PROCESOS VENDER Reservar y emitir GD GD4 GD3 GD2 GD1 GD’s Buscar producto GD4 OE Rebajar saldo Cliente recibe y firma recepción GD2’ GD1’ GD3’ PROCESO CUADRAR OE: Orden de Entrega. Lo nuevo es el principio SPPP (Simplificar Procesos y Potenciar Personas). dejando de lado el absurdo intento de preparar flujos “a prueba de tontos”. Ejemplo de flujograma de información despacho inmediato . el flujograma de información deja espacios para que las personas apliquen criterio. Veamos este FI retomando el ejemplo del mapa de procesos del capítulo 1. GD: Guía de Despacho Figura 3-15. Así. lo cual se logra aplicando por un lado el criterio curso normal de los eventos y por otro a través de capacitación. 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. sensibilización y empoderamiento. Los símbolos de uso más habitual se describen en las siguientes páginas.206 JUAN BRAVO C.

En cualquier caso. • Si el despachador no encuentra el producto podría intentar en otra tienda. 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 formularios. El administrativo de la bodega recibe la OE y se asegura que esté disponible en el inventario una cantidad suficiente del producto. Se trata de un local de ventas de artículos de línea blanca con una bodega al fondo de la tienda. paga en el local y recibe una orden de entrega (OE). . quien firma la “recepción conforme”. buscar producto similar y otras posibilidades que se estudian durante el entrenamiento en el proceso. informes o pantallas que muestra el flujo. la cual muestra en la bodega para retirar su producto. Excepciones: • Cuando consulta el administrativo de bodega. consultando en la pantalla del computador. • Rebaja el producto del inventario en el computador. • Si el cliente no está conforme con el producto. según el mapa de procesos presentado en la etapa de análisis del capítulo 1.MODELANDO UNA SOLUCIÓN DE SOFTWARE 207 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. está empoderado para tomar esas decisiones y para compensar al cliente por los retrasos o cambios hasta un cierto monto. entonces derivar al vendedor o jefe de local. 2 y 3 se envían al despachador. si no hay stock del producto derivar al vendedor o al jefe de local. quien: • Busca el producto en la bodega (en la misma guía de despacho se indica la ubicación). • Envía el ejemplar 3 de la GD a finanzas. • Le entrega el producto al cliente. • junto con los ejemplares 1 y 2 de la GD. 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. porque al efectuar la venta debiera haberse hecho una reserva provisoria del producto. El cliente realiza la compra.

es fácil de usar. facilita la comparación con procesos que se realizan en otras organizaciones y estimula la participación. Sin embargo. Hacer flujogramas de información a escala humana significa conocer bien el proceso y a las personas que los realizarán. podemos inferir que se establecieron en condiciones como las descritas”. ¿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. . pp. ayuda a normalizar el trabajo de la organización. ahí están las personas para decidir qué hacer. Por ejemplo. como los rombos típicos de los flujogramas antiguos (del tipo “if then else”. Si encontramos que muchas normas nacionales son insatisfactorias. sirve como capacitación y documentación. Es un acuerdo que todos se comprometen a cumplir mientras se mantenga la normalidad. si sucede esto entonces haga aquello. Esas mismas variantes ayudarán a perfeccionar el diagrama en la medida que se discuten y se hacen rutinarias. 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. porque los flujogramas de información son bastante autoexplicativos en ese aspecto. 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. 57-58): “Las normas y los reglamentos detallados resultan inútiles si son fijados por el estado mayor de la sede e ingenieros especialistas que no conocen la planta y que ignoran los deseos de las personas que tienen que seguirlos. Kaoru Ishikawa (1986. define canales fluidos de información. 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. No incluye condiciones. sin embargo. en consecuencia. Tampoco incluye ciclos iterativos. representadas por un rombo (ver figura 3-16).208 JUAN BRAVO C. si no haga esto otro). Cualquier decisión es una actividad más y tiene como salida el curso normal de los eventos. la complejidad del medio producirá día a día desafíos que no están resueltos en el diagrama. El flujograma de información permite describir en todo detalle un proceso. debe evitarse toda forma de condiciones. 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. tal como dice uno de los pioneros de la gestión de calidad en Japón.

Además. Por otro lado. Está bien. C. Características del Flujograma de Información 1. entonces deja generalmente dos salidas y en la vida real hay muchas más). un flujo digital estricto. se evita volver con una línea hacia arriba. es una u otra forma. es decir. tal como se aprecia en la figura 3-16. así es que en cada paso hay que dejar la posibilidad de que las personas decidan variantes que no consideró el analista que dibujó el flujo (si utilizó rombos. el diagrama de flujo está destinado a la lógica del computador. con todo detalle. sin embargo. depende de la convención que se use en la empresa. por- Es lo habitual. los símbolos y condiciones computacionales tienden a alejar a los potenciales usuarios. 60 . cada “rama” debe ser explorada. Una actividad que se realiza después va más abajo60. Por lo tanto. ocasionalmente la temporalidad se aplica hacia la derecha (como escribimos). si una orden de compra tiene cuatro ejemplares (un original y tres copias). Además. retornos. Es diferente a un flujograma de información. Figura 3-16. es decir. en el diagrama debe indicarse el destino de cada uno de ellos. Diagrama de flujo computacional El diagrama de flujo está orientado a la codificación en un lenguaje computacional (Cobol. loops y otras funciones propias del programa de computador. El flujograma de información es a nivel atómico. con una variedad y riqueza infinitas. así como el flujograma de información está dirigido a personas. así como no podemos retroceder en el tiempo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 209 ¿Por qué? Porque estamos describiendo actividades que realizan seres humanos. Se mantiene la temporalidad. Visual Basic y muchos otros). nunca ambas a la vez en la misma organización. 2. También corresponde al concepto de atomicidad conservar el orden de cada ejemplar de un documento. Por ejemplo. incorpora condiciones.

representada por las columnas que están de fondo.210 JUAN BRAVO C. Lo nuevo es construir flujogramas de información independientes para cada proceso operativo y el mapa de procesos ayuda a ver el todo. sobre todo si se usa papel autocopiativo. en no más de una página. cada uno con su propio FI. Por ejemplo. Símbolos de uso más habitual * actualzar* 2 láminas ppt Actividad manual Se debe usar verbos en infinitivo: “Emitir O/C”. porque se trabaja con procesos operativos. un macroproceso de compras se redujo a cuatro procesos operativos: compra de artículos de oficina. Aunque es válido usar a veces columnas de “observaciones” en los extremos del diagrama. No incluye comentarios. Describe procesos operativos. breves. tal como de aprobación autorizar un crédito o una compra. compra de repuestos de maquinarias y compra de materias primas. Es un diagrama que se va construyendo y perfeccionando a través de borradores sucesivos. 4. En los diagramas antiguos (tipo diagrama de flujo computacional) se hubiera incorporado el macroproceso completo. 6. 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. 5. Es un cuadrado. principalmente en el extremo derecho. Incluye la estructura organizacional. compra de equipos computacionales. Es breve y no incluye conectores. que no es lo mismo recibir el ejemplar “uno” que el ejemplar “tres” del formulario. Es un rectángulo. Llega hasta el nivel de cargos. “Ingresar solicitud”. Actividad Actividad Las actividades que tienen algún componente computacional de interacción computacional se indican con doble línea (a los lados o en todo el borde) Actividad Es una actividad de aprobación. Control . 3. tal como una información al área de auditoría. porque se trata que sea autoexplicativo. Actividad computacional Actividad de control Es una actividad de control.

el cual debiera estar siempre a la vista. otro para intranet o sistemas internos Resultados del Flujograma de información Típicamente. . etc…) @ para Internet. Por ejemplo. tal como una factura. ¿En cuál? Hay que ver el mapa de procesos. 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. Archivo manual Archivo transitorio Formulario Otro proceso Archivo Ambas formas aplican. una orden de compra o una liquidación de sueldo. es una forma de decir que se envió un documento a un proveedor o que la acción sigue en otro proceso. principalmente archivadores y gavetas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 211 Archivo manual permanente Archivo manual transitorio Formulario El triángulo con la punta hacia abajo representa almacenamiento manual permanente de la información. Es toda forma en papel en que los datos fluyen. tipo tambor es más computacional reciente y recomendable. En el anexo 5 se presenta el Método de Acción Rápida (MAR) sobre procesos. las excepciones y el trabajo conjunto con el mapa de procesos. tal como una carpeta con solicitudes de compra en espera de firma por el gerente. 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. planilla. El triángulo con la punta hacia arriba representa almacenamiento manual transitorio. Comunicación Tipo rayo para comunicación electrónica y electrónica símbolos Windows sobre el rayo para más detalle (correo. Indica acciones que están más allá del proceso.

Son los casos de uso correspondientes a los procesos del negocio. darán origen a los casos de uso del sistema computacional. . tomado desde el nombre de la columna del flujograma de información. 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. Relación del FI con la técnica UML Específicamente en la figura 3-17: • El actor es el despachador. • El caso de uso de esta figura es del tipo “alto nivel” porque la descripción es general. 2. Nota: una actividad computacional del FI se transforma en un Caso de Uso de alto nivel Figura 3-17.212 JUAN BRAVO C. las cuales. En el sistema se rebaja el saldo del producto. Actividad del FI Caso de uso de alto nivel Despachador Terminal en Bodega Rebajar Saldo Rebajar saldo 2 Usa el lector de código de barras para leer la etiqueta de cada producto que se vende. puesto en infinitivo porque refleja una acción. • El caso de uso es “Rebajar saldo”. 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. si están debidamente segmentadas según las propuestas del texto.

.MODELANDO UNA SOLUCIÓN DE SOFTWARE 213 • La situación ocurre en el terminal de la bodega. incluyendo los accesorios. 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). tal como el lector de código de barras.

CAPÍTULO 4.214 JUAN BRAVO C. MODELAMIENTO DE DATOS .

En todo caso. UML CAPÍTULO 5. claridad y elegancia son los sellos de los buenos programas. CAPÍTULO 7.MODELANDO UNA SOLUCIÓN DE SOFTWARE 215 Capítulo 4. MODELAMIENTO DE DATOS CAPÍTULO 3. 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. Richard Fairley El modelamiento de datos logra una visión de conjunto de los datos de la aplicación y de su contexto. tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global). INGENIERÍA DE SOFTWARE CAPÍTULO 1. Esta es la cuarta competencia considerada para apoyar la elaboración de modelos de una solución de software. ORIENTACIÓN A OBJETOS CAPÍTULO 4. oscuridad. ingeniosidad y complejidad son indicaciones de un diseño inadecuado y un pensamiento mal orientado. HERRAMIENTAS TI CAPÍTULO 6. Es indispensable que el analista conozca acerca del modelamiento de datos como simple responsabilidad profesional porque es una habilidad básica de su labor. De esta forma. Modelamiento de datos Sencillez. Veremos: • Definiciones sobre el modelo de datos • Criterios básicos de normalización de datos • Enfoque de bases de datos . TEORÍA DE MODELOS CAPÍTULO 2. el aporte de la solución de software será aportar nuevas tablas o modificar las existentes. ubicarse y evitar inconsistencias como la de crear dos veces la misma tabla. permite comprender. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales Es vital la visión de conjunto que provee el modelo conceptual de datos de toda la organización.

Veremos: 1. proveedores. por ejemplo: clientes. 4. Por ejemplo: obtener una lista de los clientes que han adquirido el artículo 2051.101. Disponiendo del modelo de datos completo será posible presentar visiones parciales a los usuarios. facturas de venta. Una entidad es un conjunto de datos coherentes que forman una unidad entre sí. Características estáticas y funcionales de campos 4. Componentes de una entidad Para efectos de facilitar la comprensión de las materias. Tipos de entidades 5.000 Figura 4-1.749. DEFINICIONES SOBRE EL MODELO DE DATOS El modelo de datos consta de entidades y relaciones.1. Relaciones entre entidades 1. Representación de una entidad 2. con el fin de consultar y manipular información.000 700. En la figura 4-1 se puede apreciar que: . tales como entidad.216 JUAN BRAVO C. según sus requerimientos. se han conservado algunas denominaciones tradicionales. RUT del cliente 4. Una relación permite enlazar dos entidades para establecer recorridos que permitan efectuar la navegación automática.201-4 7. Relaciones propias 3.245-6 Fecha de incorporación 10/01/1993 15/02/1993 01/03/1993 Nombre del cliente Juan Pérez Pedro Torres Ximena Kohl Línea de crédito 500. registro y campo. 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 identificación de cada persona u organización para fines tributarios).654-3 10.143.000 900.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 217 • Cada línea corresponde a un registro de la entidad clientes. el nombre del cliente. 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. la . Esta clave debe ser única (no puede repetirse entre un registro y otro). Hoy. también llamada fila. para individualizar cada registro se define una clave de acceso. • 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. Representación gráfica de una entidad En la figura 4-2 se puede apreciar que su clave es el RUT. Nombre del cliente (RP) Rut Clientes Fecha de incorporación Línea de crédito Figura 4-2. que tiene una relación propia por nombre del cliente y que el resto de los campos son fecha de incorporación y línea de crédito. Por ejemplo. aunque también ha sido fuente de muchas dificultades en el modelamiento y en la interacción con el usuario. la línea correspondiente a Juan Pérez. debido a su poca naturalidad. de tal forma que cualquier campo puede ser una relación propia o parte de ella. La entidad también puede representarse con un rectángulo. como el RUT en el ejemplo de la figura 4-1. Por ejemplo: “Fecha de incorporación”. la orientación a objetos. cuando un campo se declara como una llave alterna y permite recorrerla. 2. su clave se anota arriba. Por ejemplo. por ejemplo. compuesta por uno o varios campos. están transformándola poco a poco en sólo una característica opcional. Las RP permiten diferentes accesos a los datos de una entidad. La característica de clave única ha sido uno de los pilares del modelamiento tradicional. También se le llama atributo. Relaciones propias (RP) Las relaciones propias son al interior de la tabla. no sería válido un cliente sin nombre o RUT. algunas bases de datos y herramientas de productividad. Generalmente. • Cada columna corresponde a un campo de la entidad clientes.

Características estáticas y funcionales de campos Cada uno de los campos de una entidad incluye características estáticas y funcionales. . al igual que la identificación de claves. porque por cada relación propia el sistema administrador de bases de datos crea y mantiene nuevas tablas de índices. fecha de incorporación y la línea de crédito en el caso de la figura 4-2. Esto es un avance importante en simplificación que facilita la incorporación del usuario. ciudad. por ejemplo. una característica estática es la fecha de incorporación del cliente con la estructura dd/mm/aaaa. En la figura 4-2. La única limitación en la definición de relaciones propias es la disponibilidad de mayores recursos de hardware. Se podría decir que la RP corresponde a un ordenamiento permanentemente actualizado de los datos. la figura 4-2 podría haber quedado de esta forma: Clientes RUT Nombre del cliente Fecha de incorporación Línea de crédito 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 campo es una relación propia. apoyado por el equipamiento moderno cada vez más poderoso. En el primer caso los campos pueden repetirse y no sirve como una clave identificatoria alternativa. puesto que el contenido de los campos no se repite. 3. Una relación propia puede contener dos o más campos.218 JUAN BRAVO C. está dejándose de lado en la medida que nuevas herramientas de software permiten un manejo automatizado. En una relación propia el contenido de los campos puede ser con o sin duplicado. teléfono. la relación propia puede ser usada como una llave alternativa. Podemos declarar la relación propia por la cual queremos acceder a la información: nombre. En el segundo caso. fecha de incorporación y nombre del cliente. por ejemplo. una característica funcional es validar que los valores posibles para el mes sean sólo entre 1 y 12. La definición de relaciones propias. etc… y esa información estará siempre ordenada.

para verificar rangos (desde-hasta). Esto es parte de la llamada integridad referencial. • Condiciones de existencia. por ejemplo. La lista de valores posibles es una característica del campo y no es necesario definir una función. los cuales pueden ser implementados con estructuración de lógica en la forma de código reutilizable. para despliegue en una ventana al momento del ingreso de datos y como apoyo en múltiples formas de consulta y manipulación de datos. con máscaras a elección: dd/mm/aaaa o mm/dd/aaaa. la mayoría de las bases de datos modernas lo proveen como un parámetro más. Generalmente. rebajar el stock del producto cuando se produce una salida por ventas. desplegar la descripción del artículo. formato de despliegue. Al mismo tiempo debiera ser posible ver otros datos en la entidad de verificación. En la práctica. a cada uno de ellos se asocian características estáticas y funcionales que pueden ser modificadas. • Rutinas de cálculos especiales. secuencias de valores fijos o condiciones entre campos. Tipos de campo Prácticamente todas las herramientas proveen tipos de campo. son pequeñas funciones computacionales también denominadas triggers o reglas del negocio. descripción. Algunos ejemplos de características funcionales son: • Condiciones de validación. como cálculo de dígito verificador y transformación de cantidades a letras. • Fecha: largo de 8 dígitos: 2 para día. tipo. signo. largo. • Alfanumérico: largo 45. Las características funcionales son atributos dinámicos del campo. para verificar la existencia de un registro en otra entidad. • Conjunto de valores posibles. 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. 2 para mes y 4 para año. comentario.MODELANDO UNA SOLUCIÓN DE SOFTWARE 219 Las características estáticas son atributos fijos del campo. por ejemplo: nombre del campo. se refiere a procedimientos que van a modificar el contenido de un campo al cumplirse alguna condición. • Procesos de actualización. sin signo. por ejemplo. dígitos parte entera y decimales. realizar aritmética de fechas: responder a ¿cuántos días hábiles del mes llevamos? sumar o restar un . algunos tipos de campo son: • Numérico: largo 9. por ejemplo.

Formalmente. diferentes máscaras y cálculo de meses de diferencia. • Transacciones: son los conjuntos de datos que “transitan” por la organización y que afectarán las tablas maestras. máscaras y tablas de ponderadores. La funcionalidad asociada a los tipos de campo viene aportada por la respectiva herramienta. • Lista de valores: asocia una conexión a otra tabla donde se encuentra una lista de los valores posibles que puede tomar el campo. compras del día y descuentos en sueldos. Tipos de entidades Prácticamente en todos los casos del procesamiento de datos. ciudades o países. La entidad temporal se utiliza para ordenar y seleccionar datos o realizar cálculos. 4. La relación entre maestros y transacciones da origen a una referencia cruzada. Generalmente se elimina después de ser utilizada. 30 ó 31. más un campo alfanumérico para el dígito verificador. es posible identificar los siguientes tipos de entidades: • Maestro: contiene la información permanente del sistema. • Campo con dígito verificador: 10 dígitos de largo. día de 1 a 28. También puede ser una vista parcial. • Período mensual: largo de cuatro dígitos: 2 para mes y 2 para año. transacciones o de ambos. artículos o empleados. aunque lo habitual es que también sea posible aportar código. según mes y año. Puede ser directamente una copia de algunos de ellos. mes. debiera aceptar diferentes módulos. y efectuar las validaciones típicas: mes de 1 a 12. tal como vimos en el modelo orientado al flujo de transacciones de la sección anterior. Por ejemplo: ventas del día. Algunos ejemplos de entidades de este tipo son: proveedores. 29. la relación sería de este tipo: . • Temporales: se trata de una o varias tablas donde se guardan datos transitorios extraídos de maestros. Los datos de la entidad de maestro sólo deberían modificarse a través de transacciones. por ejemplo.220 JUAN BRAVO C. clientes.

la entidad de transacción 2 afecta a los maestros 1 y 3. ventas. Origen de las entidades Se incluye la siguiente tipología como una forma de ayudar al diseñador en la identificación de entidades. sicólogos. abogados. ajustes. cuentas corrientes.MODELANDO UNA SOLUCIÓN DE SOFTWARE 221 M1 T1 T2 M2 M3 Mi = Maestro. generalmente a través de construir una función computacional atómica (tal como vimos en el capítulo 3). proveedores. profesores. • Interacciones: generalmente dan origen a una entidad asociativa: costos entre proveedores y artículos. Ti = Transacción Se puede apreciar que los maestros son los pilares que dan el soporte a la estructura y las transacciones la atraviesan horizontalmente. dueñas de casa. clientes. modificando los datos de cada maestro asociado a esas transacciones. vestuario. medios de transporte. accidentes. ventas entre vendedores y clientes. venta histórica. compras. En cada nodo o punto de encuentro entre una entidad de transacción y una de maestro. por ejemplo: • Elementos físicos: automóviles. empresas de diferente tipo. vuelos. es necesario realizar un proceso de actualización. depósitos. empleados. • Roles de instituciones: clínicas. • Elementos lógicos: cuentas contables. . No son distinciones rígidas. casas de reposo. asociados. la entidad de transacción 1 afecta a los maestros 1 y 2. línea blanca. isapres. ingenieros. libros. edificios. Una característica común es que aparecen más de una vez en la situación que se está estudiando para modelar. personas u organizaciones: contribuyentes. licencias entre drogas y laboratorios. • Roles de personas: doctores. AFP´s. porque pueden haber múltiples situaciones intermedias y otras clasificaciones. • Transacciones: eventos que provocan cambios en otros objetos. • Roles mixtos. fábricas. farmacias. Por ejemplo. giros.

veremos los cuatro tipos básicos de relaciones: 1:1. de esta forma: 0. En esta relación.10 0. Relaciones entre entidades Son relaciones donde se comunican dos entidades.n Clientes 1 Facturas 1. En lo que sigue. también comentaremos sobre la relación de pertenencia y las relaciones de uso.1 1 Crédito Por ejemplo. lo que da origen a una malla que es llamada modelo de datos. Un artículo puede estar entre 0 y n facturas.222 JUAN BRAVO C. un cliente puede tener sólo un crédito autorizado o ninguno.m Clientes 1 Facturas Facturas Es una relación de uno a muchos. Un cliente puede tener desde 0 a n facturas. Las formas más habituales de representación de una relación 1:N se muestran con el ejemplo de clientes y facturas de venta. Una factura puede tener entre 1 y 10 artículos. 2) Relación 1:N Clientes Facturas Clientes 0. 1:N y N:M y N:M especial. 1) Relación 1:1 Clientes 0. 5.n Artículos 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 cero a varias facturas y una factura puede tener solamente un cliente. . Un crédito autorizado pertenece a sólo un cliente.

Como ejemplo. . un proveedor abastece muchos artículos y un artículo es provisto por muchos proveedores. por ejemplo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 223 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 denomina Hijo. Proveedores 0. 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. en la red la relación es independiente de los datos de las entidades. donde necesariamente la entidad hijo debe tener como clave el RUT del proveedor y el número de factura.m 0. En este caso. los artículos ofrecidos por el proveedor. 3) Relación N:M También llamada tipo red (muchos a muchos). Esto significa que no hay pertenencia entre entidades y que los respectivos campos de relación podrían no ser parte de las entidades.m Artículos Proveedores Artículos Proveedores Proveedores Artículos Artículos A diferencia de la jerarquía. identificadores de la entidad hijo. para evitar confundir las facturas de diferentes proveedores. Las formas más habituales de representación gráfica de una red se muestran en la siguiente figura. u otros campos. Sería el caso de la relación PROVEEDORES → FACTURAS. La clave de la entidad hijo es la clave de la entidad padre más otro. se utilizó la relación existente entre las entidades proveedores y artículos.

se eliminan primero los elementos de la relación. En general. se considera apropiado dejar sólo las relaciones N:M que sean indispensables. . Un cliente puede tener más de un aval y un aval puede avalar a varios clientes. respectivamente. Cada una es un índice que apunta a la otra entidad. previo deben existir ambos “padres”. por simplicidad del modelo y mejora del tiempo de respuesta. en algunas instituciones financieras. sin embargo. Se puede comprender mejor la independencia entre relación y entidad con un sencillo ejemplo: las entidades alumnos ↔ profesores incluyen los datos personales de los alumnos y de profesores.224 JUAN BRAVO C. Algunas convenciones típicas de la implementación de la relación muchos a muchos son: • Al agregar un ítem en la relación. Por lo tanto. la norma es que un aval sólo puede avalar a un cliente. tal como en la siguiente figura con las entidades A y B. Por ejemplo. sólo en la relación se encuentra la información de alumnos por profesor y profesores por alumno. la relación cambió a “uno a muchos” y se “resolvió” una relación N:M. hijas de las entidades originales. • Al eliminar un padre. implementada mediante dos nuevas entidades. aunque cuidando la consistencia de la base. la relación entre clientes y avales es muchos a muchos. La implementación de la relación tipo red es bastante compleja. sin embargo. A A B = B Índice A/B Índice B/A Si el recurso es sólo un sistema administrador de bases de datos jerárquico igual se puede implementar una red de esta forma. porque es fácil realizar alguna operación —por ejemplo de eliminación de un registro— y dejar alguna tabla de índices sin actualizar. La descomposición lógica de una red significa construir una doble jerarquía. aunque un cliente puede tener varios avales. porque cada operación sobre una entidad significa actualizar los índices de acceso y resolver los serios problemas de consistencia de los datos. aunque actualmente esta facilidad viene provista automáticamente por los sistemas administradores de bases de datos.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

225

4) Relación N:M especial La relación N:M típica no permite manejar información propia de la interacció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:

Proveedores

Costo

Artículos

Donde se establece un nodo en el arco de la relación, la que a su vez se transforma en una entidad asociativa en la cual se puede almacenar mayor informació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 manipularán los datos. A esta relación también se le denomina NUB natural porque tiene “vida propia”, es decir, aparece en el modelo conceptual (modelo que ve la realidad del usuario) y tiene un identificador. 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 siguientes atributos (persona, persona, parentesco).

Personas

Parentesco

Por simplicidad del modelo, se recomienda estudiar la real necesidad de establecer nodos con información adicional en relaciones N:M. Relaciones de uso Las relaciones de uso son independientes de las entidades, porque no es necesario que su estructura contenga la relación, como en la pertenencia. A veces, para efectos de implementación, es necesario crear entidades asociativas, como en el caso del NUB natural o artificial.

226

JUAN BRAVO C.

Las relaciones de uso pueden tomar cualquiera de las siguientes formas: • 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.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

227

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 preliminar 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 conjunto de datos uniforme, sujetos a la misma clave, esto simplifica el modelo y da la posibilidad de aplicar funciones normalizadas. • Evitar la redundancia de datos, lo cual, 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 organización, sino también al exterior. De esta manera se economiza en preparación de especialistas y es posible aplicar herramientas uniformes, como los sistemas administradores de bases de datos relacionales y las diferentes herramientas de productividad, para automatizar múltiples funciones: consulta de información, integridad, privacidad, recuperación, ingreso de datos, informes y muchas otras. • Aplicar herramientas de apoyo en el modelamiento, todas las cuales ayudan 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.

228

JUAN BRAVO C.

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 inconvenientes: • 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 identificador de cada ocurrencia del grupo repetitivo; puede ser un número correlativo o alguno de los campos del grupo repetitivo. El ejemplo de la figura 4-3 corresponde a la eliminación de un grupo repetitivo incorporando un número correlativo externo en una factura de venta.
A Entidad no normalizada Clave Nº factura Fecha Rut del cliente Grupo repetitivo Ítem 10 Ítem 1 … Código Cantidad Precio Código Cantidad Precio Entidades normalizadas B Encabezado Rut Clave Fecha del Nº factura cliente C detalle Clave Nº factura Nº ítem Código Cantidad Precio

Figura 4-3. Eliminación de grupo repetitivo usando número correlativo externo

En este caso:

MODELANDO UNA SOLUCIÓN DE SOFTWARE

229

• 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 entidad 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 anotara 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 afectar 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 recordó 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.
Entidades normalizadas B Encabezado Clave Nº factura Fecha Rut del cliente C detalle Clave Cantidad Nº factura Código Precio

Figura 4-4. Eliminación de grupo repetitivo usando campo interno

230

JUAN BRAVO C.

Al usar el código podemos apreciar que: • La eliminación del grupo repetitivo de la entidad A dio origen a una entidad (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 detalle que se obtuvieron del proceso de normalización. Gráficamente, el resultado se ve así:
B

C

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.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

231

A Entidad no normalizada Clave Código de Sucursal producto Stock Código Descripción Nombre de de del estado producto estado

Entidades normalizadas B Entidad original normalizada T/T 18 Clave Stock Código de Sucursal Código de estado producto
C/E C Nueva entidad

Tabla de Traducción (T/T) T/T 18 Descripción del estado

Clave Nombre de Código de producto producto

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 dependientes de toda la clave: • Descripción del estado: es la traducción del código de estado en la sucursal, 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 traducció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

se aplica la condición de existencia a través de relacionar el código del artículo de la entidad B con la clave de la entidad C. No obstante. Sobre esta nueva entidad. aun cuando no estaban incluidos en la entidad A. Se intercalaron puntos suspensivos en la entidad C para destacar que es posible agregarle otros campos. También podría haberse utilizado una entidad preexistente para formar la condición de existencia. respecto al código y nombre del artículo. A veces es preferible aplicar una condición de existencia antes que una tabla de traducción. se van haciendo perfeccionamientos sucesivos hasta dar por terminado el modelo y después… igual se sigue perfeccionando. papel que cumple la tabla de traducción. artículos. la mayoría de las cuales provee esta facilidad. probablemente. • La entidad de existencia tiene muchos registros. É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. proveedores) el cual. las facilidades de la herramienta y la experiencia del diseñador serán decisivas. • La entidad de existencia es un maestro típico (clientes. esto porque el modelamiento es una actividad plenamente retroalimentada. formando una nueva entidad (C) con: código del artículo y nombre del artículo. llamada entidad de existencia. 61 . Es más que la simple dupla código-traducción. también tiene uso desde otras aplicaciones. 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. además del código y nombre de moneda. En el segundo caso. el país de origen y la conversión a dólares.232 JUAN BRAVO C. La entidad B es lo que quedó de la entidad A después de la normalización. • Algunos campos de la entidad de existencia tienen alta volatilidad. tal como un saldo de mercaderías o la renta de un empleado. es decir. estado. De aquí surge la necesidad de tener agrupadas en un sólo lugar todas las traducciones simples. por ejemplo. por ejemplo: stock mínimo y costo del artículo. observando señales como éstas: • Existe más de un campo asociado a la clave de la entidad de existencia. En el siguiente punto tratamos este tema. empleados.

palabras claves. El código 99 se usa aquí para los títulos de las mismas tablas. Las Condes. A veces se presenta un problema cuando la tabla de valores es larga. texto a traducir. 62 . el cual contiene todas las traducciones de códigos. fonética.MODELANDO UNA SOLUCIÓN DE SOFTWARE 233 3. el cual. dentro de una entidad desnormalizada. 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. es deseable que se presente una ventana con efecto scrolling62 para buscar y seleccionar con un click el elemento deseado. El efecto scrolling permite moverse en una tabla desde una ventana en la pantalla del equipo. Además. código de ítem. Las Condes. El uso eficiente de la T/T está llevando a eliminar las codificaciones simples en algunas instalaciones. etc. recibe una traducción de código desde una tabla de traducción. Por ejemplo: el nombre traducido de comunas: Santiago Centro. Una solución es que el software provea también búsqueda por diferentes conceptos: índices. atrás. Esta naturalidad 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. Por ejemplo. por ejemplo: Santiago Centro. También se define el atributo traducción de código. a través de tomar directamente desde una ventana el texto correspondiente. Por ejemplo. etc… 63 Algunos programadores preguntan: ¿cómo se construye manualmente una tabla de traducción? Respondiendo a su pregunta es que se incluye la técnica. Hacia adelante. El autor usó este esquema desde fines de los setenta con bastante éxito. en este caso el scrolling se hace cansador mientras se busca el valor deseado. 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. otros campos). El uso de la tabla de traducción lleva implícita una validación de existencia y para efectos de implementación. con el contenido de la siguiente tabla. le puede ser útil a otras personas. Pudahuel. por bloques de registros. La Florida.

La tabla. más un programa simple de mantención. 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 herramientas de productividad. Núme ro de tabla 1 1 1 1 2 2 2 … 99 99 Código de ítem 1 2 3 4 1 2 3 … 1 2 Te xto a traducir Santiago Valparaíso Viña del Mar Quilpué azul rojo verde … Ciudades Colores . la tabla de traducción tiende a desaparecer. diversos informes y un formato predefinido para usar la tabla desde múltiples aplicaciones.234 JUAN BRAVO C.

Veremos: 1. Estructura relacional 3. proyectos en que labora y departamento al cual pertenece. sin incluir la renta ni el número de cargas. son subconjuntos del modelo conceptual que prepara el administrador del sistema para los usuarios que lo soliciten. Por ejemplo: los colaboradores con sus cargas. Nivel interno Métodos de acceso a los archivos físicos Nivel conceptual Modelo de datos completo de la base de datos Nivel externo Visión de Usuario A Visión de Usuario B Figura 4-6. • Externo: también llamado vista. 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. ENFOQUE DE BASES DE DATOS Se incluye esta sección debido a las referencias que se hacen en el texto a materias propias del enfoque de bases de datos.3. Arquitectura de sistemas de bases de datos Una arquitectura de sistemas de bases de datos se muestra en la figura 4-6. un tema más especializado y directamente relacionado con el modelamiento de datos. Elementos del enfoque de bases de datos 1. por ejemplo. proyectos en los cuales trabaja. renta o departamento donde labora. • Conceptual: es el modelo completo donde se relacionan todas las entidades de la base de datos. Visión de bases de datos 4. Arquitectura de sistemas de bases de datos 2. . tal vez requiera preparar al usuario del departamento de personas una “vista” con: nombre del empleado.MODELANDO UNA SOLUCIÓN DE SOFTWARE 235 4. Aquí quedan predefinidos todos los recorridos posibles para acceder a la información. instituciones previsionales. Es como una “ventana” del modelo conceptual.

Como un padre con sus hijos o un cliente con sus ventas. aquellas entidades individuales. Para su implementación. • Estructura relacional: en 1970. entre facturas y artículos. Entonces. Tal vez el ideal sería tener las posibilidades de las bases de datos no relacionales pero con la simplicidad de los archivos lineales. redes y relacional. Las estructuras de bases de datos son tres: jerárquica. porque se extrañan las simples tablas planas. sin embargo. 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 compartidos ) que dio inicio a esta novedosa forma de describir los datos y sus relaciones. Por ejemplo. . Se aprecia que cada nivel utiliza la estructura más apropiada a sus fines. A veces. En consideración a la importancia de la estructura relacional. 2. Por ejemplo. queda un sabor algo amargo cuando se aplican estas estructuras no lineales. quien da su descripción de la información que maneja. Esto es lo que se trata de lograr con la estructura relacional.236 JUAN BRAVO C. sin normalización y en muchos casos redundantes. el nivel interno podría organizarse según una estructura de redes y los niveles conceptual y externo según el esquema relacional. el precio de cada artículo en una relación proveedores–artículos. Codd ha sido considerado el “padre” del esquema relacional. Estructura relacional Las estructuras jerárquicas y redes permiten resolver los problemas más importantes de las bases de datos: redundancia. el doctor Edgar F. integración de datos e independencia de los datos versus las aplicaciones. la red requiere de software complejo. • Estructura jerárquica: esta estructura representa una relación uno a muchos. aisladas. lo cual facilita la participación del usuario. Desde entonces. el cual consiste en una visión natural de los datos con un estilo tabular de anotación. especialmente cuando se maneja el enlace entre las dos entidades como una subestructura que tiene otros atributos. con la estructura jerárquica es posible simular relaciones de muchos a muchos 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 muchos. Esto es conceptualmente equivalente a tener dos jerarquías: ventasartículos y artículos-ventas. trabajando para IBM. en el siguiente punto profundizamos en sus principios. el Dr. porque pueden haber varios artículos en una factura y un artículo puede estar presente en muchas facturas.

De aquí deriva el conocido esquema Entidad-Relación —ER—. éstas y muchas otras consultas bastante más refinadas. por ejemplo. entre otras cosas. tal como su nombre lo indica. Codd. en una relación con los atributos: número de factura. la herramienta debería buscar en dos tablas—. • Extracción vertical. por ejemplo. en forma horizontal. unión. 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. • Dominio : conjunto de datos de un atributo. 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. la factura 1518 del 10/01/95 de LINHOGAR LTDA. En el enfoque relacional se aplican las formas normales propuestas por el Dr. fecha y nombre de proveedor se pueden realizar operaciones como estas: • Extracción horizontal. El esquema relacional predomina actualmente en el ambiente de bases de datos porque tiene una sólida base conceptual y teórica. Esto significa.MODELANDO UNA SOLUCIÓN DE SOFTWARE 237 En el enfoque relacional. especialmente las operaciones destinadas a la consulta de datos: selección. consiste en seleccionar una tupla. . todos los nombres de los proveedores. por lo que debe ser resuelta a través de tablas intermedias.000 al 2. significa obtener.000 de los proveedores ubicados en la ciudad de Santiago —en este caso. • Atributo : equivalente a campo. Por este motivo se usa la entidad asociativa cuando hay relaciones muchos a muchos. Actualmente. se efectúan principalmente con productos tipo SQL (Structured Query Language). se “relacionan” algunas tablas con otras en base a campos presentes en las mismas tablas. con muchos elementos extraídos de la teoría de conjuntos y del álgebra relacional. intersección y otras. que la relación muchos a muchos no se acepta en forma directa. proyección. Algunas denominaciones usadas en el enfoque relacional son: • Relación o tabla : equivalente a entidad o archivo. Especial mención merece la extracción de datos desde una relación. • Tupla : equivalente a registro. Por ejemplo. • Una combinación podría ser: extraer las tuplas con número de factura del 1. vertical o en una combinación de ambas. siendo generalmente aceptado que la mayor parte del modelamiento de datos se resuelve con el uso de las tres primeras de ellas.

referencias cruzadas y otros procesos destinados a apoyar puntos de control y eventuales revisiones. por ejemplo el nombre y el saldo de crédito del señor Pérez. como una sumatoria o la mantención de un índice de un dato original. es decir. • Integridad referencial: significa que cada dato de la base está siempre consistente. ◊ Readecuar automáticamente el modelo de datos después de agregar o eliminar campos. • Auditoría: el software debería permitir efectuar totalizaciones. tratados en el capítulo 2. 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. básicamente en lo que se refiere a reiniciación. copias de datos para algún uso específico. Ésta consiste en reconstruir la secuencia de transacciones . que son borrados cuando cumplieron su misión. cuadraturas. 3. ◊ Recuperación: son las precauciones a tomar frente a “caídas” del sistema. Algunos ejemplos: ◊ Modificar automáticamente el campo “total neto de la factura” cada vez que varíe un ítem de la factura. Pérez aparece en dos lugares a la vez y con diferente contenido? Puede existir la redundancia controlada. De aquí surgen las principales características del enfoque de bases de datos: • Manejo de la redundancia: significa que cada dato. El término se aplica cuando algunos datos son consecuencia. integridad y recuperación. La eliminación de la redundancia es una de las principales razones para realizar el proceso de normalización de datos. presentado en el capítulo tercero. el análisis de procedimientos y errores en el diseño. • Protección de la información: se refiere a los conceptos de seguridad. ¿Le creería usted al sistema si el saldo de crédito del Sr. además de proveer los mecanismos para seguir la ruta de auditoría. Veamos un resumen: ◊ Seguridad: incluye la privacidad de datos. ◊ Integridad: es asegurar la consistencia de los datos en todo momento y protegerlos contra invalidaciones accidentales o deliberadas. se incorpora al modelo conceptual y queda almacenado una sola vez en las bases de datos. resultado o están relacionados con otros. reconstrucción y respaldos. ◊ Validar la existencia del producto cuando se incluye en una factura.238 JUAN BRAVO C.

• Independencia de datos: es clásica la característica de independencia entre datos y aplicaciones. A veces. descripción. largo. con la normalización del almacenamiento podemos aplicar funciones genéricas . Además. Son varias las soluciones para este tipo de problemas. por ejemplo. Bajo este concepto.MODELANDO UNA SOLUCIÓN DE SOFTWARE 239 que afectaron a un determinado dato. el que toma primero el registro deja al otro esperando hasta que lo actualiza. La idea es que los datos pertenecen a toda la organización y no a una aplicación particular. 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. ◊ Estructurar los campos de las entidades de manera uniforme: por ejemplo. • Concurrencia: el sistema administrador de bases de datos debe incluir el manejo de colisiones en una aplicación con múltiples usuarios. Un ejemplo elemental de pérdida de independencia. Desde éstos se puede usar el conjunto de instrucciones de manipulación de datos propios del sistema administrador de la base de datos o de la norma SQL. la consistencia de la base de datos se ve afectada por código que actúa directamente sobre los datos. Codd o la normalización simplificada de este texto. sino que lo hace un intermediario común a todas las aplicaciones: el sistema administrador de la base de datos a través de los mecanismos 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. para: ◊ Definición: tipo de campo. válido incluso en ambientes sin base de 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. generalmente a través de una bitácora de procesos. ◊ Documentación: en informes o ayudas en línea. Así se obtiene una mínima repetición de definiciones. una aplicación no modifica directamente los datos. situación que se produce cuando dos o más usuarios intentan actualizar simultáneamente el mismo registro. aplicando hasta la tercera forma normal del modelo del Dr. por ejemplo. Significa separar el almacenamiento de los datos de las características de una aplicación particular. tipo COBOL o C. etc.

Enfoque de bases de datos . DBA = Data Base Administrator. 4. DML = Data Manipulation Language. para consulta. DD = Data Dictionary. eliminación y otras. • Manejo de Bases de Datos remotas: significa manejar datos que se encuentran en bases muy distantes. DBA Lenguajes DDL DML SQL DBMS DD DB DB DB Figura 4-7. Es muy útil cuando desde una aplicación se requiere ubicar información que está en bases de datos ubicadas en diferentes equipos. Lenguaje de manipulación de datos. DB = Data Base. • Manejo de Bases de Datos distribuidas: significa que varias bases de datos “se ven” como una sola.240 JUAN BRAVO C. modificación. Elementos del enfoque de bases de datos Los principales elementos del enfoque de bases de datos se muestran en la figura 4-7. controladores o líneas dedicadas. Lenguaje de consultas estructuradas. Administrador de la base de datos. DBMS = Data Base Management System. Esta característica es cada vez más indispensable y tiene varias consecuencias: implica resolver el problema de la comunicación remota y conocer el mundo de los satélites. Diccionario de datos. Bases de datos. Sistema administrador de bases de datos (SABD). DDL = Data Definition Language. que todo sistema administrador de bases de datos provee. SQL = Structured Query Languaje. Lenguaje de definición de datos. ingreso. con las abreviaturas en inglés por ser de uso generalizado. sobre los datos.

Data Base Management System (DBMS). . • Bases de Datos. reglas de ejecución. código reutilizable y en especial. también llamado enciclopedia o repositorio. también se agregan características lógicas. 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 diferentes lenguajes que provee. de todas las actividades tendientes a optimizar el uso del recurso información. El diccionario de datos evoluciona hacia el diccionario de conocimientos. Sólo puede ser accesado según los métodos del SABD. Data Base (DB). descripción. es el conjunto de tablas (archivos físicos) donde se almacenan los datos de la organización. Data Base Administrator (DBA). largo. Posee múltiples funciones. quienes pueden apoyarse en herramientas de software para lograr sus objetivos. • Sistema administrador de bases de datos (SABD). formatos predefinidos. Data Dictionary (DD). • Administrador de la Base de Datos. es un archivo reservado del SABD donde se almacenan las características de los datos. tipo de dato. las que se activan al momento de producirse un error o al cumplirse alguna condición. En el DD también se graban las relaciones entre los datos. por ejemplo: ◊ Manejar la integridad. ayudas en línea o documentación. corresponde a una función administrativa encargada. además de almacenarse las características de los datos y sus relaciones. por ejemplo. En éste. generar una orden de reposición cuando el stock de un producto llegue a su nivel mínimo. • Diccionario de Datos. condiciones de validación. es el software administrador de la base y del diccionario de datos. Esta función puede ser desempeñada por una o varias personas. Por ejemplo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 241 A continuación veremos cada uno de lo elementos de este enfoque. o los metadatos de la organización. entre otras. por cada campo se archiva: nombre. de las siguientes actividades: ◊ Diseñar la base de datos ◊ Definir los metadatos (atributos estáticos y funcionales de datos) ◊ Proteger la base de datos En suma.

modificando o eliminando registros.242 JUAN BRAVO C. las ventas del cliente Juan Pérez o los artículos más vendidos en el último mes. permite realizar consultas sobre la base de datos. por ejemplo. excelente preparación del profesional de informática. se usa el principalmente el lenguaje SQL —Structured Query Languaje— basado en el álgebra y cálculo relacional propuestos por el doctor Codd. utilizado para actualizar los datos de la base: agregando. normalización externa y los factores de contexto: colaboración o ambiente físico. . desarrollar sistemas computacionales o consultar datos— y todos los demás factores de productividad: método. en otros. A través de este lenguaje se puede hacer un recorrido o una navegación automática dentro de la base de datos. Cuando se trabaja con bases de datos relacionales. ◊ Lenguaje de consulta: Query Language. permite mantener las definiciones y estructuras de datos almacenadas en el diccionario de datos. Son los lenguajes del SABD que permiten al usuario interactuar con la base de datos o el diccionario de datos. Sólo el desarrollo equilibrado del conjunto de factores —más que el avance espectacular en alguno de ellos— permitirá lograr los objetivos de productividad que las organizaciones requieren. para administrar bases de datos. ◊ Lenguaje de manipulación de datos: Data Manipulation Language (DML). existen explícitamente estos tres: ◊ Lenguaje de definición de datos: Data Definition Language (DDL). incorporación del usuario. métodos de trabajo normalizados. Algunos SABD poseen un lenguaje que cumple con todas las funciones. siguiendo camino de las relaciones predefinidas para dar respuesta al requerimiento. • Lenguajes. Es importante la armonía entre buenas herramientas —por ejemplo. hardware adecuado.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 243 CAPÍTULO 5. ORIENTACIÓN A OBJETOS .

así. tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). MODELAMIENTO DE DATOS CAPÍTULO 3. ORIENTACIÓN A OBJETOS CAPÍTULO 4. facilitar la mantención. tiene que ver con la visión de trabajar con integración y componentes. y el desarrollo de métodos ágiles como la programación extrema. CAPÍTULO 7. Capítulo 5. Los objetivos que se pretenden lograr son ambiciosos: aumentar la productividad. HERRAMIENTAS TI CAPÍTULO 6. UML CAPÍTULO 5.244 JUAN BRAVO C. reducir los riesgos y reutilizar el trabajo previo. TEORÍA DE MODELOS CAPÍTULO 2. p. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales Con la orientación a objetos es posible que la solución de un desarrollador sea comprendida más fácilmente por otros. INGENIERÍA DE SOFTWARE CAPÍTULO 1. la empresa usuaria se beneficia doblemente. incorporar al usuario. mejorar la calidad. 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 perfeccionando en el tiempo. xiv) La orientación a objetos (OO) provee una forma simple y natural para crear los modelos de la solución de software. Es necesario que el analista sea muy hábil en la orientación a objetos como parte de su responsabilidad profesional. . Esta es la quinta competencia considerada para apoyar la elaboración de modelos de una solución de software. Sommerville (2005. entre otros. obteniéndose mayor independencia del modelo respecto a su creador. 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. Orientación a objetos En los últimos años. 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.

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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 245 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. 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 .

no requiere de mayores comentarios mencionar que en la década de los noventa él promovió… la orientación a objetos. el principal método que dominó desde los años 60 es el diseño estructurado. Hacia fines de esa década ya existían algunas formas de diseño estructurado y otras que enfatizan el enfoque de base de datos. las aplicaciones prácticamente no tenían diseño y luego surgieron diversas formas más bien locales y artesanales. el sueño de la ingeniería de software. ya aconseja a los ingenieros en computación que comiencen a estudiar la orientación a objetos. sólo porque el tipo de datos cambia?”. En los años 60 surgió lo que conocemos como diseño físico o esquema tradicional de diseño. manteniendo sólo un “diseño estructurado mejorado” para quienes conservaban esa tecnología en sus instalaciones o se incorporaban tardíamente.246 JUAN BRAVO C. 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. José Piquer. académico del Departamento de Ciencias de la Computación. Escuela de Ingeniería de la Universidad de Chile. 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 solamente en los datos. Señala que la programación orientada a objetos. Considerando que hemos reconocido a Edward Yourdon como uno de los padres de este esquema. ¿Cuántas veces uno implementa la misma función de búsqueda. La aparición de la orientación a objetos en los años 80 hereda esos avances previos. 5. En un artículo en Revista Informática de principios de los 90. El objetivo de esta evolución histórica ha sido el aumento de productividad.1. FUNDAMENTOS DE LA ORIENTACIÓN A OBJETOS La Orientación a Objetos (OO) es un hito fundamental en el proceso de desarrollo de la computación que comenzó en los mismos años de la Segunda Guerra Mundial con el advenimiento de los primeros computadores en Alemania y Estados Unidos. “nos comienza a proveer con algunas herramientas buscadas por largo tiempo: las bibliotecas de clases. . principalmente vía SmallTalk. Reutilización.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 247 La orientación a objetos es muy amplia y permite modelar realidades de diferente índole. voces. como textos. Visión de los datos 3. SMALLTALK y SIMULA. imágenes. la cantidad potencial de funciones es n² en el esquema estructurado y n en la orientación a objetos. Mayor eficiencia 2. Esquema estructurado 9 funciones (n2) M1 Operación 10 T1 M2 Operación 11 M3 Operación 12 M1 Operación 10 T2 M2 Operación 11 M3 Operación 12 M1 Operación 10 T3 M2 Operación 11 M3 Operación 12 Mensaje 12 Mensaje 11 Mensaje 10 Objetos 3 funciones (n) M1 Operación 10 M2 Operación 11 M3 Operación 12 Mi = Maestro. La orientación a objetos 5. Mayor eficiencia Una fuerte justificación de la orientación a objetos es su mayor eficiencia. De hecho. Veremos: 1. Ti = Transacción Figura 5-1. Visión histórica funcional 4. tal como vemos en la figura 5-1. Incorporación de nuevas tecnologías 1. 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++. Interacciones entre objetos . figuras geométricas y mucho más.

con la ayuda de un sistema administrador de bases de datos.248 JUAN BRAVO C. donde a veces se logra mayor productividad eliminando interacciones innecesarias entre los departamentos. Suponiendo que cada maestro es afectado de la misma forma por cada uno de los repositorios de datos de transacciones. todavía la capacidad de procesamiento no lo permite en forma eficiente. En lugar de acceder a un campo “stock”. en la OO tan sólo se requieren 3 funciones. Por ejemplo. 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. Para entender mejor la disminución en la complejidad de las relaciones funcionales y el notable aumento de productividad que genera. 2. tal como se muestra en la figura 5-1. La disminución en el número de funciones se debe a la característica de encapsulamiento del objeto. Para satisfacer las necesidades de información de la empresa. La cantidad de interacciones funcionales entre los componentes disminuye notablemente respecto a otros métodos. producto de las tres tablas de transacciones que actualizan a 3 tablas maestras. Frente a la misma situación. 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. una vez por cada objeto de transacción. se requiere obtener el saldo de inventario de un producto. Se puede comparar con la realidad de las empresas. Hasta fines de la primera década del 2000. no es necesario construir un sistema computacional porque todo se obtiene realizando consultas sobre la base de datos. una por cada objeto. Así se originó el enfoque de bases de datos que vimos en el capítulo 4. sino que se mantienen los valores originales. veremos en el siguiente punto la evolución que han seguido los modelos de soluciones de software. en el esquema estructurado se requieren 9 funciones. Cada una de ellas sería activada tres veces. debido a la estructura de objetos independientes que se comunican entre sí a través de mensajes. donde sólo es posible afectar una variable con una operación que se activa a través de un solo tipo de mensaje. . En este esquema los datos no deben actualizarse. se suman las entradas y se restan las salidas.

manteniendo Se conservó la palabra “archivo” que se usaba en este esquema para referirse a los conjuntos de datos. era frecuente que las instalaciones llegaran a su límite de saturación. En este entorno. cuentas contables y totales de transacciones. algunas semanas de trabajo de un buen programador. C u otro. los archivos64 de transacciones: ventas. Clipper. en particular. En gran medida. probablemente escribiendo varios miles de instrucciones en algún lenguaje de alto nivel: Cobol. tal como se muestra en la figura 5-2 para un programa de actualización. uno de los más vitales de todo sistema. Esquema tradicional de diseño En esta visión funcional la mantención se veía dificultada por la extensión del programa. Típicamente. compras y mermas del día. RPG. actualizan a los maestros de artículos. por eso la doble flecha en esos archivos maestros. mediante el cual se graficaban los programas y repositorios de datos del sistema. 64 . se calculaba que la mantención consumía 5 veces más tiempo y recursos que la construcción.MODELANDO UNA SOLUCIÓN DE SOFTWARE 249 3. Era frecuente observar que una pequeña modificación significaba varios días de trabajo. minimizar el almacenamiento y el tiempo de uso de procesador. el objetivo de esta línea de diseño era la optimización de recursos del equipo. Visión histórica funcional Durante muchos años y tal vez masivamente hasta la década del 90. De hecho. la forma tradicional de desarrollar era a través de un diseño físico que culminaba en un diagrama de procesos. Ventas Artículos Compras Actualización diaria Cuentas contables Mermas Totales Figura 5-2. cada programa incorporaba muchos archivos. La construcción de un programa como el de la figura 5-2 significaba. cuando menos. En este ejemplo.

porque fue utilizada en pocas instalaciones y de modo tan informal. 65 El autor trabajó en instalaciones donde la programación estructurada estaba vedada. Tampoco ayudaba la programación estructurada. cuesta manejar un exceso de pequeñas funciones a veces muy parecidas entre ellas. cuando se modifica un campo de una entidad. Lo cual no era tan fácil porque era bastante difícil de aprender. el programa de actualización de la figura 5-2 quedaría como el esquema estructurado de la figura 5-1. Por ejemplo. porque al poco tiempo olvidaba las sutilezas del programa. hay algunos inconvenientes. La recomendación en esos días (y todavía en ciertos ámbitos) es que era preferible tener muchos programas pequeños y si eso no era posible. Descomposición funcional Luego. 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. tal como vemos en la figura 5-3. de tal forma que construyendo la primera.250 JUAN BRAVO C. aprendimos a hacer descomposición funcional. Además. Otro problema es la serie de inconsistencias que se generan cuando no se modifican todas las funciones debidas. La idea de la descomposición funcional es ubicar las funciones computacionales atómicas sin mezclarlas dentro de un programa. solamente lo urgente. de la mano del diseño estructurado. el tiempo de construcción de los pequeños programas de la figura 5-2 probablemente no exceda de dos días y la mantención se simplifique tanto que tal vez quede tiempo para nuevos desarrollos. En muchos casos. ni siquiera lo importante. Bajo este esquema. usar la programación estructurada aplicándola correctamente. convertido en 9 funciones similares entre sí. hay que buscar en muchas funciones para corregir todas las rutinas que afectan a ese campo. En otros. Prácticamente no se construían nuevas aplicaciones. . a través del modelamiento de funciones que se investigaba por esos días. Ni siquiera ayudaba que el mismo constructor hiciera la mantención. Sin embargo. que generalmente se transformaba en una receta de “no usar la instrucción go to” a toda costa65. una visión práctica se describen los principios de la programación estructurada. Por ejemplo. En el libro Desarrollo de sistemas de información. porque habían tenido muchas malas experiencias de programas innecesariamente extensos y en extremo complejos. las siguientes se copian y adaptan.

cantidad). Ambas son funciones atómicas y están bien definidas. 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 251 Ventas 1 Actualizar stock Artículos 3 Actualizar stock Mermas Figura 5-3. el cual tiene como parámetros el código del producto y la cantidad que se restará. . cuando se requiera ocuparla. porque la función restar stock se define una sola vez y pasa a ser parte del objeto artículos. donde los datos y las funciones están indisolublemente unidos. ajustes de salida o devolución de compras.. apreciaremos que ambas funciones hacen lo mismo: restar el stock. De esta manera. Aunque. se activa con un mensaje. Artículos Ventas Mensaje 1 • Código Descripción Stock 1. La orientación a objetos Con la orientación a objetos se evita repetir código. Entonces.Restar stock Mermas Mensaje 1 Figura 5-4. Ejemplo de orientación a objetos El gran avance es el encapsulamiento. Entonces. la función puede ser activada desde los objetos ventas y mermas a través del mensaje 1 (su estructura es: código. ya sea por ventas. mermas. En este caso. si observamos detenidamente. ¿por qué repetirlas?… 4. el ejemplo de la figura anterior quedaría como se muestra en la figura 5-4.

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. 5. destacando las ventajas de la orientación a objetos. Es la posibilidad de acercarnos a la forma natural del aprendizaje: el proceso cognitivo del ser humano.252 JUAN BRAVO C. Gráfico de incorporación de nuevas tecnologías La incorporación de nuevos entrantes es muy lenta al principio. A su vez. justamente cuando una nueva tecnología está naciendo. . 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. Finalmente. 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. cuando la tecnología está totalmente consolidada y hay mucha experiencia. Ciclo de tiempo de incorporación a la tecnología OO Cantidad de organizaciones que adoptan la tecnología UML DE Tiempo Figura 5-5. los más escépticos. la orientación a objetos nos provee de otro concepto vital: la generalización. se incorpora una menor cantidad de usuarios. El diseño estructurado se encontraría hoy (2008) prácticamente sin nuevos entrantes. Tal como vimos en la introducción del capítulo. luego se produce una fuerte aceleración hasta llegar a un alto nivel de entrada de nuevas organizaciones que la adoptan. más o menos en el punto (DE) señalado en la figura 5-5.

la educación y la promoción de la tecnología de orientación a objetos. Una vez que supo de la existencia de la tecnología de objetos. así surgió UML en 1997. la OMG encargó el desarrollo de un lenguaje de modelamiento basado en la orientación a objetos. Chile y otros países. se estaba utilizando en el 11.9% de los proyectos. con términos y definiciones en los cuales basar todas las especificaciones. Unisys. el OMG tiene por misión: • Maximizar la portabilidad y la reutilización del software. • Más del 75% de las empresas Fortune 100. • Estadísticas de 1993 indican que en EE.UU. 66 Hacia fines de la década de los 80 el autor se encontraba trabajando en el modelamiento de datos y funciones. la está usando o probando. donde reunía en un solo todo la estructura y la funcionalidad asociada a una entidad. Tenía diferentes nombres y muchas variaciones. Sin duda una apreciación exagerada. Hacia fines de la primera década del 2000 más del 70% de aplicaciones la usa de una u otra forma. ¿Por qué se produjo este fenómeno? Porque era una necesidad de mercado. Integran este grupo las principales empresas de computación a nivel mundial: IBM. En 1994. aunque con los mismos objetivos66. 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. En forma resumida. Europa.MODELANDO UNA SOLUCIÓN DE SOFTWARE 253 Algunos argumentos pueden ser esclarecedores respecto al éxito de la orientación a objetos: • Business Week catalogó a la tecnología de objetos como la más grande invención después del fuego. adaptó toda su investigación a ella. . 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)—. en comparación a un 3. NCR y otras. trabajaba en reutilización de código y experimentaba con herramientas CASE como una forma de agilizar el desarrollo de sistemas computacionales. • Ofrecer un foro abierto para el análisis.8% en 1991. USA. El método tradicional y las técnicas estructuradas habían sido sobrepasadas por la realidad y por el cambio en la computación. pero sintomática respecto a los sentimientos que provoca. • Crear una arquitectura de referencia.

UML. la OMG tiene varios cientos de miembros y sus productos son estándares “de hecho”. nuevas soluciones Es posible que muchos problemas tengan soluciones muy simples al observarlos con un nuevo enfoque. formas tridimensionales. MDA. textos. API’s y otros. Hacia el 2008. porque sólo se ha apreciado una pequeña porción de la realidad. tal como CORBA. fotografías o conjuntos de datos con estructuración libre.254 JUAN BRAVO C. Nuevo enfoque. Con la tecnología de objetos podemos “ver” a la organización de forma más simple. dejándose de lado la imagen real que percibe el usuario: objetos “vivos”. natural y real. distinto a la visión permitida por las estructuras tradicionales de archivos planos y programas asociados. .

MODELANDO UNA SOLUCIÓN DE SOFTWARE 255 5. se justifica una representación más simple para ellas. 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. En cierto contexto un objeto puede ser visto como una clase y en otro como un objeto. Veremos: 1. Son conceptos recursivos y que dependen del contexto. tal como lo propone Edward Yourdon. Clase Personas • Rut Nombre Dirección Ingresar Eliminar Imprimir Objetos Avales Objeto Ventas • Nº documento Rut Ingresar eliminar Instancias de clientes: Juan Pérez. Relación de pertenencia 4. También se observa que las ocurrencias de una clase son los objetos y que las ocurrencias de un objeto son las instancias. Definiciones preliminares El juego de denominaciones tiene como base la figura 5-6. . Definiciones preliminares 2. Condición de existencia 1.2. Alberto Torres Clientes C/E Figura 5-6. Convenciones de diseño 3. El punto (•) señala que el campo es llave principal. por lo tanto. Veremos que en los diagramas finales de diseño hay solamente clases. El campo Rut es un número identificador de personas y empresas en Chile. donde se aprecia que las clases y objetos se componen de atributos y funciones. DEFINICIONES SOBRE ORIENTACIÓN A OBJETOS Precisaremos aquí los conceptos básicos de la OO y algunos términos asociados del modelamiento de datos y funciones.

etc… • Objeto asociativo: generalmente resulta de una relación tipo red entre dos objetos. traducción del nombre del día y del mes. A nivel del diseño. algunos ejemplos de objetos serían: clientes. • Atributo referencial: es un atributo que a su vez es llave o parte de la clave de otro objeto. cada cliente individual del objeto CLIENTES de la figura 5-6. Consta en su mayor parte de lógica generalizada. equivalente al “registro” del diseño tradicional o a la “tupla” del esquema relacional. equivalente a la entidad más su funcionalidad. común a todas las funciones del mismo tipo y en menor medida. • Función: es un procedimiento que permite cumplir alguna acción. Definiciones de la OO: • Atributo: es equivalente a “campo”. Se aplica a nivel del modelamiento y sirve para identificar y darle sus elementos a los objetos que de ella derivan. notas de devolución de compras. mes y año. facturas de venta. actualizar el saldo de un inventario o imprimir una cartola. • Objeto: Es algo concreto del mundo real que tiene una representación física en la construcción del sistema. Veremos más sobre clases en el resto del capítulo. Por ejemplo. proveedores. Las funciones permiten “dar vida” a una estructura estática. Por ejemplo. Cada objeto viene a ser una instancia de su clase. en la figura 5-6 se aprecia que los objetos clientes y avales se derivan de la clase personas y heredan de ella sus elementos comunes. . los señores Juan Pérez y Alberto Torres. de las reglas de negocio. por ejemplo. avales. • Clase: es una abstracción que no tiene una implementación tecnológica. diferentes formatos (AAAA/MM/DD o DD/MM/AAAA). especialmente cuando se agregan atributos propios de la relación. Por ejemplo: el campo fecha con sus procedimientos de cambio de día. • Instancia: es una ocurrencia de los datos reales de cada objeto. el RUT del cliente en el objeto ventas de la figura 5-6. en la forma de un programa de computador. • Atributo identificatorio: es parte de la clave del objeto. Por ejemplo.256 JUAN BRAVO C. Se define como un conjunto de atributos con funciones indisolublemente asociadas. etc… Un atributo posee características estáticas y funcionales. o lógica que realmente tiene que ver con las necesidades particulares de la aplicación. artículos. tal como vimos en el capítulo anterior. También se le llama llave externa o llave foránea.

2. La variable no puede ser parte de la clave cuando es un atributo del objeto. Convenciones de diseño Algunas convenciones para el diseño pueden ser. por ejemplo. • Variable de resultado: puede ser física. pasar parámetros a través de mensajes. 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. como la valorización del saldo —según la fórmula saldo x costo— de un producto del inventario. • Variable global: es una variable que no pertenece a ningún objeto. con el fin de obtener nombres fácilmente entendibles y que proporcionen el máximo de información. y verbos en infinitivo para funciones. tales como restar. esto porque las observaciones se realizan de acuerdo al fin particular de la aplicación. Por ejemplo. lo que declaramos como clase en un nivel podría ser objeto en otro. etc… A veces se la identifica con subrayado. sumar e ingresar. por ejemplo. objetos y funciones son vitales para lograr claridad en modelos complejos. Los nombres de clases. También se sugiere evitar el uso de prefijos y sufijos. Suponer los siguientes largos de campos. salvo indicación diferente: . Asimismo. como un atributo del objeto donde se guarda el resultado actualizado de alguna operación.MODELANDO UNA SOLUCIÓN DE SOFTWARE 257 por ejemplo. VENTAS. permite efectuar operaciones aritméticas. como cuando se usa una variable global y el cálculo se efectúa cada vez que se requiera la variable de resultado. También puede ser lógica. Si el campo con dígito verificador se utiliza en otra entidad. por ejemplo: • Validar el dígito verificador de campos que son llave de la entidad cuando el dato entra por primera vez al sistema. Algunas convenciones recomendables son usar sustantivos para clases y objetos. El objeto asociativo también puede estar asociado a un solo objeto. el costo de cada artículo por proveedor en una relación muchos a muchos entre artículos y proveedores. al ingresar el RUT al objeto CLIENTES. • Recursividad: significa que tanto los datos como las funciones son a su vez clases y objetos en otro nivel de profundidad. parentescos del objeto personas. tales como personas. identificar el estado de los objetos. artículos y documentos.

relacionados con las convenciones de diseño. • No se puede eliminar un padre si existen hijos y no se puede crear un hijo si no existe el padre. • Cada hijo tiene un solo padre. en la cual se aprecia la pertenencia de entidades. Entidad A Donde B pertenece a A. Relación de pertenencia La línea que une los objetos A y B es más gruesa. La relación de pertenencia es un caso particular de la relación uno a muchos presentada en el capítulo anterior. los objetos hijo no podrían sobrevivir independientemente. • • • • • • Valor Documentos Nombres Dirección Teléfono RUT : numérico largo 9.258 JUAN BRAVO C. Los hijos se relacionan a través del padre. 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. 3. se definen en los siguientes puntos. es el caso de un encabezado y su detalle en documentos como una factura o una nota de devolución. para reflejar lo fuerte de la relación. . más dígito verificador Los conceptos relación de pertenencia y condición de existencia. con signo : numérico largo 6 : alfanumérico largo 30 : alfanumérico largo 35 : alfanumérico largo 15 : numérico largo 10. Se agregan las siguientes características: • Unicidad: significa que todos los objetos son parte de un solo todo. en consecuencia. lo cual da origen a la notación: A Entidad B B Figura 5-7.

así es que no sería necesario anotarla en el objeto de detalle. tal como se aprecia en el siguiente diagrama: Forma lineal Forma tabular Algunas convenciones sobre esta relación son: • Suponemos que existe un traspaso automático de información entre padre e hijo. Considerando lo poderoso de la relación. Condición de existencia La condición de existencia (C/E) es una relación funcional entre objetos. • Para efectos de implementación. la cual permite asegurarse de que uno o más atributos referenciales de un objeto . se toman automáticamente y viceversa. generalmente la información del padre se presenta en forma lineal y la del hijo en forma tabular. porque a nivel de la implementación significa que no es necesario construir ningún tipo de índice intermedio. Esto significa que si el objeto de detalle no tiene los datos requeridos para estructurar un mensaje y sí están en el encabezado. • El primer atributo de un detalle es la misma clave de la entidad encabezado. cualquier función del detalle puede ser activada desde el encabezado y viceversa. pues todo lo necesario está contenido en los objetos y en su estructura. 4. Esta distinción es vital. • Asimismo con las funciones.MODELANDO UNA SOLUCIÓN DE SOFTWARE 259 • Se llega automáticamente al hijo pasando por el padre a través de la relación de pertenencia. es conveniente que un mismo diseñador sea dueño de todos los objetos sujetos a relaciones de pertenencia.

3. 2. con los cuales se forma la clave de un objeto destino. Ofrecer tres alternativas a elección del usuario: 1. Crear la instancia en el objeto destino desde una ventana en el objeto origen. existan en éste. Rechazar el campo en el objeto origen. la siguiente lógica: ¿Existe la instancia en el objeto destino? (por ejemplo. Por ejemplo. en la figura 5-6 el objeto origen es Ventas. NO. el destino es Clientes y el atributo referencial es el RUT. . Es también una posibilidad mantenerla como una clase o rutina reutilizable. La condición de existencia es una validación que sigue. Acción de desplegar algo y aviso OK. el cual es la clave del objeto destino. más o menos. Generalmente este tipo de lógica viene provista en forma automática por sistemas administradores de bases de datos y herramientas de productividad. Buscar en una ventana la instancia deseada. un cliente) SI.260 JUAN BRAVO C. origen.

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. Mensaje 7. una tabla de artículos con todas las funciones necesarias para extraer y actualizar sus datos. Encapsulamiento 2. Necesita “saber” qué hacer con el material que entra. por ejemplo. Se parece al funcionamiento de una célula. Función 5. Identidad de instancias de objetos 6. ¿cómo lo hace? Eso es parte de sus funciones incorporadas67. por así decirlo. Ella necesita “saber” qué tipos de moléculas se encuentran a su alrededor para dejarlas entrar o cerrarles el paso. Se trata de todo un mundo fascinante que funciona a base de “información”. diseño e implementación del método GSP. fabrica los componentes que el organismo necesita y los exporta al lugar apropiado. Enfoque sistémico 1. se lo pide al objeto artículos. proteínas G y electores diversos. CONCEPTOS DE LA ORIENTACIÓN A OBJETOS Los conceptos de la orientación a objetos aplican en las etapas de análisis. los datos y las funciones que afectan esos datos. Objeto 4.3. las transforma para conseguir energía. Con el tiempo. su propia vida: recibe sustancias desde el exterior. el historial de un artículo. se sabrá cómo se relacionan entre sí las docenas de receptores.MODELANDO UNA SOLUCIÓN DE SOFTWARE 261 5. el cual responderá de acuerdo con sus funciones incorporadas. arroja fuera los desechos. Alfred Gilman. Clase 3. Encapsulamiento El encapsulamiento significa incluir en un solo todo. para actuar en consecuencia. Y ahí desempeñan un papel importante las proteínas G. Independencia 8. También necesita “conocer” el estado del organismo. Y podrá predecirse cómo reaccionarán las células en respuesta a cualquier combinación de señales”. Veremos: 1. por ejemplo. si otro objeto requiere algo. la cual recibe mensajes del exterior y reacciona proporcionando los productos correspondientes. llamado objeto. De esta forma. 67 .

Si me ponen delante otros cinco mil objetos. de las imágenes concretas de cada silla. supongamos. Aquí veo una silla. 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.262 JUAN BRAVO C. de cada objeto detectado por los diferentes sentidos. En realidad. como un candil. dejando aparte aquello que le es propio a cada una. la mente es eso: una red filtradora o una fábrica de elaboración. la mente. deduce una idea común a todos los objetos y por consiguiente. Otro ejemplo. por ejemplo. Es un trabajo de universalización. sabré decir con precisión cuáles son fríos. asociándolos a ella y dándoles los elementos comunes. Allá lejos veo otra silla. . cuáles calientes o tibios. tales como: enviar mensajes de e-mail para el cumpleaños. Y así. el cual además de una estructura de campos (nombre. las tablas de clientes y proveedores. O. A partir de experiencias concretas vamos formando y perfeccionando cada abstracción. El objeto representa algo del mundo real que tendrá una representación física. revisemos esta cita extraída del libro Muéstrame tu rostro. Una vez terminado este trabajo de elaboración. dirección. mejor. Efectivamente. Ahora comienza el trabajo elaborador de la mente. voy distinguiendo. reconociendo e identificando las mil sillas entre los diez mil objetos. Gracias a ella es posible reconocer rápidamente otros objetos del mismo tipo. rojos o amarillos. Vamos a un ejemplo concreto. obtener saldo de crédito. universal. el objeto clientes. cuáles verdes. Por ejemplo. fecha de nacimiento y otras) tiene una cantidad de funciones incorporadas. Clase La clase68. es una abstracción de la realidad y vendría a ser la forma común de describir objetos similares. los cuales pueden ser alterados en un objeto determinado. aquella idea universal y con su luz. sin equivocarme. 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. ¿Qué diferencia hay entre una clase y un objeto? La clase es una generalización que no llega a transformarse en tablas. en otro orden. cincuenta sillas de cincuenta formas diferentes. de Ignacio Larrañaga. la idea de mesa la representamos como una cubierta 68 El concepto de clase es tan importante porque tiene una fuerte sustentación natural. cuáles son duros o blandos. saca y se queda con lo que es común a todas: una idea universal de silla. Así funciona y ésta es la génesis del pensamiento humano. pueden presentar ante mis ojos mil sillas en medio de diez mil otros objetos. Mi mente toma. de muestra. Lo mismo sucede en otras áreas. 2. De todas las sillas. Esto es. agregar o eliminar registros. 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. por ejemplo: personas. entraron en mi mente.

obtener informe y consultar). responsabilidad. tendríamos que señalar tamaño. También creamos clases y formamos abstracciones de abstracciones formando conceptos cada vez más complejos. CL. textura o color. en el caso de la mesa. sin verse afectadas por las nuevas experiencias que vivimos. Un usuario u otro objeto no pueden aplicar procedimientos externos para actuar directamente sobre los datos. porque las utilizamos para filtrar la realidad y enfrentar nuevas situaciones69. tal como se aprecia en la figura 5-8. Las abstracciones son vitales. un número y un nemotécnico. 3. 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. Objeto Es una unidad monolítica de atributos con sus funciones que tiene su propia identificación. donde se muestra una forma de representación para un ejemplo de clientes. hasta cuando viene una crisis y hacemos una actualización rápida y agotadora. nombre y dirección) y las funciones realizan operaciones sobre los atributos (ingresar. de aquí el concepto de encapsulamiento de datos y procesos. El objeto se comunica con el mundo exterior a través de mensajes. La identificación del objeto contiene un nombre corto. obtenida como resultado de todas nuestras experiencias anteriores sobre el concepto de lápiz. forma. es curioso que algunas abstracciones las tenemos inconscientemente en perfeccionamiento continuo y otras se nos quedan rígidamente ancladas en alguna parte del pasado. por ejemplo. Las funciones manipulan los datos y solamente se activan a través de mensajes.MODELANDO UNA SOLUCIÓN DE SOFTWARE 263 con algún tipo de soporte. A propósito. en el ejemplo: Clientes. No se puede dibujar una abstracción. De la misma forma. por esta razón se habla de ocultamiento de datos (data hiding). una experiencia nueva. 69 . padre. Somos capaces de reconocer un lápiz. Los atributos corresponden a la definición de los datos (RUT. madre. pareja y así sucesivamente. porque si lo hacemos estamos obligados a particularizarla en un objeto concreto. 08. tenemos abstracciones de alegría. porque sus elementos distintivos cuadran con nuestra abstracción de lápiz.

mes. número. Los diferentes tipos de modelos permiten entender mejor la realidad. Por ejemplo.264 JUAN BRAVO C. Ingresar datos 2. independientemente de sus ocurrencias. es la imagen que traemos a nuestra mente cuando imaginamos un lápiz. año. Obtener informe 3. uno la entiende como un conjunto donde hay datos (DD/MM/AAAA) y operaciones (cambio de día. En este sentido. sino que. nombre. Representación de un objeto Un objeto tiene una identidad. porque lo hacen de manera más natural. propietario o condiciones fijas. intuitivamente. una silla o el maestro de clientes en la aplicación de cuentas corrientes. nemotécnico. los objetos son modelos que reflejan de mejor manera la realidad que otros mecanismos actuales. El objeto nace a partir de una abstracción de la realidad. fecha de expiración. El objeto también posee características propias. Es un punto de vista que puede diferir de persona a persona y que representa algo del mundo real. para así ayudar a resolver problemas concretos. El objeto así concebido no se daña por errores en otros objetos. . por ejemplo. Clientes 08 CL • RUT Nombre Dirección 1. son rasgos que lo definen. Aplicando el concepto de recursividad de la orientación a objetos. un comportamiento (de acuerdo con la función activada) y un estado que resulta del valor que tomen sus atributos. Consulta Identificación Atributos Funciones Figura 5-8. también puede ser que el maestro de clientes sea una clase y que cada cliente individual sea un objeto. situaciones especiales como años bisiestos o meses con diferente cantidad de días). descripción. fecha de creación. una fecha no se entiende habitualmente como característica de datos y cálculos por separado. por ejemplo.

Un objeto puede cambiar libremente cualquier atributo sin dejar de ser él mismo. obtener un informe o verificar el nivel de crédito. desaparecen las relaciones funcionales entre entidades. En consecuencia. Identidad de instancias de objetos Significa que cada instancia de un objeto tiene su propia identidad. Orientación a objetos no implica programación orientada al objeto. C u otro. Clipper. Con la identidad de instancias de objetos damos un gran paso hacia la naturalidad. • Sólo se relaciona con los atributos del objeto y con ningún otro conjunto de datos. En la orientación a objetos. Esto trae como consecuencia que en general las rutinas tengan pocas líneas de código. • Programando en algún lenguaje de alto nivel: Cobol. 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. una persona no pierde su identidad si cambia su nombre. • Utilizando facilidades de sistemas administradores de bases de datos. . cada entidad se transforma en un objeto. la función computacional debe poseer la característica de atomicidad (o descomposición funcional) porque: • Cumple un objetivo preciso y bien acotado. porque en la realidad cada instancia es independiente. no sería necesario definir atributos identificatorios en un objeto. por ejemplo: agregar un cliente. por ejemplo: • Con código reutilizable. la función puede construirse de diferentes maneras. • A través de alguna herramienta de productividad. independientemente del valor que tomen sus atributos. 4. Función Por función entendemos función computacional. el nombre del objeto debería ser el mismo que el de la entidad. por lo tanto.MODELANDO UNA SOLUCIÓN DE SOFTWARE 265 Para efectos del diseño. Por lo tanto. RUT o dirección. simplificándose notablemente la participación del usuario por este solo concepto. Por ejemplo. porque son niveles diferentes. las cuales son reemplazadas por el protocolo de un objeto. porque todo lo que necesita viene dado como parámetro en la estructura del mensaje. eliminar un cliente. de esta manera. Es equivalente a que toda función actúe únicamente sobre una entidad. 5.

Los parámetros son los valores y condiciones de entrada que requiere la función seleccionada. Todo mensaje debe ser contestado. Los componentes mínimos de un mensaje son: objeto destino. En otras palabras. a opción. Artículos Ventas Mensaje 1 • Código Descripción Stock 1. cantidad) Figura 5-9. en la figura 5-9 podemos apreciar la estructura del mensaje 1 al objeto artículos. 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. Un mensaje puede generarse de diferentes maneras. Por ejemplo. el cual activa la función 1 y lleva los parámetros: código del artículo y cantidad a restar. además de permitir referenciar cada instancia según una clave única. el sistema administrador de objetos tendría la capacidad de generar y manejar la identidad de objetos.Restar stock Mensaje 1: Artículos (código. tal como en la buena comunicación humana. función que activa y parámetros. también debiéramos poder trabajar con una clave única. Mensaje Es una forma lógica de representar la comunicación entre objetos. Opcionalmente. Ejemplo de estructura de un mensaje Al conjunto de mensajes válidos de un objeto se le llama protocolo del objeto. 6. para responder a la realidad de muchos 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. . aunque sólo sea para decir “lo escuché”.266 JUAN BRAVO C.

solicita la acción. la generación de un mensaje puede significar la realización de una llamada paramétrica a una rutina. En todo caso. en la medida que el protocolo se mantenga intacto. porque las interacciones con otros objetos están definidas y acotadas. siempre que no cambie la estructura del mensaje. se podría cambiar un objeto por otro más poderoso sin afectar al resto del sistema.MODELANDO UNA SOLUCIÓN DE SOFTWARE 267 Para efectos de la implementación del diseño con programación tradicional. su forma final dependerá de las herramientas disponibles para realizar el diseño. . No obstante. Es un tipo de comunicación estructurada donde se pueden identificar puestos intercambiables de objetos. práctica y natural de abordar los problemas de procesamiento de datos. Esto permite una forma simple. aquéllas que se refieren a “qué es lo que quiero”. Modularidad En la orientación a objetos. está identificado individualmente y no puede ser alterado desde otros objetos o programas. porque se espera llegar a tener objetos intercambiables. Independencia Cada objeto es independiente. Es decir. porque los datos de un objeto no pueden ser alterados en forma directa. 7. se puede apreciar que el servidor toma el puesto de cliente cuando requiere datos desde un servidor de mayor nivel. como éstos: • Cliente. Sólo se puede llegar a ellos a través de mensajes que activan funciones propias del objeto. La independencia es una consecuencia del encapsulamiento. Puede realizar diferentes funciones y tiene conexiones fácilmente reconocibles. La independencia de los objetos tiene efecto inmediato sobre el grado de comunicación entre ellos. Significa que disminuyen las interacciones innecesarias o de dependencia y se incrementan las relaciones importantes. • Servidor. el esfuerzo se vería notablemente simplificado. porque puede variar rápidamente. Haciendo una similitud con el esquema cliente-servidor en las redes. Esta distinción es dinámica. si fuera necesario afectar los mensajes producto de cambios mayores. da respuesta al pedido. el mismo esquema de definición de objetos permite una modularización natural a través de la definición de clases. Se pueden cambiar libremente las funciones de un objeto sin afectar a otros.

mamá-hijo. reflejada en identificar los objetos y las interacciones entre ellos (los mensajes). la calidad de la relación se traspasará al conjunto. el número de interacciones puede llegar a 6 y así sigue aumentando exponencialmente. 70 . Si hay 4. incluso cuando no haya algo especialmente conflictivo en las respectivas personas. la “sanación” de una relación enferma repercutirá favorablemente en cada integrante y en el conjunto. Por otro lado. las interacciones son 3. Del mismo modo. Debe entenderse que la simplicidad de los elementos modulares involucra mayor complejidad en su comunicación. Como analogía. Enfoque sistémico El enfoque sistémico se caracteriza por proporcionar una visión de conjunto sobre el sistema en estudio. las interfaces entre clases son muy claras y precisas. si aplicamos este enfoque a una familia con tres miembros (papá. la interacción es 1. mamá. hijo). puede ser automatizada. a veces. ¿Cuál es el número potencial de interacciones entre los objetos? Consideremos que si hay 2 objetos. Cada una con su propia identidad y peculiaridades. Somos dependientes de nuestras relaciones y cada una nos estremece de diferente manera. papá-hijo. cada interacción tiene el status de un componente más70.268 JUAN BRAVO C. Las interacciones entre los objetos tienen que ser tan bien estudiadas como los objetos mismos. identificaremos inmediatamente tres relaciones principales: papá-mamá. pero como ésta es estructurada. porque cada una es individual y afecta de diferente manera al objeto y tal como en las interacciones personales. En este enfoque. 8. Una “mala” relación afecta a toda la familia. hasta hacernos entrar en resonancia. Si hay 3.

no es imprescindible la experiencia para formar una abstracción. podríamos definir una clase transacciones de inventario que contenga los elementos comunes de las dos experiencias. Hasta cierto punto capitalizan la inteligencia de una instalación y sirven para derivar objetos. si las transacciones del inventario son órdenes de entrada y órdenes de salida. Considerando que la clase es algo abstracto. • Un objeto siempre pertenece a alguna clase de donde hereda sus elementos. Veremos: 1. Obtención de clases 2. Es como funciona el proceso cognitivo en el ser humano. como si fuera una herencia. 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 Einstein y en la física cuántica que luego se fueron descubriendo—. en el proceso de generalización formamos clases a partir de objetos o de otras clases. dos objetos.4. • Un objeto hereda siempre todas las características de la clase. 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. . Aclaremos: • Una clase nace del primer objeto que no encaja en ninguna clase existente.MODELANDO UNA SOLUCIÓN DE SOFTWARE 269 5. Si hay elementos que debe eliminar significa que deberíamos crear una subclase o modificar la clase para que sea representativa. Entonces. Profundizando más en la concepción de clases. Por ejemplo. Herencia 1. Nosotros aprendemos formando y perfeccionando múltiples abstracciones y luego aplicamos la abstracción para reconocer experiencias y tomar decisiones. 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. El concepto de generalización de la orientación a objetos permite acercarnos un poco a la tan buscada inteligencia artificial.

veamos el ejemplo sobre remuneraciones en la secuencia de figuras 5-10. Sumar haber 19.270 JUAN BRAVO C. los que heredarán sus elementos y ayudarán a perfeccionarla. ingreso. RUT del empleado y monto de la transacción. Descuento de Anticipos Transacciones de sueldos • Nº documento Rut Monto Ingresar datos Obtener informe Empleados • Rut Monto Total haber Total descuento 18. Para aclarar más el concepto. Descuento de anticipos • Nº documento Rut Monto Ingresar datos Obtener informe C/E Mensaje 19 Empleados • Rut Monto Total haber Total descuento 18. Sumar descto C/E Rebaja de préstamos Nº cuota Mensaje 19 Figura 5-11. los atributos comunes son: número de documento. Sumar haber 19. las funciones comunes son: verificación de existencia. En la figura 5-10 se pueden apreciar los objetos descuentos de anticipos y rebaja de préstamos a las personas. Ejemplo de definir una clase de transacciones de sueldos . 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. informe y activación del mensaje 19 sobre la clase empleados al terminar el ingreso de datos. ¿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. Sumar descto C/E Mensaje 19 Rebaja de Préstamos • Nº documento Rut Monto Nº cuota Ingresar datos Obtener informe Figura 5-10. 5-11 y 5-12.

la bonificación se suma al total haber del objeto personal y es necesario activar la función 18 de personal. Sumar descto Tabla de objetos de la clase Transacciones de sueldos Objeto Atributos Funciones Anticipos msg 19 Préstamos Nº cuota msg 19 Bonificaciones msg 18 Figura 5-12. tal como se muestra en la figura 5-12. como es también una transacción de sueldos. pues. en lugar de la 19. Diagrama final de la generalización En la figura 5-12 podemos apreciar la estructura de la tabla de objetos: tomando como base los elementos heredados de la clase. No hay problema. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 271 Sin embargo. como en el caso de las otras transacciones. justo cuando tenemos listo nuestro modelo. En esta secuencia apreciamos la definición. señala qué atributos o funciones se agregan a cada objeto y lo particularizan. nos damos cuenta que no consideramos las bonificaciones. 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. ¿Cómo reflejamos lo particular de cada objeto respecto a su clase? Sería extenso indicar en el diagrama de clases ese nivel de detalle. así es que usamos una tabla de objetos asociada a cada clase. Por lo tanto. Sin embargo. Sumar haber 19. el modelo final corregido quedaría solamente con las clases y la tabla de objetos. Transacciones de sueldos • Nº documento Rut Monto Ingresar datos Obtener informe C/E Mensaje 18/19 Empleados • Rut Monto Total haber Total descuento 18. aplicación y perfeccionamiento continuo de una clase. la hacemos nacer con los elementos de la clase. de la misma forma en que opera el proceso cognitivo del ser humano en relación a las abstracciones.

el documento de crédito en la figura 5-13 podría ser “genérico” y representar todos los casos del mismo tipo: letras. .272 JUAN BRAVO C. 2. por ejemplo. donde existen muchas similitudes entre un tipo de transacción y otra. Herencia El concepto de herencia es similar a la herencia genética en el ser humano. Herencia múltiple 71 Y lo que no nos transmitieron por “error” genético y que la naturaleza inventó. o cheques a fecha. estatura o ancho de los dedos— aunque incorporando 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 contado y ventas crédito. las funciones también pueden ser clases. éste nacería con los datos y funciones de la clase ventas. particularmente en la definición de transacciones. además. Ventas contado Ventas • Nº documento Fecha Cliente Precio Cantidad Ingresar datos Obtener informe Ventas por mayor Descuento Emitir factura Emitir boleta Ventas crédito Emitir pagaré Figura 5-13. Si fuera necesario definir un nuevo objeto. El concepto de herencia entrega una forma muy clara de apoyar el diseño de aplicaciones administrativas. por ejemplo “ventas por mayor”. los objetos heredan sin discusión los elementos de la clase y pueden agregar otros atributos y funciones. 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. En la herencia. Ejemplo de herencia en un sistema de ventas En otro nivel de abstracción. pagarés. puede tener particularidades tales como el atributo descuento y la función emitir factura. pero eso es otro tema.

las características heredadas pueden ser incorporadas directamente o provenir desde otras clases u objetos. es decir. Adicionalmente.MODELANDO UNA SOLUCIÓN DE SOFTWARE 273 Con la herencia múltiple pueden existir subclases o una jerarquía de clases. de personas jurídicas. los cuales heredamos desde la clase personas naturales. además. Herencia múltiple Un ejemplo de herencia múltiple a nivel del diseño es el siguiente: en un sistema de ventas necesitamos formar el objeto clientes. . En este ejemplo. Clase Clase Objeto Objeto Nuevo atributo o función Figura 5-14. requerimos agregar los datos de las personas que hacen contacto con nuestra organización —comprador. de la clase personas jurídicas heredamos los datos para formar el objeto. gerente y tesorero—. Entonces. consideraríamos a clientes como heredero de la clase principal. tal como se aprecia en la figura 5-14.

yendo de lo general a lo particular. • Identificar entidades: consiste en seleccionar los conjuntos de datos que participarán en el modelo. Visión externa 4. Repasemos brevemente esta condición de entrada al OO. Todo comienza con el modelamiento de la información. holística. en lo que se refiere a privacidad. Se aplica una visión sintética. ¿De dónde nacen? De la identificación de los procesos de la organización y más en particular. identificar con precisión los atributos de cada entidad resultante y establecer las relaciones entre ellas. menús. creación y reconstrucción de objetos.274 JUAN BRAVO C. • Modelar y normalizar los datos: significa delimitar cuidadosamente cada conjunto de datos. Modelamiento de la información Antes de comenzar con la OO es indispensable contar con el modelamiento de la información. Veremos: 1. de las transacciones que ellos generan.5. Vamos a comenzar suponiendo que existe un modelo de datos normalizado sobre un sistema de inventarios simplificado. Visión interna 5. • Modelar funciones: significa aclarar las reglas del negocio e identificar las relaciones funcionales entre entidades. Interfaz humana 1. Además de las funciones propias del modelamiento de la solución. como el de la figura 5-15. búsqueda de información. bitácora de uso del sistema. deberán definirse otras orientadas a la infraestructura de apoyo que requiere una aplicación: protección. Este . Modelamiento de la información 2. integridad y recuperación. eliminar la redundancia. FASES DE LA ORIENTACIÓN A OBJETOS Se presenta en esta sección una técnica para realizar orientación a objetos. • Definir el flujo de transacciones: significa visualizar cómo diferentes eventos (transacciones) van a producir cambios de estado (variación de atributos) de una entidad (maestro) a través de ciertas acciones (funciones). 5. Identificación de clases 3.

de uso (uno a muchos) entre personas y el encabezado de transacción. al igual que entre productos y detalle de transacción. ellas deben complementarse con mucho sentido común.MODELANDO UNA SOLUCIÓN DE SOFTWARE 275 modelo tiene transacciones de ventas y compras. para: • Realizar verificaciones de existencia en el ingreso de las transacciones: sobre proveedores en el caso de compras. Encabezado de compras Detalle de compras Proveedores Clientes Encabezado de ventas Detalle de ventas Artículos Línea blanca Figura 5-15. se aprecian las siguientes relaciones entre las clases: de pertenencia entre encabezado y detalle de la transacción. respecto a clientes en el caso de ventas y sobre artículos en ambos casos. Más que presentar recetas. el contenido de las fases es una guía para la acción. por ejemplo. El resultado esperado es el modelo de datos generalizado. Identificación de clases Durante esta fase se realiza el proceso de generalización. • Actualizar el maestro de artículos al terminar el ingreso de una transacción. clientes y artículos de línea blanca. cada una de ellas posee la estructura encabezado-detalle. . para rebajar el saldo en el caso de ventas y para sumar el saldo y calcular costo promedio en el caso de compras. 2. En ésta. como el de la figura 5-16. Modelo de datos simplificado de inventarios Los símbolos corresponden a relaciones unos a muchos: Relación de pertenencia Relación de uso También existen las relaciones funcionales entre entidades. con el fin de definir las clases y objetos que formarán parte del sistema. También incluye los maestros de proveedores.

tal como si estuviéramos llenando una factura. siguiendo el mismo ejemplo de los puntos anteriores. La clase persona es una generalización de clientes y proveedores. Visión externa Significa definir el protocolo del sistema.276 JUAN BRAVO C. Modelo de datos generalizado Se obtuvo al modelo de la figura 5-16 a partir del modelo de datos de la figura 5-15. Modelo funcional generalizado Observaciones respecto a la figura 5-17: • Se agregó una nueva clase: ingreso de transacción. Ésta representa el ingreso de un documento directamente en la pantalla del equipo. Encabezado de transacción Personas Detalle de transacción Productos Figura 5-16. cuyo objetivo es mostrar las interacciones entre las clases. La principal herramienta en esta fase es el modelo funcional generalizado. La clase productos es una generalización de artículos de línea blanca. todos los mensajes válidos que activarán las funciones de los objetos. . Las clases encabezado y detalle se obtuvieron de los elementos comunes de las entidades ventas y compras. es decir. Se presenta en la figura 5-17. 3. Encabezado de transacción C/E Mensaje 1 Ingresar transacción Personas Detalle de transacción C/E Mensajes 4 y 5 Productos Figura 5-17.

siempre el ingreso de datos pasa a través de un almacenamiento transitorio. . Visión de conjunto del modelo El modelo funcional generalizado lleva un mayor nivel de detalle. En la práctica. 72 Incluir todos los datos en la pantalla simulando el documento original equivale a un proceso de desnormalización del modelo de datos. como en el caso de la figura 5-18. e implícitamente cuando los datos quedan en la memoria del equipo o de la pantalla. eso justifica darle al ingreso de datos el tratamiento de una clase a nivel del diseño. Desde el punto de vista de implementación. así se puede lograr la necesaria visión global que tanto ayuda en el perfeccionamiento de la aplicación.MODELANDO UNA SOLUCIÓN DE SOFTWARE 277 • Se utilizó este símbolo para graficar la clase de ingreso de datos72: Ingresar transacción • Se usó la abreviatura C/E para condición de existencia. Explícitamente cuando en el procesamiento batch-interactivo los datos se guardan en una tabla de transacciones del día. En ambos casos. como un mapa. el ingreso de diferentes tipos de transacciones es bastante similar. ¿Por qué darle tratamiento de una clase al ingreso de datos? Porque refleja de mejor manera la realidad. es un modelo que representa toda la aplicación. existe almacenamiento intermedio y mucha funcionalidad.

el mensaje 1 —que tiene por misión solicitar agregar un nuevo documento a la clase transacciones— se envió sólo al encabezado. 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. detalle y totales según formato 1 Aceptar datos 2 Cuadrar totales C/E • Rut Nombre Dirección Teléfono 1 Agregar 2 Consultar 3 Imprimir Detalle de transacción • Nº documento • Código artículo Costo Cantidad 1 Cálculo total Productos C/E Mensajes 4 y 5 • Código artículo Tipo artículo Descripción Último costo Saldo 1 Agregar 2 Consultar 3 Imprimir 4 Sumar saldo 5 Restar saldo Figura 5-18. . Un mensaje implícito es que cada una de estas funciones generalizadas es también una clase en otro nivel de abstracción. Encabezado de transacción • Nº documento Fecha Rut persona 1 Agregar 2 Consultar 3 Imprimir C/E Mensaje 1 Personas Ingreso de transacción 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).278 JUAN BRAVO C. • Los mensajes 4 y 5 sobre inventarios se refieren a sumar o restar el saldo del artículo. Modelo funcional generalizado y detallado En la figura 5-18 se puede apreciar que: • 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.

En la figura 5-19 se muestra la visión interna de la clase productos. con los mismos elementos que la clase.MODELANDO UNA SOLUCIÓN DE SOFTWARE 279 Por ejemplo. atributos y funciones— y la tabla de objetos. Nótese que la tabla de objetos consta solamente de una ocurrencia. es una excelente opción darse normas de reutilización al interior de la organización o en pequeñas agrupaciones de empresas. 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á trabajando en la modularidad y se busca intercambiar y comercializar clases. todavía está en proceso de consolidarse. Visión interna En la visión interna se describen minuciosamente cada uno de los tres componentes de la clase —características propias. Mientras tanto. incluida en la figura 5-18. . sin embargo. 4.

: suma unidades al saldo y mueve último costo. : presentación tabular de los datos. todos los productos están en una bodega Creación: 21/4/2008 Expiración: 21/4/2014 Variables globales: costo total y descripción Código del artículo Tipo de artículo Descripción Último costo Saldo 1. Es la llave principal : numérico largo 2. procedimiento normal. diseñador de sistemas Es el maestro de artículos. con corte de control por tipo de artículo y orden por descripción en cada tipo. 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. Función normal. procedimiento normal : se agrega un artículo. búsqueda por cualquier atributo. Si queda negativo. asociado a la tabla de traducción 18 : alfanumérico largo 30 : numérico largo 6 : numérico largo 6. En este tipo de modelos es frecuente referenciar funciones generalizadas. : sin el costo.280 JUAN BRAVO C. con signo. Resta saldo Objeto Artículos de línea blanca Funciones Figura 5-19. También se normaliza la notación de los atributos. parámetros: código y unidades. con signo.2 puede significar: atributo numérico de 6 enteros y dos decimales. num – 6. Si el saldo queda negativo. 15 Productos (PR) Propietario: Juan Pérez. Suma saldo 5. por ejemplo. Crear 2. Consultar 3. : resta unidades al saldo. Parámetros: los 5 atributos. Visión interna de la clase productos . Imprimir : numérico largo 5. clase productos Atributos 4. Tabla de objetos. unidades y costo. parámetros: código.

sin diferencias entre sí. Ambos deben existir. stock mayor a unidades por vender. como la verificación de existencia entre las clases transacción y personas de la . Dos niveles de funcionalidad En la OO existen dos niveles de definición de funcionalidad. • Personas: podría suceder que la descripción de clientes y proveedores sea igual. número 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. Ingreso de transacción Encabezado. En el primer nivel se asocian procedimientos lógicos a atributos individuales de un objeto. Mensaje 5 Crear proveedor y artículo si no existen. Enviar mensajes para verificar Existencia de personas y artículos. vemos la descripción de la clase Ingreso de transacción.MODELANDO UNA SOLUCIÓN DE SOFTWARE 281 En la siguiente figura. Enviar solicitudes para actualizar el stock Objeto Ingreso de ventas Ingreso de compras Tabla de objetos. Cuadrar totales para referencia. en tal caso. Mensaje 4 Figura 5-20. la tabla sería similar a la de productos de la figura 5-19. clase Ingreso de transacción Atributos Funciones Indicar stock del producto Deben cuadrar totales. señalada en el punto anterior. detalle y totales según Formato de pantalla adjunto Aceptar datos y actualizar línea a línea cada producto.

Generalmente esta funcionalidad viene definida desde el modelo de datos. acerca de ingeniería de software. 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 funcionamiento pleno. figura 5-18. en otras palabras. 5. la funcionalidad puede ser generalizada. dedicamos una sección al diseño de estas interfaces. En el capítulo 2. serían clases en otro nivel de abstracción. . En ambos casos.282 JUAN BRAVO C. tal como agregar un artículo u obtener un informe. En el segundo nivel se define funcionalidad sobre conjuntos de atributos.

es indispensable considerar su cultura y nivel de madurez. Personalización del objeto 2. especialmente en cuanto a respetar normas internas y con el medio73. Reutilización de código 3. 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.6. Veremos: 1. pensar que “yo soy el objeto” y comenzar a hacernos preguntas. Como técnica de definición es muy útil “personalizar” el objeto. 73 . Personalización del objeto La forma ideal de trabajo en la orientación a objetos es entre pequeños equipos (teams) donde participen usuarios y profesionales de la informática. el funcionamiento del sistema. 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 objeto. Construcción de un modelo de objetos 1. entre todos. mejor aún. tal como en el enfoque sistémico. Esta es una excelente técnica para refinar la comunicación entre los objetos… y entre las personas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 283 5. En un grupo de trabajo cada uno de los participantes puede tomar el rol de un objeto para lograr simular. INCORPORACIÓN DE LA TECNOLOGÍA DE OBJETOS Para una incorporación exitosa de la tecnología de objetos en la organización.

Separar la esencia del objeto de su comportamiento en un instante del tiempo. Para lograr productividad tenemos que abandonar la artesanía en la programación. porque cada función incorporada al objeto puede ser realizada utilizando los servicios de una rutina catalogada a través de una buena parametrización o mediante mensajes. entre otras. no lo digo para desalentar. además de la mayor economía en el mediano plazo. a veces. • Incentivos cuando se construye una función que será reutilizable El medio cultural latinoamericano no es proclive a estas iniciativas. sino que un esfuerzo sistemático de mejoramiento de una clase. 2. una obra de arte irrepetible. Aunque también es una alternativa la generación de código ad-hoc con una herramienta de productividad. como en Japón. ¡cuánta mayor eficiencia podemos lograr al perfeccionar muchas veces las mismas rutinas! No es sólo corregir un error. reconociendo de antemano el verdadero esfuerzo de cambio . lo que en el caso de la orientación a objetos es perfectamente factible. donde cada programa es. las siguientes condiciones: • Incentivos económicos para quienes completen una aplicación con un alto componente de reutilización. Es también una buena práctica para evitar confundir el contenido con la relación. • Una biblioteca de componentes reutilizables a cargo de personal de prestigio. desperdiciándose lamentablemente todo el tremendo aprendizaje que el programador obtuvo en ese código. en comparación con el 25% de reutilización en Estados Unidos. que efectúe control de calidad de alto nivel para cada función aceptada. no es suficiente con una arenga del jefe de informática a sus subordinados. La reutilización del código tiene en Japón una prioridad tan alta que aproximadamente el 75% de cada aplicación se construye con componentes reutilizables. igual que entre los seres humanos.284 JUAN BRAVO C. ¿qué porcentaje de las aplicaciones se construye con código reutilizable?… El principal beneficio de la reutilización. sino para tomar en cuenta la realidad y adaptar apropiadamente las estrategias. Reutilización de código Una idea largamente acariciada es la reutilización de código. donde regularmente se proveen. es el perfeccionamiento continuo del código de cada función. Para incentivar la reutilización. En el departamento de sistemas de su empresa. Es indispensable crear ambiente y dar señales claras en esa dirección.

Más concretamente. Construcción de un modelo de objetos ¿Cómo se construye un modelo de OO? Se puede implementar con programación tradicional o te tipo OO. 3. Como técnica. 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 integradores. aún así es una buena inversión. supongamos que ya tenemos listo nuestro diseño. Al principio puede ser difícil y caro. porque el diseño es independiente de la implementación tecnológica. en la medida que se desarrollen y generalicen productos apropiados. entonces podemos implementarlo con: • Sistemas Administradores de Bases de Datos orientados al objeto. Los desarrolladores construyen clases. En este esquema. Esto es muy interesante. • Lenguajes de tercera generación tales como Cobol y RPG. actividad reservada a los programadores más hábiles de la instalación. • Adaptaciones al código generado por otras herramientas de productividad. propias o externas. porque los retornos son altos en el mediano y largo plazo. aunque el apoyo a las aplicaciones administrativas todavía es bajo. las que pueden ayudar en el modelamiento y generar código en ambientes con o sin bases de datos. porque en la práctica significa que en un equipo de integradores pueden participar usuarios.MODELANDO UNA SOLUCIÓN DE SOFTWARE 285 que será necesario realizar. las clases representan código reutilizable. es muy útil comenzar con equipos piloto que muestren rápidamente resultados en la línea de reutilización. • Otras alternativas… . • Bases de datos relacionales a través de herramientas especiales. Los integradores toman las clases y las adaptan para crear objetos de aplicaciones particulares. bases de datos o cualquier otra forma. Es posible que esta sea en algún momento la mejor opción. • Herramientas CASE orientadas al objeto. buscando amplia aplicación de código reutilizable. eventualmente ellos podrían completar una aplicación con muy poca programación.

la identidad personal y el proceso de generalización.286 JUAN BRAVO C. la simplicidad final del concepto. Una reflexión sobre la mayor naturalidad de la tecnología de objetos: hemos llegado hasta un punto donde estamos incorporando al modelamiento una serie de características típicamente sociales o humanas. . Siempre en la línea de entregar en estas páginas un mínimo indispensable. el enfoque sistémico. la comunicación de mensajes. por ejemplo. como la personalización de objetos. transformar las clases en entidades concretas o tomar los atributos desde un diccionario completo de los datos de la organización. ¿qué viene después? Creemos que más estándares y mayor énfasis en trabajar metodológicamente. no se ha querido romper la unicidad incorporando particularizaciones.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 287 CAPÍTULO 6. UNIFIED MODELING LANGUAGE (UML) .

aunque la idea queda mejor expresada con: Modelamiento Visual del Software. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales . TEORÍA DE MODELOS CAPÍTULO 2. ORIENTACIÓN A OBJETOS CAPÍTULO 4. expresión que se está utilizando cada vez más en español. No obstante. Se le considera parte del desarrollo tecnológico de un modelo de negocios. tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). No preescribe un proceso para modelar un sistema. 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). como UML incluye los diagramas de casos de uso. MODELAMIENTO DE DATOS CAPÍTULO 3. enfocado en la definición de los requerimientos de la aplicación. CAPÍTULO 7. INGENIERÍA DE SOFTWARE CAPÍTULO 1. UML CAPÍTULO 5. Popkin Software and Systems http://es.org UML significa literalmente Lenguaje Unificado de Modelamiento. Esta es la sexta competencia considerada para apoyar la elaboración de modelos de una solución de software. se le considera estar dotado de una aproximación al diseño centrada en el problema con los casos de uso. Capítulo 6.288 JUAN BRAVO C.tldp. por lo tanto. HERRAMIENTAS TI CAPÍTULO 6. no un método. visualización y documentación de los productos de software. El Diagrama de Caso de Uso nos da el punto de entrada para analizar los requisitos del sistema y el problema que necesitamos solucionar. UML está orientado a la especificación. Es indispensable que el analista maneje UML porque es el único estándar en esta materia. también se trata de una responsabilidad profesional. Unified Modeling Language (UML) UML es una notación.

en este capítulo veremos los modelos y en el anexo 7 podrá ver un caso completo. Ha sido perfeccionado en el tiempo y la versión actual es la 2. Toshiba y Microsoft) destinada a fijar estándares en la industria con la tecnología de objetos. 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 .0. Es mucho lo que se puede decir de UML. Unisys. organización creada por las empresas líderes mundiales de la industria del software (entre las cuales se encuentran IBM.evolucion. los doctores Grady Booch. Jim Rumbaugh e Ivar Jacobson. el cual puede bajar desde la página www.MODELANDO UNA SOLUCIÓN DE SOFTWARE 289 UML surgió de los aportes combinados de tres pioneros en el campo del modelamiento orientado a objetos.cl. La primera versión de UML estuvo disponible en 1997. a petición de la OMG (Object Management Group). Alcatel.

Diagrama de estructura compuesta 5. Diagrama de objetos 4. MODELOS DE UML La versión 2. 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. Diagrama de paquetes Diagramas de comportamiento. Diagrama de tiempos 13. Uso de herramientas . Diagrama de estados Diagramas de Interacción. Diagrama de casos de uso 9. los cuales se concentran en los elementos que deben existir del sistema: 1. es aplicable en todas las etapas del desarrollo. Diagrama de secuencia 11. es porque hace referencia al sistema computacional. 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 despliegue 6. 6.1. Cuando en el contexto de UML se usa la palabra sistema. Diagramas de estructura. Diagrama de colaboración 12. Casos de uso 2. a modelos individuales o a cualquier elemento que sea identificado individualmente. Diagrama de componentes 3. Diagrama de clases 2. En UML se usa el término artefactos para referirse a diversas agrupaciones de modelos.290 JUAN BRAVO C. Diagrama de actividades 8. utilizados para reflejar las acciones del sistema: 7.0 de UML tiene 13 tipos de diagramas. Veremos: 1.

Ejemplo de un caso de uso de alto nivel . Figura 6-1. Se aplican a la definición de los requerimientos computacionales del sistema de información. alguien fuera del sistema que interactúa con la aplicación. Incorpora el concepto de actor. las excepciones podrían dar origen a otros casos de uso. Terminal en la tienda Vendedor Consultar situación del cliente Saldo de crédito y posibilidades de cuotas. no explicamos que sucede si esa identificación es inválida. Casos de uso Los casos de uso (use case) son los modelos más conocidos de UML. El ambiente donde suceden los hechos es el dominio. Los casos de uso pueden ser llamados: • De alto nivel. si la narración dice: se ingresa la identificación del cliente. En algunos casos. permiten mostrar las interacciones con el usuario. es un ítem específico de funcionalidad.MODELANDO UNA SOLUCIÓN DE SOFTWARE 291 1. en este caso el vendedor. desde su perspectiva. Apoyo en realización de cálculos respecto a financiamiento. un vendedor consulta en su terminal por la información de un cliente. El caso de uso describe lo que importa al usuario. simplemente seguimos el curso normal de los sucesos. las excepciones son incorporadas como observaciones al final del texto. pueden contener cientos de oraciones. es decir. El caso de uso describe el curso normal de los eventos. Por ejemplo. 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”. explicados en dos o tres oraciones. Por ejemplo. en la figura 6-1 se aprecia que en una tienda minorista. También es cualquier punto de interacción con el computador. • Expandidos. se incorpora una descripción minuciosa destinada a la implementación computacional. principalmente detectados desde las actividades del flujograma de información.

son indispensables. BOUML. Uso de herramientas Existe una amplia gama de herramientas que ayudan en los modelos de UML (Visio. Enterprise Architect y muchas otras). Existe en Internet una amplia variedad de software libre para trabajar con UML. Fujaba. incluso la mayoría de estas herramientas permiten generar código. La recomendación es usarlas. por ejemplo: ArgoUML. Rational. UML Studio. 2. . Además. tienen la ventaja de generar el código de la aplicación en forma automática y son vitales para la comunicación de los modelos (generalmente en XML).292 JUAN BRAVO C. gModeler MonoUML y otras. realmente facilitan el trabajo y si el sistema es grande.

Entonces. todos los casos de uso que tienen relación con un proceso incluido en el flujograma de información. para que efectivamente pueda ser aplicado en la mayoría de las organizaciones. un dominio (en este caso terminales del área de adquisiciones) y una acción con un verbo en infinitivo dentro de cada óvalo. En el desarrollo en espiral. Caso de uso de alto nivel 3. Planteados en el espíritu del método GSP de trabajar con el mínimo indispensable. En la figura 6-2 se presenta un diagrama de casos de uso para el ámbito de adquisiciones. Veremos: 1. Contratos 1. Diagrama de secuencia del sistema 6. 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 principales modelos de UML en la etapa de análisis74. 74 Más detalle en libro Gestión de proyectos de procesos y tecnología.MODELANDO UNA SOLUCIÓN DE SOFTWARE 293 6. . se espera que el universo completo de casos de uso esté levantado al menos como diagramas de casos de uso. por ejemplo. Se observa que cada actor puede interactuar con más de un caso de uso. Visión dinámica del sistema 7. Diagrama de estado 8. El diagrama de casos de uso incluye uno o varios actores (que pueden ser personas u otros sistemas computacionales identificados con el símbolo tipo dibujo de niño). Modelo conceptual 5. Diagrama de casos de uso El diagrama de casos de uso representa una agrupación de casos de uso. los casos de uso seleccionados para la respectiva vuelta de la espiral se transforman en casos de uso expandidos. En el anexo 7 se pueden apreciar estos modelos para una aplicación real y detallada de UML. Diagrama de casos de uso 2.2. Caso de uso expandido 4.

124): “Si un caso de uso incorpora dos o más escenarios con diferencias significativas.294 JUAN BRAVO C. Entonces deciden incorporar esa necesidad común. • Separación del comportamiento variable. “Comprobar reserva” como otro caso de uso referenciado por los dos anteriores. Explican Stevens y Pooley (2002. en este caso aplica la forma <<extend>> sobre una línea punteada que apunta hacia el caso de uso original. se puede decidir que sería más claro mostrarlos como un caso principal y uno o más casos . Ejemplo de un diagrama de casos de uso En este diagrama se utilizan dos características que provienen de la orientació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. 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”. Señalan Stevens y Pooley (2002. p. Por ejemplo. pueden ocurrir varias cosas diferentes dependiendo de las circunstancias. 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 casos de uso utilizando un componente. Cotizador Terminales del área de Adquisiciones Cotizar Aprobar cotización Ingresar O/C Aprobar O/C Enviar O/C O/C = Orden de Compra Jefe de Adquisiciones Administrativo de Adquisiciones Figura 6-2. p.

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”. Permite conocer un poco del requerimiento. La O/C queda disponible para ser enviada al proveedor luego de la aprobación electrónica por el jefe de adquisiciones Figura 6-3. Caso de uso de alto nivel El caso de uso de alto nivel se caracteriza porque la narración es breve. Entonces deciden sacar esa excepción como otro caso de uso llamado “Rechazar préstamo” y la relación extend señala que pertenece al caso de uso original.MODELANDO UNA SOLUCIÓN DE SOFTWARE 295 secundarios. En la figura 6-4 se aprecia un ejemplo del caso de uso expandido Ingresar orden de compra. Cuándo hacer esto es un problema de juicio. 2. tal como se aprecia en la figura 6-3. Por ejemplo. . Recuérdese que se usa aquí el concepto de “curso normal de los eventos”. ya que siempre se pueden mostrar situaciones variables en un caso de uso. actor(es) y dominio. las excepciones se anotan al final para no romper la secuencia de la historia. Terminal en bodega Administrativo de Adquisiciones Ingresar O/C Ingresa la Orden de Compra a partir de los documentos de cotización a proveedores. algo de la acción. Caso de uso expandido El caso de uso expandido incluye una narración en todo detalle e incluye las interfaces visuales. Caso de uso de alto nivel Ingresar orden de compra 3.

Ingresar las unidades en (K) 10. . Verifica que proveedor exista. obtiene y despliega nombre y fono en (E) y (F) 6…. producto en (H) obtiene y despliega la descripción y el precio en (I) y (J) 9. Calcula el subtotal y despliega en (L) 10. No siempre una acción del actor tiene respuesta. B. 2… Incluye interfaces detalladas de E/S Figura 6-4. como la acción 1: “Tomar la O/C desde el archivador” (que está en algún mueble cercano). Tomar la O/C desde el archivador 2. Ingresar Rut en (D) 5. Ingresar Nº O/C en (A) 3.296 JUAN BRAVO C. Si el número de O/C ya existe. Excepciones: 1. Para cada línea: Para cada línea: 7. Verifica existencia del producto. las excepciones van aparte. Ingresar el código de 8. en este caso los campos se indican con letras mayúsculas entre paréntesis (A. vea caso de uso “Corregir Correlativo”. …) para identificar la ubicación del respectivo campo en la interfaz visual. tal como se aprecia en la figura 6-5 (copiada desde el anexo 7). Funciones relacionadas: Curso Normal de los eventos Acción del actor Respuesta del sistema 1. El caso de uso se complementa con una copia del documento orden de compra y de la interfaz de la pantalla. Terminal del Administrativo de Adquisiciones Administrativo de Adquisiciones Ingresar O/C Resumen: (el mismo del caso de uso de alto nivel). Dar OK a la línea 11…. Caso de uso de expandido Ingresar orden de compra Tiene dos columnas: acción del actor y respuesta del sistema. Verifica correlativo y envía respuesta en (B) 4.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

297

Interfaz de Entrada
Guía Interna de Recepción por Compra
Código Enc. Recepción RUT Proveedor Dirección Proveedor Comuna

C
-

Encargado Recepción Razón Social Proveedor

D F

Nº Guía Recepción Fecha Recepción
e-Mail

A

B

E

G
Ciudad M

H
Fax

I

J

Fono

K N
Precio

L O
Valor Neto

Guía de Despacho de Proveedor Nº

Fecha G/ D. Proveedor

Nº de O/C.

L.

Código

Descripción

Cantidad

LL

P

Q

R

S

T

Cerrada Anulada

W Y

Cerrar X Anular Z

XX
Salir

V
Grabar Total acumulado

U

Figura 6-5. Ejemplo de Interfaz visual detallada

4. Modelo conceptual
El modelo conceptual define responsabilidades y el dominio del sistema computacional, al comienzo asociado a los casos de uso identificados. Es un modelo que se va construyendo en paralelo con los casos de uso. Identifica los conceptos más relevantes del mundo real en el dominio respectivo: roles de personas, tipos de documentos o elementos físicos. También identifica las asociaciones entre conceptos con palabras de enlace: usa, registra 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.

298

JUAN BRAVO C.

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:
Encabezado de O/C compuesta por se asocia a 1 1..* contiene * existe en 1 existe en * almacena 1 Bodega Productos contiene * existe en 1 Proveedores

Líneas de la O/C

Figura 6-6. Ejemplo de modelo conceptual sistema de compras

En la figura 6-6 se puede apreciar que: • Una O/C está compuesta por 1 ó 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 gruesa) 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.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

299

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.

Encabezado de O/C Nº O/C Fecha compuesta por

contiene existe en * 1

Proveedores Rut Nombre

Líneas de la O/C Unidades Precio

contiene existe en * 1

Productos ...

existe en * almacena 1 Bodega ...

Figura 6-7. Ejemplo de modelo conceptual con atributos

5. Diagrama de secuencia del sistema
El objetivo del diagrama de secuencia es identificar las operaciones de la aplicació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 conceptual. A este nivel de especificación, la aplicación sigue siendo como una caja negra 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.

300

JUAN BRAVO C.

Administrativo

Sistema

Ingresar Nº de O/C Ingresar código de prod. Repetir hasta que no haya más productos Ingresar cantidad Dar OK a la línea

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 central de la orientación a objetos: el encapsulamiento, es decir, un sólo todo (clase u objeto) con los atributos y los métodos. Cuando se trata del primer caso de uso que estamos desarrollando en un sistema, el diagrama de secuencia y la visión dinámica son iguales, desde el segundo 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.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

301

Sistema Caso de uso Aprobar cotización Ingresar Nº de cotización Dar OK al documento ... Ingresar Nº de O/C Ingresar código de producto Ingresar cantidad Dar OK a la línea

Caso de uso Ingresar O/C

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 observa aplicado a nuestro ejemplo de ingreso de una orden de compra.

302

JUAN BRAVO C.

Ingresar línea de O/C Ingresar Nº de O/C En espera de la O/C Introducción de líneas Terminar la O/C Imprimir la O/C En espera del cierre

Figura 6-10. Ejemplo de diagrama de estado

El diagrama de estado aplica principalmente en aplicaciones de 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.
Contrato Identificación: nombre de operación y parámetros Responsabilidades: descripción informal de las responsabilidades u objetivos de la operación Tipos de datos: conceptos que afecta o clases Referencias 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 ...

MODELANDO UNA SOLUCIÓN DE SOFTWARE

303

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.

Contrato Identificación: Dar OK al ingreso de la línea Responsabilidades: 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 hay Notas: nada especial Excepciones: la no existencia de la línea en el sistema ya fue validada con el ingreso de O/C. Salida: no hay Precondiciones: 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.
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.

Veremos: 1.. 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. En la figura 6-13 se observa este diagrama para el ejemplo de la orden de compra. Proveedores Encabezado de O/C Nº O/C Fecha Crear línea Imprimir compuesta por 1 contiene * existe en 1 Rut Nombre Crear proveed.. Nace desde el modelo conceptual e incorpora las funciones necesarias para cumplir con el objetivo de los casos de uso. 6. Corresponde a la visión interna de la aplicación. Figura 6-13. 1 Bodega .3.. . Diagrama de diseño de clases 2.. 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 principales modelos de UML en la etapa de diseño75..* contiene * existe en 1 existe en almacena * Líneas de la O/C Unidades Precio Agregar línea Productos . Ejemplo de diagrama de diseño de clases 75 Más detalle en el libro Gestión de proyectos de procesos y tecnología. Modificar Rut Modificar nombre se asocia a 1.304 JUAN BRAVO C.

cant. cant. Ejemplo de diagrama de colaboración En este método de desarrollo aplicamos la técnica de espiral. pre) Terminal del administrativo 1: Crear línea de O/C (cod. • 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). pre) Encabezado de O/C 1. es decir.MODELANDO UNA SOLUCIÓN DE SOFTWARE 305 2. Corresponde al detalle de cada clase e instancias (objetos) específicas en una tabla de diferencias. Operación: Dar OK al Ingreso de la línea de O/C Ingresar producto (cód. pre) Líneas de la O/C Figura 6-14. hacer una revisión de la biblioteca de clases77 (que en un esquema de orientación a objetos es un requisito). 77 Se supone la existencia de la biblioteca de clases.1: Crear (cod. • Detalles de implementación: se responde a ¿qué clases podemos utilizar? Ya sea de la misma instalación o del medio. 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. la condición de existencia. cant. por este motivo se prefiere avanzar en características de la implementación a nivel del diseño. donde se diluye un poco la independencia de la implementación tecnológica. 76 . En la figura 6-14 se presenta un ejemplo de diagrama de colaboración para el ejemplo del ingreso de orden de compra. por ejemplo.

CAPÍTULO 7. HERRAMIENTAS DE LA TECNOLOGÍA DE INFORMACIÓN .306 JUAN BRAVO C.

Esta es la séptima competencia considerada para apoyar la elaboración de modelos de una solución de software. Por supuesto. INGENIERÍA DE SOFTWARE CAPÍTULO 1. 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. p. más que eso. la conectividad es la propiedad que permite hacer esto. tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). Éstas incluyen desde poderosos procesadores de texto hasta sofisticados sistemas administradores de bases de datos. MÉTODO PARA LA GESTIÓN DE PROYECTOS Competencias necesarias para modelar aplicaciones computacionales . HERRAMIENTAS TI CAPÍTULO 6. ORIENTACIÓN A OBJETOS CAPÍTULO 4. TEORÍA DE MODELOS CAPÍTULO 2. La metáfora sugiere correctamente que esto es sólo en parte una propiedad de los elementos conectados. Perdita Stevens y Rob Pooley (2002. CAPÍTULO 7. Es una responsabilidad profesional para aumentar la productividad del modelamiento y para compartir en equipos de trabajo. UML CAPÍTULO 5. tienen que ser compatibles unos con otros y esto depende de la presencia de una arquitectura adecuada. MODELAMIENTO DE DATOS CAPÍTULO 3. pasando por múltiples productos de ayuda directa a usuarios y especialistas en desarrollo de aplicaciones. 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 307 Capítulo 7. 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. Los componentes tienen que ser elementos que completan las necesidades del sistema en su totalidad.

lo habitual es que el especialista en informática tenga la responsabilidad de construir aplicaciones de mayor nivel de complejidad. es decir. en las cuales la herramienta será sólo un apoyo y siempre que se pueda integrar al esquema de desarrollo del departamento de sistemas en particular. Sí ocurre que la incorporación de la nueva herramienta acarrea a veces nuevas contrataciones. por ahí aparecen mensajes del siguiente tipo: es posible que las aplicaciones se construyan casi solas o que el mismo usuario pueda construir su propio software sin depender del programador. Luego estudiaremos las herramientas de uso específico. como procesadores de texto. para concluir con las herramientas de apoyo para la producción de software.308 JUAN BRAVO C. aquéllas orientadas a temas precisos. Después. revisaremos las soluciones de software generalizadas. para apreciar la evolución que derivó en las herramientas de la tecnología de información. más conocidas como herramientas CASE. Abordaremos el tema con una introducción general a los lenguajes de cuarta generación. extrapolándose las conclusiones al resto del software. planillas electrónicas o consultas de bases de datos. debido a la complejidad de su manejo y al aprovechamiento de las nuevas oportunidades que genera su mayor potencial. esa es una parte pequeña de la realidad. siendo válido. Para tranquilidad de muchos programadores. hasta hoy no se ha visto el reemplazo de un especialista por una herramienta de productividad. 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 . Esos y otros mensajes se demuestran con aplicaciones muy pequeñas y estructuradas. En el caso de las herramientas de ayuda en la producción de software conviene actuar con prudencia. algunos productos los pueden usar directamente los usuarios finales. Sin embargo.

En las siguientes páginas se presenta una clasificación más acabada de estos productos. para aumentar la productividad e incorporar al usuario final en el proceso informático. De aquí que el título del capítulo fuera genérico: herramientas de la tecnología de información. Independientemente de las denominaciones. directamente en el computador. porque da la idea de un simple lenguaje de programación más avanzado. Crisis del desarrollo Existe desde los inicios de la computación una crisis de productividad de las áreas de sistemas. herramientas CASE. Workflow. Groupware y otras. las nuevas herramientas incluyen una amplia variedad de nuevos productos: procesadores de texto. 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. El término lenguaje de cuarta generación puede ser confuso.1. lo cual ya no es tan importante y a futuro será una consideración menor. él puede participar intensamente! Lo ideal es un trabajo de conjunto entre el usuario y el analista. resulta insuficiente para reflejar la riqueza y amplitud de los nuevos productos de software orientados tanto a usuarios finales como a profesionales de la informática. EVOLUCIÓN DE LOS LENGUAJES DE COMPUTADOR El desarrollo de software no ha ido a la par con los espectaculares aumentos en la rapidez. se les comenzó a llamar herramientas de productividad. nombre que a veces compite con el de herramientas de desarrollo cliente–servidor. debido al substancial mejoramiento del hardware. se manifiesta en largas “colas” de aplicaciones pendientes por . Además. Estas nuevas herramientas fueron agrupadas inicialmente bajo el nombre lenguajes de cuarta generación y más recientemente. Es decir. planillas electrónicas. la participación del usuario en el proceso de desarrollo ha estado restringida a reuniones con los especialistas. como apoyo en la especificación de requerimientos o trabajando juntos. No obstante. rendimiento y confiabilidad del hardware. administradores de bases de datos. 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. ¡Hoy. la industria de la computación ya se percató de este hecho y comenzó a desarrollar una amplia variedad de nuevas herramientas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 309 7.

Desde el punto de vista del usuario ejecutivo. Es cierto que los nuevos lenguajes ayudan pero la gran respuesta es incorporar método. En la figura 7-1 están señaladas a la izquierda las primeras cuatro categorías. dejando de lado largas esperas. transistores en la segunda y circuitos integrados en la tercera— han surgido varios niveles de lenguajes: de máquina. sensaciones. porque realmente ignoramos todavía su potencial. además. la solución significa “hacer trabajar” al computador. aunque sin coincidir con la aparición de nuevas generaciones de computadores —caracterizadas por equipos construidos con tubos en la primera generación. Junto con el aumento de la capacidad del hardware. de cuarta generación y lo que hemos llamado provisoriamente las nuevas herramientas. donde intervienen emociones. . de alto nivel. diversas energías o fenómenos culturales. porque busca copiar capacidades humanas. las nuevas herramientas. la última y más reciente. con puntos suspensivos. También está en experimentación lo que denominan una quinta generación. tomar cierto grado de decisiones y crear sus propios procedimientos en la resolución de problemas. se indica arriba. reuniones. reconocer mensajes incompletos. las que con frecuencia llegan a representar más de 5 años de trabajo.310 JUAN BRAVO C. motivaciones. aún está lejos de alcanzar resultados prácticos. antecedentes históricos. simbólicos. La quinta generación de lenguajes no será analizada aquí porque excede los objetivos de este libro. donde se estudia la inteligencia artificial. Se espera que los sistemas producidos en esta quinta generación sean capaces de aprender de sus errores. desarrollar. especificaciones y cambios de especificaciones por obsolescencia de las anteriores. tal como vimos en el capítulo 1.

MODELANDO UNA SOLUCIÓN DE SOFTWARE 311 Las nuevas herramientas … … Groupware o workflow Herramientas cliente/servidor Imágenes Integración total Gráficos Generación de aplicaciones Bases de datos simples Herramientas CASE Planillas electrónicas Bases de datos u objetos Procesadores de textos Ciclo completo de desarrollo Lenguajes de cuarta Para construcción de generación De uso específico aplicaciones Amistosos y Productivos Código compilado o interpretado Bajo número de instrucciones COBOL/FORTRAN/C… Lenguajes de alto nivel Muy poderoso Portable Códigos de instrucción simbólicos Lenguajes Uso de símbolos para variables Simbólicos Compilación Macros Muchas instrucciones Lenguajes de Mapa de memoria máquina Ejecutable OFF ON Figura 7-1. Clasificación de lenguajes de computador Veremos: 1. Lenguajes de alto nivel 4. Lenguajes de máquina 2. Lenguajes simbólicos 3. Las nuevas herramientas . La cuarta generación de lenguajes 5.

Aunque la portabilidad es substancialmente mayor que en los lenguajes de máquina. lo cual obliga a mantener un mapa del uso de memoria. mediante los cuales se obtiene un avance substancial al lograr referenciar una variable por símbolos. la programación se realiza trabajando primero en binario y más adelante en hexadecimal. El programador utiliza códigos de instrucción simbólicos. impresión y otras. porque el programa fuente no está demasiado lejos del programa objeto. el programa en lenguaje simbólico debe ser compilado. el lenguaje simbólico se acerca bastante al lenguaje de alto nivel. haciendo abstracción de su ubicación en memoria. excepto para procesar en otro computador con el mismo procesador. donde cada uno es un nemotécnico de la propia función de la instrucción (por ejemplo: en ASSEMBLER IBM. un programa simple tendrá probablemente varios miles de instrucciones. Permiten realizar funciones de entrada de datos. 1. hasta llegar a usar nemotécnicos. El programa producido con el lenguaje de máquina viene a ser un objeto que se ejecuta directamente. aún el lenguaje simbólico está muy ligado al hardware particular donde reside. Lenguajes simbólicos Son lenguajes tipo ASSEMBLER DE IBM o NEAT/3 de NCR.312 JUAN BRAVO C. la simple operación C = A + B utiliza entre cinco a diez sentencias. sin un proceso de compilación. producto de la desagregación con que obliga a programar el lenguaje. Provee máxima eficiencia. El lenguaje de máquina se caracteriza por proporcionar un conjunto de muchas instrucciones elementales. 2. Por medio de las macros. Una extensión de este lenguaje son las macros. Por ejemplo. no existiendo portabilidad. las cuales son conjuntos de instrucciones que pueden ser llamadas desde cualquier programa. AGO es un salto incondicional y AIF es un salto condicional). Lenguajes de máquina A este nivel. . Se incorpora también al lenguaje simbólico el concepto de subprograma. porque el uso de recursos puede minimizarse y porque es extremadamente cercano a la máquina. obteniéndose un programa objeto en lenguaje de máquina que todavía es bastante eficiente en cuanto al uso de recursos. Se controla cada variable según su posición en memoria. Para ser ejecutado.

En la práctica. su universalidad y nuevas versiones que incorporan conceptos tales como orientación a objetos e interfaces gráficas. CLIPPER. lo que obliga a utilizar los servicios de un especialista. C y C++. la portabilidad total se ha dado solamente entre diferentes modelos de un mismo fabricante y cuando se desea trasladar el programa a un computador de otro fabricante. Lenguajes de alto nivel Los lenguajes de alto nivel se desarrollaron como respuesta a la excesiva dependencia de la máquina que presentaban los lenguajes simbólicos y para evitar la intervención de un intermediario entre el usuario y el computador.MODELANDO UNA SOLUCIÓN DE SOFTWARE 313 3. PASCAL Y CLIPPER. esto no sucedió en las aplicaciones administrativas y fue necesario contar con especialistas en lenguajes de alto nivel. debería pasar algunos exámenes de aptitud. Los lenguajes de alto nivel están mucho más cerca del usuario que los lenguajes de máquina y simbólicos. período que podría ser muy largo. en la práctica. Se han desarrollado más de 100 lenguajes de alto nivel y no más de 10 se han generalizado78. algunas versiones de BASIC. entre ellos se encuentran: COBOL. C. las instrucciones son bastante poderosas. sino que por la estructuración de la lógica de procesamiento. FORTRAN. En lo que se refiere a las grandes aplicaciones administrativas y pese a muchas predicciones en contra. En general. si insiste en programar. la portabilidad se ve afectada por las particularidades introducidas al lenguaje y por su difusión. quien. Normalmente. los lenguajes de alto nivel se orientan a determinados tipos de problemas. Es posible que siga siéndolo por muchos años. 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- 78 . 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. FORTRAN para aplicaciones científicas y COBOL para aplicaciones comerciales. Esto se pretendía evitar con los lenguajes de alto nivel. En general. RPG. Sin embargo. porque podrían ser aprendidos por el propio usuario para desarrollar sus aplicaciones. PL/1. Por ejemplo. la estructuración de lógica en los lenguajes de alto nivel ha sido “muy personal” por no decir anárquica. BASIC. Los lenguajes de máquina y simbólicos son muy complejos y la programación es lenta. Le siguen de lejos RPG. incorporan una lógica extraña y poco natural que dificulta la programación por parte del usuario. porque el lenguaje podría no estar disponible en esa línea de equipos. el lenguaje más común ha sido COBOL. La dificultad no se produce por el aprendizaje del conjunto de instrucciones del lenguaje. por la gran cantidad de código acumulado. seguir algunos cursos y luego practicar.

4. Este esquema de trabajo hizo crisis. . Es menos eficiente que el programa objeto. no exento de un cierto grado de temor y admiración.314 JUAN BRAVO C. contabilidad y remuneraciones. porque no se puede optimizar el código y debe traducir-ejecutar cada vez que el programa se llama a ejecución. el esquema predominante para el desarrollo de software había sido crear un departamento centralizado de informática. inventarios. en el cual se concentraban los especialistas encargados del desarrollo de nuevas aplicaciones y de la mantención de las antiguas. Sin embargo. lo que facilita la construcción y la mantención del código. como la programación estructurada o la programación práctica (ambas expuestas en el libro Desarrollo de sistemas de información. quienes pudieron resolver directa y rápidamente variadas necesidades. sino que al momento de la ejecución del programa se traduce y se procesa cada instrucción. cuando el usuario aprendió a sacar provecho del computador y observó que distrones” de programación. en los usuarios existía un gran desconocimiento del computador y de las técnicas empleadas por los especialistas. Tiene como ventaja que el programador ve su programa funcionando inmediatamente. una visión práctica). • Lenguajes Interpretados: esta denominación proviene del término “interpretación” como sinónimo de “traducción simultánea” entre diferentes idiomas. Aquí existe solamente el programa fuente. Hasta hace un tiempo. • 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 computador (programa objeto). Normalmente. Al mismo tiempo. Habitualmente los lenguajes de alto nivel se han clasificado entre lenguajes compilados (COBOL O FORTRAN) y lenguajes interpretados (BASIC). 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. el lenguaje de máquina generado es optimizado por el compilador (por ejemplo. ¿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 importantes y tradicionales. La cuarta generación de lenguajes Con el advenimiento de las herramientas de cuarta generación hubo una apertura de la informática hacia los usuarios. Esto significa que el código construido por el programador no está traducido de antemano. cuentas por pagar. como cuentas por cobrar.

porque lo estimaban una pérdida de tiempo dados los excesivos tiempos de respuesta. Hoy. Y aquí comienza la crisis. porque el entorno actual de la potencial aplicación era diferente al originalmente considerado. para aumentar. Un problema adicional fue la pérdida de vigencia de algunas aplicaciones en la cola. se dio cuenta de la gran potencialidad que esto significaba y pidió nuevas aplicaciones. porque no daba respuesta oportuna a sus requerimientos. se entiende su sentimiento de impotencia por poner a trabajar el computador inmediatamente en lo que él necesitaba. el rendimiento en el desarrollo de software. Amistosidad. El atraso invisible llegaba a ser tan largo como la cola de trabajos pendientes. 5. al menos en 10 veces. Otro problema fue el atraso invisible que se producía cuando los usuarios preferían no solicitar algunas aplicaciones. 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 segundas sí. excepto tal vez en las aplicaciones más pequeñas y con apoyo de una buena herramienta. Es más. Ambas tienen las características clave de amistosidad y productividad. La respuesta fueron los Lenguajes de Cuarta Generación. llegando a producirse una cola de trabajos pendientes que alcanzaba a varios años. para incorporar a los usuarios en el proceso de desarrollo. De esta manera. Las nuevas herramientas Al comienzo del uso de los lenguajes de cuarta generación. No es la idea que programe o arme un sistema. se fue acumulando cada vez mayor cantidad de aplicaciones sin desarrollar. muchos usuarios comenzaron a mirar con escepticismo al departamento de sistemas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 315 ponía de terminales. porque el departamento de sistemas no logró dar respuesta rápida a sus requerimientos. En este contexto. Se puede apreciar en esta introducción cómo fue creciendo la demanda por nuevas herramientas destinadas a incorporar al usuario en el proceso de desarrollo y aumentar la productividad en la construcción de sistemas. y productividad. tanto las herramientas de uso específico como los productos orientados a la construcción de aplicaciones tienen la característica clave de . Por incorporar a los usuarios en el proceso de desarrollo entendemos incrementar substancialmente su nivel de participación y que entienda el por qué del desarrollo. los cuales pueden clasificarse en dos grandes áreas: herramientas de uso específico y lenguajes para construcción de aplicaciones. mientras el usuario observaba su terminal y pensaba en sus aplicaciones largamente postergadas.

• Se avanzará mucho más hacia la integración total. especialmente entre las herramientas CASE y los sistemas administradores de bases de datos. 79 . Esto significa que todos los productos de la instalación se comunican plenamente entre sí y comparten los mismos recursos. incluso. sin programar. con interfaces cada vez más amistosas. De esta manera. es muy posible que veamos en el futuro cercano grandes productos que integren armoniosamente: automatización de oficinas79. Es decir. Por ejemplo: • Se intensificará la orientación total al usuario. Outlook y otras aplicaciones. el usuario simplemente usa las herramientas y navega libremente entre ellas. construcción de aplicaciones y administración de proyectos. cuando la funcionalidad vía menús no alcanza para resolver un requerimiento. obsérvese la integración del producto MS Office para Windows. como los indicados. Es el caso de la mayoría de las macros que uno puede construir en un administrador de bases de datos. especificar en forma procedural y no procedural. normalización interna y externa o participación de los usuarios. La característica clave de las nuevas herramientas de la tecnología de información es la integración total. De hecho. hay que tomar en cuenta el problema de la conversión de datos desde aplicaciones antiguas. No procedural se refiere a resolver un requerimiento a través de menús o comandos directos. íconos. los cuaComo ejemplo de esta tendencia. el cual es tan importante que algunos proyectos han fracasado porque sus patrocinadores lo han subestimado. o propio. Además. entonces se utiliza un lenguaje de alto nivel: huésped. en este caso con su particular conjunto de instrucciones. una planilla electrónica e. ¿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 probando muchas opciones. para hacer no sólo más fácil el trabajo sino también más atractivo. haciendo uso intensivo de ventanas. 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. colores y mucha simplicidad. el cual incluye Word. Procedural se refiere a estructurar lógica. bases de datos. Excel. en los actuales procesadores de texto. Powerpoint. Access. 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.316 JUAN BRAVO C. workflow. como en COBOL o PASCAL. en cuanto a organización.

UNIX. En lugar de diccionario de datos. generar informes. Hoy. procesamiento de imágenes. OS/2. procesamiento de texto. la mayor parte será generado automáticamente o se aplicará código reutilizable. se incrementará la necesidad del buen diseño de las aplicaciones. planillas electrónicas. pantallas. excepto instrucciones muy precisas en puntos bien determinados. sin tener que programar. Si es muy simple. aunque no es problema si se realiza en forma de clases. Resulta evidente que entre esas posibilidades hay muchas situaciones intermedias. . sino también formatos de pantallas e informes.MODELANDO UNA SOLUCIÓN DE SOFTWARE 317 les tendrán incorporadas o poseerán buenas interfaces a gráficos. probablemente la herramienta ayudará a definir prototipos con informes. Al mismo tiempo. o diccionario de conocimiento. realizar operaciones de actualización entre entidades o efectuar múltiples cálculos. Windows. probablemente no se requiera aportar código. ya es posible pintar pantallas. Esto depende en gran medida de la complejidad de la aplicación. consultas y otros módulos básicos que no representan más allá del 50 % de la aplicación. atravesar horizontalmente las diferentes plataformas de hardware y software. comenzaremos a escuchar con mayor frecuencia el término enciclopedia. • Disminuirá la necesidad de programación tradicional en el desarrollo de software. 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 “sistemas operativos generalizados”. buscar recorridos óptimos en consultas o apoyar la normalización de diseño. transmisión de datos. el cual incluiría no sólo características de datos. etc. almacenamiento de voz. todo el otro 50 % deberá ser programado. se estima que menos del 3 % del código total de una aplicación será incorporado por el desarrollador. capacidades lógicas para hacer algún tipo de inferencia. es decir. • La portabilidad se verá notablemente aumentada. Si la aplicación es muy compleja. ya que podremos trabajar con las nuevas herramientas en redes y con variados sistemas operativos: DOS.

modelar los datos y comunicar el modelo a una base de datos. comunicar información. Groupware 3.2. lo cual se puede estimar al menos en un 70%. ¿qué relevancia pueden tener las herramientas de uso específico sobre el desarrollo de software? Básicamente en dos aspectos: • El primero es la disminución en la necesidad de construir software de uso general. algunas herramientas de uso específico ayudan directamente en la producción de software a través de la automatización de las variadas y rutinarias labores asociadas a la producción de software. • En segundo lugar. Herramientas integradas para automatización de oficinas 2. con un simple procesador de palabras puede ordenar textos. por ejemplo: “pintar” una pantalla. Hace algunos años. Veremos: 1.318 JUAN BRAVO C. Por ejemplo. para satisfacer esos requerimientos. 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. producto de las mayores potencialidades de las herramientas. efectuar cálculos. realizar seguimiento del proyecto. hoy. 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. ordenar una tabla. imprimir etiquetas o manejar eficientemente una base de datos simple. 7. Workflow . 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.

sino también para desarrollar. también llamadas Workgroup. de Microsoft.MODELANDO UNA SOLUCIÓN DE SOFTWARE 319 1. con una coordinación central e integrando multimedia. se está transformando en uno de los productos más vendidos81 no sólo para interactuar con bases de datos. hoy es posible que un equipo se coordine para obtener promedios grupales de ponderación de factores de decisión. Todos los productos indicados han evolucionado a niveles extraordinarios en las nuevas versiones. Con ellos se reduce la necesidad de construir sistemas computacionales con personal especializado. Impresiona que antes de este tipo de procesadores debíamos construir algún pequeño sistema computacional para dar respuesta a cualquiera de estas facilidades y a otro costo. 2. en Estados Unidos se vendieron 3 millones de copias. Groupware Durante este período también surgieron las herramientas para trabajo de grupo. ACCESS. 81 Un dato: en los primeros 7 meses de venta de la versión 2. Considere solamente las facilidades del MS Word80: • Opera en el sistema operativo Windows • Está disponibles en varios idiomas. Éstas. 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. en evaluación de proyectos. Herramientas integradas para automatización de oficinas Todavía no hemos calibrado el impacto de los nuevos productos integrados de automatización de oficinas. son productos tales como NOTES. quienes pueden ahora destinar su tiempo a las aplicaciones más complejas y del negocio. principalmente a usuarios finales.0 de Access. Por ejemplo. de Lotus o el mismo Outlook de Windows. tal como lo haría un correo electrónico. además de permitir la comunicación entre los miembros de un grupo. por ejemplo. tipo Groupware. los que antes dependían sólo de la buena fe de algún profesional aislado. también permiten compartir documentos y hacer una construcción conjunta de proyectos. 80 .

por ejemplo82: • Eliminar o externalizar el proceso completo. Con las herramientas tipo Workflow se tiende a eliminar los documentos manuales y hacer todo el trabajo directamente en el computador. en particular aplicando el concepto de generalización de procesos. El nivel de amistosidad de estas herramientas debe ser muy alto.320 JUAN BRAVO C. operaciones crediticias o de ventas. • Agrupar todas las actividades para que las realice una sola persona (concepto de integralidad de la gestión de procesos). tal vez orientándose a determinados tipos de procesos. se evaluaran otras opciones. De esta forma. en lugar de tener una especie de línea de producción con cargos especializados. Ejemplos de este tipo de productos son: XNEAR. generalmente algún esquema con redes de computadores. Workflow automatiza ese flujo y administra la ubicación y avance de cada tarea. Lotus Notes y Workflow de IBM. cada uno de los mismos participantes puede realizar el proceso completo. • Agrupar las actividades del proceso para que un equipo de personas las realice en la misma ubicación. con o sin una herramienta Workflow. Para cumplir el objetivo de un proceso. porque serán empleadas por la mayoría de los usuarios de la organización. generalmente se requieren diversas actividades realizadas por diferentes personas en distintas unidades organizacionales. Workflow La tecnología de flujos de trabajo. Naturalmente. 82 Estas y otras posibilidades se estudian en los libros Reingeniería de negocios y Gestión de procesos. 3. sería conveniente que antes de automatizar el proceso. permite automatizar un flujo de trabajo y es un buen complemento para la tendencia actual de identificar y rediseñar los procesos del negocio. Por ejemplo. Desde el punto de vista de la reingeniería de negocios. Workflow. . exige que todos los participantes tengan el equipamiento apropiado.

Es cierto que es una pirámide de alto costo. en español inteligencia de negocios) consiste en analizar los datos de las bases de la empresa para elaborar informes. . 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. la información a usar en los análisis debe estar disponible y ser posible de acceder. Por supuesto. comenzando desde arriba. 1. Una pirámide de soluciones Veremos cada una de las capas de esta pirámide. sin embargo. un tipo de herramienta en que se pueden preparar en los aspectos estadísticos del estudio de datos. UNA PIRÁMIDE DE SOLUCIONES Es frecuente observar una pirámide como la que se presenta en la figura 7-2. BI Data Warehouse SRM ERP CRM Motor de base de datos Sistema operativo y lenguajes Figura 7-2. entre otros servicios. 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. encontrar tendencias y buscar dimensiones de los datos. BI BI (Business Intelligence. Por ejemplo.3. cada día es más necesaria en las organizaciones.MODELANDO UNA SOLUCIÓN DE SOFTWARE 321 7.

hábitos y mucho más). .322 JUAN BRAVO C. contabilidad. los sistemas ERP se relacionan con dos tipos de productos: uno cercano al consumidor (CRM) y otro cercano a los proveedores (SRM). De esta forma. 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. cuando. 4. 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. en español. facturación. Se puede ver también como un modelo de gestión que se orienta al cliente y que se manifiesta en el marketing relacional. distribución. se produce una venta. compras. en español. gestión de la relación con los clientes) ayudan en la integración con clientes proporcionando un entorno tecnológico para una relación más personalizada (observan historial de contactos. de ventas. 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). 3. personas y cobranza. ERP Los productos ERP (Enterprise Resource Planning. el sistema “explota” una serie de transacciones a contabilidad. Se evita así su ingreso independiente. CRM Los productos CRM (Customer Relationship Management. producción. sistemas de planificación de recursos empresariales) administran e integran las transacciones operacionales de la organización. 2. los cuales tendrán una estructura normalizada de acuerdo con el tipo de análisis que se quiera realizar. En variadas implementaciones. Esto significa incorporar un proceso automático de traspaso de información. bodega o producción. por ejemplo: cotizaciones. pedidos. Lo habitual es instalar el Data Warehouse sobre el procesamiento transaccional. por ejemplo. generalmente un ERP que usa algún motor de bases de datos (los veremos en los siguientes puntos).

. SQL Server. Informix. hablamos de sistemas administradores de bases de datos tales como: Oracle. 6. gestión de la relación con los proveedores) ayudan en la gestión de las relaciones con los proveedores. DMS e Ingres. en todo caso. Motor de base de datos Aquí se puede referenciar el enfoque de bases de datos del capítulo 4. por ejemplo. Buscan integración a través del software. 5. o comercio electrónico entre empresas). Sybase. 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. o comercio desde las empresas al consumidor). en español. Es una herramienta del tipo B2B (Business to Business. Progress. SRM Los productos SRM (Supplier Relationship Management.MODELANDO UNA SOLUCIÓN DE SOFTWARE 323 Es una herramienta del tipo B2C (Business to Consumer.

el concepto CASE nació de la urgencia por solucionar el problema de la productividad en el desarrollo de software. (Computer Aided Software Engineering. también influyen la normalización. Por ejemplo. Tal como vimos en el capítulo segundo. poseen el conocimiento preciso sobre los objetivos y planes de la organización.A.324 JUAN BRAVO C. construcción y mantenimiento de un proyecto de software. Las herramientas C. así como de la forma de llevarlos a cabo. son aquéllas que permiten apoyar todo o una parte del método de desarrollo. una definición más amplia podría ser: las herramientas CASE ayudan en todo o parte del diseño.E. 7. Al interior de la empresa un pequeño grupo de ejecutivos. también llamados productos orientados a la construcción de sistemas computacionales. la aplicación de buenos métodos y la participación del usuario. Este conocimiento es la base para plantear sistemas computacionales que ellos pueden ayudar a . sigla que en español significa más o menos: ingeniería de software con apoyo computacional) son un soporte automático o semiautomático para los métodos de desarrollo de software.S. el incremento de productividad no se obtiene automáticamente con la introducción de alguna herramienta. 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. Se las conoce mejor como herramientas CASE. de muy poca disponibilidad de tiempo.4. HERRAMIENTAS DE APOYO PARA LA PRODUCCIÓN DE SOFTWARE Las herramientas de la tecnología de información para la producción de software. Entre otros aspectos.

dependiendo de si apoyan las etapas superiores o inferiores del ciclo de vida del proyecto. • Se provee en forma automática una completa normalización de símbolos. Llevar los modelos a aplicaciones concretas con el apoyo de herramientas de productividad.MODELANDO UNA SOLUCIÓN DE SOFTWARE 325 desarrollar. programación muy lenta y dificultad de retroalimentación. porque es independiente de las personas que la desarrollaron y puede ser sucesivamente mejorada. En la figura 7-3 podemos apreciar las dos clasificaciones principales. siguiendo estos dos pasos: 1. respectivamente. • Permiten uniformar diseños. es menos utilizada. colas de espera. • En la construcción de aplicaciones mayores es posible modularizar y coordinar el trabajo de diferentes desarrolladores. Sin embargo. quienes no poseen la misma visión del negocio. en conjunto con los especialistas. 2. Esta es una inversión en inteligencia. agudizándose así el problema. • El usuario y el analista se concentran en lo verdaderamente importante: definir los requerimientos. . Modelar la realidad a través de métodos simples y con apoyo computacional. A veces se incluye otra clasificación para los productos en el segmento intermedio. Algunas características relevantes de las herramientas CASE son las siguientes: • Tienen la doble orientación de productividad y amistosidad. se han encontrado con las dificultades propias del desarrollo tradicional de aplicaciones. tales como atrasos. • Proveen la posibilidad de integración entre diferentes etapas. materias difíciles. • Es posible obtener una visión de conjunto de un proyecto modularizado. Con el enfoque CASE se pretende que los usuarios participen directamente en el desarrollo. de tal forma que el modelo producido se pueda seguir perfeccionando a través del tiempo por los mismos u otros desarrolladores. documentación y construcción al interior de la empresa. denominada MIDDLE CASE. • Sirven a un método para el ciclo completo de desarrollo o para una o más etapas específicas. cada solución queda registrada automáticamente y es un patrimonio de la organización. Esto los ha desalentado y han dejado la iniciativa a especialistas en computación. Al hacerlo de esta manera. Las herramientas CASE se pueden clasificar en UPPER CASE y LOWER CASE.

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. Ejemplos de herramientas en este nivel serían System Architect y ERWIN. Herramientas tipo UPPER CASE 2. reproducciones y es posible ensayar otras opciones de modelamiento. La herramienta debería entregar como resultado una completa documentación de la aplicación. especialmente la construcción y el mantenimiento del sistema. ¿Qué se documenta? Todo.326 JUAN BRAVO C. concretamente la definición de requerimientos y el diseño. Herramientas tipo UPPER CASE Tal como se aprecia en la figura 7-3. Herramientas tipo LOWER CASE Las herramientas tipo LOWER CASE apoyan las etapas inferiores del desarrollo de software. Herramientas Upper CASE y Lower CASE Veremos: 1. Herramienta Upper CASE Lower CASE Etapas que apoya Definición de requerimientos de Diseño Construcción Mantenimiento Figura 7-3. Herramientas de productividad en ambiente cliente servidor 1. especialmente: . las herramientas UPPER CASE apoyan las etapas superiores del desarrollo de software. Estas etapas del desarrollo se ven notablemente simplificadas cuando las correcciones 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. De acuerdo con la tendencia de interfaces simples y naturales. Con la automatización de la obtención de diagramas de diseño se pueden hacer revisiones más precisas. Herramientas tipo LOWER CASE 3. En ambos casos es posible traspasar directamente las definiciones a un sistema administrador de bases de datos. 2.

Genial83. Existen poderosos sistemas administradores de bases de datos que integran gran parte de las características de las herramientas de la TI. como en el caso de COGEN y GENCOB. seguridad o menús. según su filosofía. aunque es posible agregar funcionalidad a través de un lenguaje de alto nivel. El generador de aplicaciones puede tener o no un sistema administrador de bases de datos. huésped o propio. • Generadores de aplicaciones: en los generadores de aplicaciones existe un equilibrio entre procesos y datos. pero siempre va a crear automáticamente un “entorno” para: manejar tablas. en caso de no tenerlo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 327 • La especificación completa del sistema. inicializar o reconstruir entidades. Genexus. ya sea huésped o propio. originalmente con nombre Bravo/2 L4G. habitualmente es necesario programar esas funciones usando algún lenguaje de alto nivel del SABD. • Herramientas de productividad en los sistemas administradores de bases de datos (SABD): también es posible encontrar en los SABD herramientas integradas o módulos opcionales para apoyar la producción de software. por ejemplo: 83 El autor construyó esta herramienta a mediados de los 80. Los programas generados pueden ser intervenidos en el mismo lenguaje que se construyeron. TOTAL. Aquí ya es posible completar algunas aplicaciones muy simples sin llegar a programar. Un generador de aplicaciones puede dar origen a uno o varios programas. Habitualmente el programa se construye sobre una estructura predefinida. Escultor y CASE/AP. es posible simular algunas de sus facilidades definiendo nuevas funciones. En estos casos. cálculos o informes con diferentes cortes de control. administrar una bitácora de uso de la aplicación. . pero el apoyo es bajo para construir funciones de las aplicaciones computacionales: actualizaciones. a diferencia del generador de programas. 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. como DBASE III. INFORMIX U ORACLE sin SQL-PLUS. Algunos SABD proveen un buen manejo para la estructuración y consulta de datos en las bases de datos. 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. Ejemplos de lenguajes en esta categoría son Synon/2.

en lugar de generar programas fuente. Algunos SABD que están o podrían estar en esta categoría son: PACE. Como en el caso de los lenguajes de alto nivel. generador de formularios. agregar más funcionalidad a la aplicación adicionando código. La característica procedural es limitada. 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”. es decir. diseño y construcción). donde por cada instrucción se realiza un proceso de traducir-ejecutar. análisis. Algunas características de estas herramientas son: • No son muy rápidas ni eficientes en el manejo de grandes volúmenes de datos. Considerando el dinamismo en el desarrollo de productos de cuarta generación y la gran interrelación entre ellos. el código reutilizable hace uso del diccionario de referencias para manipular o seleccionar información de las bases de datos de la aplicación. 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. correo electrónico. Ingres. • No liberan la aplicación. Sybase. Progress y otros. cálculos matemáticos y financieros u operación en tiempo real. • Habitualmente son de manejo bastante sencillo. ORACLE con SQL PLUS. ayudas en todo el ciclo de desarrollo (evaluación y control del proyecto. automatización de oficinas (procesador de palabras. aunque no de instrucciones fuentes.328 JUAN BRAVO C. aquí también se requiere un proceso de “interpretación”. • Normalmente son autosuficientes. Ante un requerimiento del usuario. nombre de la función y menú dónde se encuentra. sino de las tablas del software. directorio telefónico. calendario y borrador). habitualmente almacenada bajo estructuras de datos propias del producto. digitalización de imágenes. CLIPPER o C). desde donde el software toma los parámetros para la ejecución de la aplicación. largo del campo. ubicación del campo dentro de la tabla. manipulación de planillas electrónicas. pintores de pantallas e informes. de tipo intérprete. es difícil encontrar herramientas “puras” en esta . • Es difícil y a veces imposible. porque siempre debe estar presente el software. generación de gráficos. ayudas en la toma de decisiones (análisis de sensibilidad). no requieren de otro software para procesar (como un lenguaje huésped tipo COBOL. En el diccionario de referencias se incluyen elementos tales como: nombre del campo. crean un diccionario de referencias a partir de los diccionarios de datos y de funciones. calculadora.

Delphi. de la gerencia de ventas . C o CLIPPER. A partir de la definición almacenada en los diccionarios de datos y funciones de la herramienta CASE. como Fourth Dimension. permitan ver un prototipo de la aplicación bajo este esquema. no pueden ser intervenidos directamente por el usuario. ¿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 descentralizada de aplicaciones. en: • Lenguaje huésped. No obstante. cualquier ineficiencia puede ser rápidamente 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. PowerBuilder. se construyen automáticamente los programas fuentes de la aplicación. Ante un requerimiento del usuario. por ejemplo: CASE/AP. artículos o facturas. 4D y Visual Basic. tipo COBOL.MODELANDO UNA SOLUCIÓN DE SOFTWARE 329 categoría. PACE y otras. Algunos ejemplos: Gupta (o Centura). PASCAL. LINC y GENEXUS. algunas excepciones podrían ser DBASE III y GENERATOR. Sistemas de código fuente Los sistemas de código fuente son generadores de código en lenguajes de alto nivel. Además. El esquema típico son grandes instalaciones con un departamento de sistemas centralizado que no alcanza a atender los requerimientos de importantes áreas de la empresa. por ejemplo. también quedan a disposición del usuario para ser intervenidos. 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. 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. por ejemplo. 3. Genexus y CASE/AP en el mercado latinoamericano. • Lenguaje propio o huésped. es frecuente que herramientas mayores. Esta lógica queda almacenada y luego es intercalada automáticamente en los programas. Genexus. • Lenguaje propio. quedando a disposición del usuario para ser intervenidos. de Supprix. los programas de la aplicación manipulan o consultan información directamente en los repositorios de datos de la aplicación: clientes. Es el caso. sino que se agrega lógica a través de procedimientos especiales.

ellos cuentan con soluciones locales. En todo caso. ¿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. con especialistas en diseño y construcción. Un mensaje implícito en esta narración es que. en el esquema cliente servidor. como MySQL. las herramientas de productividad tipo cliente servidor están muy orientadas hacia especialistas en informática. no necesariamente libre de costo como los productos free). para efectos del desarrollo de aplicaciones. donde trabajan 300 personas o del departamento de producción. los cuales contaran con herramientas que se comunicarán con la base central del área de sistemas. el cliente es también un especialista que se encuentra en otra unidad de la empresa. clientes y demás grupos de interés. Un índice adicional es el largo tiempo que toma llegar a obtener un manejo de buen nivel. con algún motor de bases de datos en el equipo central. incluso para programadores con experiencia. no inferior a seis meses. En este caso. informes y otros módulos especiales. dentro de las más conocidas: . A excepción de consultas. 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. También PHP integrado con alguna base de datos. . vía la norma SQL.330 JUAN BRAVO C. Así la empresa se proyecta al medio.NET y el desarrollo en JAVA. cliente no es lo mismo que usuario final. con 800 empleados. ¡Ahí está el pleno aprovechamiento de la potencialidad de estas herramientas! Con “clientes” realizando desarrollo que se comunica. un objetivo principal de la empresa es el desarrollo de páginas WEB y portales para integrarse con sus proveedores. Típicamente. El esquema cliente servidor se hace cada vez más parecido al ambiente WEB. 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. destacándose J2EE (Java Enterprise Edition).

ANEXOS Y BIBLIOGRAFÍA .MODELANDO UNA SOLUCIÓN DE SOFTWARE 331 CONCLUSIONES.

por ejemplo. • Eficientar el diseño con herramientas de productividad y criterios de modelamiento tal como el curso normal de los eventos y otros que provee la visión sistémica. p. para toda la organización y para todas las etapas de un proyecto. el modelamiento de soluciones de software puede ser tecnología y arte a la vez. se usan diariamente. • Incorporar al diseño los estándares modernos: orientación a objetos y UML. En lugar de haber una sola manera de trabajar aceptada generalmente como modelo. 50 ó 100 maneras diferentes para hacer cada elemento de trabajo. ~§~ . El buen modelamiento tiene su base en sólidos pilares: • La necesidad de trabajar con un método completo. digamos. esto significa alinear con la estrategia de la organización y verdaderamente trabajar en conjunto con el usuario. no sólo el ámbito tecnológico. W. sino que el cliente de la organización). la efectividad se logrará en un ambiente propicio. • Aplicar normas de calidad: CMM.332 JUAN BRAVO C. Taylor F. con el nivel de madurez requerido. Vimos que es posible conservar la creatividad y al mismo tiempo obtener modelos repetibles y normalizados con métodos y herramientas de uso general. Tick IT • Alinear el desarrollo de software con las verdaderas necesidades del negocio. Entonces. Mucho éxito y gracias por la lectura. Por supuesto. aunque debemos agregar la satisfacción total del cliente (no el usuario. ISO 9000. 26) Vimos que tradicionalmente el buen modelamiento de soluciones de software permite aumentar la productividad del desarrollo y la calidad del producto. CONCLUSIONES Los que conocen íntimamente un oficio saben perfectamente que lo que menos se encuentra es la uniformidad en los métodos usados. Está bien. porque la nueva visión de la totalidad y los requisitos de competitividad hacen necesario una mirada más allá de lo tradicional. (1969.

defenderse o contraatacar. “absorbe” silenciosa y positivamente la crítica. Por lo tanto. objetivos y planes. 85 84 . INTRODUCCIÓN A LA PLANIFICACIÓN ESTRATÉGICA La idea es tener una visión estratégica. Esto es. Quizá por eso Plutarco —escritor romano— dijo: Un buen enemigo es el mejor maestro. el desafío es flexibilidad y creatividad. Este es un resumen acerca de estrategia desde el libro Planificación sistémica. Debería “preparar” a su organización para ser receptiva al cambio. como sería lo habitual. Hoy. 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. Cada área de la organización debería tener su propia misión. Debería permitir que la empresa absorba los “golpes” del medio. 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 departamentales • 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 333 ANEXO 1. en armonía con las necesidades estratégicas de la institución. el rol de la planificación estratégica va mucho más allá. prepare bien una respuesta y reaccione con mucha fuerza para lograr sobrevivir85. se detenga. en vez de resistir. Es equivalente a cuando se critica a alguien y esa persona. 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.

Esto obliga a una reformulación permanente de la planificación estratégica. las personas que integran . revisaremos los aspectos más importantes de la planificación estratégica. objetivos y metas).334 JUAN BRAVO C. metas y factores críticos del éxito necesitan apoyarse en mediciones estables. Comienza por una definición clara y precisa del negocio. El objetivo de la Planificación Estratégica (PE) es ayudar a obtener una visión de los verdaderos intereses y necesidades concretas de la organización con el fin de tomar decisiones hoy. Veamos este esquema. debemos considerar que la implementación de las mediciones es la base para la definición de los sistemas de información gerenciales. luego se produce mucha retroalimentación a medida que pasa a través de los diferentes niveles jerárquicos. A continuación. 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. en la forma de visión. confiables. vienen los factores críticos del éxito. que serán ocupación prioritaria del ejecutivo. Aunque la PE comienza por la dirección superior. ¿La PE la hace solamente la alta gerencia? El ideal es que participen todos los miembros de la organización. señalados en la figura A1-1. Los objetivos. siguiendo una dirección clara y definida. aquellos aspectos fundamentales para la supervivencia y desarrollo de la organización. Factores críticos del éxito Sistemas de Información Gerenciales Definición del negocio Destino de la organización Mediciones Figura A1-1. fundador de la logoterapia. Además. está en última instancia en búsqueda del sentido de la vida. luego viene la definición del destino de la organización (lo que queremos. según Viktor Frankl. Por eso es que hoy hablamos de planificación continua. Esquema de planificación estratégica En la figura A1-1 podemos apreciar una visión de conjunto del esquema propuesto. En los siguientes pasos. oportunas y permanentes.

las cuales. Se apoya en la orientación al cliente. Para definir el negocio es indispensable efectuar un estudio iterativo y retroalimentado (en el sentido de construir borradores sucesivos) sobre los siguientes temas: • Introspección: es un escrutinio interno destinado a conocer nuestras fortalezas y debilidades. Se busca identificar las oportunidades y amenazas que surgen de la interacción con el medio. Por ejemplo: confección de jeans a pedido para clientes mayoristas. aquella función donde otorgamos un verdadero valor agregado y además. El sistema de diferenciación y luego la ventaja competitiva es la forma como vamos a competir en el mercado. A este aspecto. centro naturista de atención al público o asesorías en planificación estratégica dirigidas a la dirección de las organizaciones. ¿No le parece revolucionario? Es exactamente al revés de como lo aprendimos en el colegio. • Análisis de la industria: es un detallado estudio de la industria donde está inserta la empresa. servicio óptimo. • Misión del negocio: es la función específica que nos corresponde desarrollar en el sistema del que formamos parte. solidez o lo que sea. Ellos hablan de éxito cuando la empresa tiene verdaderos objetivos. donde no pongan en peligro la existencia de la empresa.MODELANDO UNA SOLUCIÓN DE SOFTWARE 335 la organización también deben preguntarse cuál es el sentido de la existencia de ésta. rapidez en la entrega. Esto significa destinar a las fortalezas el máximo posible de tiempo y mejorar las debilidades solamente para llevarlas a un nivel aceptable. donde nos gastábamos todo el tiempo en llevar las debilidades a un punto de rendimiento medio y las fortalezas quedaban abandonadas. compararlas con las de la competencia y así perfeccionar nuestras ventajas competitivas. • Estrategia competitiva: ¿Marketing o innovaciones? ¿En qué nos diferenciamos? ¿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. plenamente reconocido por la sociedad como útil y complementaria para lograr los objetivos de bien común. al ser trabajadas. serán elementos diferenciadores: calidad. Destaquemos en forma especial que lo que hace la diferencia en una empresa no es lo que hace menos mal. el rol que le toca jugar en la sociedad. Koch y Campbell (Cómo despertar y reanimar la empresa) le asignan una importancia radical. sino lo que hace muy bien. .

Los proveedores necesitan conocernos para entender nuestras necesidades. sentir su aroma y esbozar una sonrisa de satisfacción. anticipación. Muchos empresarios se nutren de la importancia de su labor en la sociedad para crear riqueza. un ambiente laboral estable. Señalando explícitamente un conjunto de creencias. Por ejemplo. Es decir. un trato respetuoso. condiciones de trabajo que protejan su salud física y mental. distinta de las personas que la componen. requieren pagos puntuales. aunque en el largo plazo se produce cierta similitud. inspirar profundamente. Surge de nuestros sueños. pues ellos financian nuestras actividades. los integrantes de la organización tienen necesidad de una renta digna. una relación comercial fluida. • Valores de la organización: la organización tiene personalidad propia. fabricar bienes.336 JUAN BRAVO C. etc… . tanto la organización como sus integrantes comienzan a tener conductas parecidas. nos ayuda a reflejarnos y compartir experiencias con quienes tienen la misma perspectiva. dar empleos. 86 Tal como lo reflejara muy gráficamente el dueño de una panadería. clientes o proveedores? La mecánica es describir las necesidades de cada grupo de asociados y ayudarles a satisfacerlas. alimentación o consejería. Los valores se expresan prioritariamente 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. niveles de calidad establecidos de común acuerdo. innovando día a día en su beneficio y que les ofrecemos lo mismo que la competencia y mucho más. la misión debe incluir los productos que ofrecemos y los mercados que atendemos. comunicación interpersonal)? ¿Qué sucede con el fomento a la creatividad e innovaciones? • La emoción del negocio es una fuente para la motivación de todas las personas de la organización y el principal alimento del líder. aun cuando cumplan misiones diferentes86. principios éticos y modalidades de gestión. Los clientes merecen todo nuestro apoyo. La emoción del negocio es abrir uno de los panes que estamos produciendo. de identificar la necesidad social concreta que estamos satisfaciendo: abrigo. ¿Cuáles son las condiciones del trato entre las personas? ¿Cómo se manejan temas claves (disciplina. en armonía con la satisfacción de necesidades de nuestra organización. Es el nexo que nos une con el entorno. Técnicamente. es indispensable que tengan la certeza de que trabajamos para entregarles calidad.

lo que sea su sueño. Entonces diremos que sí es posible obtener el 35% del mercado. Técnicamente. es la visión del negocio. Existen previsiones a la cantidad de años que uno desee. aquel punto adonde queremos llegar. Los plazos indicados representan solamente un promedio. o que cada norteamericano tenga un automóvil. Destino de la organización El asunto es: ¿la organización estará a la deriva o tendrá un rumbo mantenido con mano firme? Indudablemente. ¿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. banderas o revista interna.MODELANDO UNA SOLUCIÓN DE SOFTWARE 337 • La imagen corporativa es la cara que queremos mostrar de la empresa a través de: papelería. • El ideal es nuestro sueño para la organización. 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. Así. unos 2. Largo . en el mismo orden: ideal. deja de ser solamente una buena intención. Cada objetivo asocia mediciones para establecer comparaciones y apreciar un estado de avance. ideal factible. porque corresponden al destino concreto de nuestra empresa. Para ello. • Los objetivos son los elementos más representativos de la planificación estratégica. como decía Henry Ford. 5 y 15 años. el ideal factible es una propuesta que sabemos posible. aunque generalmente se hace una distinción entre objetivos de corto. comenzar a vender salmón en los supermercados en diferentes presentaciones o reducir el consumo de droga en un 90%. respectivamente. aunque no es tan precisa como un objetivo. Queremos tener el 90% del mercado.. mediano y largo plazo. tenemos que definir cuatro aspectos. construir un automóvil posible de adquirir por los trabajadores. La planificación estratégica define los objetivos según el ideal factible. un diseño efectuado sin amarrarnos a la historia del negocio. si corresponde. identificar el destino de la organización es indispensable. Un antiguo proverbio dice: El camino al infierno está pavimentado de buenas intenciones.. Aceptamos disminuir un poco nuestra pretensión original. para lograr algo concreto. porque no existe uniformidad al respecto. objetivos y metas. • El ideal factible surge de negociar con la realidad y proponer algo posible para el futuro cercano.

en una empresa de confecciones se encontraron los siguientes 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 industria. se pueden encontrar en la mayoría de las empresas del mismo tipo. que afectan directamente sus posibilidades de sobrevivencia. por ejemplo. recursos y plazos. Dependen directamente de la misión de la empresa y deben ser considerados en la toma de decisiones de la alta gerencia. la eficiencia y estabilidad de la producción. ◊ Hechos circunstanciales. Significa que él podría delegar todo lo que no es un FCE. es decir. como una nueva ley. Cada meta requiere un responsable. • Las metas vendrían a ser las paradas intermedias.338 JUAN BRAVO C. como el perfeccionamiento tecnológico. representan un filtro en la cantidad de información que llega al ejecutivo. • Temporales: se mantienen por períodos cortos de tiempo. la nueva organización de la empresa. cada uno de los diferentes escalones que nos permitirán lograr un objetivo. un incendio en instalaciones importantes o la renuncia de un empleado clave. como el desarrollo de una meta. Por ejemplo. del ejemplo anterior. ◊ Situaciones programadas. generalmente se originan en: ◊ Particularidades transitorias. Factores críticos del éxito Los Factores Críticos del Éxito (FCE) son tan vitales para la empresa. como una campaña comercial o el lanzamiento de un nuevo producto. 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. .

En este caso. Un sistema de información es un modelo diseñado para cumplir con algún fin práctico. en lugar de solamente las buenas intenciones. podría alertarse a la gerencia general. es necesario agregarle un índice. ¿Quién diseña el sistema de información? Tradicionalmente. En alguna parte de la planificación podría decir: aumentar el perfeccionamiento del personal. Cada vez que un ejecutivo da pautas sobre cómo hacer algo o se anticipa a una crisis o punto de quiebre. ésta ha sido la principal labor del ejecutivo. sin embargo. 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. en este caso. si el número de prendas producidas en el día baja hasta un cierto nivel. En el sistema de información gerencial participan personas y se emplean variados recursos: técnicos. infraestructura. Al dejarlo así no pasa de ser una bonita declaración. está diseñando sistemas de información gerenciales. la medición es número de prendas por día. por ejemplo. lo que se consigue a través de las mediciones. conocimiento o herramientas de software. existe una . apoyar una medición. comparaciones con la competencia o factores críticos del éxito. Los sistemas de información gerenciales son procesos claramente identificables. se genera automáticamente un alerta a ventas y producción. a veces sin que él lo supiera. financieros. Permiten conocer e influir sobre el estado de una variable. Las mediciones deben estar presentes en todos los elementos mencionados: objetivos. horas de capacitación anual por empleado. cuyo diseño debe estar permanentemente actualizado para conservar su efectividad.MODELANDO UNA SOLUCIÓN DE SOFTWARE 339 Mediciones La planificación puede carecer de sentido si no está fuertemente anclada a los hechos y la realidad. por ejemplo. metas. Hoy. Ahora podemos hablar en concreto: ¿cuántas horas estamos capacitando hoy a nuestro personal y a cuántas queremos llegar? Otro ejemplo es el de una empresa de confecciones que se plantea por objetivo aumentar la producción. si el índice llega a un nivel todavía más bajo. para que se transforme en una realidad. ambos ejemplos terminan con preguntas donde podemos apreciar la necesidad de mediciones actualizadas para definir sistemas de información.

tendencia a la participación de todos los interesados. De hecho. algunos grupos 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. .340 JUAN BRAVO C. Como decía El Quijote: “estar prevenidos es estar armados”.

También hay que lograr armonía entre los costos. Las personas más preparadas de la organización estarían obteniendo mayores beneficios que los accionistas. Este es uno de los aspectos más difíciles para la gerencia y exige mucha fortaleza y habilidad. como diría Peter Drucker. . buscando satisfacer sus intereses en armonía con los de la empresa. es decir. A esto se refiere Russell Ackoff (1994) cuando explica que un ejecutivo lidera interacciones. empresas afines. porque muchos grupos le exigirán justas demandas (para ellos) y algunos gritarán más que otros: ¡mayores utilidades!. bancos e instituciones financieras. Paradojas de la nueva economía. Es necesario alinear todas las acciones con la cultura de la organización y buscar armonía entre los grupos de interés: clientes. Una vez que los intereses están claros. entre otras acciones. proveedores y muchos otros a quienes conviene la existencia de la empresa. la gerencia debería liderar valores en la relación con cada grupo de interés.MODELANDO UNA SOLUCIÓN DE SOFTWARE 341 ANEXO 2. un proceso nada de simple. en las grandes empresas norteamericanas87 comienza a ganar el talento. colaboradores. El trabajo en equipo resulta aquí esencial. lo cual conduce a la rareza de que los trabajadores que no son del conocimiento hagan alianza con los dueños del capital (principalmente ellos mismos a través de los fondos de pensiones) para obtener mejores beneficios. poniéndonos en el lugar del otro y practicando la buena comunicación. ALINEAR INTERESES Existe la necesidad de negociar intereses. los trabajadores del conocimiento. ¿Cómo lograrlo? Negociando. 87 Según un artículo de Martin y Moldoveanu (2003) en el Harvard Business Review. ¡mejores sueldos!. accionistas o inversionistas. porque las personas y organizaciones tienen propósitos diferentes. Liderar interacciones Para mantener la armonía. porque hay estímulos para ello. eso contribuirá al respeto y la confianza mutua. comunidad. gobierno. lo cual implica negociar con los diferentes grupos de interés. escuchando. la gerencia debiera mantener la coherencia a través de un sistema de señales. establecer indicaciones y acciones concretas y permanentes según el objetivo que se desea obtener. aprendiendo a reconocer los intereses propios y ajenos. distribuidores. ¡más tributación…! De hecho. Las personas hacen lo que hacen porque les conviene hacerlo (o creen que les conviene).

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. Este es el resultado de una cultura mecanicista que sólo ve partes. es frecuente pagar horas extras por reparaciones de maquinarias —y de una u otra forma.342 JUAN BRAVO C. que el médico gane más en la medida que haya más gente sana. Es más. Un esquema sistémico sería aquel donde el negocio del médico es la salud y no la enfermedad. en la prevención de riesgos ¿a quien o a qué grupo le puede convenir 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. participación y negociación. Por ejemplo. El mensaje es negociar con todos los interesados. en el segundo. porque he tenido pocas operaciones. • En departamentos de mantención. lo más probable es que el rendimiento no fuera el óptimo. Igual es necesario identificarlos y negociar para alinear intereses. nuestro negocio es estar sanos. En el primer caso solamente hay mando y control. es decir. es característico otorgar incentivos de producción por cantidades de productos que en muchos casos se almacenan. . Partiendo de la base que el objetivo de la sociedad es el bien común. ¿cómo te va? Y aquel responde: mal. 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. ¿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. en lugar de incentivar a producir sólo lo que se vende. muchos de ellos mantienen su profesionalismo y amor al trabajo bien hecho a pesar de los incentivos equívocos que otorga la sociedad. siempre hay mucho trabajo— en lugar de pagar por su buen funcionamiento. • En la empresa manufacturera. 88 Como cuando un médico cirujano le pregunta a otro. Es la situación típica que se produce cuando el énfasis está en la corrección y no en la prevención. La responsabilidad no es solamente de los médicos —y lo mismo es válido en la mayoría de las profesiones—. Eso es alinear intereses. • Otro caso es nuestra interacción con los médicos en algunos tipos de programas.

Veámoslo más en detalle con el resumen de un caso real. se les ofrece a los técnicos un premio mensual extra de US$ 10. ¿es eso realmente conveniente para la empresa? Tal vez no. se descuenta de ese fondo un valor predefinido por cada hora detenida. puede parecer deseable producir cada vez más.000 al mes (horas improductivas). su conveniencia respecto a las maquinarias es que se mantengan en buen estado de funcionamiento. pero. Entonces. Sin embargo. ¿es posible la armonía en la organización en pro de sus propósitos superiores? Por supuesto. si una máquina falla. si el negocio de la empresa es la fabricación de productos industriales. a través de algún esquema que permita disminuir libremente la producción sin incrementar el costo por unidad producida. que el sueldo de cada uno es de US$ 1. En este caso tenemos alineadas las misiones: a la organización y al servicio técnico les conviene tener las máquinas buenas. Veamos otro ejemplo. 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. Sin embargo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 343 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.000 a repartirse en el grupo. incluso se les paga horas extra para incrementar el volumen de reparación. 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%. a condición de que las máquinas estén en buen estado de funcionamiento. Si el objetivo del equipo de mantención fuera “obtener ingresos por tener los equipos en óptimo estado de funcionamiento”. Entonces. . absorber gastos demasiado altos de ventas o de administración ¿Podría ser que el objetivo del área productiva fuera producir según la demanda? Sí. Se puede apreciar que ambos negocios se contraponen: a uno le conviene tener los equipos buenos y al otro le conviene que haya muchos equipos malos. tendríamos las misiones alineadas e incentivaríamos la mantención preventiva. porque sus ingresos provienen de la reparación de maquinarias descompuestas.000 y que el costo para la organización por máquinas que fallan es de US$ 40. Supongamos que son 5 técnicos. a través de alinear intereses. si uno toma separadamente el área de producción de una empresa. la conveniencia del grupo de mantención es que las máquinas estén en mal estado. porque se podría ver en la necesidad de sacrificar demasiado sus márgenes. Por ejemplo.

eficacia y eficiencia. 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. ANEXO 3. Dice Steve McConnell (1997. se establece una aproximación a la siguiente iteración… Se avanza un nivel en el rollo de canela. en consecuencia. recién se ven resultados al término del proyecto. Esta es la nueva propuesta para los proyectos menos estructurados. también se puede aplicar a proyectos de cambio un poco menor. tal vez un año en el caso de proyectos medianos. se comprueba que se tiene lo que se desea y después se comienza a trabajar en el siguiente nivel”. 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. Cada vuelta de la espiral es un ciclo completo de desarrollo para el grupo de requerimientos seleccionados. aunque resultaría un poco forzado. se localizan los riesgos. en la cual se pretende avanzar en cada etapa con todos los requerimientos a la vez. . En cada iteración la complejidad se incrementa progresivamente y se reduce el riesgo.344 JUAN BRAVO C. Simplificando. Se espera que una vuelta de la espiral demore entre dos y diez semanas. se genera un plan para manejarlos y a continuación. para un rango de entre el 5% al 20% de los requerimientos. como en el benchmarking o la mejora. p. Este método está dirigido a proyectos de cambio mayor. un desarrollo de esta naturaleza exige amplio esfuerzo de gestión y operación. Por supuesto y al igual que en un proyecto tradicional. La forma tradicional es la técnica llamada “desarrollo en cascada”.

Al término del proyecto (después de todos los ciclos) se recomienda incorporar la mejora continua (ver etapa 7 del método). aunque para un número relativamente pequeño del total de requerimientos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 345 En el desarrollo en espiral cada vuelta o ciclo es un pequeño “desarrollo en cascada”. . porque pasa por todas las etapas.

Aquí las “espinas” son los elementos del modelo de negocios: estrategia. 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. Entonces. se analizan. personas. ANEXO 4. estructura organizacional y tecnología. se detectan causas. . como en una tormenta de ideas. mano de obra. riesgo o lo que sea que estemos analizando. Veremos aquí la técnica causa . La fórmula es Y = F(x). Es una combinación que hemos venido utilizando con efectividad. indicando en que porcentaje influye cada una sobre el síntoma. técnica de los por qué y otras detalladas en el texto. 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. en la línea “personas” se podría anotar. para un síntoma de descuadraturas de caja.346 JUAN BRAVO C.efecto de Kaoru Ischikawa junto con la detección de prioridades del italiano Vilfredo Pareto (1848 – 1923). materias primas. La técnica causa – efecto se utilizaba principalmente en el ámbito industrial y las “espinas” hacían referencia a los temas relacionados: materiales. En este caso la aplicamos buscando el problema de fondo de un síntoma o dificultad. procesos. RELACIÓN CAUSAL Existen varias técnicas asociadas a la detección de causas: árbol de decisión. maquinarias y ambiente. Personas Procesos Síntoma(s) Estrategia Estructura Tecnología Por ejemplo. en la detección de los riesgos de fondo en eventos de pérdida de la administración del riesgo operacional y en la mejora continua.

su corazón no late 32. 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 relevantes. Dell y Anderson dicen (1999. los autores Wilson. El gráfico tiene la siguiente forma. 50 bebés recién nacidos se les caen a los médicos por día. Es decir. en su libro Análisis de la causa raíz. 500 operaciones quirúrgicas incorrectas por semana.1% de fallas significa: 16. 22. donde la columna más a la derecha tiene el acumulado de las causas anteriores más la nueva. puede ser necesario que una causa tenga su propio análisis causal y así sucesivamente. X1 = F(x1). Ejemplo de gráfico de Ishikawa Se priorizan y grafican de mayor a menor impacto según el porcentaje asignado. p.000 veces por año”. A propósito de Six Sigma.000 cheques deducidos de cuentas corrientes equivocadas por hora.MODELANDO UNA SOLUCIÓN DE SOFTWARE 347 Causas Procesos Especialización Forma obsoleta Efecto Personas Rotación Motivación Preparación Falta directriz Comunicar No participación Falta área Falta Tecnología Obsoleta Insatisfacción de clientes debido a excesiva duración del proceso (49 minutos) Estrategia Estructura Tecnología Figura A4-1.000 piezas de correo perdidas por hora. Esta forma de trabajo es recursiva. El nivel de profundidad al cual se llega tiene que ver con la técnica de desarrollo en espiral y con el nivel de error aceptable para la organización en algún nivel de sigma.000 prescripciones de medicamentos incorrectas por año. 20. 6): “En Estados Unidos el 0. . esquema central en la técnica Six Sigma. los pocos críticos.

ANEXO 5. sabio francés de origen búlgaro. En el MAR es vital la participación de quienes trabajan en los procesos operativos. 3. que el pensamiento es un poder real y segundo. System Arquitect u otra. 2. Aplicar criterio “Curso normal de los eventos”. dueño.348 JUAN BRAVO C. Establecer objetivos siguiendo el principio de idealización: ideal. Optimus. Se trata de proponer el (re) diseño en alguna herramienta tal como PowerPoint.evolucion. tanto para lo negativo como para lo positivo y tenemos. 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. 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. Identificar cliente. ¿Cuál es el proceso perfecto89? (Puede ser de todo el ámbito). reconocido 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. Cuando logramos “ver” en nuestra mente ese proceso perfecto. algo que sucede en nuestra mente y que podemos controlar. Visio. Seleccionar un ámbito de trabajo y dibujar un mapa de procesos. Explicar oportunidades de mejora y señalarlas en un nuevo FI. de alguna forma se generan caminos para acercarnos a ese ideal. ¿Cómo quedan las mediciones? 6. por tanto. Realizar un cierre de la propuesta indicando beneficios y costos. estáis ya saboreando el gozo de estos minutos próximos o lejanos… El poder del pensamiento es real. Se han logrado importantes cambios en las empresas con esta técnica. puede ser un área o un macroproceso. que si tenéis que afrontar una situación terrible. que os permite transportaros al futuro y vivirlo con anticipación. variable crítica y mediciones estimadas. Identificar un proceso operativo y describirlo con un Flujograma de Información (FI). el poder del pensamiento. ideal factible. 89 El concepto de “proceso perfecto” viene de aplicar algo largamente reconocido. 5. 4. Ved. el futuro no existe. El mismísimo Omraam Mikhaël Aïvanhov (1900-1986. .cl. pasar un examen o comparecer ante un tribunal. a condición de que este disponible para todos. que servirnos de él para lo positivo”. La idea es la siguiente: 1. 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. por ejemplo. es solamente imaginación nuestra. ya estáis temblando varios días antes. Aceptémoslo de una vez.

. Además. ambos de IBM (RUP fue adquirido en 2005 junto con la empresa Rational). Se puede apreciar cómo se va delineando poco a poco el concepto de que una aplicación no termina nunca. factores críticos del éxito. se acerca bastante al ciclo de vida genérico. AD/Cycle El ciclo de desarrollo de aplicaciones computacionales de IBM. creándose el ambiente para el desarrollo continuo de la aplicación. entrenamiento y poblamiento.MODELANDO UNA SOLUCIÓN DE SOFTWARE 349 ANEXO 6. objetivos. AD/Cycle. 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. Se puede apreciar que ya en 1989 IBM había eliminado la implementación como una etapa más. en AD/Cycle se habla de Análisis/diseño para referirse a lo que en el método genérico llamamos diseño. aunque sus principales tareas: documentación. • Análisis/Diseño: basado en análisis y diseño estructurado. se continúan realizando en forma automática o como parte de otras etapas. una visión de conjunto de la organización que se obtiene de la recolección de requerimientos. • Mantención: ya sea por errores o cambios en el entorno. las que fueron reemplazadas por un enfoque global. AD/Cycle provee un ambiente integrado de desarrollo que incluye desde el modelamiento hasta la mantención. El primero más antiguo y el segundo más reciente. • Codificación: es la construcción de los programas. anunciado en 1989. Las etapas de AD/Cycle son: • Recolección de requerimientos: incluye planificación de sistemas. la cual es parte de la construcción en el método genérico. Cada una de sus etapas es apoyada por herramientas de automatización propias o de otros proveedores. la principal diferencia es que incorpora explícitamente una etapa de pruebas. prioridades y procesos del negocio. 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. Con AD/Cycle también se eliminan las etapas de diagnóstico y factibilidad aplicados a resolver problemas en forma reactiva.

equipos de trabajo.350 JUAN BRAVO C. Uso de una arquitectura de componentes. configuración y mediciones. instalaciones. Mayor información puede encontrarse en www. entendible. donde se establece lo que importa para el usuario. En un ambiente de creciente complejidad: múltiples desarrolladores. Haciendo una comparación con el rubro de la construcción. se establece una prioridad en base a riesgos. Aquí se establece la arquitectura de la solución de software. Siendo la calidad uno de los más graves problemas de la construcción tradicional de software. estético y elegante. se propone incluir indicadores de calidad y verificaciones en cada punto del proceso de desarrollo. proyectos y plataformas. incluyendo la interfaz. Se aplica la técnica de casos de uso. 3. Manejo de los requerimientos. 6. Se resuelven primero los casos de uso (o requerimientos) más importantes.org. . factible. de buen rendimiento.com y otros sitios relacionados. cada iteración acerca más el sistema a lo que desea el usuario y a su plena funcionalidad. construcción y documentación de los productos de software. www. cada “versión” va quedando en funcionamiento real. Se incorpora una labor de Testing en el ciclo de vida. RUP Los autores del UML (capítulo 6) son también creadores de Rational Software Corporation (adquirida por IBM en el año 2005).rational. Se seleccionan. RUP considera seis mejores prácticas del desarrollo de software: 1. versiones del software. en cada vuelta de la espiral. 4. por otra parte. se requiere un control explícito de requerimientos. un método completo para el desarrollo de software que rápidamente está siendo incorporado en la industria informática. Control de cambios. 2. económico. reusable. Verificación de la calidad. www.omg. 5. organizan y documentan los requerimientos. funcional. En este método. Modelamiento visual del software.uml. Debe cumplir que el software sea fácil de usar. desde donde han propuesto el RUP (Rational Unified Process). esta etapa sería la de arquitectura.com. visualización. orientados a la especificación. aquellos donde el riesgo es mayor. Desarrollo Iterativo (o en espiral). Se aplican aquí los modelos que provee UML.

Prentice Hall). Reconociendo que es difícil revisar en el papel. Veremos en las siguientes láminas un caso completo de compras en UML. comienza por los modelos de la etapa de análisis. CASO COMPRAS CON UML Este caso fue un desarrollo completo de los modelos de UML contemplados en el método GSP (capítulo 1).MODELANDO UNA SOLUCIÓN DE SOFTWARE 351 ANEXO 7. Lo vimos en el anexo 5. .cl Puede bajar también: • El caso de uso Ventas • Método de Acción Rápida (MAR) sobre procesos. usted puede bajar este archivo desde la página www.evolucion. En el aspecto metodológico se basa principalmente en el libro “Applying UML and Patterns” de Craig Larman (1998. Cada lámina tiene notas que explican el respectivo modelo. modelo en Power Point y detalle en Word.

esta presentación se basa en la serie de libros de gestión. Etapa de Análisis Modelos de UML de una aplicación de ejemplo: compras Las páginas siguientes corresponden a la etapa de análisis. que incluye. .1998 (Prentice Hall) ISBN 0-13-748880-7 Bibliografía: Adicionalmente.352 JUAN BRAVO C. la cual se extiende hasta la documentación de los contratos de las operaciones del sistema inclusive. MAPA DE PROCESOS (como parte del Modelo de Negocios) Proyección ventas Adquisiciones Ventas Servicio postventa Macroprocesos Primer Flujograma de Información RECEPCIÓN POR COMPRAS DESPACHO POR VENTAS Procesos operativos Devoluciones Devoluciones Bibliografía: Esta presentación se basa principalmente en el libro “ Applying UML and Patterns “ de Craig Larman . análisis y sistemas de Juan Bravo C. entre otros. a: Gestión de Procesos (2005) y gestión de proyectos de procesos y tecnología (2006).

Desplegar datos del Encargado de Recepción registrados en almacenamiento persistente. Capturar la Cantidad de unidades del Producto respectivo (Ingreso manual). Capturar Fecha (Propia) de Guía de Despacho del Proveedor (Ingreso Manual) y desplegarla. 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. págs.6.13 R1.5 R1. 2 G/D 1 Proveed.4 R1.11 R1.tal como: revisión.2 R1.8 R1. Nota: (Craig Larman. Con ello. Registrar la transacción en proceso: los Productos a recibir. para indicar algún tipo de acción que se ha tomado con él . G/D 3’ Proveed. aunque el documento sigue siendo “el mismo”.12 R1.1.3. verificar validez (No Existencia previa) y desplegarlo. quienes relatan qué es lo que el sistema “debe hacer”.a 5. etc -.(Guía Interna de Recepción por Compra) Encargado de Recepción 3 G/D 1 Proveed.3 R1. como se muestra en este flujograma para diversos pasos que sigue la copia # 2 de la Guía de Recepción. Desplegar la descripción del Producto registrado en almacenamiento persistente. Capturar Nº de Guía de Despacho del Proveedor (Ingreso Manual). Actualizar los valores de existencia y recibido de Productos (evitando doble actualización) al dar OK a la Guía de Recepción en su totalidad. aprobación. Además calcular el nuevo Costo Promedio. G/D 1’ Proveed. Se indica gráficamente esta situación por medio de “cremillas”.7 R1. “tick”) . Capturar el Costo (Precio del Proveedor) del Producto (Ingreso manual) y desplegarlo.. . de Compras Depto. 3’ 2’ G/R 2’’ Interna Ingresar Productos a Bodega G/R 2’’’ Interna Casos de Uso: Crear Guías Internas de Recepción por Compra y de Despacho por Venta (Productos con registro persistente) Ref.6. Capturar el Código del Encargado de Recepción (Ingreso Manual). Capturar la información del Producto a recibir usando el Código (interno) (Ingreso Manual).6 R1. Nº de Guía de Recepción (correlativo) y Fecha de la Transacción.10 R1. 5. # R1. que se incrementan. 2 3 353 Proveedor Control de Calidad Inventario (Bodega) Depto.aceptar eventual modificación de Fecha (Ingreso Manual).MODELANDO UNA SOLUCIÓN DE SOFTWARE Flujograma : Proceso de Recepción de Productos de Proveedores . firma. ya no es “el mismo”. aceptar Opción (Selección Manual). 42 a 44) Las funciones básicas se “descubren” durante el desarrollo de las entrevistas con los usuarios.. También el analista agregará algunas que no son evidentes para el usuario. .1 R1. 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. de Contabilidad Ingresar Guía de Recepción 3 G/R 1 Interna 2 G/R 3’ Interna 3’ G/R 1’ Interna 2’ Verificar Calidad de Productos Nota: Un determinado documento (papel o electrónico) puede ser cambiado (por ejemplo: VºBº.14 Función Funciones Básicas (Base Craig Larman) Categoría evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente oculta oculta Capturar y activar opciones desde un Menú de Opciones. Capturar la información del Proveedor usando el RUT (Ingreso Manual) y desplegar datos pertinentes del Proveedor registrados en almacenamiento persistente.9 R1. Capturar/Verificar (C/E) Nº de Orden de Compra (Ingreso Manual) y desplegarlo. Desplegar la Interfaz de Creación de Guía de Recepción. (en forma “evidente” u “oculta”).

15 R2.12 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 Interfaz al dar OK a la línea. Capturar la información del Producto a despachar usando el Código (interno) (Ingreso Manual). Funciones Básicas (Base Craig Larman) Categoría oculta evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente evidente oculta oculta Desplegar la Interfaz de Creación de Guía de Despacho. 2 segundos Estilo Windows En colores y efectos 3D R1.6 R2. Ofrecer un mecanismo de almacenamiento persistente.7 R2.9 R2.12 R2. págs. evidente Tiempo de respuesta máx.5 R2. Capturar Fecha (Propia) de Nota de Venta del Cliente (Ingreso Manual) y desplegarla.13 Función Ofrecer un mecanismo de almacenamiento persistente.11 R2.si las hubiera . se dan unos pocos ejemplos).aceptar eventual modificación de Fecha . JUAN BRAVO C. . Capturar el Precio al Cliente del Producto (Ingreso manual) y desplegarlo. 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.4 R2. . Capturar el Código del Encargado de Despacho (Ingreso Manual).1. 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.Atributos y restricciones de las funciones del sistema (Base Craig Larman) Ref.2 R2. Nº de Guía de Despacho (correlativo) y Fecha de la Transacción.7. Capturar/Verificar Condición de Pago de la Venta (Ingreso Manual) y desplegarla. Capturar Nº de Nota de Venta del Cliente (Ingreso Manual). Funciones Básicas . . 2 segundos Categoría obligatoria obligatoria opcional obligatoria R1. Registrar la transacción en proceso: los Productos a despachar. # R1.(Ingreso Manual). quienes relatan qué atributos “debiera tener” el sistema y cuáles eventualmente serían las correspondientes restricciones.15 oculta Plataforma Usar base de datos corporativa actualmente instalada obligatoria Nota: (Craig Larman.3 R2. # R1. Capturar la Cantidad de unidades del Producto respectivo (Ingreso manual). por razones de espacio. (Aquí. Actualizar los valores de existencia y despachado de Productos (evitando doble actualización) al dar OK a la Guía de Despacho en su totalidad.8 R2.y si ellas serían “obligatorias” u “opcionales”. Categoría evidente Atributo Tiempo de respuesta Interfaz Restricción máx. Desplegar la descripción del Producto registrado en almacenamiento persistente.10 R2.1 R2.5 Función Capturar la información del Proveedor usando el RUT y desplegar sus datos. 45 y 46) Los atributos y restricciones de las funciones básicas se “descubren” durante el desarrollo de las entrevistas con los usuarios. Capturar la información del Cliente usando el RUT (Ingreso Manual) y desplegar datos pertinentes del Cliente registrados en almacenamiento persistente. Desplegar datos del Encargado de Despacho registrados en almacenamiento persistente. 5.354 Casos de Uso: Crear Guías Internas de Recepción por Compra y de Despacho por Venta (Productos con registro persistente) Ref. verificar validez (No Existencia previa) y desplegarlo.

3. entrega las copias pertinentes al Proveedor y envía las restantes copias a sus respectivos destinos. Nota: El inicio y el fin del Caso de Uso deberían estar inequívocamente indicados en la narrativa. El Encargado registra el ingreso de la mercadería. • Actores: Proveedor. firma toda la documentación.7. El Proveedor se retira. 3) Existe un Registro de Proveedores. 2. con lo cual termina el Caso de Uso.“. Encargado de Recepción (Empleado) Proveedor Comentarios relevantes : 1) Se trata de una transacción entre dos entidades. son “roles” que juegan las personas de la Organización. Encargado de Recepción..MODELANDO UNA SOLUCIÓN DE SOFTWARE 355 Diagrama de Casos de Uso (Casos de Uso Básicos) (Base Craig Larman) Nota: •Para ejemplificar el método de “Desarrollo en espiral”. • Encargado de Despacho. pág. Son Casos de Uso Genéricos que en el transcurso del análisis se desagregarían en otros Casos de Uso. 2) Se trata de una transacción que implica una entrega / recepción de Productos. 26) “Los Casos de Uso de Alto Nivel son breves descripciones de un proceso . Crear Guía Interna de Recepción por Compra Nota: • Administrador. Ver también: (Craig Larman. 6) Se lleva un registro persistente de la transacción. 49) .. (No necesariamente son tres personas distintas).2. (con Proveedor y Encargado de Recepción). 6. pág. Nota: Descripción . • Tipo: Primario. 5) Existe un Registro de Productos.1.. Administrador (Empleado) Caso de Uso: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Caso de Uso de Alto Nivel Terminal Recepción Crear Guía Interna de Recepción por Compra • Caso de Uso: Crear Guía Interna de Recepción por Compra. Nota : (Craig Larman. Encargado de Recepción (Empleado) Crear Guía Interna de Despacho por Venta Proveedor Iniciar Sistema de Bodegas Cliente Encargado de Despacho (Empleado) Administrar Sistema de Bodega de Recepción y Despacho Realizar procesos de “Fin de Día” Nota: Administrar Sistema .usualmente dos o tres frases . emite la Guía Interna de Recepción por Compra. Ello evita las superposiciones y ambigüedades en las especificaciones..Sigue la narrativa que se desprende del Flujograma de Información correspondiente -. • Descripción: Este Caso de Uso comienza cuando un Proveedor llega con mercadería acompañando la documentación legal de rigor. se estaría proponiendo estos casos de uso para ser desarrollados en las primeras vueltas de la espiral. (No se muestran aquí todos por razones de espacio). • Encargado de Recepción. 4) Existe un Registro de Encargados de Recepción (Empleado).

R1. 2. 12.15 Nota: Este Caso de Uso comprende desde la Hoja actual hasta las siguientes 4 Hojas (5 en total) Caso de Uso: (Expandido) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman ) Curso Normal de los Eventos Acción de los actores 1. 2. asigna y despliega automáticamente en A el Nº de Guía de Recepción correlativo correspondiente y en B la fecha del sistema. Capturar Datos de Recepción de Productos Comprados. I. . la Fecha de la Guía de Despacho y el Nº de la Orden de Compra.356 JUAN BRAVO C.pueden contener cientos de frases . Calcula el costo promedio y lo actualiza Genera un original y 2 copias de la transacción realizada utilizando la interfaz de salida indicada. el Encargado de Recepción oprime el botón V para indicar al sistema el fin de la captura de datos. 13. El Encargado de Recepción cierra la interfaz de Transacción oprimiendo 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. la Transacción requerida la documenta con una Guía de Despacho o Factura. R1. R1. El Encargado de Recepción ingresa en M. Al terminar de ingresar los Productos. K y L respectivamente.2. Encargado de Recepción (Actor Primario). con lo cual el sistema pasa a 3. El Encargado de Recepción acuerda realizar la Transacción. quien envía a sus respectivos destinos las restantes copias también firmadas (según Flujograma de Información correspondiente).14. H. 26) “Los Casos de Uso Expandidos son extensas narrativas de descripción de un proceso . Caso de Uso Expandido Caso de Uso: (Expandido) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Caso de Uso Expandido Nota : (Craig Larman. Comuna. (Notificación de cumplimiento del compromiso).1. 10. Ver también: (Craig Larman.2. G.6. R1. El sistema despliega el Nº de Línea en LL. Fax) en F.10. pág. (Aceptación del compromiso) y para ello ingresa a la opción de Crear Guía de Recepción del Menú de Opciones haciendo (Click) y después oprimiendo la tecla (Tab). 6. 9. 6. Opcionalmente vuelve a oprimir (Tab) para ingresar otra recepción. El sistema despliega la interfaz de Creación de Guía de Recepción. a la vez que graba la línea recién completada. además actualiza los datos de la transacción en el sistema de almacenamiento persistente. desplegando los valores en T y U. al terminar confirma la Transacción. El Encargado de Recepción verifica visualmente el Nº de Guía de Recepción y Fecha ofrecidos por el sistema y a continuación ingresa su identificación (Código) en C.11. El sistema despliega los datos básicos del Proveedor (Razón Social. Respuestas del Sistema 3. 4. 15. El Encargado de Recepción verifica la entrega física (Cantidad y Estado General) contra lo indicado por el Documento adjunto y después registra en el Terminal de Recepción los datos consignados en el mismo. El sistema verifica la validez / existencia del Nº de la Orden de Compra. R1. “Limpia” la interfaz de entrada y posiciona el cursor en A. Este Caso de Uso comienza cuando un Proveedor contacta a un Encargado de Recepción para solicitarle que reciba los Productos que está entregando. 11. El Encargado de Recepción pasa a la sección de detalle. El Caso de Uso termina cuando el Proveedor se retira. 5. R1. Ciudad. pág. El sistema obtiene y despliega el nombre del Encargado de Recepción en D. R1.5.3.7. R1.“. El sistema calcula los valores subtotales / total y los despliega / redespliega en los campos T y U. Tipo: Referencias cruzadas: Funciones: R1.13. Primario y real. Dirección. R1. R1. (Petición). 7. El Encargado de Recepción verifica los datos del Producto e ingresa el costo unitario(Precio) y la cantidad recibida en R y S.9. e-Mail. Encargado de Recepción Terminal Recepción Crear Guía Interna de Recepción por Compras Caso de Uso : Crear Guía Interna de Recepción por Compra Actores : Propósito: Resumen: Proveedor Proveedor (Iniciador) . 8. en el cual ingresa el Código del Producto en P. J.7. 16.8 R1. N y O respectivamente el Nº de Guía de Despacho del Proveedor.3. obtiene y despliega la descripción del Producto en Q. R1. 50). Luego oprime (Tab) para grabar la línea actual y crear una nueva línea o terminar el ingreso de datos. R1. El Encargado de Recepción ingresa en E el RUT del Proveedor y verifica los datos del mismo desplegados por el sistema. R1. 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. 14.4.2. El sistema calcula el valor de la línea ingresada y lo acumula.12. 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. Teléfono.

Indicar error. Comunicarse con Administrador. Código Descripción Cantidad LL P Q R S T Cerrada Anulada W Y Cerrar X Anular Z XX Salir V Grabar Total acumulado U Caso de Uso: (Expandido) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Excepciones al Curso Normal de los Eventos: . Comunicarse con Administrador. Notas adicionales a la Interfaz de Entrada: ( para desarrollar en vueltas futuras de la espiral) Curso Normal 1) Considerar operacion(es) de Cerrado en Encabezado 2) Considerar operacion(es) y “flag” de Cerrada en Líneas Excepciones 3) Considerar operación(es) y “flag” de Reversado en Encabezado 4) Considerar operacion(es) de Anulado de Encabezado 5) Considerar operacion(es) y “flag” de Anulada en Líneas 6) Considerar operacion(es) y “flag” de Reversada en Líneas 7) Considerar operación(es) de Modificar en Encabezado 8) Considerar operación(es de Modificar en Encabezado 9) Considerar operación(es) de Cancelar en Encabezado 10) Considerar operación(es) de Cancelar en Líneas Nota: Se indican algunas de las excepciones posibles únicamente a modo de ejemplo. 3) Campo E : RUT de Proveedor no registrado (RUT no existe). 2) Campo M : Nº de Guía ya existe para el RUT del Proveedor. Proveedor Nº de O/C. L. .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). Recepción RUT Proveedor Dirección Proveedor Comuna C - Encargado Recepción Razón Social Proveedor D F Nº Guía Recepción Fecha Recepción e-Mail A B E G Ciudad M H Fax I J Fono K N Precio L O Valor Neto Guía de Despacho de Proveedor Nº Fecha G/ D. Comunicarse con Administrador. 5) Campo O : Nº de Orden de Compra no existe. Comunicarse con Departamento de Compras. 4) Campo C : Encargado de Recepción no registrado (Código no existe).MODELANDO UNA SOLUCIÓN DE SOFTWARE 357 Caso de Uso: (Expandido) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Interfaz de Entrada Guía Interna de Recepción por Compra Código Enc. rechazar.

. Empresa. Ordenes de Compra. .3 . 999. Por lo contrario.999.999 Cantidad 9999 Valor Neto 999999. Interfaz de Salida Guía de Recepción Nª RUT Proveedor 999. no necesariamente se encuentra el concepto de Orden de Compra..” pág 200) * Productos Código Descripción Costo 1 Ordenes de Compra Nº OC Fecha 1 Nota: Según Craig Larman (9.99 Firma Autorizada y Timbre Total Neto 99999999.4 ..págs. etc. (Puede ser un ingreso manual). Terminal.6. 99 Código XXXXXXX Descripción XXXXXXXXXXXX Precio 9999.99 Modelo Conceptual (simplificado) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Nota : En este modelo se consideran los conceptos mínimos. se podrían excluir : Empleados. Nota: Dentro de los requerimientos. En un análisis y desarrollo posteriores se podrían incluir conceptos tales como Bodega.págs.5 Detalle de Guía Interna de Recepción por Compra Descripción Costo Cantidad Nota: La flecha gruesa entre el Encabezado y el Detalle indica una Relación de Pertenencia.999 Fecha G/D Proveedor Nº de O/C.358 Caso de Uso (Expandido): Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) JUAN BRAVO C. Encabezado de Guía Interna de Recepción por Compra Nº de Guía Fecha Proveedor Nombre * Empleados Código Nombre * * Proveedores RUT Nombre Dirección 1 1 1 1. no se trata de un modelo de software.999 .3 y 9.999 Fecha 99/99/9999 Encargado Recepción XXXXXXX Razón Social Proveedor Dirección Proveedor Comuna XXXXXXX Ciudad Teléfono 99/99/9999 Fax XXXXXXX Nº G/D del Proveedor 999. 87 a 91 -.“La Nueva Visión.X XXXXXXX XXXXXXX e-Mail XXXXXXX XXXXXXX XXXXXXX 999.1 a 9.99 L.96 y 97) Se trata de conceptos.6. además de 9. asociaciones y atributos del mundo real. (Base Juan Bravo C.

pág.264) Salvo casos específicos.262 . 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 :Sistema Encargado de Recepción Ingresar a la Opción del Menú Desplegar la Interfaz Crear la Guía de Recepción Ingresar Código del Empleado en Encabezado Ingresar RUT del Proveedor en Encabezado Ingresar Nº Guía Proveedor. no necesariamente se encuentra el concepto de Orden de Compra. modificar().págs.. es conveniente omitir los métodos : crear(). Ingresar datos de G/D Proveedor ( Nº Guía.5 Detalle de Guía Interna de Recepción por Compra Descripción Costo Cantidad subtotal() Nota: Según Craig Larman (21. Fecha y Nº O/C en Encabezado Ingresar Código del Producto en Línea Detalle Reiterar hasta que no haya más Productos que ingresar Ingresar Precio y Cantidad del Producto Dar OK a la Línea de Detalle Calcular la Línea de Detalle Dar OK al Final para Terminar la Creación Salir al Menú . de Compra total() Nota: A diferencia del Modelo Conceptual. Ingresar Código del Empleado y obtener / verificar el nombre del mismo. Diagrama de Secuencia del Sistema Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) 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. métodos y relaciones pueden bosquejarse tempranamente en la etapa de Diseño” Encabezado de Guía Interna de Recepción por Compra RUT Proveedor Nº de Guía Proveedor Nº Guía Interna Fecha Recepción Código Enc.8.3. (A su vez se eliminó : Nombre) * * Proveedores 1 RUT Nombre Dirección validarRut() Empleados Código Nombre * 1 1 1.observando la interfaz de entrada -. que muestra atributos “útiles” para entender los conceptos del contexto. Ingresar RUT del Proveedor y obtener / verificar los datos del mismo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 359 Diagrama de Diseño de Clases (Borrador inicial) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Nota: Según Craig Larman (21. Recepción Fecha Guía Proveedor Nº de Ord.257): “ Si bien la presentación de los diagramas de clases es posterior a la creación de los diagramas de interacción. eliminar() y consultar() en los diagramas de clases dado que no agregan valor y aumentan el “ruido” .8 . la conveniencia de agregar otros atributos al encabezado. Fecha.8. en la práctica usualmente se crean en paralelo.se consideran implícitos - * Productos Código Descipción Costo costoProm() 1 Ordenes de Compra Nº OC Fecha 1 Nota: Dentro de los requerimientos.4 a 21. (Puede ser un ingreso manual). se “descubrió” . verificar correlativo y fecha. Muchas clases.

360
Diagrama de Secuencia del Sistema Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)
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 Proveedor ( 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ú

JUAN BRAVO C.

Versión llamando los Eventos por su Nombre
( equivalente a Operaciones del sistema)

:Sistema
Encargado de Recepción

ingresarOpción(CrearGuiaRecepcion) desplegar(NumGuiaRecCom, FechaR) crearEncabezado(NumGuiaRecCom, FechaR) ingresarCodEmpleado(CodigoEmpleado) ingresarRutProveedor(RutProveedor) ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC) ingresarCodProducto(CodigoProducto) Reiterar hasta que no haya más Productos que ingresar ingresarPrecioCantidad(Precio,Cantidad) grabarLínea() calcularTotales() terminarTransacción() salirAMenú()
Nota: desplegar es subordinado de
ingresarOpcion y no es invocado por el actor en forma directa.

Nota: calcularTotales es subordinado
de grabarLínea y no es invocado por el actor en forma directa.

Operaciones del Sistema Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Visión Dinámica del Sistema Sistema
ingresarOpción(CrearGuiaRecepcion) desplegar(NumGuiaRecCom, FechaR) crearEncabezado(NumGuiaRecCom, FechaR) crearEncabezado(NumGuiaRecCom, FechaR) ingresarCodEmpleado(CodigoEmpleado) ingresarRutProveedor(RutProveedor) ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC) ingresarCodProducto(CodigoProducto) ingresarPrecioCantidad(Precio,Cantidad) grabarLínea() calcularTotales() terminarTransacción() salirAMenu()

MODELANDO UNA SOLUCIÓN DE SOFTWARE

361

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: Responsabilidades: ingresarOpcion(CrearGuiaRecepcion) Aceptar (Click) en la opción del Menú. Obtener el siguiente Nº de Guía correlativo (NumGuiaRecCom). Obtener la fecha del sistema (FechaR) . Usar ambos parámetros para invocar el despliegue de la interfaz de CrearGuiaRecepción Sistema R1.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 Compra requerida instalados y activos.Además conoce y tiene acceso a EncGuiaRecCompra.NumGuiaRecCom

Tipo: Referencias cruzadas: Notas:
Nota:
Los nombres de elementos usados en los contratos hacen referencia al Diagrama de Secuencia de pág. 18, al Modelo de Clases de pág. Nº 38 y al Modelo Funcional de pág. Nº 39.

Excepciones: Salida: Precondiciones:

Postcondiciones: • Se aceptó (Click) en el Menú de Opciones. Nota: Obtener Fecha del sistema y obtener Nº de Guía correlativo son operaciones (métodos) que no son evidentes para el usuario en este momento, 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 NumGuiaRecCom y FechaR.

Contratos:Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: Responsabilidades: desplegar(NumGuiaRecCom, FechaR) 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

Tipo: Referencias cruzadas: Notas:
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.

Excepciones: Salida: Precondiciones:

El sistema tiene el Menú y la opción Crear Guía de Recepción por Compra requerida instalados y activos. Tiene disponibles a NumGuiaRecCom y FechaR. Postcondiciones: • 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: NumGuiaRecCompra en A y la Fecha: FechaR en B.

362

JUAN BRAVO C.

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: Responsabilidades: crearGuiaRecCompra(NumGuiaRecCom, FechaR) Crear instancias de EncGuiaRecCompra y DetGuiaRecCompra y establecer las asociaciones necesarias entre Terminal, EncGuiaRecCompra y DetGuiaRecCompra Sistema R1.15 El Empleado oprime (Tab) para cambiar de campo en la interfaz para el ingreso. Opcionalmente usa el “mouse” N/A N/A El sistema tiene el Menú, la opción Crear Guía de Recepción por Compra y la interfaz correspondiente requerida instalados y activos.

Tipo: Referencias cruzadas: Notas:
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.

Excepciones: Salida: Precondiciones:

Postcondiciones: • Se creó una nueva instancia de EncGuiaRecCompra (creación de instancia) • Se asoció EncGuiaRecCompra a Terminal (asociación formada) • Se creó una nueva instancia DetGuiaRecCompra (creación de instancia) • Se asoció DetGuiaRecCompra a 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

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: Responsabilidades: ingresarCodEmpleado(CodigoEmpleado) Aceptar el ingreso de CodigoEmpleado. Basado en CodigoEmpleado, obtener y desplegar Nombre registrado en el sistema de almacenamiento persistente. (Alternativa a Lista de Valores Posibles). A continuación posicionar el cursor en el campo E. Sistema R1.3, R1.4, R1.15 Usar Base de Datos MS Access y (Tab) para sucesivos campos Error en ingreso manual del Código o Código no registrado N/A El sistema conoce a Empleados.CodigoEmpleado (Registrado oportunamente con anterioridad)

Tipo: Referencias cruzadas:
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.

Notas: Excepciones: Salida: Precondiciones:

Postcondiciones: • Se desplegó CodigoEmpleado en C y Nombre en D.. • Se asoció EncGuiaRecCompra a una instancia de Empleados basado en una igualdad de CodigoEmpleado (asociación formada) • Se asignó CodigoEmpleado a EncGuiaRecCompra.CodigoEmpleado (modificación de atributo) Nota : Alternativamente ( desde Lista de Valores Posibles ) - Sustituyendo CodigoEmpleado por Nombre - Se asignó Nombre a EncGuiaRecCompra.Nombre (modificación de atributo). • Se posicionó el cursor en el campo E: RUT Proveedor

MODELANDO UNA SOLUCIÓN DE SOFTWARE

363

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: Responsabilidades: ingresarRutProveedor(RutProveedor) Aceptar el ingreso de RutProveedor, por su intermedio, obtener y desplegar los Datos del Proveedor registrados en el sistema de almacenamiento persistente. A continuación posicionar el cursor en el campo M. Sistema R1.5, R1.15 Usar Base de Datos MS Access - el Encargado de Recepción oprime (Tab) para pasar a los sucesivos campos Error en ingreso manual del RUT o RUT no registrado N/A El sistema conoce a Proveedores.RutProveedor (Registrado oportunamente con anterioridad)

Tipo: Referencias cruzadas:
Nota:
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.

Notas: Excepciones: Salida: Precondiciones:

Postcondiciones: • Se desplegó RutProveedor en el campo E • Se asoció EncGuiaRecCompra a una instancia de Proveedores basado en una igualdad de RutProveedor (asociación formada) • Se asignó RutProveedor a EncGuiaRecCompra.RutProveedor (modificación de atributo) • 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º

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Nombre:
Responsabilidades:

Contrato
ingresarNGuiaFechaNOrdC(NumGDP, FecGD, NumOC) Aceptar el ingreso de NumGDP, FecGD, NumOC, eventualmente verificar existencia del Nº de Orden de Compra registrada en el sistema de almacenamiento persistente. A continuación posicionar el cursor en el campo P. Sistema R1.6, R1.7 y R1.8, R1.15 Usar Base de Datos MS Access - el Encargado de Recepción oprime (Tab) para pasar a los sucesivos campos N/A N/A

Tipo:
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.

Referencias cruzadas: Notas: Excepciones: Salida: Precondiciones:

El sistema eventualmente conoce a EncOrdCompra.NumOC (Registrado oportunamente con anterioridad). Está disponible la Guía de Despacho del Proveedor. Postcondiciones: • Se desplegó NumGDP, FecGD, NumOC en los campos M, N y O • Eventualmente, se asoció EncGuiaRecCompra a una instancia de EncOrdCompra basado en una igualdad de NumOC (asociación formada) • Se asignó NumGDP a EncGuiaRecCompra.NumGDP (modificación de atributo) • Se asignó FecGD a EncGuiaRecCompra.FecGD (modificación de atributo) • Se asignó NumOC a EncGuiaRecCompra.NumOC (modificación de atributo) • Se posicionó el cursor en el campo P:Código.

364

JUAN BRAVO C.

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: Responsabilidades: ingresarCodProducto(CodigoProducto) Aceptar el ingreso de CodigoProducto. Basado en CodigoProducto, obtener y desplegar los Datos del Producto registrados en el sistema de almacenamiento persistente. Al oprimir (Tab) - fin de ingreso de CodigoProducto - asignar Número correlativo a la Instancia de DetGuíaRecCompra.NumLinea y pasar al campo Q. Si la Descripción es la correcta pasar (Tab) al campo R: Precio. Tipo: Sistema Referencias cruzadas: R1.9, R1.10, R1.15 Notas: Usar Base de Datos MS Access y tecla (Tab) Error en ingreso manual del Código o Código no registrado N/A El sistema conoce a Productos.CodigoProducto (Registrado oportunamente con anterioridad)

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.

Excepciones: Salida: Precondiciones:

Postcondiciones: • Se redesplegó CodigoProducto en P • Se desplegó el Número de Línea NumLínea en LL • Se asoció DetGuíaRecCompra a una instancia de Productos basado en una igualdad de CodigoProducto (asociación formada) • Se asignó NumLínea a DetGuiaRecCompra.NumLínea ( modificación de atributo ) • Se asoció la nueva línea de DetGuíaRecCompra a EncGuíaRecCompra (asociación formada) • Se asignó CodigoProducto a DetGuiaRecCompra.CodigoProducto (modificación de atributo) • Se desplegó la Descripción del Producto, Descripcion en Q. • Se posicionó el cursor en R: Precio

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
ingresarPrecioCantidad(Precio, Cantidad) Aceptar el Precio del Producto del Proveedor en R, avanzar con (Tab) hasta el campo S. Aceptar Cantidad en S. Si todo está correcto pasar con (Tab) al campo T. Sistema R1.11 y R1.12 Usar Base de Datos MS Access N/A N/A El sistema conoce a Productos.Existencia (Registrado oportunamente con anterioridad) • Se posicionó el cursor en R • Se redesplegó Precio en R y se posicionó el cursor en S. • Se redesplegó Cantidad en S • Se asignó Precio a DetGuiaRecCompra.Precio y Cantidad a DetGuiaRecCompra.Cantidad ( modificación de atributos) • Se posicionó el cursor en T: Valor Neto

Nombre:

Responsabilidades:

Tipo:
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.

Referencias cruzadas: Notas: Excepciones: Salida: Precondiciones: Postcondiciones:

MODELANDO UNA SOLUCIÓN DE SOFTWARE

365

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: grabarLínea() Responsabilidades: Aceptar avance con (Tab) hasta la siguiente línea de la interfaz, creando una nueva Línea de DetGuiaRecCompra. Calcular /ValorLínea y desplegarlo en T de la línea previa. Grabar en almacenamiento persistente un registro de DetGuiaRecCompra con los datos ingresados/calculados en la línea previa (anterior). Calcular /ValorTotal y desplegarlo en U. Posicionar el cursor en P de la nueva línea. Tipo: Sistema Referencias cruzadas: R1.13, R1.15 Notas: Usar Base de Datos MS Access. En este punto el sistema queda listo para reiterar el ingreso de un nuevo código CodigoProducto o caso contrario, pasar a terminarTransacción() N/A N/A N/A

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.

Excepciones: Salida: Precondiciones:

Postcondiciones: • Se calculó /ValorLínea y se desplegó en T • Se calculó/recalculó /ValorTotal y se desplegó/redesplegó en U. • Se asignó /ValorLínea a DetGuiaRecCompra./ValorLínea ( modificación de atributo ) • Se grabó en almacenamiento persistente el registro de DetGuiaRecCompra recién completado • Se creó una nueva Línea de DetGuiaRecCompra. (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.

Contratos: Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman)

Contrato
Nombre: terminarTransacción() Responsabilidades: Aceptar (click) del Botón V (Grabar). Recalcular /ValorTotal y redesplegarlo en U. Grabar en almacenamiento persistente la instancia actual de EncGuiaRecCompra.”Limpiar” los datos desplegados en la interfaz. Actualizar Productos.Existencia, Productos.Recibido, Productos.CostoUn y DetGuiaRecCompra.notAct. Posicionar en A el cursor. Tipo: Sistema Referencias cruzadas: Notas: R1.2, R1.14, R1.15 Usar Base de Datos MS Access. Al terminar, el sistema queda listo para ingresar una nueva transacción o volver al Menú de opciones. Productos.Existencia y Productos.Recibido ya fueron actualizados. N/A N/A

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.

Excepciones: Salida: Precondiciones:

Postcondiciones: • Se activó onClick_CBGrabar de commandGrabar • Se recalculó /ValorTotal y se grabó/regrabó en almacenamiento persistente la instancia EncGuiaRecCompra y las líneas completadas DetGuiaRecCompra. • Se verificó notAct() de DetGuiaRecCompra y se actualizó Productos.Existencia, Productos.Recibido y Productos.CostoUn, regrabando los registros de Productos afectados por la transacción (modificación de atributo), después de ello, se le asignó el valor false al 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 EncGuiaRecCompra fue asociada a Terminal (asociación formada) • Se creó una nueva DetGuiaRecCompra ( creación de instancia) (en blanco) • Se asoció la nueva instancia de DetGuiaRecCompra a EncGuiaRecCompra (asociación formada) • Se posicionó el cursor en A, esperando la próxima acción del usuario.

366

JUAN BRAVO C.

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 clases de diseño y los diagramas correspondientes -.

Diagramas de Colaboración: Creación de EncGuiaRecCompra ingresarOpcion(CrearGuiaRecepcion) desplegar(GuiaRecCompra) crearEncabezado(NumGuiaRecCom, FechaR) (Productos con registro persistente) (Base Craig Larman)
Nota: desplegar() es método propio de Terminal, por ello este mensaje no va más allá de este punto. ingresarOpcion(CrearGuiaRecepcion) desplegar(GuíaRecCompra)

Nota: ingresarOpcion(CrearGuiaRecepcion) es un método del Menú. La clase Fecha es una clase del Sistema en sí - siendo ahora() un método de la misma-, mientras que desplegar(Guia RecCompra) pertenece a Terminal y siguiente() pertenece a la clase EncRecCompra - aún cuando esta última es una función genérica reutilizable-. Nota: En forma excepcional se representan en este diagrama de colaboración los mensajes correspondientes a dos operaciones y sus respectivos contratos (desplegar es subordinado de ingresarOpcion).

t1:Terminal

1:NumGuiaRecCom := siguiente():NumGuia

:EncGuiaRecCompra

2:FechaR := ahora():Fecha

Fecha

crearEncabezado(NumGuiaRecCom, FechaR)

t1:Terminal

3 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom, FechaR)

r 1:EncGuiaRecCompra

Omisión del Contenedor de Líneas Nota: Según Craig Larman ( 21.8.6 - pg.262 ) : “ Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / colección en sí mismo... estas clases ( tales como java.util.Vector... ) son clases predefinidas de la biblioteca de clases... no es útil mostrarlas explícitamente... agregan “ruido” pero poca información nueva. ”

3.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom)

Nota : crearDetRecCompra() es una de las 4 funciones básicas implícitas. (Podría ser omitida en el Modelo de Datos).

l1:DetGuiaRecCompra

f: Fono := consultarDatos (RutProveedor) 2. e1:Empleados ingresarRutProveedor(RutProveedor) 2:ingresarRutProveedor(RutProveedor) t1:Terminal r1:EncGuiaRecCompra 2. FecGD. FecGD) 1. NumOC) r1:EncGuiaRecCompra t1:Terminal ingresarNGuiaFechaNOrdC(NumGDP.d:Comuna := consultarDatos (RutProveedor) 2.11 . La forma y secuencia de los mensajes que activarán las operaciones respectivas se derivan de la aplicación de estos patrones.1. NumOC) ll:DetGuiaRecCompra .e:Ciudad := consultarDatos (RutProveedor) 2.193 a 205 ) La aplicación de los patrones GRASP es la guía para determinar las responsabilidades y la estructura del diagrama.1:Nombre := consultarDatos(CodigoEmpleado) Asignación de Responsabilidades Nota: Según Craig Larman ( 18. NumOC) 1: ingresarNGuiaFechaNOrdC(NumGDP.pág.a: aceptarDatos(NumGuiaRecCom. FecGD.9 a 18. FecGD.1. NumOC) es equivalente a repetir tres veces la función aceptarDatos().MODELANDO UNA SOLUCIÓN DE SOFTWARE 367 Diagramas de Colaboración: Creación de EncGuiaRecCompra ingresarCodEmpleado(CodigoEmpleado) ingresarRutProveedor(RutProveedor) (Productos con registro persistente) ingresarCodEmpleado(CodigoEmpleado) (Base Craig Larman) t1:Terminal 1:ingresarCodEmpleado(CodigoEmpleado) r1:EncGuiaRecCompra 1.1. enviando cada vez un parámetro correspondiente a un atributo distinto de la misma instancia de 1. NumOC) (Productos con registro persistente) (Base Craig Larman) ingresarNGuiaFechaNOrdC(NumGDP.c: eMail := consultarDatos (RutProveedor) 2.1. NumGDP) 1.b:Direccion := consultarDatos (RutProveedor) 2.g:Fax := consultarDatos (RutProveedor) p1:Proveedores Diagramas de Colaboración: Creación de EncGuiaRecCompra ingresarNGuiaFechaNOrdC(NumGDP.1. FecGD.c: aceptarDatos(NumGuiaRecCom.b: aceptarDatos(NumGuiaRecCom.1.a:RazonSocial := consultarDatos (RutProveedor) 2.1.

1... agregan “ruido” pero poca información nueva.6]: /ValorLínea := calcularValor() Nota:No se muestra la secuencia de mensajes que correspondería a grabarLinea().2:Descripcion := consultarDatos(CodigoProducto) ll:DetGuiaRecCompra b1:Productos Omisión del Contenedor de Líneas Nota: Según Craig Larman ( 21.2:crearLinea(NumLinea) 1.6 .pg. estas clases ( tales como java.Vector.1 *:[i:=1.1:aceptarCodigo(CodigoProducto) 2..11 .. en cuyo caso pasa a la siguiente acción : terminarTransaccion() . La forma y secuencia de los mensajes que activarán las operaciones respectivas se derivan de estos patrones. (Otro conjunto de diagramas .368 JUAN BRAVO C..util.6] NumLínea:= siguiente () : NumLinea t1:Terminal r1:EncGuiaRecCompra Asignación de Responsabilidades Nota: Según Craig Larman ( 18. Cantidad) ll:DetGuiaRecCompra r1:EncGuiaRecCompra t1:Terminal 2: /ValorTotal := calcularTotales() 2.1:aceptarDatos(Precio.. ) son clases predefinidas de la biblioteca de clases.no abordado aquí -). Cantidad) t1:Terminal 1:ingresarPrecioCantidad(Precio..193 a 205 ) La aplicación de los patrones GRASP es la guía para determinar las responsabilidades y la estructura del diagrama..8.262 ) : “ Un mensaje a un multiobjeto se interpreta como un mensaje al objeto contenedor / colección en sí mismo.6] NumLínea:= siguiente () : NumLinea 2.. Diagramas de Colaboración: Creación de EncGuiaRecCompra ingresarCodProducto(CodigoProducto) (Productos con registro persistente) (Base Craig Larman) ingresarCodProducto(CodigoProducto) siguiente () : NumLinea 1:ingresarCodProducto(CodigoProducto) 2 *:[i:=1.9 a 18. Cantidad) r1:EncGuiaRecCompra Nota: calcularTotales es grabarLinea() calcularTotales() subordinado de grabarLínea y no es invocado por el actor en forma directa. ll:DetGuiaRecCompra Nota: Después de grabarLinea() el usuario vuelve a la acción anterior de ingresarCodProducto() hasta que no queden más productos que ingresar..1*:[i:=1...pág. no es útil mostrarlas explícitamente. Cantidad) grabarLínea() y calcularTotales() (Productos con registro persistente) (Base Craig Larman) ingresarPrecioCantidad(Precio. Esta correspondería a la interacción entre la capa del dominio (aplicación) y la capa de servicios de almacenamiento persistente.. 1. ” Diagramas de Colaboración: Creación de EncGuiaRecCompra ingresarPrecioCantidad(Precio..

calcularTotales() Nota:terminarTransacción() es realmente un mensaje “compuesto” .. Cantidad) 2..b*:[i:=1. Precio) ll:DetGuiaRecCompra b1:Productos Diagramas de Colaboración: Creación de EncGuiaRecCompra terminarTransaccion() (Segunda Parte) (Productos con registro persistente) (Base Craig Larman) siguiente():NumGuia ahora():Fecha Nota: terminarTransacción() finalmente “termina” enviando los mensajes para crearEncadezado() y obtener los datos de inicialización desplegándolos en la interfaz “limpia”.6 ][notAct] sumarRecibido(CodigoProducto.1. se usarían los patrones aplicables .c*:[i:=1.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom) l1:DetGuiaRecCompra .a*:[i:=1.1*:[i:=1.. Indirección. Cantidad) 2.3*:[i:=1.... Precio) 2..6 ][notAct] calcularCPP(CodigoProducto. Esto es.b*:[i:=1. sumarExistencia() se realiza en la capa de dominio. Cantidad) sumarRecibido(CodigoProducto.6 ][notAct] sumarExistencia(CodigoProducto.MODELANDO UNA SOLUCIÓN DE SOFTWARE 369 Diagramas de Colaboración: Creación de EncGuiaRecCompra terminarTransaccion() (Primera Parte) (Productos con registro persistente) (Base Craig Larman) Nota: terminarTransaccion() es muy amplio y se presenta dividido en dos partes. FechaR) t1:Terminal r 1:EncGuiaRecCompra 5. Cantidad.6 ][notAct] calcularCPP(CodigoProducto. Cantidad.. que se desdobla en : calcularTotales() y los mensajes que interactúan con las capas de almacenamiento persistente y presentación......c*:[i:=1. por ejemplo.. Cantidad) 2.6 ][notAct] sumarExistencia(CodigoProducto. sin embargo se registra en la capa de almacenamiento persistente (Tema no considerado aquí) t1:Terminal 1: /ValorTotal := calcularTotales() r1:EncGuiaRecCompra 1..b*:[i:=1. Cantidad) 2. t1:Terminal 3:NumGuiaRecCom := siguiente():NumGuia :EncGuiaRecCompra 4:FechaR := ahora():Fecha Fecha crearEncabezado(NumGuiaRecCom.2.... Para implementar el mensaje “compuesto” terminarTransacción() ” (completo). FechaR) 5 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom.2.6 ][notAct] calcularCPP(CodigoProducto.6 ][notAct] sumarRecibido(CodigoProducto..c*:[i:=1.1.entre otros. Cantidad) 2... Cantidad. por ejemplo. (Tema no abordado aquí). Precio) ll:DetGuiaRecCompra t1:Terminal r1:EncGuiaRecCompra 2. Fachada.6 ][notAct] sumarRecibido(CodigoProducto.a*:[i:=1. Por cierto que esto implica una interacción entre la capa de dominio y la capa de presentación.2.6 ][notAct] sumarExistencia(CodigoProducto. Cantidad..1. Cantidad) calcularCPP(CodigoProducto. Observador -. Cantidad) 2.6 ][notAct] notAct := notAct(notAct := false) 2. Precio) 2.6] /ValorLínea := calcularValor() sumarExistencia(CodigoProducto.a*:[i:=1.

C/E. notAct se incializa a: true Modelo Funcional (Detallado y Generalizado) Crear Guía Interna de Recepción por Compra (Productos con Registro persistente) (Base este libro) Encabezado de Guía de Recepción •RUT Proveedor •Nº Guia Proveedor Nº Guía Recepción Fecha Recepción Código Empleado Fecha Guía Proveedor Nº Orden de Compra / Valor Total C/E.8. consultarDatos() Terminal Encabezado. calcularTotales() 7. 4. Calcular totales cumulativos 6. calcularCPP() Guía de Despacho de Proveedor • Nº Guía de Proveedor RUT Proveedor Fecha Guía etc. crearLínea() 2. Enviar mensajes de consulta de datos 5. anularTransacción() 9. msg2. detalle y totales según formato de pantalla adjunto. Guía de Despacho de Proveedor • Nº Guía de Proveedor RUT Proveedor Fecha Guía etc. es conveniente omitir los métodos : crear().. sumarDespachado() 10. 3. anularLínea() 9. msg1. y msg11 Detalle de Guía de Recepción •Nº Línea Código Producto Precio Cantidad / Valor línea notAct Línea Cerrada Línea Anulada 1. eliminar() y consultar() en los diagramas de clases dado que no agregan valor y aumentan el “ruido” .264) “Salvo casos especificos. notAct() C/E. aceptardatos() 6.370 JUAN BRAVO C. cerrarLínea() 8.Medida Costo Unitario Existencia Inicial Existencia Recibido Despachado 4. en principio es una Lista de Valores Posibles. aceptarDatos() 6. consultarDatos() Empleados •Código Empleado Nombre . Enviar mensajes de actualización de existencias y actualizar línea a línea el registro de la transacción Transacción Cerrada Transacción Anulada 1. Ordenes de Compra 1 • Nº Orden de Compra Datos Nota: Según Craig Larman (21... msg4. 4.. aceptarCodigo() 3. msg6. Diagrama de Diseño de Clases Crear Guía Interna de Proveedores Recepción por Compra (Productos con Registro •RUT Proveedor Razón Social persistente) Dirección e-Mail Comuna Ciudad País Contacto Fono Fax Encabezado de Guía de Recepción * 1 1 • RUT Proveedor • Nº Guía Proveedor Nº de Guía Recepción Fecha Recepción Código Empleado Fecha Guia Proveedor Nº Orden de Compra / Valor Total Transacción Cerrada Transacción Anulada crearEncabezado() aceptarDatos() calcularTotales() cerrarTransacción() anularTransacción() copiarTransacción() siguiente() Empleados * * 1 • Código Empleado Nombre Nota: Agregado para clarificar el contexto. msg8 y msg11 Productos •Código Producto Descripción U. calcularValor() 7. consultarDatos() Nota: Al crear la línea de detalle.. cerrarTransacción() 8.4 a 21.. 1. copiarLínea() 10. copiarTransacción() 10. (ingreso manual). 2. (ingreso manual). Desplegar interfaz(Correlativo. 4.8. (ingreso manual). siguiente() C/E y msg4 Nota: Agregado para clarificar el contexto. Aceptar datos.pgs.262 . msg6. siguiente() 11. consultarDatos() C/E y msg4 Ordenes de Compra • Nº Orden de Compra Datos 4. crearEncabezado() 2.8 . sumarExistencia() 7.Medida Costo Unitario Existencia Inicial Existencia Recibido Despachado sumarExistencia() restarExistencia() sumarRecibido() sumarDespachado() existenciaNegativa() calcularCPP() 1 * Nota: Agregado para clarificar el contexto..* Detalle de Guía de Recepción •Nº Línea Código Producto Precio Cantidad / Valor Línea notAct Línea Cerrada Línea Anulada crearLínea() aceptarCodigo() aceptarDatos() calcularValor() cerrarLínea() anularLínea() copiarLínea() siguiente() notAct() 1 Nota: Agregado para clarificar el contexto. msg1. msg6 y msg10 Proveedores C/E y msg4 •RUT Proveedor Razón Social Dirección e_Mail Comuna Ciudad País Contacto Fono Fax 4. 1 Productos •Código Producto Descripción U. notAct se incializa a: true . sumarRecibido() 9. modificar(). msg10 C/E y msg4 msg3. Fecha). 1. msg2. existenciaNegativa() 11. restarExistencia() 8.se consideran implícitos - Nota: Al crear la línea de detalle. consultarDatos() 6. Enviar mensajes de C/E a registros.

(1979): Rediseñando el futuro. Pontificia Universidad Católica. Chile. BRAVO. R. USA. Limusa. (1972): Un concepto de planeación de empresas. “Modelamiento de datos y funciones”. G. septiembre 30. M. AT&T Quality Process Center (1992): Reengineering Handbook. ACKOFF. Revista Ejecución. Universidad de Chile.MODELANDO UNA SOLUCIÓN DE SOFTWARE 371 BIBLIOGRAFÍA ACEVEDO. Valparaíso. México. y GUZMÁN. ANDREU. año 2. R. J. año 10. P. Empresa Binaria S. R. Quinta edición. Chile. julio de 1990. (1996): El análisis estructurado de sistemas y el desarrollo de proyectos informáticos. y ALARCÓN. BAEZA. Daniel T. ACKOFF.): • Desarrollo de sistemas de información. número 21. (1994): “Programación orientada al objeto en sistemas comerciales”. G. H. RICART. volumen 4. J. D. McGraw-Hill. Chile. marzo de 1985. USA. McGraw-Hill. Santiago de Chile. Chile. R. I.. España. Revista Akádemeia. Limusa. la productividad es la clave (2005) • Gestión de Proyectos de Procesos y Tecnología (2006) • Responsabilidad Social (2007) BOOCH. CERDA. CARROL. Ediciones Folio. Biblioteca de empresa del Financial Times. Revista Akádemeia. México. CERDA. Society for management information system proceeding. (1991): “Apuntes del curso orientación a objetos”. CHIAVENATO. (2004): “Algunas recomendaciones a aplicar en el diseño de interfaces de software”. (2000): lntroducción a la teoría general de la administración. (1999): Administración de Proyectos Civiles. BRAVO. volumen 7. J. Universidad de Ciencias de la Informática. ALLEN.A. volumen 2. diciembre de 2002. México. AT&T Bell Laboratories. (2002): “¿Estamos diseñando las interfaces de Software correctas?”. Barcelona. libros (Santiago de Chile. Universidad de Ciencias de la Informática. will object-oriented programming transform the computer industry?”. (1976): How the president satisfies his information systems requirements. (1991): Object Oriented Design with Applications. Editorial Evolución S. número 2. y GARCÍA. CAMPERO. J. “Software made simple. Benjamin/Cummings. y VALOR. M. 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. artículos: “¿Se justifica el desarrollo de un sistema computacional?” Revista Informática. . (1994): Desarrollo con éxito de nuevos productos. G. COLLADO. R. (1991): Estrategia y sistemas de información. Business Week (1991).A. L. número 2. diciembre de 2004. USA. Ecogestión Editora.

Madrid. (London) LTD DAVIDSON. KOTTER. Planeta. Regional Information Technology Studies. F. Processes for executing software projects at Infosys. México. Madrid. Chile. (1980): Structured Programming. (1989): Object-oriented concepts. GOLDIN. (1979): Principies of program design. COMISIÓN PRESIDENCIAL (1999): “Tecnologías de información y comunicación. Quinta Edición. K. GILLENSON. R. (1992): Object data management. Diario El Mercurio (12 de febrero de 1995): “Proteínas que piensan”. K. (1987): Introducción a las Bases de Datos. S. 1979.. y KENDALL. K. y REINERT. (2005): Tus ideas lo cambian todo. y ROBINSON. and applications. Sergio M. DAHL. Madrid. R. Planeta. (London) LTD. ACM PRESS. Concepts. (2000): CMM in practice. USA. J. Revista Mundo Electrónico. una poética para el gerente del tercer milenio. INTERNATIONAL Data Corporation (1995): “Latin America Research Prospectus”. conceptos e implicancias para la empresa. KOVACEVIC. Chile. Buenos Aires. Databases. y LOCHOVSKY. (1999): UML y Patrones. Sudamericana. Prentice-Hall. J. (1994): Gerencia versus sistemas de información. databases. M. Manuel. Buenos Aires. W. . Nº 143. G. (2000): El proceso unificado de desarrollo de software. P. GETZ. Alfaomega. y GONZÁLEZ. C. M. USA. J. Santiago de Chile. Santiago de Chile. Coedición CEFEPAL y Paulinas. KIM. México. México. JACOBSON. McGraw-Hill. JACKSON. KHOSHAFIAN. Madrid.A. D. (1995): Fundamentos del diseño y la programación orientada a objetos. Academic Press Inc. Prentice Hall. New York. McGraw-Hill. I. KENDALL. Pearson. México. E. M. (1990): Sistemas de Información. México. Languages. (2006): Inteligencia social.. (1984): “Introducción a la Ingeniería del Software”. Sun Microsystems. (1993): Administración y futuro. R.A. FAIRLEY. Ediciones Asterión Ltda. A. California. GOLEMAN. IBM de Chile S. Santiago de Chile. USA. User Interfases. Editorial Norma. BOOCH. Pearson educación. DIJKSTRA. GRAHAM.. (1986): ¿Qué es el control total de calidad? La modalidad Japonesa. y ABNOUS. LARMAN. AddisonWesley. Universidad Católica de Chile. (mayo de 1993): “Humanizando la tecnología”. Pearson. (1988): Software Engineering: planning for change. (2007): Arte y gestión. FRIEDMANN. Taurus. Addison-Wesley Publishing Company. y RUMBAUGH. GATTELL. JALOTE. LAMB. España. D. DRUCKER.372 JUAN BRAVO C. McGraw-Hill. Addison-Wesley Publishing Company. C. John Wiley & Sons. Deusto. (2005): Análisis y Diseño de Sistemas. J. A. Inc. Presidencia de Chile. ISHIKAWA. (2004): Liderazgo. (2007): Globalización para el desarrollo. J. I. (2001): La Gestión de Proyectos. El periodista. Colección HBR. LARRAÑAGA. FERNÁNDEZ S. (1987): Ingeniería de Software. R. COSTA Romero de Tejada. Academic Press Inc. Muéstrame tu Rostro. (1992): Object oriented methods. COVACEVICH. Inc. Revista Providencia 655. I. I. GLADWELL. A. Argentina. 1995.. S. (2006): Inteligencia Intuitiva. I. Addison Wesley. (1990): Object orientation. P. y HOARE. A. Chile: Hacia la sociedad de la información”. USA. Colombia. Bogotá.

(1996): Human-Computer Interaction. (2002): Ingeniería de Software. McCONNELL. J. S. Buenos Airtes. el desafío de hoy para la empresa del futuro. ROCKART. REVISTA AMÉRICA ECONOMÍA Telecomunicaciones. El groupware que ya viene. Biblioteca Harvard de Administración de Empresas. MARTIN. USA. REVISTA COMPUTERWORLD. España. Facturas digitales. julio de 1994. México. PARIKH. El difícil mundo de ERP. S. REVISTA MICROBYTE. creación y sostenimiento de un desempeño superior. Archivos con rostros. y TAUER. USA. España. septiembre/94. N. J. y ODELL. USA. Doce pasos para diseñar Bases de Datos relacionales. Reingeniería de negocios. Pearson. MARTIN. (1992): Ventaja competitiva. Santiago de Chile. McGraw-Hill. La realidad de la reingeniería. ¿una ventaja?. teoría y práctica. México. enero de 1995. y otros autores. marzo de 1996. octubre de 1991. H. PORTER. (2004): Re-imagina. 3ª edición. (1981): “A primer on critical sucess factors”. EDI: negocios con rapidez electrónica. Aprovechando el potencial de CASE. AddisonWesley. mayo de 1993. LIPSCHUTZ. Madrid. PREECE. Más vale la respuesta rápida. septiembre/94. Reingeniería en las hipotecas. . REVISTA INFORMÁTICA. IEEE Computer Society. USA. Santiago de Chile. PETERS. McGraw-Hill. (1994): Análisis y diseño orientado a objetos. (1983): Tutorial on Software Maintenance. (1979): “Los altos directivos definen sus necesidades de información”. julio de 1995. y Bullen. R. marzo de 1993. (1996): Systems Analysis. USA. J. C. Bases de Datos de Objetos. (1993): Ingeniería de Software. G. Massachusetts Institute of Technology. un enfoque práctico. McGrawHill. J. PFLEEGER. Infogerencia y High Tech Chile. Silver Springs. M. El giro al servicio. REVISTA NEWS 3X/400. (1985): La sociedad telemática. junio de 1993. (1997): Desarrollo y gestión de proyectos informáticos. abril/93. septiembre/94. J. MODELL. el desafío del mañana. Objetos: La revolución de los 90. un gran ejemplo de reingeniería de procesos. Editorial Pairos. Serie Schaum. J. Santiago de Chile. Unión Europea. Buenos Aires. suplementos 2º semestre 1994. Pearson.MODELANDO UNA SOLUCIÓN DE SOFTWARE 373 LEDGARD. T. marzo de 1991. OECD (2000): Information Technology Outlook 2000. J. abril de 1993. Addison-Wesley. (1987): Software Engineering Concepts. McGraw-Hill. (1987): Teoría de Conjuntos y Temas afines. PRESSMAN. Madrid. ROCKART. Continental. agosto de 1995. M. septiembre/93. S. Prentice-Hall. Argentina. Reutilización: El sueño de la Ingeniería de Software. y SVEGINTZOV.

W. USA. Thomson. y COAD. Santiago de Chile. S. las ciencias cognitivas: tendencias y perspectivas. (1987): Análisis y diseño de sistemas de información. S. and Mellor. Prentice Hall. Prentice Hall. (2005): Ingeniería del software. y WIENER. (1992): “Object-oriented Technology” (incluye Métodos de Grady Booch y Coad/Yourdon). YOURDON. 13 de octubre. I. Chile. P. (1984): Teorías del aprendizaje. Modeling the world in Data. Editorial Gedisa. USA. SOMMERVILLE. Java e Internet. 7ª ed. (1986): Diseño de Bases de Datos. (1992): La Quinta Disciplina. Bussiness week. (1999): Análisis de la causa raíz. y SCHWARTZ. Prentice Hall. 18 de noviembre. Prentice Hall. y DUGUID.374 JUAN BRAVO C. L. J. B11. SENGE.. Popkin Software & System Inc. H. P. Prentice Hall. El Ateneo. WILKERSON. (2001): La vida social de la información. WIRFS-BROCK. Yourdon Press computing series. (1992): Object Lifecycles. E. Madrid. B. . y COAD. Rob (2002): Utilización de UML en Ingeniería del software con Objetos y Componentes. Buenos Aires. YOURDON. SEELY. YOURDON. Santiago de Chile. Modeling the world in states. J. E. México. USA. VARELA. YOURDON. G. L. and M. Yourdon Press Computing Series. McGraw-Hill. will object programming transform the computer industry”. (1991): Object-oriented Analysis. Yourdon Press Computing Series. Oxford University Press. México. WILSON. C. J. Yourdon Press Computing Series. Pearson Educación. SHLAER. USA. CIISA. México. WEITZENFELD. (1991): Object-oriented Design. Diario Financiero. USA. P. Prentice Hall. Granica y Vergara. L. (1992 y 1994): “Apuntes de los cursos análisis y diseño orientado al objeto”. TAYLOR. SOLMINIHAC. Prentice Hall. Buenos Aires. R. Buenos Aires. México. VERITY. New Jersey. G. Pearson (p. E. Prentice Hall.. y Anderson. México. (1990): Designing Object-Oriented Software. Argentina. Perdita y POOLEY. USA. (1990): Software engineering with student project guidance. (2005): “La gestión de costos de proyectos”. Alfredo (2005): Ingeniería de software orientada a objetos con UML. PrenticeHall. YOURDON. Clase ejecutiva de El Mercurio. (1969. una herramienta para administración de la calidad total. Barcelona. Segunda edición. P. (1991): “Software made simple. S. P. WIEDERHOLD. SWENSON. SYSTEM ARCHITECT. E. SENN. SHLAER. (1989): Managing the Structured Techniques. 6). USA. McGrawHill. P. (2005): “¿Cuál es la rentabilidad de la informática en su empresa?”. (1990): Conocer. Yourdon Press computing series. F. USA. B. y COAD.. STEVENS. F. TOLOZA. (1991): Object-oriented Design. original de 1911): Principios de la administración científica. Dell. E. TEASLEY. Paidós. septiembre 30. (1988): Object-oriented systems Analysis. E.

es poco lo que logra realizarse porque no se sabe cómo hacerlo.. Sin embargo. . Este libro complementa. provocando grandes pérdidas en las mismas organizaciones y en la sociedad por proyectos mal planteados o fuera de costo y plazo. productos defectuosos. La gestión de procesos es un deseo que se intuye como importante en las organizaciones. trámites que demoran más de la cuenta. sobre todo. como un medio para lograr la eficiencia y agregar valor para el cliente en una relación de confianza.) El objetivo del libro es aportar métodos concretos para el rediseño y mejora de procesos en la organización.MODELANDO UNA SOLUCIÓN DE SOFTWARE 375 LIBROS DEL AUTOR PUBLICADOS POR EDITORIAL EVOLUCIÓN GESTIÓN AVANZADA DE PROCESOS Precio versión en papel: US$ 15. Surge de una profunda inquietud por el despilfarro de recursos en nuestra sociedad y. el cual es prerrequisito para éste. por la subutilización del enorme potencial de las personas. Chile $10. entregas con retraso. aporta técnicas y muestra aplicaciones de los conceptos desarrollados en el libro Gestión de Procesos. mala atención de clientes. equivocaciones médicas. 190 Págs. 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. 21 x 14 cm.000 (2009.

competitividad.. 2ª edición. ¿para qué?. Chile $16. o la forma cómo hacemos las cosas. . 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. como la calidad. por su condición de seres humanos. ¿cómo?. 24. comunicación y rentabilidad. Lo pueden hacer.2 cm. productividad. GESTIÓN DE PROCESOS GESTIÓN DE PROCESOS Precio versión en papel: US$ 24.000 (2006. Más difícil es cambiar nosotros mismos o que cambie nuestra organización.5 x 17. Porque. La gestión de procesos es un medio para lograr grandes metas organizacionales. a las cuales podríamos llamar… procesos. La gestión de procesos nos insta a detenernos. 400 Págs.376 JUAN BRAVO C. reflexionar acerca de lo que hacemos y preguntarnos: ¿por qué?.) (1ª edición de 2005) Es fácil aceptar la necesidad de cambio en nuestro mundo. porque son capaces. Lo deben hacer.

.000 (2008. ¿será posible profesionalizar su elaboración? ¡Sí! Definitivamente el diseño de sistemas puede ser arte y tecnología a la vez. 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.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. Sin perder la belleza y creatividad. 260 Págs. planificació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 comprendida y evaluada. Es importante hacer bien los proyectos.) 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. porque tampoco disfrutamos de los beneficios del proyecto si hubiese sido bien hecho. 24.) El objetivo de este libro es ofrecer un método para la gestación.000 (2006. Modelar soluciones de software es una labor bella y creativa que origina verdaderas “obras de arte”. Las empresas públicas y privadas de Chile pierden anualmente más de 2. 21 x 14 cm. MODELANDO UNA SOLUCIÓN DE SOFTWARE Precio versión en papel: US$ 24. Chile $16. 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. Chile $10. evaluación. dirección y buena ejecución de los proyectos. . 392 Págs.MODELANDO UNA SOLUCIÓN DE SOFTWARE 377 GESTIÓN DE PROYECTOS Precio versión en papel: US$ 15.. principalmente de procesos y tecnología.5 x 17 cm.

Es el caso. 2ª edición 230 Págs. emprendimiento. comunicación. delincuencia. 24. el énfasis ha estado en la prevención. Por eso la RS es la nueva causa de la riqueza de las Naciones. mala educación. Es un libro orientado a todas las personas que quieren comunicarse mejor con quienes les rodean para incrementar la calidad de su vida.000 (2007.) y de ganar fomentando la Responsabilidad Social (investigación. ¿Por qué? Porque la comunicación es cambio que podemos guiar hacia la superación personal.378 JUAN BRAVO C.. Chile $16. Por supuesto.). Surgen de dejar de perder evitando la Irresponsabilidad Social (accidentes.5 x 13 cm.5 x 17. además la mejora en las comunicaciones en las empresas tiene un efecto inmediato en la vida familiar y social de sus trabajadores..000 (2007. RESPONSABILIDAD SOCIAL (RS) Precio versión en papel: US$ 24. 18. Se puede lograr. Y porque el vínculo con nuestros seres queridos es lo único que realmente cuenta. Estamos vivos y lo más característico de la vida es la transformación. 380 Págs.. Chile $10. tenemos ejemplos de buenos diseños que han disminuido grandes males sociales en un 80%.3 cm. etc. de la disminución de la tasa de accidentabilidad de los trabajadores desde el 35% de los años 60 al actual 7%. 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. en Chile. . 1ª edición de 1998).) En los países de Latinoamérica podemos ganar miles de millones de dólares al año con la RS. EL ENCANTO DE LA COMUNICACIÓN Precio versión en papel: US$ 15. etc. corrupción. innovación.

000. Chile $16.. 164 Págs. 50 AÑOS Precio versión en papel: US$ 24. las empresas exitosas se distinguen por un pequeño número de prácticas que hacen muy bien. Chile $10. 25 x 25 cm. cuyos avances se pueden resumir en una sola palabra que bien conocen en el Instituto: prevención. También permite aprender. Además de hacer las cosas bien.. 21 x 14 cm.MODELANDO UNA SOLUCIÓN DE SOFTWARE 379 HISTORIA DEL IST. Así como existe la gestión por competencias dirigida a las personas. La historia del IST es a la vez parte de la historia de la seguridad del trabajo en Chile.) Este es un libro acerca de las empresas de éxito.000 (2005. al menos para encontrarle sentido a su quehacer y motivarse. En un contexto de buenas prácticas de gestión la tesis es que las empresas exitosas se distinguen por algunas pocas prácticas excepcionales. aquellas con una gestión que las lleva a diferenciarse. 150 Págs. porque de la lectura se podrá extraer una buena manera de gestionar una empresa. Ya sabemos que una historia puede inspirar a las personas para lograr fines superiores. Se presentan los ejemplos de IST. EMPRESAS DE ÉXITO Precio versión en papel: US$ 15.) Cumplir 50 años es un gran logro para toda organización y mucho más para una que se dedica a la seguridad social por el gran impacto que tiene en la comunidad. comenzando por una gran dosis de visión. . también existe una gestión por competencias corporativa. Es un avance de Responsabilidad Social que se puede proyectar a otros ámbitos para contribuir al Bien Común. (2007. ENAMI Ventanas. les hemos llamado “sistema de diferenciación”. Termosistema e Integramédica.

21 x 14 cm. dice Peter Drucker. Fue precursor del entrenamiento o capacitación y de la gestión por competencias. entre otras. Chile $16. trabajadores y la sociedad.000 (2005. 25.5 cm. La idea fue desafiante: compartir y aprender de la gestión realizada en una unidad de negocios de una importante organización. podrían generar grandes beneficios en la economía de Latinoamérica. Buscó evitar el derroche de materiales y se le reconoce como padre de la ingeniería industrial y de la ergonomía. entorno y personas TAYLOR REVISITADO Precio versión en papel: US$ 15. 224 Págs. 140 Págs. en el sentido de honor.. en su contribución al bienestar del país. . Se identificaron varios factores relevantes.380 JUAN BRAVO C. Taylor los países ricos le deban su condición de tales. así aprendemos de experiencias concretas.. GESTIÓN. A Frederick W. por ejemplo: liderazgo. Taylor sigue aportando a la creación de riqueza a través de la mayor productividad. Tiene una cultura distintiva que se aprecia en la ingeniería o innovación permanente. entre empresarios. Buscó que se compartieran los beneficios de la mayor productividad. Se trata de la Fundición y Refinería Ventanas de la Empresa Nacional de Minería. ¿Por qué es tan actual su mensaje? Porque su mensaje de fondo está orientado a la superación de la pobreza y porque sus propuestas. en la pasión por aprender. debidamente actualizadas.5 x 19. EL CASO ENAMI VENTANAS Precio versión en papel: US$ 24.) Es importante destacar lo positivo de la gestión de las empresas.000 (2005.) 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. ENAMI. Chile $10. productividad.

Chile $16.000 (1998.) Coautor: Giancarlo Gandolini Ambrosoli.5 x 18. inseparablemente unido a la historia de la familia Ambrosoli.MODELANDO UNA SOLUCIÓN DE SOFTWARE 381 A LA SALIDA DEL TÚNEL Precio versión en papel: US$ 15. necesitamos conocer la rica tradición acumulada en esta familia. 26. conducido por el dinámico y querido periodista Atilio Macchiavello. establecer un vínculo entre sus integrantes. estudiantes. porque excedió en mucho nuestras expectativas.. entender y difundir la cultura de una organización. DESDE LOS ALPES A LOS ANDES Precio versión en papel: US$ 24. Una inspiración para pequeños y grandes empresarios y orientación vivencial para nuestras autoridades. ¿Para qué sirve una historia? Para conocer. 231 Págs. 23 x 16 cm. preservar las tradiciones y seguir adelante unidos.000 (2000. propuestas y mensajes.. comunicar una causa común. Este libro es un reconocimiento a la labor de don Constantino Ambrosoli y a todos los emprendedores que ayudan a crear un mundo más humano. Fue un programa de UCV TV. Este documento recrea la vida de muchos visionarios y podría ser la salida de su propio túnel. AMBROSOLI. Chile $10.) Es un libro creado con las entrevistas realizadas a los participantes del programa de televisión del mismo nombre en donde se extrajeron sus mejores ideas. Es un ejemplo inspirador que queremos compartir.5 cm. 133 Págs. profesionales y público en general. Es un gran desarrollo. así que para entender la evolución de este negocio. Es un Texto obligado para profesores. .

26. la teoría de la catástrofe.5 x 18.5 cm. 240 Págs. ¡Hoy nos damos cuenta que el entorno varía con mucha rapidez! y que la velocidad del cambio sigue y sigue aumentando. Si pretendemos ignorarla. 415 Págs. como las aguas de un río que se pretenden frenar con un “prohibido el paso”.. . establecemos un sistema de diferenciación y un plan. PLANIFICACIÓN SISTÉMICA Precio versión en papel: US$ 24.000.5 cm.5 x 18. la complejidad y sus compensadores. Luego. Para adaptarnos a esta realidad. educación. creatividad y otras respuestas. Chile $16. 26. Chile $16. que considera el mundo estable y predecible. la humanidad. siguiendo un camino que comienza por determinar qué es lo que queremos. la complejidad se abrirá paso igual. lo evolutivo.382 JUAN BRAVO C.). en nuestra empresa o… en nuestra vida. hemos hecho planificación suponiendo que las condiciones ambientales se mantendrían más o menos constantes. (1998. el caos. La vieja cosmovisión mecanicista. creatividad y manejo de la incertidumbre del medio. dar órdenes o sólo poner reglas. etc.). abre paso a los sistemas: donde prevalecen las interacciones.000 (1997. ANÁLISIS DE SISTEMAS Precio versión en papel: US$ 24. Debemos descubrir los sistemas y aprender de ellos para ayudar en el desarrollo de las organizaciones.. La planificación sistémica nos ayuda a cumplir los sueños. Algunas herramientas sistémicas son: la teoría del caos. los círculos virtuosos. Tradicionalmente. la orientación al cliente. la planificación sistémica recurre a herramientas tales como: participación. ¿Cómo hacer análisis de sistemas? Con un enfoque al problema-solución que pasa por comprender la confusión. libertad. comunicación.

potenciar a las personas.5 x 18. REINGENIERÍA DE NEGOCIOS Precio versión en papel: US$ 24. remuneraciones o facturación.) (1ª edición de 1996) Sólo colección.. contabilidad.000 (1995. ¿Para qué hacer reingeniería? Para cumplir con la misión de la organización. una labor bella y eminentemente creativa que origina verdaderas “obras de arte”. Siempre conservando la creatividad. tales como inventarios. Este libro trata sobre el desarrollo de sistemas computacionales. ¿Cómo lograrlo? A través de efectuar grandes cambios en los procesos del negocio. . sirviendo los intereses de los clientes en armonía con los valores de la empresa y de la comunidad. Chile $16. las ventas o la producción. Chile $16. Esta propuesta de la ingeniería de software tiene su base en tres sólidos pilares: La planificación estratégica en informática.MODELANDO UNA SOLUCIÓN DE SOFTWARE 383 LA NUEVA VISIÓN.5 x 18. por ejemplo: aumentar la productividad de las personas.5 cm. DISEÑO Y CONSTRUCCIÓN DE SISTEMAS COMPUTACIONALES Precio versión en papel: US$ 24. definir una estructura organizacional flexible e incorporar tecnología. 26.) La finalidad de la reingeniería es lograr grandes desafíos.000. no en un 30%. el diseño orientado al objeto y las herramientas de productividad. tarea en la que deben estar empeñadas todas las personas que ahí laboran. 272 Págs. 300 Págs. Todo en sintonía con la cultura y estrategia de la organización.. a veces artesanales. sino en 400% y más.5 cm. 26. Se busca aumentar la productividad en ese ámbito. En especial se estudia el diseño de sistemas computacionales. ¿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. (contenido actualizado en libro Modelando una solución de software) (2ª edición 2007.

quienes podrán ver facilitado su aprendizaje al enfrentarse con metodologías y ejemplos concretos.. Se trata de lograr el desarrollo de software de calidad.000 (1996. 26. económico y en plazos convenidos. 250 Págs. comenzando por la planificación estratégica del negocio.2 cm. mediante la aplicación de pautas simples y lógicas. Chile $16. 3ª edición. Especial relevancia tienen la Ingeniería de Software y las herramientas de apoyo en cada etapa del desarrollo del sistema de información. DESARROLLO 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.). Está especialmente dirigido a todos quienes laboran en el área de informática. Sólo colección. MODELAMIENTO DE SISTEMAS DE INFORMACIÓN Precio versión en papel: US$ 24. . También se orienta a estudiantes de carreras del área computación e informática..5 x 18. 204 Págs. los lenguajes de cuarta generación y la orientación a objetos.) (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. y que podrían hacer uso de las materias prácticas. Da una visión de conjunto sobre el desarrollo de sistemas de información.5 cm. que buscan mejorar el rendimiento.384 JUAN BRAVO C. En las últimas décadas la “computación” ha sido un agente de cambio al interior de la organización. 24. En el texto se incorporan los conceptos de evaluación de proyectos informáticos. hoy las áreas de informática o de sistemas también deben cambiar. donde el criterio predomina sobre la reglamentación.4 x 18. sobre la base de una visión de conjunto del desarrollo de sistemas de información. El libro ha sido de gran ayuda para académicos de las áreas mencionadas.

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. España) e Ingeniero de Ejecución en Sistemas de Información (USM. Rolec. Modelando una Solución de Software 5. Gestión de Proyectos 4. Son los libros más relacionados con el hacer actual de consultoría: 1. el Dr. Centro de Estudios Avanzados y editor de la Revista Responsabilidad Social. Empresa Portuaria de Valparaíso. El Encanto de la Comunicación . Gestión de Procesos 3. Universidad Técnica Federico Santa María (Chile y Ecuador). Publicó los 18 libros indicados.MODELANDO UNA SOLUCIÓN DE SOFTWARE 385 ACERCA DEL AUTOR: Juan Bravo Carrasco Doctor por la Universidad de Lleida (España). Chile). Bravo ha ayudado a clientes tales como: Mutual de Seguridad. consultor y relator de seminarios. Municipalidad de Quillota. Banco Itaú. Transbank. Isapre Colmena. Bravo es profesor de programas de postgrado en la Pontificia Universidad Católica. Con más de 30 años de experiencia como ejecutivo. BancoEstado. Gestión Avanzada de Procesos 2. Master en Dirección de Informática (Ide Cesem. Es Presidente de Evolución. ENAMI. Universidad de Chile y otras destacadas instituciones. Constructora TECSA y Termosistema. Libros en digital y actualizados Estos seis textos están disponibles y actualizados en digital. El Dr.

. Planificación Sistémica (1997) 4. Diseño. Gestión. 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 indican: 1.A. 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. Análisis de Sistemas (1998) 5. Editorial Evolución S. Por ejemplo. desde Los Alpes a Los Andes (1998) 4. of 307. tercera edición. Modelamiento de sistemas de información (1994) 3. Libertador Bernardo O’Higgins Nº171. Santiago.cl. Reingeniería. Modelamiento. el caso Enami Ventanas (2005) 5.: Av. en la forma de nuevos textos que heredan contenidos reciclados posibles de rescatar de los antiguos. Instituto de Seguridad del Trabajo. 6. En este caso aplica el rediseño.cl. info@evolucion. el libro Modelando una Solución de Software heredó algunos contenidos de los textos Modelamiento y Diseño. A la Salida del Túnel (2000) 6. fono: 6389717 www. Otros seis (Desarrollo. IST y Empresas de éxito). Enami.evolucion. primera versión de 1987) 2. historia (2007) INFORMACIÓN GENERAL Cada texto puede ser adquirido en la forma de una versión corporativa en papel o digital. Responsabilidad Social Los siguientes doce libros no tienen actualización: Seis son históricos (A la salida del Túnel. Desarrollo de sistemas de información. Diseño de sistemas computacionales (1996) 3. Taylor Revisitado (2005) 7. Ambrosoli. Ambrosoli.386 JUAN BRAVO C. (1996. Taylor. Planificación y Análisis) perdieron tanta vigencia que no basta con la actualización para su permanencia.

Sign up to vote on this title
UsefulNot useful