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

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

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

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

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

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

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

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

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

• • • • • • • • Desarrollo de sistemas de información. donde convergen todas las otras ideas menores. 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. En su particular manera de escribir. nuevamente ha realizado otro gran esfuerzo. es decir. Con metodologías que aseguran un resultado predecible en las operaciones diarias de los diferentes procesos comerciales. Ratificando una vez más. ideas y conceptos actualizados al día de hoy. . a quien conozco por muchos años. autor de un gran número de libros del área de la Tecnología de la Información (TI) aplicada a los negocios. las cuales están insertas en organizaciones de diferente tamaño y sector. 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. 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. como afluentes a un río mayor. para entregar estos nuevos conocimientos. Christian Andrews3 Todo libro conlleva un gran esfuerzo del parte del autor. 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. Tienen en común estar a cargo de áreas de informática. Mi amigo Juan Bravo.16 JUAN BRAVO C. que el tener sistemas computacionales no constituye ninguna ventaja sobre la competencia. A. ¿Dónde radica la importancia de este libro para los profesionales de TI? A mi juicio. esta entrega orienta y prepara a las pequeñas y medianas empresas. en concebir los sistemas computacionales como un commodity. por la búsqueda de conceptos e ideas nuevas que se desarrollan y plasman alrededor de una idea “maestra”. 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.

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

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

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

Tengo la suerte de trabajar en una empresa constructora y sería un suicidio comenzar un proyecto sin tener los planos. no podemos comenzar a construir el sacro edificio si no tengo planos arquitectónicos hechos y bien hechos. no olvide que hay personas que van a vivir dentro de ese sistema y va a ser su casa en forma permanente. les tengo malas noticias. bueno. cuando programaba mi primer software. Juan dice en el prólogo de este libro que lo que buscamos finalmente es una mayor productividad de nuestras empresas. pero ese es el punto. . De pronto me siento repitiendo algo que escuché por primera vez en mis inicios. en informática los planos del sistema podemos dibujarlos con alguna nomenclatura estándar como UML o alguna propia. o sea que con los mismos recursos seamos capaces de entregar más productos o si lo profieren que con menos recursos podamos entregar los mismos productos. Un sistema informático bien hecho (partiendo de su modelación) debe bajar los costos del área en la 7 Gerente de Informática del Grupo Constructor Besalco. 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. 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. 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. 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. 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. no comience el desarrollo sin planos. acá es lo mismo. 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.20 JUAN BRAVO C. El pecado original en informática es comenzar a desarrollar sin tener los planos.

eso es todo. Bueno. no estamos hablando de modelar por modelar.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. . 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.

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

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

eficiencia y adaptabilidad al cambio. tal como si a un artista le encargaran una obra (requerimientos) y él. ¿Por qué modelar? Porque es necesario representar formalmente una realidad deseada. Modelar soluciones de software puede ser arte y tecnología a la vez. buscando simplicidad. en este caso una solución de software. que de otra forma resultaría muy difícil de transmitir. KENDALL y KENDALL (2005. modelar soluciones de software con técnicas normalizadas. Por esta razón. Problema Solución Implementación Necesidad Realidad deseada (difusa) Modelos de la solución . entonces la probabilidad de éxito es alta. más como un deseo difuso que como un requerimiento. ¿Será posible profesionalizar conservando la creatividad? ¡Sí! y de esta forma los métodos y herramientas van a recibir el aporte de muchas personas. 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. 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. 30) Modelar una solución de software es una labor bella y creativa. p. Eso es lo que quiere mostrar la siguiente figura. Lo más probable es que la realidad deseada se encuentre vagamente escrita y que principalmente esté en la mente de las personas. en el contexto de un proceso general de desarrollo que permita trazabilidad y productos repetibles. Este es el desafío.24 JUAN BRAVO C. La función del modelamiento es hacer tangible y aclarar esa realidad para que luego se pueda implementar. utilizando sus propios métodos y herramientas de trabajo. Si esa realidad deseada da respuesta a una necesidad por una parte y por otra los modelos de esa realidad son factibles de implementar. frecuentemente se obtienen muy buenos productos que son verdaderas “obras de arte”. diera vida a una creación única e irrepetible.

toda aplicación desde un costo de algunos miles de dólares ya hace necesario un modelar formalmente. 3. . podemos declarar que algo es una solución a un problema si satisface todos los requerimientos planteados en la especificación. La idea es superar la construcción artesanal de software (por ejemplo. puede contratar un experto y sólo darle instrucciones verbales. Entonces. en particular el modelamiento de funciones y el criterio curso normal de los eventos. si usted sólo quiere extender una pared interior de 2 metros. Las competencias son conocimientos. 226): “Se utiliza la especificación de requerimientos para definir el problema. 4. En muchos casos el número de soluciones es prácticamente ilimitado”. La profesionalización de conocimientos que aporta la ingeniería de software para comprender todos los aspectos técnicos de los modelos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 25 Shari Pfleeger explica en su libro Ingeniería de software (2002. ¿Siempre es necesario modelar la solución antes de implementar? Depende. p. En el software es igual. Contenido del libro Lo primero sucede en esta misma introducción. cañerías de agua. normalización (tal como orientación a objetos y UML) y construcción con herramientas CASE. Un método completo para la gestión de proyectos y así situar el modelamiento de soluciones de software en su contexto. 2. 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. cables de electricidad y todo lo demás). las normas y estándares que existen. Sin embargo. El indispensable modelamiento de datos. si quiere construir su casa necesitará de maquetas y muchos planos (obra gruesa. habilidades y actitudes necesarias para modelar aplicaciones computacionales (o soluciones de software). Los múltiples aportes de la nueva teoría de modelos. tal vez le resulte y ahorre tiempo y dinero. una selección de los modelos más relevantes de una solución de software. es posible que no requiera los modelos. en este texto se presentan en la forma de capítulos: 1. construir sin planos) y aplicar los nuevos conocimientos sobre teoría de modelos. 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). Los necesarios conocimientos de la orientación a objetos. 5.

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

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. 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 . retroalimentación y sistemas. Incluir como plan de acción de RS Mapa de proyectos 10p Tiempo Problemas detectados: 1. Alinear con la estrategia 2. Pago tardío a Proveedores 2. procesos. proyectos.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. Son los mapas de necesidades. Bienestar Productividad Calidad Costo Responsabilidad Social 2p Soluciones propuestas: 1.

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE 29 En este caso. estructura (organizacional y física) y tecnología (de todo tipo). incluye responsabilidad social) y las 4 patas son: personas (incluyendo ambiente). con cinco elementos que se representan con la metáfora de una mesa. En esta etapa todo el trabajo se centra en el modelo de negocios de la solución. procesos. 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. los modelos siguen la lógica del método GSP. Se emplean principalmente los modelos mapa de procesos y flujograma de información. En esencia: corresponde decidir Qué hacer. comenzando por la cubierta de la mesa (detalle de la figura en el capítulo 1). la cubierta es la estrategia (alineando la de la empresa y la de del proyecto. los cuales se observan en la siguiente figura (detalle en los capítulos 1 y 3 respectivamente). en la empresa corresponden a los contenidos del proceso de desarrollo de software que ésta se haya dado. GD: Guía de Despacho .

se puede emplear esta serie de modelos (una buena técnica es por borradores sucesivos. . 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). 2 y 3). en tal caso. comenzando por cualquiera de ellos). Lo cual está descrito en el capítulo 1. El objetivo es decidir qué incluye el modelo de negocios (detalle en los capítulos 1. Desde aquí surgirán definiciones para las otras patas de la mesa: personas. Para definir el alcance de la solución de software en la etapa de análisis. estructura y tecnología.30 JUAN BRAVO C. es necesario profundizar en los requerimientos principales de la solución de software.

Funciones relacionadas: Curso Normal de los eventos Acción del actor Respuesta del sistema 1. Ingresar Nº O/C en (A) 3. 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). Ingresar las unidades en (K) 10.. 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. Ingresar Rut en (D) 5.. Calcula el subtotal y despliega en (L) 10. Dar OK a la línea 11….. Excepciones: 1.* contiene * existe en 1 existe en * almacena 1 Bodega Productos contiene * existe en 1 Proveedores Caso de uso de expandido Encabezado de O/C Nº O/C Fecha compuesta por contiene existe en * 1 Proveedores Rut Nombre Líneas de la O/C Líneas de la O/C Unidades Precio contiene existe en * 1 Productos . producto en (H) obtiene y despliega la descripción y el precio en (I) y (J) 9. 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. Verifica existencia del producto. Ingresar el código de 8.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. Si el número de O/C ya existe. Tomar la O/C desde el archivador 2. existe en * almacena 1 Bodega . Proveedor Nº de O/C.. vea caso de uso “Corregir Correlativo”. Verifica que proveedor exista. obtiene y despliega nombre y fono en (E) y (F) 6…. Detalle de transacción C/E Mensajes 4 y 5 Productos L.. 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 . Verifica correlativo y envía respuesta en (B) 4.

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). • Se actualizó el contador de líneas en el encabezado.32 JUAN BRAVO C. clase Ingreso de transacción Atributos Funciones Indicar stock del producto Deben cuadrar totales. • Se actualizó la asociación entre encabezado y detalle de O/C. sin mayores problemas de volver a veces a la etapa de análisis. Poscondiciones: •Se creó una línea en el concepto detalle. Tipos de datos: afecta a los conceptos Encabezado de O/C y Detalle de O/C. stock mayor a unidades por vender. 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. 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. Repetir hasta que no haya más productos Ingresar cantidad Dar OK a la línea Diagrama de secuencia Contrato . Ambos deben existir. Salida: no hay Precondiciones: no existe la línea. Ingresar Nº de O/C Ingresar código de prod. Modelos de la etapa de diseño De la misma forma que la etapa de análisis. detalle y totales según Formato de pantalla adjunto Aceptar datos y actualizar línea a línea cada producto. detalle y totales según formato 1 Aceptar datos 2 Cuadrar totales C/E Ingreso de transacción Encabezado. Cuadrar totales para referencia. es decir. Enviar mensajes para verificar Existencia de personas y artículos. mediante borradores sucesivos y la técnica de desarrollo en espiral (ver anexo 3) se avanza en el diseño. 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. 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. Mensaje 5 Crear proveedor y artículo si no existen.

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

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

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

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

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

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

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

procedimientos y técnicas y herramientas propuestas”. 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. descripción técnica del sistema propuesto. La lista se extiende hasta los planes específicos para las prácticas transversales. dee recursos y muchos otros. nograma. de riesgos.40 JUAN BRAVO C. estándares del proyecto. En la figura 1-1 se presenta la totalidad del método GSP. Totalidad del método GSP . tales como plan de aseguramiento de calidad. organización del equipo de trabajo.

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

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

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

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. evitándose la práctica tan cara de repetir el levantamiento de un cierto ámbito en cada aplicación de software. al centro los del negocio y abajo los de apoyo. En este caso se muestra para la empresa comercial e industrial Linhogar (nombre ficticio por supuesto). Nótese en la figura 1-4 que la práctica es ubicar arriba los procesos estratégicos.44 JUAN BRAVO C. en proyectos de gestión de calidad o cualquier otro. c) Mapa de Procesos Quedan reflejados todos los procesos de la organización. ya sean estratégicos. . 12 Ver libro del mismo nombre. 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. 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. del negocio o de apoyo.

Conviene conocerlos ya sea porque son experiencias que es bueno replicar o porque hubo sucesos que queremos evitar. No sirve. Así se puede capitalizar la retroalimentación. Mapa de retroalimentación para replicar o evitar Es fundamental que el mapa este a la vista y siempre actualizado. 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. 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 45 d) Mapa de Retroalimentación Lleva registros de eventos enriquecedores al finalizar los proyectos. 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. . esa información debe estar viva. En la figura 1-5 se usó la forma de un mapa mental.

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

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

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

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

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

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

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

Por ejemplo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 53 3. También se le llama PMO (Project Management Office). quienes lo actualizarán y difundirán. Puede tener además la forma de una UTP (Unidad Técnica de Proyectos) que se asegure de la formalidad metodológica de cada proyecto. 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. 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. llevar al cuerpo. sumar a la estructura organizacional. a) Área de metodología o UTP En el área de metodología trabajan los responsables del método. 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. se incorpora aquí una labor más bien operativa. . es decir. Eventualmente las áreas de metodología y de UTP pueden ser áreas diferentes y que trabajan coordinadamente. “hacer carne”. 14 Es la primera clave de la implantación de método de la sección 1. Esto es lo que se denomina “incorporar” a la organización. es decir.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inmediato. para quienes debería ser autoexplicativo.68 JUAN BRAVO C. 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. el flujograma de información. Una de los macroprocesos. Despachar. y otro macro: A domicilio. 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. digamos desde el año 2000. 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). el cambio ha sido grande en esta materia). es conveniente una nueva inmersión. • Tiene temporalidad • Está orientado a seres humanos. Un ejemplo se muestra en la figura 1-11. 25 . • Las actividades con doble línea tienen alguna relación con TI y luego dan origen a los casos de uso. más tres macroprocesos: Comprar. se abre a su vez en dos procesos. Más detalle en el libro Gestión de Procesos. principalmente a los usuarios operativos. • No es un diagrama de flujo computacional. 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. Utilizaremos como ejemplo el proceso Despacho inmediato en el siguiente modelo. Se aprecia en la figura 1-10 que el macroproceso Comercializar incluye un proceso operativo: Proyectar ventas. ya indicados. Vender al detalle y Servicio postventa. uno operativo. • Debe caber en una página con letra de tamaño legible.

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. 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. CC: Comprobante del Crédito. OE: Orden de Entrega Figura 1-11. 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. .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. Se debe realizar el diseño de formularios asociados al detalle de los flujogramas de información.

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

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

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

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

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

• Contar con la dedicación completa del líder28 y de los demás integrantes del equipo de trabajo. Por ejemplo. cuidar el corto plazo (la solución preexistente) y el largo plazo (el nuevo proyecto) a la vez. mejor). • Aplicar la estrategia tenaza. Es preferible invertir en disponibilidad de personas que en mayor equipamiento técnico (si se puede ambas cosas a la vez. la dirección de la empresa y proveedores especializados de elementos de comunicación o infraestructura. El autor tuvo el privilegio de asesorar en una conocida empresa minera en un proyecto de renovación tecnológica. • Mostrar resultados pronto para mantener el nivel de entusiasmo —por ejemplo. entre otros actores. • Tener la flexibilidad para resolver con rapidez los inevitables problemas que se producirán. los usuarios. 27 28 El libro Análisis de Sistemas aborda el tema de la complejidad de los sistemas. 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). a través de los quick wins. especialmente en la atención a los usuarios (puede ser rotativa a diversas horas). Es crítico en la relación con el usuario mantener verdaderamente “puertas abiertas” y despejados todos los medios de comunicación. aquella difícil de predecir. el equipo de trabajo de tecnología. considerando un período de prueba integral con datos reales y en la práctica. Que esto no se confunda con improvisación ni que sea una excusa para una mala planificación. es ideal tener una persona o un equipo “de acción rápida” como forma de lidiar con la complejidad27. c) Instalar el piloto Una actividad vital de esta etapa es comenzar a operar la solución en carácter piloto. 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. el equipo asesor en metodología. .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. buenos resultados se han logrado con una reunión semanal breve con los consultores que apoyan el rediseño. es simplemente responder con variedad a la variedad natural del medio.

la etapa contempla instalar el sistema en alguna máquina específica y comenzar el uso real en una instalación piloto. Una recomendación es asegurarse que efectivamente se usa lo nuevo. 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). lo que llevaría a modificar el proyecto. Es importante la dedicación completa de estas personas al proyecto. quienes luego pueden hacer de instructores para los demás usuarios. Taylor) se refiere a la formación en los procesos específicos en que trabaja la persona. Es importante no confundir la instalación piloto con un prototipo. Desde el punto de vista de la TI. El prototipo es para que el usuario vea un boceto de lo que quiere o para probar aspectos específicos de la funcionalidad. El entrenamiento (el training de F. 6. entrenan29 y reubican si corresponde (la sensibilización ya debería estar lograda). 29 De acuerdo lo indicado en el libro Gestión de Procesos. 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. 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. W. • Comunicación del avance.76 JUAN BRAVO C. Y si lo nuevo no se usa. 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. tal vez sea por razones fundamentadas. Al mismo tiempo se avanza en: • Capacitación de usuarios piloto. . La capacitación se orienta al desarrollo de competencias generales. Esto implica que: • Los usuarios se capacitan.

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

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

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

Flujograma de información de control de cambios Detalle del procedimiento de control de cambios menores: 1. 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 . El jefe de informática la recibe y asigna a un analista 3. 2. Ya sea obtención de nuevos informes o consultas. es indispensable seguir el procedimiento general del área de sistemas en cuanto a requerimientos menores. Un ejemplo de procedimiento se presenta en la figura 1-13 y a continuación como texto.80 JUAN BRAVO C. Control de cambios Se trata de establecer un procedimiento de aceptación de requerimientos menores en el ámbito de la TI. Un usuario autorizado emite una solicitud de cambio menor. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

licencias. escritorios. baños. espacio físico. 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. más allá de sólo tener planes de contingencia. La idea de fondo es evitar la contingencia. 24. 22. . Incluso se sigue realizando mejora continua de la antigua solución. • Minimizar interrupciones a las operaciones del negocio y limitar la severidad de la interrupción. 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. Cuidar la solución anterior Cuidar la solución anterior significa que al mismo tiempo que se trabaja en la nueva solución. 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. redes. • Minimizar pérdidas financieras. al mismo tiempo que otro gerente se encarga del proyecto de cambio. La continuidad operacional está relacionada con la seguridad de las operaciones y la calidad de la información. Continuidad operacional Se refiere a incorporar en el proyecto los mecanismos que permitan la continuidad de las operaciones cuando el proyecto esté en funcionamiento. se aplica alguna forma de continuidad de lo existente.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. • 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. En algunas experiencias incluso se designa un gerente de continuidad. 23. prevenir. comedores y otros.

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

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

CAPÍTULO 2.98 JUAN BRAVO C. INGENIERÍA DE SOFTWARE .

Pressman El objetivo más importante de la ingeniería de software es lograr la producción profesional de software. ORIENTACIÓN A OBJETOS CAPÍTULO 4. ellos mismos no han aplicado estas técnicas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 99 Capítulo 2. 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. UML CAPÍTULO 5. muchos ingenieros de software han sido “los hijos del zapatero”. INGENIERÍA DE SOFTWARE CAPÍTULO 1. TEORÍA DE MODELOS CAPÍTULO 2. Roger S. donde se aumente la calidad y la productividad y se disminuyan los riesgos del proyecto mediante una excelente planificación y modelamiento. porque se profundiza en una especialización. Aunque estos profesionales han construido sistemas complejos que automatizan el trabajo de otros. CAPÍTULO 7. HERRAMIENTAS TI CAPÍTULO 6. el desarrollo 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. desarrollado con método. con documentación . técnicas y herramientas conocidas. 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”. Es una competencia de tipo vertical. 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. sino a la obtención de un producto creativo y personalizado. Durante los últimos 20 años. Esta es la segunda competencia considerada para apoyar la elaboración de modelos de una solución de software. No se refiere a la producción en serie. hacia productos de programación normalizados.

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

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

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

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

Sin embargo. mejora el funcionamiento de equipos de trabajo y se refuerza la motivación. La educación implica una mentalidad abierta. ella está indudablemente supeditada a los mayores intereses de la educación. se pueden extraer algunos temas de la clasificación de materias presentada en la figura 2-1. es indispensable hacerlo si queremos producir software efectivo y de calidad. Está relacionada con una sistematización del conocimiento. dar mejores respuestas a los desafíos del medio y atreverse a hacer cambios. Utilizamos la palabra educación porque ella es consecuencia del proceso de aprendizaje y reflejo de ser una persona culta. ¿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. uno de los cuales es la tecnología de información. se incrementa la capacidad individual. comenzando por los ejecutivos de mayor nivel. Una faceta de la educación es la capacitación. dice: “la calidad comienza con educación y termina con educación”. la cual es solamente un ejemplo del tipo de materias en cada categoría. un “aprender a pensar” y luego cambiar la forma de pensar. Otra faceta es el Training (traducido como entrenamiento) destinado a formar a las personas en los procesos específicos en que participa. 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. 3. Se refiere a una conducta “educada” y no a una acumulación de títulos. Siendo la actividad de capacitación de fundamental importancia en la empresa. debiera destinar una cantidad equivalente de horas a los temas de su entorno. el Dr.104 JUAN BRAVO C. Si un ejecutivo destina a su labor especializada varios miles de horas de perfeccionamiento. 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. Este es un principio sistémico. Adicionalmente. el equilibrio entre especialización y generalización. la cual se refiere a dominar una materia o a lograr una destreza específica. menos prejuicios. refiriéndose al control total de calidad. Para diseñar el programa de enseñanza. . Kaoru Ishikawa. Este tema es de tal trascendencia que. ganador del premio Deming a la 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. . con las materias propias del área informática. los ejecutivos y profesionales podrán apreciar su organización desde un punto de vista más amplio. Parte de este esfuerzo de educación es conocer en profundidad los alcances de la tecnología de información y sus implicancias.MODELANDO UNA SOLUCIÓN DE SOFTWARE 105 La empresa en la comunidad Planificación estratégica Adaptación al cambio Liderazgo. 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. 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. orientado a los eslabones más altos del manejo de información y la tecnología de información. De esta manera.

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

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

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

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

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

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

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

en la organización debieran existir funciones de manejo de la información. centralizada y como parte de cada área usuaria autónoma. entre otras. dando a cada área usuaria autonomía en el manejo informático. compatibles entre sí: Equilibrio entre centralización y descentralización Significa conservar un centro de información a nivel de la empresa. de personas. en el marco de las normas convenidas y administradas por el centro de información. Reconversión de programadores 3. La autonomía en esta materia tiene su base en los principios sistémicos de viabilidad y recursividad. . 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. Para que un área sea viable. dirección y tecnología.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. 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. Así como existe una fuerza aérea nacional y una rama aeronaval de la armada.

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

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

tuvo que hacer muchas contrataciones adicionales. se trabaja en las definiciones estratégicas del área informática: organización de la función informática. a poco andar. modelo de datos. empresa de 30 ex-empleados que. La planificación informática fija el marco para priorizar los proyectos informáticos y obtiene un plan que debe mantenerse actualizado. 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. 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. En la figura 2-3 vemos un esquema de planificación informática. plan de equipamiento. tipo de producto para . 4. 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.116 JUAN BRAVO C. definiciones estratégicas y plan de implementación Figura 2-3.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

donde hay otros factores que también inciden.000 en el caso de codificar y a US$ 600 en el caso de ampliar el hardware. considerando la mantención del código. El presupuesto es de US$ 400. Otros factores serían: ¿cuánto es el costo de oportunidad al retrasar la solución en un mes. si se cuantifican en dinero. El objetivo ha sido destacar que la simple renovación del hardware resuelve automáticamente un cierto rango de problemas. asciende a US$ 1. se ha valorado conservadoramente el costo de la mantenció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. ampliarían todavía más la brecha. Este ejercicio se puede extrapolar a problemas mayores en las instalaciones. Lo mismo es válido para variadas formas de externalización. en el caso de optimizar código? y ¿cuánto cuesta el tiempo del usuario. considerando que al optimizar código debe disponer de tiempo para interactuar con el especialista? Es importante destacar que en el caso de la optimización de código. 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. 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 cual puede elevarse varias veces cuando el programa no está bien documentado o los métodos de programación han sido anárquicos. Es claramente conveniente ampliar el hardware y esto sin considerar los otros factores de comparación que.MODELANDO UNA SOLUCIÓN DE SOFTWARE 137 • Contratar un programador para optimizar el código de los programas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

D.D.152 JUAN BRAVO C.F. hasta llegar al nivel elemental o atómico. las cuales proveen o reciben información del sistema. 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. 51 .F. El diagrama de contexto muestra la ubicación del sistema respecto al medio donde se encuentra. perdiéndose los supuestos beneficios del enfoque51.). Las entidades —también llamadas fuentes— son empresas. es de por sí casi una utopía. 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. 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. Esta herramienta se divide en dos partes: diagrama de contexto y D. Diccionario de Datos (D. En la figura 2-7 podemos apreciar un ejemplo: el diagrama de contexto de un sistema de control de stock. así como la orientación a objetos no obliga a emplear programación orientada al objeto. departamentos o personas relacionadas con el sistema. veremos cada una de ellas. y la mini especificación. 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. 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. Las principales herramientas del diseño estructurado son: Diagrama de Flujo de Datos (D. más el D. nivelado. 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.) y mini especificaciones en pseudolenguaje.D.

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

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

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

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

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

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).. 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. en algunos casos será necesario reconstruir periódicamente la base de datos. ¿Qué pasa si?. • Borrar los archivos temporales o tablas intermedias • Dosificar el procesamiento del sistema para evitar las fluctuaciones innecesarias en el uso de procesador. se saturen las líneas o una tabla se dañe. son parte del conjunto de normas del área de informática. Una causa de las serias dificultades en que caen algunos sistemas es porque no se hicieron estas preguntas a nivel del diseño. . cuando. significa preguntarse cómo apoyar la operación.158 JUAN BRAVO C. por ejemplo. • Organizar el uso de la impresora para economizar papel. se corte la luz. 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. • • • • procesos. Desde el punto de vista del método presentado en el capítulo 1. • Estudiar las secuencias de control para evitar duplicidades en procesos u ordenamientos. Reconstrucción de bases de datos: dependiendo del sistema operativo del computador. Este tipo de tareas no implica particularizar el diseño ni romper la uniformidad. más allá de los planes de contingencia. las que podrían disminuir el rendimiento. el concepto es la continuidad operacional. 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). Esto significa: • Estudiar el tamaño de bases de datos para dimensionar dispositivos. para equilibrar la carga del computador. es buscar permanentemente minimizar el uso de recursos.. Uso de recursos: una importante tarea que también podría estar parcialmente incorporada en el diseño. etc… • Evitar la impresión automática de informes. cumplir con entregas de tipo periódico y por seguridad. con el fin de reorganizar las claves y recuperar el espacio ocupado por registros eliminados.

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

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

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

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

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

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

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

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

2. los conjuntos de datos serían accesos a los diferentes objetos y las funciones generalizadas permitirían acceder a las consultas. • Diseñar la jerarquía de opciones: significa realizar el ordenamiento de opciones según la normalización. agruparlas de 3 en 3 y con una profundidad de no más de tres niveles en la jerarquía de opciones. • Ayudas en línea eficientes: de tal forma que. no sea necesaria la existencia de los manuales. Ambos juegos vienen incluidos en el sistema operativo Windows. informes y diferentes procesos del sistema. p. generalmente agrupados bajo una opción de menú. por ejemplo: incorporar primero las opciones de uso más frecuente ordenadas según la secuencia de ejecución de tareas. principiantes o expertos. ojalá. Estamos a fines de la primera década del 2000. un amigo —Rolf Achterberg. Una primera aproximación podría ser considerar cada menú como una clase que representa a todo el diseño. No le interesa entender el por qué del funcionamiento si no solamente cómo lo debe utilizar para sacarle provecho. baja o alta especialización. “La idea es simple” asegura Gerardo Cerda (2002. Sin embargo. • 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)”. En este caso. para aprender a tomar. Gerente de sistemas—. Si todavía hubiera usuarios con temor a usar el computador. en un ambiente donde la tecnología computacional está ya totalmente consolidada. les pide jugar al buscaminas para aprender a posicionar el mouse en un punto y luego al solitario.MODELANDO UNA SOLUCIÓN DE SOFTWARE 167 • Diseñar las interfaces según el tipo de usuario: empleados o ejecutivos. mover y soltar. 2): “El usuario quiere utilizar un software que sea lo más simple posible. ¿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. 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. 52 .

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

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

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

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

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

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

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

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

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

TEORÍA DE MODELOS CAPÍTULO 2. UML CAPÍTULO 5. o dicho de otra forma. Senn (1987. en particular el criterio del curso normal de los eventos. MODELAMIENTO DE DATOS CAPÍTULO 3. INGENIERÍA DE SOFTWARE CAPÍTULO 1. Esta es la tercera competencia considerada para apoyar la elaboración de modelos de una solución de software. p. no existen problemas de sistemas que no hayan sido primero del negocio. Teoría de modelos aplicada Sin importar el tipo de empresa. 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. son claves en esta misión. Sería un error distinguir entre problemas del negocio en sí y de sistemas.MODELANDO UNA SOLUCIÓN DE SOFTWARE 177 Capítulo 3. 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. En este caso. ORIENTACIÓN A OBJETOS CAPÍTULO 4. CAPÍTULO 7. 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. el analista trabaja en problemas comerciales. 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 . 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.

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

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

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

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

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

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

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

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

la intuición juega un rol preponderante. esas son solamente herramientas que aplican los especialistas. Intuición El modelamiento es una tarea eminentemente creativa. Lo explica bien Malcolm Gladwell en su documentado libro Inteligencia Intuitiva (2006. sino de procesos biológicos que recién se comienzan a estudiar científicamente. Es simple. Esto se puede interpretar como de acuerdo con el sentido común o percepción. Es una parte central de lo que significa ser humano. tal vez algo cambió en la realidad o existe un problema de enfoque que es mejor atender. 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. ¡hágale caso a su intuición! Probablemente descubrirá que su percepción era correcta. pero a usted algo le incomoda. ¿Qué es la intuición? Hay quienes dicen que es una de las voces de la conciencia. 2. No es quien aplica la técnica más moderna o usa los productos más sofisticados. el subconsciente es bastante más rápido que la reflexión por una cuestión de sobrevivencia. por lo tanto. de que algo sobra o algo falta en el modelo. aunque no sea más que durante uno o dos segundos. 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. puede darnos muchísima información”. Es esa sensación de incomodidad.186 JUAN BRAVO C. 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. . Lo que plantea Gladwell es que esos pocos datos relevantes son simples observaciones de la realidad detectadas con mayor rapidez. 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. Lo hacemos siempre que conocemos a una persona o tenemos que entender algo con rapidez o nos encontramos ante una situación nueva. No estamos hablando de algo místico. ¿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.

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

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

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

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

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

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

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

Con las aplicaciones . casi). definido siguiendo el orden natural de las cosas. ríos) y mucha negociación. 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. La idea es llevar el concepto de descomposición funcional desde el ámbito de un programa de computador hacia el de un sistema. 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. La atomicidad depende del nivel en el cual estamos hablando: en el análisis pueden ser procesos del negocio. en el diseño objetos y dentro de un objeto funciones que actúan sobre los datos. ¿Cómo se llega a determinar una función computacional atómica? Aplicando el concepto de descomposición funcional. el mismo que se usa en programación estructurada para identificar los módulos del programa y ahora orientado a partes de la aplicación. eso sería te a la descomposición funcional. En el caso A las fronteras están definidas considerando dominio cultural. historia. En el caso B. 0º 20º 40º Caso A: Separación natural Caso B: División artificial Figura 3-9. Concepto de descomposición funcional En la figura 3-9 queda de manifiesto que cada país es la “unidad atómica” del mapa.194 JUAN BRAVO C. separaciones naturales (cordilleras. bueno. 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.

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

agregar..Actualizar saldo de crédito disponible del cliente 3. o ambas.196 JUAN BRAVO C. En la figura 3-10 se puede apreciar una secuencia de procesamiento de varias funciones: 1. extracción o selección de información. sean alteradas. 3. 1 3 Ventas Actualizar stock Actualizar saldo de crédito del cliente Artículos Actualizar stock Mermas 2 Clientes Figura 3-10. aunque con la posibilidad de que el usuario la pueda alterar o “pintar” de acuerdo con su gusto. son los siguientes: • Ingreso: se realizan las operaciones de consultar. la presentación de la pantalla podría ser proporcionada por omisión. con la característica de que una de ellas. Ejemplo de relaciones funcionales Una relación funcional puede corresponder a cualquier función entre dos entidades. • Consulta: aquí se permite la consulta por la clave y por las relaciones propias. modificar y eliminar registros de una entidad. 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.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. Si se trabaja con alguna herramienta. Es el caso de la actualización...

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

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

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

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

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

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

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

En el capítulo 5 veremos que la orientación a objetos recoge la mayoría de los conceptos descritos en este punto.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). .

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

sensibilización y empoderamiento. lo cual se logra aplicando por un lado el criterio curso normal de los eventos y por otro a través de capacitación. Ejemplo de flujograma de información despacho inmediato .206 JUAN BRAVO C. 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. el flujograma de información deja espacios para que las personas apliquen criterio. Los símbolos de uso más habitual se describen en las siguientes páginas. 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. Veamos este FI retomando el ejemplo del mapa de procesos del capítulo 1. dejando de lado el absurdo intento de preparar flujos “a prueba de tontos”. Así. Lo nuevo es el principio SPPP (Simplificar Procesos y Potenciar Personas). entre otras acciones dirigidas a las personas. GD: Guía de Despacho Figura 3-15.

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

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

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

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

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

212 JUAN BRAVO C. Nota: una actividad computacional del FI se transforma en un Caso de Uso de alto nivel Figura 3-17. puesto en infinitivo porque refleja una acción. las cuales. 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. En el sistema se rebaja el saldo del producto. • El caso de uso de esta figura es del tipo “alto nivel” porque la descripción es general. 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. 2. Relación del FI con la técnica UML Específicamente en la figura 3-17: • El actor es el despachador. tomado desde el nombre de la columna del flujograma de información. . La actividad “Rebajar saldo” del flujograma de información (figura 3-15) se transforma en un caso de uso de alto nivel de UML. Son los casos de uso correspondientes a los procesos del negocio. darán origen a los casos de uso del sistema computacional. Específicamente ese punto de encuentro está en las actividades con alguna interacción computacional del flujograma de información. En la figura 3-17 se aprecia este punto de encuentro. • El caso de uso es “Rebajar saldo”. si están debidamente segmentadas según las propuestas del texto.

incluyendo los accesorios. tal como el lector de código de barras. Una recomendación metodológica es unir en un “Diagrama de casos de uso” (una forma de agrupación de casos de uso) los casos de uso de cada proceso operativo (o flujograma de información). .MODELANDO UNA SOLUCIÓN DE SOFTWARE 213 • La situación ocurre en el terminal de la bodega.

214 JUAN BRAVO C. MODELAMIENTO DE DATOS . CAPÍTULO 4.

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

000 700. con el fin de consultar y manipular información.101.143. proveedores.1.654-3 10. según sus requerimientos. se han conservado algunas denominaciones tradicionales. 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).201-4 7. por ejemplo: clientes. Por ejemplo: obtener una lista de los clientes que han adquirido el artículo 2051. Tipos de entidades 5.216 JUAN BRAVO C. RUT del cliente 4. Relaciones entre entidades 1. Disponiendo del modelo de datos completo será posible presentar visiones parciales a los usuarios. Componentes de una entidad Para efectos de facilitar la comprensión de las materias. DEFINICIONES SOBRE EL MODELO DE DATOS El modelo de datos consta de entidades y relaciones. 4.000 900. Características estáticas y funcionales de campos 4. registro y campo. facturas de venta.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. Representación de una entidad 2. Relaciones propias 3.000 Figura 4-1. Una entidad es un conjunto de datos coherentes que forman una unidad entre sí. Veremos: 1. En la figura 4-1 se puede apreciar que: . Una relación permite enlazar dos entidades para establecer recorridos que permitan efectuar la navegación automática. tales como entidad.749.

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

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

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

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

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

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

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

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

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

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

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

diversos informes y un formato predefinido para usar la tabla desde múltiples aplicaciones. 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. La tabla.234 JUAN BRAVO C. hacen muy fácil la mantención de los códigos de la instalación. más un programa simple de mantenció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.

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

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

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

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

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

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

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

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

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

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

más aun cuando el diseño queda registrado en alguna herramienta de apoyo para esta etapa. 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 . 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.

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. Reutilización. 5. El objetivo de esta evolución histórica ha sido el aumento de productividad. el principal método que dominó desde los años 60 es el diseño estructurado. . académico del Departamento de Ciencias de la Computación. sólo porque el tipo de datos cambia?”. La aparición de la orientación a objetos en los años 80 hereda esos avances previos. 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. manteniendo sólo un “diseño estructurado mejorado” para quienes conservaban esa tecnología en sus instalaciones o se incorporaban tardíamente. “nos comienza a proveer con algunas herramientas buscadas por largo tiempo: las bibliotecas de clases. En los años 60 surgió lo que conocemos como diseño físico o esquema tradicional de diseño. Escuela de Ingeniería de la Universidad de Chile. Señala que la programación orientada a objetos. no requiere de mayores comentarios mencionar que en la década de los noventa él promovió… la orientación a objetos. 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. principalmente vía SmallTalk. 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. ¿Cuántas veces uno implementa la misma función de búsqueda. Considerando que hemos reconocido a Edward Yourdon como uno de los padres de este esquema. José Piquer.246 JUAN BRAVO C. En un artículo en Revista Informática de principios de los 90. ya aconseja a los ingenieros en computación que comiencen a estudiar la orientación a objetos.1. 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.

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

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

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

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

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

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

Hacia fines de la primera década del 2000 más del 70% de aplicaciones la usa de una u otra forma. La orientación a objetos es una tecnología joven que comenzó a mediados de los 80 con un fenómeno muy curioso: nació en cientos de lugares a la vez: Japón. el OMG tiene por misión: • Maximizar la portabilidad y la reutilización del software. • Más del 75% de las empresas Fortune 100. pero sintomática respecto a los sentimientos que provoca. con términos y definiciones en los cuales basar todas las especificaciones. 66 Hacia fines de la década de los 80 el autor se encontraba trabajando en el modelamiento de datos y funciones. en comparación a un 3. la OMG encargó el desarrollo de un lenguaje de modelamiento basado en la orientación a objetos. . se estaba utilizando en el 11.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.UU. Europa. • Crear una arquitectura de referencia. la está usando o probando. En 1994. aunque con los mismos objetivos66. Sin duda una apreciación exagerada. Una vez que supo de la existencia de la tecnología de objetos. • Ofrecer un foro abierto para el análisis. la educación y la promoción de la tecnología de orientación a objetos. Chile y otros países. Tenía diferentes nombres y muchas variaciones. donde reunía en un solo todo la estructura y la funcionalidad asociada a una entidad. El método tradicional y las técnicas estructuradas habían sido sobrepasadas por la realidad y por el cambio en la computación. adaptó toda su investigación a ella. Unisys. USA.8% en 1991. En forma resumida.9% de los proyectos. 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. Integran este grupo las principales empresas de computación a nivel mundial: IBM. ¿Por qué se produjo este fenómeno? Porque era una necesidad de mercado. 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)—. • Estadísticas de 1993 indican que en EE. así surgió UML en 1997.

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

tal como lo propone Edward Yourdon. 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. El punto (•) señala que el campo es llave principal. El campo Rut es un número identificador de personas y empresas en Chile. Veremos: 1. Condición de existencia 1. En cierto contexto un objeto puede ser visto como una clase y en otro como un objeto. donde se aprecia que las clases y objetos se componen de atributos y funciones. Clase Personas • Rut Nombre Dirección Ingresar Eliminar Imprimir Objetos Avales Objeto Ventas • Nº documento Rut Ingresar eliminar Instancias de clientes: Juan Pérez. Son conceptos recursivos y que dependen del contexto. por lo tanto. Convenciones de diseño 3. Definiciones preliminares El juego de denominaciones tiene como base la figura 5-6. 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. Veremos que en los diagramas finales de diseño hay solamente clases.MODELANDO UNA SOLUCIÓN DE SOFTWARE 255 5. Alberto Torres Clientes C/E Figura 5-6. 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. .2. Definiciones preliminares 2.

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

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

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

Esto significa que si el objeto de detalle no tiene los datos requeridos para estructurar un mensaje y sí están en el encabezado. • Asimismo con las funciones. • El primer atributo de un detalle es la misma clave de la entidad encabezado. 4. la cual permite asegurarse de que uno o más atributos referenciales de un objeto . generalmente la información del padre se presenta en forma lineal y la del hijo en forma tabular. así es que no sería necesario anotarla en el objeto de detalle. Esta distinción es vital. pues todo lo necesario está contenido en los objetos y en su estructura. cualquier función del detalle puede ser activada desde el encabezado y viceversa. porque a nivel de la implementación significa que no es necesario construir ningún tipo de índice intermedio. es conveniente que un mismo diseñador sea dueño de todos los objetos sujetos a relaciones de pertenencia.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. 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. • Para efectos de implementación. Condición de existencia La condición de existencia (C/E) es una relación funcional entre objetos. se toman automáticamente y viceversa.

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

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

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

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

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

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

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

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

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

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

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

justo cuando tenemos listo nuestro modelo. nos damos cuenta que no consideramos las bonificaciones.MODELANDO UNA SOLUCIÓN DE SOFTWARE 271 Sin embargo. como en el caso de las otras transacciones. pues. Transacciones de sueldos • Nº documento Rut Monto Ingresar datos Obtener informe C/E Mensaje 18/19 Empleados • Rut Monto Total haber Total descuento 18. Sumar 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. Los mensajes —también llamados solicitudes— pertenecen a cada relación particular entre objetos. 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. señala qué atributos o funciones se agregan a cada objeto y lo particularizan. . así es que usamos una tabla de objetos asociada a cada clase. la bonificación se suma al total haber del objeto personal y es necesario activar la función 18 de personal. de la misma forma en que opera el proceso cognitivo del ser humano en relación a las abstracciones. Sin embargo. así es que se indicaron explícitamente en la tabla de objetos. en lugar de la 19. el modelo final corregido quedaría solamente con las clases y 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. En esta secuencia apreciamos la definición. Por lo tanto. tal como se muestra en la figura 5-12. como es también una transacción de sueldos. la hacemos nacer con los elementos de la clase. aplicación y perfeccionamiento continuo de una clase. Sumar haber 19. No hay problema.

pero eso es otro tema. las funciones también pueden ser clases. Si fuera necesario definir un nuevo objeto.272 JUAN BRAVO C. estatura o ancho de los dedos— aunque incorporando nuestra particular forma de ser obtenida de la experiencia y la reflexión. 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. 2. los objetos heredan sin discusión los elementos de la clase y pueden agregar otros atributos y funciones. pagarés. En la herencia. El concepto de herencia entrega una forma muy clara de apoyar el diseño de aplicaciones administrativas. puede tener particularidades tales como el atributo descuento y la función emitir factura. éste nacería con los datos y funciones de la clase ventas. heredar significa recibir nuestras características a través de los genes y así partimos con lo que nuestros padres nos transmitieron71. En la figura 5-13 se aprecia el nacimiento y aplicación de la clase ventas. Ejemplo de herencia en un sistema de ventas En otro nivel de abstracción. la cual fue definida a partir de los elementos comunes de los objetos ventas contado y ventas crédito. . por ejemplo. el documento de crédito en la figura 5-13 podría ser “genérico” y representar todos los casos del mismo tipo: letras. por ejemplo “ventas por mayor”. además. 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. particularmente en la definición de transacciones. Herencia múltiple 71 Y lo que no nos transmitieron por “error” genético y que la naturaleza inventó. sin posibilidad de modificarlo —color de ojos. o cheques a fecha.

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

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

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

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

¿Por qué darle tratamiento de una clase al ingreso de datos? Porque refleja de mejor manera la realidad.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. En ambos casos. e implícitamente cuando los datos quedan en la memoria del equipo o de la pantalla. Desde el punto de vista de implementación. En la práctica. Visión de conjunto del modelo El modelo funcional generalizado lleva un mayor nivel de detalle. Explícitamente cuando en el procesamiento batch-interactivo los datos se guardan en una tabla de transacciones del día. como un mapa. así se puede lograr la necesaria visión global que tanto ayuda en el perfeccionamiento de la aplicación. es un modelo que representa toda la aplicación. . siempre el ingreso de datos pasa a través de un almacenamiento transitorio. existe almacenamiento intermedio y mucha funcionalidad. como en el caso de la figura 5-18. el ingreso de diferentes tipos de transacciones es bastante similar. eso justifica darle al ingreso de datos el tratamiento de una clase a nivel del diseño. 72 Incluir todos los datos en la pantalla simulando el documento original equivale a un proceso de desnormalización del modelo de datos.

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. respectivamente. . esto por la característica de funcionalidad intercambiable indicada al comienzo del capítulo. • Los mensajes 4 y 5 sobre inventarios se refieren a sumar o restar el saldo del artículo. Un mensaje implícito es que cada una de estas funciones generalizadas es también una clase en otro nivel de abstracción. • 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. el mensaje 1 —que tiene por misión solicitar agregar un nuevo documento a la clase transacciones— se envió sólo al encabezado.278 JUAN BRAVO C. con lo cual también se agregará automáticamente en el detalle (a través de un mensaje que enviará el encabezado al detalle). 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. Por ejemplo. 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.

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

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

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

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

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

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

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

286 JUAN BRAVO C. la simplicidad final del concepto. la identidad personal y el proceso de generalización. la comunicación de mensajes. . Siempre en la línea de entregar en estas páginas un mínimo indispensable. el enfoque sistémico. transformar las clases en entidades concretas o tomar los atributos desde un diccionario completo de los datos de la organización. por ejemplo. ¿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. 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. como la personalización de objetos.

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

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

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

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

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

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

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

en este caso aplica la forma <<extend>> sobre una línea punteada que apunta hacia el caso de uso original. Por ejemplo. 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. “Comprobar reserva” como otro caso de uso referenciado por los dos anteriores. • Separación del comportamiento variable. 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”. pueden ocurrir varias cosas diferentes dependiendo de las circunstancias. se puede decidir que sería más claro mostrarlos como un caso principal y uno o más casos . en este caso se usa la forma <<include>> sobre una línea punteada que apunta hacia el caso de uso común.294 JUAN BRAVO C. Explican Stevens y Pooley (2002. p. Entonces deciden incorporar esa necesidad común. 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. Señalan Stevens y Pooley (2002. 124): “Si un caso de uso incorpora dos o más escenarios con diferencias significativas. 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. p.

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

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

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.

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

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

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

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

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

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

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

Las nuevas herramientas . La cuarta generación de lenguajes 5.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. Lenguajes de máquina 2. Lenguajes de alto nivel 4. Clasificación de lenguajes de computador Veremos: 1. Lenguajes simbólicos 3.

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

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

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

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

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

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

¿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. Por ejemplo. ordenar una tabla. para satisfacer esos requerimientos. 7. Herramientas integradas para automatización de oficinas 2.2. comunicar información. 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. producto de las mayores potencialidades de las herramientas. Groupware 3. Hace algunos años. 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. imprimir etiquetas o manejar eficientemente una base de datos simple. 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. con un simple procesador de palabras puede ordenar textos. realizar seguimiento del proyecto.318 JUAN BRAVO C. • En segundo lugar. efectuar cálculos. modelar los datos y comunicar el modelo a una base de datos. lo cual se puede estimar al menos en un 70%. hoy. Workflow . por ejemplo: “pintar” una pantalla. Veremos: 1. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Como decía El Quijote: “estar prevenidos es estar armados”. El diseño de sistemas de información gerenciales tiene relación directa con una antigua habilidad: la anticipación. tendencia a la participación de todos los interesados. . algunos grupos autodirigidos definen y mantienen sus propios sistemas de información. De hecho.340 JUAN BRAVO C.

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

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

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

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

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. porque pasa por todas las etapas. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 345 En el desarrollo en espiral cada vuelta o ciclo es un pequeño “desarrollo en cascada”.

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

p. 22.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 cheques deducidos de cuentas corrientes equivocadas por hora. 500 operaciones quirúrgicas incorrectas por semana. donde la columna más a la derecha tiene el acumulado de las causas anteriores más la nueva. esquema central en la técnica Six Sigma.000 veces por año”. A propósito de Six Sigma. . Dell y Anderson dicen (1999. los pocos críticos. Ejemplo de gráfico de Ishikawa Se priorizan y grafican de mayor a menor impacto según el porcentaje asignado. Esta forma de trabajo es recursiva. 50 bebés recién nacidos se les caen a los médicos por día. 6): “En Estados Unidos el 0. puede ser necesario que una causa tenga su propio análisis causal y así sucesivamente.000 prescripciones de medicamentos incorrectas por año. El gráfico tiene la siguiente forma. 20. X1 = F(x1). 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. 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. su corazón no late 32.000 piezas de correo perdidas por hora. los autores Wilson. en su libro Análisis de la causa raíz. Es decir.1% de fallas significa: 16.

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

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

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

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

análisis y sistemas de Juan Bravo C. 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. 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 . entre otros. a: Gestión de Procesos (2005) y gestión de proyectos de procesos y tecnología (2006). la cual se extiende hasta la documentación de los contratos de las operaciones del sistema inclusive. esta presentación se basa en la serie de libros de gestión.1998 (Prentice Hall) ISBN 0-13-748880-7 Bibliografía: Adicionalmente. .352 JUAN BRAVO C.

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

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

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

El sistema calcula el valor de la línea ingresada y lo acumula.14.7.7. 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. Ver también: (Craig Larman. 8.13.5. 14.12. I.3. R1. Tipo: Referencias cruzadas: Funciones: R1. a la vez que graba la línea recién completada. Opcionalmente vuelve a oprimir (Tab) para ingresar otra recepción. Primario y real. Encargado de Recepción (Actor Primario). El sistema despliega la interfaz de Creación de Guía de Recepción. R1. 9. Comuna. El Encargado de Recepción ingresa en M. 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. . 2. Al terminar de ingresar los Productos. 15. 5. R1. Respuestas del Sistema 3. asigna y despliega automáticamente en A el Nº de Guía de Recepción correlativo correspondiente y en B la fecha del sistema. El sistema verifica la validez / existencia del Nº de la Orden de Compra. El Encargado de Recepción verifica los datos del Producto e ingresa el costo unitario(Precio) y la cantidad recibida en R y S. 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.10. N y O respectivamente el Nº de Guía de Despacho del Proveedor. “Limpia” la interfaz de entrada y posiciona el cursor en A. El Encargado de Recepción ingresa en E el RUT del Proveedor y verifica los datos del mismo desplegados por el sistema. Teléfono. (Petición). El sistema calcula los valores subtotales / total y los despliega / redespliega en los campos T y U. R1.6. 7. (Notificación de cumplimiento del compromiso). 16. pág. 13. 12. la Fecha de la Guía de Despacho y el Nº de la Orden de Compra. obtiene y despliega la descripción del Producto en Q. Dirección. quien envía a sus respectivos destinos las restantes copias también firmadas (según Flujograma de Información correspondiente). e-Mail.356 JUAN BRAVO C. pág. 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. desplegando los valores en T y U. al terminar confirma la Transacción. en el cual ingresa el Código del Producto en P. la Transacción requerida la documenta con una Guía de Despacho o Factura.1.2. G. El Encargado de Recepción pasa a la sección de detalle. 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. Luego oprime (Tab) para grabar la línea actual y crear una nueva línea o terminar el ingreso de datos. R1. H.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.pueden contener cientos de frases .3. (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). R1. 6. R1. el Encargado de Recepción oprime el botón V para indicar al sistema el fin de la captura de datos. 11.9. 4. con lo cual el sistema pasa a 3. Calcula el costo promedio y lo actualiza Genera un original y 2 copias de la transacción realizada utilizando la interfaz de salida indicada. 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. R1.2. 26) “Los Casos de Uso Expandidos son extensas narrativas de descripción de un proceso . El sistema despliega los datos básicos del Proveedor (Razón Social.“. 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. El sistema obtiene y despliega el nombre del Encargado de Recepción en D. R1. además actualiza los datos de la transacción en el sistema de almacenamiento persistente. 6. El Caso de Uso termina cuando el Proveedor se retira. Ciudad.4. J. 50). R1. R1. 10. Capturar Datos de Recepción de Productos Comprados. R1. Fax) en F. 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 R1.2. R1. El Encargado de Recepción acuerda realizar la Transacción. 2. El sistema despliega el Nº de Línea en LL. K y L respectivamente.

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.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). rechazar. 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: . 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. 2) Campo M : Nº de Guía ya existe para el RUT del Proveedor. Comunicarse con Administrador. 4) Campo C : Encargado de Recepción no registrado (Código no existe). 3) Campo E : RUT de Proveedor no registrado (RUT no existe). Indicar error. Comunicarse con Administrador.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. Comunicarse con Departamento de Compras. 5) Campo O : Nº de Orden de Compra no existe. L. . Comunicarse con Administrador. Proveedor Nº de O/C.

999 Cantidad 9999 Valor Neto 999999.3 y 9. Terminal. Ordenes de Compra. En un análisis y desarrollo posteriores se podrían incluir conceptos tales como Bodega. .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.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.999. no necesariamente se encuentra el concepto de Orden de Compra.págs.. no se trata de un modelo de software.99 Firma Autorizada y Timbre Total Neto 99999999. Nota: Dentro de los requerimientos.6.“La Nueva Visión. se podrían excluir : Empleados. Empresa..1 a 9. asociaciones y atributos del mundo real. (Puede ser un ingreso manual).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. etc.999 . Interfaz de Salida Guía de Recepción Nª RUT Proveedor 999.99 L. 999.” pág 200) * Productos Código Descripción Costo 1 Ordenes de Compra Nº OC Fecha 1 Nota: Según Craig Larman (9. (Base Juan Bravo C. además de 9.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. 87 a 91 -.96 y 97) Se trata de conceptos. Por lo contrario.3 .págs.4 . 99 Código XXXXXXX Descripción XXXXXXXXXXXX Precio 9999.6.999 Fecha G/D Proveedor Nº de O/C.X XXXXXXX XXXXXXX e-Mail XXXXXXX XXXXXXX XXXXXXX 999.

264) Salvo casos específicos. Ingresar Código del Empleado y obtener / verificar el nombre del mismo. (Puede ser un ingreso manual). de Compra total() Nota: A diferencia del Modelo Conceptual.observando la interfaz de entrada -. se “descubrió” . Muchas clases. 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. Recepción Fecha Guía Proveedor Nº de Ord.se consideran implícitos - * Productos Código Descipción Costo costoProm() 1 Ordenes de Compra Nº OC Fecha 1 Nota: Dentro de los requerimientos. (A su vez se eliminó : Nombre) * * Proveedores 1 RUT Nombre Dirección validarRut() Empleados Código Nombre * 1 1 1. 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ú .8.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. Ingresar datos de G/D Proveedor ( Nº Guía. la conveniencia de agregar otros atributos al encabezado. 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. modificar(). que muestra atributos “útiles” para entender los conceptos del contexto.3. pág. no necesariamente se encuentra el concepto de Orden de Compra.257): “ Si bien la presentación de los diagramas de clases es posterior a la creación de los diagramas de interacción. Ingresar RUT del Proveedor y obtener / verificar los datos del mismo.8 . es conveniente omitir los métodos : crear().. Fecha.5 Detalle de Guía Interna de Recepción por Compra Descripción Costo Cantidad subtotal() Nota: Según Craig Larman (21. eliminar() y consultar() en los diagramas de clases dado que no agregan valor y aumentan el “ruido” .págs.8.4 a 21.262 . 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. en la práctica usualmente se crean en paralelo. verificar correlativo y fecha.

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

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

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

b*:[i:=1.b*:[i:=1. Fachada..2.6 ][notAct] calcularCPP(CodigoProducto.a*:[i:=1...1. Observador -.. Precio) 2. (Tema no abordado aquí)..1... t1:Terminal 3:NumGuiaRecCom := siguiente():NumGuia :EncGuiaRecCompra 4:FechaR := ahora():Fecha Fecha crearEncabezado(NumGuiaRecCom. Cantidad) 2.. Cantidad..6 ][notAct] calcularCPP(CodigoProducto.1 :[NuevaGuiaRecepcion] crearDetRecCompra(NumGuiaRecCom) l1:DetGuiaRecCompra .. por ejemplo.6 ][notAct] notAct := notAct(notAct := false) 2. 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”.. Por cierto que esto implica una interacción entre la capa de dominio y la capa de presentación. Indirección. Cantidad. Cantidad..6 ][notAct] sumarExistencia(CodigoProducto. Cantidad) sumarRecibido(CodigoProducto.c*:[i:=1..b*:[i:=1. calcularTotales() Nota:terminarTransacción() es realmente un mensaje “compuesto” .2.. Precio) 2... que se desdobla en : calcularTotales() y los mensajes que interactúan con las capas de almacenamiento persistente y presentación..6] /ValorLínea := calcularValor() sumarExistencia(CodigoProducto.6 ][notAct] sumarRecibido(CodigoProducto..entre otros. por ejemplo. Cantidad) calcularCPP(CodigoProducto. sumarExistencia() se realiza en la capa de dominio...c*:[i:=1. Para implementar el mensaje “compuesto” terminarTransacción() ” (completo)..6 ][notAct] sumarRecibido(CodigoProducto. Esto es.c*:[i:=1.1. Cantidad) 2.6 ][notAct] sumarExistencia(CodigoProducto. Cantidad) 2. Precio) ll:DetGuiaRecCompra t1:Terminal r1:EncGuiaRecCompra 2. FechaR) 5 :[NuevaGuiaRecepcion] crearEncabezado(NumGuiaRecCom.6 ][notAct] calcularCPP(CodigoProducto. Cantidad) 2. sin embargo se registra en la capa de almacenamiento persistente (Tema no considerado aquí) t1:Terminal 1: /ValorTotal := calcularTotales() r1:EncGuiaRecCompra 1.2.6 ][notAct] sumarRecibido(CodigoProducto.6 ][notAct] sumarExistencia(CodigoProducto.1*:[i:=1.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) 2. Cantidad) 2. Cantidad.a*:[i:=1. se usarían los patrones aplicables .3*:[i:=1..a*:[i:=1.

msg2.se consideran implícitos - Nota: Al crear la línea de detalle. calcularValor() 7. (ingreso manual).8. Aceptar datos. notAct se incializa a: true . consultarDatos() Terminal Encabezado. 4. notAct() C/E. modificar()..8. 4.Medida Costo Unitario Existencia Inicial Existencia Recibido Despachado 4. eliminar() y consultar() en los diagramas de clases dado que no agregan valor y aumentan el “ruido” .. consultarDatos() 6. siguiente() C/E y msg4 Nota: Agregado para clarificar el contexto. msg10 C/E y msg4 msg3..4 a 21. cerrarTransacción() 8.370 JUAN BRAVO C. anularLínea() 9. sumarExistencia() 7. msg1. sumarDespachado() 10. msg6. 4. (ingreso manual).264) “Salvo casos especificos. Desplegar interfaz(Correlativo. aceptardatos() 6. es conveniente omitir los métodos : crear(). crearEncabezado() 2. msg1. Calcular totales cumulativos 6. msg2. en principio es una Lista de Valores Posibles. 1 Productos •Código Producto Descripción U.. detalle y totales según formato de pantalla adjunto. msg4. anularTransacción() 9. consultarDatos() Empleados •Código Empleado Nombre .262 . consultarDatos() Nota: Al crear la línea de detalle. 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. Guía de Despacho de Proveedor • Nº Guía de Proveedor RUT Proveedor Fecha Guía etc. 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. (ingreso manual). cerrarLínea() 8. msg6.. 2. crearLínea() 2. msg8 y msg11 Productos •Código Producto Descripción U. aceptarCodigo() 3. 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. existenciaNegativa() 11. Enviar mensajes de consulta de datos 5. restarExistencia() 8.* 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. 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. 3. copiarTransacción() 10.. 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.Medida Costo Unitario Existencia Inicial Existencia Recibido Despachado sumarExistencia() restarExistencia() sumarRecibido() sumarDespachado() existenciaNegativa() calcularCPP() 1 * Nota: Agregado para clarificar el contexto. Enviar mensajes de C/E a registros. siguiente() 11.pgs. calcularTotales() 7. calcularCPP() Guía de Despacho de Proveedor • Nº Guía de Proveedor RUT Proveedor Fecha Guía etc.8 .. aceptarDatos() 6. copiarLínea() 10. Ordenes de Compra 1 • Nº Orden de Compra Datos Nota: Según Craig Larman (21. sumarRecibido() 9. consultarDatos() C/E y msg4 Ordenes de Compra • Nº Orden de Compra Datos 4. 1. 1. Fecha). C/E.

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

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

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

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

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

por su condición de seres humanos.376 JUAN BRAVO C.5 x 17. comunicación y rentabilidad. GESTIÓN DE PROCESOS GESTIÓN DE PROCESOS Precio versión en papel: US$ 24. .000 (2006. 400 Págs.2 cm. competitividad. Más difícil es cambiar nosotros mismos o que cambie nuestra organización. a las cuales podríamos llamar… procesos. productividad. La gestión de procesos nos insta a detenernos. o la forma cómo hacemos las cosas. Chile $16. ¿cómo?. al mismo tiempo deberían inventar los nuevos empleos de las personas que serán liberadas de funciones obsoletas. 24. ¿para qué?.) (1ª edición de 2005) Es fácil aceptar la necesidad de cambio en nuestro mundo.. Lo deben hacer. Porque. reflexionar acerca de lo que hacemos y preguntarnos: ¿por qué?. Lo pueden hacer. 2ª edición. porque son capaces. si profesionales capaces tienen ideas brillantes que permitirán ganar o ahorrar mucho dinero. como la calidad. La gestión de procesos es un medio para lograr grandes metas organizacionales.

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

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

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

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

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

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

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

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

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

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