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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

También de las organizaciones donde he tenido el privilegio de participar como asesor o relator de seminarios: CMP. . Juan Carlos Soto Trucido. Polygram Chile Ltda. Luis Cavieres Rojas. Termosistema. Alexis Cifuentes Barra. Dagoberto Cabrera Tapia y Cristian Rubilar Utillano. no la sustituye. Rodrigo Baldecchi. Integramédica. Santiago Macías Huenchullan. Luis Cid. José Labra Molina. Rolf Achterberg Neüman. Gloria Arellano Mundaca. AT&T Chile. Diseño y Construcción de Sistemas Computacionales (1996). NCR y Weisselberger y Cía. Empresa Portuaria de Valparaíso. Rodrigo Collado Lizama. 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. Sota y Nicoletti Comunicaciones. ideas. Estoy agradecido de las empresas donde me acogieron como colaborador de tiempo completo: Empremar. Eugenio Díaz González. Bernardo Cienfuegos Areces. IST y ACHS. p. Hugo Osses Bravo. Derek Hyland. Carlos Parra Bustos y Raúl Prado Baldratti. motivación): Rolf Achterberg Neüman. Víctor Silva Ballerini. Christian Andrews Villagra. Manuel Videla Abarca. Marcos Merino. José Leiva Olmedo. Ricardo Cahe Cabach. David Medina Avilés. Especial mención requieren las empresas con las cuales hemos trabajado en la última década: BancoEstado. Carlos Toloza y Enrique Jorquera (mis disculpas por las eventuales omisiones). Carlos Reyes Rubio. Jeannette Caballero Pinilla.. Editorial Televisa. Ricardo Baeza Yates. Gerardo Cerda Neumann. Eugenio Díaz González. Daniel Kanonitsch. Rolec. Ignacio Castro Escobar. Sonia Esturillo Herrera. Mauricio Arancibia Pino. entre otras. Luis Méndez Reyes.22 JUAN BRAVO C. Muchas ideas y motivación han surgido de las conversaciones con Liliana Gajardo. Este libro es heredero de dos textos anteriores: Modelamiento de Sistemas Computacionales (1994) y La Nueva Visión. Liliana Gajardo Campos. Jorge Stein Blau. AGRADECIMIENTOS El liderazgo complementa a la gestión. Enami Ventanas (actual Codelco). Francisco Ramírez. así es que reitero en éste los agradecimientos a quienes aportaron de una u otro forma en aquellos (revisiones. Giancarlo Gandolini Ambrosoli. Francisco Méndez Sanhueza. Agencia de Aduanas Jorge Stein. Aquacultivos. Francisco Medina. Francisco Guerrero Novoa. Kotter (2004. 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. Juan Bravo C. • Universidad de Chile. una vez más fue muy valiosa en todo tipo de apoyo logístico. El diseño de la portada es obra de Juan Pablo Bravo Zamora. mi hermana. . • Universidad Santa María en Ecuador. por ejemplo. en la forma de múltiples seminarios de un día de divulgación de estos temas. su cercanía ha sido un estímulo en la realización de esta obra. • Revista Gerencia. Un reconocimiento especial a mi esposa e hijos. el magíster en gestión y tecnología. los cursos acerca de procesos y de tecnología. La colaboración de Silvia.MODELANDO UNA SOLUCIÓN DE SOFTWARE 23 En cuanto al ámbito académico. A todos agradezco sus aportes y libero de cualquier responsabilidad por algún error en el texto. • Pontificia Universidad Católica de Chile. El diploma realizado por varios años en análisis y diseño de sistemas. destacar actividades abiertas de capacitación. a través de: • Universidad Técnica Federico Santa María en Viña del Mar y Santiago.

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

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

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

procesos. Son los mapas de necesidades. Alinear con la estrategia 2.MODELANDO UNA SOLUCIÓN DE SOFTWARE 27 Mapas para la visión de conjunto Conviene observar estos cinco mapas que deberían existir en la organización previo al desarrollo de una aplicación específica. Pago tardío a Proveedores 2. Incluir como plan de acción de RS Mapa de proyectos 10p Tiempo Problemas detectados: 1. proyectos. retroalimentación y sistemas. Bienestar Productividad Calidad Costo Responsabilidad Social 2p Soluciones propuestas: 1. 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 . 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conviene conocerlos ya sea porque son experiencias que es bueno replicar o porque hubo sucesos que queremos evitar.MODELANDO UNA SOLUCIÓN DE SOFTWARE 45 d) Mapa de Retroalimentación Lleva registros de eventos enriquecedores al finalizar los proyectos. Mapa de retroalimentación para replicar o evitar Es fundamental que el mapa este a la vista y siempre actualizado. por eso es que se promueve que este mapa y los demás estén pegados en las paredes donde sean visibles y su rica información sirva. No sirve. . 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. Así se puede capitalizar la retroalimentación. 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. esa información debe estar viva. Hay lugares donde se hace retroalimentación en un informe de fin de proyecto que luego queda archivado y nadie lo lee. En la figura 1-5 se usó la forma de un mapa mental.

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

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

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

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

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

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

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

Por ejemplo. 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. 14 Es la primera clave de la implantación de método de la sección 1. es decir. a) Área de metodología o UTP En el área de metodología trabajan los responsables del método. También se le llama PMO (Project Management Office).2. quienes lo actualizarán y difundirán. “hacer carne”. llevar al cuerpo. para cada mapa se indica el área más adecuada: • Necesidades: estudios • Proyectos: desarrollo • Procesos: gestión de procesos • Retroalimentación: estudios y/o desarrollo • Sistemas: sistemas Se presenta a continuación una breve descripción de cada área. Estructura para la gestión de proyectos La buena gestión de proyectos también tiene que ver con una serie de instancias de estructura organizacional o funciones. se incorpora aquí una labor más bien operativa. es decir. Algunas de estas instancias son: • Área de metodología o UTP • Área de estudios • Área de desarrollo • Comité de Proyectos (CP) • Áreas relacionadas Generalmente la responsabilidad de mantener los mapas globales14 recae en algunas de estas áreas. sumar a la estructura organizacional.MODELANDO UNA SOLUCIÓN DE SOFTWARE 53 3. Esto es lo que se denomina “incorporar” a la organización. .

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

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

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

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

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

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

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

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

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

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

flujos tensados. por ejemplo: cadena de valor. costos. Kanban. Algunas actividades de esta etapa son: • Conformar el equipo de trabajo • Revisar el problema • Describir el ámbito de trabajo • Plantear un ideal de solución • Plantear alternativas con amplia libertad • Definir un gran desafío • Identificar restricciones de la solución • Seleccionar alternativas y objetivos generales • Evaluar cada alternativa • Evaluar las alternativas en forma comparativa • Decidir la opción y los objetivos específicos • Elaborar el plan de proyecto Algunas técnicas en la etapa de factibilidad: • Evaluación financiera • Técnicas de evaluación de programas y proyectos • Análisis costo-beneficio para la evaluación social de proyectos24 • Idealización y creatividad • Planificación de proyectos También se debe revisar cada práctica transversal para incluir en el plan de proyecto. logística. En el libro Responsabilidad Social se profundiza en este tipo de análisis. salir del pensamiento dicotómico.64 JUAN BRAVO C. comunicación. nuevas reglas del juego. just-in-time. Por otra parte. . existe un amplio abanico de técnicas23 que pueden ayudar a generar soluciones. Getz y Robinson agregan (2005. riesgos. producción flexible. plazos. completitud. armonizar las economías de escala con otras opciones. Recuérdese que cada una aborda aspectos fundamentales de los proyectos: incorporación del cliente y de los proveedores. un sistema de gestión de iniciativas y muchas otras. p. son 28 en total. 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”. costo objetivo. 23 24 Detalladas en el libro Gestión de Procesos.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

En algunas experiencias incluso se designa un gerente de continuidad. 22. Cuidar la solución anterior Cuidar la solución anterior significa que al mismo tiempo que se trabaja en la nueva solución. La idea de fondo es evitar la contingencia. redes. 24. se aplica alguna forma de continuidad de lo existente. comedores y otros. espacio físico. al mismo tiempo que otro gerente se encarga del proyecto de cambio. • Agilizar la restauración de los servicios y reiniciar operaciones críticas en un tiempo breve. Plan de recursos físicos del proyecto El plan de recursos físicos se refiere a disponer oportunamente de los elementos que se requerirán en el proyecto: equipos computacionales.MODELANDO UNA SOLUCIÓN DE SOFTWARE 95 Es necesario que exista algún nivel de control centralizado y que el equipo de dirección del proyecto tenga la información inmediata del avance. escritorios. más allá de sólo tener planes de contingencia. Continuidad operacional Se refiere a incorporar en el proyecto los mecanismos que permitan la continuidad de las operaciones cuando el proyecto esté en funcionamiento. 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. • Minimizar pérdidas financieras. • 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. baños. Incluso se sigue realizando mejora continua de la antigua solución. La continuidad operacional está relacionada con la seguridad de las operaciones y la calidad de la información. . 23. licencias. prevenir. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

121

cirán cambios y realizarán las adaptaciones necesarias para atender cada situación particular. Definiciones estratégicas del área informática Organización de la función informática Plan de equipamiento Administrador de las bases de datos de la empresa Métodos de la tecnología de información Herramientas de productividad para usuarios y especialistas Acuerdos de normalización en múltiples aspectos Grado de participación de los usuarios Identificación de los procesos del negocio de la organización, principales y secundarios Conjuntos de datos que se manejan en cada proceso Matriz con todos los procesos y conjuntos de datos Modelo de datos conceptual de la organización Realidad actual De las definiciones estratégicas Aplicaciones en funcionamiento Conjuntos de datos ya formados Proyectos en desarrollo Evaluación Participación de los usuarios Factores (negociaciones) Importancia del proceso Grado de desarrollo previo Tamaño Dimensionamiento Requerimientos de personas Capacitación Hardware Software Infraestructura Comunicaciones Estrategia informática Prioridades de desarrollo Modelo de los conjuntos de datos y sus relaciones Definiciones estratégicas reformuladas

122

JUAN BRAVO C.

Plan de implementación Perfeccionamiento En conclusión • La TI por si sola no aporta valor, está al servicio del propósito de la organización. La proporción en que se aplica será mayor si se acerca al corazón del negocio • La buena comunicación con los socios tecnológicos es central • La TI pasa a través de integrantes de la organización quienes deben querer usarla y estar capacitados para ello La secuencia Fortalezas (FO), Factores de diferenciación (FD) y Ventajas competitivas (VC) es importante.

FO

FD

VC

El principal esfuerzo en TI debe estar centrado en las fortalezas del negocio, así se obtendrá un factor diferenciador que luego podría llegar a ser una ventaja competitiva. En las debilidades es preferible no desgastarse, mejor externalizar o aplicar la solución tipo commodity. Se sugiere revisar el concepto de cadena de valor40 de Michael Porter, el cual se centra en el mismo mensaje: diseñar una estrategia para fortalecer los valores que percibe el cliente.

40

Ver libro Gestión de procesos.

MODELANDO UNA SOLUCIÓN DE SOFTWARE

123

2.3. SISTEMA DE PRODUCTIVIDAD EN EL DESARROLLO DE SOFTWARE
Una pregunta clave es: ¿cómo aumentar la productividad41 en el desarrollo de software? Desde la visión sistémica ya sabemos que no existe el factor de productividad (también conocido como bala de plata o panacea), ni siquiera la incorporación aislada de varios factores. Lo que realmente funciona es un sistema de productividad42. El sistema de productividad se podría definir como la mejor combinación de todos los elementos del conjunto de factores de productividad. No se trata de tener lo mejor de cada factor, sino la combinación que resulte más apropiada a la realidad de la organización. Como todo sistema viable, el sistema de productividad es mucho más que la suma aislada de los factores y necesariamente considera un acuerdo armonioso entre los integrantes de la organización para su implementación. Ya sabemos que es vital aumentar la productividad del desarrollo de software. Con la aplicación del sistema de productividad, el desarrollo de aplicaciones puede elevar su rendimiento en una proporción estimada de 1:10 (aumento de 10 veces). Esto es vital, porque más allá de las beneficiosas implicancias económicas de corto plazo, disponer a tiempo de los sistemas computacionales es un factor diferenciador para el éxito del negocio. Obviamente, esto no es gratis, pues exige una inversión que debería ser asumida como un proyecto, comparando beneficios versus costos, incluyendo el costo vigente de la falta de información para la toma de decisiones. La inversión, además de dinero, incluye tiempo, disposición y esfuerzo de los interesados. Es más, si la organización como conjunto no está dispuesta a comprometerse, no vale la pena el esfuerzo. También se puede justificar el sistema de productividad desde el punto de vista sistémico: un sistema rico en variedad, como es la producción de software, sólo puede ser modificado por una solución con variedad equivalente. Esa

Productividad, en simple, es producir más con menos recursos. Es la base de la creación de riqueza, en el libro Gestión de procesos se profundiza en este concepto. 42 Se refiere específicamente al desarrollo de software, este sistema de productividad se puede ver como un subconjunto del método GSP presentado en el capítulo 1. Por lo mismo, no se incluyó aquí la vital orientación al cliente.

41

124

JUAN BRAVO C.

es la variedad que aporta el sistema de productividad. En contraposición a soluciones con escasa variedad, por ejemplo, cuando sólo abordan uno o dos factores, como el equipamiento o el software. Se describen a continuación los principales factores detectados, con una advertencia: el éxito del sistema de productividad es la armonía del conjunto, lo cual es mucho más importante que tomar lo mejor del mercado para cada factor. Por ejemplo, tal vez no elijamos la herramienta más moderna, pero nuestra selección se lleva bien con el hardware que empleamos, es fácil de aprender y conocida en el medio (podría ser un lenguaje de programación, una herramienta cliente–servidor o un administrador de bases de datos). Es que no hay “balas de plata” (las que matan al hombre lobo). Alfredo Weitzenfeld se refiere a ellas (2005, p. 17): “Un legado importante de Fred Brooks fue el célebre aunque controversial artículo No Silver Bullet, en el cual se discuten los desafíos más importantes de la ingeniería de software. En este artículo Brooks deja un desafío a las nuevas generaciones: Según miramos al horizonte de una década, no vemos ninguna bala de plata. No existe un solo desarrollo, en la tecnología o técnica de administración, que por si mismo prometa incluso una mejora de un orden de magnitud en productividad, confiabilidad, simplicidad, dentro de una década”. Aunque este artículo fue escrito en los años 70, mantiene su actualidad, nada hay en el horizonte que prometa cambios radicales en las variables críticas del desarrollo de software. Hoy como ayer, sólo el trabajo arduo y metodológico hace una diferencia. Los factores son: 1. Método 2. Técnicas 3. Herramientas de software 4. Hardware 5. Incorporación del usuario 6. Habilidad del desarrollador 7. Normalización externa 8. Factores de contexto

1. Método
Se requiere método para toda la organización y que aborde el ciclo de vida completo de cualquier proyecto, no sólo su parte tecnológica. Por supuesto, el

MODELANDO UNA SOLUCIÓN DE SOFTWARE

125

énfasis en aspectos de calidad, control de riesgos e incorporación de las competencias de las personas resulta central. Es lo que vimos en el capítulo 1.

2. Técnicas
Las técnicas debieran ser modernas, simples, fáciles de aprender y conocidas por todos, tanto para el ciclo completo de desarrollo como al interior de cada etapa. Por ejemplo, orientación a objetos y UML. Las técnicas tienen que llevar a una amplia portabilidad del software producido. Este concepto se aplica generalmente a implementar la aplicación en diferentes plataformas, aunque también se refiere a la portabilidad del diseño. Las técnicas también deben ayudar a facilitar el perfeccionamiento de las aplicaciones, para que: • Puedan utilizarse en otras unidades de la misma organización. • Puedan utilizarse como parte de otra aplicación. • Sean independientes de sus desarrolladores. • Sean fácil de ampliar, explicar y de utilizar por otras personas. En otras palabras, incorporando un amplia portabilidad, en la forma de componentes, como en la técnica de orientación a objetos. Directamente relacionados con las técnicas se encuentran los procedimientos, indispensables para enlazar diferentes técnicas en distintas etapas del ciclo de vida de un sistema de información, regular la participación de especialistas y usuarios o normar el uso de una u otra herramienta según el tipo de problema. Por ejemplo, como el enlace que veremos en el capítulo 6 entre las actividades del flujograma de información y los casos de uso de UML.

3. Herramientas de software
Los métodos y técnicas tienen que estar apoyados por buenas herramientas, con especial énfasis en la amistosidad. Por supuesto, la incorporación de este tipo de software debiera ir acompañada del correspondiente entrenamiento, no sólo en el uso del producto sino también en la técnica que le acompaña, esa tecnología que viene junto con la herramienta. Es indispensable el alineamiento entre los métodos adoptados por la organización y las herramientas de apoyo al desarrollo de software (CASE).

126

JUAN BRAVO C.

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

4. Hardware
Mucho se habla sobre el extraordinario avance en el rendimiento de los computadores y el acierto de Gordon E. Moore con la conocida ley que lleva su apellido, dice que cada 18 meses se duplica la capacidad de los computadores, originalmente aplicada a los grandes equipos, se popularizó para los PC’s43. Es innecesario profundizar en este aspecto, aunque sí puntualizar la imperiosa necesidad de aprovechar este potencial para aumentar la productividad. Especial mención requiere la revolución provocada con la introducción de los PC’s, cada vez más poderosos, al punto de hacerse comparables con el rendimiento de los mainframes (equipos grandes). Incluso surgió una tendencia, llamada Downsizing44, orientada a la reducción de tamaño del equipamiento computacional y en general de toda la infraestructura. En el caso de los equipos, típicamente se pasa desde mainframes a microcomputadores que tienen el rol de servidores en una red. En todo caso, se aprecia que en las grandes instalaciones predominan los equipos tipo mainframes, especializados en el manejo de alto volumen de transacciones. Una solución que está siendo cada vez más utilizada es disponer de “estaciones de trabajo” con PC´s poderosos donde los especialistas puedan desarrollar y luego llevar el producto de software al computador central. Es destacable que los avances del hardware han permitido el uso masivo de software más poderoso. Y viceversa, porque nuevo software, como los juegos para niños, requieren hardware cada vez más poderoso. El respaldo y la solidez del proveedor fueron y siguen siendo fundamentales.

Sorprende al autor el rápido avance, en 1980 estaba a cargo de una instalación con equipamiento por valor de más de un millón de dólares. Hoy, a fines de la primera década del nuevo milenio, esa misma instalación (512 KB de memoria, 200 MB en disco, 6 terminales), costaría alrededor de una milésima parte y tendría 100 veces más capacidad. 44 En el punto 3, Nuevas formas de las organización informática, de la sección 2.2, Planificación en Informática, se describió este concepto.

43

MODELANDO UNA SOLUCIÓN DE SOFTWARE

127

5. Incorporación del usuario
Es indispensable que trabajen en conjunto el usuario y el especialista. Resulta evidente la necesidad de preparación del especialista, sin embargo, también es vital la formación del usuario en la tecnología de información. No obstante, la dificultad no está en el grado de capacitación, sino en algo mucho más profundo… la adaptación al cambio. A veces el usuario no sabe exactamente lo que quiere, aún así, eso no es motivo para un trabajo anárquico. Es posible hacer prototipos en las etapas de análisis y de diseño aunque sea solamente para aclarar sus requerimientos. Usuarios entrenados en la tecnología de información, particularmente métodos y herramientas amistosas, pueden desarrollar sus aplicaciones más sencillas; además, estarán en condiciones de participar activamente en el desarrollo de aplicaciones más grandes en conjunto con el especialista. Aquí influye un elemento conceptual de primera importancia: la aplicación le pertenece al usuario, él debiera ser el gestor, no los especialistas. La construcción de un sistema de información no significa una “imposición de cambios” al usuario, sino que es una respuesta a su requerimiento bien planteado. El es quien debe hacer una buena gestión de la demanda. El grado de éxito de la aplicación dependerá en gran medida de la comprensión que tiene el usuario de su propia necesidad45 y de la calidad de la información entregada por él. La introducción del usuario en el desarrollo de software implica que él debe aprender a dimensionar y analizar su problema, lo cual puede lograrse en el contexto de un amplio esfuerzo de educación, tal como vimos en la sección anterior. Se puede hacer una similitud con la evolución de los automóviles desde principios del siglo XX. Cuando recién aparecieron, se pensaba que era difícil su masificación, porque cada automóvil requería un chofer-mecánico. Sin embargo, los automóviles se simplificaron, la infraestructura de apoyo mejoró (garajes, red vial, etc…) y los usuarios aprendieron a conducir y a realizar el nivel básico de mantenimiento (cambio de neumático o revisión de niveles).

45

Se presenta ante un Juez el infractor de una norma de tránsito, le dice: “señor Juez, es la primera vez que tengo una infracción, ¿puede anularla?” El Juez señala el computador que tiene en su escritorio (recién instalado, todavía sin funcionar) y le dice: “Si ingreso su identificación, el sistema me dirá si usted dice la verdad, ¿lo hago?” El infractor contesta: “Prefiero pagar”. El Juez tiene clara su necesidad.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

En la figura 2-7 podemos apreciar un ejemplo: el diagrama de contexto de un sistema de control de stock. nivelado. y la mini especificación.F. 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. veremos cada una de ellas. las cuales proveen o reciben información del sistema.). Las principales herramientas del diseño estructurado son: Diagrama de Flujo de Datos (D. Ejemplo de diagrama de contexto En la figura 2-7 el círculo señala el sistema y los rectángulos indican las entidades con las cuales se relaciona. Las entidades —también llamadas fuentes— son empresas. perdiéndose los supuestos beneficios del enfoque51. hasta llegar al nivel elemental o atómico.) y mini especificaciones en pseudolenguaje.D. La ubicación está dada por la relación que se produce (y que debe existir) entre las entidades que le solicitarán o le proveerán de datos o información. 51 .D. Esta herramienta se divide en dos partes: diagrama de contexto y D. más el D. así como la orientación a objetos no obliga a emplear programación orientada al objeto.152 JUAN BRAVO C.D. Los flujos de información se muestran con Una experiencia interesante ha sido que el diseño estructurado no obliga a tener programación estructurada.F. Diccionario de Datos (D. después de un tiempo ni siquiera el programador que lo construyó creía en eso y efectuaba revisiones detalladas para efectos de la mantención.D. departamentos o personas relacionadas con el sistema. 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. es de por sí casi una utopía.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Los mensajes 4 y 5 sobre inventarios se refieren a sumar o restar el saldo del artículo. respectivamente. 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. el mensaje 1 —que tiene por misión solicitar agregar un nuevo documento a la clase transacciones— se envió sólo al encabezado. 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. 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. Encabezado de transacción • Nº documento Fecha Rut persona 1 Agregar 2 Consultar 3 Imprimir C/E Mensaje 1 Personas Ingreso de transacción Encabezado. detalle y totales según formato 1 Aceptar datos 2 Cuadrar totales C/E • Rut Nombre Dirección Teléfono 1 Agregar 2 Consultar 3 Imprimir Detalle de transacción • Nº documento • Código artículo Costo Cantidad 1 Cálculo total Productos C/E Mensajes 4 y 5 • Código artículo Tipo artículo Descripción Último costo Saldo 1 Agregar 2 Consultar 3 Imprimir 4 Sumar saldo 5 Restar saldo Figura 5-18.278 JUAN BRAVO C. . con lo cual también se agregará automáticamente en el detalle (a través de un mensaje que enviará el encabezado al detalle).

En la figura 5-19 se muestra la visión interna de la clase productos. 4. la lista podría incluir: a) Condición de existencia b) Agregar un registro c) Eliminar un registro d) Modificar cualquier campo del registro e) Consultar todo f) Imprimir todo g) Obtener copia de seguridad total h) Obtener copia de seguridad con las últimas modificaciones i) Estadísticas de uso j) Eliminación de ocurrencias sin movimiento k) Respaldo automático l) Reconstrucción automática m) Inicialización n) Auditoría o) Restricciones de acceso La funcionalidad generalizada ¿puede ser una norma del medio? Se está trabajando en la modularidad y se busca intercambiar y comercializar clases. es una excelente opción darse normas de reutilización al interior de la organización o en pequeñas agrupaciones de empresas. Nótese que la tabla de objetos consta solamente de una ocurrencia. todavía está en proceso de consolidarse. Visión interna En la visión interna se describen minuciosamente cada uno de los tres componentes de la clase —características propias.MODELANDO UNA SOLUCIÓN DE SOFTWARE 279 Por ejemplo. atributos y funciones— y la tabla de objetos. sin embargo. . con los mismos elementos que la clase. Mientras tanto. incluida en la figura 5-18.

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

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

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

pensar que “yo soy el objeto” y comenzar a hacernos preguntas. entre todos. 73 . Veremos: 1. En un grupo de trabajo cada uno de los participantes puede tomar el rol de un objeto para lograr simular. tal como en el enfoque sistémico. especialmente en cuanto a respetar normas internas y con el medio73. mejor aún. Personalización del objeto 2. Construcción de un modelo de objetos 1. 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. INCORPORACIÓN DE LA TECNOLOGÍA DE OBJETOS Para una incorporación exitosa de la tecnología de objetos en la organización.MODELANDO UNA SOLUCIÓN DE SOFTWARE 283 5. Personalización del objeto La forma ideal de trabajo en la orientación a objetos es entre pequeños equipos (teams) donde participen usuarios y profesionales de la informática. por ejemplo: ¿Quién soy? ¿Para qué sirvo? ¿Qué atributos tengo? ¿Qué funciones cumplo? ¿Cuándo realizo esa función? ¿Cuál es el valor agregado que aporto? ¿Qué información necesito de otros objetos? ¿Qué información necesito para cumplir una función? A través de las cuales se va aclarando el entorno y luego el contenido del objeto. Reutilización de código 3.6. Esta es una excelente técnica para refinar la comunicación entre los objetos… y entre las personas. el funcionamiento del sistema. Como técnica de definición es muy útil “personalizar” el objeto.

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

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

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

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

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

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

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

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

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

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

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

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

297

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

C
-

Encargado Recepción Razón Social Proveedor

D F

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

A

B

E

G
Ciudad M

H
Fax

I

J

Fono

K N
Precio

L O
Valor Neto

Guía de Despacho de Proveedor Nº

Fecha G/ D. Proveedor

Nº de O/C.

L.

Código

Descripción

Cantidad

LL

P

Q

R

S

T

Cerrada Anulada

W Y

Cerrar X Anular Z

XX
Salir

V
Grabar Total acumulado

U

Figura 6-5. Ejemplo de Interfaz visual detallada

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

298

JUAN BRAVO C.

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

Líneas de la O/C

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

299

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

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

contiene existe en * 1

Proveedores Rut Nombre

Líneas de la O/C Unidades Precio

contiene existe en * 1

Productos ...

existe en * almacena 1 Bodega ...

Figura 6-7. Ejemplo de modelo conceptual con atributos

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

300

JUAN BRAVO C.

Administrativo

Sistema

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

Figura 6-8. Ejemplo de diagrama de secuencia

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

301

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

Caso de uso Ingresar O/C

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

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

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

302

JUAN BRAVO C.

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

Figura 6-10. Ejemplo de diagrama de estado

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

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

MODELANDO UNA SOLUCIÓN DE SOFTWARE

303

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.MODELANDO UNA SOLUCIÓN DE SOFTWARE 345 En el desarrollo en espiral cada vuelta o ciclo es un pequeño “desarrollo en cascada”. aunque para un número relativamente pequeño del total de requerimientos.

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

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

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

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

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

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

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

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

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

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

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

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). 3) Campo E : RUT de Proveedor no registrado (RUT no existe). Comunicarse con Administrador. Comunicarse con Administrador. Comunicarse con Departamento de Compras. L. Indicar error. 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: . 4) Campo C : Encargado de Recepción no registrado (Código no existe). 5) Campo O : Nº de Orden de Compra no existe. Proveedor Nº de O/C. Comunicarse con Administrador.MODELANDO UNA SOLUCIÓN DE SOFTWARE 357 Caso de Uso: (Expandido) Crear Guía Interna de Recepción por Compra (Productos con registro persistente) (Base Craig Larman) Interfaz de Entrada Guía Interna de Recepción por Compra Código Enc. 2) Campo M : Nº de Guía ya existe para el RUT del Proveedor. rechazar. . 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. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful