Embed Size (px)
Citation preview
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
ii
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
iii
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
iv
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
v
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
vi
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
vii
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
viii
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
ix
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
x
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
xi
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
xii
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
xiii
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
xiv
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
xv
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
xvi
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
xvii
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
xviii
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
xix
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
xx
1
1 INTRODUCCIÓN
1.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
2
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.
3
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 1artefactos de la metodología por fases
1 “Artefactos es un producto tangible resultante del proceso del
desarrollo de software” tomado de Wikipedia
4
• 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
5
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.
6
2 MARCO TEÓRICO
2.1 INTRODUCCIÓN 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.
7
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
8
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
9
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.
10
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.
11
2.2.13 SOAP SOAP (Single Object Access Protocol), que en español significa Protocolo
Simple de Acceso a Objetos, define cómo se puede comunicar dos
objetos por medio de XML.
2.2.14 HTTP HTTP (Hypertext Transfer Protocol), que en español significa Protocolo de
Transferencia de Hipertexto, se define como un protocolo usado por
internet WWW (World Wide Web).
2.2.15 W3C W3C (World Wide Web Consortium), son las siglas de una comunidad
internacional que trabajan para poder desarrollar estándares para el
desarrollo web. Es reconocido a nivel mundial por ser la organización
encargada de estandarizar el lenguaje HTML ( lenguaje de hipertexto) .
2.2.16 MODELO DE DOMINIO Un modelo de dominio es un modelo conceptual de todos los temas
relacionados con un problema específico. En él se describen las distintas
entidades, sus atributos, papeles y relaciones, además de las
restricciones que rigen el dominio del problema.
2.2.17 KPI KPI (Key Performance Indicator), que en español significa Indicadores de
Rendimiento que según Wikipedia http://es.wikipedia.org/wiki/KPI “Es una
medida del nivel del desempeño de un proceso; el valor del indicador está
directamente relacionado con un objetivo fijado de antemano.
Normalmente se expresa en porcentaje”, estos indicadores sirven para
mejorar el rendimiento en aplicaciones SOA.
12
2.3 METODOLOGÍA DE DESARROLLO DE SOFTWARE RUP
2.3.1 DEFINICIÓN RUP (Rational Unified Process) o Proceso Unificado, es una metodología
de desarrollo de software creado por Rational Software Corporation,
actualmente es propietario IBM, esta se ayuda con UML para poder
diagramar las diferentes etapas del desarrollo de software.
RUP contiene un conjunto de procesos iterativos e incrementales, obliga a
la asignación de tareas y responsabilidades en forma disciplinada en un
proyecto de software, es decir quién hace qué, cuándo y cómo.
Los procesos de RUP se basan en las mejores prácticas que se han
intentado y se han probado en el campo, se divide en cuatro fases:
• Inicio, define el alcance del proyecto
• Elaboración, definición, análisis y diseño
• Construcción, implementación
• Transición, fin del proyecto y puesta en producción.
En cada fase se concluye con un hito de toma de decisiones, cabe
destacar que planificar las fases involucra asignación de tiempos, hitos
principales, iteraciones por fases y plan de proyecto.
RUP define nueve disciplinas a realizar en cada fase del proyecto:
• Modelado del negocio
• Análisis de requisitos
• Análisis y diseño
• Implementación
• Pruebas
• Distribución
• Gestión de configuración y cambios
13
• Gestión del entorno
2.3.2 FASE DE INICIO Durante la fase de inicio se define el modelo de negocio y el alcance del
proyecto. Se identifican los actores y casos de uso, y se diseñan los
casos de uso más esenciales (aproximadamente el 20% del modelo
completo). Se desarrolla, un plan de negocio para determinar que
recursos deben ser asignados al proyecto.
Los objetivos de esta fase son:
• Establecer el ámbito del proyecto y sus límites.
• Encontrar los casos de uso críticos del sistema, los escenarios
básicos que definen la funcionalidad.
• Estimar el coste en recursos y tiempo de todo el proyecto.
• Estimar los riesgos, las fuentes de incertidumbre.
Los resultados de la fase de inicio deben ser:
• Documento de visión que indica una visión general de los
requerimientos del proyecto, características claves y restricciones
principales.
• Modelo inicial de casos de uso (10-20% completado).
• Glosario inicial de términos.
• Casos de uso de negocio.
• Listado de riesgos y plan de contingencia.
• Plan de proyecto, mostrando fases e iteraciones.
• Modelo de negocio, si es necesario.
• Prototipos de software, si es necesario
Al terminar la fase de inicio se deben comprobar los criterios de
evaluación para continuar:
• Los interesados en el proyecto coinciden en la definición del ámbito
del sistema y las estimaciones de agenda
14
• Entendimiento de los requisitos, como evidencia de fidelidad de los
casos de uso principales
• Las estimaciones de tiempo, coste y riesgo son creíbles
• Los gastos hasta el momento se asemejan a los planeados
Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o
repensarlo profundamente.
2.3.3 FASE DE ELABORACIÓN El propósito de la fase de elaboración es analizar el dominio del problema,
establecer los cimientos de la arquitectura, desarrollar el plan del proyecto
y eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe
evolucionar en iteraciones sucesivas hasta convertirse en el sistema final.
Este prototipo debe contener los casos de uso críticos identificados en la
fase de inicio. También debe demostrarse que se han evitado los riesgos
más graves.
Los objetivos de esta fase son:
• Definir, validar y cimentar la arquitectura.
• Completar la visión
• Crear un plan fiable de construcción. Este plan puede evolucionar
en sucesivas iteraciones. Debe incluir los costes si procede.
• Demostrar que la arquitectura propuesta soportará la visión con un
coste razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados:
• Un modelo de casos de uso completa al menos hasta el 80%,
todos los casos y actores identificados, la mayoría de los casos
desarrollados.
• Requisitos adicionales que capturan los requisitos no funcionales y
cualquier requisito no asociado con un caso de uso específico.
15
• Descripción de la arquitectura software
• Un prototipo ejecutable de la arquitectura
• Plan de desarrollo para el proyecto
• Un caso de desarrollo actualizado que especifica el proceso a
seguir
• Un manual de usuario preliminar (opcional)
En esta fase se debe tratar de abarcar todo el proyecto con la profundidad
mínima. Sólo se profundiza en los puntos críticos de la arquitectura o
riesgos importantes.
En la fase de elaboración se actualizan todos los productos de la fase de
inicio.
En esta fase se actualizarán todos los artefactos de la fase de inicio:
• La visión del producto es estable
• La arquitectura es estable
• Se ha demostrado mediante la ejecución del prototipo que los
principales elementos de riesgos han sido abordados y resueltos.
• El plan para la fase de construcción es detallado y preciso. Las
estimaciones son creíbles.
• Todos los interesados coinciden en que la visión actual será
alcanzada si se siguen los planes actuales en el contexto de la
arquitectura actual.
• Los gastos hasta ahora son aceptables, comparados con los
previstos.
Si no se superan los criterios de evaluación quizá sea necesario
abandonar el proyecto o replanteárselo considerablemente.
2.3.4 FASE DE CONSTRUCCIÓN La finalidad principal de esta fase es alcanzar la capacidad operacional
del producto de forma incremental a través de las sucesivas iteraciones.
16
Durante esta fase todos los componentes, características y requisitos
deben ser implementados, integrados y probados en su totalidad,
obteniendo una versión aceptable del producto.
Los objetivos concretos de esta fase son:
• Minimizar los costes de desarrollo mediante la optimización de
recursos y evitando el tener que rehacer un trabajo o incluso
desecharlo.
• Conseguir una calidad adecuada tan rápido como sea práctico
• Conseguir versiones funcionales (alfa, beta y otras versiones de
prueba) tan rápido como sea práctico.
Los resultados de la fase de construcción deben ser:
• Modelos completos ( casos de uso, análisis, diseño, despliegue e
implementación)
• Arquitectura íntegra ( mantenida y mínimamente actualizada)
• Riesgos presentados mitigados
• Plan de proyecto para la fase de transición
• Manual inicial de usuario (con suficiente detalle)
• Prototipo operacional – beta
• Caso del negocio actualizado
Los criterios de evaluación de esta fase son los siguientes:
• El producto es estable y maduro como para ser entregado a la
comunidad de usuario para ser probado.
• Todos los usuarios expertos están listos para la transición en la
comunidad de usuarios.
• Son aceptables los gastos actuales versus los gastos planeados.
2.3.5 FASE DE TRANSICIÓN La finalidad de la fase de transición es poner el producto en manos de los
usuarios finales, para lo que se requiere desarrollar nuevas versiones
actualizadas del producto, completar la documentación, entrenar al
17
usuario en el manejo del producto, y en general tareas relacionadas con
el ajuste, configuración, instalación y facilidad de uso del producto.
Algunas cosas que puede incluir esta fase:
• Prueba de la versión - beta para validar el nuevo sistema frente a
las expectativas de los usuarios
• Funcionamiento paralelo con los sistemas que están siendo
sustituidos por nuestro proyecto
• Conversión de las bases de datos operaciones.
• Entrenamiento de los usuarios y técnicos de mantenimiento
• Traspaso del producto a los equipos de marketing, distribución y
venta.
Los principales objetivos de esta fase son:
• Conseguir que el usuario se valga por sí mismo
• Un producto final que cumpla los requisitos esperados, que
funcione y satisfaga suficientemente al usuario.
Los resultados de la fase de transición son:
• Prototipo operacional
• Documentos legales
• Caso del negocio completo
• Línea de base del producto completa y corregida que incluye todos
los modelos del sistema
• Descripción de la arquitectura completa y corregida
• Las iteraciones de esta fase irán dirigidas normalmente a conseguir
una nueva versión
Los criterios de evaluación de esta fase son los siguientes:
• El usuario se encuentra satisfecho
• Son aceptables los gastos actuales versus los gastos planificados
18
2.3.6 ROLES Un rol define comportamiento y responsabilidades de un individuo, o de
un grupo de individuos trabajando juntos como un equipo. Una persona
puede desempeñar diversos roles, así como un mismo rol puede ser
representado por varias personas.
Las responsabilidades de un rol es tanto el llevar a cabo un conjunto de
actividades como el ser el dueño de un conjunto de artefactos.
Analistas:
• Analista de procesos de negocio
• Diseñador del negocio
• Analista de sistema
• Especificador de requisitos
Desarrolladores:
• Arquitecto de software
• Diseñador de interfaz de usuario
• Diseñador de base de datos
• Implementador
• Integrador
Gestores
• Jefe de proyecto
• Jefe de control de cambios
• Jefe de configuración
• Jefe de pruebas
• Jefe de despliegue
• Ingeniero de procesos
• Revisor de gestión del proyecto
• Gestor de pruebas
Apoyo
19
• Documento técnico
• Administrador de sistema
• Especialista en herramienta
• Desarrollador de cursos
• Artista gráfico
Especialista en pruebas:
• Especialista en pruebas
• Analista de pruebas
• Diseñador pruebas
Otros roles:
• Stakeholders
• Revisor
• Coordinación de revisiones
• Revisor técnico
• Cualquier rol
2.4 SOFTWARE ESCALABLES Software escalable, es la capacidad para responder rápidamente ante los
cambios y optimizar los procesos de negocio, son factores claves para la
competitividad y el crecimiento de las organizaciones, cuando un software
se puede adaptar y crecer junto con la empresa entonces se trata de un
software escalable, siempre con el objetivo claro de satisfacer las
necesidades que el negocio exige y manteniendo un rendimiento
adecuado.
La escalabilidad debe formar parte del proceso de diseño del desarrollo
de software porque no es una característica separada que se pueda
agregar después. Al igual que con otras funciones de aplicación, las
decisiones que se tomen durante las primeras fases de diseño y
codificación determinaran en gran medida la escalabilidad de la aplicación.
20
Las organizaciones se han dado cuenta que el objetivo final es la
automatización de los procesos de negocio (desarrollar aplicaciones que
darán soporte a todos y cada uno de los pasos de un proceso de negocio,
desde su comienzo hasta su finalización). La Arquitectura SOA es una
filosofía de diseño que permite un mejor alineamiento de las tecnologías
de información (IT) con las necesidades de negocio.
Se percibe cada vez con mayor claridad que los procesos de negocio no
son constantes y necesitan ser adaptados. Necesitan ser flexibles, por lo
tanto, IT también debe ser flexible.
Las empresas necesitan poder interconectar los procesos, personas e
información tanto con la propia organización como atravesando sus
fronteras con la subsidiaria y socios comerciales. La falta de integración e
interoperabilidad entre los componentes de sistemas, aplicaciones y datos,
hace difícil obtener una respuesta rápida y efectiva ante los cambios que
afectan de forma natural a los negocios. La inflexibilidad genera costos,
reduce la capacidad de respuesta ante los clientes, compromete el
cumplimiento de la normativa legal y afecta negativamente en el personal
de la empresa.
El software de gestión administrativa está estrechamente ligado a la
organización interna, procesos y modelos de negocio, durante todo el
tiempo existirán requisitos de este tipo de software, debido a el cambio
permanente en los mercados de negocio, la organización de la empresa y
sus objetivos de negocio, es por eso que el desarrollo de software
administrativo se hace realmente muy complejo.
Como resultado de la estrecha relación con la organización interna, los
procesos y modelos de negocio, un diseño de software debe cumplir con
requisitos muy diferentes que los tradicionales, para poder brindar agilidad
y eficiencia a un diseño de software de gestión, debe contemplar
características particulares como: simplicidad, flexibilidad y mantenimiento,
21
reusabilidad y por último poder desacoplar la funcionalidad y la tecnología
mediante la utilización de una arquitectura SOA.
2.5 ARQUITECTURA DE SOFTWARE BASADA EN SOA
2.5.1 INTRODUCCIÓN Una empresa es una entidad compleja compuesta por personas, procesos
y tecnología, que producen productos o servicios orientados a satisfacer
las necesidades de los clientes. La arquitectura empresarial actúa como
una fuerza integradora entre aspectos de planificación de negocios,
aspectos de operación de negocio y aspectos tecnológicos.
Con la implementación de SOA en las empresas se ha logrado alcanzar
un alto nivel de importancia y relevancia, gracias a que las necesidades
latentes que tienen las organizaciones se alinean al modelo de negocio
con los servicios tecnológicos, con el único objetivo de ser más
competitivos y poder brindar prontas respuestas a las exigencias del
mercado.
SOA corresponde a un estilo de arquitectura en el contexto de las
tecnologías de la información (TI), entendiéndose como la planeación y el
diseño de un sistema de información de acuerdo con un conjunto de guías
y lineamientos de manera que soporte las capacidades actuales y futuras
para las cuales fue diseñado.
Tradicionalmente, los modelos de gestión tecnológica en una
organización están relacionados con los modelos de negocio bajo este
enfoque, el diseño y construcción de las soluciones informáticas consiste
en tomar el conjunto de requerimientos que define el negocio, y a partir de
estos extraer un modelo de tecnología que de respuesta explícita a dichos
requerimientos.
22
Lo que se busca con SOA es tener una visión más abierta y estrecha con
el negocio, así como una nueva alternativa de pensamiento sobre la
orientación a servicios de los componentes tecnológicos que provee. La
adopción de un modelo de arquitectura orientado a servicios proporciona
los mecanismos que permiten definir contratos de prestación de servicios
que aseguren que la capa de negocio en una organización se encuentra
alineada con la capa de TI.
Figura 2.1 Antes y después de SOA
Fuente: Marcos Milanesio http://marcosmilanesio.blogspot.com/2010_04_01_archive.html
A través de SOA, los procesos de negocios se implementan mediante
servicios que ejecutan cada una de las unidades de trabajo mencionadas,
cada servicio es autónomo e independiente del resto, el cual al no
necesitar información de contexto puede reutilizarse indistintamente en
varios procesos es decir son stateless o sin estado.
La comunicación con el resto de componentes se realiza por medio de su
interfaz, que mientras no sea modificada, permite la mejora continua del
servicio disminuyendo la necesidad de realizar pruebas de procesos
23
completos continuamente. A esto se lo conoce como loose coupling o
bajo acoplamiento.
El proceso para transitar de un estado actual hacia un estado deseado, se
denomina GAP que significa brecha, SOA permite que se vaya
realizando un acercamiento hacia el modelo objetivo.
2.5.2 TERMINOLOGÍA BÁSICA SOA
2.5.2.1 MENSAJE Es una unidad independiente de comunicación, es simple y es solo una
estructura de datos. En el contexto de SOA, los consumidores y
servidores intercambian información libremente en base a los contratos y
políticas.
2.5.2.2 SERVICIOS SIN ESTADO Son métodos o procedimientos sin estado, que acepta unas llamadas y
devuelve respuestas. Los servicios pueden también ejecutar unidades
discretas de trabajo como serían editar y procesar una transacción.
Los servicios no dependen del estado de otras funciones o procesos.
Las características principales son las siguientes:
• Interoperabilidad, es decir la capacidad de intercambiar información
entre los sistemas de tecnologías de la información, comunicación,
y procesos empresariales.
• Flexibilidad, es decir la resolución de muchos obstáculos en la
puesta en producción e integración de las aplicaciones.
• Basados en protocolos HTTP (Hyper Typer Text Protocol), en
español protocolo de híper texto.
• Interfaz definida o contrato de servicio, especifica el consumo del
servicio, desde cualquier cliente, como puede ser otros servicios o
programas.
• Reutilizable y/o compatible con otros
24
• Desacoplado, lo que indica, que la funcionalidad del servicio, no
dependa de otro para poder ejecutarse.
Ejemplo:
• Consultar la hora
• Calcular monto
• Consultar clientes
2.5.2.3 ORQUESTACIÓN La orquestación o composición de servicios, es la unión de dos o más
servicios, con alguna lógica, para crear otro servicios más complejo, la
lógica depende de los procesos del negocio: simple o secuencial.
Estos servicios más complejos se pueden crear con lenguajes diferentes
a los servicios básicos, como BPEL.
La administración, metodología y estándares utilizados para estos
procesos se los conoce como BPM.
2.5.2.4 BPEL BPEL (Business Process Execution Language), que en español significa
Lenguaje de Ejecución de Procesos de Negocio, es un lenguaje
estandarizado para la composición de servicios web. Básicamente,
consiste en un lenguaje basado en XML diseñado para el control
centralizado de la invocación de diferentes servicios Web, con cierta
lógica de negocios añadida que ayuda a la programación en gran escala.
2.5.2.5 BPM BPM (Business Process Manager), que en español significa
Administración de Procesos de Negocio, es el enfoque de negocio de los
sistemas de información y también resulta ser una disciplina de gestión
por proceso de negocio apoyadas fuertemente por tecnologías de
25
información, así tratando de lograr que se construyan sistemas de
información de acuerdo a las necesidades del cliente.
2.5.3 DEFINICIÓN DE SOA SOA (Service Oriented Architecture), que en español es Arquitectura
Orientada a Servicios, es la organización fundamental de un sistema
descrita en servicios y la relación entre estos, está basada en estándares,
los servicios son autónomos y granulares.
2.5.4 OBJETIVO DE LA ARQUITECTURA SOA. El fin de una arquitectura SOA es conseguir combinar distintos módulos
funcionales para generar aplicaciones de carácter especifico, que
provienen de servicios existentes.
La arquitectura SOA se rige sobre un principio fundamental: la orientación
al servicio. En un entorno SOA los servicios pueden ser utilizados sin
conocimiento alguno de las características de la plataforma sobre la que
se despliegan.
2.5.5 BENEFICIOS DE SOA Los beneficios que puede obtener una organización que adopta SOA son:
• Mejora en los tiempos de realización de cambios en procesos.
• Facilidad para evolucionar a modelos de negocios basados en
tercerización.
• Facilidad para abordar modelos de negocios basados en
colaboración con otros entes (socios, proveedores).
• Poder para reemplazar elementos de la capa aplicativa SOA sin
disrupción en el proceso de negocio.
• Facilidad para la integración de tecnologías disímiles.
26
2.5.6 DESVENTAJAS DE SOA: Las desventajas que presenta SOA son:
• La velocidad de intercambio de información entre cada servicio es
más lenta comparada con una conexión directa.
• Requiere un cambio en las organizaciones, un alto esfuerzo. No
siendo sencillo, para la mayoría de las organizaciones adoptar
SOA.
• SOA demanda muchas horas de trabajo en el principio del proyecto.
2.5.7 COMPONENTES DE SOA Dentro de una implementación SOA se encuentran los siguientes
componentes tecnológicos:
• ESB (Enterprise Service Bus): Es un software especializado que
facilita la comunicación entre los servicios
• Herramientas de desarrollo: Ambiente integrado que permite el
diseño y construcción de la mediación/orquestación de los servicios
• Servicios de información: Funciones que administran datos y
contenido de diversas fuentes de una manera unificada.
• Servicios de acceso: Funciones que facilitan la interacción entre
las diferentes aplicaciones de negocio.
2.5.8 IMPLEMENTACIÓN DE SOA Existen tres fases para implementar exitosamente SOA, y se ejecutan de
manera consecutiva:
• Planificación.
• EAI (Integración de Aplicaciones Empresariales)
• BPM (Procesos de negocio)
27
2.5.9 PLANIFICACIÓN DE DESARROLLO DE APLICACIONES SOA
Antes de empezar tenemos que contestar a las siguientes preguntas :
• Qué servicios se requieren?
• Qué servicios se deben desarrollar?
• Cómo crear nuevos servicios?
• Cómo administrar los servicios?
• Cómo estandarizar los mensajes que van a intercambiar los
servicios?
2.5.9.1.1 IDENTIFICACIÓN DE SERVICIOS
¿Qué servicios necesitamos? Uno de los principales errores que se
pueden cometer al adoptar SOA es empezar a desarrollar nuevos
servicios o incluso exponer servicios existentes sin tener la seguridad de
que los vayamos a necesitar. Esto se debe a que ese proceso toma
tiempo y requiere de recursos especializados. Por lo tanto, para ser
exitosa, la adopción de SOA debe ser progresiva y basada en proyectos
reales de EAI o de BPM. Los servicios se deben crear o exponer a
medida que se requieren. Eso si, los servicios se deben planear para que
sean reutilizables y por lo tanto deben ser tan generales como sea posible.
Esto significa que si lo que se requiere es un servicio para dar de alta un
cliente en una región determinada, quizás sea mejor crear uno que
permita crear un cliente para cualquier región.
En general, lo más recomendable es dejar que los usuarios de negocios
definan los servicios, sin intervención de la gente de TI. Para lograrlo, lo
mejor es dejar que utilicen una herramienta de modelado de procesos, es
decir representar tanto sus procesos existentes, como los que desearían
implementar. Normalmente, de esos procesos se obtiene fácilmente los
servicios que se deben implementar. Para decidir en qué orden hacerlo
podemos ayudarnos de una pequeña matriz en la que un eje indicamos la
complejidad del desarrollo y en la otra su importancia. De esta manera
28
podemos empezar por los más importantes y sencillos y dejar los
complejos y menos críticos para más adelante.
Figura 2.2 Identificación de servicios
Fuente: tomado de Gustavo Francisco Guerra
http://es.slideshare.net/gustavofranciscoguerra/implemen
tacion-exitosa-soa
La mejor manera de detectar servicios es pidiendo a los usuarios de
negocio que modelen sus procesos.
2.5.9.1.2 SERVICIOS EXISTENTES
Qué servicios se deben desarrollar?, para cada servicio detectado es
necesario determinar si debe ser desarrollado desde cero o si es posible
exponer la funcionalidad que ya provee un sistema antiguo como un
servicio.
El desarrollo de nuevos servicios es un proceso muy similar al desarrollo
de una aplicación. Los primeros pasos consisten en levantar los
requerimientos, luego se crea una arquitectura que permita soportar la
aplicación con los niveles de servicio y otros requerimientos no
1
3 4
ALTA BAJA
ALT
A
BA
JA
Complejidad
Impo
rtan
cia
29
funcionales necesarios y finalmente se hace un análisis exhaustivo de la
aplicación. Al tratarse de componentes que ofrecen funcionalidad limitada,
la fase de desarrollo generalmente se puede completar en una sola
iteración.
Al igual que con cualquier tipo de desarrollo, el uso de una metodología
de desarrollo probada como RUP es altamente recomendado.
Figura 2.3 Metodología RUP
Fuente: IBM http://www.ibm.com/developerworks/library/ws-soa-term2/
Una de las características de los servicios web es que normalmente
realizan solo una función, por eso suelen ser muy fáciles de probar. Las
pruebas se deben hacer tanto para comprobar la funcionalidad del
servicio como su escalabilidad. Existen herramientas que automatizan las
pruebas unitarias de los servicios web.
Sin embargo, el desarrollo de nuevos componentes no es tan complicado
como la administración de cambios a los mismos. En efecto, una vez que
un servicio ha sido creado y es utilizado por múltiples procesos, realizar
cambios al mismo puede parecer imposible. Esto no significa que una vez
creado no sea posible realizar nunca cambios al mismo pero tampoco
significa tener que crear otros similares pero con la funcionalidad
30
específica que se requiere, porque eso tampoco es una opción. ¿Por
qué? Porque entonces, se da la proliferación de servicios de la que
hablábamos anteriormente la cual es nefasta, tanto para los
programadores responsable de mantener el código como para los
administradores del sistema. Por lo tanto, es necesario llevar un control
de las dependencias existentes así como una comprensión precisa del
impacto de los cambios. Esto es algo que se ha hecho desde hace años
en proyectos tradicionales, pero que se ha vuelto aún más importante en
un entorno de SOA.
2.5.9.1.3 PROTOCOLOS DE COMUNICACIÓN DE SERVICIOS
En los orígenes de los servicios web, lo importante era saber cómo
invocarlos. Para eso se creó el protocolo SOAP (Simple Object Access
Protocol). Simplificando, se trata básicamente de un documento XML que
se utiliza para transportar los parámetros de entrada y de salida entre una
aplicación cliente y un servicio web. Lo que no define es el protocolo de
transporte único como HTTP o SMTP. En lugar de eso, enumera una
serie de protocolos posibles y termina con puntos suspensivos indicando
que cualquier protocolo es aceptable, siempre y cuando el mensaje
cumpla con SOAP.
Inicialmente, la gente utilizó HTTP como protocolo de transporte para los
mensajes SOAP porque ofrece varias ventajas importantes, como bajo
costo, posibilidad de utilizarlo a través de firewalls y posibilidad de
utilizarlo con software de infraestructura existente.
Sin embargo, HTTP tiene muchas limitaciones para un uso empresarial.
La más importante es que HTTP no garantiza la entrega del mensaje ni la
recepción de una respuesta. Esto en muchos casos no es muy importante.
Por ejemplo, en EEUU, el gobierno facilita un servicio web público para
que los desarrolladores puedan incluir las predicciones del tiempo en su
página Web. Si este servicio se utiliza desde un portal como Yahoo! y el
31
servicio por algún motivo no contesta, no pasa nada. El usuario solo
necesita pulsar el botón “Recargar” y el problema queda resuelto.
Sin embargo, dentro de una empresa, para aplicaciones que tienen
sistemas de información implementados con ESB, no se puede usar el
botón “Recargar” que tiene los navegadores de internet, explicaremos con
un ejemplo, una aplicación de recursos humanos que se utilice para dar
de alta a nuevos empleados, cuando termina este proceso supongamos
que utiliza servicios web para conectarse con el sistema de activos fijos
para asignar una laptop a ese nuevo empleado, si la llamada al servicio
falla con HTTP no sabríamos si el servicio falló antes de asignar al equipo
o después, por lo tanto, no es posible simplemente “Recargar” la pagina
para volver a invocar el servicio porque corremos el riesgo de asignar
varios equipos a una misma persona. El mismo problema se presentaría
con una transferencia bancaria, necesitamos la garantía de que esa
transacción se va a realizar y de que sólo se va a realizar una vez, en
ese tipo de casos HTTP no es una opción.
Afortunadamente existe una alternativa que cumple con los
requerimientos que se han señalado, consiste en utilizar colas de
mensajes para servir como transporte seguro de los mensajes SOAP,
permite al emisor y al receptor que se encuentren inactivos, permite
comunicaciones persistentes asincrónicas, transferencia de mensajes que
duren minutos, dicho en otras palabras permite que el emisor y el
receptor del mensaje no necesiten interactuar con la cola del mensaje al
mismo tiempo.
Entonces, la pregunta obvia es ¿Qué protocolo debo usar? No existen
reglas estrictas al respecto, pero sí unas recetas que conviene adoptar:
AMQP ( Advanced Message Queuing Protocol), según Wikipedia
http://es.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol , es
“es un protocolo de estándar abierto en la capa de aplicaciones de un
sistema de comunicación. Las características que definen al protocolo
32
AMQP son la orientación a mensajes, encolamiento ("queuing"),
enrutamiento (tanto punto-a-punto como publicación-subscripción),
exactitud y seguridad”, siendo un protocolo para colas de mensajería.
Las situaciones donde se utilizaría colas de mensajes:
• Servicios asíncronos
• Servicios que representan procesos de negocios (tanto micro-flujos
BPEL como macro-flujos)
• Servicios transaccionales, en los que se requiere la garantía de
que se va a obtener una respuesta
Situaciones en las que se debe utilizar SOAP/HTTP:
• Cuando el lenguaje de programación utilizado por el servicio no
puede interactuar con colas de mensaje
• En las situaciones que se debe interactuar con un número alto o
desconocido de socios de negocios
• Consultas síncronas sencillas que afectan a un solo sistema
Como se puede observar, siguen existiendo zonas grises en las que
podría usar hipotéticamente ambas soluciones tecnológicas. Si bien es
posible y de hecho muy fácil exponer un mismo servicio tanto por
SOAP/JMS como por SOAP/HTTP, lo más recomendable es que en caso
de duda se adopte SOAP/JMS ya que para el área de operaciones es
mucho más sencillo monitorear una infraestructura de colas de mensajes
que una basada en HTTP donde los mensajes se mezclan con el tráfico
normal de acceso a Internet.
2.5.9.1.4 ADMINISTRACIÓN DE LOS SERVICIOS
Para la administración de los servicios se tiene que realizar una
normalización sintáctica, si se dispone de pocos servicios, es posible que
los desarrolladores sean quienes conserven las especificaciones de lo
servicios , si se cuenta con bastantes servicios es necesario contar con un
repositorio centralizado, en el que se publiquen todos los servicios
existentes.
33
Si la empresa tiene cientos o miles de servicios es necesario un directorio
avanzado que permita contestar, las siguientes preguntas:
• Quién es el responsable de cada servicios?
• Quién es el responsable de desarrollo de cada servicio?
• Quién es el responsable de la calidad de datos?
• Qué procesos se ven afectados si no funciona el servicio?
Cuando se trabaja con decenas de sistemas, es normal que no todos
manejen el mismo vocabulario, por ejemplo el objeto “Cliente“ se puede
representar de manera distinta.
Es importante que en el modelado de los procesos se intente normalizar
la estructura de los objetos de negocio para simplificar la integración de
sistemas y reducir la necesidad de realizar transformaciones en las que
se pueden perder datos, al interconectar diversos sistemas.
2.5.9.2 COMUNICACIÓN ENTRE SERVICIOS La comunicación entre servicios se lo puede realizar mediante un ESB,
para lo que es necesario considerar:
• Ruteo y transformación de mensajes
• Seguridad
• Monitoreo
• Calidad de Servicio
El ESB servirá de intermediario entre las aplicaciones existentes en un
entorno empresarial, sin importar su infraestructura o lenguaje de
programación, el objetivo es aprovechar las funcionales existentes para
un fin común.
34
Figura 2.3 Modelo de un ESB
Fuente: tomado de http://www.misbytes.com/wp/wp-
content/uploads/2006/10/esb3.jpg
La seguridad es muy importante en el contexto de los servicios web, es
posible encriptar los mensajes o el canal de comunicaciones, es más
sencillo encriptar el canal de comunicaciones que el mensaje así
brindando una flexibilidad a los desarrolladores.
La seguridad debe tomar en cuenta lo siguiente:
• La seguridad debe estar centralizada con el directorio LDAP
• La seguridad puede llegar a impactar seriamente al rendimiento de
la aplicación
2.6 SEGURIDAD EN SERVICIOS WEB Alguna de las características de los servicios web, como por ejemplo el
acceso e intercambio de la información no están acordes con los modelos
y controles tradicionales de la seguridad informática, esta situación a
35
generado desafíos para modificar los mecanismos de confidencialidad e
integridad de los datos que son transmitidos por los protocolos de
servicios web.
Los sistemas de seguridad como: Firewalls (software o hardware que
comprueba la información de internet o red) y/o Sistemas de Detección
de Intrusos no son adecuados para proteger arquitecturas basadas en
SOA, esto es debido que estas técnicas son dinámicas y son transmitidas
a través de HTTP; soluciones como TLS y SSL es decir tener canales
seguros no se adaptan totalmente porque trabajan asegurando canales
de aplicación punto a punto y no de aplicaciones.
Algunos estándares desarrollos por W3C pueden garantizar:
confidencialidad, integridad y disponibilidad de los servicios web, estos
proveen mecanismos para cifrar, firmar digitalmente, autenticar y certificar
documentos XML.
2.6.1 WS-Security WS-Security, que en español significa Seguridad Web Services, que
según Wikipedia http://es.wikipedia.org/wiki/WS-Security “Es un protocolo
de comunicaciones que suministra un medio para aplicar seguridad a los
Servicios Web”, define mecanismos para proteger la integridad y
confidencialidad en los mensajes.
WS-Security define como utilizar mecanismos existentes para
proporcionar autenticación, confidencialidad e integrar a los servicios web,
de esta forma resuelve que en vez de crear una autenticación desde cero,
se utilice alguna que ya este lista como: Kerbeos y Certificados X.509, se
cifra con el XML Encryption y se firma con la XML Signature tras preparar
los datos mediante el XML Canonicalization.
Una de las características del WS-Security, es que es un framework
( marco de trabajo) que integra otros estándares de mensajes de tipo
36
SOAP ( protocolo de especificación para intercambio de información
estructurada), se puede aplicar tanto a trozos del documento como a su
totalidad e independientemente de los protocolos de transporte.
2.6.2 XML ENCRYPTION Es una recomendación de W3C que según Wikipedia
http://es.wikipedia.org/wiki/XML_Encryption “Especifica un proceso para
cifrar datos (no únicamente documentos XML) y representar esa
información cifrada a su vez en XML para que viaje por los medios de
transmisión”
2.6.3 XML SIGNATURE XML Signature, que en español significa Firma XML, es una
recomendación de W3C que define una sintaxis para firmas digitales.
2.6.4 XML CANONICALIZATION XML Canonicalization, que es español significa canonicalización XML es
un termino que significa escoger la mejor URL para mostrar en un sitio
web. Permite relativamente comparar pares de documentos XML para la
equivalencia; para este propósito, la transformación canónica XML elimina
diferencias no significativas entre los documentos, cualquier documento
XML se puede convertir en XML canónica.
37
3 ANÁLISIS DE METODOLOGÍA ACTUAL DE
DESARROLLO DE SOFTWARE EN PENSIONES DEL
IESS.
3.1 INTRODUCCIÓN En el presente capitulo mostraremos como es la metodología de
desarrollo de software actual que posee el departamento de pensiones
del IESS.
La actual metodología del área de pensiones es la metodología RUP, la
misma que ha sido modificada para cumplir con los lineamientos de la
dirección informática del IESS (DDI), esta ha sido cumplida en cualquier
tipo de proyectos informáticos, tiene cuatro fases:
• Factibilidad
• Elaboración
• Desarrollo
• Implantación
Estas fases deben ser cumplidas a cabalidad y tal como la metodología lo
dicta, algunos artefactos no son obligatorios correspondiente al tipo de
proyecto que se tenga, esta metodología debe ser cumplida por los
proveedores del departamento del IESS, y así constaría en el contrato
del proyecto, a continuación se detalla las fases y artefactos.
3.2 FASES DE LA METODOLOGÍA RUP PARA EL ÁREA DE PENSIONES.
3.2.1 FASE DE FACTIBILIDAD La fase de factibilidad es la primera fase del proyecto y se pone un
énfasis en la elaboración de requerimientos.
38
Tabla 3.1 Fase de factibilidad RUP área de pensiones Disciplina Artefacto Observación
Arquitectura Documento de
arquitectura referencial
Generalmente ya se
cuenta con una
arquitectura definida
entonces el documento
ya se lo tiene realizado
Mecanismos de
Arquitectura
Referencial
Generalmente ya se
cuenta con una
arquitectura definida
entonces el documento
ya se lo tiene realizado
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Modelo de Negocio por
Procesos.
Levantamiento y
optimización de
procesos
Proceso en el cual se
toma el proceso actual,
y con ayuda de los
usuarios funcionales
se lo optimiza
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Continúa …
39
Continuación de la Tabla 3.1
Modelo de Negocios
por Casos de Uso de
Negocio
Visión del negocio
Modelo de casos de
uso del negocio
Especificación de
casos de uso del
negocio
Diagrama de
actividades
Diagramas de clase de
negocio
Diagrama de estados
de negocio
Glosario de términos
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Administración de
requerimientos
Visión del Sistema
Modelo de casos de
uso del sistema
Especificación de
casos de uso del
sistema
Revisión de
especificaciones
suplementarias
Continúa ..
40
Continuación de la Tabla 3.1
Prueba de concepto
(opcional)
Este artefacto es
decisión del líder de
proyectos si cree
conveniente realizarlo
y que circunstancia
realizarlo
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Gestión del proyecto Cronograma de
Factibilidad
Acta de negociación
Plan de comunicación
Especificaciones
suplementarias
Lista y matriz de
riesgos
Matriz inicial de
funcionalidades y
componentes
Plan de desarrollo de
software
Evidencia y lista de
control de control de
calidad
Continúa …
41
Continuación de la Tabla 3.1
Certificación control de
calidad
Informe lideres con
observaciones de
calidad
Evaluación niveles de
servicio
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Fuente: Documentación de Metodología RUP para el IESS
La primera disciplina que se debe realizar es la de gestión del proyecto,
ya que coordinará a todos los elementos del proyecto en sus respectivas
disciplinas, en una etapa pre-inicial se realizará una propuesta del
proyecto, en la cual se incluirá únicamente la planificación de la fase de
factibilidad, lo primordial de esta disciplina en esta fase es coordinar la
comunicación entre los involucrados (stakeholders) mediante el artefacto
de plan de comunicación, es de gran relevancia realizar el artefacto de
especificaciones suplementarias para mirar los detalles que contemplan
los involucrados del proyecto, es de gran importancia detectar los
riesgos que podrían tener el proyecto con esto tratar de mitigarlos y tener
mecanismos de prevención y así poder garantizar el éxito del proyecto,
esta disciplina está terminada cuando está debidamente legalizada con un
acta entre los involucrados, que indiquen el fin de la fase de factibilidad.
En la disciplina de arquitectura en esta fase se trata de brindar los
lineamientos de la arquitectura del proyecto, para esto se tiene como
entrada los artefactos realizados en la disciplina de planificación, tomando
en cuenta en el departamento de pensiones del IESS, se cuenta con
42
una arquitectura pre-definida y este documento ya lo tienen realizado, por
lo que los líderes piden a los arquitectos de software difundan este
documento a los desarrolladores de software y que se firmen las actas
respectivas indicando que se realizó esta capacitación.
En la disciplina del modelado del negocio, el líder de proyecto puede
optar por dos vías de modelado: procesos de negocio y casos de uso del
negocio. La primera se lo realiza generalmente cuando se quiere
optimizar al proceso de negocio que el software posee y se quiere
adicionar requerimientos funcionales que son requeridos y que
impactarían crucialmente a el sistema, este modelado lo realiza el área
de procesos, primero detallan el proceso actual del negocio mediante un
flujo de trabajo y después con la ayuda de los usuarios expertos en el
negocio, optimizan el flujo realizado anteriormente con esto realizan un
documento que describe el flujo a optimizar. La segunda vía es el
modelamiento de casos de uso del negocio, el cual se lo realiza cuando
los usuarios funcionales no tienen claro de todos los requerimientos que
necesita adicionar o modificar en la aplicación, lo que hacen los analistas
es crear ó modificar el modelo de casos de uso del negocio para después
especificar cada caso de uso de negocio de una manera detallada, para
un mejor entendimiento se pueden usar diagramas de actividades, clases
y de estado de UML. El glosario de términos se debe realizar para aclarar
cualquier termino que tengan dudas los involucrados y no caer en
controversias, al momento de la lectura de cualquier artefacto del
modelado de negocio.
La disciplina de la administración de requerimientos se realiza tras
finalizada la etapa del modelado del negocio, y en caso de no haber
finalizado esta disciplina no debe iniciarse, lo principal de esta disciplina
es la especificación del caso de uso del sistema, se debe detallar todos
los requerimientos funcionales en su totalidad, ya que este define el
alcance del software. Para esto el analista de sistemas debe tener la
habilidad de obtener todos los requerimientos dictados por el negocio y
para un mejor entendimiento del caso de uso se puede complementar con
43
la creación de diagramas UML y prototipos de pantallas del sistema. La
especificación de casos del sistema es una parte fundamental para el
proyecto ya que en caso de controversia se remite a estos.
3.2.2 FASE DE ELABORACIÓN La fase de elaboración se realizará siempre y cuando el negocio vea
factible la realización de la solución, en caso que sea factible la
realización del proyecto se tiene que dictar una planificación detallada del
proyecto con todas sus fases y disciplinas, a continuación se describe
las disciplinas con los artefactos respectivos.
Tabla 3.2 Fase de elaboración RUP área de pensiones Disciplina Artefacto Observación
Arquitectura / Vista de
diseño
Diagrama de clases de
diseño
Diagrama de
secuencia de diseño
Arquitectura / Vista de
implementación
Diagrama de
componentes
Arquitectura / Vistas de
datos
Diseño de la base de
datos
Diccionario de datos
Gestión del Proyecto Evidencia y lista de
control de calidad
Certificación control
calidad
Informe lideres con
observación de calidad
Evaluación de niveles
de servicio
Matriz de
componentes afinada
Continúa …
44
Continuación de la Tabla 3.2
Matriz de lineamientos
Matriz de costos
SAD
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Fuente: Documentación de Metodología RUP para el IESS
En esta fase de elaboración se puede complementar la especificación de
casos de uso con diagramas de clases y diagramas de secuencia para
que el desarrollador tenga más entendimiento sobre la programación que
tiene que realizar en la siguiente fase.
En esta fase es fundamental preparar todos los aspectos técnicos para
que el desarrollador tenga todos los aspectos claros y su trabajo lo realice
en el tiempo planificado, una parte importante es el diseño de la base de
datos ya que el arquitecto de software deberá tomar en cuenta lo
existente y empatar con lo que se va a implementar y de esto generar un
diccionario de datos.
En esta fase se elabora el documento SAD es decir el documento de
arquitectura, el objetivo es proporciona una descripción de la
arquitectura del sistema, haciendo uso de diversas visiones
arquitectónicas para representar diversos aspectos del sistema. Se realiza
con el fin de documentar las decisiones de arquitectura significativas que
se han tomado en el sistema definiendo de manera detallada la
distribución de los paquetes del sistema en las diversas capas que éste
presenta, así como una descripción de las capas a utilizar.
45
En esta fase de elaboración también se completan la matriz de
componentes y lineamientos para que se encuentren completas y esté
disponible para los desarrolladores.
3.2.3 FASE DE DESARROLLO Esta fase para ser iniciada, se tuvo que finalizar anteriormente la fase de
elaboración y el objetivo principal es el desarrollo del proyecto, a
continuación se detalla las disciplinas con sus artefactos respectivos.
Tabla 3.3 Fase de desarrollo RUP área de pensiones Disciplina Artefacto Observación
Implementación Código
Scripts de base de
datos
Evidencia de pruebas
unitarias
Evidencias de
sincronización de
código
Evidencia de pruebas
técnicas
Documento de menús
– roles y permisos
Gestión del Proyecto Evidencia y lista de
chequeos de control de
calidad
Certificación control de
calidad
Informe lideres con
observación de calidad
Evaluación de niveles
de servicio
Continúa …
46
Continuación Tabla 3.3
Acta de aceptación de
Líder IESS y Líder
Proveedor
Artefacto creado para
evidenciar que se
acepta esta disciplina
en esta fase y se
encuentra aceptada y
finalizada.
Fuente: Documentación de Metodología RUP para el IESS
En esta fase se construirá el sistema con las dos fases anteriores ya
realizadas, se tienen todos los instrumentos necesarios para culminar
esta fase, lo importante es desarrollar el proyecto con los estándares de
calidad establecidos, para esto se debe tener evidencia de pruebas
unitarias y técnicas, se acepta esta fase cuando el área de pruebas
certifica lo desarrollado.
3.2.4 FASE DE IMPLANTACIÓN En esta fase es importante mencionar que la fase de desarrollo se
encuentra cerrada, y el objetivo de esta fase es desplegar el sistema en el
ambiente de producción.
Tabla 3.4 Fase de implantación RUP área de pensiones Disciplina Artefacto Observación
Deployment y Pruebas
/ Deployment
Plan de despliegue
Deployment y Pruebas
/ Plan de pruebas
Funcionales
Rendimiento y carga
Ambiente e integración
Deployment y Pruebas
/ Evidencia de
pruebas
Funcionales
Rendimiento y de
carga
Continúa …
47
Continuación Tabla 3.4
Ambiente e integración
No funcionales
Informe de errores y
correcciones
Producción Reporte de
capacitación técnica
Plan de operaciones
Plan de soporte
Manual de usuario
Lecciones aprendidas
Gestión del Proyecto Evidencia y lista de
chequeos de control de
calidad
SAD actualizado
Lista de chequeos de
control de calidad
Evaluación de niveles
de servicio
Acta de cierre de
proyecto (finiquito)
Fuente: Documentación de Metodología RUP para el IESS
En esta fase el objetivo principal sería desplegar la solución en ambiente
de producción, se entrega el código fuente al departamento de pruebas
del IESS para el versionamiento respectivo, para luego realizar el plan de
despliegue y con esto documentar el cómo se realizará la instalación de la
solución propuesta en su ámbito de producción final, se debe realizar
pruebas funcionales y técnicas, cabe mencionar que para esto utilizan el
artefacto de especificación de casos de uso y las especificaciones
suplementarias realizadas en fases anteriores, después se debe
desplegar la aplicación en producción, es importante para cerrar la
actualización del documento SAD (Documento de Arquitectura de
48
Software) y realizar los planes de operaciones. Se debe indicar al área de
operaciones del IESS lo que hace la solución y el impacto que traerá a
ellos, lo mismo se realizará con el área de soporte del IESS, es
importante siempre tener lecciones aprendidas, ya que se puede afinar la
metodología y si el área de pruebas aprueba que la calidad es
satisfactoria de acuerdo a los estándares de calidad de esta área, se
procederá a realiza el finiquito o cierre del proyecto.
3.3 EQUIPO DE TRABAJO El área de pensiones sigue la metodología RUP dictada por la DDI del
IESS los cuales cuentan con un equipo de trabajo capaz para completar
todas las fases y disciplinas de esta metodología, como son los
siguientes:
• Gerente de proyectos
• Administrador de Proyectos
• Líderes de proyectos
• Desarrolladores Java
• Ingenieros de pruebas
• Arquitecto de Software
• Arquitecto de Datos
• Analistas de Sistemas
• Analistas Funcionales
• Líder de Analistas
• Líder de Pruebas
• Líder del departamento de arquitectura
3.3.1 PERFIL DE LOS RECURSOS
3.3.1.1 GERENTE DE PROYECTO Descripción general del cargo El perfil de la gerencia de proyectos es mirar las factibilidades de los
proyectos, manejar el presupuesto general de los proyectos, manejo de
los recursos, administración en general.
49
Tabla 3.5 Perfil gerente de proyectos área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Masterado en Business
Administration
Masterado en
Administración de
Negocios
Ingeniero informático Ingeniera informático o
sistemas o afines
PMP Curso en metodologías
PMP
RUP Curso de metodologías
RUP
Experiencia
Experiencia en cargos
similares de Gerencia
de Proyectos
Experiencia anterior en
gerencia de proyectos
informáticos y
administración en
negocios informáticos
8 años
Experiencia en
negociaciones
empresariales
Experiencia validada
en negocios
empresariales
3 años
Experiencia en
liderazgo de sistemas
financieros y
administrativos
Experiencia validada
en proyectos de
sistemas financieros y
administrativos
5 años
Experiencia en
metodologías RUP
Experiencia validada
en manejo de
metodologías RUP
3 años
Habilidades
ü Facilidad de negociación
ü Manejo de recursos humanos
ü Proactivo
Continúa …
50
Continuación de la Tabla 3.5
ü Facilidad de incentivo a empleados
ü Informes gerenciales
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.2 ADMINISTRADORA DE PROYECTOS Descripción general del cargo
El perfil de la administradora de proyectos es coordinar los proyectos
informáticos y recursos del proyecto.
Tabla 3.6 Perfil administrador de proyectos área de pensiones
Requerimiento / Habilidad
Detalle Tiempo
Estudios
Masterado en Gestión
informática
Masterado en gestión
informática
Ingeniero informático Ingeniera informático o
sistemas o afines
RUP Curso de en
metodologías RUP
Experiencia
Experiencia en cargos
similares de
administración de
proyectos informáticos
Experiencia anterior en
administración de
proyectos informáticos
5 años
Experiencia en
liderazgo de sistemas
financieros y
administrativos
Experiencia validada
en proyectos de
sistemas financieros y
administrativos
5 años
Experiencia en
metodologías RUP
Experiencia validada
en manejo de
metodologías RUP
3 años
Continúa …
51
Continuación de la Tabla 3.6
Habilidades
ü Manejo de recursos humanos
ü Proactivo
ü Liderazgo
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.3 LÍDERES DE PROYECTOS Descripción general del cargo
El perfil de líder de proyecto es la gestión de proyectos informáticos
mediante el uso de metodologías de proyectos y el dominio de manejo de
recursos, su principal objetivo es finalizar el proyecto acorde a lo pactado
inicialmente en el tiempo pedido y con el presupuesto asignado,
satisfaciendo al cliente en sus necesidades que lo impulsaron a realizar el
proyecto.
Tabla 3.7 Perfil de líder de proyectos área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Masterado en Gestión
informática
Masterado en gestión
informática
(deseable)
Ingeniero informático Ingeniera informático o sistemas
o afines
RUP Curso de en metodologías RUP
Experiencia
Experiencia en
liderazgo de sistemas
financieros y
administrativos
Experiencia validada en
proyectos de sistemas
financieros y administrativos
4 años
Experiencia en
metodologías RUP
Experiencia validada en manejo
de metodologías RUP
2 años
Continúa …
52
Continuación Tabla 3.7
Habilidades
ü Manejo de recursos humanos
ü Proactivo
ü Liderazgo
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.4 DESARROLLADOR JAVA Descripción general del cargo
El perfil de un desarrollador java es la programación en tecnologías java.
Tabla 3.8 Perfil de desarrollador java área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o sistemas o
afines
Estudios en desarrollo
de software con java
Cursos de desarrollo en software
java
Experiencia
Experiencia en cargos
similares
Experiencia anterior en desarrollo
de software con Java
5 años
Experiencia en
desarrollo de software
financiero y/o
administrativo
Experiencia de desarrollo de
software con Java en negocios
financieros y/o administrativo
3 años
Experiencia en
metodologías RUP
Experiencia validada con
metodologías RUP
3 años
Habilidades
ü Desarrollo de Software con tecnología Web
ü IDE de programación eclipse
ü Programación con Oracle Data Base
ü Proactivo
Fuente: Documentación de Metodología RUP para el IESS
53
3.3.1.5 INGENIERO DE PRUEBAS Descripción general del cargo
El perfil de un ingeniero de pruebas es la verificación y validación de todo
el proceso de desarrollo de software.
Tabla 3.9 Perfil ingeniero de pruebas área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o
sistemas o afines
RUP Curso de en
metodologías RUP
Experiencia
Experiencia en cargos
similares
Experiencia anterior
como ingeniero de
pruebas
5 años
Experiencia con
metodologías RUP
Experiencia validada
con metodologías RUP
3 años
Experiencia de pruebas
en negocios como
financieros y/o
financieros
Experiencia anterior
como ingeniero de
pruebas en
Habilidades
ü Proactivo
ü Manejo de herramientas de pruebas informáticas
ü Liderazgo
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.6 ARQUITECTO DE SOFTWARE Descripción general del cargo
El perfil de un arquitecto de software es orientar y guiar el mejor esquema
para una solución informática.
54
Tabla 3.10 Perfil arquitecto de software área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o
sistemas o afines
Cursos en Java Estudios en
tecnologías Java
Curso en UML Estudios en
diagramación en UML
Experiencia
Experiencia en
desarrollo de sistemas
Experiencia anterior
como arquitecto de
software
10 años
Experiencia con
arquitecturas java
Experiencia con
arquitecturas java
5 años
Experiencia en
versionamiento de
sistemas
Experiencia en
versionamiento de
sistemas
8 años
Habilidades
ü Proactivo
ü Manejo de herramientas de modelamiento de arquitecturas
ü Liderazgo
ü Manejo de recursos técnicos
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.7 ARQUITECTURA DE DATOS Descripción general del cargo
El perfil de un arquitecto de datos es orientar y guiar el mejor esquema en
lo relacionado a la base de datos
55
Tabla 3.11 Perfil de arquitectura de datos área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o
sistemas o afines
Cursos en
programación con
Oracle
Estudios en
programación con base
de datos Oracle
Curso de afinación de
base de datos Oracle
Estudios en afinación
de base de datos
Oracle
Experiencia
Experiencia en
programación de
sistemas con Oracle
Experiencia anterior
como programador
Oracle
10 años
Experiencia afinando
base de datos Oracle
Experiencia afinando
base de datos Oracle
5 años
Experiencia modelando
sistemas informáticos
Experiencia modelando
sistemas informáticos
8 años
Habilidades
ü Proactivo
ü Manejo de herramientas de modelamiento de base de datos Oracle
ü Liderazgo
ü Manejo de recursos técnicos
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.8 ANALISTAS DE SISTEMAS Descripción general del cargo
El perfil de un analistas de sistemas es plasmar de una manera óptima en
requerimientos técnicos lo que el negocio quiere implementar como
solución informática.
56
Tabla 3.12 Perfil de analistas de sistemas Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o
sistemas o afines
Cursos en
metodologías RUP
Estudios en
metodologías RUP
Curso de
modelamiento con
UML
Estudios de
modelamiento UML
Experiencia
Experiencia en análisis
de sistemas
informáticos y
administrativos
Experiencia anterior
como analista en
sistemas informáticos y
administrativos
5 años
Experiencia en
modelamiento con
UML
Experiencia en
modelamiento con
UML
5 años
Habilidades
ü Proactivo
ü Manejo de herramientas de modelamiento UML
ü Liderazgo
ü Facilidad de palabra
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.9 ANALISTAS FUNCIONALES Descripción general del cargo
El perfil de analistas funcional es proporcionar todo la información acerca
del negocio que necesita el proyecto para realizar la solución.
57
Tabla 3.13 Perfil de analistas funcionales Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero en
administración de
empresas o afines
I Ingeniero en
administración de
empresas o afines
Experiencia
Experiencia en análisis
funcional de sistemas
informáticos y
administrativos
Experiencia anterior
como analista en
sistemas informáticos y
administrativos
5 años
Habilidades
ü Proactivo
ü Liderazgo
ü Facilidad de palabra
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.10 LÍDER DE ANALISTAS Descripción general del cargo
El perfil de líder de analistas es dar los lineamientos necesarios para la
realización de la disciplina de administración de requerimientos, manejo
del personal de analistas y también reuniones de pre factibilidad.
Tabla 3.14 Perfil de líder de analistas Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático
o sistemas o afines
Cursos en metodologías
RUP
Estudios en
metodologías RUP
Curso de modelamiento
con UML
Estudios de
modelamiento UML
Continúa …
58
Continuación de la Tabla 3.14
Experiencia
Experiencia en
análisis de
sistemas
informáticos y
administrativos
Experiencia anterior como
analista en sistemas
informáticos y
administrativos
8 años
Experiencia en
modelamiento con
UML
Experiencia en
modelamiento con UML
8 años
Experiencia como
analista de
sistemas en IESS
Experiencia anterior como
analista en el IESS
1 año
Habilidades
ü Proactivo
ü Manejo de herramientas de modelamiento UML
ü Liderazgo
ü Facilidad de palabra
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.11 LÍDER DE PRUEBAS Descripción general del cargo
El perfil de líder de pruebas es dar los lineamientos necesarios para la
realización del control de calidad de los proyectos, manejo del personal
de pruebas y también reuniones de pre factibilidad.
Tabla 3.15 Perfil de líder de pruebas área de pensiones Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o sistemas
o afines
RUP Curso de en metodologías RUP
Continúa …
59
Continuación de la Tabla 3.15
Experiencia
Experiencia en
cargos similares
Experiencia anterior como
ingeniero de pruebas
8 años
Experiencia con
metodologías RUP
Experiencia validada con
metodologías RUP
5 años
Experiencia de
pruebas en negocios
como financieros y/o
financieros
Experiencia anterior como
ingeniero de pruebas en
5 años
Experiencia como
ingeniero de pruebas
en el IESS
Experiencia como ingeniero de
pruebas en el IESS
Mínimo de 1
año
Habilidades
ü Proactivo
ü Manejo de herramientas de pruebas informáticas
ü Liderazgo
Fuente: Documentación de Metodología RUP para el IESS
3.3.1.12 LÍDER DE DEPARTAMENTO DE ARQUITECTURA Descripción general del cargo
El perfil de líder de arquitectura es dar los lineamientos necesarios para
la realización de arquitectura de los diferentes proyectos, manejo del
personal de arquitectura y también reuniones de pre factibilidad.
Tabla 3.16 Perfil de líder de departamento de arquitectura área de pensiones
Requerimiento / Habilidad
Detalle Tiempo
Estudios
Ingeniero informático Ingeniera informático o
sistemas o afines
Continúa …
60
Continuación de la Tabla 3.16
Curso en Java Estudios en
tecnologías Java
Cursos en
programación con
Oracle
Estudios en
programación con
base de datos Oracle
Curso de afinación de
base de datos Oracle
Estudios en afinación
de base de datos
Oracle
Experiencia
Experiencia en
programación de
sistemas con Oracle
Experiencia anterior
como programador
Oracle
10 años
Experiencia afinando
base de datos Oracle
Experiencia afinando
base de datos Oracle
5 años
Experiencia modelando
sistemas informáticos
Experiencia
modelando sistemas
informáticos
8 años
Experiencia en Java Experiencia en
tecnologías Java
5 años
Experiencia como
arquitecto Java en
IESS
Experiencia en Java en
el IESS
Mínimo 2 años de
experiencia
Habilidades
ü Proactivo
ü Manejo de herramientas de modelamiento de base de datos Oracle
ü Manejo de herramientas de desarrollo
ü Liderazgo
ü Manejo de recursos técnicos
Fuente: Documentación de Metodología RUP para el IESS
61
3.4 ORGANIGRAMA DE GESTIÓN DE PROYECTOS DEL IESS
En la dirección de informática del IESS existe el equipo de trabajo antes
descrito, los cuales vamos a mostrar cómo funcionan con el área de
pensiones.
Figura 3.1 Organigrama DDI con departamento de Pensiones
Realizado por: POZO W., octubre 2013, tomado con entrevistas
realizadas al personal del departamento de pensiones del
IESS.
La DDI (Departamento de Dirección Informática) del IESS, como
observamos tiene recursos informáticos para los proyectos informáticos,
pero en particular el área de pensiones tiene sus propios líderes de
proyecto y desarrolladores debido que el negocio es tan complejo que
necesita especialistas de negocio.
Director informático DDI
Líder de analistas
Analistas
Lider de arquitectura
Arquitectura de Datos
Arquitectura de software
Arquitectura de infraestructura
Lider de pruebas
Ingeniero de pruebas
Desarrolladores
Desarrolladores Java
Desarrollladores Oracle
Pensiones
Lideres de proyecto departamento Pensiones
Desarrollador de pensiones
departamento Pensiones
Lider de proyecto
62
3.5 RECURSOS TECNOLÓGICOS
3.5.1 RECURSOS DE HARDWARE El departamento de pensiones posee su infraestructura propia debido a lo
que demanda el negocio.
Tabla 3.17 Recursos de hardware del área de pensiones Tecnología Ambiente Observaciones
Servidor de Base de
datos Oracle
Desarrollo
Servidor de Base de
datos Oracle
Pruebas
Servidor de Base de
datos Oracle
Producción
Servidor de
aplicaciones JBOSS 4.x
Pruebas
Servidor de
aplicaciones JBOSS 4.x
Producción
Fuente: Documentación de Metodología RUP para el IESS
3.5.2 RECURSO DE SOFTWARE
3.5.2.1 SOFTWARE DE AMBIENTE DE DESARROLLO El ambiente de desarrollo lo tienen configurado en cada máquina del
programador.
Tabla 3.18 Software de ambiente de desarrollo del área de pensiones Tecnología Observaciones
Java 1.6
JBoss 4.x Servidor de aplicaciones
Oracle 11 Gestor de Base de datos
Eclipse IDE de desarrollo
Fuente: Documentación de Metodología RUP para el IESS
63
3.5.2.2 SOFTWARE DE AMBIENTE DE PRUEBAS / PRODUCCIÓN El ambiente de pruebas y producción, son similares a continuación
detallamos el software
Tabla 3.19 Software de ambiente de pruebas / producción del área de pensiones
Tecnología Observaciones
Java 1.6
JBoss 4.x Servidor de aplicaciones
Oracle 11 Gestor de Base de datos
Fuente: Documentación de Metodología RUP para el IESS
3.5.3 ARQUITECTURA DE SOFTWARE DEL SOFTWARE DE PENSIONES.
La arquitectura de software esta realizada en 2 capas físicas:
• Base de Datos
• Aplicación
La Base de Datos es Oracle 10 G, y solo contiene objetos como tablas y
vistas, es decir no tiene procedimientos almacenados.
3.5.3.1 CAPA DE APLICACIÓN La capa de aplicación esta compuesta: Capa Medía y Fachada
3.5.3.1.1 CAPA MEDIA
La capa media está realizada en tecnología JAVA versión 1.6, es la que
gestiona la información con la base datos y esta a su vez contiene una
lógica de negocio para los componentes empresariales que necesita la
fachada para el usuario.
64
Tabla 3.20 Capa media de arquitectura de software de pensiones Componente Descripción Observación
JPA 1.X Persistencia de
Base de Datos
Regresa información que contiene
la base de datos, y actualiza la
información de los procesos
entiéndase como inserción,
actualización y borrado de
información.
EJB 2.X Componentes
empresariales
Contiene los procesos de negocio
y su objetivo es separar la lógica
del negocio con la fachada y para
el manejo con la base de datos
utiliza JPA
Fuente: Documentación de Arquitectura de Software del IESS
3.5.3.1.2 CAPA DE FACHADA
La capa de fachada está realizada en tecnología JAVA versión 1.6, es la
que se comunica con el usuario y con la capa media de esta forma
gestiona la información de la base de datos
Tabla 3.21 Capa de fachada de arquitectura de software de pensiones Componente Descripción Observación
JSF 1.X Tecnología para
ambientes web
de java
MVC Patrón de diseño
que hace el
Modelo Vista
Controlador
RICHFACES
3.X
Librería
necesaria para la
fachada
Esta librería es necesaria para el
diseño de la página web que va a
utilizar al base de datos
Fuente: Documentación de Arquitectura de Software del IESS
65
3.5.3.2 SEGURIDAD DE APLICACIÓN La seguridad la realizan con JAAS ( Java Authentication and Authorization
Services) , que en español significa Autenticación y Autorización Java y
cuyo fin es brindar un estándar para los procesos de autorización y
autenticación de usuarios.
3.5.4 CAMBIO DE AMBIENTE PARA PRODUCCIÓN En el desarrollo de software para desplegar en el ambiente de producción,
se debe realizar estos pasos.
Figura 3.2 Diagrama de cambios de ambiente para producción
Realizado por: POZO W., octubre 2013
En el ambiente de desarrollo de cada programador se encuentra en cada
computador del mismo y la base de datos se encuentra en otro servidor,
cuando se encuentra concluida esta fase se despliega en un ambiente de
pruebas el cual es similar al ambiente de producción y el objetivo de este
ambiente es eliminar los problemas que se hubieran tenido al momento
de desplegar en el ambiente de producción, por último el ambiente de
producción debería ser desplegado sin mayor impacto.
Desarrollo Pruebas Producción
66
3.6 CONCLUSIONES Hemos detallado la metodología RUP que utiliza el departamento de
pensiones de IESS, tenemos las siguientes conclusiones :
• La ventaja indiscutible de esta metodología es que todo se
encuentra documentado, y esto es sumamente ventajoso al
momento de una auditoría y para que no quede nada fuera.
• El departamento de pensiones del IESS tiene líderes de proyecto,
desarrolladores de sistemas y usuarios funcionales que son
especialistas en el área de pensiones, con esto se tiene la
capacidad de realizar los proyectos más rápido, ya que se tiene la
experiencia suficiente.
• Una desventaja que hemos analizado es la ausencia de arquitectos
de SOA con experiencia en productos Oracle.
• No existe artefactos que se adapten para desarrollar software
basados en sistemas escalables.
• Es muy claro con todo lo que hemos analizado que es necesario
modificar la metodología para adaptarla al desarrollo de sistemas
escalables.
67
4 METODOLOGÍAS DE DESARROLLO PARA
SOFTWARE ESCALABLES
4.1 INTRODUCCIÓN En el presente capitulo expondremos las principales metodologías de
desarrollo de software para SOA, que podrían usarse en el departamento
de pensiones del IESS.
La mayoría de veces empresas quien invertir en software escalable por
los beneficios que han sido mencionados, se piensa que el trabajo va ser
sencillo ya que se idean que es solamente conectar aplicaciones con
otras y lo último que toman en cuenta es el impacto que puede ocasionar,
como perdida de la continuidad del negocio y esto repercute en el
crecimiento financiero de la empresa.
Mudarse de un sistema de información tradicional a una que sea
escalable requiere implementar SOA (Arquitectura Orientada a Servicios)
generaría numerosos beneficios para las empresas como la disminución
de la brecha que tiene el software con el negocio de la empresa y de esta
manera obteniendo una agilidad constante de cambios en las soluciones.
La mayoría de metodologías SOA proponen dividir el ciclo de desarrollo
en seis fases: análisis orientada a servicios, diseño orientado a servicios,
desarrollo de los servicios, prueba de servicios, transacción despliegue de
servicios, administración de servicios. Las primeras dos fases son las más
importantes debido a que el éxito del desarrollo de software con SOA
depende de estos. Las tecnologías y estándares tales como BPM, BPEL,
WSDL, EA, OOAD son importantes para el desarrollo de SOA pero ha
sido ampliamente reconocido que ellos no son suficiente por sí solos.
Solamente por aplicar una capa de servicios web en las aplicaciones o
componentes no garantiza que sea cierto las propiedades de SOA como
alineamiento al negocio, flexibilidad, bajo acoplamiento y reusabilidad.
Existe algunas metodologías SOA tales como IBM RUP/SOMA, SOAF,
68
SOUP, metodología por Thomas Erl y metodología por Michael
Papazoglou han sido propuestas para garantizar el desarrollo de SOA con
éxito .
4.2 CARACTERÍSTICAS DE LAS FASES DE ANÁLISIS Y DISEÑO DE METODOLOGÍAS SOA.
4.2.1 ANÁLISIS SOA Y ESTRATEGIAS DE DISEÑO ü Tres estrategias existen en el desarrollo de SOA tales como: top-
down que en español significa de arriba hacia abajo, bottom – up
que en español es abajo hacia arriba y meet-in-the-middle que en
español sería encontrarse en el medio existente, cada uno de estos
difiere en la cantidad de análisis de dominios de negocio y de las
dependencias de sistemas heredados que se tengan ya realizados.
4.2.1.1 ENFOQUES DE SOA En SOA existen tres enfoques al momento de construir servicios , que son
los siguientes:
• Bottom – Up (Abajo hacia arriba), esta estrategia se enfoca para la
modernización de los sistemas antiguos o sistema que no son
SOA para ecosistemas SOA.
Las siguientes actividades están involucradas
ü Análisis de aplicaciones a nivel de empresa
ü Análisis de redundancia y refactorización de esfuerzo
ü Identificación de los servicios de granularidad gruesa y la
creación de interfaces / fachada por encima de las
funcionalidades antiguas
ü Habilitación de fachadas como servicios
69
Este enfoque no requiere necesariamente el enfoque de procesos
de negocio (identificación de procesos, modelarlos y luego utilizar
los servicios para implementar esos procesos)
• Top – Down ( De arriba hacía abajo), También conocido como
campo verde. Este enfoque es el más adecuado cuando se va a
implementar un nuevo sistema.
Las siguientes actividades están involucradas
ü Identificar grandes dominio de negocio y su relación
ü Identificar los procesos de negocio en marcha o requeridos
para ejecutar el sistema. También identifican otros procesos,
roles, etc.
ü Identificar los servicios de alto nivel necesarios para ejecutar
estos procesos basados en las actividades del proceso
ü Analizar cómo es el sistema para identificar los procesos
implementados para asignarlos con el sistema y los
procesos necesarios para saber espacio deseado
ü Hacer una estrategia para llenar los vacíos, permitiendo
procesos que faltan en el nuevo sistema
Beneficios de este enfoque
ü Ayuda en la definición del alcance
ü Captura de reglas de negocio en un alto nivel
ü Comprender mejor el contexto empresarial
ü Las dependencias pueden ser identificados antes del nivel
superior
ü Ayuda en las interacción entre los diversos actores
ü Complejidad dentro de la empresa en términos de patrones
de intercambio de mensajes se conoce antes.
• Meet in the middle (encontrarse en el medio), los dos enfoques
antes descritos tienen ventajas y desventajas. La verdadera
solución de qué enfoque elegir es hacer las dos cosas y no solo
una, eso es lo que se llama el término “Meet in the middle”.
70
El enfoque top-down es muy importante para alcanzar los objetivos
de negocio, y es muy importante utilizar las inversiones realizadas
en los sistemas actuales de los últimos años. Al combinar estos
dos enfoques se obtiene lo mejor de ambos mundos: la integración
con la infraestructura actual de la aplicación (en una forma
orientada a servicios) y la preparación para la funcionalidad, así
impulsando el proceso de desarrollo de software donde se
especifican las necesidades del negocio.
4.2.2 ANÁLISIS SOA Y COBERTURA DE DISEÑO El análisis orientados a servicios y las fases de diseño de metodologías
SOA pueden ser divididas en 5 actividades principales.
• Análisis de negocios de los objetivo de la organización, el
objetivo de este paso se identificará lo siguiente: objetivos
organizacionales, objetivos de negocio y KPI’s (Key Perfomance
Indicator es decir Indicadores de Rendimiento) para su realización,
así determinando lo siguiente:
ü Tecnología
ü Aplicaciones
ü Glosario de términos comunes de negocio
ü Reglas de negocio
ü Actores de negocio
ü Los principales Casos de Uso de Negocios
ü Modelo de Negocios “As-Is“ y “To-Be“ que en español
tendría un significado de ”Tal cual” y “A-Ser
• Planificación de proyectos SOA, el objetivo de esta etapa es
formular la visión y el alcance del proyecto SOA, seleccionamos la
estrategia de ejecución SOA ( creación de servicios desde cero,
creación de servicios desde componentes de software, compra de
71
servicios desde proveedores de tercero) , creación del plan del
proyecto y llevar acabo el análisis financiero.
• Identificación del servicio, lo principal de esta etapa es
seleccionar candidatos de servicios, y también identificar todos los
requerimientos funcionales y no funcionales de SOA, se realizará lo
siguiente:
o El Modelo de negocio “to-be“ se separará dentro de los
dominios de negocio
o Iniciar con las especificaciones de los candidatos de servicio,
la comunicación y las dependencias iniciales
o Se analizan las aplicaciones existentes en orden para
encontrar cuáles son los componentes de software pueden
ser reusados en el desarrollo con SOA.
• Análisis y especificación de servicios, el objetivo de esta etapa
es seleccionar cuáles de los candidatos de servicios van a ser
desarrollados. Los servicios son agrupados para estas
funcionalidades en: entidades de negocio, aplicaciones y servicios
de proceso de negocio. Las especificaciones de procesos de
negocio que agruparan los servicios son creadas.
• Decisiones de realización de servicio, el objetivo de esta etapa
es documentar las decisiones realizadas en los servicios, asignar
componentes de servicios a las capas y acoplar técnicamente la
exploración de factibilidad.
4.2.3 ADOPCIÓN DE TÉCNICAS EXISTENTES Y NOTACIONES
La mayoría de metodologías SOA son basadas en técnicas como OOAD,
CBM, BPM, Arquitecturas Empresariales y notaciones tales como UML y
BPMN, mientras otras técnicas no especifican claramente técnicas y
notaciones, estas técnicas permiten al usuario elegir qué técnica y
72
notación son apropiadas en una situación concreta, esto implica que las
metodologías son difíciles para entender y usar para usuarios sin
experiencia.
4.3 ANÁLISIS DE METODOLOGÍAS EXISTENTES SOA
4.3.1 SOMA SOMA (Service Oriented Modeling and Arquitecture), que en español
significa Modelamiento y Arquitectura Orientada a Servicios, es una
metodología para el modelamiento de aplicaciones SOA y diseño de
métodos que se extiende tradicionalmente a orientación de objetos y
análisis basado en componentes y diseño de métodos.
SOMA es un método extremo a extremo para la identificación,
especificación, realización e implementación de servicios (incluyendo
servicios de información) , componentes, flujos ( procesos / composición) .
SOMA se puede utilizar en tecnologías actuales, en áreas tales como
análisis de diseño, áreas funcionales de agrupación, análisis orientada a
variabilidad, modelamiento de procesos, desarrollo basado en
componentes, análisis y diseño orientado a objetos y modelamiento de
casos de uso. SOMA introduces nueva tecnologías tales como
modelamiento como meta de servicio, modelo creación de servicio y
análisis de activos existentes.
SOMA es basado en tres grandes fases:
• Identificación, descubren candidatos de servicios, componentes
empresariales y flujos.
• Especificación, toma de decisiones en exposición de servicios y
especifica los servicios y componentes empresariales a realizar
• Realización, capta las decisiones de realización
73
Las fases son usadas para modelar las tres principales elementos de
SOA:
• Servicios
• Componentes que implementan los servicios, que también son
conocidos como componentes de servicios
• Flujos que pueden ser usados para componer servicios necesarios
en una aplicación SOA.
Figura 4.1 Diagrama de SOMA
Fuente: tomado de IBM
http://www.ibmpressbooks.com/articles/article.asp?p=1194198&seq
Num=2
Los pasos SOMA se realizan de forma iterativa e incremental.
Figura 4.2 Gráfico de interacción entre fases SOMA
Fuente: tomado de IBM tomado de IBM
http://www.ibmpressbooks.com/articles/article.asp?p=1194198&seqNum
=2
74
4.3.1.1 FASE DE IDENTIFICACIÓN En esta fase identifica los candidatos de servicios. Todos los
requerimientos funcionales y no funcionales están contemplados, se
puede comenzar tanto de los modelos de negocio a través de la
descomposición de dominios que incluye el análisis de las áreas
funcionales y descomposición de procesos y sistemas existentes.
4.3.1.2 FASE DE ESPECIFICACIÓN En esta fase se trata de seleccionar cuales de los candidatos de servicios
serán desarrollados y se creará una especificación detallada de estos.
Estas especificaciones forman el modelo de servicio, una entrega clave
de SOMA es la que cubre la sintaxis y semántica de invocación de
servicios, así como temas operacionales transversales y otros, tales
como la propiedad de servicio, dependencias, control de versiones, y las
cuestiones de gobernanza.
4.3.1.3 FASE DE REALIZACIÓN La realización de servicios y componentes son usualmente construidos
como el negocio necesita y son vistos desde un punto de arquitectura de
aplicaciones, también se definen herramientas y técnicas tales como
patrones de diseño bien establecidos.
4.3.2 IBM RUP/SOMA Es una metodología integrada desarrollada por IBM, desea llevar
aspectos únicos de SOMA para RUP, ya que SOMA es una metodología
patentada por IBM.
La metodología consiste en cuatro fases:
• Análisis de transformación de negocios (opcional)
• Identificación
• Especificación
• Realización de servicios.
75
Las etapas de análisis y diseño de SOA son de gran importancia sin
embargo IBM RUP / SOMA no cubre las etapas de despliegue y
administración de servicios.
4.3.2.1 ANÁLISIS DE TRANSFORMACIÓN DE NEGOCIOS La primera etapa de análisis de transformación de negocios pueden ser
asignada como el comienzo de la fase de la metodología clásica RUP.
Esta fase es opcional y puede ser omitida si la organización tiene un
análisis completo del negocio y no quiere ser mejorado. El objetivo es
describir “tal cual es“ (más conocido en ingles como “as-in“) el proceso de
negocio de una organización para entender las áreas problemáticas y las
potenciales mejoras, así como cualquier información sobre temas
externos como competidores o tendencias en el mercado.
Esta fase comprende actividades como: evaluación de objetivos de la
organización y sus objetivos, identificación de metas de servicio.
4.3.2.2 IDENTIFICACIÓN Esta etapa puede ser asignada a la fase de elaboración de la clásica
metodología RUP y el objetivo es identificar candidatos de servicios. La
identificación de servicios comprende actividades como:
• Descomposición de dominio.
• Modelamiento de metas de servicio
• Análisis de activos existentes
4.3.2.3 ESPECIFICACIÓN Esta etapa puede ser asignada a la elaboración de la clásica metodología
RUP y se enfoca a la selección de candidatos de servicios que serán
desarrollados.
76
La etapa de especificación de servicio comprende actividades tales como:
• Especificación de servicios
• Análisis del subsistema
• Especificación de componentes
4.3.2.4 REALIZACIÓN DE SERVICIOS Esta fase puede ser asignada a la fase de construcción de la clásica
metodología RUP, enfocada a finalizar el diseño de los componentes y
con esto poder implementar los componentes. La realización de servicios
comprende actividades tales como:
• Documentación de decisiones de realización de servicios
• Asignación de servicios
• Componentes de capas
4.3.3 SOAF SOAF significa Service Oriented Architecture Framework que en español
significa Marco de Arquitectura Orientada a Servicios, esta metodología
consiste en cinco fases:
• Obtención de información
• Identificación de servicios
• Definición de servicios
• Realización de servicio
• Hoja de ruta y planificación
El objetivo de SOAF es aliviar la identificación de servicios, definición y
realización de actividades mediante la combinación de un modelado top-
down ( de arriba hacia abajo) de un proceso existente de negocio con un
análisis bottom-up (de abajo hacia arriba) de una aplicación existente.
77
4.3.3.1 DESCRIPCIÓN DE LA METODOLOGÍA SOAF parte de una etapa de obtención de información, lo clave de esto
es definir el alcance y restricciones de procesos de negocios existentes y
determinar la tecnología que utiliza la empresa. Se crea el modelo de
negocio “as-is“ (en español ”tal cual es”) y el modelo de negocio “to-
be“ (en español “a ser“) es definido, se identifican los candidatos de
servicios para contemplar lo que especifica el modelo de negocio “to-be“.
Requerimientos No Funcionales (NFRs) y Acuerdos de nivel de negocios
(BLAs) deben ser definidos, categorizados y priorizados. El Mapeo de
Procesos de Negocio es realizado con el objetivo de analizar los activos
de software existentes y poder descubrir funcionalidades candidatas de
aplicaciones SOA.
En la etapa de identificación de servicios, el objetivo es definir un
conjunto óptimo de servicios. La realización de servicios tiene por
objetivo definir estrategias de transformación que serán usadas para la
transición de la arquitectura de aplicaciones antiguas, para que en un
futuro la arquitectura de la aplicación empresarial se pueda reusar,
desarrollar y pueda estar en la capacidad de comprar servicios de
terceros. La hoja de ruta y la fase de planificación proporcionan un detalle
de la planificación de transformación e identificación de negocios y
riesgos técnicos.
4.3.4 METODOLOGÍA DE PAPAZOGLOU Es una metodología de desarrollo de SOA que cubre un ciclo de vida
SOA, se basa en estar bien establecido el desarrollo de aplicaciones
como RUP, desarrollo basado en componentes y BPM. La metodología se
basa en procesos iteractivos e incrementales y comprende una
preparatoria de planificación y ocho fases principales:
• Análisis de Servicios
• Diseño de Servicios
• Construcción de Servicios
78
• Prueba de Servicios
• Aprovisionamiento de Servicios
• Despliegue de Servicios
• Ejecución de Servicios
• Monitoreo de Servicios.
Hablar acerca de análisis y diseño SOA no se trata solamente de la
planificación, ya que el análisis y diseño de servicios son bastantes
importantes. La fase de planificación es una preparación al desarrollo del
proyecto de software, la etapa de análisis de negocios necesita la revisión
de tecnología que se impulsa en ese momento, se debe contemplar el
análisis financiero de los proyectos y una creación de un plan de
desarrollo de SOA. El objetivo de la fase de análisis orientada a servicios
es para obtener los requisitos para la aplicación SOA. La creación de
análisis de negocio como un modelo de procesos de negocio “as-is“ (Tal
como está, es decir como se encuentra actualmente) que permite a los
involucrados entender un portafolio de servicios disponibles y procesos de
negocios. El resultado de la fase es la creación del modelo de procesos
de negocio “to-be“ (es decir como debe ser) que será implementado en
soluciones SOA. La fase de análisis consiste en cuatro fases principales:
• Identificación de procesos
• Alcance de procesos
• Análisis de brecha (gap) de negocio
• Realización de proceso
4.4 COMPARACIÓN ENTRE METODOLOGÍAS A continuación se analizará las metodologías antes descritas con el
objetivo de determinar el mejor acoplamiento a la metodología RUP del
IESS.
79
Tabla 4.1 Comparación entre metodologías de desarrollo de software SOA
Factor Metodología
SOMA
IBM
RUP/SOM
A
SOAF
PAPAZO
GLOU
Alto acoplamiento con RUP Bajo Alto Bajo Alto
Posee estrategias de análisis y
diseño SOA
Medio Alto Alto Alto
La madures de la metodología SI SI SI SI
Puede manejar técnicas y
notaciones
SI SI SI SI
Tipo de enfoque que soporta Meet in
the
middle
Meet in
the middle
Meet in
the
middle
Meet in
the
middle
Permite hacer análisis de
negocio
Medio Alto Alto Alto
Todos los roles están claros SI SI SI SI
Soporta UML INFORM
ATIVO
SI SI NO
Ciclo de vida COMPL
ETO
COMPLE
TO
ANÁLI
SIS Y
PROYE
CTO
COMPL
ETO
Realizado por: POZO W., octubre 2013
Tomando en cuenta el alto acoplamiento a la metodología RUP quedarían
dos IBM / RUP SOMA y Papazoglou, el resto de factores son
exactamente lo mismo y el diferenciador sería el soporte con UML,
fundamental con la metodología RUP del IESS ya que se utiliza bastante,
quedaría como finalista IBM/ RUP SOMA.
80
5 PROPUESTA DE METODOLOGÍA DE SOFTWARE
ESCALABLE PARA EL IESS.
5.1 INTRODUCCIÓN Tras el análisis presentado en el capítulo anterior hemos determinado que
la metodología a adaptar es IBM / RUP SOMA, tenemos que realizar una
propuesta metodológica basada en RUP del IESS con la anterior
mencionada y realizar mediciones si es satisfactoria.
5.2 ROLES DE IBM RUP SOMA A continuación mostramos los roles que son necesarios:
• Arquitectura de seguridad
• Implementador
• Diseñador de negocios
• Analista de proceso de negocio
• Diseñador de base de datos
• Diseñador
• Arquitecto de software
• Arquitecto de negocio
5.2.1 ARQUITECTO DE SEGURIDAD Este rol lidera el desarrollo de la arquitectura de seguridad del sistema,
que incluye la selección de los patrones de seguridad para el diseño del
sistema, la documentación de la política técnica relativa a la aplicación de
seguridad y el apoyo a las decisiones técnicas clave que limitan la
implementación de seguridad global para el proyecto.
Una persona de este rol lidera a un grupo de desarrolladores en la tarea
del desarrollo de una arquitectura de seguridad. Una arquitectura de
seguridad es una representación de las mejores prácticas de la
comunidad de seguridad. A menudo incluye la selección de los patrones
de seguridad preferidas para el diseño del sistema (los patrones de
81
diseño de seguridad), la documentación de la política técnica (políticas de
patrones de diseño ) en relación con la implementación de seguridad
(patrones de implementación de seguridad) y los patrones de arquitectura
de seguridad reflejan las decisiones técnicas claves que limitan la
implementación del proyecto.
5.2.2 IMPLEMENTADOR Este rol desarrolla componentes de software y realiza pruebas de
desarrollo para la integración en subsistemas más grandes de acuerdo
con las normas adoptadas en el proyecto
El papel implementador es responsable de desarrollar y probar los
componentes, de conformidad con las normas adoptadas en el proyecto,
para su integración en subsistemas más grandes. Cuando los
componentes de prueba, como conductores o talones, se deben crear
para soportar las pruebas, el implementador también es responsable de
desarrollar y probar los componentes de prueba y los subsistemas
correspondientes.
5.2.3 DISEÑADOR DE NEGOCIOS Este papel detalla la especificación de una parte de la organización.
Esta función especifica el flujo de trabajo de los casos de uso del negocio
en términos de sistemas de negocios, trabajadores de empresas y
entidades empresariales. También distribuye el comportamiento de estos
sistemas de negocios, trabajadores de empresas y entidades
empresariales - la definición de sus responsabilidades, operaciones,
atributos y relaciones.
5.2.4 ANALISTA DE PROCESO DE NEGOCIO Este rol dirige y coordina los requerimientos del negocio para esbozar y
delimitar la organización que va a ser modelado, si se adopta un enfoque
82
de casos de uso del negocio el analista de proceso de negocio realizará lo
siguiente:
• Coordinar el modelado de casos de uso del negocio
• Establecer lineamientos y establecer el alcance del proyecto
• Establecer actores
• Realizar Casos de Uso del Negocio y la interacción entre estos.
5.2.5 DISEÑADOR DE BASE DE DATOS Este rol lleva el diseño de la estructura de base de datos persistente para
ser utilizado por el sistema.
Para la mayoría de los proyectos de desarrollo de aplicaciones, la
tecnología utilizada para la persistencia de datos es una base de datos
relacional. El diseñador de la base de datos se encarga de definir el
diseño de base de datos detallada, incluyendo tablas, índices, vistas,
restricciones, disparadores, procedimientos almacenados, y otros
constructos específicos de bases de datos necesarias para almacenar,
recuperar y borrar objetos. Esta información se mantiene en el Artefacto:
Modelo de Datos.
El alcance de las tareas realizadas por el papel de diseñador de la base
de datos varían dependiendo del tamaño y complejidad de las actividades
de desarrollo de aplicaciones y el tipo de mecanismos de almacenamiento
de datos persistentes utilizados para el proyecto.
5.2.6 DISEÑADOR Este rol lleva el diseño de una parte del sistema, dentro de las
limitaciones de los requisitos, la arquitectura, y el proceso de desarrollo
del proyecto.
El diseñador identifica y define las responsabilidades, operaciones,
atributos y relaciones de elementos de diseño. El diseñador asegura que
83
el diseño es compatible con la arquitectura de software, y es detallada a
un punto en el que la aplicación puede continuar.
5.2.7 ARQUITECTO DE SOFTWARE Este papel lidera el desarrollo de la arquitectura de software del sistema,
que incluye la promoción y creación de apoyo a las decisiones técnicas
clave que limitan el diseño e implementación general del proyecto.
El arquitecto de software tiene la responsabilidad general de la
conducción de las principales decisiones técnicas, expresado como la
arquitectura de software. Esto normalmente incluye la identificación y
documentación de los aspectos de gran importancia arquitectónica del
sistema, incluyendo los requisitos, diseño, implementación y despliegue
"vistas" del sistema.
El arquitecto también es responsable de establecer el fundamento de
estas decisiones, el equilibrio de los intereses de los diversos grupos de
interés, reduciendo los riesgos técnicos, y garantizar que las decisiones
se comunican efectivamente, validados y respetados.
5.2.8 ARQUITECTO DE NEGOCIO Este rol tiene la responsabilidad del negocio de la empresa, debe estar
involucrado en todas las decisiones importantes relativas a la estructura,
el comportamiento principal y su realización, las interfaces, las
limitaciones y compensaciones con la empresa.
El arquitecto de negocio identifica y documenta los aspectos de gran
importancia del negocio del sistema, que entra en el ámbito del ejercicio
de modelos de negocio.
La justificación de las principales decisiones de diseño de negocios tiene
que ser el resultado de encontrar el justo equilibrio entre los factores de la
84
competencia, incluyendo las preocupaciones de los grupos de interés
diversos, riesgos, limitaciones. Las decisiones deben ser acordados,
validados y comunicados a todas las partes interesadas.
5.3 TAREAS DE IBM RUP SOMA Se especifican las tareas RUP SOMA para los siguientes disciplinas:
• Modelamiento de negocios
• Análisis y diseño
• Implementación
5.3.1 TAREAS DE MODELAMIENTO DE NEGOCIOS
5.3.1.1 IDENTIFICACIÓN DE METAS DE NEGOCIOS Y KPIs. Esta tarea describe un enfoque combinado (top-down y bottom-up) para la
identificación de los objetivos de negocio y los indicadores clave de
rendimiento asociados.
Propósito
• Identificar los objetivos con los que la empresa puede planificar y
gestionar el uso de indicadores clave de rendimiento
• Asegurar el alineamiento entre los objetivos estratégicos a largo
plazo y las metas operacionales a corto plazo
• Traducir la estrategia de negocio en acción
• Proporcionar una base para medir y mejorar las actividades de la
empresa
Tabla 5.1 Entrada y salidas de identificación de metas Rol: Analista de Proceso de Negocio
Entrada: Visión del negocio
Salida: Meta de Negocio
Fuente: SOMA de RUP IBM
85
5.3.1.2 ANÁLISIS DEL ÁREA FUNCIONAL Esta tarea tiene ideas iniciales acerca del particionado del negocio (por
ejemplo, desde un enfoque de modelo de componentes de negocio) y los
refina basado en la identificación de los conjuntos de funciones de
negocio coherentes para el dominio de negocios, en áreas funcionales -
agregados de funcionalidad que se asignan a los sistemas de negocio.
Figura 5.1 Descomposición de negocio
Fuente: tomado de IBM, http://www.ibm.com/developerworks/library/ws-
designsoapart1/
Propósito
El propósito del análisis de área funcional es validar las ideas iniciales
acerca de la división de la empresa, en primer lugar dominios de negocio
(que lógicamente se agrupará en un conjunto de sistemas de negocios
que son de interés para el modelado de negocio), cabe señalar que esto
puede requerir una paso intermedio para identificar subdominios y así
limitar la parte de la empresa a estudiar para luego descubrir áreas
funcionales. Se puede decir que se trata de un enfoque complementario al
análisis arquitectónico de negocios y se puede utilizar en conjunto con
esa tarea.
86
Tabla 5.2 Entrada y salida de análisis del área funcional Rol: Arquitecto de negocio
Entrada: Dominio de negocio
Salidas: • Modelo de análisis de negocio
• Documento de arquitectura de negocio
Fuente: SOMA de RUP IBM
5.3.1.3 AFINAMIENTO DE CASOS DE USO DE NEGOCIO Esta tarea se realiza cuando el negocio requiere una definición de alto
nivel y deben ser afinado antes de su implementación.
Propósito
El propósito de esta tarea es tomar un caso de uso del negocio que se
define como de alto nivel para poder evidenciar la intención y el propósito
del negocio. Se debe tomar en cuenta que si no se afina este caso de
uso resultaría ser demasiado abstracto para poder implementarlo
inmediatamente, por lo que se debería afinarlo dentro de un conjunto de
casos de uso que representarían un proceso de negocio.
Tabla 5.3 Entrada y salida de casos de uso del negocio Rol: Analista de procesos de negocios
Entrada: • Actores de negocio
• Casos de uso del negocio
• Modelo de casos de uso de negocio
Salidas: • Actores de negocio
• Casos de uso del negocio
• Modelo de caso de uso de negocio
• Especificaciones suplementarias de
negocio
Fuente: SOMA de RUP IBM
87
5.3.2 TAREAS DE ANÁLISIS Y DISEÑO
5.3.2.1 IDENTIFICAR FACTORES COMUNES Y VARIABILIDAD Esta tarea se aplica a una serie de análisis y diseño de elementos donde
se verifican la variabilidad de estos elementos y saca los factores
comunes, esto hace que sea un resultado más robusto y flexible.
Propósito
Analizar los elementos de los modelo e identifica cuál de estos elementos
son comunes en diferentes aplicaciones y separarlos de aquellos
elementos que varían en diferentes aplicaciones, debe realizar una
documentación específica de este análisis.
Tabla 5.4 Entrada y salida de identificar factores comunes Rol: Diseñador
Entrada: • Ninguno
Salidas: • Modelo de análisis
• Modelo de diseño
• Modelo de servicio
Fuente: SOMA de RUP IBM
5.3.2.2 IDENTIFICAR PATRONES DE SEGURIDAD Durante la arquitectura inicial de un sistema, el arquitecto de seguridad
es responsable de la identificación y selección de patrones claves de
seguridad, así garantizando el nivel de seguridad requerido por el sistema.
Propósito
El objetivo de esta tarea es identificar los patrones de seguridad de alto
nivel, de esta manera unir los elementos arquitectónicos que responden a
exigencias y políticas de seguridad. Estos patrones son detallados a una
tecnología en particular y a una plataforma de diseño.
88
Tabla 5.5 Entrada y salida de identificar patrones de seguridad Rol: Arquitecto de seguridad
Entrada: • Documento de arquitectura de software
Salidas: • Documento de arquitectura de software
Fuente: SOMA de RUP IBM
5.3.2.3 ESPECIFICACIÓN DE COMPONENTES (SOA) Esta tarea especifica los detalles de los componentes de los servicios que
se dan cuenta de un Subsistema de Diseño.
Propósito
Elaborar uno o más artefactos de diseño de subsistemas los cuales están
descritos durante la tarea de diseño de subsistemas (SOA) y proveer
detalles de diseño de artefactos de componentes de servicio.
Tabla 5.6 Entrada y salida de especificación de componentes SOA Rol: Diseñador
Entrada: • Diseños de subsistemas
• Compontes de servicio
Salidas: • Componentes de servicio
Fuente: SOMA de RUP IBM
5.3.2.4 CONSTRUIR PRUEBA DE CONCEPTO ARQUITECTÓNICO (SOA)
Esta tarea define la forma de desarrollar una prueba de concepto de
arquitectura, de una solución SOA, basada en requisitos arquitectónicos
existentes y perfil de riesgo.
Propósito
Sintetizar una solución ejemplar que cumpla con los requisitos
arquitectónicos críticos, este ejemplar puede estar limitado de alguna
manera, como por ejemplo:
• La solución resultante puede ser simplemente conceptual
89
• La solución resultante sólo puede ilustrar algún aspecto crítico de los
requisitos generales
Tabla 5.7 Entrada y salida Prueba de concepto arquitectónico SOA Rol: Arquitecto de software
Entrada: • Modelo de despliegue
• Modelo de diseño
• Modelo de servicio
• Documento de Arquitectura de Software
Salidas: • Prueba de Concepto Arquitectónico
Fuente: SOMA de RUP IBM
5.3.2.5 IDENTIFICA SERVICIOS ASOCIADOS A OBJETIVOS Identifica servicios, mediante el análisis de los objetivos de la empresa o
de una unidad de negocio.
Propósito
Esta técnica comienza con declaraciones generalizadas de los objetivos
de negocio, con la posterior descomposición en sub objetivos para
cumplir con la meta del nivel superior. Esto a la larga conduce a un nivel
de descomposición que apoya a la identificación de los servicios
asociados a las sub metas. Durante este proceso, los KPIs se identifican y
se recoge junto con los indicadores que se utilizarán para medir,
monitorear y verificar el grado de éxito en la consecución de los objetivos
en realidad.
Tabla 5.8 Entrada y salida de identificar servicios asociados a objetivos
Rol: Diseñador
Entrada: • Meta de negocio
• Modelo de servicio
Salidas: • Modelo meta de servicio
Fuente: SOMA de RUP IBM
90
5.3.2.6 ANÁLISIS DE PROCESOS EMPRESARIALES Esta tarea identifica los elementos de diseño de una solución orientada a
servicios y documenta la especificación inicial de esos servicios.
Propósito
• Identificar los elementos de diseño de una solución orientada a
servicios
• Documentar la especificación inicial de los servicios
• Determinar las dependencias iniciales y la comunicación entre los
servicios.
Tabla 5.9 Entrada y salida de análisis de procesos empresariales Rol: Arquitecto de software
Entrada: • Modelo de análisis de negocio
• Modelo de Casos de Uso del Negocio
Salidas: • Modelo de servicio
Fuente: SOMA de RUP IBM
5.3.2.7 ANÁLISIS DE MODELO DE DATOS Esta tarea utiliza modelos de procesos de negocio como entrada e
identifica un conjunto de candidatos de servicios que se incluyen en la
cartera de servicios del proyecto. Estos candidatos de servicios todavía
pueden requerir refinamiento adicional, se puede tener como resultado
un conjunto inicial de especificaciones para el servicio
Tabla 5.10 Entrada y salida de análisis de modelos de datos Rol: Arquitecto de software
Entrada: • Modelo de servicio
• Modelo de Caso de Uso del Negocio
Salidas: • Modelo de servicio
Fuente: SOMA de RUP IBM
91
5.3.2.8 ANÁLISIS DE ACTIVOS EXISTENTES El análisis de activos existentes es el proceso de aprovechamiento de los
activos existentes (por ejemplo, sistemas existentes como aplicaciones
empaquetadas o personalizadas), así como de los estándares del sector,
los modelos y los activos para conseguir la ejecución de los servicios. Con
un enfoque de arriba a abajo, el análisis de activos existentes identifica y
valida servicios candidatos, componentes y flujos. Las limitaciones
técnicas relacionadas con los sistemas existentes deberían evaluarse tan
pronto como sea posible, con el fin de gestionar los riesgos. Esto conduce
a que la viabilidad técnica de las decisiones de realización de servicio se
ejecute a menudo tan pronto como sea posible después o durante el
análisis de activos existentes.
Propósito
• Identifica candidatos de servicio a partir de aplicaciones
personalizadas
• Identifica candidatos de servicio a partir de aplicaciones
empaquetadas
• Garantiza la documentación de los requisitos no funcionales
Tabla 5. 11 Entrada y salida análisis de activos existentes Rol: Arquitecto de software
Entrada: • Modelo de servicio
Salidas: • Modelo de servicio
Fuente: SOMA de RUP IBM
5.3.2.9 ANÁLISIS DE REGLAS DEL NEGOCIO Determinadas clases de soluciones tienden a depender enormemente del
uso de reglas de negocio para extraer la variabilidad de la solución y
poder externalizar estas reglas fuera de la lógica de aplicación. A partir de
un modelo de análisis empresarial que incluya entidades empresariales y
reglas empresariales, es posible definir servicios que encapsulen las
reglas empresariales, externalizándolas del resto de la lógica de la
92
solución. Las reglas también pueden adjuntarse a acciones o procesos y
a menudo se evalúan como condiciones previas o posteriores para la
acción.
Tabla 5.12 Entrada y salida de análisis de reglas de negocio Rol: Arquitecto de software
Entrada: • Modelo de servicio
Salidas: • Modelo de servicio
Fuente: SOMA de RUP IBM
5.3.2.10 ANÁLISIS DE CASOS DE USO DE NEGOCIO (SOA) Esta tarea utiliza el artefacto de realización de casos de uso del
negocio como entrada, e identifica un conjunto de candidatos de servicios
que se incluyen en la cartera de servicios del proyecto. Estos servicios
candidatos pueden necesitar todavía más ajustes; sin embargo, los pasos
aquí incluidos proporcionan una forma efectiva de producir un conjunto
inicial de artefactos de Especificación de servicio
Propósito
• Identifica candidatos de servicio a partir de casos de uso del negocio
• Ajusta especificaciones de servicios candidatos
Tabla 5.13 Entrada y salida de análisis de casos de uso de negocio (SOA)
Rol: Arquitecto de software
Entrada: • Modelo de análisis de negocio
Salidas: • Modelo de servicio
Fuente: SOMA de RUP IBM
5.3.2.11 DISEÑO DE MENSAJE Esta tarea describe las acciones necesarias para el desarrollo de un
modelo de diseño completo de mensajes (catálogo). Se analizan los
93
patrones de intercambio de mensajes y la relación del modelo de dominio
con el modelo de mensaje.
Propósito
La comunicación entre los mensajes de servicios y componentes, es una
parte crítica de SOA. Estos no incluyen solamente los mensajes de
entrada y salida de una invocación de un servicio dado, sino también el
formato de mensaje interno para ser utilizado dentro de la empresa como
el flujo de información pasa a través de las capas de la arquitectura de la
aplicación. En muchos casos, se recomienda un formato de mensaje
común.
La especificación de mensajes para el modelo de servicio debe tener en
cuenta los puntos de vista de la arquitectura empresarial / arquitectura de
aplicaciones, arquitectura de datos y arquitectura de integración. Esto
incluye:
• Normas de mensajes definidos a nivel empresarial o aplicación
• Meta apropiada o modelo de datos que son parte de una arquitectura
de datos
• Las normas de transformación de mensajes que forman parte de una
arquitectura de integración
Tabla 5.14 Entrada y salida de diseño de mensaje Rol: Diseñador
Entrada: • Modelo de servicio
Salidas: • Modelo de servicio
Fuente: SOMA de RUP IBM
5.3.2.12 PRUEBAS SERVICIOS LITMUS Esta tarea se describe como un requisito que debe cumplir los candidatos
de servicios para asegurar que aquellos que están desarrollándose en
realidad cumplen con las necesidades de la empresa.
94
Propósito
Una vez que los candidatos de servicios han sido seleccionados y
documentados en el portafolio de servicios, entonces necesitamos
determinar cuáles deben ser expuestos como servicios. Aunque, en teoría,
cualquier candidato de servicio podría ser expuesto mediante la
exportación de su interfaz como una descripción del servicio. En particular,
la decisión de exponer "todos los métodos de todas las clases" crea
enormes problemas de rendimiento y gestión de servicios, por no
mencionar el hecho de que podemos estar regalando el capital intelectual
de la empresa. Por otra parte, hay que recordar que hay un costo
asociado con cada servicio que elegimos para exponer: la financiación, la
gobernanza y la infraestructura (seguridad, rendimiento, gestión) del
servicio y los componentes.
5.3.2.13 ESPECIFICACIÓN DE SERVICIO Esta tarea define y especifica los servicios y la estructura de una solución
orientada a los servicios, en términos de la colaboración de elementos de
diseño de contenidos y subsistemas / interfaces externas.
Propósito
• Definir los servicios y la estructura de una solución orientada a
servicios
• Analizar el servicio de interés común y la variabilidad
• Documentar la especificación de servicios
• Determinar las dependencias y la comunicación entre los servicios
Tabla 5.15 Entrada y salida de especificación de servicio Rol: Diseñador
Entrada: • SAD (Documento de Arquitectura de
Software)
• Especificaciones suplementarias
• Modelo de diseño
Salidas: • Especificación de servicio
Fuente: SOMA de RUP IBM
95
5.3.2.14 DISEÑO SUB SISTEMAS (SOA) Esta tarea se extiende al diseño del subsistema RUP tradicional con
detalles específicos para una solución SOA, especialmente donde se
identificaron los subsistemas de modelos de análisis de negocio. Una vez
que hacemos la transición del dominio de negocio para el dominio de TI,
identificamos áreas funcionales definidas.
Propósito
Enlazar los modelos de negocios con sus contrapartes de TI de la
siguiente manera:
• Identificar la relación entre las áreas funcionales en el modelo de
análisis de negocio que corresponde diseño de sub sistemas
• Definir los comportamientos especificados en las interfaces de
subsistemas en cuanto a las colaboraciones de los elementos de
diseño y subsistemas contenidos / interfaces externas
• Documentar la estructura interna del subsistema, en términos de
componentes de servicio
• Definir realizaciones entre las interfaces del subsistema y contenía
componentes y clases
• Determinar las dependencias sobre otros subsistemas
Tabla 5.16 Entrada y salida de diseño sub sistemas (SOA) Rol: Diseñador
Entrada: • Modelo de análisis de negocio
• Diseño de subsistemas
• Interface
Salidas: • Encapsulamiento
• Diseño de clases
• Modelo de diseño
• Diseño de subsistemas
• Interface
Fuente: SOMA de RUP IBM
96
5.3.3 TAREAS DE IMPLEMENTACIÓN
5.3.3.1 DOCUMENTO DE DECISIONES DE REALIZACIÓN DE SERVICIO
Esta tarea se centra en la realización de un modelo de servicio en
términos de componentes de software para funcionar en entornos de
middleware existentes.
Propósito
El propósito de esta tarea es proporcionar un modelo de diseño de la
aplicación que puede ser utilizada por los desarrolladores para
implementar componentes de servicio para proporcionar los servicios
requeridos
Tabla 5.17 Entrada y salida de documento de decisiones de realización de servicio
Rol: Diseñador
Entrada: • Referencia de arquitectura
• Modelo de servicio
• Documento de arquitectura de servicio
Salidas: • Modelo de diseño
Fuente: SOMA de RUP IBM
5.4 PROPUESTA DE METODOLOGÍA RUP ENFOCADO EN SOA PARA EL DEPARTAMENTO
DE PENSIONES DEL IESS. Hemos mostrado como se encuentra la actual metodología que posee el
departamento de pensiones del IESS y también hemos analizado la
propuesta de la metodología IBM RUP SOMA y existen algunos aspectos
que debemos contemplar.
97
5.4.1 RECURSOS HUMANOS El departamento de pensiones del IESS no posee personal para construir
sistemas de información enfocados al negocio, se debe incorporar los
siguientes recursos:
• Arquitectos de software SOA
• Arquitectos de negocios
• Analista de procesos de negocios
• Implementadores SOA
• Programadores SOA
Con respecto a los arquitectos de negocio del IESS poseen la experiencia
necesaria en el negocio de pensiones, pero no poseen la habilidad del
modelado del negocio sobre herramientas SOA y no tienen conocimiento
sobre metodologías de desarrollo con SOA, pero por otra parte no existe
personal técnico en el departamento de pensiones del IESS.
5.4.2 RECURSOS TECNOLÓGICOS El departamento de pensiones del IESS no posee las herramientas
necesarias para realizar un desarrollo de software con SOA, sugerimos
instalar las siguientes herramientas de IBM que se acoplan directamente
con la metodología actual:
• Rational Rose
• Rational RequisitePro
5.4.3 ADAPTACIONES DE LA METODOLOGÍA RUP CON IBM RUP SOMA
En la metodología RUP para el departamento de pensiones del IESS se
orientará exclusivamente a procesos de negocios.
5.4.3.1 FASE DE FACTIBILIDAD Esta fase es la inicial y trata de buscar la factibilidad del proyecto, se
incrementaron tareas para cumplir con los objetivos de soluciones SOA.
98
Tabla 5.18 Fase de factibilidad IBM RUP SOMA adaptado a RUP
Disciplina
No.
Tarea
Rol
Artefacto
Modelado
del
negocio
1
Visión de
negocios
Analista de
proceso de
negocio
Documento de
visión de negocio
2
Construcció
n de
glosario de
términos
comunes
de negocio
Analista de
proceso de
negocio
Documento de
glosario de términos
comunes de
negocio
3
Especificaci
ones
suplementa
rias
Analista de
proceso de
negocio
Documento de
especificaciones
suplementarias
4
Levantamie
nto y
optimizació
n de
procesos
de
negocios
Analista de
proceso de
negocio
• Modelo de
procesos de
negocio “As In“
• Modelo de
procesos de
negocio “To Be“
• Documento de
especificaciones
de modelos de
negocio
5
Casos de
Uso del
Negocio
Analista de
proceso de
negocio
• Modelo de casos
de uso del
negocio
• Especificación
de casos de uso
del negocio
Continúa …
99
Continuación de la Tabla 5.18
6
Identificació
n de metas
de negocio
y KPIs
Analista de
proceso de
negocio
Registro de
actividades en
herramientas
Rational y
RequisitePro
7
Mantener
reglas de
negocio
Analista de
proceso de
negocio
Registro de
actividades en
herramientas
Rational y
RequisitePro
Análisis
de
requisitos
8 Glosario de
términos
Analista de
Sistemas
• Documentos de
glosario de
términos
9 Buscar
actores y
guiones de
uso
Analista de
Sistemas
• Actores
• Atributos de
requisitos
• Casos de uso y
Modelo de casos
de uso
10 Visión del
Sistema
Analista de
Sistemas • Documento de
visión del
sistema
11 Especificaci
ones
suplementa
rias
Analista de
Sistemas
• Documento de
especificaciones
suplementarias
Análisis y
diseño
12 Elaboración
de SAD
Arquitecto de
Software
• Documento de
arquitectura de
solución
Fuente: SOMA de RUP IBM
100
En esta fase de factibilidad se espera lo siguiente:
• Crear la documentación del proyecto el mismo que servirá para mirar
la factibilidad tras la finalización de esta etapa
• Se trata de especificar todo el negocio posible a través de diagrama de
casos de uso del negocio, especificación de casos de uso de negocio,
diagramas de modelo de procesos de negocios y especificaciones de
los modelos.
• Se tiene que realizar diagramas de casos de uso del sistema y sus
especificaciones de casos de uso el cual pretende especificar los
requerimientos del sistema pedidos por el negocio
5.4.3.2 FASE DE ELABORACIÓN Esta fase de elaboración es un preámbulo para la fase de construcción es
decir la construcción del sistema.
Tabla 5.19 Fase de elaboración IBM RUP SOMA adaptado a RUP Disciplina
No.
Tarea
Rol
Artefacto
Diseño 1 Desarrollar
un guión de
desarrollo
Desarrollad
ores SOA
• Documento de
guión de
desarrollo
Diseño 2 Preparar
directrices
para el
proyecto
Desarrollad
ores SOA
• Documentación
de directrices
específicas de
proyectos
Diseño 3 Desarrollar la
guía de estilo
del manual
Desarrollad
ores SOA • Guía de estilo de
manuales
Diseño 4 Preparar
plantillas para
el proyecto
Desarrollad
ores SOA • Plantillas
específicas del
proyecto
Continúa …
101
Continuación de la Tabla 5.19
Diseño 5 Inicio proceso
de desarrollo
Desarrollad
ores SOA
Diseño 6 Configurar
herramientas
de desarrollo
Desarrollad
ores SOA
Diseño 7 Verificar la
instalación y
configuración
de
herramientas
Pruebas
Diseño 8 Definir el
contexto del
sistema
Analista de
sistemas
• Modelo de
análisis
• Afinación de
modelo de casos
de uso
• Documento de
operación
Diseño 9 Análisis de la
arquitectura
Arquitecto
SOA
• Afinación de
documento de
arquitectura de
software
• Afinación de
modelo de
análisis
• Modelo de
despliegue
• Modelo de
despliegue
Continúa …
102
Continuación de la Tabla 5.19
Diseño 10 Análisis de
operación
Arquitecto
SOA • Modelo de
análisis
• Modelo de casos
de uso
• Documento de
operación
• Realización de
una operación
Diseño 11 Identificar
patrones de
seguridad
Arquitecto
SOA • Documento de
arquitectura de
software
Diseño 12 Identificar
mecanismos
de diseño
Arquitecto
SOA
• Documento de
arquitectura de
software
• Modelo de diseño
• Modelo de
servicio
Diseño 13 Identificar
elementos de
diseño
Arquitecto
SOA • Modelo de diseño
• Modelo de
servicio
Diseño 14 Análisis de
operación
Arquitecto
SOA • Modelo de
análisis
• Modelo de casos
de uso
• Documento de
operación
• Realización de
una operación
Continuación …
103
Continuación de la Tabla 5.19
Diseño 15 Incorporar
elementos de
diseño
existentes
Arquitecto
SOA • Documento de
arquitectura de
software
• Modelo de diseño
• Modelo de
servicio
Diseño 16 Estructurar el
modelo de
implementaci
ón
Arquitecto
SOA • Documento de
arquitectura de
software
• Modelo de
implementación
Diseño 17 Describir la
arquitectura
de tiempo de
ejecución
Arquitecto
SOA • Especificaciones
suplementarias
• Modelo de diseño
Diseño 18 Describir la
distribución
Arquitecto
SOA • Documento de
arquitectura de
software
• Modelo de
despliegue
Diseño 19 Revisión de
arquitectura
Pruebas
Diseño 20 Desarrollo de
componentes
Arquitecto
SOA
Pruebas 21 Integración y
pruebas
Pruebas
Fuente: SOMA de RUP IBM
104
5.4.3.3 FASE DE CONSTRUCCIÓN En esta fase de construcción se desarrollaran los sistemas enfocados en
SOA.
Tabla 5.20 Fase de elaboración IBM RUP SOMA adaptado a RUP Disciplina
No.
Tarea
Rol
Artefacto
Implementa
ción
1 Desarrollar un
guión o
conjunto de
instrucciones
(script) para
los
desarrolladore
s
Desarrollador
SOA • Guión o
conjunto de
instrucciones
(script) para
los
desarrolladore
s
Implementa
ción
2 Preparar
directrices
para el
proyecto
Desarrollador
SOA • Directrices
especificas
del proyecto
Implementa
ción
3 Desarrollar la
guía de estilo
del manual
Desarrollador
SOA • Guía de estilo
de manuales
Implementa
ción
4 Preparar
plantillas para
el proyecto
Desarrollador
SOA • Plantillas
especificas
del proyecto
Implementa
ción
5 Configurar las
herramientas
Desarrollador
SOA
Implementa
ción
6 Verificar la
instalación y
configurar de
herramientas
Pruebas
Continúa ….
105
Continuación de la Tabla 5.20
Implementa
ción
7 Desarrollo de
componentes
Arquitecto
SOA
Implementa
ción
7.1 Analizar el
comportamient
o
Arquitecto
SOA
Implementa
ción
7.2 Identificación
de servicio
Arquitecto
SOA
Implementa
ción
7.3 Componente
de diseño
Arquitecto
SOA
Implementa
ción
7.3.1 Diseño de
casos de uso
Arquitecto
SOA
Implementa
ción
7.3.2 Diseño de
subsistema
Arquitecto
SOA
Implementa
ción
7.3.3 Diseño de la
operación
Arquitecto
SOA
Implementa
ción
7.3.4 Diseño de
clase
Arquitecto
SOA
Implementa
ción
7.3.5 Definir los
elementos de
comprobabilid
ad
Arquitecto
SOA
Implementa
ción
7.3.6 Diseñar los
elementos de
comprobabilid
ad
Arquitecto
SOA
Implementa
ción
7.3.7 Diseño de la
capsula
Arquitecto
SOA
Implementa
ción
7.3.8 Revisar el
diseño
Pruebas
Implementa
ción
7.4 Diseñar la
base de datos
Arquitecto de
Software
Continúa …
106
Continuación de la Tabla 5.20
Implementa
ción
7.4.1 Diseño de
clases
Arquitecto de
Software
Implementa
ción
7.4.2 Especificar la
migración de
datos
Arquitecto de
Software
Implementa
ción
7.4.3 Diseño de
base de datos
Arquitecto de
Software
Implementa
ción
7.4.4 Revisar el
diseño
Arquitecto de
Software
Implementa
ción
7.5 Especificación
de servicios
Arquitecto
SOA
Implementa
ción
7.5.1 Realizar
especificacion
es de servicio
Arquitecto
SOA
Implementa
ción
7.5.2 Realizar
análisis de
subsistemas
Arquitecto
SOA
Implementa
ción
7.5.3 Especificación
de
componentes
Arquitecto
SOA
Implementa
ción
7.6 Realización de
servicios
Arquitecto
SOA
Implementa
ción
7.7 Implementar
componentes
Arquitecto
SOA
Prueba 8 Integrar y
Probar
Pruebas
Prueba 8.1 Verificar el
enfoque de
prueba
Pruebas
Prueba 8.2 Prueba y
evaluación
Pruebas
Fuente: SOMA de RUP IBM
107
5.4.3.4 FASE DE IMPLEMENTACIÓN En esta fase el objetivo principal es garantizar que el software estará listo
para que el cliente lo pueda usar según las necesidades del mismo.
Tabla 5.21 Fase de implementación IBM RUP SOMA adaptado a RUP Disciplina
No.
Tarea
Rol
Artefacto
Gestión de
Cambios y
Configuraci
ón
1 Gestión y
soporte
continuos
Implementador
Gestión de
Cambios y
Configuraci
ón
1.1 Supervisar la
iteración
Implementador
Gestión de
Cambios y
Configuraci
ón
1.2 Supervisar y
controlar el
proyecto
Implementador
Gestión de
Cambios y
Configuraci
ón
1.3 Gestionar
cambios de
requisitos
Implementador
Gestión de
Cambios y
Configuraci
ón
1.4 Gestionar
solicitudes de
cambios
Implementador
Gestión de
Cambios y
Configuraci
ón
1.5 Soporte en la
iteración
Implementador
Continúa ….
108
Continuación de la Tabla 5.21
Gestión de
Cambios y
Configuraci
ón
1.6 Cambiar y
entregar
elementos de
configuración
Implementador
Gestión de
Cambios y
Configuraci
ón
1.7 Gestionar
líneas bases y
releases
Implementador
Gestión de
Cambios y
Configuraci
ón
1.8 Supervisar y
notificar el
estado de la
configuración
Implementador
Gestión de
proyectos
2 Planificación
de despliegue
Líder de
proyecto
Gestión de
proyectos
2.1 Desarrollar el
plan de
despliegue
Líder de
proyectos
Gestión de
proyectos
2.2 Definir la lista
de materiales
Líder de
proyectos
Gestión de
Cambios y
Configuraci
ón
3 Arreglar los
defectos de los
componentes
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
3.1 Planificar la
integración del
subsistema
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
3.2 Implementar
elementos de
diseño
Desarrollador
SOA
Continúa ….
109
Continuación de la Tabla 5.21
Gestión de
Cambios y
Configuraci
ón
3.3 Analizar el
comportamient
o en tiempo de
ejecución
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
3.4 Implementar
los elementos
de
comprobabilid
ad
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
3.5 Implementar la
prueba de
desarrollador
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
3.6 Ejecutar
pruebas del
desarrollador
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
3.7 Revisar el
código
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4 Desarrollar los
componentes
restantes
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4.1 Analizar el
comportamient
o
Desarrollador
SOA
Continúa
110
Continuación de la Tabla 5.21
Gestión de
Cambios y
Configuraci
ón
4.2 Identificación
de servicio
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4.3 Componentes
de diseño
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4.4 Diseñar la
base de datos
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4.5 Especificación
de servicios
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4.6 Realización de
servicios
Desarrollador
SOA
Gestión de
Cambios y
Configuraci
ón
4.7 Implementar
componentes
Desarrollador
SOA
Pruebas 5 Integración y
pruebas
Pruebas
Pruebas 5.1 Verificar el
enfoque de
pruebas
Pruebas
Pruebas 5.2 Validar la
compilación
Pruebas
Continúa …
111
Continuación de la Tabla 5.21
Pruebas 5.3 Pruebas y
evaluación
Pruebas
Despliegue 6 Desarrollar el
material de
soporte
restante
Implementador
Despliegue 6.1 Desarrollar
material de
soporte
Implementador
Despliegue 6.2 Probar y
evaluar
Implementador
Despliegue 7 Gestionar la
prueba de
aceptación
Implementador
Despliegue 7.1 Gestionar la
prueba de
aceptación
Implementador
Despliegue 7.2 Dar soporte al
desarrollo
Implementador Infraestructura
de desarrollo
Despliegue 7.3 Ejecutar el
conjunto de
aplicaciones
de prueba
Implementador Registro de
prueba
Despliegue 8 Gestionar la
prueba de
versión beta
Implementador Solicitud de
cambio
Despliegue 9 Crear el
producto para
el release
Implementador
Continúa
112
Continuación de la Tabla 5.21
Despliegue 9.1 Producir la
unidad de
despliegue
Implementador
Despliegue 9.2 Empaquetar el
producto
Implementador
Despliegue 9.3 Proporcionar
acceso a un
sitio de
descarga
Implementador
Fuente: SOMA de RUP IBM
5.4.4 PLANIFICACIÓN DE PROYECTOS Hemos detallado las fases, actividades y artefactos que se deben realizar
durante un proyecto de software escalable del departamento de
pensiones del IESS, ahora vamos a detallar cómo se debería planificar
con estas variaciones.
Vamos asumir que para la realización de software escalables, en el
departamento de pensiones del IESS existe el personal técnico y expertos
en el negocios lo suficientemente capacitados para realizar cualquier
implementación, adaptación o mejora que se necesite según lo indicado
anteriormente.
Antes de la realización del proyecto debe existir una concepción del
proyecto el cual tiene que dirigir el líder de proyectos
5.4.4.1 TAREAS ANTES DE INICIAR EL PROYECTO Antes de que se inicie el proyecto es necesario completar una serie de
tareas previas que influirán decisivamente en la finalización exitosa de un
proyecto, se incluyen actividades tales como: determinación del ámbito
del proyecto, estudio de viabilidad, análisis de riesgos, estimación del
113
costo del proyecto, planificación temporal y la asignación de recursos a
las distintas etapas del proyecto.
Las tareas más criticas son las de las de fase de factibilidad y elaboración,
ya de que estas se establecen unas bases sólidas para el proyecto.
5.4.4.2 PLANIFICACIÓN FASE DE FACTIBILIDAD El líder de proyectos en esta etapa debería actuar de la siguiente manera
Figura 5.2 Diagrama de actividades de líder en fase inicial
Fuente: tomado de IBM http://www.ibm.com/developerworks/ssa/library/l-
greenit/
114
Los artefactos que deberían entregar serían los siguientes:
Tabla 5.22 Artefactos a entregar en planificación de fase de factibilidad
Tarea Artefacto
Generar lista de riesgos Lista de riesgos
Desarrollar caso de
negocio
Caso de negocio
Desarrollar plan de
software
Plan de software
Definir planes de
proyecto • Plan de medidas
• Plan de gestión de
riesgos
• Plan de aceptación
del producto
• Plan de resolución
de problemas
• Plan de garantía de
calidad
• Organización y el
personal del
proyecto
Planificar y asignar
trabajo • Solicitud de cambio
• Pedido de trabajo
• Plan de iteración
Supervisar el estado del
proyecto • Lista de problemas
• Lista de riesgos
Fuente: SOMA de RUP IBM
115
5.4.4.2.1 ESTIMACIÓN DE TIEMPOS
A continuación mostraremos cómo se podría estimar los tiempos para la
fase de gestión de proyectos, la métrica que se toma para la tarea de
supervisión y control es el 30% del tiempo de la planificación estimada.
A continuación mostramos algunas métricas para poder estimar tiempos,
se debe categorizar el proyecto como Bajo, Medio y Alto, con esto se
puede tener un tiempo más acertado, cabe recalcar que los tiempos
serían de carácter normal es decir ni tan optimista ni pesimista
Tabla 5.23 Métricas de estimación de tiempos Disciplina
Tarea
Artefacto
Estimación de tiempo
Modelado
del negocio
Visión de
negocios
Documento de
visión de
negocio
Si el proyecto es:
• Bajo, 8 horas
• Medio, 12 horas
• Alto, 16 horas
Construcción de
glosario de
términos
comunes de
negocio
Documento de
glosario de
términos
comunes de
negocio
Si el proyecto es:
• Bajo, 3 horas
• Medio, 6 horas
• Alto, 8 horas
Especificaciones
suplementarias
Documento de
especificacion
es
suplementaria
s
Si el proyecto es:
• Bajo, 3 horas
• Medio, 6 horas
Alto, 9 horas
Continúa
116
Continuación de la Tabla 5.23
Levantamiento y
optimización de
procesos de
negocios
• Modelo de
procesos
de negocio
“As In“
• Modelo de
procesos
de negocio
“To Be“
• Documento
de
especificaci
ones de
modelos de
negocio
En base a la
complejidad del
negocio, número de
procesos a modelar
por cada área
Se saca una lista de
todos los posibles
procesos a
optimizar por área y
se categoriza, por
bajo, medio y alto,
con esto se puede
ayudar con el
arquitecto de
negocio.
Tiempo por proceso
de cada categoría.
• Bajo, 2 días
• Medio, 4 días
• Alto, 5 días
Incluye ambos
modelos mas la
especificación del
modelo
Total del tiempo es
igual a la sumatoria
de los tiempos por
proceso de cada
categoría
Continúa
117
Continuación de la Tabla 5.23
Casos de Uso del
Negocio • Modelo de
casos de
uso del
negocio
• Especificac
ión de
casos de
uso del
negocio
Si el proyecto es:
• Bajo, 3 días
• Medio, 5 días
• Alto, 8 días
Identificación de
metas de negocio
y KPIs
Registro de
actividades en
herramientas
Rational y
RequisitePro
Si el proyecto es:
• Bajo, 1 días
• Medio, 2 días
• Alto, 4 días
Mantener reglas
de negocio
Registro de
actividades en
herramientas
Rational y
RequisitePro
Si el proyecto es:
• Bajo, 1 días
• Medio, 2 días
• Alto, 4 días
Análisis de
requisitos
Glosario de
términos
• Documento
s de
glosario de
términos
Si el proyecto es:
• Bajo, 1 días
• Medio, 2 días
• Alto, 4 días
Continúa ….
118
Continuación de la Tabla 5.23
Buscar actores y
guiones de uso • Actores
• Atributos
de
requisitos
• Casos de
uso
• Modelo de
casos de
uso
Si el proyecto es:
• Bajo, 2 días
• Medio, 4 días
• Alto, 8 días
Aquí lo principal es
detectar los casos
de uso y en cada
uno de estos
especificar los
requerimientos que
debería tener.
Visión del
Sistema • Documento
de visión
del sistema
Si el proyecto es:
• Bajo, 4 horas
• Medio, 8 horas
• Alto, 16 horas
Especificaciones
suplementarias • Documento
de
especificaci
ones
suplementa
rias
Si el proyecto es:
• Bajo, 4 horas
• Medio, 8 horas
• Alto, 16 horas
Análisis y
diseño
Elaboración del
documento de
arquitectura de
solución
• Documento
de
arquitectur
a de
solución
Si el proyecto es:
• Bajo, 12 horas
• Medio, 16 horas
• Alto, 20 horas
Realizado por: POZO W., octubre 2013
Al finalizar esta etapa se debe consultar con el negocio si efectivamente
se logró especificar todos los requerimientos pedidos, en caso que la
respuesta haya sido negativa se debería realizar una nueva iteración y
119
volver a planificar para afinar los artefactos necesarios, para los casos de
uso en una segunda iteración se debería realizar de la siguiente manera.
Tabla 5.24 Listado de casos de uso identificados y categorizarlo. Caso de Uso Factor de Categoría Porcentaje
completado
Tiempo
Caso de Uso Bajo / Medio / Alto 70% = Factor de
Categoría +
Estimado para
contemplar
Total
= Suma de todos
los tiempos
Realizado por: POZO W., octubre 2013
5.4.4.3 PLANIFICACIÓN FASE DE ELABORACIÓN En esta etapa entendemos que es factible el proyecto y se puede seguir
desarrollando el proyecto.
Las tareas que realiza el líder de proyectos son las siguientes:
Figura 5.3 Diagrama de actividades de líder en fase inicial
Fuente: tomado de IBM http://www.ibm.com/developerworks/ssa/library/l-
greenit/
120
Los artefactos que deberían entregar serían los siguientes:
Tabla 5.25 Artefactos de entrega de planificación en fase de elaboración
Tarea Artefacto
Planificar el proyecto • Plan de medidas
• Plan de gestión de proyectos
• Plan de aceptación de proyectos
• Plan de resolución de problemas
• Plan de garantía de calidad
• Organización y el personal del
proyecto
Planificar la
configuración del
proyecto y el control de
cambios
• Plan de gestión de la
configuración
• Proceso de control de cambios
Planificar la integración • Planificar la integración del
sistema
Planear el despliegue • Plan de despliegue
Fuente: SOMA de RUP IBM
5.4.4.3.1 ESTIMACIÓN DE TIEMPOS
En la fase de elaboración mostraremos como se podría estimar los
tiempos, para llevar acabo esto se categorizará dependiente el tipo de
proyecto como Bajo, Medio y Alto.
121
Tabla 5.26 Métrica de estimación de tiempos en fase de elaboración Disciplina
Tarea
Artefacto Estimación de tiempo
Diseño Desarrollar un
guión de desarrollo • Documento de
guión de
desarrollo
Si el proyecto es :
• Bajo, 2 días
• Medio, 3 días
• Alto, 4 días
Diseño Preparar
directrices para el
proyecto
• Documentación
de directrices
específicas de
proyectos
Si el proyecto es :
• Bajo, 1 días
• Medio, 2 días
• Alto, 3 días
Diseño Desarrollar la guía
de estilo del
manual
• Guía de estilo
de manuales
Estimación
indicada por el
área técnica
Diseño Preparar plantillas
para el proyecto • Plantillas
específicas del
proyecto
Diseño Inicio proceso de
desarrollo
Diseño Configurar
herramientas de
desarrollo
Diseño Verificar la
instalación y
configuración de
herramientas
Continúa …
122
Continuación de la Tabla 5.26
Diseño Definir el contexto del
sistema • Modelo de
análisis
• Afinación de
modelo de
casos de uso
• Documento de
operación
Diseño Análisis de la
arquitectura • Afinación de
documento de
arquitectura de
software
• Afinación de
modelo de
análisis
• Modelo de
despliegue
• Modelo de
despliegue
Diseño Análisis de operación • Modelo de
análisis
• Modelo de
casos de uso
• Documento de
operación
• Realización de
una operación
Diseño Identificar patrones de
seguridad
• Documento de
arquitectura de
software
Continúa …
123
Continuación de la Tabla 5.26
Diseño Identificar mecanismos
de diseño • Documento de
arquitectura de
software
• Modelo de
diseño
• Modelo de
servicio
•
Diseño Identificar elementos
de diseño • Modelo de
diseño
• Modelo de
servicio
Diseño Análisis de operación • Modelo de
análisis
• Modelo de
casos de uso
• Documento de
operación
• Realización de
una operación
Diseño Incorporar elementos
de diseño existentes • Documento de
arquitectura de
software
• Modelo de
diseño
• Modelo de
servicio
Continúa …
124
Continuación de la Tabla 5.26
Diseño Estructurar el modelo
de implementación • Documento de
arquitectura de
software
• Modelo de
implementación
•
Diseño Describir la
arquitectura de
tiempo de ejecución
• Especificaciones
suplementarias
• Modelo de
diseño
Diseño Describir la
distribución • Documento de
arquitectura de
software
• Modelo de
despliegue
Diseño Revisión de
arquitectura
Diseño Desarrollo de
componentes
Pruebas Integración y pruebas
Realizado por: POZO W., octubre 2013
125
6 CONCLUSIONES Y RECOMENDACIONES
6.1 INTRODUCCIÓN En el presente capitulo mostraremos las conclusiones y recomendaciones
del presente documento.
6.2 CONCLUSIONES • Se estableció una metodología de desarrollo de software escalables
para el departamento de pensiones, la cual servirá de una gran ayuda
a los gerentes de proyectos en la planificación de desarrollo de
software escalables.
• Se identifico que las fases de factibilidad y elaboración son las que
tienen inconvenientes al momento de realizar software escalables con
una metodología RUP clásica, debido que no se posee los suficientes
artefactos para realizar software escalables y esto repercute al
momento de realizar estos tipos de software.
• Se identifico las mejores metodologías de desarrollo de software
escalables que se tiene al momento, brindando una explicación
detallada y brindando las ventajas y desventajas correspondientes.
• Se realizo una comparación entre las metodologías de desarrollo
escalables, dando un ganador a la de IBM RUP SOMA por sus
características especificas y por su acoplamiento a la actual que posee
el departamento de pensiones del IESS.
• Mediante la incorporación de algunos artefactos característicos de la
metodología IBM RUP SOMA y una sugerencia de estimación de
tiempos sugerida, se mejora la planificación y control de software
escalables.
126
• El negocio de pensiones es muy cambiante debido a que su medio
ambiente esta en medio del gobierno central y de las leyes que rigen
debe de recordad el histórico de reglas de negocio y las que regirán en
un instante de tiempo, por esto es necesario el desarrollo de software
escalable para el departamento de pensiones
• Como hemos enunciado, la debilidad actual es la falta de conocimiento
sobre SOA tanto en metodologías de desarrollo de SOA y
herramientas, lo que suele suceder que el personal técnico del IESS
no construya el software pedido bajo las especificaciones del cliente y
esto ocasiona a que los proyectos queden inconclusos o si finalizan
se encuentran bastante desfasados, hemos mostrado todas las pautas
necesarias para desarrollar software con SOA.
6.3 RECOMENDACIONES • Al departamento de pensiones del IESS, le va a beneficiar la
adaptación de esta metodología de desarrollo de aplicaciones
escalables es decir SOA, para ser posible esto, se tendrá que
realizar lo siguiente:
o Incorporación de personal técnica en herramientas SOA
o Incorporación de personal experto en la parte de negocios y
esto implica a reducir la rotación de personal
o Evangelización de la adaptación a la nueva metodología
o Necesario incorporar herramientas de gestión como las que
ofrece IBM para automatizar la realización de los proyectos
• El software escalable debe ser adaptado al software antiguo, hasta
que en un momento se migre progresivamente a la arquitectura
SOA.
• Se debe tomar en cuenta al momento de realizar casos de uso del
sistema, las reglas del negocio ya que de esta manera queda por
127
fuera las reglas del negocio del flujo del sistema, y esto resulta ser
uno de los principales inconvenientes que tiene el departamento de
pensiones en la actualidad.
• La realización del modelo de dominio del negocio es clave ya que
con esto se podrá capturar y expresar el entendimiento ganado en
el negocio y servirá como paso previo al diseño de un sistema.
• Las primera vez que se quiera implementar software escalables es
muy recomendable que se contrate consultores externos, de esta
se podrá evitar una alta curva de aprendizaje en el desenvolviendo
de las herramientas SOA.
• El personal de seguridad del IESS deberá capacitarse en la
infraestructura de las herramientas SOA, debido a que la gran
cantidad de información que maneja el departamento del IESS es
muy critica y de alto impacto a los proceso.
• Se deben de tener personal especialista en el negocio de
pensiones, debido a que la dimensión del negocio de pensiones es
cada vez más grande
• Lo que se debe realizar primero es la contratación del personal
adecuado para estos roles:
o Analista de Sistemas SOA
o Desarrolladores de Sistemas SOA
o Arquitectos de proyectos SOA
El personal debería tener el suficiente conocimiento y experiencia
en desarrollo de software SOA
128
BIBLIOGRAFÍA 1. Juan Pablo Gómez Gallego (2007). Fundamentos de la metodología
RUP. Colombia, 9p.
2. Kurose J. (2004). REDES DE COMPUTADORES Un enfoque
descendente basado en Internet. España, 192p.
3. Grossman, B. and J. Naumann (2004). ACORD & XBRL US-XML
Standards and the Insurance. Estados Unidos, 40p.
4. Deblaere M. et al (2002). IBM Insurance Application Architecture (IAA).
Estados Unidos. 49p.
5. Jaramillo Ruiz y Pedro Alonso (2012). Diseño de un modelo de
interoperabilidad tecnológica basado en la arquitectura SOA para las
municipalidades de lima metropolitana orientado a maximizar la
satisfacción del ciudadano. Perú, 60p.
6. M. P. Papazoglou (2006). Service-Oriented Design and Development
Methodology. Estados Unidos, 2010p.
7. T. Erl (2012). Service-Oriented Architecture: Conceptos, Technology
and Design. Prentice Hall PTR. Estados Unidos 189p.
8. T. ERL (2008). SOA Principles of Services Design. Prentice Hall PTR.
Estados Unidos, 145p.
9. Michael Richardson (2012). Introduction to RUP, IBM Corp. Estados
Unidos, 239p
10. A. Erradi, S. Anand, and N. Kulkarni. SOAF: an architectural
framework for services definition and realization. In: IEEE International
Conference on Services Computing. Estados Unidos 150p.
129
11. Wikipedia, IBM Rational Unified Process. 2012 [Fecha de consulta: 16
de Noviembre 2012]. Disponible en:
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
12. Wikipedia, LDAP. 2014 [Fecha de consulta: 5 de Noviembre del 2014 ].
Disponible en:
http://es.wikipedia.org/wiki/LDAP
13. Wikipedia, Lenguaje Unificado de Modelado. 2012 [Fecha de
consulta: 16 de Noviembre 2012]. Disponible en:
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
14. Wikipedia, Arquitectura orientada a servicios. 2012 [Fecha de
consulta: 16 de Noviembre 2012]. Disponible en:
http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
15. Wikipedia, Gestión o administración por procesos de negocio. 2012
[Fecha de consulta: 16 de Noviembre 2012]. Disponible en:
http://es.wikipedia.org/wiki/Gestion_de_procesos_de_negocio
16. Metodología Rational Unified Process (RUP). 2012 [Fecha de
consulta: 19 de Noviembre 2012]. Disponible en:
http://www.usmp.edu.ec/publicaciones/boletin/fia/info49/articulos/RUP
%20vs%20XP.pdf
17. Conceptos de RUP.2012 [Fecha de consulta: 19 de Noviembre 2012].
Disponible en: http://es.scribd.com/doc/7844685/CONCEPTOS-DE-
RUP
18. Información general sobre escalabilidad. 2012 [Fecha de consulta: 21
de Noviembre 2012]. Disponible en:
http://es.scribd.com/9644975/Como-Hacer-Que-Un-Sistema-Sea-
Escalable-JM
130
19. Aplicación Distribuida. 2012 [Fecha de consulta: 21 de Noviembre
2012]. Disponible en:
http://es.wikipedia.org/wiki/aplicaci%C3%B3n_distribuida
20. Arquitectura orientada a servicios en el contexto de la arquitectura
empresarial. 2010 [Fecha de consulta: 28 de Noviembre 2012].
Disponible en:
http://www2.unalmed.edu.co/~pruebasminas/index.php?option=com_d
ocman&task=doc_vie&gid=1635&tmpl=component&format=raw&Itemid
=285
21. Aplicación orientada a servicios. 2012 [Fecha de consulta: 28 de
Noviembre 2012]. Disponible en:
http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios
22. Componentes de SOA. 2012 [Fecha de consulta: 28 de Noviembre
2012]. Disponible en: http://soaction.sisorg.com.mx/componentes.html
23. Arquitectura SOA orientada a servicios. 2012 [Fecha de consulta: 26
de Junio del 2013]. Disponible en:
http://oposicionestic.blogspot.com/2012/08/arquitectura-soa-orientada-
servicios.html
24. Adopción de mejores prácticas y lecciones aprendidas de SOA [ Fecha
de consulta: 28 de Mayo del 2014] . Disponible en:
http://www.ibm.com/developerworks/ssa/library/ws-SOAbestpractices/
25. SOA Approaches - Top down vs Bottom up [ Fecha de consulta: 12 de
Agosto del 2014] . Disponible en:
http://completesoa.blogspot.com/2009/05/soa-approaches-top-down-
vs-bottom-up.html
131
BIOGRAFÍA
Mi nombre es William Fernando Pozo, nací el 7 de Mayo del 1980 en la
ciudad de Quito, hijo de Teresa Almeida y Luis Edmundo Pozo quienes
toda mi vida he respetado y admirado, tengo 3 hermanos, siendo el último
hijo.
Me gradué de bachiller de Físico - Matemático de la “Unidad Educativa
Cardenal Spellman” en Quito – Ecuador, la educación es salesiana por lo
que agradezco a mis padres esta educación ya que gracias a esto he
adquirido los mejores valores para mi vida profesional y personal.
Siempre he tenido una pasión por los juegos de video y las matemáticas,
cuando tenía que decidir en mi carrera profesional me decidí en seguir
ingeniería informática en la “Universidad Central del Ecuador” ya que
poseía el mix entre informática y matemática, durante mis estudios tome a
la programación como los juegos que sabía jugar durante mi niñez y de
ahí nació mi inclinación por el desarrollo de software, me gradué a los 24
años para después iniciarme en mis primeros retos profesionales ya como
programador de sistemas.
A lo largo de mi vida profesional he aprendido los retos y experiencias que
involucra el desarrollo de sistemas, me he especializado en software libre
como software privativo, manejo herramientas como java, .net, algunas
bases de datos, he realizado proyectos para el sector financiero, privado y
publico, gracias el trabajo constante logre ser líder de proyectos en una
empresa multinacional y manejando software de alto impacto, también he
tenido la oportunidad de ser consultor independiente en otros países
como Panamá, Estados Unidos, Japón y Puerto Rico, con ayuda de las
empresas que aporte con mi trabajo, viví casi 1 año en otro país como
Panamá y dejando muy en alto al Ecuador, demostrando que somos
gente de trabajo y con excelentes resultados.
