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

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

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

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

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

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

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

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

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

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

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

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

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

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

si lo entienden se darán cuenta del poder que hay en la informática. estamos hablando de hacer un buen proyecto informático que genere utilidades a la empresa. . no estamos hablando de modelar por modelar. Bueno. eso es todo.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.

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

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

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

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

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

Son los mapas de necesidades. Incluir como plan de acción de RS Mapa de proyectos 10p Tiempo Problemas detectados: 1. Bienestar Productividad Calidad Costo Responsabilidad Social 2p Soluciones propuestas: 1. Pago tardío a Proveedores 2. proyectos. procesos. 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 .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. retroalimentación y sistemas. Trabajadores fuman en sector atención clientes 1p = Libera = Neutro = Requiere 7p Mapa de necesidades Procesos Estratégicos Gestión de Personas Gestión de Procesos Gestión de Proyectos Gestión de Calidad Control de Gestión Gestión de Contratos Analizar cargos Reclutar Inducir Mapa de procesos Desarrollo Planificación Estratégica RS Evaluar Formar Diseñar carrera Proceso del Negocio Comercializar Proyectar ventas Conocer la demanda Visitar Clientes Estadísticas internas Emitir O/C Almacenar Traspasar Comprar Recibir Distribuir Planear cada local Emitir traspaso Ordenar Preparar cada local Presentar Coordinar merchand. Alinear con la estrategia 2.

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

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

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

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. obtiene y despliega nombre y fono en (E) y (F) 6…. Detalle de transacción C/E Mensajes 4 y 5 Productos L. Ingresar Nº O/C en (A) 3... Ingresar las unidades en (K) 10. Si el número de O/C ya existe. Recepción RUT Proveedor Dirección Proveedor Comuna C - Encargado Recepción Razón Social Proveedor D F Nº Guía Recepción Fecha Recepción e-Mail A B 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. existe en * almacena 1 Bodega . Excepciones: 1. Tomar la O/C desde el archivador 2. Verifica existencia del producto. Para cada línea: Para cada línea: 7.. producto en (H) obtiene y despliega la descripción y el precio en (I) y (J) 9. Verifica correlativo y envía respuesta en (B) 4. 2… Incluye interfaces detalladas de E/S Caso de uso de alto nivel Encabezado de O/C compuesta por se asocia a 1 1. Ingresar Rut en (D) 5. Calcula el subtotal y despliega en (L) 10. Ingresar el código de 8. Funciones relacionadas: Curso Normal de los eventos Acción del actor Respuesta del sistema 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 . 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).. Proveedor Nº de O/C. Modelo conceptual de datos Modelo conceptual con atributos Interfaz de Entrada Guía Interna de Recepción por Compra Código Enc.* 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 . Dar OK a la línea 11…. Verifica que proveedor exista. vea caso de uso “Corregir Correlativo”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

aseguramiento de la calidad y control de calidad. 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”. Comportamiento ético Respecto a la ética de los profesionales. Algu- . ambos considerados dentro de trabajar metodológicamente. Ética y visión global del profesional Un aspecto central de la totalidad que representa la GSP es la integridad del profesional. planificadas y sistemáticas. contempla: planificación de la calidad. • El Aseguramiento de la calidad incluye todas las actividades. requeridas para brindar confianza en que el proyecto va a satisfacer los estándares de calidad relevantes. • 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. Sin embargo.56 JUAN BRAVO C. 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. 5. No basta con decir que usted debe poseer estándares normales de honestidad e integridad. pp. existen áreas donde los estándares de comportamiento aceptable no están acotados por las leyes. sino por las más tenue noción de responsabilidad profesional. • La Planificación de la calidad identifica qué estándares de calidad son relevantes para el proyecto y luego determinar como satisfacerlos. Ian Sommerville señala (2005. Gestión de calidad en proyectos Es un tema fundamental abordado por todos los métodos existentes. 12-13): “Deben comportarse de una forma ética y moral responsable si es que desean ser respetados como profesionales. por ejemplo. especialmente en dos aspectos: comportamiento ético y visión global. 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 para qué Por otra parte. todas las decisiones que se tomen respecto al proyecto irán en el mismo sentido con más probabilidad de lograr ese final deseado”. 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. p. 33): “Al tener una idea clara del final deseado. En tal caso puede ocurrir que no existan otros profesionales para desarrollar la estrategia y los demás elementos del modelo de negocios: personas. no falsificar su nivel de competencia. . es vital definir y conocer lo que se quiere lograr. Pasión por conocer la finalidad. 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. Un analista de sistemas debiera tener la capacidad de trabajar en “la mesa” completa. Para ello es vital una formación lo más completa posible17. Visión y acción global Sucede a veces que el punto de partida de un proyecto es la definición de una necesidad computacional. En tal caso. Aconseja Davidson (2001. al menos en el mínimo indispensable. 17 Ver libro Análisis de Sistemas. derechos de propiedad intelectual y uso inapropiado de los computadores”. resultados y propósito alineado. Más allá de los entregables por etapa. procesos y estructura organizacional. todos los actores del proyecto deben tener claridad en objetivos. Tener la vista puesta en el destino ayudará a darle sentido a todas las actividades del proyecto.MODELANDO UNA SOLUCIÓN DE SOFTWARE 57 nas de estas son: confidencialidad.

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

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

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

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

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

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

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

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

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

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

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

CC: Comprobante del Crédito. Flujograma de información Si se está utilizando el desarrollo en espiral. El mapa de procesos debería estar construido desde el principio y solamente se realizarían perfeccionamientos en cada vuelta de la espiral. OE: Orden de Entrega Figura 1-11. 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 detalle a nivel de los flujogramas de información podría ser parte de cada iteración. Válido para formularios manuales o computacionales. Se debe realizar el diseño de formularios asociados al detalle de los flujogramas de informació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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

computacionales o no. orientado a los eslabones más altos del manejo de información y la tecnología de información. .MODELANDO UNA SOLUCIÓN DE SOFTWARE 105 La empresa en la comunidad Planificación estratégica Adaptación al cambio Liderazgo. De esta manera. Parte de este esfuerzo de educación es conocer en profundidad los alcances de la tecnología de información y sus implicancias. 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. 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. los ejecutivos y profesionales podrán apreciar su organización desde un punto de vista más amplio. Con una visión de conjunto que permita tener a todos sus integrantes un alto grado de participación en el rediseño de los procesos del negocio.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

la operación regular de la aplicación destinada a satisfacer el requerimiento para el cual fue construida. porque unos dos tercios de las actividades regulares de los centros de computación están destinadas a mantenimiento. Sin pretender profundizar en esta materia. conviene señalar algunas labores clave: • Mantención de una bitácora de procesos • Control de funcionamiento correcto • Optimización de recursos • Reconstrucción de bases de datos • Seguridad e integridad de la información • Recuperación de la información • Auditoría computacional . esto es.144 JUAN BRAVO C. 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 %.

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

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

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

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

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

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

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

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

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

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

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

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

fechas u opciones de menú.MODELANDO UNA SOLUCIÓN DE SOFTWARE 157 2. 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. 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. Veremos: 1. evitándose el ingreso de parámetros. Auditoría computacional 3. la explotación mejora en mucho. Seguridad de la información 5. es deseable ejecutar cada proceso de la forma más automática posible. Integridad de la información 6. El diseñador del sistema debería conocer algunas tareas técnicas propias de la operación. Operación del sistema 2. 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. Es importante este cambio de concepto. Contribución del diseño a la protección de la información 4. Recuperación de la información 1. realizadas por especialistas y usuarios. como las siguientes: • Mantención de una bitácora de procesos: incluso en los sistemas de tiempo real hay procesos batch que es indispensable programar según una bitácora de . Operación del sistema Entendemos la operación como el conjunto de tareas que permiten el buen funcionamiento de la aplicación. En sistemas mayores hoy es una labor de conjunto y en sistemas pequeños los usuarios pueden realizar todas las labores.6. 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. Es sabido que tomando algunas precauciones en la etapa de diseño de la aplicación que luego se implementen. En este caso el costo aumenta al menos en un orden de magnitud y el modelo pierde elegancia. Para obtener una aplicación amistosa.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Veremos: • Marco teórico de los modelos • Modos de procesamiento • Once claves de los modelos computacionales • Modelamiento de funciones • Fundamentos del modelamiento de funciones • Criterio curso normal de los eventos . tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). Senn (1987. Esta es la tercera competencia considerada para apoyar la elaboración de modelos de una solución de software. o dicho de otra forma. UML CAPÍTULO 5. 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. ORIENTACIÓN A OBJETOS CAPÍTULO 4. 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. TEORÍA DE MODELOS CAPÍTULO 2. CAPÍTULO 7. p. INGENIERÍA DE SOFTWARE CAPÍTULO 1. Sería un error distinguir entre problemas del negocio en sí y de sistemas. Teoría de modelos aplicada Sin importar el tipo de empresa. el analista trabaja en problemas comerciales. en particular el criterio del curso normal de los eventos. MODELAMIENTO DE DATOS CAPÍTULO 3. 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. HERRAMIENTAS TI CAPÍTULO 6. son claves en esta misión.MODELANDO UNA SOLUCIÓN DE SOFTWARE 177 Capítulo 3. no existen problemas de sistemas que no hayan sido primero del negocio. En este caso.

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

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

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

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

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

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

. En tiempo real Se ingresan los datos en el punto de generación del dato y la actualización de la información es inmediata. por lo tanto. hardware y de comunicación que se requieren. se activan mensajes para realizar las actualizaciones de maestros. Aquí la característica principal es que se procesa transacción a transacción. uno de los cuales será un registro de las transacciones del día.184 JUAN BRAVO C. Este es un método de procesamiento relativamente nuevo y trascendental. 3. es necesario cuantificar los recursos de software. 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. o del período de ingreso considerado. Al terminarse el ingreso de una transacció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. de la misma manera como las aguas de un río buscan su cauce natural. 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. Son 11 claves orientadas a enriquecer los modelos de aplicaciones computacionales. sino que la capture lo más fielmente posible en pocos modelos dinámicos. En la organización. Generalización 9. Asimismo. . Armonía entre el modelo y la realidad 1. Totalidad 8. Por lo tanto. portabilidad. Desarrollo incremental 10. Intuición 3.MODELANDO UNA SOLUCIÓN DE SOFTWARE 185 3. de algún hardware específico y de las herramientas de software que apoyan el desarrollo. como por ejemplo: abstracción. flexibilidad. amistosidad. Simplicidad 4. Veremos: 1. a veces el flujo de datos queda atrapado en una reglamentación obsoleta. Transacciones presentes 11. impersonalidad y factibilidad. Iteración 7. no hay una indicación en la forma de “pasos a seguir”. Se supone que ellas son conocidas.3. son independientes de la implementación. Son diferentes a las características universales del diseño de productos y servicios. Fluidez 2. Independencia de la implementación tecnológica 6. Fluidez El modelamiento del sistema debe mantener abiertos los cauces por donde fluyen libremente los datos de la organización. Orientación al cliente 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

204 JUAN BRAVO C. • La modularidad e independencia de las funciones atómicas permite que una aplicación computacional sea construida con piezas intercambiables y tal vez desarrolladas en diferentes lugares (como los juegos de armar de los niños). . En el capítulo 5 veremos que la orientación a objetos recoge la mayoría de los conceptos descritos en este punto.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

la tabla de traducción tiende a desaparecer. más un programa simple de mantención.234 JUAN BRAVO C. hacen muy fácil la mantención de los códigos de la instalación. Cabe destacar que con la introducción de la lista de valores posibles como una característica más del campo y manejada en forma automática con herramientas de productividad. 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.

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

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

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

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

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

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

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

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

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE 245 porque no se repiten soluciones a los mismos problemas y porque hay una inversión en inteligencia al ser posible que nuevos especialistas aprovechen todo o parte del avance de sus predecesores. Veremos: • Fundamentos de la orientación a objetos • Definiciones sobre orientación a objetos • Conceptos de la orientación a objetos • Proceso de generalización • Fases de la orientación a objetos • Incorporación de la tecnología de objetos . 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. más aun cuando el diseño queda registrado en alguna herramienta de apoyo para esta etapa.

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. Reutilización. José Piquer. . sólo porque el tipo de datos cambia?”. 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. académico del Departamento de Ciencias de la Computación.1. Escuela de Ingeniería de la Universidad de Chile. 5. En los años 60 surgió lo que conocemos como diseño físico o esquema tradicional de diseño. ya aconseja a los ingenieros en computación que comiencen a estudiar la orientación a objetos.246 JUAN BRAVO C. ¿Cuántas veces uno implementa la misma función de búsqueda. El objetivo de esta evolución histórica ha sido el aumento de productividad. el sueño de la ingeniería de software. 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. La aparición de la orientación a objetos en los años 80 hereda esos avances previos. principalmente vía SmallTalk. Lo cual se logra en esta técnica mediante tres formas principales: • Evitando la redundancia en la construcción de código • Reutilizando estructuras y código • Aplicando visión sistémica (visión de conjunto y autonomía) Al principio de la informática. las aplicaciones prácticamente no tenían diseño y luego surgieron diversas formas más bien locales y artesanales. “nos comienza a proveer con algunas herramientas buscadas por largo tiempo: las bibliotecas de clases. Considerando que hemos reconocido a Edward Yourdon como uno de los padres de este esquema. En un artículo en Revista Informática de principios de los 90. no requiere de mayores comentarios mencionar que en la década de los noventa él promovió… la orientación a objetos. el principal método que dominó desde los años 60 es el diseño estructurado. manteniendo sólo un “diseño estructurado mejorado” para quienes conservaban esa tecnología en sus instalaciones o se incorporaban tardíamente. Señala que la programación orientada a objetos.

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

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

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

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

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

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

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

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

Convenciones de diseño 3. El punto (•) señala que el campo es llave principal. se justifica una representación más simple para ellas. 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. El campo Rut es un número identificador de personas y empresas en Chile. 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.2. . Definiciones preliminares El juego de denominaciones tiene como base la figura 5-6. Veremos que en los diagramas finales de diseño hay solamente clases. Condición de existencia 1. Veremos: 1. tal como lo propone Edward Yourdon. por lo tanto.MODELANDO UNA SOLUCIÓN DE SOFTWARE 255 5. Definiciones preliminares 2. Nomenclatura de la orientación a objetos Nótese en la figura 5-6 que la representación gráfica de los objetos es con una doble línea y la de las clases es con una sola línea. En cierto contexto un objeto puede ser visto como una clase y en otro como un objeto. 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. Son conceptos recursivos y que dependen del contexto. Alberto Torres Clientes C/E Figura 5-6.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿qué viene después? Creemos que más estándares y mayor énfasis en trabajar metodológicamente. Siempre en la línea de entregar en estas páginas un mínimo indispensable. . la identidad personal y el proceso de generalización. no se ha querido romper la unicidad incorporando particularizaciones. la simplicidad final del concepto.286 JUAN BRAVO C. por ejemplo. la comunicación de mensajes. el enfoque sistémico. 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. transformar las clases en entidades concretas o tomar los atributos desde un diccionario completo de los datos de la organización.

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

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

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

a modelos individuales o a cualquier elemento que sea identificado individualmente. Diagrama de paquetes Diagramas de comportamiento. Diagrama de vista de interacción También utiliza un glosario: incluye la definición de todos los términos que se emplean en los modelos de UML. Diagrama de estructura compuesta 5. MODELOS DE UML La versión 2. Diagrama de despliegue 6.1. los cuales se concentran en los elementos que deben existir del sistema: 1. es aplicable en todas las etapas del desarrollo. Diagrama de componentes 3. En UML se usa el término artefactos para referirse a diversas agrupaciones de modelos. 6. son parte de los diagramas de comportamiento que se refieren al flujo de control y de datos entre los elementos del sistema: 10. Cuando en el contexto de UML se usa la palabra sistema. Casos de uso 2. utilizados para reflejar las acciones del sistema: 7. Veremos: 1. Diagrama de clases 2.290 JUAN BRAVO C.0 de UML tiene 13 tipos de diagramas. Diagrama de objetos 4. es porque hace referencia al sistema computacional. Diagrama de colaboración 12. Diagrama de estados Diagramas de Interacción. Diagrama de secuencia 11. Diagrama de casos de uso 9. Diagramas de estructura. Diagrama de actividades 8. Uso de herramientas . Diagrama de tiempos 13.

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE 293 6. por ejemplo. Caso de uso expandido 4. Modelo conceptual 5. Caso de uso de alto nivel 3. Diagrama de secuencia del sistema 6. todos los casos de uso que tienen relación con un proceso incluido en el flujograma de información. 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). un dominio (en este caso terminales del área de adquisiciones) y una acción con un verbo en infinitivo dentro de cada óvalo. Diagrama de casos de uso 2. APLICACIÓN DE LOS MODELOS UML EN LA ETAPA DE ANÁLISIS El siguiente ejemplo muestra en la práctica el uso simplificado de los principales modelos de UML en la etapa de análisis74. Diagrama de casos de uso El diagrama de casos de uso representa una agrupación de casos de uso. Se observa que cada actor puede interactuar con más de un caso de uso. Planteados en el espíritu del método GSP de trabajar con el mínimo indispensable. Visión dinámica del sistema 7. para que efectivamente pueda ser aplicado en la mayoría de las organizaciones. los casos de uso seleccionados para la respectiva vuelta de la espiral se transforman en casos de uso expandidos. . 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. En el desarrollo en espiral. Diagrama de estado 8.2. Contratos 1. Entonces. Veremos: 1. En la figura 6-2 se presenta un diagrama de casos de uso para el ámbito de adquisiciones. En el anexo 7 se pueden apreciar estos modelos para una aplicación real y detallada de UML.

Señalan Stevens y Pooley (2002. en este caso aplica la forma <<extend>> sobre una línea punteada que apunta hacia el caso de uso original. 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. Por ejemplo. ambas descripciones de los casos de uso “Tomar prestada copia de libro” y “Ampliar préstamo” mencionan la necesidad de comprobar si existe una reserva sobre el libro”. 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. Explican Stevens y Pooley (2002. pueden ocurrir varias cosas diferentes dependiendo de las circunstancias. p. 124): “Si un caso de uso incorpora dos o más escenarios con diferencias significativas. Entonces deciden incorporar esa necesidad común.294 JUAN BRAVO C. 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. p. 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. • Separación del comportamiento variable. “Comprobar reserva” como otro caso de uso referenciado por los dos anteriores.

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

297

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

C
-

Encargado Recepción Razón Social Proveedor

D F

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

A

B

E

G
Ciudad M

H
Fax

I

J

Fono

K N
Precio

L O
Valor Neto

Guía de Despacho de Proveedor Nº

Fecha G/ D. Proveedor

Nº de O/C.

L.

Código

Descripción

Cantidad

LL

P

Q

R

S

T

Cerrada Anulada

W Y

Cerrar X Anular Z

XX
Salir

V
Grabar Total acumulado

U

Figura 6-5. Ejemplo de Interfaz visual detallada

4. Modelo conceptual
El modelo conceptual define responsabilidades y el dominio del sistema computacional, al comienzo asociado a los casos de uso identificados. Es un modelo que se va construyendo en paralelo con los casos de uso. Identifica los conceptos más relevantes del mundo real en el dominio respectivo: roles de personas, tipos de documentos o elementos físicos. También identifica las asociaciones entre conceptos con palabras de enlace: usa, registra en, almacenado en, pagado por, contenida en… Se trazan líneas entre los conceptos para representar este detalle. En esta etapa, una recomendación es incorporar en el modelo el máximo de conceptos y el mínimo de asociaciones. Las características del modelo conceptual son muy similares al modelamiento tradicional de datos. En las asociaciones entre los conceptos se da multiplicidad o cardinalidad.

298

JUAN BRAVO C.

Se expresa de la siguiente forma: * : cero o más (muchos) 1..* : uno o más 1..12 : de uno a doce 3 : exactamente 3 2, 4, 9 : exactamente 2, 4 ó 9 Siguiendo con nuestro ejemplo de la Orden de compra, el modelo conceptual tendría la forma que se indica en la figura 6-6:
Encabezado de O/C compuesta por se asocia a 1 1..* contiene * existe en 1 existe en * almacena 1 Bodega Productos contiene * existe en 1 Proveedores

Líneas de la O/C

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

En la figura 6-6 se puede apreciar que: • Una O/C está compuesta por 1 ó más líneas de O/C. A su vez, una línea de O/C se asocia a un solo encabezado de O/C. • Un encabezado de O/C contiene un proveedor. Un proveedor existe en 0 ó más encabezados de O/C. • Una línea de O/C contiene un producto. Un producto existe en 0 ó más líneas de O/C. • Un producto existe en 1 bodega. Una bodega almacena 0 ó más productos. Obsérvese que aparece, con un rombo negro, una asociación de composición, equivalente a la relación de pertenencia (que se marca con una línea más gruesa) del modelamiento de datos. En la composición, también llamada unicidad, una línea de la O/C no puede existir sin su encabezado y viceversa.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

299

En los conceptos también existen atributos, tal como se aprecia en el modelo de la figura 6-7, siguiendo con nuestro ejemplo de la orden de compra.

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

contiene existe en * 1

Proveedores Rut Nombre

Líneas de la O/C Unidades Precio

contiene existe en * 1

Productos ...

existe en * almacena 1 Bodega ...

Figura 6-7. Ejemplo de modelo conceptual con atributos

5. Diagrama de secuencia del sistema
El objetivo del diagrama de secuencia es identificar las operaciones de la aplicación, las que luego darán origen a los mensajes y al protocolo del sistema. Con base en la narración realizada en el caso de uso, se identifican las operaciones de la aplicación, aquellas que obligarán al sistema computacional a hacer algo y que afectarán a uno o más conceptos de aquellos incluidos en el modelo conceptual. A este nivel de especificación, la aplicación sigue siendo como una caja negra de la cual sólo se conocen sus entradas y salidas. En la figura 6-8 se muestra la forma general del diagrama de secuencia para un caso de uso donde se está ingresando una orden de compra. Suponemos que se obtuvieron esas operaciones desde la narración del caso de uso.

300

JUAN BRAVO C.

Administrativo

Sistema

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

Figura 6-8. Ejemplo de diagrama de secuencia

¿Qué es una operación? Una operación es un mensaje, un mandato para que algo se ejecute, provoca que algo suceda fuera de la frontera del caso de uso. Específicamente, activa una o más funciones en el sistema. Al principio de la especificación, la aplicación se ve como una caja negra y en la medida que se avanza con el detalle, la columna Sistema se abre en otras: los conceptos, produciéndose una estructura de mensajes.

6. Visión dinámica del sistema
Este diagrama es un resumen de las operaciones del sistema, la gráfica sugiere que al unir esta funcionalidad con el modelo conceptual, lograremos algo central de la orientación a objetos: el encapsulamiento, es decir, un sólo todo (clase u objeto) con los atributos y los métodos. Cuando se trata del primer caso de uso que estamos desarrollando en un sistema, el diagrama de secuencia y la visión dinámica son iguales, desde el segundo se diferencian porque la visión dinámica es acumula las operaciones de los diferentes casos de uso, tal como se aprecia en la figura 6-9.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

301

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

Caso de uso Ingresar O/C

Figura 6-9. Ejemplo de diagrama visión dinámica del sistema

Algunos comentarios respecto a los diagramas de secuencia y visión dinámica del sistema: • Las operaciones del sistema y el diagrama de secuencia son uno a uno con el caso de uso. • Ambos tienen las mismas operaciones, más bien llamadas a operaciones, porque corresponden a la estructura de mensajes del diagrama de clases (que ya veremos). • La nomenclatura es la de orientación a objetos. • Los mensajes de la visión dinámica del sistema son mensajes que llegarán a varias clases, cada una tiene la estructura de atributos y funciones.

7. Diagrama de estado
El diagrama de estado de UML representa gráficamente el estado del caso de uso antes y después de cada una de sus operaciones. En la figura 6-10 se observa aplicado a nuestro ejemplo de ingreso de una orden de compra.

302

JUAN BRAVO C.

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

Figura 6-10. Ejemplo de diagrama de estado

El diagrama de estado aplica principalmente en aplicaciones de ingeniería y se utiliza poco en el ámbito de los sistemas de información administrativos, por lo tanto, no lo incluimos en el curso normal de los eventos de los modelos a utilizar en el método GSP.

8. Contratos
Los contratos detallan cada operación y existirán tantos como operaciones se hayan identificado en el caso de uso y detalladas en el diagrama de secuencia. Tienen la estructura que se indica en la figura 6-11.
Contrato Identificación: nombre de operación y parámetros Responsabilidades: descripción informal de las responsabilidades u objetivos de la operación Tipos de datos: conceptos que afecta o clases Referencias cruzadas: enlaces con otras funciones del sistema o casos de uso. Notas: indicaciones para diseño, algoritmos (tal como el cálculo de dígito verificador) y otros datos. Excepciones: ¿qué sucede si...? y otros casos excepcionales. Salida: Mensajes o registros que se envían fuera del sistema. Precondiciones: Supuestos acerca del estado del sistema antes de ejecutar la operación. Poscondiciones: Indicación de como quedó el sistema después de la operación. • Poscondición 1 ... • Poscondición 2 ... • Poscondición n ...

MODELANDO UNA SOLUCIÓN DE SOFTWARE

303

Figura 6-11. Forma de un contrato por operación

Una clave para entender los contratos son las poscondiciones, es decir, como quedó el sistema después que se ejecutó la operación. Es como la fotografía que se toma después de un suceso. Veamos el ejemplo de la figura 6-12 para nuestro caso de ingreso de orden de compra.

Contrato Identificación: Dar OK al ingreso de la línea Responsabilidades: con cada ingreso de línea los conceptos deben ser consistentes. Tipos de datos: afecta a los conceptos Encabezado de O/C y Detalle de O/C. Referencias cruzadas: no hay Notas: nada especial Excepciones: la no existencia de la línea en el sistema ya fue validada con el ingreso de O/C. Salida: no hay Precondiciones: no existe la línea. Poscondiciones: •Se creó una línea en el concepto detalle. • Se actualizó el contador de líneas en el encabezado. • Se actualizó la asociación entre encabezado y detalle de O/C.
Figura 6-12. Ejemplo de contrato en dar OK ingreso línea

Se identificó, en tiempo verbal pasado, cómo fueron afectados los conceptos tras la operación (poscondiciones). Un contrato sin poscondiciones es una alerta de error, tal vez en la definición de la operación.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

340 JUAN BRAVO C. 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. De hecho. . Como decía El Quijote: “estar prevenidos es estar armados”. algunos grupos autodirigidos definen y mantienen sus propios sistemas de información.

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

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

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

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

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

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

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

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

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

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

Veremos en las siguientes láminas un caso completo de compras en UML. modelo en Power Point y detalle en Word. comienza por los modelos de la etapa de análisis. usted puede bajar este archivo desde la página www. En el aspecto metodológico se basa principalmente en el libro “Applying UML and Patterns” de Craig Larman (1998. 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.cl Puede bajar también: • El caso de uso Ventas • Método de Acción Rápida (MAR) sobre procesos. .evolucion.MODELANDO UNA SOLUCIÓN DE SOFTWARE 351 ANEXO 7. Lo vimos en el anexo 5. Cada lámina tiene notas que explican el respectivo modelo. Prentice Hall).

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.352 JUAN BRAVO C. 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). que incluye.1998 (Prentice Hall) ISBN 0-13-748880-7 Bibliografía: Adicionalmente. . 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. análisis y sistemas de Juan Bravo C.

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

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

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

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

Comunicarse con Departamento de Compras. Comunicarse con Administrador. rechazar. Comunicarse con Administrador. 2) Campo M : Nº de Guía ya existe para el RUT del Proveedor. 4) Campo C : Encargado de Recepción no registrado (Código no existe). Recepción RUT Proveedor Dirección Proveedor Comuna C - Encargado Recepción Razón Social Proveedor D F Nº Guía Recepción Fecha Recepción e-Mail A B E G Ciudad M H Fax I J Fono K N Precio L O Valor Neto Guía de Despacho de Proveedor Nº Fecha G/ D.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).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. . 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: . 3) Campo E : RUT de Proveedor no registrado (RUT no existe). 5) Campo O : Nº de Orden de Compra no existe. Proveedor Nº de O/C. Indicar error. Comunicarse con Administrador. L. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful