UNIVERSIDAD CENTRAL DEL ECUADOR

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERÍA EN CIENCIAS FÍSICAS Y MATEMÁTICA INSTITUTO DE INVESTIGACIÓN Y POSGRADO (IIP) METODOLOGÍA PARA EL DESARROLLO DE SOFTWARE ESCALABLE PARA EL DEPARTAMENTO DE PENSIONES DEL IESS. WILLIAM FERNANDO POZO ALMEIDA TUTOR: JAIME OSWALDO SALVADOR MENESES Trabajo presentado como requisito parcial para la obtención del grado de: MAGÍSTER EN GESTIÓN INFORMÁTICA EMPRESARIAL Quito Ecuador 2015

DEDICATORIA Dedico está tesis a Dios, siempre se siente su incondicional apoyo, amor, cariño y sus infinitas bendiciones sobre mi familia. Cuando uno llega a ser padre llega a entender el sacrificio y esfuerzo de los padres, les dedico a ellos ya que gracias a ellos he tenido las decisiones mas atinadas en mi vida y sin el amor sincero y desinteresado de mi mamá Teresa Almeida nunca hubiera llegado a ser el buen ser humano que soy por esto este esfuerzo es solamente de ella. Dedico también esta tesis a mi familia Angélica Figueroa y Camila Pozo por su constante apoyo y amor, en los momentos difíciles ellas han tenido las palabras precisas para brindar un aliento para poder continuar, a mi hija Cammy te dedico esta tesis para te sirva de ejemplo para que el llegues a ser mucho más de lo que nosotros como padres hemos logrado. Fernando Pozo ii

AGRADECIMIENTO Siempre estaré agradecido a mi familia Angélica Figueroa y Camila pozo por su total apoyo y comprensión sin su amor nunca podría haber realizado esta tesis, quedo muy agradecido a mi esposa Ange por su constante cariño y dulzura, me ha servido de apoyo incondicional para poder concluir esta tesis. Agradezco a mamá Teresa Almeida, quien siempre ha desvelado por mi bienestar y educación, haciendo presente siempre su amor, gracias a mi padre Luis Edmundo Pozo por tu ejemplo y trabajo constante que tuviste no estas aquí pero siempre presente en nuestros corazones. Gracias a Jaime Salvador por brindar sus conocimientos y dedicación que ha brindado para la realización de esta tesis. Tengo un grato agradecimiento a Jaime Salvador, Ramiro Pilaluisa y Santiago Morales por sus conocimientos y ayuda que me ha brindado para poder concluir este documento. Fernando Pozo iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL Yo, WILLIAM FERNANDO POZO ALMEIDA en calidad de autor del trabajo de investigación o tesis realizada sobre la METODOLOGÍA PARA EL DESARROLLO DE SOFTWARE ESCALABLES PARA EL DEPARTAMENTO DE PENSIONES DEL IESS, por la presente autorizo a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de todos los contenidos que me pertenecen o de parte de los que contiene esta obra, con fines estrictamente académicos o de investigación. Los derechos que como autor me corresponden, con excepción de la presente autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los artículos 5, 6, 8, 19 y demás pertinentes de la Ley de Propiedad Intelectual y su Reglamento. Quito, 09 de Enero del 2015. WILLIAM FERNANDO POZO ALMEIDA C.C. 1715961692 iv

CERTIFICADO Certifico que el presente trabajo fue realizado en su totalidad WILLIAM FERNANDO POZO ALMEIDA como requisito parcial a la obtención del título de MAGISTER EN GESTIÓN INFORMÁTICA EMPRESARIAL. Quito, 9 de Enero del 2015 JAIME OSWALDO SALVADOR MENESES v

CONTENIDO DEDICATORIA... ii AGRADECIMIENTO... iii AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL... iv CERTIFICADO... v CONTENIDO... vi LISTA DE FIGURAS... xiv LISTA DE TABLAS... xv RESUMEN... xvii ABSTRACT... xviii 1 INTRODUCCIÓN... 1 1.1 INTRODUCCIÓN... 1 1.2 PLANTEAMIENTO DEL PROBLEMA... 2 1.3 OBJETIVO GENERAL... 2 1.4 OBJETIVOS ESPECÍFICOS... 3 1.5 JUSTIFICACIÓN... 3 1.6 HIPÓTESIS Y VARIABLES... 3 1.6.1 HIPÓTESIS... 3 1.6.2 VARIABLES - INDICADORES... 3 1.7 METODOLOGÍA... 4 1.7.1 TIPOS DE ESTUDIO... 4 1.7.2 DISEÑO DE ESTUDIO... 4 1.7.3 POBLACIÓN, MUESTRA Y MUESTREO... 5 vi

1.7.4 TÉCNICAS DE ANÁLISIS DE DATOS... 5 2 MARCO TEÓRICO... 6 2.1 INTRODUCCIÓN... 6 2.2 TERMINOLOGÍA BÁSICA... 6 2.2.1 UML... 6 2.2.2 WORKFLOW... 7 2.2.3 SOA... 7 2.2.4 BPM... 8 2.2.5 BPMN... 8 2.2.6 ESB... 9 2.2.7 OOAD... 9 2.2.8 CBM... 9 2.2.9 ARTEFACTOS... 10 2.2.10 APLICACIONES DISTRIBUIDAS... 10 2.2.11 ARQUITECTURA EMPRESARIAL... 10 2.2.12 LDAP... 10 2.2.13 SOAP... 11 2.2.14 HTTP... 11 2.2.15 W3C... 11 2.2.16 MODELO DE DOMINIO... 11 2.2.17 KPI... 11 2.3 METODOLOGÍA DE DESARROLLO DE SOFTWARE RUP... 12 2.3.1 DEFINICIÓN... 12 2.3.2 FASE DE INICIO... 13 2.3.3 FASE DE ELABORACIÓN... 14 2.3.4 FASE DE CONSTRUCCIÓN... 15 vii

2.3.5 FASE DE TRANSICIÓN... 16 2.3.6 ROLES... 18 2.4 SOFTWARE ESCALABLES... 19 2.5 ARQUITECTURA DE SOFTWARE BASADA EN SOA... 21 2.5.1 INTRODUCCIÓN... 21 2.5.2 TERMINOLOGÍA BÁSICA SOA... 23 2.5.2.1 MENSAJE... 23 2.5.2.2 SERVICIOS SIN ESTADO... 23 2.5.2.3 ORQUESTACIÓN... 24 2.5.2.4 BPEL... 24 2.5.2.5 BPM... 24 2.5.3 DEFINICIÓN DE SOA... 25 2.5.4 OBJETIVO DE LA ARQUITECTURA SOA.... 25 2.5.5 BENEFICIOS DE SOA... 25 2.5.6 DESVENTAJAS DE SOA:... 26 2.5.7 COMPONENTES DE SOA... 26 2.5.8 IMPLEMENTACIÓN DE SOA... 26 2.5.9 PLANIFICACIÓN DE DESARROLLO DE APLICACIONES SOA... 27 2.5.9.1.1 IDENTIFICACIÓN DE SERVICIOS... 27 2.5.9.1.2 SERVICIOS EXISTENTES... 28 2.5.9.1.3 PROTOCOLOS DE COMUNICACIÓN DE SERVICIOS... 30 2.5.9.1.4 ADMINISTRACIÓN DE LOS SERVICIOS... 32 2.5.9.2 COMUNICACIÓN ENTRE SERVICIOS... 33 viii

2.6 SEGURIDAD EN SERVICIOS WEB... 34 2.6.1 WS-Security... 35 2.6.2 XML ENCRYPTION... 36 2.6.3 XML SIGNATURE... 36 2.6.4 XML CANONICALIZATION... 36 3 ANÁLISIS DE METODOLOGÍA ACTUAL DE DESARROLLO DE SOFTWARE EN PENSIONES DEL IESS.... 37 3.1 INTRODUCCIÓN... 37 3.2 FASES DE LA METODOLOGÍA RUP PARA EL ÁREA DE PENSIONES.... 37 3.2.1 FASE DE FACTIBILIDAD... 37 3.2.2 FASE DE ELABORACIÓN... 43 3.2.3 FASE DE DESARROLLO... 45 3.2.4 FASE DE IMPLANTACIÓN... 46 3.3 EQUIPO DE TRABAJO... 48 3.3.1 PERFIL DE LOS RECURSOS... 48 3.3.1.1 GERENTE DE PROYECTO... 48 3.3.1.2 ADMINISTRADORA DE PROYECTOS... 50 3.3.1.3 LÍDERES DE PROYECTOS... 51 3.3.1.4 DESARROLLADOR JAVA... 52 3.3.1.5 INGENIERO DE PRUEBAS... 53 3.3.1.6 ARQUITECTO DE SOFTWARE... 53 3.3.1.7 ARQUITECTURA DE DATOS... 54 3.3.1.8 ANALISTAS DE SISTEMAS... 55 3.3.1.9 ANALISTAS FUNCIONALES... 56 3.3.1.10 LÍDER DE ANALISTAS... 57 ix

3.3.1.11 LÍDER DE PRUEBAS... 58 3.3.1.12 LÍDER DE DEPARTAMENTO DE ARQUITECTURA... 59 3.4 ORGANIGRAMA DE GESTIÓN DE PROYECTOS DEL IESS... 61 3.5 RECURSOS TECNOLÓGICOS... 62 3.5.1 RECURSOS DE HARDWARE... 62 3.5.2 RECURSO DE SOFTWARE... 62 3.5.2.1 SOFTWARE DE AMBIENTE DE DESARROLLO... 62 3.5.2.2 SOFTWARE DE AMBIENTE DE PRUEBAS / PRODUCCIÓN... 63 3.5.3 ARQUITECTURA DE SOFTWARE DEL SOFTWARE DE PENSIONES.... 63 3.5.3.1 CAPA DE APLICACIÓN... 63 3.5.3.1.1 CAPA MEDIA... 63 3.5.3.1.2 CAPA DE FACHADA... 64 3.5.3.2 SEGURIDAD DE APLICACIÓN... 65 3.5.4 CAMBIO DE AMBIENTE PARA PRODUCCIÓN... 65 3.6 CONCLUSIONES... 66 4 METODOLOGÍAS DE DESARROLLO PARA SOFTWARE ESCALABLES... 67 4.1 INTRODUCCIÓN... 67 4.2 CARACTERÍSTICAS DE LAS FASES DE ANÁLISIS Y DISEÑO DE METODOLOGÍAS SOA.... 68 4.2.1 ANÁLISIS SOA Y ESTRATEGIAS DE DISEÑO... 68 4.2.1.1 ENFOQUES DE SOA... 68 4.2.2 ANÁLISIS SOA Y COBERTURA DE DISEÑO... 70 4.2.3 ADOPCIÓN DE TÉCNICAS EXISTENTES Y NOTACIONES... 71 x

4.3 ANÁLISIS DE METODOLOGÍAS EXISTENTES SOA... 72 4.3.1 SOMA... 72 4.3.1.1 FASE DE IDENTIFICACIÓN... 74 4.3.1.2 FASE DE ESPECIFICACIÓN... 74 4.3.1.3 FASE DE REALIZACIÓN... 74 4.3.2 IBM RUP/SOMA... 74 4.3.2.1 ANÁLISIS DE TRANSFORMACIÓN DE NEGOCIOS... 75 4.3.2.2 IDENTIFICACIÓN... 75 4.3.2.3 ESPECIFICACIÓN... 75 4.3.2.4 REALIZACIÓN DE SERVICIOS... 76 4.3.3 SOAF... 76 4.3.3.1 DESCRIPCIÓN DE LA METODOLOGÍA... 77 4.3.4 METODOLOGÍA DE PAPAZOGLOU... 77 4.4 COMPARACIÓN ENTRE METODOLOGÍAS... 78 5 PROPUESTA DE METODOLOGÍA DE SOFTWARE ESCALABLE PARA EL IESS.... 80 5.1 INTRODUCCIÓN... 80 5.2 ROLES DE IBM RUP SOMA... 80 5.2.1 ARQUITECTO DE SEGURIDAD... 80 5.2.2 IMPLEMENTADOR... 81 5.2.3 DISEÑADOR DE NEGOCIOS... 81 5.2.4 ANALISTA DE PROCESO DE NEGOCIO... 81 5.2.5 DISEÑADOR DE BASE DE DATOS... 82 5.2.6 DISEÑADOR... 82 5.2.7 ARQUITECTO DE SOFTWARE... 83 5.2.8 ARQUITECTO DE NEGOCIO... 83 xi

5.3 TAREAS DE IBM RUP SOMA... 84 5.3.1 TAREAS DE MODELAMIENTO DE NEGOCIOS... 84 5.3.1.1 IDENTIFICACIÓN DE METAS DE NEGOCIOS Y KPIs.. 84 5.3.1.2 ANÁLISIS DEL ÁREA FUNCIONAL... 85 5.3.1.3 AFINAMIENTO DE CASOS DE USO DE NEGOCIO... 86 5.3.2 TAREAS DE ANÁLISIS Y DISEÑO... 87 5.3.2.1 IDENTIFICAR FACTORES COMUNES Y VARIABILIDAD... 87 5.3.2.2 IDENTIFICAR PATRONES DE SEGURIDAD... 87 5.3.2.3 ESPECIFICACIÓN DE COMPONENTES (SOA)... 88 5.3.2.4 CONSTRUIR PRUEBA DE CONCEPTO ARQUITECTÓNICO (SOA)... 88 5.3.2.5 IDENTIFICA SERVICIOS ASOCIADOS A OBJETIVOS 89 5.3.2.6 ANÁLISIS DE PROCESOS EMPRESARIALES... 90 5.3.2.7 ANÁLISIS DE MODELO DE DATOS... 90 5.3.2.8 ANÁLISIS DE ACTIVOS EXISTENTES... 91 5.3.2.9 ANÁLISIS DE REGLAS DEL NEGOCIO... 91 5.3.2.10 ANÁLISIS DE CASOS DE USO DE NEGOCIO (SOA). 92 5.3.2.11 DISEÑO DE MENSAJE... 92 5.3.2.12 PRUEBAS SERVICIOS LITMUS... 93 5.3.2.13 ESPECIFICACIÓN DE SERVICIO... 94 5.3.2.14 DISEÑO SUB SISTEMAS (SOA)... 95 5.3.3 TAREAS DE IMPLEMENTACIÓN... 96 5.3.3.1 DOCUMENTO DE DECISIONES DE REALIZACIÓN DE SERVICIO... 96 xii

5.4 PROPUESTA DE METODOLOGÍA RUP ENFOCADO EN SOA PARA EL DEPARTAMENTO DE PENSIONES DEL IESS.... 96 5.4.1 RECURSOS HUMANOS... 97 5.4.2 RECURSOS TECNOLÓGICOS... 97 5.4.3 ADAPTACIONES DE LA METODOLOGÍA RUP CON IBM RUP SOMA... 97 5.4.3.1 FASE DE FACTIBILIDAD... 97 5.4.3.2 FASE DE ELABORACIÓN... 100 5.4.3.3 FASE DE CONSTRUCCIÓN... 104 5.4.3.4 FASE DE IMPLEMENTACIÓN... 107 5.4.4 PLANIFICACIÓN DE PROYECTOS... 112 5.4.4.1 TAREAS ANTES DE INICIAR EL PROYECTO... 112 5.4.4.2 PLANIFICACIÓN FASE DE FACTIBILIDAD... 113 5.4.4.2.1 ESTIMACIÓN DE TIEMPOS... 115 5.4.4.3 PLANIFICACIÓN FASE DE ELABORACIÓN... 119 5.4.4.3.1 ESTIMACIÓN DE TIEMPOS... 120 6 CONCLUSIONES Y RECOMENDACIONES... 125 6.1 INTRODUCCIÓN... 125 6.2 CONCLUSIONES... 125 6.3 RECOMENDACIONES... 126 BIBLIOGRAFÍA... 128 BIOGRAFÍA... 131 xiii

LISTA DE FIGURAS Figura 2.1 Antes y después de SOA... 22 Figura 2.2 Identificación de servicios... 28 Figura 2.3 Modelo de un ESB... 34 Figura 3.1 Organigrama DDI con departamento de Pensiones... 61 Figura 3.2 Diagrama de cambios de ambiente para producción... 65 Figura 4.1 Diagrama de SOMA... 73 Figura 4.2 Gráfico de interacción entre fases SOMA... 73 Figura 5.1 Descomposición de negocio... 85 Figura 5.2 Diagrama de actividades de líder en fase inicial... 113 xiv

LISTA DE TABLAS Tabla 3.1 Fase de factibilidad RUP área de pensiones... 38 Tabla 3.2 Fase de elaboración RUP área de pensiones... 43 Tabla 3.3 Fase de desarrollo RUP área de pensiones... 45 Tabla 3.4 Fase de implantación RUP área de pensiones... 46 Tabla 3.5 Perfil gerente de proyectos área de pensiones... 49 Tabla 3.6 Perfil administrador de proyectos área de pensiones... 50 Tabla 3.7 Perfil de líder de proyectos área de pensiones... 51 Tabla 3.8 Perfil de desarrollador java área de pensiones... 52 Tabla 3.9 Perfil ingeniero de pruebas área de pensiones... 53 Tabla 3.10 Perfil arquitecto de software área de pensiones... 54 Tabla 3.11 Perfil de arquitectura de datos área de pensiones... 55 Tabla 3.12 Perfil de analistas de sistemas... 56 Tabla 3.13 Perfil de analistas funcionales... 57 Tabla 3.14 Perfil de líder de analistas... 57 Tabla 3.15 Perfil de líder de pruebas área de pensiones... 58 Tabla 3.16 Perfil de líder de departamento de arquitectura área de pensiones... 59 Tabla 3.17 Recursos de hardware del área de pensiones... 62 Tabla 3.18 Software de ambiente de desarrollo del área de pensiones... 62 Tabla 3.19 Software de ambiente de pruebas / producción del área de pensiones... 63 Tabla 3.20 Capa media de arquitectura de software de pensiones... 64 Tabla 3.21 Capa de fachada de arquitectura de software de pensiones. 64 Tabla 4.1 Comparación entre metodologías de desarrollo de software SOA... 79 Tabla 5.1 Entrada y salidas de identificación de metas... 84 Tabla 5.2 Entrada y salida de análisis del área funcional... 86 Tabla 5.3 Entrada y salida de casos de uso del negocio... 86 Tabla 5.4 Entrada y salida de identificar factores comunes... 87 Tabla 5.5 Entrada y salida de identificar patrones de seguridad... 88 xv

Tabla 5.6 Entrada y salida de especificación de componentes SOA... 88 Tabla 5.7 Entrada y salida Prueba de concepto arquitectónico SOA... 89 Tabla 5.8 Entrada y salida de identificar servicios asociados a objetivos 89 Tabla 5.9 Entrada y salida de análisis de procesos empresariales... 90 Tabla 5.10 Entrada y salida de análisis de modelos de datos... 90 Tabla 5. 11 Entrada y salida análisis de activos existentes... 91 Tabla 5.12 Entrada y salida de análisis de reglas de negocio... 92 Tabla 5.13 Entrada y salida de análisis de casos de uso de negocio (SOA)... 92 Tabla 5.14 Entrada y salida de diseño de mensaje... 93 Tabla 5.15 Entrada y salida de especificación de servicio... 94 Tabla 5.16 Entrada y salida de diseño sub sistemas (SOA)... 95 Tabla 5.17 Entrada y salida de documento de decisiones de realización de servicio... 96 Tabla 5.18 Fase de factibilidad IBM RUP SOMA adaptado a RUP... 98 Tabla 5.19 Fase de elaboración IBM RUP SOMA adaptado a RUP... 100 Tabla 5.20 Fase de elaboración IBM RUP SOMA adaptado a RUP... 104 Tabla 5.21 Fase de implementación IBM RUP SOMA adaptado a RUP 107 Tabla 5.22 Artefactos a entregar en planificación de fase de factibilidad... 114 Tabla 5.23 Métricas de estimación de tiempos... 115 5.24 Listado de casos de uso identificados y categorizarlo.... 119 Tabla 5.25 Artefactos de entrega de planificación en fase de elaboración... 120 Tabla 5.26 Métrica de estimación de tiempos en fase de elaboración... 121 xvi

RESUMEN METODOLOGÍA PARA EL DESARROLLO DE SOFTWARE ESCALABLES PARA EL DEPARTAMENTO DE PENSIONES DEL IESS. Este documento presenta una metodología de desarrollo de software escalable al departamento de pensiones del IESS, la cual ha sido adaptado a la metodología RUP (Rational Unified Process) acoplada para el Instituto Ecuatoriano de Seguridad Social y en particular al área de pensiones. Existen inconvenientes al momento de desarrollar software escalable, no hay normativas, artefactos, métodos ni técnicas, lo que afecta radicalmente a la planificación de los proyectos y esto involucra retrasos en los proyectos y a la no realización de estos, para lograr un entendimiento del problema en este documento se menciono las fases y actividades de la metodología RUP y sus adaptaciones. Presentamos las principales metodologías, se especifican sus fases y los detalles para la realización de este tipo de software, así teniendo una comparativa entre estas y teniendo el resultado de la mejor metodología vista desde el punto de vista de las necesidades del área de pensiones del IESS. Se especifica la metodología RUP SOMA IBM como la ganadora, mostrando las fases y los artefactos que involucra la metodología, brindando criterios de planificación para facilitar a los líderes de proyectos en la planificación de los mismos. DESCRIPTORES: / DESARROLLO DE SOFTWARE SOA / GESTIÓN DE PROYECTOS CON ARQUITECTURA SOA / PLANIFICACIÓN DE PROYECTOS / METODOLOGÍA RUP / METODOLOGÍA DE DESARROLLO DE SOFTWARE CON ARQUITECTURA SOA / SOFTWARE ESCALABLES xvii

ABSTRACT METHODOLOGY FOR SCALABLE SOFTWARE DEVELOPMENT FOR THE DEPARTMENT OF PENSION FUND IESS. This document presents a methodology for development of scalable software for the department of pension fund IESS, which has been adapted to the RUP (Rational Unified Process) coupled to the Ecuadorian Institute of Social Security and particularly the area of pension fund. In the area of pensions fund there are some obstacles when developing scalable software, no regulations, devices, methods and techniques, which dramatically affects the planning of projects and this involves project delays and non-realization of these. To achieve an understanding of the problem this document mentions phases and activities of the RUP methodology and adaptations that have the pension fund area IESS. We Present the main methods for developing software scalable, phases and details for the realization of such software are specified, and having a comparison between these and taking the result of the better methodology view from the perspective of the needs the area of pensions fund IESS. The IBM RUP SOMA methodology is specified as the winner, showing the phases and the artifacts methodology involves, providing planning criteria to facilitate to project leaders the best planning of them. DESCRIPTORS: / SOFTWARE DEVELOPMENT SOA / PROJECT MANAGEMENT ARCHITECTURE WITH SOA / PLANNING PROJECT / METHODOLOGY RUP / SOFTWARE DEVELOPMENT METHODOLOGY WITH ARCHITECTURE SOA / SCALABLE SOFTWARE xviii

CERTIFICACIÓN Yo, Angélica del Rocio Figueroa Hernández, con cédula de identidad número 0401018585, con suficiencia en idioma inglés; certifico haber realizado la traducción de la hoja del resumen del idioma español al idioma inglés. Quito, 22 de enero del 2015 Angélica del Rocio Figueroa Hernández C.I.: 0401018585 xix

xx

1.1 INTRODUCCIÓN 1 INTRODUCCIÓN En el presente capitulo brindaremos los parámetros generales del presente trabajo, así podrá entender el por qué la realización este documento. En el mundo cada vez se hace más importante el desarrollo de tecnologías web ya que a los usuarios ha brindado una forma más efectiva de satisfacer sus dudas o consultas que tengan sin tener la necesidad de realizarlas presencialmente, así se ahorra tiempo y dinero. El departamento de pensiones de IESS posee una infraestructura que soporta las aplicaciones de pago de pensiones a jubilados, jubilación ordinaria e invalidez, montepío, auxilio de funerales. Están desarrolladas de una forma tradicional y alineadas con los requerimientos que exige el negocio cabe mencionar que la institución es pública y estos requerimientos son directamente vinculados con las leyes y normas ecuatorianas las cuales son altamente cambiantes. Los líderes de proyectos del departamento del IESS planifican y coordinan actividades para solventar los cambios que se tienen que realizar en la aplicación, esto ha repercutido en poseer una cantidad de personal en el departamento de tecnología lo que involucra que tengan conocimientos bien afianzados en el negocio y conozcan en un alto grado el detalle de la construcción de la aplicación, por lo que la disposición de este personal está limitado a la carga de trabajo que demanda. La realización de aplicaciones web escalables hoy en día son necesarias cuando se tiene como primicia que el negocio es altamente cambiante, esto ayuda que el desarrollo de estas aplicaciones sea mucho mas rápido, se tenga un mejor control de la aplicación pero a la vez es necesario que 1

el personal técnico posea un conocimiento más detallado del giro de negocio de la empresa. Las metodologías de software ayudan a organizar, planificar y controlar actividades del personal y el resultado más fiel en la actualidad ha sido poseer aplicaciones web con alta calidad. Con el cambio a aplicaciones escalables se ha tenido la necesidad de cambiar la forma de gestionar. 1.2 PLANTEAMIENTO DEL PROBLEMA En el departamento de pensiones del Instituto Ecuatoriano de Seguridad Social (IESS), la metodología de desarrollo de software está adaptada exclusivamente a software web tradicional y esta no contempla el desarrollo de software con tecnologías escalables, las cuales ayudan a mantener el software de gestión del departamento en una manera rápida y sencilla, así las definiciones que exige el negocio van de la mano con la funcionalidad del software. Al momento de desarrollar software escalable, siguiendo la metodología actual del departamento de pensiones del IESS, se han tenido resultados no satisfactorios, como el retraso en los hitos de los proyectos, esto es como consecuencia de una planificación no adecuada debido a que la presente metodología de software no contempla una serie de etapas, lo que dificulta en la elaboración de un correcto presupuesto del proyecto y en un adecuado plan de adquisiciones de software, para solucionar estos graves inconvenientes se requiere incursionar en una metodología de desarrollo de software para negocios con requerimientos altamente cambiantes, es decir que exigen escalabilidad. 1.3 OBJETIVO GENERAL Establecer una metodología de desarrollo de software escalable que ayude al gerente de proyecto en la planificación de desarrollo de sistemas. 2

1.4 OBJETIVOS ESPECÍFICOS Identificar las fases y disciplinas que tiene inconvenientes en la metodología actual. Enunciar las diferentes metodologías de desarrollo enfocado al negocio existentes. Comparar las estrategias y métodos de las diferentes metodologías. Establecer una metodología RUP enfocado al negocio en base a las necesidades de la dirección de pensiones del IESS. Mejorar la planificación y control con la incorporación de una metodología RUP enfocado al negocio. 1.5 JUSTIFICACIÓN El departamento de pensiones del IESS necesita la investigación de una metodología de desarrollo de software escalable, esto permitirá a los líderes de proyecto planificar, presupuestar, controlar, monitorear y brindar el seguimiento necesario a los proyectos y así ayudar en la optimización del tiempo y el recurso económico en la institución. 1.6 HIPÓTESIS Y VARIABLES 1.6.1 HIPÓTESIS Se optimiza el tiempo y recurso económico al poseer una metodología de desarrollo de software escalable? 1.6.2 VARIABLES - INDICADORES Las variables para la investigación son: Número de 1 artefactos de la metodología por fases 1 Artefactos es un producto tangible resultante del proceso del desarrollo de software tomado de Wikipedia 3

Cumplimiento de los artefactos por fase Fecha fin de la fase Fecha inicio de la fase Fecha real del proyecto Fecha fin del proyecto Los indicadores para la investigación son: %Cumplimiento de la fase = Sumatoria del cumplimiento de los artefactos por fase / Número de artefactos por fase. Tiempo Empleado por fase = Fecha fin de la fase Fecha inicio de la fase %Cumplimiento del proyecto = (Fecha real del proyecto Fecha inicio del proyecto)*100/ (Fecha fin del proyecto Fecha inicio del proyecto) 1.7 METODOLOGÍA 1.7.1 TIPOS DE ESTUDIO La investigación tiene la necesidad de contribuir a la elaboración de una metodología de desarrollo de negocio enfocado al negocio para el IESS. Se utilizará el método inductivo ya que se recopilará información acerca de la presente metodología de software para ser analizada y detallada en los diferentes etapas y procesos, se realizará entrevistas con los funcionarios expertos del IESS y se analizará la metodología de desarrollo de software enfocado al negocio. 1.7.2 DISEÑO DE ESTUDIO El diseño de estudio se aplicará a un diseño no experimental descriptivo comparativo ya que se debe comparar la metodología actual contra la que será producto de la investigación http://es.wikipedia.org/wiki/artefacto_%28dise%c3%b1o_de_software%2 9 4

1.7.3 POBLACIÓN, MUESTRA Y MUESTREO La población serán el número de proyectos informáticos realizados para el departamento de pensiones del IESS. La muestra serán el número de proyectos de desarrollo y mantenimiento de software realizado en los últimos 8 años, tiempo en el cual se tiene automatizado el sistema actual de pensiones y debido a la calidad de los proyectos, el muestreo se realizará de tipo probabilístico. El método que se aplicará en la investigación será de tipo encuesta y se realizará mediante entrevistas personales y material que nos brinden los funcionarios del IESS, los instrumentos que utilizaremos serán cuestionarios y guías de entrevistas; siendo recolectada la información en tablas de indicadores y gráficos para analizar los datos. 1.7.4 TÉCNICAS DE ANÁLISIS DE DATOS Teniendo las tablas de indicadores y gráficos, el resultado sería aplicar la metodología a investigar con respecto a la muestra y analizar los resultados que brinda comparando los resultados para verificar si cumple los objetivos. 5

2.1 INTRODUCCIÓN 2 MARCO TEÓRICO El presente capítulo nos brinda la terminología y conocimiento básico para poder entender los siguientes capítulos del presente documento. 2.2 TERMINOLOGÍA BÁSICA 2.2.1 UML UML (Unified Modeling Language), que en español significa Lenguaje Unificado de Modelado, es un lenguaje de modelado de sistemas de software en la actualidad es el más conocido y se está volviendo en un estándar. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar, en otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, no es una programación de sistemas, lo que se trata de hacer es diagramar la realidad del cómo se usa uno o varios requerimientos. Mientras que en programación estructurada, es una forma de programar, como lo es la orientación a objetos y esto es un perfecto complemento de UML. 6

2.2.2 WORKFLOW El workflow, que en español es flujo de trabajo, es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas. Generalmente los problemas de flujo de trabajo se modelan con redes de Petri. Si bien el concepto de flujo de trabajo no es específico a la tecnología de la información, una parte esencial del software para trabajo colaborativo (groupware) es justamente el flujo de trabajo. Una aplicación de flujos de trabajo automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportación de las herramientas necesarias para gestionarlo. Se pueden distinguir tres tipos de actividad: Actividades colaborativas: Es un grupo de usuarios que trabajan sobre un mismo repositorio de datos para obtener un resultado común. Actividades cooperativas: Es un grupo de usuarios que trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos. Actividades de coordinación: Los workflow permiten automatizar procesos, usualmente se usan en procesos de negocio, en general permiten hacerlo con cualquier tipo de proceso que requiera ejecutar una serie de pasos en un orden predeterminado. 2.2.3 SOA SOA (Service Oriented Architecture), que en español significa Arquitectura Orientada a Servicios, es un término utilizado en arquitectura 7

de software, indica que el software utiliza servicios y esto permite la creación de sistemas de información altamente escalables, lo cual facilita la interacción entre diferentes sistemas propios o de terceros. 2.2.4 BPM BPM (Business Process Manager), que en español significa Administración de Procesos de Negocio, se llama gestión o administración por procesos de negocio y su objetivo es mejorar el desempeño de la organización a través de la gestión de los procesos de negocio. Los procesos se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. BPM es el entendimiento, visibilidad y control de los procesos de negocio de una organización. Un proceso de negocio representa una serie discreta de actividades o pasos de tareas que pueden incluir personas, aplicativos, eventos de negocio y organizaciones. 2.2.5 BPMN BPMN (Business Process Modeling Notation ), que en español significa Notación para el Modelo de Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo (workflow). BPMN fue inicialmente desarrollada por la organización Business Process Management Initiative (BPMI), y es actualmente mantenida por el OMG (Object Management Group), después de la fusión de las dos organizaciones en el año 2005. Su versión actual, a abril de 2011, es la 2.0. El principal objetivo de BPMN es proporcionar una notación estándar que sea fácilmente legible y entendible por parte de todos los involucrados e interesados del negocio (stakeholders). Entre estos interesados están los analistas de negocio (quienes definen y redefinen los procesos), los desarrolladores técnicos (responsables de implementar los procesos) y 8

los gerentes y administradores del negocio (quienes monitorizan y gestionan los procesos). En síntesis, BPMN tiene la finalidad de servir como lenguaje común para cerrar la brecha de comunicación que frecuentemente se presenta entre el diseño de los procesos de negocio y su implementación. Actualmente hay una amplia variedad de lenguajes, herramientas y metodologías para el modelado de procesos de negocio. La adopción cada vez mayor de la notación BPMN como estándar ayudará a unificar la expresión de conceptos básicos de procesos de negocio (por ejemplo procesos públicos y privados, orquestación, coreografía, etc.) así como conceptos avanzados de modelado (por ejemplo manejo de excepciones, compensación de transacciones, entre otros). 2.2.6 ESB ESB (Enterprise Service Bus), que en español significa Bus de Servicios Empresariales, es un mediador de los servicios en un entorno empresarial. 2.2.7 OOAD OOAD (Object Oriented Analysis and Design), que en español significa Análisis y Diseño Orientado a Objetos, el objetivo es modelar y diseñar un sistema como un grupo de interacciones entre objetos. 2.2.8 CBM CBM (Componente Business Modeling), que en español significa Modelamiento de Componentes de Negocio, es una técnica desarrollada por IBM para modelar y analizar una empresa. Es una representación lógica o mapa de componentes de negocio o buildings blocks es decir bloques de construcción y pueden ser representados en una sola página. 9

2.2.9 ARTEFACTOS Un producto o artefactos es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final. Un artefacto puede ser cualquiera de los siguientes: Un documento, como el documento de la arquitectura de software Un modelo, como el modelo de casos de uso o el modelo de diseño Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un caso de uso o un subsistema. 2.2.10 APLICACIONES DISTRIBUIDAS Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las aplicaciones distribuidas tradicionales son de dos niveles (cliente servidor) tres niveles (Cliente middleware-servidor) y multinivel. 2.2.11 ARQUITECTURA EMPRESARIAL La arquitectura empresarial identifica los componentes principales de la organización y su relación para conseguir los objetivos. 2.2.12 LDAP LDAP (Lightweight Directory Access Protocol), que en español significa Protocolo Ligero de Acceso a Directorios, es un protocolo a nivel de aplicación, tiene acceso a una base de datos de un conjuntos de objetos, organizados en una manera lógica y jerárquica, es decir permite la administración de usuarios por cada grupo o área de la organización dentro de una empresa. 10