Personalización Metodológica para el Aseguramiento de la Calidad del Software Implementado por Mi PyMes

Texto completo

(1)UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. PERSONALIZACIÓN METODOLÓGICA PARA EL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE IMPLEMENTADO POR MI PYMES Caso de estudio: Efron Colombia S.A.S.. Autor: LUIS ALEJANDRO URIBE NIÑO Código 20172099046 Grupo No. 2. FACULTAD DE INGENIERÍA ESPECIALIZACIÓN EN INGENIERIA DE SOFTWARE Bogotá, Colombia Mayo 2018.

(2)

(3) UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. PERSONALIZACIÓN METODOLÓGICA PARA EL ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE IMPLEMENTADO POR MI PYMES Caso de estudio: Efron Colombia S.A.S. Autor: LUIS ALEJANDRO URIBE NIÑO Código 20172099046 Grupo No. 2 Director: SANDRO JAVIER BOLAÑOS CASTRO, Ph.D. Revisor: EDILBERTO FERNANDEZ SANTOS. FACULTAD DE INGENIERÍA ESPECIALIZACIÓN EN INGENIERIA DE SOFTWARE Bogotá, Colombia Mayo 2018.

(4)

(5) “Dedico este trabajo a Leslie, a Sara, a Sofı́a, a mi Mami, y a Doña Betty, quienes me han enseñado desde diferentes puntos de vista lo bello que es el amor, y me han brindado durante las diferentes etapas de mi vida todo lo bonito y mágico que está palabra contempla.”. Luis Alejandro Uribe Niño..

(6)

(7) AGRADECIMIENTOS. Gracias a Dios por darnos la salud y permitirnos alcanzar este logro. A la Universidad por formarnos para llegar al punto en el que estamos hoy. Al ingeniero Sandro Bolaños por orientarnos y compartir todo su conocimiento. A Edilberto Fernández, Roberto Pava, Lilian Bejarano, Joaquı́n Mesa, Alexandra Abuchar, Jorge Mario Calvo, John Fredy Parra, Sandra Milena Cortes, y demás profesores y funcionarios por este logro. A Efron por darnos la oportunidad y la información para realizar este trabajo. Y a cada una de las personas que se preocuparon y me colaboraron para que yo culminara esta importante etapa, en especial a mis compañeros de estudio Daniel y Daniela por la colaboración y el apoyo mancomunado. A Edwin mi jefe, por aconsejarme, orientarme y apoyarme en este proceso. A mi mamá por estar ahı́ cada vez que necesité de todo su apoyo, y por supuesto a Leslie por darme la fuerza para culminar esta etapa y brindarme todo su amor. A todos mil Gracias!. Luis Alejandro Uribe Niño.. 7.

(8)

(9) D E C L A R AT O R I A. Declaro que la información y las imágenes contenidas en el presente trabajo de grado titulado: Personalización Metodológica para el Aseguramiento de la Calidad del Software Implementado por Mi Pymes, son de absoluta autorı́a propia, por lo tanto, son el resultado del trabajo del autor, excepto aquellos aportes intelectuales de otros autores, los cuales se han referenciado debidamente en el texto de dicho trabajo.. Luis Alejandro Uribe Niño.. 9.

(10)

(11) Í N D I C E G E N E R A L. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . 2 O R G A N I Z A C I Ó N . . . . . . . . . . . . . . . . 2.1 Empresa . . . . . . . . . . . . . . . . . . 2.1.1 Misión . . . . . . . . . . . . . . . 2.1.2 Visión . . . . . . . . . . . . . . . 2.1.3 Objetivos de Calidad . . . . . . . 2.1.4 Objetivos de la Organización . . . 3 FASE DE ARQUITECTURA DE NEGOCIOS . . 3.1 Punto de Vista de Organización . . . . . 3.1.1 Metamodelo . . . . . . . . . . . . 3.1.2 Modelo . . . . . . . . . . . . . . 3.2 Punto de Vista de Cooperación de Actor 3.2.1 Metamodelo . . . . . . . . . . . . 3.2.2 Modelo . . . . . . . . . . . . . . 3.3 Punto de Vista de Función de Negocio . 3.3.1 Metamodelo . . . . . . . . . . . . 3.3.2 Modelo . . . . . . . . . . . . . . 3.4 Punto de Vista de Proceso de Negocio . . 3.4.1 Metamodelo . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. I. 1. C O N T E X T U A L I Z A C I Ó N D E L A I N V E S T I G A C I Ó N D E S C R I P C I Ó N D E L A I N V E S T I G A C I Ó N. 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 II. Planteamiento del Problema . . . . Objetivos . . . . . . . . . . . . . . Justificación de la Investigación . . Hipótesis . . . . . . . . . . . . . . . Marco Referencial . . . . . . . . . . Metodologı́a de la Investigación . . Organización del Trabajo de Grado Estudio de Sistemas Previos . . . .. A R Q U I T E C T U R A Y D I S E Ñ O. . . . . . . . . .. . . . . . . . . .. 17. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 19 21 21 21 22 23 24 25 26 26. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. 27 29 29 30 30 30 31 33 35 35 36 36 36 37 38 38 39 41 41. 11.

(12) 12. Í N D I C E G E N E R A L. 3.4.2 Modelo . . . . . . . . . . . . . . . . . . . . . . 3.5 Punto de Vista de Cooperación de Proceso de Negocio . 3.5.1 Metamodelo . . . . . . . . . . . . . . . . . . . . 3.5.2 Modelo . . . . . . . . . . . . . . . . . . . . . . 3.6 Punto de Vista de Producto . . . . . . . . . . . . . . . . 3.6.1 Metamodelo . . . . . . . . . . . . . . . . . . . . 3.6.2 Modelo . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . .. F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I Ó N. 4.1 Punto de Vista de Uso de la Aplicación . . . . . . . 4.1.1 Metamodelo . . . . . . . . . . . . . . . . . . 4.1.2 Modelo . . . . . . . . . . . . . . . . . . . . 4.2 Punto de Vista de Comportamiento de la Aplicación 4.2.1 Metamodelo . . . . . . . . . . . . . . . . . . 4.2.2 Modelo . . . . . . . . . . . . . . . . . . . . 4.3 Punto de Vista de Cooperación de la Aplicación . . 4.3.1 Metamodelo . . . . . . . . . . . . . . . . . . 4.3.2 Modelo . . . . . . . . . . . . . . . . . . . . 4.4 Punto de Vista de Estructura de la Aplicación . . . 4.4.1 Metamodelo . . . . . . . . . . . . . . . . . . 4.4.2 Modelo . . . . . . . . . . . . . . . . . . . . 5 F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A . . . . . . 5.1 Punto de Vista de Infraestructura . . . . . . . . . . 5.1.1 Metamodelo . . . . . . . . . . . . . . . . . . 5.1.2 Modelo . . . . . . . . . . . . . . . . . . . . 5.2 Punto de Vista de Uso de Infraestructura . . . . . . 5.2.1 Metamodelo . . . . . . . . . . . . . . . . . . 5.2.2 Modelo . . . . . . . . . . . . . . . . . . . . 5.3 Punto de Vista de Organización e Implementación . 5.3.1 Metamodelo . . . . . . . . . . . . . . . . . . 5.3.2 Modelo . . . . . . . . . . . . . . . . . . . . 5.4 Punto de Vista de Estructura de Información . . . . 5.4.1 Metamodelo . . . . . . . . . . . . . . . . . . 5.4.2 Modelo . . . . . . . . . . . . . . . . . . . . 5.5 Punto de Vista de Realización del Servicio . . . . . 5.5.1 Metamodelo . . . . . . . . . . . . . . . . . . 5.5.2 Modelo . . . . . . . . . . . . . . . . . . . . 5.6 Punto de Vista de Capas . . . . . . . . . . . . . . . 5.6.1 Metamodelo . . . . . . . . . . . . . . . . . . 5.6.2 Modelo . . . . . . . . . . . . . . . . . . . . 6 F A S E D E V I S I Ó N D E A R Q U I T E C T U R A . . . . . . . . . . 6.1 Punto de Vista de Stakeholder . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42 42 42 44 44 44 45 47 48 48 49 50 50 51 52 52 53 54 54 55 57 58 58 59 60 60 61 62 62 63 64 64 65 66 66 67 68 68 69 71 73.

(13) Í N D I C E G E N E R A L. 6.1.1 Metamodelo . . . . . . . . . . . . . . . . . 6.1.2 Modelo . . . . . . . . . . . . . . . . . . . 6.2 Punto de Vista de Realización de Objetivos . . . . 6.2.1 Metamodelo . . . . . . . . . . . . . . . . . 6.2.2 Modelo . . . . . . . . . . . . . . . . . . . 6.3 Punto de Vista de Contribución de Objetivos . . . 6.3.1 Metamodelo . . . . . . . . . . . . . . . . . 6.3.2 Modelo . . . . . . . . . . . . . . . . . . . 6.4 Punto de Vista de Principios . . . . . . . . . . . . 6.4.1 Metamodelo . . . . . . . . . . . . . . . . . 6.4.2 Modelo . . . . . . . . . . . . . . . . . . . 6.5 Punto de Vista de Realización de Requerimientos 6.5.1 Metamodelo . . . . . . . . . . . . . . . . . 6.5.2 Modelo . . . . . . . . . . . . . . . . . . . 6.6 Punto de Vista de Motivación . . . . . . . . . . . 6.6.1 Metamodelo . . . . . . . . . . . . . . . . . 6.6.2 Modelo . . . . . . . . . . . . . . . . . . . 7 F AS E DE O PO RT UNIDA DES Y S O LUC IO NE S . . . . . 7.1 Punto de Vista de Proyecto . . . . . . . . . . . . . 7.1.1 Modelo . . . . . . . . . . . . . . . . . . . 8 F A S E D E P L A N E A C I Ó N Y M I G R A C I Ó N . . . . . . . . . 8.1 Punto de Vista de Migración . . . . . . . . . . . . 8.1.1 Metamodelo . . . . . . . . . . . . . . . . . 8.1.2 Modelo . . . . . . . . . . . . . . . . . . . 9 F A S E D E I M P L E M E N TA C I Ó N D E G O V E R N A N Z A . . . 9.1 Punto de Vista de Migración e Implemantación . 9.1.1 Metamodelo . . . . . . . . . . . . . . . . . 9.1.2 Modelo . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 73 73 74 74 75 76 76 77 78 78 78 79 79 80 81 81 81 83 84 85 87 87 87 87 89 89 89 90. . . . . . . . . . . 10 P R O P U E S TA M E T O D O L Ó G I C A . 11 C O N C L U S I O N E S . . . . . . . . . 12 T R A B A J O S F U T U R O S . . . . . . 13 A N E X O S . . . . . . . . . . . . . . 13.1 Coloso . . . . . . . . . . . . 13.1.1Colosoft EU . . . . . 13.1.2Autor . . . . . . . . . Bibliografı́a . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 91 93 97 99 101 101 101 101 103. III. REFLEXIONES. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 13.

(14)

(15) Í N D I C E D E F I G U R A S. Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21 Figura 22 Figura 23 Figura 24 Figura 25 Figura 26 Figura 27 Figura 28 Figura 29 Figura 30 Figura 31. Efron Consulting[4] . . . . . . . . . . . . . . . . . . . . . . . Punto de Vista de Organización[7, 3] . . . . . . . . . . . . . . Modelo de Organización. Fuente: Autor . . . . . . . . . . . . Punto de Vista de Cooperación de Actor[7, 3] . . . . . . . . . Modelo de Cooperación de Actor. Fuente: Autor . . . . . . . . Punto de Vista de Función de Negocio[7, 3] . . . . . . . . . . Modelo de Función de Negocio. Fuente: Autor . . . . . . . . . Punto de Vista de Proceso de negocio[7, 3] . . . . . . . . . . Modelo de Proceso de Negocio. Fuente: Autor . . . . . . . . . Punto de Vista de Cooperación de Proceso de Negocio[7, 3] . Modelo de Cooperación de Proceso de Negocio. Fuente: Autor Punto de Vista de Producto[7, 3] . . . . . . . . . . . . . . . . Modelo de Producto. Fuente: Autor . . . . . . . . . . . . . . . Punto de Vista de Uso de Aplicación[7, 3] . . . . . . . . . . . Modelo de Uso de Aplicación. Fuente: Autor . . . . . . . . . . Punto de Vista de Comportamiento de Aplicación[7, 3] . . . . Modelo de Comportamiento de Aplicación. Fuente: Autor . . Punto de Vista de Cooperación de Aplicación[7, 3] . . . . . . Modelo de Cooperación de Aplicación. Fuente: Autor . . . . . Punto de Vista de Estructura de Aplicación[7, 3] . . . . . . . . Modelo de Estructura de Aplicación. Fuente: Autor . . . . . . Punto de Vista de Infraestructura[7, 3] . . . . . . . . . . . . . Modelo de Infraestructura. Fuente: Autor . . . . . . . . . . . Punto de Vista de Uso de Infraestructura[7, 3] . . . . . . . . . Modelo de Uso de Infraestructura. Fuente: Autor . . . . . . . Punto de Vista de Organización e Implementación[7, 3] . . . Modelo de Organización e Implementación. Fuente: Autor . . Punto de Vista de Estructura de Información[7, 3] . . . . . . . Modelo de Estructura de Información. Fuente: Autor . . . . . Punto de Vista de Realización del Servicio[7, 3] . . . . . . . . Modelo de Realización del Servicio. Fuente: Autor . . . . . . .. 30 35 36 37 38 39 40 41 42 43 44 45 46 49 50 51 52 53 54 55 55 59 60 61 62 63 64 65 66 67 68. 15.

(16) 16. Í N D I C E G E N E R A L. Figura 32 Figura 33 Figura 34 Figura 35 Figura 36 Figura 37 Figura 38 Figura 39 Figura 40 Figura 41 Figura 42 Figura 43 Figura 44 Figura 45 Figura 46 Figura 47 Figura 48 Figura 49 Figura 50 Figura 51 Figura 52 Figura 53 Figura 54. Punto de Vista de Capas[7, 3] . . . . . . . . . . . . . . . . . . 69 Modelo de Capas. Fuente: Autor . . . . . . . . . . . . . . . . 70 Relación entre los elementos principales y los elementos motivacionales [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Punto de Vista de Stakeholder[7, 3] . . . . . . . . . . . . . . 73 Modelo de Stakeholder. Fuente: Autor . . . . . . . . . . . . . 74 Punto de Vista de Realización de Objetivos[7, 3] . . . . . . . . 75 Modelo de Realización de Objetivos. Fuente: Autor . . . . . . 76 Punto de Vista de Contribución[7, 3] . . . . . . . . . . . . . . 77 Modelo de Contribución. Fuente: Autor . . . . . . . . . . . . . 77 Punto de Vista de Principios[7, 3] . . . . . . . . . . . . . . . . 78 Modelo de Principios. Fuente: Autor . . . . . . . . . . . . . . 79 Punto de Vista de Realización de Requerimientos[7, 3] . . . . 80 Modelo de Realización de Requerimientos. Fuente: Autor . . . 80 Punto de Vista de Motivación[7, 3] . . . . . . . . . . . . . . . 81 Modelo de Motivación. Fuente: Autor . . . . . . . . . . . . . . 82 Punto de Vista de Proyecto[7, 3] . . . . . . . . . . . . . . . . 84 Modelo de Proyecto. Fuente: Autor . . . . . . . . . . . . . . . 85 Punto de Vista de Migración[7, 3] . . . . . . . . . . . . . . . . 87 Modelo de Migración. Fuente: Autor . . . . . . . . . . . . . . 88 Punto de Vista de Migración e Implementación[7, 3] . . . . . 89 Modelo de Migración e Implementación. Fuente: Autor . . . . 90 Propuesta Metodológica. Fuente: Autor . . . . . . . . . . . . . 96 Logo de Colosoft[1] . . . . . . . . . . . . . . . . . . . . . . . 101.

(17) I N T R O D U C C I Ó N. El proceso de desarrollo de software es un proceso flexible que permite que cada persona, grupo de trabajo o entidad defina su propia metodologı́a de desarrollo, lo cual brinda una autonomı́a para que dicho proceso sea tan estructurado como se desee, esto mismo puede ser contraproducente si se define una metodologı́a no muy estructurada, es decir crea las condiciones para la aparición de riesgos, los cuales bajo estas condiciones no se deben tener identificados y mucho menos deben tener definidos planes de acción para la mitigación de los mismos. El proceso de mejora continua, los procesos de certificación de calidad y demás procesos que requieren la definición de estándares y la elaboración de la documentación de los mismos, permiten cada vez más que el aseguramiento de la calidad de los productos de software mejore, dado que de esta manera se identifican factores de riesgo que pueden ser mitigados o controlados, como también la identificación de procesos y procedimientos que pueden ser depurados y/u optimizados. Basado en lo anterior es donde el aseguramiento de calidad toma fuerza y apalanca los demás procesos antes mencionados, y es allı́ donde la sinergia de varios estándares y las buenas practicas hacen posible la implementación de un producto de software con calidad, el cual no solo cumple con los requerimientos funcionales y no funcionales solicitados por el cliente, si no también es un producto amigable y que genera un valor agregado al cliente, maximizando de esta forma su nivel de satisfacción y generando un ambiente cliente proveedor propicio para realizar nuevos negocios.. 17.

(18)

(19) Parte I C O N T E X T U A L I Z A C I Ó N D E L A I N V E S T I G A C I Ó N.

(20)

(21) 1 D E S C R I P C I Ó N D E L A I N V E S T I G A C I Ó N. 1.1. PLANTEAMIENTO DEL PROBLEMA. En la actualidad se presenta una dificultad en el momento de la entrega de los productos de software a los usuarios funcionales, dado que no siempre se cumple con todas las especificaciones que requieren y/o que esperan recibir los mismos, lo cual no sólo genera insatisfacción al grupo de trabajo tanto de cara al cliente como del proveedor de software, sino también genera sobrecostos al proyecto, retrasos en los tiempos de entrega, reducción en los indicadores de calidad del proyecto, y mala imagen de los colaboradores involucrados hacia al cliente y hacia la compañı́a que provee los servicios de software. Actualmente se cuenta con todo el marco teórico que brindan las normas ISO y demás propuestas metodológicas que han sido implementadas a nivel mundial por empresas desarrolladoras de software de tamaño similar al de las mi pymes en Colombia, o incluso de mayor tamaño pero que pueden tomarse como punto de referencia para mejorar el proceso de desarrollo de software.. 1.2. OBJETIVOS. Objetivo General. − Elaborar una personalización metodológica por medio de la investigación de las buenas prácticas del mercado para el aseguramiento de la calidad del software implementado por mi pymes.. 21.

(22) 22. D E S C R I P C I Ó N D E L A I N V E S T I G A C I Ó N. Objetivos Especı́ficos. − Investigar los aspectos definidos en las normas internacionales ISO para el aseguramiento de la calidad de un producto de software por medio del internet y demás registros documentales. − Analizar las falencias de calidad más comunes en un producto de software por medio de la retroalimentación de las mi pymes para focalizar la problemática existente. − Analizar la arquitectura de negocio para el proceso de levantamiento de requerimientos de Efron Colombia. 1.3. J U S T I F I C A C I Ó N D E L A I N V E S T I G A C I Ó N. Justificación Teórica Basado en las normas ISO principalmente en la norma 15504, la cual demarca todos los aspectos generales sobre el aseguramiento de la calidad, y apoyado en otras buenas prácticas estandarizadas y/o acogidas a nivel mundial se debe buscar definir y delimitar a un nivel especı́fico el marco teórico sobre el aseguramiento de la calidad de los productos de software. Justificación Metodológica Tomando la delimitación teórica que brindan las normas ISO y enfocado en las metodologı́as propias de cada mi pyme, se debe estructurar una propuesta metodológica flexible que permita mejorar la calidad de los productos de software implementados por las mi pymes. Justificación Práctica Como resultado del proceso investigativo se busca mejorar la satisfacción del cliente incrementando la calidad de los productos de software que le son entregados, lo cual generará un efecto beneficioso de forma transversal al cliente y a la misma mi pyme, dado que esto reducirá los sobrecostos de las implementaciones, los tiempos de retroalimentación, la imagen y las relaciones entre los participantes de los grupos de trabajo tanto de parte del cliente como de parte del grupo de trabajo que implementa la solución de software..

(23) 1.4 H I P Ó T E S I S. 1.4. H I P Ó T E S I S. Al estructurar una personalización metodológica para la gestión del conocimiento que garantice el aseguramiento de la calidad del software implementado por mi pymes, se obtendrá un valor agregado para los clientes y a su vez para las mismas mi pymes, dado que esto generará de forma implı́cita una tranquilidad y seguridad hacia el cliente, quien sabrá que el producto que está recibiendo de parte de la mi pyme es un producto que satisface sus necesidades funcionales y no funcionales, y adicionalmente traerá beneficios para la compañı́a. La personalización metodológica le dará a la gerencia del proyecto de parte de la mi pyme una lı́nea base para lograr el aseguramiento de la calidad del software que le será entregado al cliente, dado le brindará mecanismos metodológicos para gestionar tanto como los clientes externos e internos del proyecto, logrando un mayor acompañamiento y retroalimentación de parte de todo el equipo de trabajo, dando como resultado un producto con el mayor nivel de calidad posible, adicionalmente está personalización metodológica dará insumos y/o herramientas para poder identificar indicadores de medición, los cuales podrán evaluarse y hacer seguimiento por medio de una trazabilidad, la cual permitirá determinar las acciones a tomar durante la ejecución del proyecto de implementación del software implementado por una mi pyme. Es aquı́ donde toma relevancia la implementación de unos productos de software que apoyen la gestión de requerimientos y los indicadores del proyecto, su trazabilidad, la generación de una serie de reportes detallados, consolidados y gerenciales que permitan analizar y mostrar el comportamiento de las mediciones realizadas durante la implementación del producto de software; está herramienta tecnológica también deberá mostrar el estado actual e histórico de cualquier proyecto que haya sido registrado en dicho software en un periodo de tiempo determinado, es decir, debe visualizar la información entre periodos de tiempo que el usuario requiera. Todo lo anterior apalancará de forma transversal el proceso de mejora continua de la mi pyme, dado que brindará información relevante y muy oportuna para identificar puntos de control, puntos de medición, identificación de factores de riesgos y un sin número de información que permitirá que el software que se está implementando tenga un curva de maduración mucho más corta, y su vez permitirá que la misma mi pyme se convierta en una organización más estructurada, más metódica, con mejores controles de calidad, y a su vez más confiable para los clientes actuales y futuros, los cual les brindará un plus en el mercado que en la medida del tiempo se verá reflejado en sus indicadores financieros.. 23.

(24) 24. D E S C R I P C I Ó N D E L A I N V E S T I G A C I Ó N. 1.5. MARCO REFERENCIAL. Marco Teórico La norma ISO 15504 o SPICE por su nombre en inglés, Software Process Improvement Capability Determination, es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software, dentro de la cual se define el Modelo de procesos de referencia como los procesos contenidos en la norma ISO 12207.[12] Normalmente, en la mejora de la calidad de los procesos participan dos tipos de modelos, el modelo de procesos y el modelo de evaluación. El modelo de procesos define un catálogo o colección estructurada de buenas prácticas que describen las caracterı́sticas de un proceso efectivo, mientras que el modelo de evaluación proporciona los principios para realizar una evaluación de la calidad, e implantación, de dicho modelo de procesos en una organización.[5] Establece un marco y los requisitos para cualquier fase de evaluación de procesos y proporciona requisitos para los modelos de evaluación de estos. Proporciona también requisitos para cualquier modelo de evaluación de organizaciones. Proporciona guı́as para la definición de las competencias de un evaluador de procesos. Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad. Proporciona, en su parte 5, un Modelo de evaluación de procesos para las fases de ciclo de vida del software definidos en el estándar ISO 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. Proporciona, en su parte 6, un Modelo de evaluación de procesos para las etapas de ciclo de vida del sistema, definidos en el estándar ISO 15288 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de sistemas. Proporcionará, en su parte 8, un Modelo de evaluación de procesos para los procesos de servicios TIC que serán definidos en el estándar ISO 20000-4 que definirá los procesos contenidos en la norma ISO 20000-1. Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de esta última con 15504. [12] Marco Conceptual Los sistemas de gestión están pensados para apoyar la gestión de procesos de una organización y tienen como objetivo establecer y alcanzar unos indicadores previamente definidos por la dirección. Las organizaciones que tiene sistematizados sus procesos o cuentan con software que apoya dicha labor obtienen ventajas sobre sus competidores directos, dado que pueden evidenciar las fortalezas o debilidades que presentan en determinado momento y basados en la información que se provee a la dirección, la organización puede tomar decisiones estratégicas frente el mercado cambiante..

(25) 1.6 M E T O D O L O G Í A D E L A I N V E S T I G A C I Ó N. Las normas ISO se constituyen en una serie de estándares que se pueden agrupar por familias, según los distintos aspectos relacionados con la calidad. Aunque existen más de 18.000 normas publicadas por ISO, se pueden clasificar las normas según el siguiente criterio, normas relacionadas directamente con la calidad, normas relacionadas con la calidad en el medio ambiente y sostenibilidad, normas relacionadas con la gestión de la seguridad y normas relacionadas con la calidad en la investigación y desarrollo.[9] Marco Espacial El objetivo de este proceso investigativo es apoyar a las mi pymes que desarrollan productos de software en la ciudad de Bogotá, para que basado en el resultado de la propuesta metodológica se mejore el proceso de implementación de desarrollo de software y mejoren sus procesos internos. Marco Histórico Dı́a a dı́a las compañı́as en general buscan como optimizar los procesos y los resultados financieros para mitigar los gastos, los sobrecostos e incrementar la rentabilidad, basado en esto se busca por medio de este proceso investigativo apoyar dicha labor y optimizar el uso de los recursos fı́sicos, financieros y del mismo capital humano. Marco Legal Este proceso investigativo directamente no está enmarcado en un ámbito legal, pero si puede mitigar o subsanar el incumplimiento de algunas cláusulas contractuales asociadas al aseguramiento de la calidad que pueden llegarse a presentarse durante la ejecución de un proyecto de implementación de un producto de software. 1.6. M E T O D O L O G Í A D E L A I N V E S T I G A C I Ó N. Tipo de Estudio El tipo de estudio que se va a emplear en este proceso investigativo va a ser experimental, dado que se busca construir una personalización metodológica para el aseguramiento de la calidad del software implementado por mi pymes, y por lo mismo se debe tomar como base lo existente y lo recomendado por las normas ISO, lo implementado por otras compañı́as, las buenas practicas acogidas a nivel mundial y engranar todo lo anterior para proyectarlo y hacerlo encajar con las especificaciones metodológicas del más bajo nivel posible para obtener el resultado esperado.. 25.

(26) 26. D E S C R I P C I Ó N D E L A I N V E S T I G A C I Ó N. Método de Investigación El holotipo de investigación a utilizar es proyectivo con un nivel comprensivo, lo cual implica encontrar una relación con todos los factores inmersos en este proceso investigativo, enfatizando las relaciones de causalidad, y teniendo como objetivo la propuesta metodológica. Fuentes y Técnicas para la recolección de la Información En este proceso investigativo se van a utilizar las fuentes de información primaria y secundaria, dado que se debe recoger información sobre el objeto de estudio, la cual ya existe y ha sido definida a nivel mundial, incluyendo la resultante de otros procesos investigativo y demás propuestas metodológicas ya implementadas, adicional a lo anterior se debe adicionar la información que se debe recolectar por medio de entrevistas que nos permitan identificar puntos de análisis para general una propuesta metodológica integral o que contemple varios escenarios que hoy en dı́a impactan los proyectos. Tratamiento de la Información El tratamiento que se le dará a la información será analı́tico, dado que se debe realizar un estudio a la información suministrada por compañı́as del sector de forma tal que se encuentren los puntos crı́ticos que impactan no solo al cliente sino a la misma mi pyme. Esto debido a que el concepto Calidad es subjetivo y cada proveedor de software y cliente lo puede interpretar desde un punto de vista diferente. 1.7. O R G A N I Z A C I Ó N D E L T R A B A J O D E G R A D O. La organización del trabajo de grado está delimitada por la fase de contextualización, en donde se determinan todos los aspectos del planteamiento del problema y los mecanismos para dar solución a la problemática; seguida de la parte del desarrollo de la investigación, en donde se detalla la fase de arquitectura y diseño de la solución tecnológica; y por último la fase final, donde se relacionan las reflexiones resultantes del mismo, lo cual todo depende en gran medida de la información suministrada por las pymes para analizar los puntos que requieren mejora o una reestructuración bien sea nivel del proceso o a nivel de la metodologı́a utilizada según sea el caso. 1.8. ESTUDIO DE SISTEMAS PREVIOS. Se realizó el estudio previo a dos mi pymes, las cuales se dedican a realizar implementaciones de software a diferentes tipos de clientes y mercados, encontrando allı́ que cada una de las organizaciones enfoca sus esfuerzos en entregar un software de calidad a sus clientes, pero gestionando diferentes indicadores..

(27) Parte II A R Q U I T E C T U R A Y D I S E Ñ O.

(28)

(29) 2 O R G A N I Z A C I Ó N. 2.1. EMPRESA. En el año de 1999 en la ciudad de Bogotá se constituyó Consult Soft Ltda, la cual desde sus inicios se forjó como una empresa de desarrollo de Software a la medida sobre tecnologı́a Oracle, por lo mismo con el tiempo se certificó como partner Oracle, ası́ poco a poco y gracias al trabajo y a la dedicación de sus fundadores, Consult Soft empezó a crecer para consolidarse en una de las empresas con un posicionamiento relevante en el mercado, no solo del sector privado sino también en el sector público. Es ası́ como se inició la lı́nea de consultorı́a especializada, contratando y desarrollando el talento humando en áreas como la arquitectura de aplicaciones, la administración de bases de datos, el afinamiento de aplicaciones y la implantación y configuración de servidores de aplicaciones. Esto último permitió que a la compañı́a llegarán nuevos inversionistas, quienes después de un tiempo finalmente adquirieron la compañı́a en su totalidad. Gracias a la buena gestión que realizaron los nuevos dueños, se logró una alianza con la multinacional de origen español Efron Consulting, lo cual generó el cambio de razón social a Efron Colombia S.A.S., y bajo este nuevo nombre se han comprado otras compañı́as nacionales que han permitido diversificar las lı́neas de servicio de la empresa. En la actualidad se presenta una dificultad en el momento de la entrega de los productos de software a los usuarios funcionales, dado que no siempre se cumple con todas las especificaciones que requieren y/o que esperan recibir los mismos, lo cual no sólo genera insatisfacción al grupo de trabajo tanto de cara al cliente como del proveedor de software, sino también genera sobrecostos al proyecto, retrasos en los tiempos de entrega, reducción en los indicadores de calidad del proyecto, y mala imagen de los colaboradores involucrados hacia al cliente y hacia la compañı́a que provee los servicios. 29.

(30) 30. O R G A N I Z A C I Ó N. de software.. Figura 1: Efron Consulting[4] 2.1.1. Misión. Soportada por más de 800 empleados a través de Europa, LatinoAmerica y los Estados Unidos, nuestra misión es ayudar a nuestros clientes a cumplir sus metas haciéndolos más competitivos a través del cumplimiento de la excelencia en TI. Como consultores TI y asesores contables, nos enorgullecemos en escuchar a nuestros clientes para poder identificar necesidades y ofrecer soluciones de necesidad especı́fica. Estamos orgullosos de saber que 500 empresas de Fortune’s Global nos confı́an proyectos que impactan decenas de miles, sino millones, de sus clientes alrededor del mundo.. 2.1.2. Visión. En el año 2020, EFRON será reconocida por sus clientes como una compañı́a eficaz en la entrega de productos y servicios tecnológicos en el mercado global, facilitando de esta manera que se desarrollen relaciones a largo plazo y siendo percibidos por nuestros clientes como aliados estratégicos de negocios tecnológicos. Contaremos con colaboradores motivados y orientados al logro de objetivos, quienes tendrán las competencias necesarias para ser considerados como consultores de negocios, lo cual permitirá diferenciarnos de la competencia. Ası́ mismo, para el año 2022 EFRON posicionará sus productos, entregando soluciones confiables y flexibles a sus clientes, lo que les permitirá adaptar sus negocios a las condiciones cambiantes del mercado.. 2.1.3. Objetivos de Calidad. − Incrementar la satisfacción de nuestros clientes..

(31) 2.1 E M P R E S A. − Cumplir los requisitos establecidos por el cliente. − Cumplir las metas establecidas para ventas y rentabilidad de la organización. − Mejorar el clima organizacional. − Incursionar en nuevos mercados. − Mejorar las competencias del personal de la organización. − Mejorar el Sistema de Gestión de Calidad.. 2.1.4. Objetivos de la Organización. − Desarrollar soluciones de software capases de resolver las necesidades de nuestros clientes. − Brindar servicios de consultorı́a y soporte óptimos que promuevan el buen desempeño de la organización de nuestros clientes.[2]. 31.

(32)

(33) 3 FA S E D E A R Q U I T E C T U R A D E N E G O C I O S. La fase de arquitectura de negocios tiene una correspondencia con la capa de negocios donde se hace referencia a la estructura estática de una organización, en términos de entidades que componen la organización y sus relaciones. Las entidades activas son los sujetos como por ejemplo actores del negocio o roles del negocio, que ejecutan procesos de negocio o funciones. Los actores del negocio pueden ser individuos pero también grupos y recursos que permanecen a través de la organización. Las entidades pasivas son los objetos de negocio que son manipulados por algún comportamiento tal como un proceso de negocio o una función y representan los conceptos importantes en los cuales la empresa piensa en un ámbito.[7] La mejora forma de interpretar los diferentes componentes a evaluar en la capa de negocios se pueden resumir en el siguiente cuadro resumen de los conceptos: Cuadro 1: Conceptos Capa de Negocio Descripción. Concepto Actor de Negocio. Rol de Negocio. Colaboración Negocio. de. Notación. Entidad organizacional que es capaz de comportamiento de ejecución Responsabilidad de realizar acciones especı́ficas según su comportamiento, ante el cual un actor puede ser asignado Agregado de dos o más roles de negocio que trabajan juntos para realizar comportamiento colectivo.. 33.

(34) 34. FASE DE ARQUITECTURA DE NEGOCIOS. Concepto Interfaz de Negocio Localización. Objeto de Negocio. Proceso de Negocio. Función de Negocio. Interacción de Negocio Evento de Negocio. Servicio de Negocio Representación. Meaning. Cuadro 1: Conceptos Capa de Negocio Descripción Un punto de acceso donde un servicio comercial está disponible para el medio ambiente. Un punto o extensión conceptual en el espacio. Un elemento pasivo que tiene relevancia de una perspectiva comercial. Un elemento de comportamiento que agrupa el comportamiento basado en un orden de actividades. Es destinado a producir un conjunto definido de productos o servicios comerciales. Un elemento de comportamiento que agrupa el comportamiento basado en un conjunto de criterios elegidos (tı́picamente recursos comerciales requeridos y / o competencias). Un elemento de comportamiento que describe la comportamiento de una colaboración empresarial. Algo que sucede (internamente o externamente) e influye en el comportamiento. Un servicio que satisface una necesidad comercial de un cliente (interno o externo al organización). Una forma perceptible de la información llevado por un objeto comercial. El conocimiento o experiencia presente en un objeto comercial o su representación, dado un contexto particular.. Notación.

(35) 3.1 P U N T O D E V I S TA D E O R G A N I Z A C I Ó N. Concepto Valor. Producto. Contrato. 3.1 3.1.1. Cuadro 1: Conceptos Capa de Negocio Descripción El valor relativo, la utilidad o la importancia de un servicio o producto comercial. Una colección coherente de servicios, acompañado de un contrato / conjunto de acuerdos, que se ofrece en su conjunto para (internos o externos) clientes. Una especificación formal o informal de acuerdo que especifica los derechos y obligaciones asociadas con un producto.. Notación. P U N T O D E V I S TA D E O R G A N I Z A C I Ó N. Metamodelo. Este punto de vista se enfoca en la organización interna de una compañı́a, un departamento, una red de compañı́as o cualquier otra entidad organizacional. En este punto de vista es posible presentar modelos como diagramas de bloques anidados, o también, en una forma más tradicional como los organigramas. El punto de vista de organización es muy útil en la identificación de competencias, autoridad y responsabilidades en una organización.. Figura 2: Punto de Vista de Organización[7, 3]. 35.

(36) 36. FASE DE ARQUITECTURA DE NEGOCIOS. 3.1.2. Modelo. EFRON es una compañı́a que enfoca sus esfuerzos en las instalaciones del cliente a través de un consultor que reporta a un Director General y quien compone la Oficina de Gerencia de Proyectos (PMO por sus siglas en ingles).. Figura 3: Modelo de Organización. Fuente: Autor. 3.2 3.2.1. P U N T O D E V I S TA D E C O O P E R A C I Ó N D E A C T O R. Metamodelo. El punto de vista de cooperación del actor se enfoca en la relación que tienen los actores entre si y de estos con su entorno. Un ejemplo común de esto es el diagrama de contexto, el cual ubica una organización en su ambiente, que consiste en las partes externas tales como clientes, proveedores y otros aliados de negocio. Es muy útil a la hora de determinar dependencias y colaboraciones externas, y muestra la cadena de valor o la red en la que el actor opera..

(37) 3.2 P U N T O D E V I S TA D E C O O P E R A C I Ó N D E A C T O R. Otro uso importante del punto de vista de cooperación de actor es mostrar como un número de actores de negocio cooperantes y/o componentes de aplicación realizan juntos un proceso de negocio. Por lo tanto, en esta vista, tanto actores de negocio como roles y componentes de aplicación pueden aparecer.. Figura 4: Punto de Vista de Cooperación de Actor[7, 3]. 3.2.2. Modelo. En el levantamiento de requerimientos logramos identificar que la especificación del proyecto y los lineamientos de calidad son los puntos convergentes entre el consultor y el director regional, y entre este y la PMO respectivamente. Aplicados en el proceso el cliente va a ser requerido para entrevistas, reuniones y teleconferencias.. 37.

(38) 38. FASE DE ARQUITECTURA DE NEGOCIOS. Figura 5: Modelo de Cooperación de Actor. Fuente: Autor. 3.3 3.3.1. P U N T O D E V I S TA D E F U N C I Ó N D E N E G O C I O. Metamodelo. El punto de vista de función de negocio muestra las funciones de negocio principales de una organización y sus relaciones en términos de flujo de información, valor o bienes entre ellos. Las funciones de negocio son usadas para representar los aspectos más estables de una compañı́a en términos de las actividades primarias que esta desempeña, a pesar de los cambios organizacionales o los desarrollos tecnológicos. Por lo tanto la arquitectura de función de negocio de compañı́as que operan en el mismo mercado a menudo exhibe mucha similaridad. De esta forma el punto de vista de función de negocio provee información de alto nivel en las operaciones generales de la compañı́a,.

(39) 3.3 P U N T O D E V I S TA D E F U N C I Ó N D E N E G O C I O. y puede ser usada para identificar las competencias necesarias o para estructurar una organización de acuerdo a sus actividades principales.. Figura 6: Punto de Vista de Función de Negocio[7, 3]. 3.3.2. Modelo. Para el proceso de levantamiento de requerimientos en EFRON se reconocen dos roles fundamentales, el director general y el consultor, donde el director es un especialista en gerencia de proyectos el cual tiene como funciones del proceso el estimar y analizar costos de los proyectos, asignar consultores y recursos fı́sicos, transmitir los lineamientos de calidad que la PMO ha determinado aplicar al proyecto, realizar seguimiento de la ejecución, gestionar pagos y cierre del proyecto. A su vez el consultor que es un ingeniero de sistemas, debe aplicar los lineamientos de calidad para el levantamiento y análisis de los requerimientos para luego elevar las inquietudes y sugerir mejoras del proceso al cliente, documentar los requerimientos depurados y gestionar la aprobación del requerimiento para pasarlo a la siguiente fase dentro de EFRON para el desarrollo de software a la medida; es importante resaltar que el consultor se encuentra en constante retroalimentación con el director regional como parte del seguimiento del proyecto.. 39.

(40) 40. FASE DE ARQUITECTURA DE NEGOCIOS. Figura 7: Modelo de Función de Negocio. Fuente: Autor.

(41) 3.4 P U N T O D E V I S TA D E P R O C E S O D E N E G O C I O. 3.4 3.4.1. P U N T O D E V I S TA D E P R O C E S O D E N E G O C I O. Metamodelo. El punto de vista de proceso de negocio es usado para mostrar la estructura de alto nivel y la composición de uno o más procesos de negocio. Junto a los procesos como tal, este punto de vista contiene otros conceptos directamente relacionados, tales como:. − Los servicios que un proceso de negocio ofrece al mundo exterior, mostrando como un proceso contribuye a la realización de los productos de la compañı́a. − La asignación de procesos de negocio a roles que le dan significado a las responsabilidades de los actores asociados. − La información usada por los procesos de negocio. Cada uno de estos puede ser entendido como un subproceso de la vista de proceso de negocio.. Figura 8: Punto de Vista de Proceso de negocio[7, 3]. 41.

(42) 42. FASE DE ARQUITECTURA DE NEGOCIOS. 3.4.2. Modelo. Las diferentes solicitudes de mejora a sus procesos de negocio que realizan los clientes a EFRON son cubiertas por el servicio de levantamiento de requerimientos. Ese proceso tiene como lineamiento corporativo la calidad y la búsqueda de la satisfacción del cliente lo cual conlleva los procesos de análisis del problema, sugerencias de mejora y documentación del problema. El consultor durante el proceso puede recibir el apoyo del gerente regional en cualquier momento que sea requerido para encontrar otros puntos de vista que puedan ayudar a la resolución del problema y que ası́ se pueda constituir un documento de requerimientos de alta calidad.. Figura 9: Modelo de Proceso de Negocio. Fuente: Autor. 3.5 3.5.1. P U N T O D E V I S TA D E C O O P E R A C I Ó N D E P R O C E S O D E N E G O C I O. Metamodelo. El punto de vista de cooperación de proceso de negocio es usado para mostrar las relaciones de uno o más procesos de negocio con los demás procesos de negocio y / o.

(43) 3.5 P U N T O D E V I S TA D E C O O P E R A C I Ó N D E P R O C E S O D E N E G O C I O. con su ambiente. Puede ser usado tanto para crear un diseño de alto nivel de procesos de negocio dentro de su contexto como para proveer un responsable administrador operacional para uno o más de tales procesos con mando en sus dependencias. Son aspectos importantes del punto de vista de cooperación de procesos de negocio:. − Relación causal entre los principales procesos de negocio de la empresa. − Mapeo de los procesos de negocio a las funciones de negocio. − Realización de servicios por procesos de negocio. − Uso de datos compartidos. Cada uno de estos puede ser considerado como una ”sub-vista”de la vista de cooperación de procesos de negocio.. Figura 10: Punto de Vista de Cooperación de Proceso de Negocio[7, 3]. 43.

(44) 44. FASE DE ARQUITECTURA DE NEGOCIOS. 3.5.2. Modelo. En el proceso de levantamiento de requerimientos es clave para el éxito trabajar de la mano del cliente para logara el documento de requerimientos. Sin esa colaboración de los diferentes actores del proceso de negocio del cliente no será un documento completo y puede que termine retrasando la fase de desarrollo de software. Es por eso que insistimos en la interacción entre EFRON y el cliente.. Figura 11: Modelo de Cooperación de Proceso de Negocio. Fuente: Autor. 3.6 3.6.1. P U N T O D E V I S TA D E P R O D U C T O. Metamodelo. El punto de vista del producto muestra el valor que estos productos ofrecen a los clientes u otras partes externas involucradas y muestra la composición de uno o más productos en términos de sus servicios constituyentes (aplicación o negocios) y los contratos asociados u otros acuerdos. También puede ser usado para mostrar las interfaces (canales) a través de los cuales este producto es ofrecido, y los eventos asociados con el producto. El punto de vista del producto es tı́picamente usado en el desarrollo de producto para diseñar un producto por composición de servicios ofrecidos o identificando cuales servicios nuevos tienen que ser creados para este producto, dado el valor que un cliente espera de este. Puede entonces servir como entrada para arquitectos de proce-.

(45) 3.6 P U N T O D E V I S TA D E P R O D U C T O. sos de negocio y otros que necesitan diseñar los procesos e igualmente realizar estos productos.. Figura 12: Punto de Vista de Producto[7, 3]. 3.6.2. Modelo. Para el consultor de EFRON prestar los servicios de entendimiento y análisis del problema y la retroalimentación y sugerencias del problema de forma correcta constituyen un documento de requerimientos bajo estándares de calidad como producto o materia prima para el desarrollo de software a la medida. Es sumamente importante el momento en que se da la retroalimentación del gerente regional al proceso de levantamiento de requerimientos porque puede ayudar a dilucidar soluciones o mejoras lo cual es considerado una oferta de valor para el cliente en el producto terminado, y que al tener. 45.

(46) 46. FASE DE ARQUITECTURA DE NEGOCIOS. alta la satisfacción del cliente se facilita la elaboración y consecución del contrato de acuerdo de pagos.. Figura 13: Modelo de Producto. Fuente: Autor.

(47) 4 FA S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I Ó N. La fase de arquitectura de sistemas de información tiene una correspondencia con la capa de aplicación en donde el principal concepto de estructura activa es el componente de aplicación. Este concepto es usado para modelar cualquier entidad estructural como son componentes de software que pueden ser parte de una o más aplicaciones, aplicaciones completas, sub-aplicaciones o sistemas de información. Los componentes inter-relacionados son un ingrediente esencial, por eso es que se introduce el concepto de colaboración de aplicación definido por un colectivo de componentes los cuales ejecutan aplicaciones. [7] Veamos los componentes de la capa de aplicación en la siguiente imagen:. Cuadro 2: Conceptos Capa de Aplicación Concepto Descripción Una parte modular, implementable y reemplazable de un sistema de softwaComponente re que encapsula su comportamiento y de Aplicación datos y los expone a través de un conjunto de interfaces. Un agregado de dos o más componentes de aplicación que trabajan juntos Colaboración para realizar un comportamiento code Aplicaciolectivo. nes. Notación. 47.

(48) 48. F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I Ó N. Cuadro 2: Conceptos Capa de Aplicación Concepto Descripción Un punto de acceso donde un servicio de aplicación está disponible para un Interfaz de usuario u otro componente de aplicaAplicación ción. Objeto de Datos Función de Aplicación. Interacción de Aplicaciones Servicio de Aplicación. 4.1 4.1.1. Notación. Un elemento pasivo adecuado para el procesamiento automatizado.. Un elemento de comportamiento que agrupa el comportamiento automatizado que puede realizar un componente de la aplicación. Un elemento de comportamiento que describe el comportamiento de una colaboración de aplicaciones. Un servicio que expone el comportamiento automatizado.. P U N T O D E V I S TA D E U S O D E L A A P L I C A C I Ó N. Metamodelo. El punto de vista de uso de aplicación describe como las aplicaciones son usadas para soportar uno o más procesos de negocio, y como ellos son usados por otras aplicaciones. Puede ser usado en el diseño de una aplicación para identificar los servicios requeridos por los procesos de negocios y otras aplicaciones, o en el diseño de procesos de negocio para describir los servicios que están disponibles. Ası́, al identificar las dependencias de.

(49) 4.1 P U N T O D E V I S TA D E U S O D E L A A P L I C A C I Ó N. los procesos de negocio sobre las aplicaciones, puede ser útil para los administradores operativos responsables de estos procesos.. Figura 14: Punto de Vista de Uso de Aplicación[7, 3] 4.1.2. Modelo. El proceso de levantamiento de requerimientos y su producto el documento de requerimientos deberı́an ser soportados por un servicio de software de Gestión de Requerimientos el cual es soportado por el componente del gestor de requerimientos. El documento de requerimientos es soportado por el reporte del levantamiento de requerimientos que se extrae del software.. 49.

(50) 50. F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I Ó N. Figura 15: Modelo de Uso de Aplicación. Fuente: Autor. 4.2 4.2.1. P U N T O D E V I S TA D E C O M P O R TA M I E N T O D E L A A P L I C A C I Ó N. Metamodelo. El punto de vista de comportamiento de aplicación describe el comportamiento interno de una aplicación. Por ejemplo, de qué forma se realizan uno o más servicios de aplicación. Este punto de vista es útil en el diseño del comportamiento general de aplicaciones, o en la identificación de interferencias funcionales entre diferentes aplicaciones..

(51) 4.2 P U N T O D E V I S TA D E C O M P O R TA M I E N T O D E L A A P L I C A C I Ó N. Figura 16: Punto de Vista de Comportamiento de Aplicación[7, 3]. 4.2.2. Modelo. Un software de gestión de requerimientos debe permitir gestionar las precondiciones de los requerimientos, gestionar las post condiciones de los requerimientos, gestionar los criterios de aceptación de los requerimientos, generar reportes y por supuesto y de gran importancia la gestión en sı́ de los requerimientos. Cabe destacar que la generación de reportes debe permitir generar un documento con los criterios de aceptación y el documento de levantamiento de información como producto para la fase de desarrollo de software.. 51.

(52) 52. F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I Ó N. Figura 17: Modelo de Comportamiento de Aplicación. Fuente: Autor. 4.3 4.3.1. P U N T O D E V I S TA D E C O O P E R A C I Ó N D E L A A P L I C A C I Ó N. Metamodelo. El punto de vista de cooperación de aplicación describe las relaciones entre los componentes de aplicación en términos de la información que fluye entre ellos, o en términos de los servicios que ellos ofrecen y usan. Este punto de vista es tı́picamente usado para crear una vista general del panorama de aplicaciones en una organización. También es.

(53) 4.3 P U N T O D E V I S TA D E C O O P E R A C I Ó N D E L A A P L I C A C I Ó N. usado para expresar la cooperación (interna) o la orquestación de servicios que unidos soportan la ejecución de un proceso de negocio.. Figura 18: Punto de Vista de Cooperación de Aplicación[7, 3]. 4.3.2. Modelo. Adentrándonos una capa más abajo en el modelo del software encontramos un back office que debe soportar el componente del gestor de requerimientos del cual destacamos el servicio de generación de reportes en el front office de la aplicación ya que va a ser la funcionalidad que nos va permitir obtener el documento de levantamiento de información y el documento de criterios de aceptación a través de una interfaz gráfica de usuario.. 53.

(54) 54. F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I Ó N. Figura 19: Modelo de Cooperación de Aplicación. Fuente: Autor. 4.4 4.4.1. P U N T O D E V I S TA D E E S T R U C T U R A D E L A A P L I C A C I Ó N. Metamodelo. El punto de vista de estructura de aplicación presenta la estructura de una o más aplicaciones o componentes. Es útil en el diseño o entendimiento de la estructura principal de las aplicaciones o componentes y de la información asociada; por ejemplo, para detallar la estructura de un sistema bajo construcción, o para identificar componentes de aplicaciones obsoletas que son apropiados para migración / integración..

(55) 4.4 P U N T O D E V I S TA D E E S T R U C T U R A D E L A A P L I C A C I Ó N. Figura 20: Punto de Vista de Estructura de Aplicación[7, 3] 4.4.2. Modelo. El componente de gestión de requerimientos debe poder basar la información de los documentos de levantamiento de información y criterios de aceptación en una carga masiva de información en un momento o varios momentos particulares de cada proceso de levantamiento de requerimientos. Dicha colaboración va permitir integrar archivos planos que los ingenieros pueden llegar a usa en situaciones donde la interfaz de la aplicación no sea usada.. Figura 21: Modelo de Estructura de Aplicación. Fuente: Autor. 55.

(56)

(57) 5 FA S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. La fase de arquitectura de tecnologı́a es correspondiente con la capa de tecnologı́a en la cual el nodo es usado para modelar entidades estructurales de un sistema; su comportamiento es modelado por una relación explicita entre los conceptos de comportamiento. También contamos con una interface de infraestructura la cual es una locación lógica donde los servicios de infraestructura son ofrecidos por un nodo que se accesará por otros nodos o componentes de aplicaciones desde la capa de aplicación. Los nodos pueden ser de dos tipos, dispositivo y sistema de software, donde el dispositivo modela un recurso computacional fı́sico sobre el cual los artefactos pueden ser desplegados para ejecución. Por otro lado el sistema de software es un componente que corre en un dispositivo. Las interrelaciones de componentes en la capa tecnológica son principalmente formadas por la infraestructura de comunicaciones, la cual modela las relaciones entre 2 o más nodos, a través de los cuales hay constante intercambio de información.[7] Todo esto lo podemos modelar con los siguientes conceptos resumidos:. Concepto. Cuadro 3: Conceptos Capa de Tecnologı́a Descripción. Nodo. Un recurso computacional sobre el cual artefactos pueden ser almacenados o desplegados para ejecución.. Dispositivo. Un recurso de hardware sobre el cual los artefactos pueden ser almacenado o desplegado para su ejecución.. Notación. 57.

(58) 58. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Concepto Network. Ruta de comunicación Interfaz de Infraestructura. Software del Sistema. Función de Infraestructura. Servicio de Infraestructura. Artefacto. 5.1 5.1.1. Cuadro 3: Conceptos Capa de Tecnologı́a Descripción. Notación. Un medio de comunicación entre dos o más dispositivos.. Un enlace entre dos o más nodos, a través del cual estos nodos pueden intercambiar datos. Un punto de acceso al que otros nodos y componentes de la aplicación pueden acceder a servicios de infraestructura ofrecidos por un nodo. Un entorno de software para tipos especı́ficos de componentes y objetos que se implementan en él en forma de artefactos.. Un elemento de comportamiento que agrupa el comportamiento infraestructural que puede realizar un nodo. Una unidad de funcionalidad externamente visible, proporcionada por uno o más nodos, expuesta a través de interfaces bien definidas y significativa para el entorno. Una pieza fı́sica de datos que se utiliza o produce en un proceso de desarrollo de software, o mediante el despliegue y la operación de un sistema.. P U N T O D E V I S TA D E I N F R A E S T R U C T U R A. Metamodelo. El punto de vista de infraestructura contiene los elementos de infraestructura de software y hardware que soportan la capa de aplicación, tales como dispositivos fı́sicos,.

(59) 5.1 P U N T O D E V I S TA D E I N F R A E S T R U C T U R A. redes o sistemas de software (por ejemplo, sistemas operativos, bases de datos y software de capa media).. Figura 22: Punto de Vista de Infraestructura[7, 3]. 5.1.2. Modelo. Por lineamientos corporativos de EFRON, la aplicación Gestor de requerimientos deberı́a ser desarrollada para correr sobre sistema operativo Linux y la base de datos debe ser Oracle. La forma cómo vamos a llegar la aplicación a la nube es a través del servidor de aplicaciones Oracle WebLogic y todo esto en el hosting contratado por EFRON para las soluciones internas y en el que soportan las aplicaciones de clientes cuando ellos requieren la tercerización del servicio o que la solución sea integral como Software como servicio.. 59.

(60) 60. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Figura 23: Modelo de Infraestructura. Fuente: Autor. 5.2 5.2.1. P U N T O D E V I S TA D E U S O D E I N F R A E S T R U C T U R A. Metamodelo. El punto de vista de uso de la infraestructura muestra como las aplicaciones están soportadas por el software y hardware de infraestructura: los servicios de infraestructura son despachados por los dispositivos; los sistemas de software y las redes son provistos a las aplicaciones. Este punto de vista juega un rol importante en el análisis de desempeño y escalabilidad, ya que relaciona la infraestructura fı́sica al mundo lógico de las aplicaciones. Es muy útil en determinar los requerimientos de desempeño y calidad de la infraestructura basada en las demandas de las muchas aplicaciones que la usan..

(61) 5.2 P U N T O D E V I S TA D E U S O D E I N F R A E S T R U C T U R A. Figura 24: Punto de Vista de Uso de Infraestructura[7, 3] 5.2.2. Modelo. El componente gestor de requerimientos es usado por el servidor de aplicaciones Oracle WebLogic del cual es importante resaltar como se especializa en la base de datos de Oracle en la cual se van a convertir todos los requerimientos en data estructurada gracias al correcto diligenciamiento por el consultor.. 61.

(62) 62. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Figura 25: Modelo de Uso de Infraestructura. Fuente: Autor. 5.3 5.3.1. P U N T O D E V I S TA D E O R G A N I Z A C I Ó N E I M P L E M E N TA C I Ó N. Metamodelo. El punto de vista de organización e implementación muestra como una o más aplicaciones son realizadas sobre la infraestructura. Esto comprende la asignación de aplicaciones (lógicas) y componentes en artefactos (fı́sicas), como Enterprise Java Beans, y el mapeo de la información utilizada por estas aplicaciones y componentes en la infraestructura de almacenamiento subyacente; por ejemplo, las tablas de las bases de datos o sus archivos. Las vistas de despliegue juegan un papel importante en el análisis de desempeño y escalabilidad, ya que relaciona la infraestructura fı́sica con el mundo lógico de las aplicaciones. En análisis de seguridad y riesgos, las vistas de despliegue son usadas para identificar, por ejemplo, las dependencias crı́ticas y los riesgos..

(63) 5.3 P U N T O D E V I S TA D E O R G A N I Z A C I Ó N E I M P L E M E N TA C I Ó N. Figura 26: Punto de Vista de Organización e Implementación[7, 3]. 5.3.2. Modelo. El modelo de organización e implementación nos muestra un componente gestor de requerimientos usado por el servidor de aplicaciones Oracle WebLogic para exponer el servicio de administración de requerimientos al consultor y orquestar los contenidos y estructurar las plantillas del documento de levantamiento de información y los criterios de aceptación; recordemos que en el momento que sea requerido por el consultor, él puede hacer una carga masiva de información.. 63.

(64) 64. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Figura 27: Modelo de Organización e Implementación. Fuente: Autor. 5.4 5.4.1. P U N T O D E V I S TA D E E S T R U C T U R A D E I N F O R M A C I Ó N. Metamodelo. El punto de vista de estructura de la información es comparable con los modelos tradicionales creados en el desarrollo de casi cualquier sistema de información. Muestra la estructura de la información usada en la empresa o en un proceso de negocio o aplicación especı́fica, en términos de tipos de datos o estructuras de clases. Ası́, este punto de vista puede mostrar como la información del nivel de negocio es representada en el nivel de aplicación en términos de las estructuras de datos usadas allı́, y como.

(65) 5.4 P U N T O D E V I S TA D E E S T R U C T U R A D E I N F O R M A C I Ó N. estas son luego mapeadas hacia la infraestructura subyacente.; por ejemplo, por medio de un esquema de base de datos.. Figura 28: Punto de Vista de Estructura de Información[7, 3]. 5.4.2. Modelo. Para logra representar la necesidad del cliente y los lineamientos de calidad es necesario definir un objeto de datos llamado requerimiento y otro llamado criterio de aceptación respectivamente en la capa de software. Dicho requerimiento compone una tabla de la base de datos llamada modulo la cual entrega información al proyecto. Este a su vez es alimentado por la información del objeto de datos cliente, completando ası́ toda la estructura del modelo de la base de datos de forma muy abstracta o de alto nivel.. 65.

(66) 66. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Figura 29: Modelo de Estructura de Información. Fuente: Autor. 5.5 5.5.1. P U N T O D E V I S TA D E R E A L I Z A C I Ó N D E L S E R V I C I O. Metamodelo. El punto de vista de realización del servicio es usado para mostrar como uno o más servicios de negocio son realizados por los procesos subyacentes (y algunas veces por componentes de aplicación). Ası́, se forma el puente entre el punto de vista de producto.

(67) 5.5 P U N T O D E V I S TA D E R E A L I Z A C I Ó N D E L S E R V I C I O. de negocio y la vista de proceso de negocio. Proporciona una ”vista desde afuera”sobre uno o más procesos de negocio.. Figura 30: Punto de Vista de Realización del Servicio[7, 3]. 5.5.2. Modelo. En EFRON la satisfacción de los clientes es fundamental y la forma como se logra es a través de la calidad del servicio, y es por eso que en el servicio de levantamiento de requerimientos se contemplan 2 objetos de negocio fundamentales para realizar dicho servicio y son la necesidad del cliente y los lineamientos de calidad los cuales van a ser parte fundamental de la aplicación de gestión de requerimientos constituyéndose como tablas de la base de datos para poder gestionar esa información de forma eficiente.. 67.

(68) 68. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Figura 31: Modelo de Realización del Servicio. Fuente: Autor. 5.6 5.6.1. P U N T O D E V I S TA D E C A PA S. Metamodelo. El punto de vista de capas muestra varias capas y aspectos de una arquitectura empresarial en un diagrama. Hay dos categorı́as de capas, las llamadas capas dedicadas y las llamadas capas de servicio. Las capas son el resultado del uso de la relación de “agrupamiento”para una división natural del conjunto entero de objetos y relaciones que hacen parte de un modelo. La capa de infraestructura, la de aplicación, la de proceso y la de actores/roles conforman la primera categorı́a. El principio estructural detrás de un punto de vista completamente de capas es que cada capa dedicada expone, por medio de la relación de “realización”, una capa de servicios que son más bien “usadas por”la siguiente capa dedicada. Ası́, podemos fácilmente separar la estructura interna y la organización de una capa dedicada de su comportamiento externamente observable expresado como la capa de servicio que la capa dedicada realiza..

(69) 5.6 P U N T O D E V I S TA D E C A PA S. Figura 32: Punto de Vista de Capas[7, 3] 5.6.2. Modelo. En resumen, el servicio de levantamiento de requerimientos con calidad para incrementar la satisfacción del cliente es realizado por el proceso del levantamiento de requerimientos el cual se desarrolla a un nivel de negocio, el cual genera la necesidad de controlar y gestionar dicho proceso a través de un gestor de requerimientos en una plataforma web, para lo cual es necesario soportar desde un servidor de aplicaciones Oracle WebLogic.. 69.

(70) 70. F A S E D E A R Q U I T E C T U R A D E T E C N O L O G Í A. Figura 33: Modelo de Capas. Fuente: Autor.

(71) 6 FA S E D E V I S I Ó N D E A R Q U I T E C T U R A. Los principales conceptos de ArchiMate se enfocan en describir la arquitectura de los sistemas que soportan a las empresas. Sin tener en cuenta están los elementos que motivan el diseño y la operación de la empresa. Estos aspectos motivacionales corresponden al ¿Por qué?, el cual fue intencionalmente dejado por fuera del alcance en el diseño de ArchiMate 1.0. Los conceptos motivacionales tales como objetivos, principios y requerimientos están direccionados de forma tal que la arquitectura empresarial es alineada a ese contexto y descrita por elementos motivacionales. Un elemento motivacional es definido como un elemento que provee el contexto o razón que está detrás de la arquitectura de una empresa, además que reconoce los conceptos de los Implicados (Stakeholder), lineamientos (driver/manejador) y valoraciones. Los Stakeholders representan las personas u organizaciones que influencian, guı́an o restringen a las empresas. Los lineamientos representan los factores internos y externos que influencian los planes y objetivos de las empresas. El entendimiento de las fortalezas, debilidades, oportunidades y amenazas en relación a los lineamientos ayudan a la formación de planes y objetivos que apropiadamente se direccionan a esos factores.[7]. Concepto. Stakeholder. Driver (Controlador). Cuadro 4: Conceptos Capa Motivacional Descripción El papel de un individuo, equipo u organización (o sus clases) que representa sus intereses o preocupaciones en relación con el resultado de la arquitectura.. Notación. Algo que crea, motiva y alimenta el cambio en una organización.. 71.

(72) 72. F A S E D E V I S I Ó N D E A R Q U I T E C T U R A. Concepto Assessment (Resultado). Cuadro 4: Conceptos Capa Motivacional Descripción El resultado de algún análisis de algún controlador.. Goal (Meta). Un estado final que una parte interesada intenta lograr.. Requerimiento. Una declaración de necesidad que debe ser realizada por un sistema.. Restricción Principle (Principio). Notación. Una restricción en la forma en que se realiza un sistema. Una propiedad normativa de todos los sistemas en un contexto dado, o la forma en que se realizan.. El principal objetivo de los conceptos motivacionales en ArchiMate es soportar los requerimientos de gestión los cuales establecen los objetivos de negocio de alto nivel, los principios de arquitectura y los requerimientos de negocio iniciales, y es por eso que los objetivos y principios deben ser traducidos en requerimientos antes que los elementos principales, tales como los servicios, procesos y aplicaciones que pueden ser asignados para realizarlos.[8]. Figura 34: Relación entre los elementos principales y los elementos motivacionales [7].

(73) 6.1 P U N T O D E V I S TA D E S TA K E H O L D E R. 6.1 6.1.1. P U N T O D E V I S TA D E S TA K E H O L D E R. Metamodelo. El punto de vista de Stakeholder permite al analista modelar los implicados, los lineamientos y las valoraciones en términos de fortalezas, debilidades, oportunidades y amenazas. Además, el vı́nculo con los objetivos principales que abordan estas preocupaciones e indicadores debe ser descrito. En general es importante entender que el implicado tiene un rol dentro de la organización y que el objetivo a analizar debe ser el más general de la unidad en análisis. Estos objetivos constituyen la base para el proceso de ingenierı́a de requerimientos ya que son la puerta para los requerimientos de la organización, mientras que los lineamientos (manejador) son una caracterı́stica fundamental de la misión del Stakeholder la cual termina siendo una función de alto nivel dentro de la organización.. Figura 35: Punto de Vista de Stakeholder[7, 3]. 6.1.2. Modelo. Basados en la contextualización del problema de la primera parte de este documento, el siguiente diagrama nos permite reconocer que elaborar un documento con los requerimientos del proceso y solucionar un problema crı́tico de la compañı́a, son 2 objetivos generales de Efron Colombia, y en especı́fico de su proceso de levantamiento de requerimientos, en donde el Consultor de EFRON ofrece un valor agregado en la relación con el Cliente, entendiendo su situación actual en busca del ahorro del dinero y tiempo, en uno o varios procesos de negocio en los que se pueda presentar algún cuello de botella,. 73.

(74) 74. F A S E D E V I S I Ó N D E A R Q U I T E C T U R A. y adicionalmente exista una opción de mejora desde el interior de la organización por los implicados.. Figura 36: Modelo de Stakeholder. Fuente: Autor. 6.2 6.2.1. P U N T O D E V I S TA D E R E A L I Z A C I Ó N D E O B J E T I V O S. Metamodelo. El punto de vista de realización de objetivos permite al diseñador modelar el refinamiento de los objetivos a un alto nivel en objetivos muy concretos para un posterior refinamiento adicional convirtiéndolos en requerimientos o en restricciones que describen las propiedades que son necesarias para realizar los objetivos. El refinamiento de objetivos en sub-objetivos es modelado usando la relación de agregación. El refinamiento de objetivos en requerimientos es modelado usando la relación de realización. Adicio-.

(75) 6.2 P U N T O D E V I S TA D E R E A L I Z A C I Ó N D E O B J E T I V O S. nal, los principios pueden ser modelados para guiar el refinamiento de los objetivos en requerimientos.. Figura 37: Punto de Vista de Realización de Objetivos[7, 3]. 6.2.2. Modelo. El punto de vista de realización de objetivos nos permite concluir que la “Elaboración de un documento de requerimientos de un proceso que cumpla con los estándares de calidad de EFRON y del cliente es a través la indagación y profundización del proceso,. 75.

(76) 76. F A S E D E V I S I Ó N D E A R Q U I T E C T U R A. del entendimiento de los problemas del negocio a través del trabajo con los actores del proceso, proponiendo alternativas de solución y definiendo un alcance de la solución.. Figura 38: Modelo de Realización de Objetivos. Fuente: Autor. 6.3 6.3.1. P U N T O D E V I S TA D E C O N T R I B U C I Ó N D E O B J E T I V O S. Metamodelo. El punto de vista de contribución de objetivos permite a un diseñador o analista modelar las relaciones de influencia entre los objetivos y los requisitos. Los puntos de vista resultantes pueden utilizarse para analizar el impacto que unos objetivos tienen sobre otros o para detectar conflictos entre los objetivos de las partes interesadas. Por lo general, este punto de vista se puede utilizar después de que los objetivos han sido refinados, en cierta medida, en subobjetivos y, posiblemente, en requisitos. Por lo tanto las relaciones de agregación y de realización también pueden aparecer en este punto de vista..

(77) 6.3 P U N T O D E V I S TA D E C O N T R I B U C I Ó N D E O B J E T I V O S. Figura 39: Punto de Vista de Contribución[7, 3] 6.3.2. Modelo. El modelo de contribución nos permite evidenciar que para elaborar un documento con calidad con los requerimientos del proceso en estudio, es necesario que el usuario o cliente del proceso suministre toda la información de las tareas que realiza el proceso. Para lograrlo encontramos que el consultor debe definir metodologı́as para el entendimiento con el usuario para lograr compenetrar con él y obtener la mayor información del proceso. Se detectó que la tarea se ve obstaculizada por una especie de rechazo natural al cambio que las personas sufrimos.. Figura 40: Modelo de Contribución. Fuente: Autor. 77.