Proyecto de Ingenieria de Sistemas I

Plan de Tesis
Proyecto de Ingeniera de Sistemas I

Facultad de Ingeniera Industrial y de Sistemas
Plan de tesis
Tema:
Diseo de un sistema orientado a servicios para una
Administradora de Fondos de Pensiones.
Curso
Proyectos de Ingeniera de Sistemas I
Alumno
Pisco Sedano Jorge Luis
Asesor
MBA Ing. Carlos Zorrilla Vargas
Semestre
2012 II
Plan de Tesis
Dedicatoria:
A
todos
los
profesionales
investigadores e innovadores, que buscan aplicar
nuevos conceptos; que deseen plantear una
estrategia de organizacin de los elementos de TI y
resolver necesidades de negocio.
Plan de Tesis
AGRADECIMIENTO:
A mis padres, por apoyarme de
manera incondicional; por haberme formado con
valores que harn de mi un buen profesional y una
persona de bien.
Plan de Tesis
ndice
Plan De Tesis........................................................................................................................................6
Resumen Ejecutivo..............................................................................................................................6
Captulo I: Formulacin del Problema................................................................................................7
1.1. Planteamiento del Problema........................................................................................................7
1.2. Antecedentes de Solucin............................................................................................................8
1.3. Propuesta de Solucin..................................................................................................................8
1.4. Alcance de la Propuesta...............................................................................................................8
1.5. Justificacin ..............................................................................................................9
1.6. Objetivos ..............................................................................................................10
1.3.1. Objetivo General.....................................................................................................................10
1.3.2. Objetivos Especficos...............................................................................................................10
Captulo II: Marco Terico ............................................................................................11
2.1. Base Teorica...............................................................................................................11
2.1.1. Sistemas de Informacin.........................................................................................................11
2.2. UML...........................................................................................................12
2.2.1. Diagrama de Casos de Uso......................................................................................................13
2.2.2. Actor.......................................................................................................13
2.2.3. Diagrama de Clases.........................................................................................................14
2.2.4. Diagrama de Secuencia.........................................................................................................15
2.2.5. Diagrama de Colaboracin......................................................................................................16
2.2.6. Diagrama de Estado.................................................................................................................17
2.2.7. Diagrama de Actividades.........................................................................................................18
2.2.8. Diagrama de Componentes.....................................................................................................19
2.2.9. Diagrama de Despliegue.......................................................................................................20
Plan de Tesis
2.3. Base de Datos.......................................................................................................21

2.4. Plataforma Java.......................................................................................................21
2.5. Erwin Data Modeler........................................................................................................22
2.6. Metodologa RUP.......................................................................................................23
2.6.1. Fases de la Metodologa....................................................................................................23
2.6.1.1. Fase de Inicio........................................................................................................23
2.6.1.2. Fase de Elaboracion........................................................................................................24
2.6.1.3. Fase de Construccin.................................................................................................24
2.6.1.4. Fase de Transicin.....................................................................................................24
2.6.2. Especificacin de Fases...................................................................................................24
2.7. Arquitectura Orientada a Servicios............................................................................................24
2.8. Servicios Web.......................................................................................................25
2.9. Definicin de Terminos......................................................................................................26
2.9.1. Integracin......................................................................................................26
2.9.2. Flexibilidad......................................................................................................26
2.10. Sistema de Hiptesis.....................................................................................................26
2.10.1. Hiptesis General.....................................................................................................26
2.10.2. Hiptesis Complementaria....................................................................................................27
2.11. Sistema de Variables.....................................................................................................27
2.11.1. Variable Dependiente......................................................................................................27
2.11.2. Variable Independiente......................................................................................................27
2.11.3. Variables de Causa y Efecto................................................................................................28
Captulo III: Marco Metodolgico ................................................................................11
3.1. Metodologa para el Anlisis y Diseo de la Solucin................................................................28
3.1.1. Metodologa para el Estudio de la Factibilidad de la Solucin................................................28
Plan de Tesis
Captulo IV: Aspectos Administrativos.............................................................................................38

4.1. Diagrama de Gantt.................................................................28
4.1. ndices Preliminares..................................................................28
4.1.1. ndice Preliminar Proyectos de Sistemas 1.............................................................28
4.1.2. ndice Preliminar Proyectos de Sistemas 2........................................................................28
Plan de Tesis
1. Plan de Tesis
2. Resumen Ejecutivo
En la presente investigacin se diseara un sistema bajo la concepcin de la
Arquitectura Orientada a Servicios (SOA), esto nos permitir mejorar la integracin
de los componentes de software, sin importar la plataforma en la que fue
construida. Tambin a travs de esta nueva filosofa de diseo se podr reutilizar
componentes y mejorar el sistema estimador de pensiones de la administradora
de fondos y pensiones AFP Integra, cuya misin es establecer el estndar en la
administracin de pensiones y otorgar el mejor servicio a sus clientes.
El motivo de esta investigacin es porque en la actualidad AFP Integra cuenta con
un sistema estimador de pensiones que no tiene definida una arquitectura que
facilite la integracin, reutilizacin de componentes y es poco flexible frente a
cambios, ocasionando cierta inestabilidad en el sistema adems de no brindar
informacin exacta y oportuna.
El sistema utilizara el estndar UML (Lenguaje Unificado de Modelado), ser un
aplicativo elaborado bajo un entorno web, se utilizara web services, y para la
codificacin se utilizara el lenguaje de programacin Java 1.7, con un IDE Eclipse
Indigo, la base de datos que se utilizara es SQL Server 2008 R2, para el modelado
de los diferentes diagramas se utilizara el Rational Rose y, para el modelamiento
de la base de datos se utilizar el Erwin Data Modeler 7.3.
Plan de Tesis
3. Captulo I: Formulacin del Problema

3.1. Planteamiento del problema
En la actualidad la Aseguradora de Fondos de Pensiones AFP Integra, cuenta
con una serie de sistemas desarrollados en distintas plataformas, uno de los
problemas que existe es la integracin entre sistemas, incluso entre mdulos
de un mismo sistema, como es el caso del estimador de pensiones.
Con el nico objetivo de comprender el problema, se revisara la estructura del
sistema estimador de pensiones.
Calculador
Calculador
Web Site
Publico
Web Site Privado
DB
Administrador
Administrador
Como se puede ver en la imagen, existen dos sistemas haciendo tareas

similares. El nivel de acoplamiento que existe es muy elevado, la integracin es
mucho ms compleja, esto hace que los cambios sean mucho ms difciles de lo
esperado. Con este diseo de sistema nos imposibilita cuatro cosas
fundamentales que se busca en un sistema: Presentar informacin, resolver
lgica de negocio, resolver lgica de datos y almacenar informacin.
Plan de Tesis
3.2. Antecedentes de Solucin

3.2.1. IBM Institute For Business Value
En el 2006 IBM realizo un estudio sobre 35 proyectos realizados
aplicando una arquitectura orientada a servicios en distintos sectores y
regiones de Estados Unidos, como consecuencia del estudio IBM
concluyo que cada proyecto que haba sido diseado bajo una
arquitectura orientada a servicios (SOA), aportaba mucha flexibilidad en
los sistemas y una mejor integracin. En la mayora de los casos reduca
los costos y el mantenimiento era mucho ms sencillo. Ver figura 2.
3.3.
Propuesta de Solucin
Lo que se propone disear un sistema estimador de pensiones adoptando

una Arquitectura Orientada a Servicios (SOA), que facilite la integracin y
brinde informacin exacta y oportuna.
3.4.
Alcance de la Propuesta
Definicin del estndar de Arquitectura Orientada a Servicios para el

sistema estimador de pensiones.
Diseo del sistema estimador de pensiones.
Plan de Tesis
3.5.
Justificacin
Desde hace algn tiempo, las Arquitecturas Orientadas a Servicios (SOA)

son mencionadas constantemente por las empresas proveedoras de
plataformas de aplicaciones.
Por qu adoptar una arquitectura SOA?
Antes de todo aclaremos un trmino clave en esta arquitectura, Servicio,
desde el punto de vista de SOA, servicio ha sido utilizado para describir una
funcin de negocio auto-contenida, con una interfaz bien definida y estable
que recibe requerimientos de sus clientes.
SOA es un estilo arquitectnico que propone modelar toda la empresa,
como una coleccin de servicios expuestos, para as de esta manera llegar a
formar una red de recursos integrados, y cambiar la manera en que se concibe
una arquitectura, no de un sistema o una aplicacin aislada, sino dela empresa
como un todo.
Como ya lo haba mencionado anteriormente, los problemas que se
presentaban en los sistemas que tiene la Aseguradora de Fondos de Pensiones,
era bsicamente de integracin.
La trascendencia de una arquitectura SOA?
A fin de seguir incurriendo este problema lamentable, es que se propone la
definicin de una arquitectura orientada a servicios, que bsicamente nos
permitir reducir el nivel de acoplamiento, permitir la reutilizacin de
componentes, se incrementara la flexibilidad, logra un mapeo ms directo
entre los procesos de negocio y los sistemas.
Varias encuestas sostienen que slo en el orden del 20% de los proyectos
de
sistemas
finalizan
obteniendo
el
objetivo
planteado.
10
Plan de Tesis
3.6. Objetivos
3.6.1. Objetivo General
Diseo de un sistema estimador de pensiones para la
Administradora de Fondos y Pensiones AFP Integra, con orientacin a
Servicios.
3.6.2. Objetivos Especficos

Aplicar una metodologa RUP.
Establecer ciertos estndares que nos permitan un mejor diseo
del sistema.
Dividir el proyecto en varias iteraciones, de tal forma que nos
permita un mejor resultado.
Establecer patrones de diseo.
Arquitectura Orientada a Servicios.
4. Capitulo II: Marco Terico

4.1. Bases Tericas
4.1.1. Sistemas de Informacin
Un sistema de informacin es un conjunto de elementos interrelacionados con el
propsito de prestar atencin a las demandas de informacin de una organizacin,
para elevar el nivel de conocimientos que permitan un mejor apoyo a la toma de
decisiones y desarrollo de acciones.
Un sistema de informacin realiza cuatro actividades bsicas: entrada,
almacenamiento, procesamiento y salida de informacin.
Entrada de datos: Es el proceso mediante el cual el Sistema de Informacin toma
los datos que requiere para procesar la informacin. Las entradas pueden ser
manuales o automticas. Las manuales son aquellas que se proporcionan en forma
directa por el usuario, mientras que las automticas son datos o informacin que
provienen o son tomados de otros sistemas o mdulos.
Almacenamiento de datos: Despus de haber ingresado ciertos datos a travs del
sistema, es necesario guardar esos datos para su posterior uso, para eso existen
ciertos programas denominados sistemas gestores de base de datos (SGBD), que
permiten almacenar y acceder posteriormente a los datos de forma estructurada.
11
Plan de Tesis
Procesamiento de datos: Es la capacidad del Sistema de Informacin para efectuar

clculos de acuerdo con una secuencia de operaciones pre-establecida. Estos
clculos pueden efectuarse con datos introducidos recientemente en el sistema o
bien con datos que estn almacenados. Esta caracterstica de los sistemas permite
la transformacin de datos fuente en informacin que puede ser utilizada para la
toma de decisiones.
Salida de Informacin: La salida, es la capacidad de un Sistema de Informacin
para sacar la informacin procesada; puede ser por medio de reportes en distintos
formatos.
4.2. UML (Lenguaje de Modelado Unificado)

UML (Unified Modeling Language) es un lenguaje que permite modelar,
construir y documentar los elementos que forman un sistema software
orientado a objetos. Se ha convertido en el estndar de facto de la industria de
software.
Grady Booch, Ivar Jacobson y Jim Rumbaugh. Fueron quienes desarrollaron una
notacin unificada en la que basar la construccin de sus herramientas case.
Esta notacin ha sido ampliamente aceptada debido al prestigio de sus
creadores y debido a que incorpora las principales ventajas de cada uno de los
mtodos particulares en los que se basa:
Booch, OMT y OOSE. UML ha puesto fin a las llamadas guerras de mtodos
que se han mantenido a lo largo de los 90.
UML ofrece nueve diagramas en los cuales se puede modelar sistemas.
Diagramas de Casos de Uso para modelar los procesos de negocio.
Diagramas de Secuencia para modelar el paso de mensajes y eventos
que existen entre objetos.
Diagramas de Colaboracin para modelar interacciones entre objetos.
12
Plan de Tesis
Diagramas de Estado para modelar el comportamiento de los objetos

en el sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos
de Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura esttica de las clases en
el sistema.
Diagramas de Objetos para modelar la estructura esttica de los objetos
en el sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementacin para modelar la distribucin del sistema.
4.2.1. Diagramas de Casos de Uso

Los casos de uso, son requisitos funcionales que indican que har el
sistema, los casos de uso son documentos de texto que esta bien
detallado y estructurado para entender en profundidad los objetivos,
tareas o requisitos.
Un diagrama de caso de uso, es una excelente representacin del
contexto del sistema; muestra los limites del sistema y como se utiliza.
Sirve como herramienta de comunicacin que resume el
comportamiento de un sistema y sus actores.
13
Plan de Tesis
4.2.2. Actor
Un actor es cualquier objeto con comportamiento. Los actores no son
solamente roles que juegan personas, sino tambin organizaciones
software y maquinas.
Existen tres tipos de actores:
Actor principal: Tiene objetivos de usuario que se satisfacen mediante
el uso de los servicios del UsD (Sistemas en Discusin).
Actor de Apoyo: proporciona un servicio (por ejemplo, informacin) al
sistema en discusin. Normalmente se trata de un sistema informtico,
pero podra ser una organizacin o una persona.
Actor Pasivo: esta interesado en el comportamiento del caso de uso,
pero no es principal ni de apoyo.
14
Plan de Tesis
4.2.3. Diagrama de Clases

Un diagrama de clases es un tipo de diagrama esttico que describe la
estructura de un sistema mostrando sus clases, atributos y las
relaciones entre ellos. Los diagramas de clases son utilizados durante el
proceso de anlisis y diseo de los sistemas, donde se crea el diseo
conceptual de la informacin que se manejar en el sistema, y los
componentes que se encargaran del funcionamiento y la relacin entre
uno y otro.
4.2.4. Diagrama de Secuencia

Un diagrama de secuencia del sistema, es un artefacto creado de
manera rpida y fcil, que muestra los eventos de entrada y salida
relacionados con el sistema que se esta estudiando. UML incluye la
notacin de los diagramas de secuencia para representar los eventos
que parten de los actores externos hacia el sistema.
Los casos de uso describen como interactan los actores externos con
el sistema software que estamos interesados en crear. Durante esta
interaccin, un actor genera eventos sobre un sistema, normalmente
solicitando alguna operacin como respuesta.
15
Plan de Tesis
Un diagrama de secuencia es un dibujo que muestra, para un escenario

especifico de un caso de uso, los eventos que generan los actores, el
orden de los eventos entre los sistemas.
4.2.5. Diagrama de Colaboracin

Un diagrama de colaboracin, es esencialmente un diagrama que muestra
interacciones organizadas alrededor de los roles. A diferencia de los diagramas de
secuencia, los diagramas de colaboracin, tambin llamados diagramas de
comunicacin, muestran explcitamente las relaciones de los roles. Por otra parte, un
diagrama de comunicacin no muestra el tiempo como una dimensin aparte, por lo
que resulta necesario etiquetar con nmeros de secuencia tanto la secuencia de
mensajes como los hilos concurrentes.
16
Muestra cmo las instancias especficas de las clases trabajan juntas para
conseguir un objetivo comn.
Plan de Tesis
Implementa las asociaciones del diagrama de clases mediante el paso de

mensajes de un objeto a otro. Dicha implementacin es llamada "enlace".
4.2.6. Diagrama de Estado

Un Diagrama de Estados muestra la secuencia de estados por los que
pasa un caso de uso o un objeto a lo largo de su vida, indicando qu
eventos hacen que se pase de un estado a otro y cules son las
respuestas y acciones que genera.
En cuanto a la representacin, un diagrama de estados es un grafo
cuyos nodos son estados y cuyos arcos dirigidos son transiciones
etiquetadas con los nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del
estado en su interior. Una transicin se representa como una flecha
desde el estado origen al estado destino.
La caja de un estado puede tener 1 o 2 compartimentos. En el primer
compartimento aparece el nombre del estado. El segundo
compartimento es opcional, y en l pueden aparecer acciones de
entrada, de salida y acciones internas.
Una accin de entrada aparece en la forma entrada/accin_asociada
donde accin_asociada es el nombre de la accin que se realiza al
entrar en ese estado. Cada vez que se entra al estado por medio de una
transicin la accin de entrada se ejecuta.
Una accin de salida aparece en la forma salida/accin_asociada. Cada
vez que se sale del estado por una transicin de salida la accin de
salida se ejecuta.
17
Plan de Tesis
Una accin interna es una accin que se ejecuta cuando se recibe un

determinado evento en ese estado, pero que no causa una transicin a
otro estado. Se indica en la forma nombre_de_evento/accin_asociada.
4.2.7. Diagrama de actividades

Los diagramas de actividades fundamentalmente sirven para modelar el
flujo de control entre actividades.
La idea es generar una especie de diagrama Pert, en el que se puede ver
el flujo de actividades que tienen lugar a lo largo del tiempo, as como
las tareas concurrentes que pueden realizarse a la vez. El diagrama de
actividades sirve para representar el sistema desde otra perspectiva, y
de este modo complementa a los anteriores diagramas vistos.
Grficamente un diagrama de actividades ser un conjunto de arcos y
nodos.
Desde un punto de vista conceptual, el diagrama de actividades
muestra cmo fluye el control de unas clases a otras con la finalidad de
culminar con un flujo de control total que se corresponde con la
consecucin de un proceso ms complejo.
Por este motivo, en un diagrama de actividades aparecern acciones y
actividades correspondientes a distintas clases. Colaborando todas ellas
para conseguir un mismo fin.
Bsicamente los diagramas de actividades contienen:
Estados de la actividad.
Estados de accin.
Transicin.
18
Plan de Tesis
Objetos.
4.2.8. Diagrama de Componentes

Un diagrama de componentes muestra la organizacin y las
dependencias entre un conjunto de componentes.
Para todo sistema OO se han de construir una serie de diagramas que
modelan tanto la parte esttica (diagrama de clases), como dinmica
(diagramas de secuencia, colaboracin, estados y de actividades), pero
llegado el momento todo esto se debe materializar en un sistema
implementado que utilizar partes ya implementadas de otros sistemas,
todo esto es lo que pretendemos modelar con los diagramas de
componentes.
Un diagrama de componentes muestra un conjunto de componentes y
sus relaciones de manera grfica a travs del uso de nodos y arcos entre
estos.
Normalmente los diagramas de componentes contienen:
Componentes.
Interfaces.
Relaciones de dependencia, generalizacin, asociaciones y
realizacin.
19
Plan de Tesis
Paquetes o subsistemas.
Instancias de algunas clases.
Visto de otro modo un diagrama de componentes puede ser un tipo
especial de diagrama de clases que se centra en los componentes fsicos
del sistema.
4.2.9. Diagrama de despliegue

El desarrollo de un sistema empotrado es ms que el desarrollo de un
sistema software. Hay que manejar el mundo fsico. Los diagramas de
despliegue son tiles para facilitar la comunicacin entre los ingenieros
de hardware y los de software.
Para modelar un sistema empotrado es necesario:
Identificar los dispositivos y nodos propios del sistema.
Proporcionar seales visuales, sobre todo para los dispositivos
poco usuales.
Modelar las relaciones entre esos procesadores y dispositivos en
un diagrama de despliegue.
20
Plan de Tesis
Si es necesario hay que detallar cualquier dispositivo inteligente,

modelando su estructura en un diagrama de despliegue ms
pormenorizado.
4.3. Base de datos

Microsoft SQL Server es un sistema de base de datos relacional de gestin
desarrollado por Microsoft. Como una base de datos, es un producto de
software cuya principal funcin es la de almacenar y recuperar datos solicitada
por otras aplicaciones de software. Hay al menos una docena de diferentes
ediciones de Microsoft SQL Server dirigidas a pblicos diferentes y para
diferentes cargas de trabajo (que van desde pequeas aplicaciones que
almacenan y recuperan los datos en el mismo equipo, a millones de usuarios y
equipos que tienen acceso a grandes cantidades de datos a travs de Internet
al mismo tiempo).
4.4. Plataforma Java

Java es un lenguaje de programacin de alto nivel orientado a objetos,
desarrollado por James Gosling en 1995. El lenguaje en s mismo toma mucha
de su sintaxis de C, Cobol y Visual Basic, pero tiene un modelo de objetos ms
simple y elimina herramientas de bajo nivel.
21
Plan de Tesis
La plataforma Java es el nombre de un entorno o plataforma de computacin

originaria de Sun Microsystems, capaz de ejecutar aplicaciones desarrolladas
usando el lenguaje de programacin Java u otros lenguajes que compilen
a bytecodey un conjunto de herramientas de desarrollo. En este caso, la
plataforma no es un hardware especfico o un sistema operativo, sino ms bien
una mquina virtual encargada de la ejecucin de las aplicaciones.
La Plataforma Java se compone de un amplio abanico de tecnologas, cada una
de las cuales ofrece una parte del complejo de desarrollo o del entorno de
ejecucin en tiempo real. Por ejemplo, los usuarios finales suelen interactuar
con la mquina virtual de Java y el conjunto estndar de bibliotecas. Adems,
las aplicaciones Java pueden usarse de forma variada, como por ejemplo ser
incrustadas en una pgina web. Para el desarrollo de aplicaciones, se utiliza un
conjunto de herramientas conocidas como JDK (Java Development Kit, o
herramientas de desarrollo para Java).
4.5. Erwin Data Modeler

CA ERwin Data Modeler (Erwin) es una herramienta de software para el
modelado de datos (anlisis de requerimientos, diseo de bases de datos, etc)
de los sistemas de informacin personalizados desarrollados, incluyendo bases
de datos de los sistemas transaccionales y data marts. ERwin motor de
modelado de datos se basa en el mtodo IDEF1X, a pesar de que ahora soporta
diagramas que se muestran con la notacin de informacin de ingeniera.
22
Plan de Tesis
4.6. Metodologa RUP

El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de
ingeniera de software que suministra un enfoque para asignar tareas y
responsabilidades dentro de una organizacin de desarrollo. Su objetivo es
asegurar la produccin de software de alta calidad que satisfaga la necesidad del
usuario final dentro de un tiempo y presupuesto previsible. Es una metodologa de
desarrollo iterativo enfocada hacia los casos de uso, manejo de riesgos y el
manejo de la arquitectura.
4.6.1. Fases
4.6.1.1.
Fase de Inicio
Durante esta fase de inicio las iteraciones se centran con

mayor nfasis en las actividades de modelamiento de la empresa y
en sus requerimientos.
4.6.1.2.
Fase de Elaboracin
Durante esta fase de elaboracin, las iteraciones se centran

al desarrollo de la base de la diseo, encierran ms los flujos de
trabajo de requerimientos, modelo de la organizacin, anlisis,
diseo y una parte de implementacin orientada a la base de la
construccin
23
Plan de Tesis
4.6.1.3.
Fase de Construccin
Durante esta fase de construccin, se lleva a cabo la

construccin del producto por medio de una serie de iteraciones las
cuales se seleccionan algunos Casos de Uso, se redefine su anlisis y
diseo y se procede a su implantacin y pruebas. En esta fase se
realiza una pequea cascada para cada ciclo, se realizan tantas
iteraciones hasta que se termine la nueva implementacin del
producto.
4.6.1.4.
Fase de Transicin
Durante esta fase de transicin busca garantizar que se tiene

un producto preparado para su entrega al usuario.
4.6.2. Especificacin de Fases

Establece oportunidad y alcance.
Identifica las entidades externas o actores con las que se trata.
Identifica los casos de uso.
4.7. Services Oriented Architecture (SOA)

La Arquitectura SOA establece un marco de diseo para la integracin de
aplicaciones independientes de manera que desde la red pueda accederse a sus
funcionalidades, las cuales se ofrecen como servicios. La forma ms habitual de
implementarla es mediante Servicios Web, una tecnologa basada en estndares e
independiente de la plataforma, con la que SOA puede descomponer aplicaciones
monolticas en un conjunto de servicios e implementar esta funcionalidad en
forma modular.
La estrategia de orientacin a servicios permite la creacin de servicios y
aplicaciones compuestas que pueden existir con independencia de las tecnologas
subyacentes. En lugar de exigir que todos los datos y lgica de negocio residan en
un mismo ordenador, el modelo de servicios facilita el acceso y consumo de los
recursos de IT a travs de la red. Puesto que los servicios estn diseados para ser
independientes, autnomos y para interconectarse adecuadamente, pueden
combinarse y recombinarse con suma facilidad en aplicaciones complejas que
respondan a las necesidades de cada momento en el seno de una organizacin. Las
aplicaciones compuestas (tambin llamadas
24
Plan de Tesis
dinmicas) son lo que permite a las empresas mejorar y automatizar sus

procesos manuales, disponer de una visin consistente de sus clientes y socios
comerciales y orquestar sus procesos de negocio para que cumplan con las
regulaciones legales y polticas internas. El resultado final es que las organizaciones
que adoptan la orientacin a servicios pueden crear y reutilizar servicios y
aplicaciones y adaptarlos ante los cambios evolutivos que se producen dentro y
fuera de ellas, y con ello adquirir la agilidad necesaria para ganar ventaja
competitiva.
4.7.1. Servicios Web

Los servicios Web se basan en un conjunto de estndares de comunicacin, como
son XML para la representacin de datos, SOAP (Simple Object Access Protocol)
para el intercambio de datos y el lenguaje WSDL (Web Services Description
Language) para describir las funcionalidades de un servicio
Web. Existen ms especificaciones, a las que se denomina genricamente como la
arquitectura WS, que definen distintas funcionalidades para el descubrimiento de
servicios Web, gestin de eventos, archivos adjuntos, seguridad, gestin y
fiabilidad en el intercambio de mensajes y transacciones.
25
Plan de Tesis
4.8. Definicin de Trminos

4.8.1. Integracin
Integracin tiene su origen en el concepto latino integration. Se trata de
la accin y efecto de integrar o integrarse (constituir un todo,
completar un todo con las partes que faltaban o hacer que alguien o
algo
pase
a
formar
parte
de
un
todo).
4.8.2. Flexibilidad
Por flexibilidad se entiende a la caracterstica de flexible. Se trata de
una palabra que permite resaltar la disposicin de un individuo u
objeto para ser doblado con facilidad, la condicin de plegarse segn la
voluntad de otros y la susceptibilidad para adaptarse a los cambios de
acuerdo a las circunstancias.
4.9. Sistemas de Hiptesis

4.9.1. Hiptesis General
Sistema en diseo, permitir lograr una mejor integracin y mayor
flexibilidad, adems deber permitir la reutilizacin de componentes.
26
Plan de Tesis
4.9.2. Hiptesis Complementaria

-
El sistema brindara informacin de las estimaciones que se desee

realizar.
El sistema ser parametrizable.
El sistema deber permitir la reutilizacin de los componentes.
4.10. Sistemas de variables

4.10.1. Variables Dependientes
Integracin
Se clasificara Esta definida a la capacidad de integracin que
pueda tener el sistema, la clasificacin ser en tres niveles (Alta,
Mediana, Baja).
Flexibilidad
Se clasifica por la capacidad de cambiar ciertas
funcionalidades, la clasificacin ser en tres niveles (alta,
mediana, baja).
4.10.2. Variable Independientes

Arquitectura aplicada
Esta variable esta definida, teniendo en cuenta si se desarrollo
alguna arquitectura para la construccin del sistema.
Metodologa de desarrollo
Esta variable esta definida teniendo en cuenta el porcentaje se
sigui cada fase de la metodologa (Anlisis, diseo, construccin,
pruebas).
Estndares de desarrollo
Esta variable esta definida tendiendo en cuenta si se aplic
algunos estndares de desarrollo durante la fase de
construccin del proyecto.
4.10.3. Variables de Causa y Efecto
27
Plan de Tesis
28
Plan de Tesis
5. Captulo III: Marco Metodolgico

5.1. Metodologa para el anlisis y diseo de la solucin
La metodologa que se aplicara para desarrollar el presente proyecto es la
metodologa de proceso unificado (RUP), a continuacin se explicara las buenas
practicas, las fases que comprende la metodologa RUP y las herramientas que se
utilizaran en cada una de sus fases.
Adems se aplicara una arquitectura Orientada a Servicios con la finalidad de
concebir un mejor diseo del sistema en estudio.
El proceso unificado de rational fomenta muchas buenas prcticas, pero tres
destacan sobre las dems:
Dirigido por casos de uso.- Dentro del proceso unificado uno de los aspectos ms
resaltantes es la elaboracin de casos de uso.
Centrado en la arquitectura.- Para este proceso del proceso unificado, se est
considerando aplicar una arquitectura orientada a servicios, que nos permita
implantar las necesidades de negocio desde una nueva perspectiva de realizar
sistemas.
Iterativo e incremental.- en este enfoque el desarrollo se organiza en miniproyectos cortos, de duracin fija llamados iteraciones, el resultado de cada uno
es un sistema que puede ser probado, integrado y ejecutado, Cada iteracin
incluye sus propias actividades de anlisis, diseo, implantacin y pruebas.
El ciclo de vida iterativo se basa en la ampliacin y refinamiento sucesivos del
sistema mediante mltiples iteraciones con retroalimentacin cclica y adaptacin
como elementos principales que dirigen para converger hacia un sistema
adecuado.
29
Plan de Tesis
5.1.1. Fases del RUP

Inicio.- Visin aproximada, anlisis del negocio, alcance, estimaciones
imprecisas.
Elaboracin.- Visin refinada, implantacin iterativa del ncleo central de
la arquitectura, resolucin de los riesgos altos, identificacin de ms
requisitos y alcance, estimaciones ms realistas.
Construccin.- implantacin iterativa del resto de requisitos del menor
riesgo y elementos ms fciles, preparacin para el despliegue.
Transicin.- pruebas y despliegue del sistema que se desarroll.
5.1.2. Herramientas y Tcnicas que se utilizaran en cada una de las

fases de la metodologa RUP.
Inicio:
Entrevista.- Las entrevistas se harn con los usuarios, en una primera
instancia la informacin recolectada nos permitir realizar un primer
bosquejo de las necesidades y nos permitir un alcance tentativo del
proyecto.
Formato de para los casos de uso.- Como sabemos, una de las buenas
prcticas de RUP es la orientacin a casos de uso, para ello es necesario
realizar una buena especificacin, con la finalidad de entender mejor los
requerimientos.
30
Plan de Tesis
Elaboracin
En la elaboracin se realizan los diferentes diagramas de UML, La
elaboracin de estos diagramas se realizara sobre la herramienta Rational
Rose, es una herramienta que permite disear los diferentes diagramas
(Diagramas de casos de uso, Diagramas de Secuencia, Diagrama de
estados, Diagrama de Clase, Diagrama de Componentes, Diagrama de
Despliegue, Diagrama de actividades, Diagrama de colaboracin). A travs
de estos diagramas asignaremos responsabilidades a los objetos de clases
y podemos ver la secuencia de mensajes entre objetos. Esto brindara una
idea ms clara de lo que queremos realizar y nos ayude en la construccin.
En esta fase del RUP, tambin se elaborar el modelamiento de datos con
la herramienta Erwin Data Modeler, tendr todas las entidades y sus
relaciones entre ellas, posteriormente se aplicara un forward engineering
para la generacin de nuestro script, donde los datos se almacenaran en
nuestras tablas generadas.
Construccin:
Lenguaje de programacin: Se utilizara el lenguaje JAVA, ya que es un
lenguaje muy maduro, basado en clases y orientado a objetos.
Web Services: una de las formas de implantar SOA es a travs de los Web
Services, estas aplicaciones utilizan estndares para el transporte,
codificacin y protocolo de intercambio de informacin. Los web services
permiten la comunicacin entre sistemas de distintas plataformas.
Entre los estndares que maneja esta:
XML: para la representacin de datos.
SOAP: para el intercambio de datos.
WSDL: para describir las funcionalidades de los servicios.
Para la implantacin de los web services se realizara a travs de la
tecnologa MULE, donde crearemos aplicaciones mediante la creacin
de servicios que posteriormente sern consumidas, es una tecnologa
OpenSource ligera y altamente escalable que permite la conexin de
aplicaciones en l tiempo.
Se utilizar tambin la tecnologa MAVEN para la gestin de
dependencias en el proyecto.
31
Plan de Tesis

Como controlador de utilizar el framework Spring MVC, donde las
inyecciones de dependencias se realizara a travs de anotaciones, es un
framework OpenSource.
Para la parte visual del sistema se utilizara un framework llamado, este
framework nos facilitara el manejo de los componentes a nivel de interfaz,
es un framework OpenSource.
Hibrnate es un framework que se utilizar para la parte de persistencia
de datos con mapeo de entidades a travs de JPA.
Se utilizara para el almacenamiento de datos SQL Server 2008 R2, est
basado en el modelo relacional, es uno de los potentes sistemas gestores
de base de datos al igual que Oracle, DB2, etc.
Servidor de Aplicaciones: Se utilizara como servidor de aplicaciones JBoss,
sus principales caractersticas por el que se eligi son las siguientes:
OpenSource.
Escalable.
Alto Desempeo.
Arquitectura Modular.
5.1.3. Consideraciones para implantar SOA

Embarcarse en un proyecto de SOA supone tener que resolver una serie de
retos, tanto a nivel organizativo como tcnico, y estos retos pueden
convertirse en verdaderas barreras insuperables si se ha partido de la idea de
que SOA es el remedio para toda clase de males..
Para que las iniciativas de adopcin de SOA tengan un fin satisfactorio, hay
que asegurarse de que se cumplen una serie de condiciones indispensables:
Definir claramente los objetivos de negocio. El primer paso a la hora de
adoptar SOA es identificar con claridad los problemas o retos empresariales
ms prioritarios. Cuando ms precisa sea esa formulacin, ms fcilmente se
podr delimitar la direccin y el alcance de cualquier proyecto SOA. Disponer
de una visin y un rumbo claro desde el principio har mucho ms fcil la
ejecucin de procesos cuya esencia es la integracin de mltiples funciones.
Definir claramente el alcance del proyecto SOA. El objetivo de cualquier
proyecto SOA no debe consistir en renovar de forma indiscriminada y masiva
toda la infraestructura de IT. Este tipo de megaproyectos fracasan a la hora de
implementarlos porque cuando por fin se ha conseguido crear la solucin, las
condiciones del negocio suelen haber cambiado tanto que los problemas que
ahora deben resolverse ya no tienen mucho que ver con aquellos que se
pretendan resolver cuando se inici el proyecto. El objetivo real de cada
32
Plan de Tesis

iniciativa SOA debe ser responder a necesidades concretas de negocio y crear
soluciones en pasos discretos, incrementales e iterativos.
Evitar introducir SOA sin motives reales que lo justifiquen. La adopcin de
SOA no debe considerarse una necesidad tecnolgica, sino organizativa: debe
responder a las necesidades de la organizacin. Si la introduccin de SOA
solamente responde al puro gusto por disponer de SOA y se empiezan a crear
servicios sin un significado de negocio claro, sin la granularidad adecuada o
con demasiadas interconexiones, el resultado ser una implementacin
excesivamente compleja, inmanejable y tremendamente costosa.
Gestionar el proceso. Los servicios y aplicaciones se corresponden con
procesos y los outputs de informacin deseados a travs de las diversas reas
funcionales de la organizacin. Puesto que representan procesos compartidos,
es necesario que se les asigne un propietario para que puedan inventariarse y
gestionarse a fin de garantizar que cumplen en todo momento con las
directivas corporativas y responden adecuadamente a las necesidades que los
justifican.
5.1.4. Beneficios de Aplicar SOA.

Mejora la toma de decisiones: Al mejorar la integracin de nuestras
aplicaciones, los usuarios disponen de informacin exacta y oportuna, adems
que la organizacin puede reaccionar con ms rapidez frente a los cambios
que puedan surgir.
Mejora la productividad de los empleados: El acceso ptimo a los sistemas y
a la informacin permiten mejorar la productividad individual de los
empleados.
Aplicaciones ms productivas y flexibles: la orientacin a servicios permite
una mayor productividad de los recursos de IT, y una de sus caractersticas es
la flexibilidad a la hora del diseo de cualquier solucin.
Desarrollo de aplicaciones ms rpido y econmico: el desarrollo sobre una
arquitectura SOA, permite la reutilizacin de componentes, de esta manera se
estara reduciendo costes.
33
Plan de Tesis
5.2. Metodologa para el estudio de factibilidad (viabilidad) de la

solucin.
5.2.1. Factibilidad Tcnica.
Herramientas Software y Frameworks
Factibilidad
Rational Rose
Erwin Data Modeler
SQL Server 2008 R2
Servidor de Aplicaciones JBoss
Lenguaje de Programacin Java
MULE
Framework: Spring MVC, ZK,
Hibernate, JPA.
Maven
SVN
Hardware
Factibilidad
Laptop y PCs Desktop
Router
Modem
5.2.2. Factibilidad Econmica.

Para verificar si nuestro proyecto es factible econmicamente tendremos
que recurrir a las siguientes herramientas.
-
Valor Actual Neto (VAN)

Anlisis Costo Beneficio
Valor Actual Neto.- Es un indicador que nos permitir medir los flujos de los
futuros ingresos y egresos que tendr nuestro proyecto, para determinar, si
luego de descontar la inversin inicial, nos quedara alguna ganancia. Si el
resultado es positivo, el proyecto es viable.
Anlisis Costo Beneficio.- El anlisis Costo Beneficio es una herramienta
que mide la relacin entre los costos y los beneficios asociados a un
proyecto de inversin con el fin de evaluar su rentabilidad.
34
Plan de Tesis
Segn el anlisis Costo Beneficio, podremos saber si el proyecto en

estudio es rentable para ello la relacin tiene que ser mayor que la unidad
Los pasos necesarios para hallar y analizar la relacin costo-beneficio son
los siguientes:
1. Hallar costos y beneficios: en primer lugar hallamos la proyeccin de
los costos de inversin o costos totales y los ingresos totales netos o
beneficios netos del proyecto o negocio para un periodo de tiempo
determinado.
2. Convertir costos y beneficios a un valor actual: debido a que los
montos que hemos proyectado no toman en cuenta el valor del dinero
en el tiempo (hoy en da tendran otro valor), debemos actualizarlos a
travs de una tasa de descuento.
3. Hallar relacin costo-beneficio: dividimos el valor actual de los
beneficios entre el valor actual de los costos del proyecto.
4. Analizar relacin costo-beneficio: si el valor resultante es mayor que 1
el proyecto es rentable, pero si es igual o menor que 1 el proyecto no
es viable pues significa que los beneficios sern iguales o menores que
los costos de inversin o costos totales.
35
Plan de Tesis
6. Captulo IV:
6.1. Diagrama de Gantt
36
Plan de Tesis
37
Plan de Tesis
6.2. ndice Preliminar

6.2.1. ndice Proyectos de Sistemas 1
Plan De Tesis
Resumen Ejecutivo
Captulo I: Formulacin del Problema
1.1. Planteamiento del Problema
1.2. Antecedentes de Solucin
1.3. Propuesta de Solucin
1.4. Alcance de la Propuesta
1.5. Justificacin
1.6. Objetivos
Captulo II: Marco Terico
2.1. Base Terica
2.1.1. Sistemas de Informacin
2.2. UML
2.2.1. Diagrama de Casos de Uso
2.2.2. Actor
2.2.3. Diagrama de Clases
2.2.4. Diagrama de Secuencia
2.2.5. Diagrama de Colaboracin
2.2.6. Diagrama de Estado
2.2.7. Diagrama de Actividades
2.2.8. Diagrama de Componentes
2.2.9. Diagrama de Despliegue
2.3. Base de Datos
2.4. Plataforma Java
2.5. Erwin Data Modeler
2.6. Metodologa RUP
2.6.1. Fases de la Metodologa
2.6.1.1. Fase de Inicio
2.6.1.2. Fase de Elaboracin
2.6.1.3. Fase de Construccin
2.6.1.4. Fase de Transicin
2.6.2. Especificacin de Fases
2.7. Arquitectura Orientada a Servicios
2.8. Servicios Web
2.9. Definicin de Trminos
2.9.1. Integracin
2.9.2. Flexibilidad
38
Plan de Tesis

2.10. Sistema de Hiptesis
2.10.2. Hiptesis Complementaria
Captulo III: Marco Metodolgico
3.1.5. Metodologa para el Anlisis y Diseo de la Solucin
3.1.6. Metodologa para el Estudio de la Factibilidad de la solucin
3.1.6.1. Factibilidad Tcnica
3.1.6.2. Factibilidad Econmica
Captulo IV: Aspectos Administrativos
4.1. Diagrama Gantt
4.2 ndice Preliminar
4.2.1. ndice Preliminar Proyectos 1
4.2.2. ndice Preliminar Proyectos 2
6.2.2. ndice Proyectos de Sistemas 2

Resumen Ejecutivo
Captulo I: Introduccin
Captulo II: Justificacin de la Investigacin
2.1. Objetivos
2.2. Hiptesis
2.2.2. Hiptesis Especficas
2.3. Diferenciacin con otras Investigaciones Similares
Captulo III: Situacin Actual
3.1. Definicin del Problema
3.2. Alcance y Limites del Estudio
3.3. Identificacin de las Variables
3.3.1. Variable Independiente
3.3.2. Variable Dependiente
3.4. Volmenes de Informacin
Captulo IV: Marco Terico
Captulo V: Solucin Propuesta
5.1. Anlisis de la Solucin Propuesta
5.2. Propuesto del Proyecto
5.2.1. Diagrama de Contexto
39
Plan de Tesis
5.2.2. Diagrama de Flujo de Datos

5.2.3. Caso de Uso
5.2.4. Diagrama de Actividad
5.2.5. Modelo Entidad-Relacin (E-R)
5.2.6. Diagrama de Actividades
5.2.7. Prototipos
5.3. Cronograma de Actividades
5.4. Anlisis Costo-Beneficio
Captulo VI: Conclusiones y Recomendaciones
6.1. Conclusiones
6.2. Recomendaciones
6.2.3. Referencias
http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/docmodelado-sistemas-uml.pdf
http://fermat.usach.cl/~msanchez/comprimido/OBJETOS.pdf
http://www-03.ibm.com/marketing/pe/soa/
http://www.degerencia.com/articulo/por_que_fracasan_los_proyectos
http://www.econlink.com.ar/sistemas-informacion/definicion
40

Proyecto de Ingenieria de Sistemas I

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto de Ingenieria de Sistemas I

Cargado por

Copyright:

Formatos disponibles

Plan de Tesis

Proyecto de Ingeniera de Sistemas I

Proyectos de Ingeniera de Sistemas I

Pisco Sedano Jorge Luis

MBA Ing. Carlos Zorrilla Vargas

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

2.3. Base de Datos.......................................................................................................21

Proyecto de Ingeniera de Sistemas I

Captulo IV: Aspectos Administrativos.............................................................................................38

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

3. Captulo I: Formulacin del Problema

Web Site Privado

Como se puede ver en la imagen, existen dos sistemas haciendo tareas

Proyecto de Ingeniera de Sistemas I

3.2. Antecedentes de Solucin

Lo que se propone disear un sistema estimador de pensiones adoptando

Definicin del estndar de Arquitectura Orientada a Servicios para el

Proyecto de Ingeniera de Sistemas I

Desde hace algn tiempo, las Arquitecturas Orientadas a Servicios (SOA)

Proyecto de Ingeniera de Sistemas I

3.6.2. Objetivos Especficos

4. Capitulo II: Marco Terico

Proyecto de Ingeniera de Sistemas I

Procesamiento de datos: Es la capacidad del Sistema de Informacin para efectuar

4.2. UML (Lenguaje de Modelado Unificado)

Proyecto de Ingeniera de Sistemas I

Diagramas de Estado para modelar el comportamiento de los objetos

4.2.1. Diagramas de Casos de Uso

Proyecto de Ingeniera de Sistemas I

Proyecto de Ingeniera de Sistemas I

4.2.3. Diagrama de Clases

4.2.4. Diagrama de Secuencia

Proyecto de Ingeniera de Sistemas I

Un diagrama de secuencia es un dibujo que muestra, para un escenario

4.2.5. Diagrama de Colaboracin

Proyecto de Ingeniera de Sistemas I

Implementa las asociaciones del diagrama de clases mediante el paso de

4.2.6. Diagrama de Estado

Proyecto de Ingeniera de Sistemas I

Una accin interna es una accin que se ejecuta cuando se recibe un

4.2.7. Diagrama de actividades

Proyecto de Ingeniera de Sistemas I

4.2.8. Diagrama de Componentes

Proyecto de Ingeniera de Sistemas I

4.2.9. Diagrama de despliegue

Proyecto de Ingeniera de Sistemas I

Si es necesario hay que detallar cualquier dispositivo inteligente,

4.3. Base de datos

4.4. Plataforma Java

Proyecto de Ingeniera de Sistemas I

La plataforma Java es el nombre de un entorno o plataforma de computacin

4.5. Erwin Data Modeler

Proyecto de Ingeniera de Sistemas I

4.6. Metodologa RUP

Durante esta fase de inicio las iteraciones se centran con

Durante esta fase de elaboracin, las iteraciones se centran

Proyecto de Ingeniera de Sistemas I

Durante esta fase de construccin, se lleva a cabo la

Durante esta fase de transicin busca garantizar que se tiene

4.6.2. Especificacin de Fases