Modelando Software

2

JUAN BRAVO C.

Estimado lector: Hemos visto cmo este libro agrega valor para la humanidad a travs del conocimiento que aporta, por lo tanto, con mucho agrado empleo tambin este medio digital. Esta es una versin completa y actualizada del libro en 2009, sin costo durante este ao como forma de contribuir en la solucin de la crisis que nos afecta a nivel mundial. La serie de libros aporta motivacin, conceptos, tcnicas 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 Evolucin Centro de Estudios Avanzados www.evolucion.cl PD1. Pueden bajar presentaciones de apoyo en Modelos de la Gestin de Procesos y la revista RS, sin costo ni claves.

MODELANDO UNA SOLUCIN DE SOFTWARE

3

Modelando una Solucin de Software

Juan Bravo Carrasco

4 JUAN BRAVO CARRASCO, 2008

JUAN BRAVO C.

Inscripcin 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, [email protected] Edicin revisada y actualizada en mayo de 2009

Valor versin digital: $ 5.000 (Chile) US$ 7 (sin costo en 2009) Puede complementar bajando los Modelos de la Gestin de Procesos y la Revista de Responsabilidad social (www.evolucion.cl).

EDITORIAL EVOLUCIN S.A. www.evolucion.cl, [email protected] Alameda 171 Of. 307, Fono 6389717

Santiago de Chile


5

A todos los profesionales de la tecnologa que se esfuerzan cada da por trabajar metodolgica y ticamente.

6

JUAN BRAVO C.

CONTENIDOCONTENIDO ............................................................................................................................... 6 TABLA DE ILUSTRACIONES ...................................................................................................... 12 PRLOGO ................................................................................................................................. 14 AGRADECIMIENTOS ................................................................................................................. 22 INTRODUCCIN ........................................................................................................................ 24 Contenido del libro .......................................................................................................... 25 Sntesis de modelos de una solucin de software ............................................................ 26 CAPTULO 1. MTODO PARA LA GESTIN DE PROYECTOS............................... 34 1.1. TRABAJAR METODOLGICAMENTE................................................................................... 36 1. Qu es mtodo?.......................................................................................................... 36 2. Las mejores prcticas .................................................................................................. 37 3. Fundamento conceptual: la visin sistmica ............................................................... 37 4. Mtodo GSP ................................................................................................................. 39 1.2. CLAVES DE LA IMPLANTACIN DE MTODO....................................................................... 41 Clave 1. Cinco mapas globales para la visin de conjunto ............................................. 41 Clave 2. Mnimo indispensable ........................................................................................ 47 Clave 3. Participacin de todos los actores .................................................................... 47 Clave 4. Circularidad ...................................................................................................... 48 1.3. ADAPTACIN Y PROFESIONALISMO ................................................................................... 49 1. Adhesin a estndares y normas de calidad ................................................................ 49 2. Actualizacin y adaptabilidad del mtodo................................................................... 50 3. Estructura para la gestin de proyectos ...................................................................... 53 4. Aportes del PMI ........................................................................................................... 55 5. tica y visin global del profesional ........................................................................... 56 1.4. ETAPAS GENRICAS .......................................................................................................... 58 1. Concepcin .................................................................................................................. 60 2. Factibilidad ................................................................................................................. 62 3. Anlisis ........................................................................................................................ 65 4. Diseo .......................................................................................................................... 71 5. Implementacin............................................................................................................ 73 6. Despliegue ................................................................................................................... 76 7. Operacin .................................................................................................................... 78 1.5. PRCTICAS TRANSVERSALES ............................................................................................ 82 1. Direccin del proyecto................................................................................................. 84 2. Plan de la etapa ........................................................................................................... 86 3. Exposicin de los planes .............................................................................................. 87 4. Retroalimentacin........................................................................................................ 87 5. El equipo de trabajo .................................................................................................... 87 6. Entrevistas ................................................................................................................... 88 7. Comunicacin .............................................................................................................. 89 8. Informes ....................................................................................................................... 89 9. Tcnicas ....................................................................................................................... 89


7

10. Herramientas de apoyo .............................................................................................. 90 11. Trazabilidad............................................................................................................... 90 12. Quick Wins ................................................................................................................. 91 13. Costos y duracin ...................................................................................................... 91 14. Gestin de riesgos...................................................................................................... 91 15. Gestin de la calidad ................................................................................................. 92 16. Responsabilidad social .............................................................................................. 92 17. Insercin .................................................................................................................... 93 18. Orientacin al cliente ................................................................................................ 93 19. Sensibilizacin ........................................................................................................... 94 20. Capacitacin .............................................................................................................. 94 21. Seguimiento ............................................................................................................... 94 22. Cuidar la solucin anterior ....................................................................................... 95 23. Continuidad operacional ........................................................................................... 95 24. Plan de recursos fsicos del proyecto ........................................................................ 95 25. Kill time ..................................................................................................................... 96 26. Control de cambios .................................................................................................... 96 27. Gestin del cambio .................................................................................................... 96 28. Gestin de proveedores ............................................................................................. 97 CAPTULO 2. INGENIERA DE SOFTWARE ................................................................ 98 2.1. ALCANCE DE LA INGENIERA DE SOFTWARE ................................................................... 101 1. Definiciones de la ingeniera de software.................................................................. 101 2. Desarrollar un buen software o solucionar el problema? ....................................... 102 3. Esfuerzo de educacin ............................................................................................... 104 4. Tecnologa de informacin ........................................................................................ 106 2.2. PLANIFICACIN EN INFORMTICA ................................................................................... 108 1. Algunas directrices sobre la tecnologa de informacin ........................................... 109 2. Reconversin de la informtica ................................................................................. 111 3. Nuevas formas de organizacin informtica ............................................................. 113 4. Mtodo de planificacin estratgica en informtica ................................................. 116 5. Cambio cultural de la organizacin .......................................................................... 118 6. Resumen de la planificacin estratgica en informtica ........................................... 120 2.3. SISTEMA DE PRODUCTIVIDAD EN EL DESARROLLO DE SOFTWARE .................................. 123 1. Mtodo ....................................................................................................................... 124 2. Tcnicas ..................................................................................................................... 125 3. Herramientas de software .......................................................................................... 125 4. Hardware ................................................................................................................... 126 5. Incorporacin del usuario ......................................................................................... 127 6. Habilidad del desarrollador ...................................................................................... 130 7. Normalizacin 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

8

JUAN BRAVO C.

5. Pruebas del software por el programador................................................................. 141 6. Mantenimiento de la solucin de software ................................................................ 142 2.5. MTODOS PARA LA PRODUCCIN DE SOFTWARE ............................................................ 145 1. Ciclo de vida clsico .................................................................................................. 145 2. Tcnica de prototipos ................................................................................................ 147 3. Diseo estructurado................................................................................................... 151 4. Programacin extrema (XP) ...................................................................................... 155 2.6. APOYO DEL DISEO EN LA EXPLOTACIN DEL SISTEMA ................................................. 157 1. Operacin del sistema ............................................................................................... 157 2. Auditora computacional ........................................................................................... 159 3. Contribucin del diseo a la proteccin de la informacin ...................................... 162 4. Seguridad de la informacin ..................................................................................... 163 5. Integridad de la informacin ..................................................................................... 164 6. Recuperacin de la informacin ................................................................................ 165 2.7. DISEO DE INTERFACES .................................................................................................. 166 1. Directrices para el diseo de interfaces humanas ..................................................... 166 2. Diseo de niveles de mens ....................................................................................... 167 3. Leyes para lograr una mejor interfaz humana .......................................................... 168 2.8. NORMAS Y ESTNDARES APLICADOS A LOS MODELOS TI .............................................. 170 1. Corba ......................................................................................................................... 171 2. MDA........................................................................................................................... 171 3. CMM .......................................................................................................................... 172 4. ISO 9000 .................................................................................................................... 173 5. Tick IT ........................................................................................................................ 173 6. ITIL ............................................................................................................................ 174 7. SOA ............................................................................................................................ 175 CAPTULO 3. TEORA DE MODELOS APLICADA ................................................... 176 3.1. MARCO TERICO DE LOS MODELOS ............................................................................... 178 1. Concepto de caja negra ............................................................................................. 178 2. Concepto de homomorfismo ...................................................................................... 179 3.2. MODOS DE PROCESAMIENTO .......................................................................................... 182 1. Batch-Interactivo ....................................................................................................... 183 2. En lnea ...................................................................................................................... 183 3. En tiempo real............................................................................................................ 184 3.3. ONCE CLAVES DE LOS MODELOS COMPUTACIONALES.................................................... 185 1. Fluidez ....................................................................................................................... 185 2. Intuicin ..................................................................................................................... 186 3. Simplicidad ................................................................................................................ 187 4. Orientacin al cliente ................................................................................................ 187 5. Independencia de la implementacin tecnolgica ..................................................... 188 6. Iteracin..................................................................................................................... 188 7. Totalidad .................................................................................................................... 189 8. Generalizacin ........................................................................................................... 189 9. Desarrollo incremental .............................................................................................. 190 10. Transacciones presentes .......................................................................................... 190 11. Armona entre el modelo y la realidad .................................................................... 191


9

3.4. MODELAMIENTO DE FUNCIONES ..................................................................................... 193 1. Descomposicin funcional ......................................................................................... 193 2. Reglas del negocio ..................................................................................................... 195 3. Funciones asociadas a una entidad ........................................................................... 196 4. Relaciones funcionales entre dos entidades .............................................................. 198 3.5. FUNDAMENTOS DEL MODELAMIENTO DE FUNCIONES ..................................................... 201 1. Resolucin de problemas simples .............................................................................. 201 2. Modelar bien a la primera ......................................................................................... 202 3. Concepto de mquinas abstractas ............................................................................. 202 3.6. CRITERIO CURSO NORMAL DE LOS EVENTOS .................................................................. 205 1. Aplicado al flujograma de informacin ..................................................................... 205 2. Relacin del FI con la tcnica UML .......................................................................... 212 CAPTULO 4. MODELAMIENTO DE DATOS ............................................................. 214 4.1. DEFINICIONES SOBRE EL MODELO DE DATOS ................................................................. 216 1. Representacin de una entidad .................................................................................. 216 2. Relaciones propias (RP) ............................................................................................ 217 3. Caractersticas estticas y funcionales de campos .................................................... 218 4. Tipos de entidades ..................................................................................................... 220 5. Relaciones entre entidades ........................................................................................ 222 4.2. CRITERIOS BSICOS DE NORMALIZACIN DE DATOS ...................................................... 227 1. Eliminacin de grupos repetitivos ............................................................................. 228 2. Eliminacin de dependencias parciales..................................................................... 230 3. Tabla de traduccin ................................................................................................... 233 4.3. ENFOQUE DE BASES DE DATOS ....................................................................................... 235 1. Arquitectura de sistemas de bases de datos ............................................................... 235 2. Estructura relacional ................................................................................................. 236 3. Visin de bases de datos ............................................................................................ 238 4. Elementos del enfoque de bases de datos .................................................................. 240 CAPTULO 5. ORIENTACIN A OBJETOS ................................................................ 243 5.1. FUNDAMENTOS DE LA ORIENTACIN A OBJETOS ............................................................ 246 1. Mayor eficiencia ........................................................................................................ 247 2. Visin de los datos ..................................................................................................... 248 3. Visin histrica funcional .......................................................................................... 249 4. La orientacin a objetos ............................................................................................ 251 5. Incorporacin de nuevas tecnologas ........................................................................ 252 5.2. DEFINICIONES SOBRE ORIENTACIN A OBJETOS ............................................................. 255 1. Definiciones preliminares .......................................................................................... 255 2. Convenciones de diseo ............................................................................................. 257 3. Relacin de pertenencia ............................................................................................ 258 4. Condicin de existencia ............................................................................................. 259 5.3. CONCEPTOS DE LA ORIENTACIN A OBJETOS ................................................................. 261 1. Encapsulamiento........................................................................................................ 261 2. Clase .......................................................................................................................... 262 3. Objeto ........................................................................................................................ 263 4. Funcin ...................................................................................................................... 265

10

JUAN BRAVO C.

5. Identidad de instancias de objetos ............................................................................. 265 6. Mensaje ...................................................................................................................... 266 7. Independencia ............................................................................................................ 267 8. Enfoque sistmico ...................................................................................................... 268 5.4. PROCESO DE GENERALIZACIN ...................................................................................... 269 1. Obtencin de clases ................................................................................................... 269 2. Herencia .................................................................................................................... 272 5.5. FASES DE LA ORIENTACIN A OBJETOS........................................................................... 274 1. Modelamiento de la informacin ............................................................................... 274 2. Identificacin de clases.............................................................................................. 275 3. Visin externa ............................................................................................................ 276 4. Visin interna............................................................................................................. 279 5. Interfaz humana ......................................................................................................... 282 5.6. INCORPORACIN DE LA TECNOLOGA DE OBJETOS ......................................................... 283 1. Personalizacin del objeto......................................................................................... 283 2. Reutilizacin de cdigo.............................................................................................. 284 3. Construccin de un modelo de objetos ...................................................................... 285 CAPTULO 6. UNIFIED MODELING LANGUAGE (UML) ....................................... 287 6.1. MODELOS DE UML......................................................................................................... 290 1. Casos de uso .............................................................................................................. 291 2. Uso de herramientas .................................................................................................. 292 6.2. APLICACIN DE LOS MODELOS UML EN LA ETAPA DE ANLISIS .................................... 293 1. Diagrama de casos de uso ......................................................................................... 293 2. Caso de uso de alto nivel ........................................................................................... 295 3. Caso de uso expandido .............................................................................................. 295 4. Modelo conceptual..................................................................................................... 297 5. Diagrama de secuencia del sistema ........................................................................... 299 6. Visin dinmica del sistema ...................................................................................... 300 7. Diagrama de estado ................................................................................................... 301 8. Contratos ................................................................................................................... 302 6.3. APLICACIN DE LOS MODELOS UML EN LA ETAPA DE DISEO ...................................... 304 1. Diagrama de diseo de clases ................................................................................... 304 2. Diagrama de colaboracin ........................................................................................ 305 CAPTULO 7. HERRAMIENTAS DE LA TECNOLOGA DE INFORMACIN ..... 306 7.1. EVOLUCIN DE LOS LENGUAJES DE COMPUTADOR ......................................................... 309 1. Lenguajes de mquina ............................................................................................... 312 2. Lenguajes simblicos ................................................................................................. 312 3. Lenguajes de alto nivel .............................................................................................. 313 4. La cuarta generacin de lenguajes ............................................................................ 314 5. Las nuevas herramientas ........................................................................................... 315 7.2. HERRAMIENTAS DE USO ESPECFICO .............................................................................. 318 1. Herramientas integradas para automatizacin de oficinas ....................................... 319 2. Groupware ................................................................................................................. 319 3. Workflow .................................................................................................................... 320 7.3. UNA PIRMIDE DE SOLUCIONES ...................................................................................... 321


11

1. BI ............................................................................................................................... 321 2. Data Warehouse ........................................................................................................ 322 3. ERP ............................................................................................................................ 322 4. CRM ........................................................................................................................... 322 5. SRM ........................................................................................................................... 323 6. Motor de base de datos .............................................................................................. 323 7.4. HERRAMIENTAS DE APOYO PARA LA PRODUCCIN DE SOFTWARE ................................. 324 1. Herramientas tipo UPPER CASE .................................................................................. 326 2. Herramientas tipo LOWER CASE .................................................................................. 326 3. Herramientas de productividad en ambiente cliente servidor ................................... 329 CONCLUSIONES, ANEXOS Y BIBLIOGRAFA ......................................................... 331 CONCLUSIONES...................................................................................................................... 332 ANEXO 1. INTRODUCCIN A LA PLANIFICACIN ESTRATGICA.............................................. 333 Definicin del negocio ................................................................................................... 334 Destino de la organizacin ............................................................................................ 337 Factores crticos del xito .............................................................................................. 338 Mediciones ..................................................................................................................... 339 Sistemas de informacin gerenciales ............................................................................. 339 ANEXO 2. ALINEAR INTERESES .............................................................................................. 341 ANEXO 3. DESARROLLO EN ESPIRAL DEL PROYECTO ............................................................ 344 ANEXO 4. RELACIN CAUSAL................................................................................................ 346 ANEXO 5. MTODO DE ACCIN RPIDA (MAR) .................................................................... 348 ANEXO 6. AD/CYCLE Y RUP................................................................................................. 349 AD/Cycle ........................................................................................................................ 349 RUP ............................................................................................................................... 350 ANEXO 7. CASO COMPRAS CON UML ................................................................................... 351 BIBLIOGRAFA........................................................................................................................ 371

12

JUAN BRAVO C.

TABLA DE ILUSTRACIONESFigura 1-1. Totalidad del mtodo GSP 45 Figura 1-2. Mapa de necesidades con problemas y soluciones 47 Figura 1-3. Mapa de proyectos con relaciones para reubicar personas 48 Figura 1-4. Mapa de procesos de Fabrica de Electrodomsticos Linhogar 49 Figura 1-5. Mapa de retroalimentacin para replicar o evitar 50 Figura 1-6. Mapa de Sistemas Computacionales 51 Figura 1-7. Adaptacin del mtodo a cada tipo de proyecto 57 Figura 1-8. Esfuerzo estimado por etapa en el mtodo GSP 63 Figura 1-9. El modelo de negocios como una mesa 70 Figura 1-10. Mapa de procesos 72 Figura 1-11. Flujograma de informacin 74 Figura 1-12. Diseo general de la interfaz 76 Figura 1-13. Flujograma de informacin de control de cambios 85 Figura 2-1. Clasificacin de materias para perfeccionamiento en TI 111 Figura 2-2. Reconversin de programadores 119 Figura 2-3. Planificacin estratgica en informtica 122 Figura 2-4. Armona entre tcnica y comunicacin 137 Figura 2-5. Tabla comparativa para disminuir tiempo de respuesta 143 Figura 2-6. Ejemplo de grosor de la piel de las cras de osos 155 Figura 2-7. Ejemplo de diagrama de contexto 158 Figura 2-8. Estructura general de un D. F. D. 159 Figura 2-9. Ejemplo de D. F. D. nivelado 159 Figura 2-10. Definicin de mens como una clase 174 Figura 3-1. Concepto de caja negra 186 Figura 3-2. Modelo orientado al objetivo principal del sistema 187 Figura 3-3. Modelo orientado a los datos 188 Figura 3-4. Modelo orientado a las funciones del sistema 188 Figura 3-5. Modelo orientado al flujo de transacciones 189 Figura 3-6. Infinitas visiones de una realidad 189 Figura 3-7. Las tres dimensiones del diseo 190 Figura 3-8. Esquema de aproximaciones sucesivas 197 Figura 3-9. Concepto de descomposicin funcional 202 Figura 3-10. Ejemplo de relaciones funcionales 204 Figura 3-11. Esquema de una actualizacin 206 Figura 3-12. Esquema de una extraccin 207 Figura 3-13. Esquema de una seleccin 207 Figura 3-14. Esquema de una mantencin 208 Figura 3-15. Ejemplo de flujograma de informacin despacho inmediato 214 Figura 3-16. Diagrama de flujo computacional 217 Figura 3-17. Relacin del FI con la tcnica UML 220 Figura 4-1. Componentes de una entidad 226 Figura 4-2. Representacin grfica de una entidad 227 Figura 4-3. Eliminacin de grupo repetitivo usando nmero correlativo externo 238


13

Figura 4-4. Eliminacin de grupo repetitivo usando campo interno 239 Figura 4-5. Ejemplo de eliminacin de dependencias parciales 241 Figura 4-6. Arquitectura de bases de datos 245 Figura 4-7. Enfoque de bases de datos 250 Figura 5-1. Interacciones entre objetos 258 Figura 5-2. Esquema tradicional de diseo 260 Figura 5-3. Ejemplo de relaciones funcionales estructuradas 262 Figura 5-4. Ejemplo de orientacin a objetos 262 Figura 5-5. Grfico de incorporacin de nuevas tecnologas 263 Figura 5-6. Nomenclatura de la orientacin a objetos 266 Figura 5-7. Relacin de pertenencia 269 Figura 5-8. Representacin de un objeto 275 Figura 5-9. Ejemplo de estructura de un mensaje 277 Figura 5-10. Ejemplo de transacciones de sueldos con objetos 281 Figura 5-11. Ejemplo de definir una clase de transacciones de sueldos 281 Figura 5-12. Diagrama final de la generalizacin 282 Figura 5-13. Ejemplo de herencia en un sistema de ventas 283 Figura 5-14. Herencia mltiple 284 Figura 5-15. Modelo de datos simplificado de inventarios 286 Figura 5-16. Modelo de datos generalizado 287 Figura 5-17. Modelo funcional generalizado 287 Figura 5-18. Modelo funcional generalizado y detallado 289 Figura 5-19. Visin interna de la clase productos 291 Figura 5-20. Visin interna de la clase ingreso de transaccin 292 Figura 6-1. Ejemplo de un caso de uso de alto nivel 304 Figura 6-2. Ejemplo de un diagrama de casos de uso 307 Figura 6-3. 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 Interfaz visual detallada 310 Figura 6-6. Ejemplo de modelo conceptual sistema de compras 311 Figura 6-7. Ejemplo de modelo conceptual con atributos 312 Figura 6-8. Ejemplo de diagrama de secuencia 313 Figura 6-9. Ejemplo de diagrama visin dinmica del sistema 314 Figura 6-10. Ejemplo de diagrama de estado 315 Figura 6-11. Forma de un contrato por operacin 316 Figura 6-12. Ejemplo de contrato en dar OK ingreso lnea 316 Figura 6-13. Ejemplo de diagrama de diseo de clases 317 Figura 6-14. Ejemplo de diagrama de colaboracin 318 Figura 7-1. Clasificacin de lenguajes de computador 325 Figura 7-2. Una pirmide de soluciones 335 Figura 7-3. Herramientas Upper CASE y Lower CASE 340 Figura A1-1. Esquema de planificacin estratgica 349 Figura A4-1. Ejemplo de grfico de Ishikawa 362

14

JUAN BRAVO C.

PRLOGOLa presin irrazonable en la planificacin puede hacer que los desarrolladores pierdan el respeto a sus directivos. La mayora de las personas se sentirn contentas con los resultados de un proyecto planificado con precisin. McCONNELL (1997, pp. 237-8)

Este libro responde a una bsqueda de lograr mayor productividad en las organizaciones de Latinoamrica, en una intensa investigacin acerca de las mejores prcticas para modelar buenas soluciones de software. Lo destaco porque la serie de modelos de anlisis y diseo efectivamente debe dar solucin a una necesidad bien comprendida y evaluada, todo ello en el contexto de aplicar un mtodo completo para la gestin del proyecto. Es importante, no slo por el imperativo de trabajar con calidad sino que tambin como una forma de crear riqueza en toda la sociedad a travs de la transferencia de conocimiento. En su reconocido1 libro Globalizacin para el desarrollo, Goldin y Reinert sealan (2007, p. 344): La transferencia global de ideas en forma de tecnologa es uno de los procesos de desarrollo ms importantes. Durante dcadas, el abismo en aparente crecimiento entre los pases desarrollados y los pases en desarrollo ha despertado inquietudes acerca de una brecha tecnolgica. En aos recientes, los pases en desarrollo lderes como Brasil, China, India y Sudfrica han demostrado que pueden no slo salvarla, sino tambin ponerse en la delantera en algunas reas puntuales. Debido en parte a estos adelantos, los pases en desarrollo buscan entre s las ideas y la colaboracin. Hemos aprendido que se puede hacer lo que es debido para salir del subdesarrollo, ya sea aplicar calidad, aprender a modelar un software o trabajar con mtodo. Lo importante es que podemos lograrlo. El contenido de este libro se sustenta en varios pilares: Las buenas ideas del medio nacional e internacional recogidas a travs de mltiples lecturas, en congresos, seminarios y formacin de postgrado en Chile y el exterior. Los cursos sobre anlisis y diseo que he dictado a alumnos y profesionales en la Universidad de Chile, Universidad Catlica y Universidad Tcnica Fe-

1

Entre otras personalidades, el libro es presentado por los Premios Nobel de Economa Joseph Stiglitz y Amartya Sen.


15

derico Santa Mara, adems de talleres en muchas empresas desde hace ya dos dcadas. En mi experiencia como desarrollador de varios cientos de sistemas computacionales destinados a diferentes organizaciones, ensayando variadas formas de diseo y construccin, propias y normalizadas; incluso, constru una herramienta CASE a fines de los 80s. En relacin al desarrollo de software, mi propia evolucin se fue orientando desde el perfeccionamiento de mtodos tradicionales, reflejados en el libro Desarrollo de sistemas de informacin, una visin prctica, publicado a fines de la dcada de los 80, hacia la bsqueda de frmulas cada vez ms productivas, como el mtodo de cuarta generacin y el modelamiento de datos y funciones, expuestos en revistas especializadas a comienzos de la dcada de los 90. Esos avances fueron profundizados en el libro Modelamiento de sistemas de informacin. La bsqueda sigui hasta desembocar a mediados de esa dcada en la orientacin a objetos, una respuesta natural, productiva, elegante, amistosa y simple para modelar soluciones de software. Ese aprendizaje qued reflejado en el libro La Nueva Visin, Diseo y Construccin de Sistemas Computacionales. Hacia fines de los 90, la orientacin a objetos se transform en un estndar de hecho en la forma del lenguaje de modelamiento UML, el cual incorpor en mis desarrollos y document en un nuevo libro en el 2006, Gestin de Proyectos de Procesos y Tecnologa. Lectores del libro Esta nueva publicacin se orienta a especialistas en informtica, a docentes y estudiantes de carreras afines a la computacin quienes requieren conocer mtodos para aumentar su productividad y efectividad. Tambin a usuarios de la tecnologa, quienes podrn conocer la terminologa bsica para interactuar con los especialistas. Libros de apoyo Complementando este texto y para efectos de que el lector pueda profundizar en ideas especficas (sin ser indispensable porque el modelamiento se trata aqu como una totalidad), hago referencia dentro de la lectura a mis libros relacionados con el tema2:

Para las citas en el pie de pgina indicar slo su ttulo. Los libros estn editados en Santiago de Chile por Editorial Evolucin S.A.

2

16

JUAN BRAVO C.

Desarrollo de sistemas de informacin, una visin prctica (1988) Reingeniera de negocios (1995) Planificacin sistmica (1997) Anlisis de sistemas (1998) Gestin de procesos (2005) Taylor revisitado, la productividad es la clave (2005) Gestin de proyectos de procesos y tecnologa (2006) Responsabilidad social (2007)

No hago referencias a mis libros Modelamiento de sistemas de informacin y La nueva visin, diseo y construccin de sistemas computacionales porque todos sus contenidos relevantes para efectos de modelar soluciones de software estn incorporados en esta nueva obra. Prlogo de Gerentes de reas de sistemas Algunos estimados amigos me han otorgado el privilegio de agregar algunas palabras. Tienen en comn estar a cargo de reas de informtica, las cuales estn insertas en organizaciones de diferente tamao y sector. Christian Andrews3 Todo libro conlleva un gran esfuerzo del parte del autor, por la bsqueda de conceptos e ideas nuevas que se desarrollan y plasman alrededor de una idea maestra, donde convergen todas las otras ideas menores, como afluentes a un ro mayor. Mi amigo Juan Bravo, autor de un gran nmero de libros del rea de la Tecnologa de la Informacin (TI) aplicada a los negocios, a quien conozco por muchos aos, nuevamente ha realizado otro gran esfuerzo, para entregar estos nuevos conocimientos, ideas y conceptos actualizados al da de hoy. En su particular manera de escribir, nos ofrece esta nueva entrega literaria: un libro que versa alrededor de una idea: el modelar soluciones de software. Dnde radica la importancia de este libro para los profesionales de TI? A mi juicio, esta entrega orienta y prepara a las pequeas y medianas empresas, en concebir los sistemas computacionales como un commodity, es decir, sistemas que son construidos con mtodos estndares de construccin y calidad. Con metodologas que aseguran un resultado predecible en las operaciones diarias de los diferentes procesos comerciales. Ratificando una vez ms, que el tener sistemas computacionales no constituye ninguna ventaja sobre la competencia,3

Gerente de Sistemas en Empresas Hites S. A.


17

muy por el contrario, el no tener estos sistemas constituye una clara desventaja competitiva, sin importar en cual industria participe y compita. Desventaja que erosiona gravemente los mrgenes de ingreso, da tras da, en todas estas empresas sin los sistemas computacionales. La tierra es plana postula Thomas Friedman, destacado periodista americano, como un eslogan que interpreta el impacto de la globalizacin en el mundo moderno, botando muros polticos, tendiendo expeditos puentes comerciales sobre los diferentes ocanos, derribando montaas y cordilleras que separan a los pases y finalmente conectando con unas extraordinarias autopistas de fibra ptica todos los continentes de este planeta Tierra, que permiten acercar y hacer local casi cualquier bien o servicio. Un hecho impactante es la cercana de los productos de origen chino en casi todo el diario vivir o la oferta increble de servicios computacionales y tecnolgicos de grandes compaas de origen indio. Hoy por hoy, la gran fbrica de software del mundo est en India, ms que en otro lugar de este mundo, miles de ingenieros de software con conocimientos actualizados y metodologas, estn dispuestos a desarrollar productos de software por una fraccin del ingreso medio de un pas medianamente desarrollado. Entonces, cmo competir en este mundo ms bien adverso? Pues actualizndose permanentemente en los diferentes avances que se van liberando en el mundo desarrollado. De ah, la importancia de este libro de Juan Bravo, quien nuevamente se esfuerza en descubrir, rescatar lo medular de cada nuevo conocimiento del ltimo tiempo, lo encapsula, lo simplifica y lo entrega como un mtodo simple a seguir por sus alumnos y profesionales que siguen sus libros. Quizs hoy ms que nunca es relevante actualizar los conocimientos con la mayor prontitud posible. En su libro, Thomas Friedman cuenta una historia que es atingente: En el frica, cada maana el len hambriento piensa que debe correr ms rpido que la gacela ms lenta para poder alimentarse y sobrevivir. Cada maana la gacela piensa que debe correr ms rpido que el len ms rpido para poder sobrevivir. Para nosotros, que no estamos en el frica, slo podemos pensar que, no importa si somos len o gacela, cada maana debemos comenzar a correr rpido si queremos sobrevivir.

18

JUAN BRAVO C.

Rodrigo Collado4 Conozco a Juan desde hace muchos aos, conozco de su trabajo, de sus anteriores libros y, sobre todo, de su cario por la Ingeniera de Software; especialidad cuya formalizacin le ha tenido de cabezas por un par de dcadas. He ledo su nuevo libro Modelando una solucin de software, una obra que sirve a los especialistas en construccin de software, pero tambin a los que estn ms lejos del diseo de software. Para los iniciados, el mensaje es claro: abandonemos la artesana y hagamos ingeniera. Para los legos, es la oportunidad de conocer la complejidad de una disciplina que an no alcanza la formalidad de otras especialidades. Para ambos, tomar conciencia de la necesidad y prisa de trabajar conforme a los postulados de la Ingeniera de Software, la cual est apoyando el desarrollo y desempeo de casi todas las reas en el mundo del siglo XXI. Y es clave en muchos casos. Siendo tan relevantes y amplios estos mensajes, debemos buscar la forma que el libro se desmaterialice y llegue a las salas de clases y a las empresas. Juan tiene la ventaja de conocer el medio local, de haber enseado en l, de haber trabajado en muchas empresas chilenas, de haber intercambiado sus puntos de vista y sus sueos con tantos, entre los que me cuento. Deseo firmemente que su libro no sea uno ms, que compita o se compare con cualquier otro editado en Estados Unidos o en otro pas. Agradezco el empeo de Juan, el cario por su profesin, su amor por el estudio de esta especialidad y su coraje en la bsqueda de la impecabilidad en el modelamiento de buenas soluciones de software. Limbi Ortiz Neira5 Cuando el doctor Juan Bravo Carrasco, me llam para pedirme que le escribiera un prlogo a este libro, me embarg la emocin por el gran honor que esto significa para m, y luego de unos segundos de respirar profundo, le respond que lo hara. Mi humilde opinin es la que presento ahora a ustedes: El creativo, novedoso y entretenido enfoque que le ha dado el doctor Juan Bravo C. a este libro, ha logrado que el hecho de modelar una solucin de Software, sea un desafo que nos obliga a considerar diferentes aspectos, por lo general no considerados en este ejercicio, tal como visin sistmica, un concepto que nos abre la mente a ver nuestro software como parte de un en4 5

Gerente de Desarrollo en BancoEstado. Directora de Sistemas en la Municipalidad de Melipilla.


19

torno rico en posibilidades, en el cual necesariamente debemos considerar la mesa6, es decir, el modelo de negocios en el cual estamos trabajando, considerar tambin el diseo orientado a objetos, el cual nos aclara conceptos tan utilizados como desconocidos hoy en da. Un acierto, que destaca dentro de la claridad de este libro, ha sido el hecho de que el doctor Bravo ha logrado explicar de manera simple, sencilla y sin abandonar la formalidad de la Ingeniera de software, las competencias necesarias para modelar una solucin de software, las cuales tienen tal importancia que ellas siete se traducen en los respectivos captulos del libro. Merece la pena nombrarlas aqu: Competencia 1: Aplicar un mtodo completo para la gestin de proyectos Competencia 2: Profesionalizar el desarrollo con la ingeniera de software Competencia 3: Conocer la nueva teora de modelos Competencia 4: Manejar el modelamiento de datos Competencia 5: Conocer necesariamente la orientacin a objetos Competencia 6: Trabajar con el estndar UML Competencia 7: Conocer las herramientas de la TI El libro es tan entretenido que te transporta y te inquieta por continuar aprendiendo. Te desafa a utilizar todos los conceptos, tcnicas y herramientas que all aparecen, as tambin, te estimula a continuar investigando. Modelando una solucin de software, una visin sistmica del anlisis y diseo orientado a objetos, con UML y herramientas TI, es uno de esos libros que por ser tan interesantes, no quieres que se termine y te entusiasma. En este libro, se plasma mucho de la gran experiencia adquirida en sta rea por el doctor Bravo, parte de la cual he tenido la suerte de escuchar y aprender. Finalmente, quisiera felicitar al doctor Juan Bravo por hacernos partcipes a todos de este libro, al cual ha dedicado muchsimas horas de trabajo y el resultado ha sido excelente. Asimismo, agradecerle su confianza en m, y haberme permitido dar mi opinin.

6

Se refiere a cinco elementos que se representan con la metfora de una mesa (la cubierta es la estrategia y las 4 patas son: personas, procesos, estructura y tecnologa), la cual se describe brevemente en la introduccin y se detalla en la etapa de anlisis (seccin 1.4).

20

JUAN BRAVO C.

Carlos Toloza 7 Cuando Juan me pidi revisar el material de este libro y escribir unas lneas al respecto acept sin ningn problema, pero al sumergirme en el tema especfico 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 opinin con la esperanza de que en el momento de estar leyendo estas lneas aportar un mensaje simple y claro. 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 informtico que frente a la construccin de una catedral. El pecado original en informtica es comenzar a desarrollar sin tener los planos, ac es lo mismo, no podemos comenzar a construir el sacro edificio si no tengo planos arquitectnicos hechos y bien hechos. Tengo la suerte de trabajar en una empresa constructora y sera un suicidio comenzar un proyecto sin tener los planos, bueno, en informtica los planos del sistema podemos dibujarlos con alguna nomenclatura estndar como UML o alguna propia, pero ese es el punto, por favor no comience la construccin sin los planos!!! La verdad es que prefiero dejar un mensaje simple y fuerte en la mente del lector que participa en un proyecto informtico, no comience el desarrollo sin planos, no olvide que hay personas que van a vivir dentro de ese sistema y va a ser su casa en forma permanente. De pronto me siento repitiendo algo que escuch por primera vez en mis inicios, cuando programaba mi primer software, pero la realidad de las empresas es muy exigente y a veces la presin por resultados nos hace improvisar o simplificar el tema en las etapas iniciales de los proyectos, les tengo malas noticias, es verdad que los costos de improvisar son muy altos y pueden duplicar fcilmente cualquier presupuesto de tiempo y costo con el consiguiente impacto negativo en el negocio. Juan dice en el prlogo de este libro que lo que buscamos finalmente es una mayor productividad de nuestras empresas, o sea que con los mismos recursos seamos capaces de entregar ms productos o si lo profieren que con menos recursos podamos entregar los mismos productos. Un sistema informtico bien hecho (partiendo de su modelacin) debe bajar los costos del rea en la

7

Gerente de Informtica del Grupo Constructor Besalco.


21

cual se implementa y esta reduccin debe pagar la inversin comprometida para generar utilidades en el tiempo. Bueno, eso es todo, no estamos hablando de modelar por modelar, estamos hablando de hacer un buen proyecto informtico que genere utilidades a la empresa, si lo entienden se darn cuenta del poder que hay en la informtica.

22

JUAN BRAVO C.

AGRADECIMIENTOSEl liderazgo complementa a la gestin, no la sustituye. Kotter (2004, p. 41)

Mi especial reconocimiento a quienes tuvieron la gentileza de revisar borradores de este texto y compartir tanto de su sabidura: Limbi Ortiz Neira, Gloria Arellano Mundaca, Mauricio Arancibia Pino, Gerardo Cerda Neumann, Christian Andrews Villagra, Rolf Achterberg Neman, Rodrigo Collado Lizama, Luis Cavieres Rojas, Vctor Silva Ballerini, Ignacio Castro Escobar, Carlos Reyes Rubio, Eugenio Daz Gonzlez, Hugo Osses Bravo, Carlos Parra Bustos y Ral Prado Baldratti. Muchas ideas y motivacin han surgido de las conversaciones con Liliana Gajardo, Derek Hyland, Francisco Ramrez, Daniel Kanonitsch, Miguel Sez, Luis Cid, Francisco Medina, Rodrigo Baldecchi, Marcos Merino, Carlos Toloza y Enrique Jorquera (mis disculpas por las eventuales omisiones). Este libro es heredero de dos textos anteriores: Modelamiento de Sistemas Computacionales (1994) y La Nueva Visin, Diseo y Construccin de Sistemas Computacionales (1996), as es que reitero en ste los agradecimientos a quienes aportaron de una u otro forma en aquellos (revisiones, ideas, motivacin): Rolf Achterberg Neman, Giancarlo Gandolini Ambrosoli, Ricardo Baeza Yates, Eugenio Daz Gonzlez, Santiago Macas Huenchullan, Francisco Mndez Sanhueza, Jos Labra Molina, Jeannette Caballero Pinilla, Alexis Cifuentes Barra, Luis Mndez Reyes, David Medina Avils, Jos Leiva Olmedo, Ricardo Cahe Cabach, Juan Carlos Soto Trucido, Francisco Guerrero Novoa, Bernardo Cienfuegos Areces, Sonia Esturillo Herrera, Liliana Gajardo Campos, Jorge Stein Blau, Manuel Videla Abarca, Dagoberto Cabrera Tapia y Cristian Rubilar Utillano. Estoy agradecido de las empresas donde me acogieron como colaborador de tiempo completo: Empremar, NCR y Weisselberger y Ca. Tambin de las organizaciones donde he tenido el privilegio de participar como asesor o relator de seminarios: CMP, AT&T Chile, Agencia de Aduanas Jorge Stein, Polygram Chile Ltda., Termosistema, Aquacultivos, Editorial Televisa, Integramdica, Sota y Nicoletti Comunicaciones, entre otras. Especial mencin requieren las empresas con las cuales hemos trabajado en la ltima dcada: BancoEstado, Empresa Portuaria de Valparaso, Rolec, Enami Ventanas (actual Codelco), IST y ACHS.


23

En cuanto al mbito acadmico, destacar actividades abiertas de capacitacin, por ejemplo, a travs de: Universidad Tcnica Federico Santa Mara en Via del Mar y Santiago. El diploma realizado por varios aos en anlisis y diseo de sistemas. Universidad Santa Mara en Ecuador, el magster en gestin y tecnologa. Universidad de Chile, los cursos acerca de procesos y de tecnologa. Pontificia Universidad Catlica de Chile, en particular los cursos de gestin de proyectos de procesos y de tecnologa en el formato de dos das. Revista Gerencia, en la forma de mltiples seminarios de un da de divulgacin de estos temas. La colaboracin de Silvia, mi hermana, una vez ms fue muy valiosa en todo tipo de apoyo logstico. El diseo de la portada es obra de Juan Pablo Bravo Zamora. A todos agradezco sus aportes y libero de cualquier responsabilidad por algn error en el texto. Un reconocimiento especial a mi esposa e hijos, su cercana ha sido un estmulo en la realizacin de esta obra. Juan Bravo C.

24

JUAN BRAVO C.

INTRODUCCINEl 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 enfrentarn. 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. KENDALL y KENDALL (2005, p. 30)

Modelar una solucin de software es una labor bella y creativa. Por esta razn, frecuentemente se obtienen muy buenos productos que son verdaderas obras de arte, tal como si a un artista le encargaran una obra (requerimientos) y l, utilizando sus propios mtodos y herramientas de trabajo, diera vida a una creacin nica e irrepetible. Ser posible profesionalizar conservando la creatividad? S! y de esta forma los mtodos y herramientas van a recibir el aporte de muchas personas. Modelar soluciones de software puede ser arte y tecnologa a la vez. Este es el desafo, modelar soluciones de software con tcnicas normalizadas, buscando simplicidad, eficiencia y adaptabilidad al cambio, en el contexto de un proceso general de desarrollo que permita trazabilidad y productos repetibles. Por qu modelar? Porque es necesario representar formalmente una realidad deseada, que de otra forma resultara muy difcil de transmitir, en este caso una solucin de software. Lo ms probable es que la realidad deseada se encuentre vagamente escrita y que principalmente est en la mente de las personas, ms como un deseo difuso que como un requerimiento. La funcin del modelamiento es hacer tangible y aclarar esa realidad para que luego se pueda implementar. Si esa realidad deseada da respuesta a una necesidad por una parte y por otra los modelos de esa realidad son factibles de implementar, entonces la probabilidad de xito es alta. Eso es lo que quiere mostrar la siguiente figura.Problema Solucin Implementacin

Necesidad

Realidad deseada (difusa)

Modelos de la solucin


25

Shari Pfleeger explica en su libro Ingeniera de software (2002, p. 226): Se utiliza la especificacin de requerimientos para definir el problema. Entonces, podemos declarar que algo es una solucin a un problema si satisface todos los requerimientos planteados en la especificacin. En muchos casos el nmero de soluciones es prcticamente ilimitado. Siempre es necesario modelar la solucin antes de implementar? Depende, si usted slo quiere extender una pared interior de 2 metros, es posible que no requiera los modelos, puede contratar un experto y slo darle instrucciones verbales, tal vez le resulte y ahorre tiempo y dinero. Sin embargo, si quiere construir su casa necesitar de maquetas y muchos planos (obra gruesa, caeras de agua, cables de electricidad y todo lo dems). En el software es igual, toda aplicacin desde un costo de algunos miles de dlares ya hace necesario un modelar formalmente. La idea es superar la construccin artesanal de software (por ejemplo, construir sin planos) y aplicar los nuevos conocimientos sobre teora de modelos, normalizacin (tal como orientacin a objetos y UML) y construccin con herramientas CASE.

Contenido del libroLo primero sucede en esta misma introduccin, una seleccin de los modelos ms relevantes de una solucin de software, donde slo se muestra un boceto de ellos para lograr una visin de conjunto (el detalle de cada uno est en el resto del libro). Esta presentacin ser nuestra gua y a partir de esta experiencia extraeremos una conclusin vital: las competencias que debera tener un profesional de la informtica. Las competencias son conocimientos, habilidades y actitudes necesarias para modelar aplicaciones computacionales (o soluciones de software), en este texto se presentan en la forma de captulos: 1. Un mtodo completo para la gestin de proyectos y as situar el modelamiento de soluciones de software en su contexto. 2. La profesionalizacin de conocimientos que aporta la ingeniera de software para comprender todos los aspectos tcnicos de los modelos, las normas y estndares que existen. 3. Los mltiples aportes de la nueva teora de modelos, en particular el modelamiento de funciones y el criterio curso normal de los eventos. 4. El indispensable modelamiento de datos. 5. Los necesarios conocimientos de la orientacin a objetos.

26

JUAN BRAVO C.

6. El estndar UML. 7. Las herramientas de la tecnologa de informacin. Cada captulo, en el mismo orden, profundiza en la competencia correspondiente, producindose un avance que parece una pirmide, tal como se aprecia en la siguiente figura.

CAPTULO 7. HERRAMIENTAS TI CAPTULO 6. UML CAPTULO 5. ORIENTACIN A OBJETOS CAPTULO 4. MODELAMIENTO DE DATOS CAPTULO 3. TEORA DE MODELOS CAPTULO 2. INGENIERA DE SOFTWARE CAPTULO 1. MTODO PARA LA GESTIN DE PROYECTOS

Competencias necesarias para modelar aplicaciones computacionales

Sntesis de modelos de una solucin de softwareLos modelos se crean en las etapas de anlisis y diseo de la Gestin Sistmica de Proyectos (GSP)8. El camino para dibujarlos es iterativo, es decir, se van perfeccionando mediante borradores sucesivos. Es recomendable contar cuanto antes con un boceto de todos los modelos que se considerarn para cada etapa de la aplicacin particular, una primera versin destinada a lograr una visin de conjunto. Ese es el sentido de esta introduccin. Seguimos la idea de una doble espiral que se traslapan parcialmente: la primera del anlisis y la segunda del diseo, tal como vemos en la figura.

Anlisis

Diseo

8

En el captulo 1 veremos el mtodo completo.


27

Mapas para la visin de conjunto Conviene observar estos cinco mapas que deberan existir en la organizacin previo al desarrollo de una aplicacin especfica. Son los mapas de necesidades, proyectos, procesos, retroalimentacin y sistemas.Bienestar Productividad Calidad Costo Responsabilidad Social2p

Soluciones propuestas: 1. Alinear con la estrategia 2. Incluir como plan de accin de RS

Mapa de proyectos10p

Tiempo

Problemas detectados: 1. Pago tardo a Proveedores 2. Trabajadores fuman en sector atencin clientes

1p= Libera = Neutro = Requiere

7p

Mapa de necesidadesProcesos EstratgicosGestin de Personas Gestin de Procesos Gestin de Proyectos Gestin de Calidad Control de Gestin Gestin de ContratosAnalizar cargos Reclutar Inducir

Mapa de procesos

Desarrollo

Planificacin Estratgica

RS

Evaluar

Formar

Disear carrera

Proceso del Negocio ComercializarProyectar ventas Conocer la demanda Visitar Clientes Estadsticas 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 Atencin al cliente Medicin y seguimiento Servicio de garanta

Cotizar

Recepcionar

Despachar

Cuadrar

Procesos de ApoyoAdquisiciones Servicios Bsicos Finanzas Contabilidad Legal Transporte Remuneraciones y bienestar Tecnologa y Mantencin

Meditacin

CobranzasBuen trabajo en equipo

DevolucinLiderazgo sistmico

Ventas

Alcance poco claro Retroalimentacin de eventos destacados Demora en entrega finalDificultades para coordinar entrevistas con usuarios

Facturacin Compras Bodega Entrega

= Experiencias para evitar = Experiencias para replicar

Recepcin

Mapa de retroalimentacin

Mapa de sistemas computacionales

28

JUAN BRAVO C.

Estos mapas son modelos que ayudan a lograr la visin de conjunto para luego formalizar en el anlisis y diseo la solucin de software. El detalle de cada uno se puede apreciar en el captulo 1. La visin de conjunto es vital en la visin sistmica, cosmovisin que gua todo el trabajo de este libro, tanto en los mapas como en los siguientes modelos, los cuales tienen la caractersticas de contextualidad, es decir, dependen del mtodo y nivel de madurez de cada organizacin. Los modelos que se presentan a continuacin para anlisis y diseo son slo una muestra de las posibilidades del modelamiento. Cada empresa debe tener su propia ruta metodolgica e incluso adaptada segn tipos de proyectos. Se presentan los modelos ordenados segn las etapas de anlisis y diseo. En la siguiente figura se aprecia el objetivo y actores de cada una. Todo el modelamiento est orientado al cliente (externo, quien paga), la etapa de anlisis se orienta a definir el qu y la de diseo el cmo, en ambas participan analistas y usuarios. Una vez que el diseo est completo, se enva al constructor (aunque sea el mismo analista en otro rol).

Qu Anlisis

Cmo Diseo Constructor

Cliente Usuarios y Analistas

Modelos de la etapa de anlisis La siguiente seleccin de modelos no pretende ser exhaustiva, se incluye con el nico objetivo de lograr una visin global, no se explican aqu porque el detalle de cada uno est en los captulos del libro.


29

En este caso, los modelos siguen la lgica del mtodo GSP, en la empresa corresponden a los contenidos del proceso de desarrollo de software que sta se haya dado. En esta etapa todo el trabajo se centra en el modelo de negocios de la solucin, con cinco elementos que se representan con la metfora de una mesa, la cubierta es la estrategia (alineando la de la empresa y la de del proyecto, incluye responsabilidad social) y las 4 patas son: personas (incluyendo ambiente), procesos, estructura (organizacional y fsica) y tecnologa (de todo tipo). En esencia: corresponde decidir Qu hacer, comenzando por la cubierta de la mesa (detalle de la figura en el captulo 1).

Estrategia Personas Procesos Tecnologa Estructura

Luego se comienza a trabajar en la pata de los procesos: levantamiento detallado y propuestas de cambio. Se emplean principalmente los modelos mapa de procesos y flujograma de informacin, los cuales se observan en la siguiente figura (detalle en los captulos 1 y 3 respectivamente).Vender al detalle

PROCESO DESPACHO INMEDIATOCLIENTE OE BODEGA ADMINISTRATIVO DE BODEGA FINANZAS DESPACHADOR

Vender

Despachar

CuadrarPROCESOS VENDER

Reservar y emitir GDGD4

GD3 GD2 GD1

GDs

Buscar producto

Al Contado A Crdito

Inmediato A domicilio

GD4 OE

Rebajar saldoCliente recibe y firma recepcin

Programar

EntregarGD2 GD1 GD3PROCESO CUADRAR

Mapa de procesosOE: Orden de Entrega, GD: Gua de Despacho

30

JUAN BRAVO C.

Desde aqu surgirn definiciones para las otras patas de la mesa: personas, estructura y tecnologa. Lo cual est descrito en el captulo 1. Para definir el alcance de la solucin de software en la etapa de anlisis, se puede emplear esta serie de modelos (una buena tcnica es por borradores sucesivos, comenzando por cualquiera de ellos). El objetivo es decidir qu incluye el modelo de negocios (detalle en los captulos 1, 2 y 3).ClientesPedidos y devoluciones Costos

GerenciaNiveles

Compras Devoluciones Entradas Traspasos

Ventas

Artculos y factura Artculos y gua

Control del stock

Salidas

Devoluciones Traspasos

Control de stock

Despacho de artculos Peticiones

Proveedores

Orden de compra y devoluciones

Sala de ventas

Diagrama de contextoMaestros

Modelo orientado al objetivo principal del sistemaClientes Artculos ProveedoresTransacciones

Proveedores

Cuentas Contables

Historial Ventas

Historial Compras

Ventas ComprasDevolucin ventas

X X

Compras

Clientes

X X X

X

X X X

X X X

Artculos

Ventas

Modelo orientado a los datosCotizador

Modelo orientado al flujo de transaccionesTerminales del rea de Adquisiciones Cotizar Aprobar cotizacin Ingresar O/C Aprobar O/C Enviar O/C O/C = Orden de Compra Jefe de Adquisiciones

Administrativo de Adquisiciones

Diseo general de la interfaz

Diagrama de casos de uso

Una vez lograda la decisin respecto a los qu, es necesario profundizar en los requerimientos principales de la solucin de software, en tal caso, la recomendacin es trabajar con estos nuevos modelos (detalle en los captulos 5 y 6).


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 cotizacin a proveedores. La O/C queda disponible para ser enviada al proveedor luego de la aprobacin electrnica por el jefe de adquisiciones

Resumen: (el mismo del caso de uso de alto nivel). Funciones relacionadas: Curso Normal de los eventos Accin del actor Respuesta del sistema 1. Tomar la O/C desde el archivador 2. Ingresar N O/C en (A) 3. Verifica correlativo y enva respuesta en (B) 4. Ingresar Rut en (D) 5. Verifica que proveedor exista, obtiene y despliega nombre y fono en (E) y (F) 6. Para cada lnea: Para cada lnea: 7. Ingresar el cdigo de 8. Verifica existencia del producto, producto en (H) obtiene y despliega la descripcin y el precio en (I) y (J) 9. Ingresar las unidades en (K) 10. Calcula el subtotal y despliega en (L) 10. Dar OK a la lnea 11. Excepciones: 1. Si el nmero de O/C ya existe, vea caso de uso Corregir Correlativo. 2 Incluye interfaces detalladas de E/S

Caso de uso de alto nivelEncabezado 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

Caso de uso de expandidoEncabezado de O/C N O/C Fecha compuesta por contiene existe en * 1 Proveedores Rut Nombre

Lneas de la O/C

Lneas de la O/C Unidades Precio

contiene existe en * 1

Productos ...

existe en * almacena 1 Bodega ...

Modelo conceptual de datos

Modelo conceptual con atributos

Interfaz de EntradaGua Interna de Recepcin por CompraCdigo Enc. Recepcin RUT Proveedor Direccin Proveedor Comuna

C-

Encargado Recepcin Razn Social Proveedor

D F

N Gua Recepcin Fecha Recepcine-Mail

A

B

Encabezado de transaccin

C/E Mensaje 1

Ingresar transaccin

Personas

E I

GCiudad M

HFax

J

Fono

K NPrecio

L OValor Neto

Gua de Despacho de Proveedor N

Fecha G/ D. Proveedor

N de O/C.

Detalle de transaccin

C/E Mensajes 4 y 5

Productos

L.

Cdigo

Descripcin

Cantidad

LL

P

Q

R

S

T

Modelo funcional generalizadoCerrada Anulada

W Y

Cerrar X Anular Z

XXSalir

VGrabar Total acumulado

U

Interfaz visual detallada

32

JUAN BRAVO C.

Modelos de la etapa de diseo De la misma forma que la etapa de anlisis, es decir, mediante borradores sucesivos y la tcnica de desarrollo en espiral (ver anexo 3) se avanza en el diseo, sin mayores problemas de volver a veces a la etapa de anlisis, porque ambas forman una totalidad que llamamos modelar una solucin de software (el detalle de estos modelos est en los captulos 5 y 6).Encabezado de transaccin N documento Fecha Rut persona 1 Agregar 2 Consultar 3 ImprimirC/E Mensaje 1

Personas Ingreso de transaccin Encabezado, detalle y totales segn formato 1 Aceptar datos 2 Cuadrar totalesC/E

Ingreso de transaccin Encabezado, detalle y totales segn Formato de pantalla adjunto Aceptar datos y actualizar lnea a lnea cada producto. Enviar mensajes para verificar Existencia de personas y artculos, Ambos deben existir. Cuadrar totales para referencia. Enviar solicitudes para actualizar el stock

Rut Nombre Direccin Telfono 1 Agregar 2 Consultar 3 Imprimir

Detalle de transaccin N documento Cdigo artculo Costo Cantidad 1 Clculo total

ProductosC/E Mensajes 4 y 5

Cdigo artculo Tipo artculo Descripcin ltimo costo Saldo 1 Agregar 2 Consultar 3 Imprimir 4 Sumar saldo 5 Restar saldo

Objeto Ingreso de ventas Ingreso de compras

Tabla de objetos, clase Ingreso de transaccin Atributos Funciones Indicar stock del producto Deben cuadrar totales, stock mayor a unidades por vender. Mensaje 5 Crear proveedor y artculo si no existen. Mensaje 4

Modelo funcional generalizado y detalladoAdministrativo Sistema

Visin interna de la clase ingreso de transaccin con la tabla de objetosContrato Identificacin: Dar OK al ingreso de la lnea Responsabilidades: con cada ingreso de lnea 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 lnea en el sistema ya fue validada con el ingreso de O/C. Salida: no hay Precondiciones: no existe la lnea. Poscondiciones: Se cre una lnea en el concepto detalle. Se actualiz el contador de lneas en el encabezado. Se actualiz la asociacin entre encabezado y detalle de O/C.

Ingresar N de O/C Ingresar cdigo de prod. Repetir hasta que no haya ms productos Ingresar cantidad Dar OK a la lnea

Diagrama de secuencia

Contrato


33

Los dos modelos ms caractersticos del diseo desde el punto de vista de UML son el de diseo de clases y colaboracin (detalle en el captulo 6).Proveedores Encabezado de O/C N O/C Fecha Crear lnea Imprimir compuesta por 1 contiene * existe en 1 Rut Nombre Crear proveed. Modificar Rut Modificar nombre

se asocia a

1..* contiene * existe en 1 existe en almacena*

Lneas de la O/C Unidades Precio Agregar lnea

Productos ...

1 Bodega ...

Diagrama de diseo de clasesOperacin: Dar OK al Ingreso de la lnea de O/C Ingresar producto (cd, cant, pre) Terminal del administrativo 1: Crear lnea de O/C (cod, cant, pre) Encabezado de O/C 1.1: Crear (cod, cant, pre) Lneas de la O/C

Diagrama de colaboracin

34

JUAN BRAVO C.

CAPTULO 1. MTODO PARA LA GESTINDE PROYECTOSCaptulo 1. Mtodo para la gestin de proyectosEl papel de la arquitectura de software es parecido al papel que juega la arquitectura en la construccin de edificios. El edificio se contempla desde varios puntos de vista: estructura, servicios, conduccin de calefaccin, fontanera, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construccin. Anlogamente, la arquitectura en el sistema de software se describe mediante diferentes vistas del sistema en construccin. BOOCH, JACOBSON y RUMBAUGH (2000, p. 5)

Este captulo introduce en los conceptos y la necesidad de contar con un mtodo completo para la gestin de proyectos en la organizacin, no slo en el mbito tecnolgico. Esta es la primera competencia considerada para apoyar la elaboracin de modelos de una solucin de software, tal como se aprecia en la siguiente figura (en la introduccin se incluy la visin global de las competencias). Es necesario que el analista conozca la totalidad de pasos de un proyecto para insertar su aporte. Podramos decir que es un conocimiento de tipo horizontal, con visin de procesos, porque se refiere a entender la totalidad de la gestin de proyectos, independiente de que su foco estar en las etapas deCAPTULO 7. HERRAMIENTAS TI CAPTULO 6. UML CAPTULO 5. ORIENTACIN A OBJETOS CAPTULO 4. MODELAMIENTO DE DATOS CAPTULO 3. TEORA DE MODELOS CAPTULO 2. INGENIERA DE SOFTWARE CAPTULO 1. MTODO PARA LA GESTIN DE PROYECTOS

Competencias necesarias para modelar aplicaciones computacionales


35

anlisis y diseo. La visin global, sistmica, que ofrece un mtodo es indispensable para entender la totalidad que surge de necesidades concretas en la empresa que los proyectos ayudarn a resolver creando una habilidad organizacional9. Al mtodo que presentamos en estas pginas le hemos llamado GSP (Gestin Sistmica de Proyectos), es resultado de extensas investigaciones acerca de las mejores prcticas de proyectos y es un extracto del libro Gestin de proyectos de procesos y tecnologa, sealado en el prlogo. Trabajar metodolgicamente es una competencia indispensable para todo profesional del rea de proyectos y para todo tipo de proyectos, ya sea que estn orientados a procesos del negocio, de apoyo o estratgicos. Por otra parte, toda organizacin debe contar con un mtodo para la gestin de sus proyectos. Las etapas son los grandes bloques que aporta el mtodo GSP: concepcin, factibilidad, anlisis, diseo, implementacin, despliegue y operacin. Las etapas estn agrupadas en tres fases: estudio, desarrollo y mejora continua. Tanto las etapas como las fases se pueden traslapar en los lmites. Tambin existen prcticas transversales a las etapas, es decir, aplican en algunas o en todas las etapas del mtodo. Son 28: direccin del proyecto, plan de la etapa, exposicin de los planes, retroalimentacin, equipo de trabajo, entrevistas, comunicacin, informes, tcnicas, herramientas de apoyo, trazabilidad, Quick wins, costos y duracin, gestin de riesgos, gestin de la calidad, responsabilidad social, insercin, orientacin al cliente, sensibilizacin, capacitacin, seguimiento, cuidar la solucin anterior, continuidad operacional, plan de recursos fsicos del proyecto, kill time, control de cambios, gestin del cambio y gestin de proveedores. Veremos: Trabajar metodolgicamente Claves de la implantacin de mtodo Adaptacin y profesionalismo Etapas genricas Prcticas transversales

Por habilidad organizacional entendemos una competencia que adquiere la empresa mediante una solucin de software, por ejemplo, ahora puede vender a travs de Internet o tener su contabilidad al da.

9

36

JUAN BRAVO C.

1.1. TRABAJAR METODOLGICAMENTEEn la Edad Media, la incorporacin a un oficio, hacer zapatos o construir catedrales, era una iniciacin en un gremio muy cerrado. El arte o secreto de los maestros se transmita desde stos a principiantes a travs de la revelacin de los misterios del oficio. De la misma forma comenz el desarrollo de proyectos tecnolgicos, con iniciados que conocan los secretos del arte y que parecan estar juramentados para no revelarlo. Sin embargo, no ha sido necesario que transcurrieran 400 aos para que ese arte se transformara en tecnologa, tal como ocurri con la mayora de los oficios de la Edad Media. En la gestin de proyectos TI han bastado slo 40 aos para que la situacin cambiara drsticamente. Hoy sabemos cmo hacer gestin de proyectos y ese conocimiento est al alcance de todos en la forma de mtodos de alcance bastante amplio. Una definicin de la gestin de proyectos hace Alejandro Covacevich (1994, 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 fsicos, se necesita un ejecutivo que planifique, organice, dirija, controle y coordine. Todas esas acciones configuran la gestin del proyecto, que generalmente ser ms compleja mientras ms recursos y personas intervengan. Veremos: 1. Qu es mtodo? 2. Las mejores prcticas 3. Fundamento conceptual: la visin sistmica 4. Mtodo GSP

1. Qu es mtodo?Antes de continuar, aclaremos qu es mtodo? Consideramos que es una competencia bsica para todo profesional que le permite guiar su trabajo de acuerdo con normas y procedimientos definidos, visualizar el inicio y el fin de los procesos en que participa, ubicar su aporte en el contexto del proceso completo y trabajar en equipo con los dems participantes del proceso.


37

Se desprende de la definicin que mtodo est asociado con personas, quienes deben trabajar metodolgicamente, lo cual aplica para todo tipo de procesos y proyectos de cambio organizacional. Las prcticas que adquieren las personas con la competencia mtodo se pueden ver como un continuo que comienza desde la toma de conciencia de cmo lo hacemos (ya sea un proceso operativo o un proyecto) hasta aplicar mejora continua, rediseo e innovacin sobre esa secuencia. Refirindose a la buena gestin de proyectos, Campero y Alarcn en su libro Administracin de Proyectos Civiles sealan (1999, pp. 2-3): Los buenos resultados de una administracin sern el producto de condiciones personales de los responsables y de las tcnicas de administracin que empleen. Cumplir con las metas programadas de costo y plazo no resulta fcil y existe una alta posibilidad de arriesgar los beneficios y costos esperados. Un estudio realizado por Thompson y Perry usando un gran nmero de proyectos del Banco Mundial, indica que, de 1.778 proyectos revisados, en el 63% de los casos el costo final super el presupuesto, de 1.627 proyectos revisados, el 88% termin con atraso. De 42 proyectos controlados, el 70% de ellos no alcanz a la tasa interna de retorno (TIR) esperada.

2. Las mejores prcticasEl mtodo presentado surge de revisar y ensayar con las propuestas de lenguajes, normas de calidad y herramientas que el mercado ofrece, aprendiendo de tales opciones e incorporando las mejores prcticas para aplicar en las organizaciones de Latinoamrica, donde podemos profundizar en trabajar con calidad y excelencia. Es un mtodo genrico porque la idea es conocer y seleccionar del medio las mejores tcnicas (causa-efecto, creatividad, mapa de procesos, flujograma de informacin, UML, ITIL, PMI, orientacin a objetos y otras) avanzando hacia las estandarizaciones formales o de hecho.

3. Fundamento conceptual: la visin sistmicaEl modelamiento de soluciones de software tiene su base conceptual en la visin sistmica10, tambin conocida como pensamiento sistmico, visin area, aceptacin del caos y de la complejidad.10

El libro Anlisis de sistemas se refiere en su totalidad a visin sistmica.

38

JUAN BRAVO C.

Peter Senge provee algunas claves en su libro La quinta disciplina (1992, p. 148): La clave del pensamiento sistmico es la palanca: hallar el punto donde los actos y modificaciones en estructuras pueden conducir a mejoras significativas y duraderas. A menudo la palanca sigue el principio de la economa de medios, buscando el lugar donde los mejores resultados no provienen de esfuerzos en gran escala sino de actos pequeos y bien focalizados. El pensamiento asistmico resulta perjudicial porque nos induce a efectuar cambios de bajo apalancamiento: nos concentramos en los sntomas donde la tensin es mayor y reparamos o aliviamos los sntomas. Pero esos esfuerzos a lo sumo, mejoran la situacin en el corto plazo, y la empeoran en el largo plazo. Conviene conocer algo de la visin sistmica porque nos ayuda a entender por qu hemos organizado el mundo tal como lo conocemos, en fragmentos, buscando especializacin. Tambin nos ayuda a pensar en integralidades, en volver a unir las partes de los rompecabezas que hemos creado. Este nuevo paradigma tiene su propio campo de conocimientos y se nutre desde otras disciplinas: antropologa, sociologa, psicologa, pedagoga, todas las cuales aportan a una visin ms amplia. Una gua para modelar una solucin de software La visin sistmica ser el gran fundamento conceptual que citaremos en este camino prctico del modelamiento de aplicaciones de software. Por ejemplo, nos ayuda a entender que un cambio en un modelo afectar a todos los dems, que la actitud de los diseadores es fundamental y que el nimo y la cooperacin de quienes modelan es vital. La visin sistmica nos ayuda a ver el todo, apreciar sus interacciones, la energa presente y descubrir sus caractersticas distintivas, aquellas que son propias del conjunto y que no existen en las partes. A la vez, ubica el sistema en su entorno, acepta la complejidad que nos excede, la irreversibilidad del tiempo, la autoorganizacin, la inteligencia de los sistemas y nuestra responsabilidad con el bien comn. Qu es un sistema? No existe una definicin generalmente aceptada para un sistema. Tradicionalmente se lo entiende en dos aspectos: orientado al exterior en cuanto se encuentra situado en un medio donde interacta con otros sistemas de su nivel y con sistemas mayores de los que forma parte, y orientado a su interior, en este caso el sistema es energa que toma la forma de interacciones y crea los elementos que sean necesarios para su evolucin.


39

Dice Idalberto Chiavenato (2000, p. 769): El concepto sistema pas a dominar las ciencias y, en especial, la administracin. Si se habla de astronoma, se piensa en el sistema solar; si el tema es fisiologa, se piensa en el sistema nervioso, en el sistema circulatorio o en el sistema digestivo. La sociologa habla de sistema social; la economa, de sistemas monetarios; la fsica, de sistemas atmicos, y as sucesivamente. En la actualidad, el enfoque sistmico es tan comn en administracin que no se nos ocurre pensar que estamos utilizndolo en todo momento. Y en este texto lo estamos aplicando a modelar soluciones de software

4. Mtodo GSPEl Mtodo GSP (Gestin Sistmica de Proyectos) es una gua para el desarrollo completo de un proyecto, pasando por todas las etapas de su ciclo de vida: concepcin, factibilidad, anlisis, diseo, implementacin, despliegue y operacin. Es un mtodo abierto, con etapas genricas, amplio uso de tcnicas del medio, apoyo de herramientas existentes y aplicacin de las mejores prcticas. El Mtodo GSP es parte de un modelo integral para la gestin de la innovacin en la organizacin que contempla las definiciones estratgicas, formacin de las personas, mtodo, creacin de estructura organizacional y apoyo tecnolgico (todos los elementos de la mesa sealados en la introduccin y que se estudian en detalle en la etapa de anlisis de la seccin 1.4). El plan de proyecto es una totalidad con contenidos mucho ms all de la carta Gantt, incluye tambin la historia del proyecto, clculos financieros, justificacin de la necesidad y mucho ms segn veremos en la etapa de factibilidad en la seccin 1.4. Adems, el plan de proyecto contempla dos lneas de trabajo paralelas, como las vas del ferrocarril: Etapas del proyecto Prcticas transversales Shari Pfleeger seala (2002, p. 135): Para comunicar a los clientes el anlisis y la gestin del riesgo, el cronograma y la organizacin, usualmente se escribe un documento denominado plan de proyecto. El plan deja por escrito las necesidades del cliente, as como lo que se espera hacer para satisfacerlas. El cliente puede remitirse al plan para tener informacin sobre las actividades del proceso de desarrollo, siendo fcil seguir el avance del proyecto durante el desarrollo Un buen plan incluye los siguientes items: alcance del proyecto, cro-

40

JUAN BRAVO C.

nograma, organizacin del equipo de trabajo, descripcin tcnica del sistema propuesto, estndares del proyecto, procedimientos y tcnicas y herramientas propuestas. La lista se extiende hasta los planes especficos para las prcticas transversales, tales como plan de aseguramiento de calidad, de riesgos, dee recursos y muchos otros. En la figura 1-1 se presenta la totalidad del mtodo GSP.Mtodo GSP Etapas del mtodo genrico (CFADIDO)

Concepcin Factibilidad Anlisis Diseo Implementacin Despliegue Operacin

Prcticas Transversales

Direccin del proyecto Plan de la etapa Gestin de riesgos Retroalimentacin Capacitacin Entrevistas Comunicacin Informes y las otras 20

Figura 1-1. Totalidad del mtodo GSP


41

1.2. CLAVES DE LA IMPLANTACIN DE MTODOSon claves que guan el trabajo en la implantacin de mtodo. Previo, es necesario sincerar lo que realmente hace la organizacin con mtodo y lo que est dispuesta a aplicar. Mtodo no es algo que solamente se compra y usa, como una mquina, tampoco se puede internalizar mediante pastillas (ni disponemos todava de la tecnologa de la pelcula Matrix, aquella donde Neo aprenda rpido mediante un tubo conectado directamente al cerebro). Mtodo tiene que ver con el desarrollo de competencias de las personas, con un trabajo arduo de generar estndares internos y sumarse a normas externas. Hemos detectado 4 claves, son recursivas, es decir, tambin aplican para los proyectos que utilizarn el mtodo en la organizacin. Clave 1. Cinco mapas globales para la visin de conjunto Clave 2. Mnimo indispensable Clave 3. Participacin de todos los actores Clave 4. Circularidad

Clave 1. Cinco mapas globales para la visin de conjuntoAdems de ver el mtodo en su totalidad, la visin de conjunto se apoya en cinco mapas globales: necesidades, proyectos, procesos, retroalimentacin y sistemas, los cuales veremos en las siguientes pginas. Cada mapa debe tener una documentacin de apoyo con los atributos de cada componente, su propia base de datos y el registro de cambios. Por supuesto, es vital mantener una versin actualizada de cada uno de ello

Modelando Software

Documents

Transcript of Modelando Software