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

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

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

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

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

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

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

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

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

16 JUAN BRAVO C. . a quien conozco por muchos años. las cuales están insertas en organizaciones de diferente tamaño y sector. A. sistemas que son construidos con métodos estándares de construcción y calidad. Christian Andrews3 Todo libro conlleva un gran esfuerzo del parte del autor. Ratificando una vez más. una visión práctica (1988) Reingeniería de negocios (1995) Planificación sistémica (1997) Análisis de sistemas (1998) Gestión de procesos (2005) Taylor revisitado. ¿Dónde radica la importancia de este libro para los profesionales de TI? A mi juicio. Prólogo de Gerentes de áreas de sistemas Algunos estimados amigos me han otorgado el privilegio de agregar algunas palabras. En su particular manera de escribir. la productividad es la clave (2005) Gestión de proyectos de procesos y tecnología (2006) Responsabilidad social (2007) No hago referencias a mis libros Modelamiento de sistemas de información y La nueva visión. diseño y construcción de sistemas computacionales porque todos sus contenidos relevantes para efectos de modelar soluciones de software están incorporados en esta nueva obra. 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. 3 Gerente de Sistemas en Empresas Hites S. nos ofrece esta nueva entrega literaria: un libro que versa alrededor de una idea: el modelar soluciones de software. es decir. como afluentes a un río mayor. • • • • • • • • Desarrollo de sistemas de información. autor de un gran número de libros del área de la Tecnología de la Información (TI) aplicada a los negocios. para entregar estos nuevos conocimientos. Tienen en común estar a cargo de áreas de informática. esta entrega orienta y prepara a las pequeñas y medianas empresas. Mi amigo Juan Bravo. ideas y conceptos actualizados al día de hoy. Con metodologías que aseguran un resultado predecible en las operaciones diarias de los diferentes procesos comerciales. donde convergen todas las otras ideas menores. en concebir los sistemas computacionales como un commodity. nuevamente ha realizado otro gran esfuerzo.

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

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

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

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

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

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

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

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

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE 27 Mapas para la visión de conjunto Conviene observar estos cinco mapas que deberían existir en la organización previo al desarrollo de una aplicación específica. Vender al detalle Vender Postventa Atención al cliente Medición y seguimiento Servicio de garantía Cotizar Recepcionar Despachar Cuadrar Procesos de Apoyo Adquisiciones Servicios Básicos Finanzas Contabilidad Legal Transporte Remuneraciones y bienestar Tecnología y Mantención Meditación Cobranzas Buen trabajo en equipo Devolución Liderazgo sistémico Ventas Alcance poco claro Retroalimentación de eventos destacados Demora en entrega final Dificultades para coordinar entrevistas con usuarios Facturación Compras Bodega Entrega = Experiencias para evitar = Experiencias para replicar Recepción Mapa de retroalimentación Mapa de sistemas computacionales . Son los mapas de necesidades. Incluir como plan de acción de RS Mapa de proyectos 10p Tiempo Problemas detectados: 1. Alinear con la estrategia 2. procesos. Pago tardío a Proveedores 2. 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. proyectos. Bienestar Productividad Calidad Costo Responsabilidad Social 2p Soluciones propuestas: 1. retroalimentación y sistemas.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. 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. 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 45 d) Mapa de Retroalimentación Lleva registros de eventos enriquecedores al finalizar los proyectos. No sirve. esa información debe estar viva. 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. 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. Mapa de retroalimentación para replicar o evitar Es fundamental que el mapa este a la vista y siempre actualizado. En la figura 1-5 se usó la forma de un mapa mental. Hay lugares donde se hace retroalimentación en un informe de fin de proyecto que luego queda archivado y nadie lo lee.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hay que desmitificar la producción de software. herramientas de productividad o de automatización de oficinas. sobre herramientas de la tecnología de información.100 JUAN BRAVO C. La ingeniería de software incluye la producción de otros productos de software. como el énfasis en la programación orientada al objeto o la utilización de lenguajes que provean máxima eficiencia. quienes conocen su problema y saben como estructurarlo. para lograr aumentos de productividad de los desarrolladores de software. Veremos: • Alcance de la ingeniería de software • Planificación en informática • Sistema de productividad en el desarrollo de software • Criterios de desarrollo de software • Métodos para la producción de software • Apoyo del diseño en la explotación del sistema • Diseño de interfaces • Normas y estándares aplicados a los modelos TI . Usuarios calificados son profesionales y ejecutivos que poseen entrenamiento formal en tecnología de la información. es hacia la producción de software que apoye directamente los procesos de la organización teniendo siempre al cliente como norte (al cliente final. fáciles de construir y de mantener. No hay una contradicción entre obtener productos creativos trabajando metodológicamente. automatizada. a través de la aplicación de técnicas simples y herramientas poderosas. transformándola en una actividad mucho más amistosa. Todo lo que se refiere al apoyo automatizado para el desarrollo de software (Herramientas CASE) se incluyó en el capítulo 7. como sistemas operativos. Éstos siguen patrones parecidos a la producción de software administrativo e incluyen algunos aspectos más especializados. La orientación del capítulo y de todo el libro. el que paga). con una finalidad revolucionaria: permitir que los usuarios calificados puedan participar activamente en todo el ciclo de desarrollo.

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

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

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

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

De esta manera. 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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 105 La empresa en la comunidad Planificación estratégica Adaptación al cambio Liderazgo. . los ejecutivos y profesionales podrán apreciar su organización desde un punto de vista más amplio. Clasificación de materias para perfeccionamiento en TI En la figura 2-1 se puede apreciar que las materias de perfeccionamiento para los ejecutivos y profesionales de la organización están clasificadas en dos grandes áreas: un ambiente de calidad. organización y administración Ambiente de Calidad Reingeniería y benchmarking Mejoramiento continuo Visión sistémica Gestión de procesos Mapas de procesos Flujograma de Información Gestión de proyectos Orientación al cliente Diseño de sistemas Sistema de productividad Tecnología De Información Orientación a objetos y UML Modelamiento de datos Métodos de desarrollo de software Herramientas CASE Bases de datos simple Automatización de oficinas Figura 2-1. Parte de este esfuerzo de educación es conocer en profundidad los alcances de la tecnología de información y sus implicancias. con las materias propias del área informática. computacionales o no. orientado a los eslabones más altos del manejo de información y la tecnología de información.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

conviene señalar algunas labores clave: • Mantención de una bitácora de procesos • Control de funcionamiento correcto • Optimización de recursos • Reconstrucción de bases de datos • Seguridad e integridad de la información • Recuperación de la información • Auditoría computacional . Se estima que este solo concepto permite elevar la productividad de los especialistas en un departamento de sistemas al menos en 100 %.144 JUAN BRAVO C. esto es. porque unos dos tercios de las actividades regulares de los centros de computación están destinadas a mantenimiento. Sin pretender profundizar en esta materia. Junto con el mantenimiento de un sistema computacional se realiza su explotación. la operación regular de la aplicación destinada a satisfacer el requerimiento para el cual fue construida.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Lo nuevo es el principio SPPP (Simplificar Procesos y Potenciar Personas). el flujograma de información deja espacios para que las personas apliquen criterio.206 JUAN BRAVO C. dejando de lado el absurdo intento de preparar flujos “a prueba de tontos”. Ejemplo de flujograma de información despacho inmediato . GD: Guía de Despacho Figura 3-15. Así. 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. sensibilización y empoderamiento. entre otras acciones dirigidas a las personas. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

225

4) Relación N:M especial La relación N:M típica no permite manejar información propia de la interacción; por ejemplo, en la relación: proveedores ↔ artículos, el precio de los artículos según cada proveedor. Para resolver este problema, la relación puede tomar la siguiente forma:

Proveedores

Costo

Artículos

Donde se establece un nodo en el arco de la relación, la que a su vez se transforma en una entidad asociativa en la cual se puede almacenar mayor información, por ejemplo, el costo del artículo entre diferentes proveedores. Esta entidad asociativa es indispensable en el esquema relacional, donde las diferentes tablas deben contener los campos a través de los cuales se manipularán los datos. A esta relación también se le denomina NUB natural porque tiene “vida propia”, es decir, aparece en el modelo conceptual (modelo que ve la realidad del usuario) y tiene un identificador. También existe el NUB artificial, creado sólo para evitar la relación N:M mediante una doble jerarquía, no los ve el usuario en el modelo conceptual ni tienen identificador propio. La entidad asociativa también puede estar relacionada con una sola entidad, como en el siguiente ejemplo, donde la entidad parentesco tendría los siguientes atributos (persona, persona, parentesco).

Personas

Parentesco

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

226

JUAN BRAVO C.

Las relaciones de uso pueden tomar cualquiera de las siguientes formas: • Relación uno a uno. • Relación uno a muchos, a excepción de la relación de pertenencia. • Relación muchos a muchos, más conocida como tipo red.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

227

4.2. CRITERIOS BÁSICOS DE NORMALIZACIÓN DE DATOS
Se presenta un esquema de normalización del modelo de datos, basado en dos criterios: eliminación de grupos repetitivos y eliminación de dependencias parciales. Ambos fáciles de entender y aplicar, así aumenta la posibilidad de aplicación por parte de especialistas y usuarios. Aunque, un esquema completo de normalización es el que propone el Dr. E. F. Codd, con sus formas normales y variaciones sobre ellas. Los dos criterios de este capítulo son una simplificación que permite un acercamiento preliminar y equivalen hasta la tercera forma normal. ¿Por qué normalizar? Porque presenta variados beneficios, por ejemplo: • Lograr definir entidades atómicas, tiene la ventaja de trabajar con un conjunto de datos uniforme, sujetos a la misma clave, esto simplifica el modelo y da la posibilidad de aplicar funciones normalizadas. • Evitar la redundancia de datos, lo cual, además de ordenar y economizar recursos, ayuda a mantener la integridad, porque cada dato existe sólo una vez en el sistema, ¿si no fuera así? ¿A cuáles de las versiones de un dato le cree el usuario? • Normalizar el almacenamiento de datos, no sólo al interior de la organización, sino también al exterior. De esta manera se economiza en preparación de especialistas y es posible aplicar herramientas uniformes, como los sistemas administradores de bases de datos relacionales y las diferentes herramientas de productividad, para automatizar múltiples funciones: consulta de información, integridad, privacidad, recuperación, ingreso de datos, informes y muchas otras. • Aplicar herramientas de apoyo en el modelamiento, todas las cuales ayudan y hacen exigible la normalización de los datos. Por ejemplo, algunas herramientas de apoyo en el modelamiento de datos son: ERWIN y System Architect.

228

JUAN BRAVO C.

Evitar los tipos de registros Uno de los principales elementos que confabula contra la normalización de los datos, es incluir tipos de registros; por ejemplo: una tabla de transacciones con tipo de dato 1 para ventas y 2 para compras, lo cual presenta varios inconvenientes: • Probablemente existirán campos del registro asociados solamente a un tipo de datos. • Se produce una excesiva dependencia de los especialistas que construyeron el sistema, porque es muy difícil de entender. • Como la entidad no es uniforme, es difícil aplicarle funciones automáticas; en consecuencia, los programas que manipulan estas entidades son complejos y extensos. Veremos: 1. Eliminación de grupos repetitivos 2. Eliminación de dependencias parciales 3. Tabla de traducción

1. Eliminación de grupos repetitivos
Significa que los campos que se repiten en una entidad se llevan a otra. La nueva entidad nace con la misma clave de la entidad origen, más un identificador de cada ocurrencia del grupo repetitivo; puede ser un número correlativo o alguno de los campos del grupo repetitivo. El ejemplo de la figura 4-3 corresponde a la eliminación de un grupo repetitivo incorporando un número correlativo externo en una factura de venta.
A Entidad no normalizada Clave Nº factura Fecha Rut del cliente Grupo repetitivo Ítem 10 Ítem 1 … Código Cantidad Precio Código Cantidad Precio Entidades normalizadas B Encabezado Rut Clave Fecha del Nº factura cliente C detalle Clave Nº factura Nº ítem Código Cantidad Precio

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

En este caso:

MODELANDO UNA SOLUCIÓN DE SOFTWARE

229

• La factura de la entidad A tiene los campos: # factura, fecha, RUT y 10 artículos, cada uno con código, cantidad y precio. La normalización de esta entidad dio como resultado la creación de las entidades B Y C. Nota: el subrayado en # factura significa que el campo es identificatorio, que pertenece a la clave. • La entidad B (ENCABEZADO), quedó con los campos: # factura, fecha y RUT del cliente. Se puede apreciar que posee los mismos datos de la entidad A, menos el grupo repetitivo. • La entidad C (DETALLE), quedó con los campos: # factura, # ítem, código de artículo, cantidad y precio. Se agregó el número de ítem a la clave de la entidad de detalle, equivalente a un número de línea en la factura, porque en la factura podría repetirse un artículo, lo cual inhabilitaría al código para ser parte de la clave. El uso del número de ítem, un correlativo externo, presenta varias ventajas: • Se respeta el orden de ingreso de cada elemento del grupo repetitivo, lo que es vital en el momento de hacer revisiones manuales. Si la clave fuera el código del artículo, aun cuando éste no se repitiera, es posible que se pierda el orden de ingreso, porque es poco probable que el código se anotara en orden ascendente en el documento. • Es más uniforme y ordenado. • Se le da flexibilidad al modelo, porque se podría repetir un código sin afectar la integridad del documento; por ejemplo, en el caso de una factura se podría anotar dos veces un mismo producto, tal vez porque el cliente recordó al final del pedido que requería mayor cantidad del primer producto solicitado. En el ejemplo de la figura 4-4 vemos la eliminación de un grupo repetitivo usando un campo de la entidad origen (la misma de la figura 4-3), para este ejemplo, el código de artículo de la factura de venta.
Entidades normalizadas B Encabezado Clave Nº factura Fecha Rut del cliente C detalle Clave Cantidad Nº factura Código Precio

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

230

JUAN BRAVO C.

Al usar el código podemos apreciar que: • La eliminación del grupo repetitivo de la entidad A dio origen a una entidad (C) de detalle, con los campos: # factura, código de artículo, cantidad y precio. En este caso, suponemos que el código de artículo no se repite en la factura, así es que se lo incorporó en la clave como un campo identificador. • La entidad (B) de encabezado quedó igual que en la figura 4-3. Eliminar un grupo repetitivo usando un campo que ya viene incorporado en la entidad original es la forma más habitual de resolver un grupo repetitivo. Prácticamente en todos los casos, la eliminación de un grupo repetitivo da origen a una relación de pertenencia entre las entidades de encabezado y detalle que se obtuvieron del proceso de normalización. Gráficamente, el resultado se ve así:
B

C

2. Eliminación de dependencias parciales
El término dependencia parcial se aplica a campos que dependen sólo de una parte de la clave o bien de un campo que no es parte de la clave. Por lo tanto, una dependencia válida se da cuando el campo depende de toda la clave. Generalmente, la eliminación de las dependencias parciales significa llevar los campos parcialmente dependientes a una tabla de traducción (T/T) o aplicar una condición de existencia (C/E) sobre otra entidad que tenga como clave el o los campos origen de la dependencia parcial, tal como se muestra en la figura 4-5. La eliminación de la dependencia parcial da origen a una relación uno a muchos cuando la dependencia del campo es respecto a una parte de la clave. Si la dependencia es respecto de un campo no clave, se genera una relación de uso entre las entidades.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

231

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

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

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

Clave Nombre de Código de producto producto

Figura 4-5. Ejemplo de eliminación de dependencias parciales

En la figura 4-5 se aprecia que la entidad A tiene dos campos que no son dependientes de toda la clave: • Descripción del estado: es la traducción del código de estado en la sucursal, un campo no clave. La forma que toma la descripción es, por ejemplo: 1=terminado, 2=semiterminado. La tabla de traducción que da respuesta a esta dependencia parcial podría haberse reemplazado por una lista de valores posibles, como la que aparece en el ambiente Windows cuando se requiere buscar dentro de una gama de posibilidades. Este tema se trata extensamente en el siguiente punto, sobre tabla de traducción. • Nombre del artículo: dependiente del código del producto, un campo clave. ¿Cómo se resuelven estas dos dependencias parciales de la entidad A? En el primer caso, como se trata simplemente de la traducción de un código (código de estado versus descripción de estado), se le asigna una tabla de traducción identificada con el número 18 en el ejemplo. También estaría correcto definir una nueva entidad, la cual nacería con el código y la descripción del

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

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

diversos informes y un formato predefinido para usar la tabla desde múltiples aplicaciones.234 JUAN BRAVO C. 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. la tabla de traducción tiende a desaparecer. 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 .

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

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

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

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

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

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

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

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

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

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

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. el principal método que dominó desde los años 60 es el diseño estructurado. no requiere de mayores comentarios mencionar que en la década de los noventa él promovió… la orientación a objetos. La aparición de la orientación a objetos en los años 80 hereda esos avances previos. En los años 60 surgió lo que conocemos como diseño físico o esquema tradicional de diseño.246 JUAN BRAVO C. Reutilización. 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. Señala que la programación orientada a objetos. “nos comienza a proveer con algunas herramientas buscadas por largo tiempo: las bibliotecas de clases. En un artículo en Revista Informática de principios de los 90. Escuela de Ingeniería de la Universidad de Chile. 5.1. el sueño de la ingeniería de software. las aplicaciones prácticamente no tenían diseño y luego surgieron diversas formas más bien locales y artesanales. manteniendo sólo un “diseño estructurado mejorado” para quienes conservaban esa tecnología en sus instalaciones o se incorporaban tardíamente. 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. académico del Departamento de Ciencias de la Computación. 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. 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. principalmente vía SmallTalk. . ¿Cuántas veces uno implementa la misma función de búsqueda. sólo porque el tipo de datos cambia?”. José Piquer.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

con lo cual también se agregará automáticamente en el detalle (a través de un mensaje que enviará el encabezado al detalle). 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. Por ejemplo. . respectivamente. 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. 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. • Los mensajes 4 y 5 sobre inventarios se refieren a sumar o restar el saldo del artículo. 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. esto por la característica de funcionalidad intercambiable indicada al comienzo del capítulo. • 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.278 JUAN BRAVO C.

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

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

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

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

mejor aún.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. 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. Construcción de un modelo de objetos 1. Reutilización de código 3. En un grupo de trabajo cada uno de los participantes puede tomar el rol de un objeto para lograr simular. pensar que “yo soy el objeto” y comenzar a hacernos preguntas. por ejemplo: ¿Quién soy? ¿Para qué sirvo? ¿Qué atributos tengo? ¿Qué funciones cumplo? ¿Cuándo realizo esa función? ¿Cuál es el valor agregado que aporto? ¿Qué información necesito de otros objetos? ¿Qué información necesito para cumplir una función? A través de las cuales se va aclarando el entorno y luego el contenido del objeto. Esta es una excelente técnica para refinar la comunicación entre los objetos… y entre las personas. tal como en el enfoque sistémico. especialmente en cuanto a respetar normas internas y con el medio73. Personalización del objeto 2.6. Veremos: 1. Como técnica de definición es muy útil “personalizar” el objeto. es indispensable considerar su cultura y nivel de madurez. 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. entre todos. el funcionamiento del sistema. 73 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. De hecho. algunos grupos autodirigidos definen y mantienen sus propios sistemas de información.340 JUAN BRAVO C. tendencia a la participación de todos los interesados.

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

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

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

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

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

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

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

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

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

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

comienza por los modelos de la etapa de análisis. Veremos en las siguientes láminas un caso completo de compras en UML. Reconociendo que es difícil revisar en el papel. CASO COMPRAS CON UML Este caso fue un desarrollo completo de los modelos de UML contemplados en el método GSP (capítulo 1). Cada lámina tiene notas que explican el respectivo modelo. usted puede bajar este archivo desde la página www. .evolucion. modelo en Power Point y detalle en Word. 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. Prentice Hall).cl Puede bajar también: • El caso de uso Ventas • Método de Acción Rápida (MAR) sobre procesos.MODELANDO UNA SOLUCIÓN DE SOFTWARE 351 ANEXO 7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful