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

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

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

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

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

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

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

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

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

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

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

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

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

De pronto me siento repitiendo algo que escuché por primera vez en mis inicios. no olvide que hay personas que van a vivir dentro de ese sistema y va a ser su casa en forma permanente. El pecado original en informática es comenzar a desarrollar sin tener los planos. bueno. no comience el desarrollo sin planos. Juan dice en el prólogo de este libro que lo que buscamos finalmente es una mayor productividad de nuestras empresas. Tengo la suerte de trabajar en una empresa constructora y sería un suicidio comenzar un proyecto sin tener los planos. 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. les tengo malas noticias. 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. no podemos comenzar a construir el sacro edificio si no tengo planos arquitectónicos hechos y bien hechos. acá es lo mismo. 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. Carlos Toloza 7 Cuando Juan me pidió revisar el material de este libro y escribir unas líneas al respecto acepté sin ningún problema. pero al sumergirme en el tema especí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. 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. cuando programaba mi primer software. por favor no comience la construcción sin los planos!!! La verdad es que prefiero dejar un mensaje simple y fuerte en la mente del lector que participa en un proyecto informático. Yo pienso que lo que estamos hablando en este libro es de tener y sentir la misma responsabilidad profesional frente al desarrollo de un sistema informático que frente a la construcción de una catedral. pero ese es el punto.20 JUAN BRAVO C. . en informática los planos del sistema podemos dibujarlos con alguna nomenclatura estándar como UML o alguna propia.

estamos hablando de hacer un buen proyecto informático que genere utilidades a la empresa. Bueno. no estamos hablando de modelar por modelar. . si lo entienden se darán cuenta del poder que hay en la informática.MODELANDO UNA SOLUCIÓN DE SOFTWARE 21 cual se implementa y esta reducción debe pagar la inversión comprometida para generar utilidades en el tiempo. eso es todo.

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

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

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

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

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

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

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

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

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

producto en (H) obtiene y despliega la descripción y el precio en (I) y (J) 9. 2… Incluye interfaces detalladas de E/S Caso de uso de alto nivel Encabezado de O/C compuesta por se asocia a 1 1.. Verifica que proveedor exista.* 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 . Excepciones: 1. Ingresar Rut en (D) 5.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. Dar OK a la línea 11…. Ingresar las unidades en (K) 10.. Para cada línea: Para cada línea: 7. Código Descripción Cantidad LL P Q R S T Modelo funcional generalizado Cerrada Anulada W Y Cerrar X Anular Z XX Salir V Grabar Total acumulado U Interfaz visual detallada . Funciones relacionadas: Curso Normal de los eventos Acción del actor Respuesta del sistema 1. Tomar la O/C desde el archivador 2. Ingresar Nº O/C en (A) 3. Calcula el subtotal y despliega en (L) 10. obtiene y despliega nombre y fono en (E) y (F) 6…. Ingresar el código de 8. Verifica existencia del producto... La O/C queda disponible para ser enviada al proveedor luego de la aprobación electrónica por el jefe de adquisiciones Resumen: (el mismo del caso de uso de alto nivel). vea caso de uso “Corregir Correlativo”. Si el número de O/C ya existe.. Verifica correlativo y envía respuesta en (B) 4. Proveedor Nº de O/C. 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. Modelo conceptual de datos Modelo conceptual con atributos Interfaz de Entrada Guía Interna de Recepción por Compra Código Enc. Detalle de transacción C/E Mensajes 4 y 5 Productos L. existe en * almacena 1 Bodega .

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

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

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

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

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

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

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

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

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

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

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

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE 45 d) Mapa de Retroalimentación Lleva registros de eventos enriquecedores al finalizar los proyectos. . Hay lugares donde se hace retroalimentación en un informe de fin de proyecto que luego queda archivado y nadie lo lee. En la figura 1-5 se usó la forma de un mapa mental. 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. 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. Así se puede capitalizar la retroalimentación. Conviene conocerlos ya sea porque son experiencias que es bueno replicar o porque hubo sucesos que queremos evitar. 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. esa información debe estar viva. No sirve.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

es indispensable seguir el procedimiento general del área de sistemas en cuanto a requerimientos menores. El jefe de informática la recibe y asigna a un analista 3. El analista realiza un estudio de impacto: • Lo presenta como un caso de uso • Determina impacto en la aplicación y en otros sistemas • Calcula costo y recursos • Determina duración . Flujograma de información de control de cambios Detalle del procedimiento de control de cambios menores: 1. 2. Un ejemplo de procedimiento se presenta en la figura 1-13 y a continuación como texto. Control de cambios Se trata de establecer un procedimiento de aceptación de requerimientos menores en el ámbito de la TI.80 JUAN BRAVO C. 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. Un usuario autorizado emite una solicitud de cambio menor.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cuándo y por qué aplicarla. Esto es profesionalismo.MODELANDO UNA SOLUCIÓN DE SOFTWARE 107 Es que la implementación de cualquier tecnología debe armonizar conocimiento y entendimiento. no cabe duda. Con capacitación podemos conocerla. . pero sólo con educación sabremos dónde. 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.

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

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

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

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

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

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. . centralizada y como parte de cada área usuaria autónoma. debe poseer funciones esenciales de sobrevivencia: manejo económico. dirección y tecnología. Así como existe una fuerza aérea nacional y una rama aeronaval de la armada. dando a cada área usuaria autonomía en el manejo informático.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. entre otras. La recursividad dice que estas funciones esenciales se encuentran a nivel de la empresa y de cada área viable. de personas. en la organización debieran existir funciones de manejo de la información. Analizaremos aquí algunas posibilidades de organización informática. Para que un área sea viable. Reconversión de programadores 3. Nuevas formas de organización informática El diseño organizacional del área informática es parte integrante de las definiciones estratégicas respecto a la ingeniería de software. compatibles entre sí: Equilibrio entre centralización y descentralización Significa conservar un centro de información a nivel de la empresa.

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

En este caso. 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. MODELAMIENTO DE DATOS CAPÍTULO 3. Sería un error distinguir entre problemas del negocio en sí y de sistemas. p. 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. CAPÍTULO 7. 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. tal como se aprecia en la siguiente figura (en la introducción se incluyó la visión global de las competencias). Senn (1987. 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. UML CAPÍTULO 5. 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 . Esta es la tercera competencia considerada para apoyar la elaboración de modelos de una solución de software. o dicho de otra forma. el analista trabaja en problemas comerciales. Teoría de modelos aplicada Sin importar el tipo de empresa. HERRAMIENTAS TI CAPÍTULO 6. en particular el criterio del curso normal de los eventos. ORIENTACIÓN A OBJETOS CAPÍTULO 4. INGENIERÍA DE SOFTWARE CAPÍTULO 1. TEORÍA DE MODELOS CAPÍTULO 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tal como el lector de código de barras. incluyendo los accesorios.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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. más aun cuando el diseño queda registrado en alguna herramienta de apoyo para esta etapa. Veremos: • Fundamentos de la orientación a objetos • Definiciones sobre orientación a objetos • Conceptos de la orientación a objetos • Proceso de generalización • Fases de la orientación a objetos • Incorporación de la tecnología de objetos . En este libro se aborda la orientación a objetos desde el punto de vista del desarrollo de las aplicaciones computacionales que apoyarán el negocio de la organización.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sumar descto C/E Mensaje 19 Rebaja de Préstamos • Nº documento Rut Monto Nº cuota Ingresar datos Obtener informe Figura 5-10. 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. Sumar haber 19. Para aclarar más el concepto. los atributos comunes son: número de documento. ingreso. Sumar descto C/E Rebaja de préstamos Nº cuota Mensaje 19 Figura 5-11. Ejemplo de definir una clase de transacciones de sueldos . 5-11 y 5-12. 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.270 JUAN BRAVO C. 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. Descuento de Anticipos Transacciones de sueldos • Nº documento Rut Monto Ingresar datos Obtener informe Empleados • Rut Monto Total haber Total descuento 18. 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. los que heredarán sus elementos y ayudarán a perfeccionarla. RUT del empleado y monto de la transacción.

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

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

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

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

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

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

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

esto por la característica de funcionalidad intercambiable indicada al comienzo del capítulo. 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. 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. Por ejemplo. el mensaje 1 —que tiene por misión solicitar agregar un nuevo documento a la clase transacciones— se envió sólo al encabezado. Un mensaje implícito es que cada una de estas funciones generalizadas es también una clase en otro nivel de abstracción. Encabezado de transacción • Nº documento Fecha Rut persona 1 Agregar 2 Consultar 3 Imprimir C/E Mensaje 1 Personas Ingreso de transacción Encabezado. • Los mensajes 4 y 5 sobre inventarios se refieren a sumar o restar el saldo del artículo.278 JUAN BRAVO C. con lo cual también se agregará automáticamente en el detalle (a través de un mensaje que enviará el encabezado al detalle). respectivamente. • La similitud que existe entre las funciones de las clases nos debería llevar a definir un conjunto de funciones generalizadas que tuvieran siempre la misma identificación. .

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE 281 En la siguiente figura. Enviar solicitudes para actualizar el stock Objeto Ingreso de ventas Ingreso de compras Tabla de objetos. la tabla sería similar a la de productos de la figura 5-19. stock mayor a unidades por vender. Dos niveles de funcionalidad En la OO existen dos niveles de definición de funcionalidad. número 5-20. Ingreso de transacción Encabezado. detalle y totales según Formato de pantalla adjunto Aceptar datos y actualizar línea a línea cada producto. vemos la descripción de la clase Ingreso de transacción. Cuadrar totales para referencia. sin diferencias entre sí. Mensaje 4 Figura 5-20. 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. Visión interna de la clase ingreso de transacción Para completar el sistema de inventarios presentado en la figura 5-18. Ambos deben existir. • Personas: podría suceder que la descripción de clientes y proveedores sea igual. señalada en el punto anterior. deberíamos describir las otras clases e incluir la tabla de objetos de cada una: • Encabezado y Detalle de transacción: van juntas porque hay una relación de pertenencia entre ellas. Mensaje 5 Crear proveedor y artículo si no existen. 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. en tal caso.

en otras palabras. figura 5-18. En el segundo nivel se define funcionalidad sobre conjuntos de atributos. tal como agregar un artículo u obtener un informe. Generalmente esta funcionalidad viene definida desde el modelo de datos. En ambos casos. serían clases en otro nivel de abstracción. Interfaz humana Especialmente en el orientación a objetos el diseño de la interfaz humana es vital para lograr el objetivo final de tener una buena aplicación en funcionamiento pleno. .282 JUAN BRAVO C. la funcionalidad puede ser generalizada. 5. acerca de ingeniería de software. En el capítulo 2. dedicamos una sección al diseño de estas interfaces.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. comunicar información. ¿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. con un simple procesador de palabras puede ordenar textos. Workflow . Herramientas integradas para automatización de oficinas 2.318 JUAN BRAVO C. Hace algunos años. era necesario construir sistemas computacionales pequeños que podían ocupar un mes de programación y lo mismo es válido con el uso de graficadores o planillas electrónicas. por ejemplo: “pintar” una pantalla. realizar seguimiento del proyecto. modelar los datos y comunicar el modelo a una base de datos.2. Por ejemplo. 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. 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. 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. hoy. lo cual se puede estimar al menos en un 70%. para satisfacer esos requerimientos. efectuar cálculos. producto de las mayores potencialidades de las herramientas. Veremos: 1. ordenar una tabla. imprimir etiquetas o manejar eficientemente una base de datos simple. Groupware 3. • En segundo lugar.

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

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

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

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

6. SRM Los productos SRM (Supplier Relationship Management. Informix. 5. Motor de base de datos Aquí se puede referenciar el enfoque de bases de datos del capítulo 4. Sybase. Buscan integración a través del software. DMS e Ingres. SQL Server. . en todo caso. en español.MODELANDO UNA SOLUCIÓN DE SOFTWARE 323 Es una herramienta del tipo B2C (Business to Consumer. Es una herramienta del tipo B2B (Business to Business. o comercio electrónico entre empresas). o comercio desde las empresas al consumidor). hablamos de sistemas administradores de bases de datos tales como: Oracle. por ejemplo. para que un proveedor de materias primas vea el saldo de productos en la bodega de la empresa y genere una reposición automática. Progress. gestión de la relación con los proveedores) ayudan en la gestión de las relaciones con los proveedores.

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

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

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

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

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

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

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

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

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

Quizá por eso Plutarco —escritor romano— dijo: Un buen enemigo es el mejor maestro. Debería “preparar” a su organización para ser receptiva al cambio. en vez de resistir. Esto es. prepare bien una respuesta y reaccione con mucha fuerza para lograr sobrevivir85. reflexiona sobre ella e independiente de las exageraciones que pudiera contener. Cada área de la organización debería tener su propia misión. 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. Es equivalente a cuando se critica a alguien y esa persona. Hoy. en armonía con las necesidades estratégicas de la institución. la toma con agradecimiento y se esfuerza por ajustar su conducta en base a la porción de verdad que ella contiene. 85 84 . “absorbe” silenciosa y positivamente la crítica. Debería permitir que la empresa absorba los “golpes” del medio. el rol de la planificación estratégica va mucho más allá. defenderse o contraatacar. como sería lo habitual. Por lo tanto. dando respuesta a preguntas del siguiente tipo: ¿Damos énfasis a la calidad o al mínimo costo? ¿Bajo qué paradigma de administración? ¿Potenciamos el conocimiento de la propia organización o utilizamos métodos externos? ¿Se requiere desarrollar más el área comercial o el área productiva?… Tradicionalmente la planificación se ha preocupado de: • Definición del propósito de la organización y de las metas departamentales • Creación de nuevos productos • Posicionamiento en determinados segmentos de mercado • Perfil de empleados • Estrategia de marketing • Estrategia de comercialización • Definición de imagen corporativa • Áreas geográficas de la organización y globalización.MODELANDO UNA SOLUCIÓN DE SOFTWARE 333 ANEXO 1. INTRODUCCIÓN A LA PLANIFICACIÓN ESTRATÉGICA La idea es tener una visión estratégica. se detenga. objetivos y planes. el desafío es flexibilidad y creatividad. Este es un resumen acerca de estrategia desde el libro Planificación sistémica.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

352 JUAN BRAVO C. entre otros. . 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. análisis y sistemas de Juan Bravo C. que incluye.1998 (Prentice Hall) ISBN 0-13-748880-7 Bibliografía: Adicionalmente. a: Gestión de Procesos (2005) y gestión de proyectos de procesos y tecnología (2006). 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 . 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.

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

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

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

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

Comunicarse con Administrador. 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. 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. 4) Campo C : Encargado de Recepción no registrado (Código no existe). Comunicarse con Administrador. Código Descripción Cantidad LL P Q R S T Cerrada Anulada W Y Cerrar X Anular Z XX Salir V Grabar Total acumulado U Caso de Uso: (Expandido) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Excepciones al Curso Normal de los Eventos: . Proveedor Nº de O/C. Indicar error. L. 2) Campo M : Nº de Guía ya existe para el RUT del Proveedor.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.Cursos Alternos al Curso Normal de los Eventos (para desarrollar los Casos de Uso correspondientes en otras vueltas de la espiral) 1) Campo F : Producto no registrado (Código no existe). Comunicarse con Administrador. 5) Campo O : Nº de Orden de Compra no existe. . rechazar. 3) Campo E : RUT de Proveedor no registrado (RUT no existe). Comunicarse con Departamento de Compras.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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