Bolsa de Trabajo Hecha

SISTEMA WEB DE BOLSA DE EMPLEO PARA EL MINISTERIO DE TRABAJO Y EMPLEO

ESCUELA POLITCNICA DEL EJRCITO

DPTO. DE CIENCIAS DE LA COMPUTACIN

CARRERA DE INGENIERA EN SISTEMAS E INFORMTICA

SISTEMA WEB DE BOLSA DE EMPLEO PARA EL MINISTERIO DE TRABAJO Y EMPLEO DEL ECUADOR

Previa a la Obtencin del Ttulo de:

INGENIERO EN SISTEMAS E INFORMTICA

POR:

SR. MARIO LEONARDO ESPINOZA DAZ SR. JAIRO ANBAL PREZ CUESTAS

SANGOLQU, Diciembre del 2009

1


CERTIFICACINCertifico que el presente trabajo fue realizado en su totalidad por los Srs. Mario Leonardo Espinoza Daz y Jairo Anbal Prez Cuestas como requerimiento parcial a la obtencin del ttulo de Ingenieros en Sistemas e Informtica.

21 de Diciembre del 2009.

_________________________ Ing. Mauricio Campaa

2


DEDICATORIAEste trabajo est dedicado especialmente a mis padres y a mi hermana, ya que gracias su esfuerzo y sacrificio diario me ayudaron a nunca rendirme en los momentos difciles, puesto que con todo su amor y cario supieron darme fuerzas para mantenerme constante en conseguir mis metas. Fueron mi principal fuente de inspiracin en mi vida profesional y personal.

Las gracias se las doy a mis padres por inculcarme todos los valores desde mi infancia para ser una persona de bien, por depositar en mi toda su confianza y apoyo, por aconsejarme diariamente para de esta manera disfrutar de esta nueva etapa en mi vida.

A mis abuelitos y a mi familia que siempre me apoyaron durante toda mi etapa escolar.

MARIO LEONARDO ESPINOZA DAZ.

3


AGRADECIMIENTOS

A Dios por permitirme escribir cada una de estas palabras, por siempre haberme brindado la fuerza necesaria para culminar esta etapa en mi vida a pesar de tantas dificultades que se me presentaron. Agradezco a mis padres ANA DAZ y LEONARDO ESPINOZA, a mis abuelitos OLGA DAZ y LUIS DAZ, a mi ta VIVIANA DAZ y a toda mi familia por darme siempre su apoyo y confianza incondicional, por estar junto a m en los momentos ms difciles y por todo el amor y cario que me brindan da a da. A mi amigo y colaborador de esta tesis JAIRO PREZ, quien deposito en m toda su confianza para poder desarrollar este trabajo sin ningn tipo de contratiempo y teniendo siempre una meta en comn, de realizar un excelente trabajo. A mi director y codirector de tesis, quienes con sus conocimientos supieron guiarme en el proceso de desarrollo de la tesis A mi querida ESPE y a mis maestros que fueron ms que docentes, amigos por impartir el conocimiento durante todo el tiempo que duro mi carrera, lo cual me ayudar y me guiar en mi vida profesional y personal. A mis amigos por depositar en mi su apoyo, amistad y confianza en todo momento dentro de nuestra etapa universitaria y fuera de ella.

MARIO LEONARDO ESPINOZA DAZ

4


DEDICATORIA

Este trabajo de investigacin est dedicado principalmente a mis padres JAIRO PEREZ, ARALY CUESTAS y a todos mis familiares que de una u otra manera estuvieron involucrados en la culminacin de mi carrera, supieron ayudar en los momentos ms difciles. Tambin dedico este arduo trabajo a una persona muy especial en mi vida PAMELA RIVERA, que siempre ha estado ah en las buenas y en las malas, para ayudarme y darme aliento para seguir adelante. A todos mis maestros que me supieron guiar y formar de la mejor manera, gracias a todos. ya que con su cario y empuje me

JAIRO ANBAL PREZ CUESTAS

5


AGRADECIMIENTOS

En primer lugar agradezco a Dios que es quien me ha dado lo ms importante que es la vida y me ha sabido dar aliento en los peores momentos. Agradezco a mis padres JAIRO PEREZ y ARALY CUESTAS, adems a mis abuelitos ANA RODRIGUEZ, JORGE CUESTAS, BLANCA PAVON, LUIS PIARPUEZAN y toda mi familia, ya que ellos fueron quienes me apoyaron moralmente, econmicamente, y sobre todo me brindaron todo su amor. A mis hermanos y familiares que me supieron dar consejos muy valiosos en los momentos ms difciles, lo cual me sirvi para salir adelante. A mi amigo y colaborador de este trabajo LEONARDO ESPINOZA, por quien pongo las manos al fuego ya que es una persona sper comprometida con su trabajo. Al Ingeniero MAURICIO CAMPAA y al Ingeniero CESAR LLUMIQUINGA quienes con su apoyo supieron guiarnos para la culminacin de este trabajo. A la universidad donde fui formado y a mis maestros que fueron ms que docentes, por impartir el conocimiento durante todo el tiempo que duro mi carrera A todas las personas que son parte de este xito.

JAIRO ANBAL PREZ CUESTAS

6


NDICE DE CONTENIDOINTRODUCCIN...... 1.1 1.2 1.3

1.

21

ANTECEDENTES ................................................................................ 21 PLANTEAMIENTO DEL PROBLEMA .................................................. 22 OBJETIVOS ..................................................................................... 24 24 1.3.1 OBJETIVO GENERAL ........................................................... 24 24 1.3.2 OBJETIVOS ESPECFICOS ................................................. 24 24

1.4 1.5 1.6 1.7

JUSTIFICACIN E IMPORTANCIA. ALCANCE. METODOLOGA......... FACTIBILIDAD.

25 27 28 30

1.7.1 Factibilidad Operativa .................................................. 30 30 1.7.2 Factibilidad Tcnica ............................................................ ..30 30 1.7.3 Factibilidad Econmica.. 1.8 2 CRONOGRAMA DE ACTIVIDADES 31 35 36 36 38 39 40 42 42 42 43 45 45

MARCO TERICO... 2.1 INTRODUCCIN A LA METODOLOGA DE DESARROLLO DE SOFTWARE.. 2.2 PROCESO UNIFICADO RACIONAL, RUP 2.2.1 2.2.2 2.2.3 2.2.4 Principios de desarrollo Ciclo de vida de RUP. Caractersticas del ciclo de vida de RUP... Disciplinas de RUP 2.2.4.1 2.2.4.2 2.2.5 Disciplina de Desarrollo... Disciplina de Soporte

Actividades que se realizan en las Fases de RUP... 2.2.5.1 Modelado del negocio.. 7


2.2.5.2 2.2.5.3 2.2.5.4 2.2.5.5 2.2.5.6 2.2.5.7 2.2.5.8 2.2.5.9 2.3

Requerimientos. Anlisis y Diseo... Implementacin. Pruebas... Despliegue. Gestin del cambio y configuracin... Gestin del proyecto. Entorno

45 46 46 47 47 48 49 49 50 50 52 52 53 55 57 57 59 64 64 65 66 66 66 67 69 70 71

IEEE 830 Especificacin de Requisitos de Software (ERS). 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 Introduccin a la ERS... Definicin de la ERS. Quin puede usar la ERS?........................................... Para qu sirve la ERS?................................................ Caractersticas de la ERS Beneficios al desarrollar la ERS. Descripcin del proceso de desarrollo de la ERS Contenido de la ERS

2.4

LENGUAJE UNIFICADO DE MODELADO (UML, UNIFIED MODELING LANGUAGE). 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 Introduccin al UML... Definicin del UML. Inconveniente en el UML.. Bloques de construccin en el UML Elementos en el UML 2.4.5.1 Elementos estructurales. 2.4.5.2 Elementos de comportamiento 2.4.5.3 Elementos de agrupacin. 2.4.5.4 Elementos de anotacin 8


2.4.6 2.4.7 2.5

Relaciones en el UML Diagramas del UML...

71 73 74 74 74 76 77 77 78 79 80 83 85 85 85 86 87 87 87 87 88 89 90 90 90 90 91

OBJECT ORIENTED HYPERMEDIA DESIGN METHODOLOGY OOHDM 2.5.1 2.5.2 2.5.3 Introduccin al OOHDM Definicin de OOHDM... Tipos de clases de navegacin en OOHDM

2.6

APLICACIN EN CAPAS 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 Introduccin a la Aplicacin en Capas Definicin de la Aplicacin en Capas.. Modelo Cliente- Servidor.. Modelo tres capas.. Modelo 4 capas..

2.7

APLICACIONES WEB 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 Introduccin a las Aplicaciones Web...... Definicin de Aplicaciones Web . Caractersticas de Aplicaciones Web. Estructura de las Aplicaciones Web Uso empresarial de las Aplicaciones Web.

2.8

SERVICIOS WEB 2.8.1 2.8.2 2.8.3 2.8.4 Definicin de Servicios Web. Ventajas de los Servicios Web. Inconvenientes de los Servicios Web Extensible Markup Language (XML)... 2.8.4.1 2.8.4.2 2.8.4.3 2.8.5 Definicin de XML. Caractersticas de XML Ventajas de XML...

Simple Object Access Protocol (SOAP). 9


2.8.5.1 2.8.5.2 2.8.6

Definicin de SOAP.. Estructura bsica de un mensaje SOAP...

91 92 93 93 93 94 94 94 96 96 97 98 100 101 101 102 102 102 103 104 104 105 105 105 107 108

Web Services Description Language (WSDL) 2.8.6.1 2.8.6.2 Definicin de WSDL. Caractersticas de WSDL

2.8.7 Universal Description, Discovery and Integration (UDDI)... 2.8.7.1 2.8.7.2 Introduccin de UDDI... Definicin de UDDI...

2.9 TECNOLOGA PARA IMPLEMENTAR SERVICIOS WEB... 2.9.1 2.9.2 2.9.3 2.9.4 2.9.5 2.9.6 2.9.7 2.9.8 Herramientas de Desarrollo.. Java Enterprise Edition (Java EE)... Modelo de desarrollo Java EE. Ventajas de Java EE. Java Development Kit (JDK) Java Virtual Machine(JVM)... Java Runtime Environment(JRE) Java Server Pages (JSP).. 2.9.8.1 2.9.8.2 2.9.8.3 2.9.8.4 2.9.9 Definicin de JSP.. Caractersticas de JSP. Funcionamiento de JSP... Ventajas de JSP..............

JavaServer Faces(JSF). 2.9.9.1 2.9.9.2 2.9.9.3 Definicin de JSF.. Caractersticas de JSF. Ventajas de JSF..............

2.10 SISTEMAS DE ADMINISTRACIN DE BASE DE DATOS.. 10


2.10.1 Definicin de Sistemas de Administracin de Base de 108 Datos. 2.10.2 MYSQL. 2.10.2.1 2.10.2.2 3. Definicin de MySQL.... Caractersticas de MySQL... 109 109 110 112 112 112 116 116 116 117 117 120 120 121 121 126 138 140 141 141 142 142 142 142 143 144

ANLISIS, DISEO Y DESARROLLO. 3.1 MODELADO DEL NEGOCIO 3.1.1 3.2 Modelo de negocio.

ESPECIFICACIN DE REQUISITOS DE SOFTWARE (ERS)... 3.2.1 Introduccin. 3.2.1.1 3.2.1.2 3.2.1.3 3.2.1.4 3.2.1.5 3.2.2 Propsito.. mbito y Alcance Definiciones, acrnimos y abreviaturas Referencias.. Visin General del documento.

Descripcin global.. 3.2.2.1 3.2.2.2 3.2.2.3 3.2.2.4 3.2.2.5 Perspectiva del producto... Funciones del Sistema.. Caractersticas del usuario Restricciones generales Suposiciones y dependencias.. 3.2.2.5.1 3.2.2.5.2 Suposiciones. Dependencias...

3.2.3

Requisitos especficos... 3.2.3.1 Requisitos de las interfaces externas.. 3.2.3.1.1 3.2.3.1.2 3.2.3.1.3 Interfaces de usuario.. Interfaces de hardware... Interfaces de software 11


3.2.3.1.4 3.2.3.2 3.2.3.3 3.2.3.4 3.2.3.5 3.2.3.6 3.2.3.7 3.2.3.8 3.2.3.9 3.2.3.10 3.3

Interfaces de comunicaciones......

144 145 175 178 179 179 180 184 184 186

Requisitos funcionales... Requisitos de desempeo. Requisitos de rendimiento. Requisitos tecnolgicos. Requisitos de seguridad............... Requerimientos lgicos para base de datos.. Limitantes de diseo.. Atributos del software.. Otros requerimientos..

CONDICIONES DE USO Y POLTICAS DEL MINISTERIO DE 187 TRABAJO Y EMPLEO DEL ECUADOR. 3.3.1 3.3.2 3.3.3 3.3.4 MISIN DEL MINISTERIO DE TRABAJO EN MATRIA 187 DE EMPLEO... USO DEL CONTENIDO REGLAS DE SEGURIDAD... 187 188

INFORMACIN DE LOS USUARIOS OFERENTES Y 189 DEMANDANTES... 3.3.4.1 3.3.4.2 3.3.4.3 Consideraciones Generales.. De la seccin Empleado. De la seccin Empresas. 190 192 195 198 202 203 205 211 213 221 227

3.4

CASOS DE USOS. 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 Caso de Uso Iniciar Sesin.. Caso de Uso Cambiar Clave Caso de Uso Administracin de Usuario Caso de Uso Administracin de Perfil Caso de Uso Administracin de Solicitante... Caso de Uso Administracin de Empresa. Caso de Uso Administracin de Vacante... 12


3.4.8 Caso de Uso Administrar Vinculacin Solicitante 233 Vacante....................................................................................... 3.4.9 Caso de Uso Administrar Vinculacin Vacante 236 Solicitante.................................................................................... 3.4.10 Caso de Uso Administrar Seguimiento 238 Solicitante. 3.4.11 Caso de Uso Administrar Seguimiento Vacante... 3.4.12 Caso de uso Administrar Reportes. 3.5 3.6 3.7 3.8 DIAGRAMAS DE ACTIVIDADES. DIAGRAMAS DE ESTADO... DIAGRAMA NAVEGACIONAL. ESTNDARES DE DISEO. 3.8.1 3.8.2 3.8.3 3.8.4 3.9 Estndares de Interfaz.. Estndares de la Base de Datos. Estndares de Reportes Estndares de Programacin... 241 244 256 265 269 270 270 270 272 272 274 274 275

DIAGRAMA LGICO DE LA BASE DE DATOS 3.9.1 3.9.2 3.9.3 3.9.4 DIAGRAMA LGICO DEL SUBMODELO KMELLONET DIAGRAMA LGICO DEL SUBMODELO PERSONAL.

DIAGRAMA LGICO DEL SUBMODELO EMPRESA Y 276 SOLICITANTE DIAGRAMA LGICO DEL SUBMODELO SEGURIDAD 277 278 278 279 280

3.10

DISEO FSICO DE LA BASE DE DATOS.. 3.10.1 DIAGRAMA FSICO DEL SUBMODELO KMELLONET. 3.10.2 DIAGRAMA FSICO DEL SUBMODELO PERSONAL... 3.10.3 DIAGRAMA FSICO DEL SUBMODELO EMPRESA Y SOLICITANTE.

3.10.4 DIAGRAMA FSICO DEL SUBMODELO 281 SEGURIDAD... 4. PRUEBAS............ 282

13


4.1 4.2

INTRODUCCIN.... EJECUCIN DE PRUEBAS 4.2.1 4.2.2 MODULO DE CONTROL DE USUARIOS MODULO DE SOLICITANTES DE EMPLEO...

282 282 282 285 288 291 293 298 298 299 301

4.2.3. MODULO DE EMPRESAS.. 4.2.4. MODULO DE SEGUIMIENTO 4.2.5 5. MODULO DE REPORTES..

CONCLUSIONES Y RECOMENDACIONES.. 5.1 5.2 CONCLUSIONES RECOMENDACIONES..

6.

BIBLIOGRAFA.

14


LISTADO DE TABLASTabla 1.7.3.1: Descripcin del Hardware . Tabla 1.7.3.2: Descripcin del Software .. Tabla 1.7.3.3: Descripcin del Humanos . Tabla 1.7.3.4: Descripcin del Valor Total ... 31 31 32 34

Tabla 3.1: Definiciones 117 Tabla 3.2: Abreviaturas y Acrnimos. Tabla 3.3: Descripcin detallada de datos del Usuario.. Tabla 3.4: Descripcin detallada de datos del Solicitante de Empleo. Tabla 3.5: Descripcin detallada de datos de la Empresa. Tabla 3.6: Descripcin detallada de datos de la Vacante Tabla 3.7: Descripcin de Caso de Uso Iniciar Sesin.. Tabla 3.8: Descripcin de Caso de Uso Cambiar Clave Tabla 3.9: Descripcin de Caso de Uso Crear Usuario. Tabla 3.10: Descripcin de Caso de Uso Buscar Usuario. Tabla 3.11: Descripcin de Caso de Uso Actualizar Usuario Tabla 3.12: Descripcin de Caso de Uso Dar de Baja Usuario Tabla 3.13: Descripcin de Caso de Uso Crear Perfil Tabla 3.14: Descripcin de Caso de Uso Asignar Perfil Tabla 3.15: Descripcin de Caso de Uso Crear Solicitante.. Tabla 3.16: Descripcin de Caso de Uso Buscar Solicitante Tabla 3.17: Descripcin de Caso de Uso Actualizar Solicitante... Tabla 3.18: Descripcin de Caso de Uso Dar de Baja Solicitante Tabla 3.19: Descripcin de Caso de Uso Crear Empresa. Tabla 3.20: Descripcin de Caso de Uso Buscar Empresa.. Tabla 3.21: Descripcin de Caso de Uso Actualizar Empresa. Tabla 3.22: Descripcin de Caso de Uso Dar de Baja Empresa.. 15 119 145 148 156 160 202 204 205 207 208 209 211 212 214 216 217 220 221 223 224 225


Tabla 3.23: Descripcin de Caso de Uso Crear Vacante.. Tabla 3.24: Descripcin de Caso de Uso Buscar Vacante Tabla 3.25: Descripcin de Caso de Uso Actualizar Vacante... Tabla 3.26: Descripcin de Caso de Uso Dar de Baja Vacante... Tabla 3.27: Descripcin de Caso de Uso Vincular a Vacante.. Tabla 3.28: Descripcin de Caso de Uso Carta de Recomendacin Tabla 3.29: Descripcin de Caso de Uso Vincular a Solicitante... Tabla 3.30: Descripcin de Caso de Uso Seguimiento Solicitante.. Tabla 3.31: Descripcin de Caso de Uso Buscar Solicitante Vinculado. Tabla 3.32: Descripcin de Caso de Uso Seguimiento Vacante.. Tabla 3.33: Descripcin de Caso de Uso Buscar Vacante Vinculada. Tabla 3.34: Descripcin de Caso de Uso Reporte Solicitantes Tabla 3.35: Descripcin de Caso de Uso Reporte Vacantes Tabla 3.36: Descripcin de Caso de Uso Reporte Perfil Solicitantes Tabla 3.37: Descripcin de Caso de Uso Reporte Perfil Vacante Tabla 3.38: Descripcin de Caso de Uso Reporte Estadstico Mensual. Tabla 3.39: Descripcin de Caso de Uso Reporte Estadstico Anual.. Tabla 3.40: Descripcin de Caso de Uso Reporte Colocados Mensual.. Tabla 3.41: Descripcin de Caso de Uso Reporte Colocados Anual.. Tabla 3.42: Estndares de Interfaz Tabla 3.43: Estndares de la Base de Datos.. Tabla 3.44: Estndares de Reportes. Tabla 3.45: Estndares de Programacin

227 229 230 232 234 235 237 238 239 241 243 245 246 248 249 250 252 253 254 270 270 272 272

16


LISTADO DE FIGURAS

Figura 2.1: Ciclo de vida de RUP... Figura 2.2: Disciplinas de RUP y su ciclo de vida... Figura 2.3: Descripcin del proceso de desarrollo de la ERS... Figura 2.4: Flujo del proceso de desarrollo de la ERS... Figura 2.5: Evolucin UML.. Figura 2.6: Clase... Figura 2.7: Interfaz Figura 2.8: Colaboracin. Figura 2.9: Caso de uso.. Figura 2.10: Clase activa. Figura 2.11: Componente Figura 2.12: Nodo. Figura 2.13: Interaccin... Figura 2.14: Mquina de Estados.. Figura 2.15: Paquetes.. Figura 2.16: Nota.. Figura 2.17: Dependencia... Figura 2.18: Asociacin Figura 2.19: Generalizacin Figura 2.20: Realizacin.. Figura 2.21: Diseo Navegacional. Figura 2.22: Cliente- Servidor. Figura 2.23: Modelo lgico tres capas.. Figura 2.24: Modelo fsico en tres capas.. Figura 2.25: Modelo en cuatro capas... Figura 2.26: Ejemplo de UDDI 17

41 44 58 58 65 67 67 68 68 68 69 69 70 70 71 71 72 72 72 72 72 77 81 83 84 95


Figura 2.27: Modelo de desarrollo de Java EE Figura 2.28: Arquitectura MVC... Figura 3.1: Modelo Global de Negocio.. Figura 3.2: Descripcin de Proceso SPE. Figura 3.3: Diagrama Contextual del Usuario Administrador Figura 3.4: Diagrama Contextual del Usuario Asesor de Empleo Figura 3.5: Diagrama Contextual del Usuario Call Center. Figura 3.6: Diagrama Contextual del Usuario Empresa. Figura 3.7: Diagrama Contextual del Usuario Solicitante.. Figura 3.8: Diagrama Contextual del Usuario Estadstica. Figura 3.9: Diagrama de Caso de Uso Iniciar Sesin. Figura 3.10: Diagrama de Caso de Uso Cambiar Clave Figura 3.11: Diagrama de Caso de Uso Administracin Usuario. Figura 3.12: Diagrama de Caso de Uso Administracin Perfil.. Figura 3.13: Diagrama de Caso de Uso Administracin Solicitante. Figura 3.14: Diagrama de Caso de Uso Administrar Empresa. Figura 3.15: Diagrama de Caso de Uso Administrar Vacante.. Figura 3.16: Caso de Uso Administrar Vinculacin Solicitante Vacante. Figura 3.17: Caso de Uso Administrar Vinculacin Vacante Solicitante. Figura 3.18: Caso de Uso Administrar Seguimiento Solicitante... Figura 3.19: Caso de Uso Administrar Seguimiento Vacante... Figura 3.20: Caso de Uso Administrar Reportes. Figura 3.21: Diagrama de actividades de Inicio de Sesin Figura 3.22: Diagrama de cambio de Contrasea.. Figura 3.23: Diagrama de actividades del Usuario. Figura 3.24: Diagrama de actividades del Solicitante de Empleo Figura 3.25: Diagrama de actividades de la Empresa

99 106 112 113 198 199 200 200 201 201 202 203 205 211 213 221 227 233 236 238 241 244 256 257 258 259 260

18


Figura 3.26: Diagrama de actividades de la Vacante.

261

Figura 3.27: Diagrama de actividades de la Vinculacin de Solicitante 262 Vacante y Vacante - Solicitante Figura 3.28: Diagrama de actividades de Seguimientos Figura 3.29: Diagrama de actividades de los Reportes. Figura 3.30: Diagrama de estados del Usuario... Figura 3.31: Diagrama de estados del Solicitante de Empleo.. Figura 3.32: Diagrama de estados de la Empresa.. Figura 3.33: Diagrama de estados de la Vacante... Figura 3.34: Diagrama Navegacional del Sistema Web de Bolsa de Empleo Figura 3.35: Diagrama Lgico del Submodelo Kmellonet.. Figura 3.36: Diagrama Lgico del Submodelo Personal... Figura 3.37: Diagrama Lgico del Submodelo Empresa y Solicitante. Figura 3.38: Diagrama Lgico del Submodelo Seguridad. Figura 3.39: Diagrama Fsico del Submodelo Kmellonet Figura 3.40: Diagrama Fsico del Submodelo Personal. Figura 3.41: Diagrama Fsico del Submodelo Empresa y Solicitante.. Figura 3.42: Diagrama Fsico del Submodelo Seguridad.. 263 264 265 266 267 268 269 274 275 276 277 278 279 280 281

19


RESUMEN

El proyecto de tesis de Ingeniera est orientado a proporcionar una herramienta informtica que permita minimizar el ndice de desempleo dentro del Ecuador. El sistema web toma en consideracin procesos de registro de solicitantes de empleo, empresas, vacantes; posteriormente el proceso de vinculacin del solicitante de empleo hacia la vacante y viceversa. Con la implementacin y utilizacin adecuada de la herramienta se optimizar el manejo de un recurso muy importante como es el tiempo, permitiendo canalizar adecuadamente dicho recuso con el fin de lograr una mejor atencin a todos los usuarios finales. El sistema Web lleva el nombre KMELLONET, Bolsa de Empleo del Ministerio de Trabajo y Empleo. Para la Metodologa de desarrollo de software se estableci usar RUP (Proceso Unificado de Desarrollo de Software) junto a UML (Lenguaje de

Modelado Unificado) debido a que al estar estrechamente relacionados permiten realizar un mejor proceso de desarrollo de software desde el levantamiento de requisitos, anlisis, diseo, implementacin, pruebas, documentacin del sistema Web. La herramienta es un sistema web distribuido desarrollado en el lenguaje programacin JAVA, que usa el patrn de diseo Modelo Vista Controlador que nos permite separar en componentes dicho sistema; posee un motor de base de datos MYSQL. El sistema cuenta con diversos mdulos , entre los ms importantes y destacados tenemos el modulo de Seguridad para restringir el acceso de usuarios y funciones dentro del Sistema, modulo de Solicitantes de Empleo para la administracin de sus datos, modulo de Empresas, para la administracin de sus datos y de las vacantes.

20


CAPTULO I

INTRODUCCIN

1.1 ANTECEDENTESEl Ministerio de Trabajo y Empleo del Ecuador es una Institucin Pblica del Estado, la cual regula el empleo de nuestro pas estableciendo polticas y reglas que beneficien tanto a trabajadores como a empresarios.

El rol de la Direccin Nacional de Empleo y Recursos Humanos dentro del Ministerio de Trabajo y Empleo es el de ser el intermediario entre la oferta y la demanda de trabajadores nacionales con el fin de que se les asesore para que obtengan un beneficio mutuo.

La Unidad del Servicio Pblico de Empleo es la encargada de receptar los formularios con la informacin de las personas que necesitan empleo, as como la informacin de los empresarios o representantes legales de las empresas para registrar tanto la empresa como las Vacantes. Adems verifica la documentacin presentada tanto por las personas y los empresarios o representantes legales de las empresas.

Uno de los mayores problemas dentro del Ministerio de Trabajo y Empleo del Ecuador especficamente en la Unidad del Servicio Pblico de Empleo es que existe una prdida de informacin entre los usuarios y los servidores pblicos de empleo.21


Esta informacin es til para que una persona pueda ser fcilmente vinculada a un puesto de trabajo y para que una Vacante de una empresa sea cubierta por un candidato apto para la misma.

Actualmente se posee un sistema de registro de datos de Solicitantes, empresas, Vacantes de empleo; pero el mismo es obsoleto debido a que fue donado y no cuenta con los requerimientos actuales de empleo para ser una herramienta eficiente y oportuna dentro de la Unidad de Servicio Pblico y Empleo.

De igual manera se carece de comunicacin

entre los Servidores Pblicos de

Empleo y el pblico en general, los mismos que deben conocer que informacin es necesaria para poder conseguir un puesto de trabajo con la asesora del Ministerio de Trabajo y Empleo del Ecuador.

1.2 PLANTEAMIENTO DEL PROBLEMAEn el Ministerio de Trabajo y Empleo se ha detectado que existe una herramienta la cual no es adecuada, eficiente, ni oportuna que agilite los registros de datos principales de los Solicitantes, empresas, Vacantes de empleo y adems que

permita la vinculacin entre el Solicitante y la Vacante de empleo que se genera en el sector productivo.

22


CAUSAS: El sistema que fue donado no cumple con los requisitos acordes a la situacin actual de empleo de nuestro pas para : Registro de datos generales del Solicitante. Registro de datos generales de la empresa. Registro de datos generales de la Vacante. Vinculacin entre el Solicitante y la Vacante de empleo.

Las personas deben acercarse hacia la matriz del Ministerio de Trabajo y Empleo o hacia sus delegaciones en todo el pas, para obtener informacin sobre : La informacin del Solicitante, que necesita ser registrada para poder acceder a un puesto de trabajo. La informacin de la empresa, que necesita ser registrada para poder ingresar datos de una Vacante de empleo. La informacin de la Vacante, que necesita ser registrada para que el empresario obtenga candidatos para cubrir sus Vacantes. La documentacin necesaria para acceder a un puesto de trabajo.

En caso de que el sistema actual siga operando dentro de la Unidad de Servicio Pblico y Empleo, no existir un eficiente y oportuno aprovechamiento del tiempo para registrar a los Solicitantes de empleo, empresas, Vacantes; adems seguir existiendo una prdida de informacin necesaria tanto para los Solicitantes de

23


empleo como para los empresarios y el nivel de desempleo en el pas no alcanzar un ndice realmente bajo.

1.3 OBJETIVOS 1.3.1 OBJETIVO GENERALImplantar un Sistema Web de Bolsa de Empleo para el Ministerio de Trabajo y Empleo y para el pblico en general, para hacer ms eficiente y oportuna la vinculacin de las personas que buscan un empleo con las Vacantes de trabajo.

1.3.2 OBJETIVOS ESPECFICOS Levantamiento de los requisitos en la Direccin Nacional de Empleo y Recursos Humanos dentro de la Unidad de Servicio Pblico de Empleo para implantar un adecuado Sistema Web de acuerdo a las necesidades de la Unidad. Publicacin de los datos de Solicitantes y empresarios respectivamente mediante una herramienta tecnolgica para la vinculacin de los mismos. Diseo de un Sistema Web de amigable presentacin bajo estndares de toda Institucin Pblica, el cual permita apoyar tanto a la calificacin de Solicitantes de empleo hacia un puesto de trabajo como tambin apoye a las empresas en la bsqueda de candidatos aptos para cubrir sus Vacantes.

24


Administrar la informacin generada por los Solicitantes de empleo y los empresarios o representantes legales de la empresa. Implementacin de un Sistema Web con la utilizacin de Software Libre.

1.4 JUSTIFICACIN E IMPORTANCIAA continuacin se detallan las razones que justifican la creacin del Sistema Web de Bolsa de Empleo: Las personas podrn acceder desde su propio hogar o desde un cyber caf hacia una Vacante de empleo sin la necesidad de ir hasta alguna delegacin del Ministerio de Trabajo y Empleo del Ecuador. Actualmente existen muchas Bolsas de Empleo dentro del pas, las cuales:: No cumplen con las leyes vigentes por el Ministerio de Trabajo y Empleo del Ecuador para la contratacin de personal por parte de una empresa. Solicitan a los empresarios alguna cantidad de dinero o comisin por cada candidato para una plaza de empleo dentro de una Vacante. La toma de datos no ser realizada por medios fsicos es decir por hojas, con lo cual se agilizarn los procesos de registros de Solicitantes, Vacantes y empresas. Existir dentro del Ministerio de Trabajo y Empleo un personal capacitado con lo cual habr un equilibrio entre los avances tecnolgicos y los avances de conocimiento de los funcionarios, que cumplan con el perfil profesional para25


desempearse de manera ptima para la vinculacin de un Solicitante de empleo hacia una Vacante. No existir demora en los trmites, de modo que se evitar la duplicidad de tareas cumplidas y excesivas prcticas burocrticas. Habr un nivel eficiente atencin a los usuarios, con lo cual existir una gran cultura de atencin al usuario. Se podr conocer datos estadsticos acerca de : El nmero de personas registradas dentro de la Bolsa de Empleo El nmero de empresas registradas dentro de la Bolsa de Empleo. El nmero de Vacantes que son generadas mensualmente en el pas por las empresas. El nmero de personas en el pas y por cada provincia son colocadas en un puesto de trabajo mensualmente. Existir una central de informacin a nivel nacional lo cual permitir que se realicen reportes estadsticos e informes ms exactos a nivel nacional. Y no por archivo como se realiza actualmente sin tener una base de datos que ayude en esta tarea. No existir un sistema burocrtico con lo cual los trmites realizados por una persona para encontrar un Vacante de empleo no llevarn un tiempo considerable. En el caso de no implementar el sistema seguir existiendo una brecha entre las personas, empresas y los funcionarios del Ministerio de Trabajo y Empleo debido a que no se optimizar el tiempo tanto para el registro de

26


datos as como para que puedan encontrar un puesto de trabajo digno y con una remuneracin adecuada.

Tomando en cuenta estas consideraciones, la presente solucin se basa en una herramienta tecnolgica de informacin, denominada Sistema Web de Bolsa de Empleo, la cual funcionar mediante una plataforma de libre distribucin, para obtener un producto que permita optimizar el tiempo para la vinculacin de las personas hacia una Vacante de empleo y viceversa de la manera ms fcil, gil y oportuna posible dentro del Ministerio de Trabajo y Empleo del Ecuador.

1.5 ALCANCEEl alcance de la presente creacin del Sistema Web de Bolsa de Empleo para el Ministerio de Trabajo y Empleo del Ecuador, abarca la utilizacin de las ltimas tecnologas de libre distribucin disponibles. Los archivos a ser manejados por el Sistema Web estarn en formato PDF. El Sistema Web que a manera general manejar las siguientes opciones: Acceso por primera vez: Registro del usuario y contrasea del usuario.

Acceso del Solicitante de Empleo: Ingreso y validacin del Solicitante de empleo. Registro y Modificacin de datos generales del Solicitante de empleo. Bsqueda y Seleccin de una Vacante acorde a sus capacidades.27


Acceso al Empresario o Representante legal de la Empresa: Ingreso y validacin del Empresario o Representante Legal de la Empresa. Registro y Modificacin de datos generales de la empresa. Registro y Modificacin de datos generales de la Vacante. Bsqueda y Seleccin de candidatos aptos para una Vacante

registrada por el empresario que cumpla los requisitos de la misma Reportes: Reportes de Solicitantes de Empleo, el reporte va a presentar informacin de los Solicitantes que han sido inscritos, enviados, y colocados. Reportes de Empresas, despliega el nmero de Vacantes de empleo existentes en las empresas. Reporte Por perfil, es decir por Solicitante y/o por Vacantes. Reporte Resumen, desplegar informacin total de acuerdo a la secuencia de opciones.

1.6 METODOLOGAPara el proceso de desarrollo del software es fundamental contar con un conjunto de conceptos, estndares y metodologas que se detallan a continuacin los cuales sern aplicados en el proyecto: Lenguaje Unificado de Modelado (Unified Modeling Language) conocido como UML, es el lenguaje que permite modelar (analizar y disear) el software el28


cual es muy utilizado en la actualidad para documentar y construir el sistema y se est convirtiendo poco a poco en un estndar, el cual da soporte a una metodologa de desarrollo tal como RUP. Proceso Racional Unificado (Rational Unified Process) conocido como RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, forman la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

RUP y UML estn estrechamente relacionados entre s, pues mientras el primero establece, describe las actividades y los criterios para conducir un sistema desde su mximo nivel de abstraccin (es decir la idea en la cabeza del cliente), hasta su nivel ms concreto (es decir un programa ejecutndose en las instalaciones del cliente) utilizando un conjunto de metodologa adaptables las necesidades de cada organizacin. El segundo ofrece la notacin grfica necesaria para representar los sucesivos modelos necesarios para la construccin del sistema que se obtienen en el proceso de refinamiento. Metodologa OOHDM u Object Oriented Hypermedia Design Methodology, para diseo de aplicaciones hipermedia y para la Web, es una mezcla de estilos de desarrollo basado en prototipos, en desarrollo interactivo y de desarrollo incremental. En cada fase se elabora un modelo orientado a objetos conceptual que recoge las caractersticas a resaltar en la misma incrementando los resaltados de la fase o fases anteriores.29


IEE830 es un estndar para las especificaciones de requisitos del software.

1.7 FACTIBILIDAD 1.7.1 Factibilidad OperativaEl Coordinador de la Unidad de Recursos Tecnolgicos del Ministerio de Trabajo y Empleo del Ecuador, como auspiciante de ste proyecto de tesis, facilitar toda la informacin que se requiera, y colaborar con todos los aspectos necesarios para la satisfactoria culminacin del mismo. Adems garantiza el compromiso de ofrecer colaboracin total con los desarrolladores, y cumplimiento en fechas y tiempos estimados para las entrevistas.

1.7.2 Factibilidad TcnicaLos desarrolladores tienen los conocimientos necesarios y suficientes acerca de: aplicaciones Web, herramientas de desarrollo a utilizar y el motor de bases de datos, para realizar el presente proyecto de tesis. Dentro de la Unidad de Tecnologa del Ministerio de Trabajo y Empleo existe un personal adecuado con conocimiento de las tcnicas de desarrollo de sistemas Web y pueden brindar el soporte necesario para el satisfactorio desarrollo del presente proyecto de tesis.

30


1.7.3 Factibilidad Econmica

Los desarrolladores del presente proyecto tendrn sus propios equipos los cuales sern entregados por la Unidad de Tecnologa del Ministerio de Trabajo y Empleo del Ecuador para que los desarrolladores no tengan ningn tipo de inconveniente y puedan culminar satisfactoriamente el proyecto de tesis.

Tabla 1.7.3.1: Descripcin del Hardware

Equipo 2 PCs 1 impresora 1 Servidor Subtotal

Valor $ 2400.00 $ 100.00 $ 18000.00 $20500.00

Tabla 1.7.3.2: Descripcin Software

Software MySql NetBeans 6.0 Subtotal

Valor $ 0.00 $ 0.00 $ 0.00

31


Tabla 1.7.3.3: Descripcin Humanos

Desarrollador Mario Leonardo Espinoza Daz Jairo Anbal Prez Cuestas Subtotal

Valor $ 600.00 x 6 meses $ 600.00 x 6 meses $7200.00

Tabla 1.7.3.4: Descripcin Valor Total

Recurso Hardware Software Recursos Humanos TOTAL

Valor $ 20500.00 $ 0.00 $ 7200.00 $ 27700.00

Con respecto al costo de hardware a los desarrolladores se les entregar los equipos dentro del Ministerio de Trabajo y Empleo del Ecuador, por lo cual no es necesario adquirirlos y no representara un gasto para que puedan desarrollar el presente proyecto de tesis. Al tratarse de un proyecto a desarrollarse para una Institucin Pblica en herramientas de Software Libre, no es necesario adquirir licencias para la implementacin del mismo.

32


Se desarrollar con dichas herramientas, debido a que el Gobierno del Ecuador para alcanzar soberana y autonoma tecnolgica, as como un significativo ahorro de recursos pblicos adopto Software Libre como poltica de Estado. El Software Libre es en mucha instancias un instrumento para alcanzar dichos objetivos, los mismos se regularon mediante el Decreto 1014, el mismo que establece: Art. 1: Establecer como poltica pblica para las entidades de administracin Pblica central la utilizacin del Software Libre en sus sistemas y equipamientos informticos.

Art. 2: Se entiende por software libre, a los programas de computacin que se pueden utilizar y distribuir sin restriccin alguna, que permitan el acceso a los cdigos fuentes y que sus aplicaciones puedan ser mejoradas.

Estos programas de computacin tienen las siguientes libertades:

Utilizacin de programa con cualquier propsito de uso comn. Distribucin de copias sin restriccin alguna Estudio y modificacin de programa (Requisito: cdigo fuente disponible) Publicacin del programa mejorado (Requisito: cdigo fuente disponible

Art. 3: Las entidades de la administracin pblica central previa a la instalacin del software libre en sus equipos, debern verificar la existencia de capacidad tcnica que brinde el soporte necesario para este tipo de software.

Art. 4: Se faculta la utilizacin de software propietario (no libre) nicamente cuando no exista una solucin de software libre que supla las necesidades33


requeridas, o cuando este en riesgo de seguridad nacional, o cuando el proyecto informtico se encuentre en un punto de no retorno.

Dentro de este marco de trabajo el desarrollo del Sistema Web de Bolsa de Empleo para el Ministerio de Trabajo y Empleo del Ecuador, es econmicamente factible de realizar.

34


1.8 CRONOGRAMA DE ACTIVIDADES

35


CAPTULO II MARCO TERICO

2.1 INTRODUCCIN A LA METODOLOGA DE DESARROLLO DE SOFTWARE Al momento de desarrollar un sistema informtico el programador se ha hecho la pregunta de Qu metodologa se debe usar para desarrollar un sistema informtico?, pues como arquitecto de software se debe tener un plano estructurado que se utilice y sirva de herramienta de apoyo.1

Todo tipo desarrollo de sistemas informticos es riesgoso y tiene complicacin

para ser controlado, pero al no tener una metodologa de por medio, lo que se tendr de resultado es usuarios insatisfechos y an mas desarrolladores insatisfechos con el desarrollo del sistema informtico. Sin embargo, muchas de las veces que se desarrolla un sistema informtico no se toma en cuenta la utilizacin de una metodologa adecuada, sobre todo al referirse a proyectos no muy grandes los cuales van comnmente hasta 3 meses en su desarrollo. Lo que se hace con este tipo de proyectos pequeos es separar rpidamente el aplicativo en procesos, cada proceso en funciones y por cada funcin determinar el tiempo estimado o aproximado en el desarrollo.

1

Tomado de http://www.informatizate.net Metodologa de desarrollo de software

36


Al tener proyectos de gran envergadura para el desarrollo, es decir proyectos grandes ah si toma sentido utilizar una metodologa de desarrollo y comenzar a buscar la ms apropiada para nuestro caso. Pero realmente en muchas ocasiones no se encuentra la ms adecuada y se termina por hacer o disear una propia metodologa, lo que por supuesto no est mal, siempre y cuando cumpla con el objetivo; pero no se est basando en una metodologa estndar lo cual sera de gran ayuda para encontrar una solucin ms adecuada para el desarrollo del sistema informtico. En diversas ocasiones se realiza el diseo del sistema informtico de manera rgida eso quiere decir con los requerimientos que el cliente solicita, de tal forma que cuando el usuario en la etapa final (etapa de prueba), solicita que se realice un cambio o solicita un requisito adicional; entonces el mismo ser muy difcil de ser realizado debido a que altera muchas cosas que no se tienen previstos. Este ser uno de los factores que ocasionan un retraso en el proyecto y por lo tanto la incomodidad en el desarrollador del sistema informtico porque no va a cumplir con el cambio solicitado y el malestar va a ser evidente en el usuario final por no tomar a consideracin su pedido. De manera tal que para evitar estos incidentes se debe llegar a un acuerdo formal con el usuario, al inicio del proyecto, de tal manera que cada cambio o modificacin no perjudique al desarrollo final del mismo. En reiteradas ocasiones el usuario final se da cuenta de las cosas que no se menciona en un principio y recin en la etapa final del proyecto se quiere adicionar

37


dichas cosas; pese a que ya anteriormente se pudo observar un prototipo del software en la etapa inicial del proyecto. Pero realmente los proyectos que si tienen problemas son los que salen del presupuesto, tienen retrasos muy grandes o los que no cumplen las expectativas del cliente. Para utilizar una metodologa que se adapte al proyecto orientado a objetos se pone a consideracin RUP junto a UML para el desarrollo del Sistema Web.

2.2 PROCESO UNIFICADO RACIONAL, RUP El Proceso Unificado Racional, 2es el proceso de desarrollo de software que permite establecer una infraestructura flexible, que junto con el Lenguaje Unificado de Modelado UML, constituyen una metodologa estndar utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. RUP divide el proyecto en proyectos ms pequeos, es decir de menos envergadura; de esta manera este modelo iterativo incremental permite que se enfoque a las necesidades del usuario, funcionalidades de los sistemas, tener refinadas las fases de desarrollo del software y la manera de construir el mismo. RUP define claramente quin, cmo y cundo se debe hacer el proyecto de

desarrollo de software debido a que RUP permite la adaptacin en contexto, para

2

Tomado de http://es.wikipedia.org/wiki/RUP

38


asegurar la alta calidad del sistema informtico de acuerdo a las necesidades de la organizacin.

2.2.1 Principios de desarrollo RUP se basa en 5 principios los cuales son de vital importancia: a. Adaptar el proceso, el proceso se debe adaptar de acuerdo a las necesidades de la organizacin. Las regulaciones del proyecto en base a su tamao, alcance, tipo son los que influirn en su diseo especfico. b. Equilibrar prioridades, se toma los requerimientos de los diversos participantes, se debe equilibrar de manera que se satisfaga el deseo de todos. c. Demostrar valor iterativamente, el proyecto se debe realizar en forma iterativa de modo que se analice la opinin de los inversores, estabilidad y calidad del software procurando siempre la refinacin del mismo. d. Elevar el nivel de abstraccin, de manera que se motive la reutilizacin de componentes dentro del software y as poder satisfacer de mejor manera los requerimientos y al usuario. e. Enfocar en la calidad, el control de calidad no se debe ejecutar al final de cada iteracin sino de una manera continua en los aspectos de la produccin.

39


2.2.2 Ciclo de vida de RUP En cuanto se refiere al ciclo de vida de RUP, esta es una implementacin del Desarrollo en Espiral, este divide el proceso de desarrollo del software en ciclos. Los cuales son la clave que posee el modelo para crear un proyecto de buena calidad. RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al culminar cada uno de ellos, estos a la vez se dividen en fases. RUP se divide en 4 fases: a. Iniciacin: Los objetivos en esta etapa son que se determine la visin y la especificacin de requerimientos, riesgos relacionados con el negocio y requerimientos. Adems establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto. Se asegura que vale la pena y si es posible desarrollar el proyecto. b. Elaboracin: El objetivo en esta etapa es que se determine la arquitectura ptima (definicin, anlisis, diseo) para proveer bases estables en el desarrollo para la siguiente fase. La arquitectura debe abarcar todas las consideraciones de mayor importancia de los

requerimientos y una evaluacin del riesgo. c. Construccin: Los objetivos en esta etapa son que se obtenga la capacidad operacional inicial y la implementacin, permitiendo clarificar los requerimientos faltantes y completar el desarrollo del sistema basado en una arquitectura base. Es una fase que se ve como de manufactura debido

40


al nfasis de la misma en la administracin de recursos y control de operaciones que permitan la optimizacin de costos, tiempo y calidad. d. Transicin: El objetivo de esta etapa es la puesta en produccin y la finalizacin del proyecto. Esta ltima fase puede ser subdividida en varias iteraciones, adems incluye las pruebas del producto para poder hacer entregable el mismo. Adems se debe realizar ajustes pequeos junto con el usuario. Aqu la retroalimentacin de los usuarios se centra en la depuracin del producto, configuraciones, instalacin y aspectos sobre la utilizacin. Al interior de cada una de estas etapas, se debe realizar varias iteraciones en nmero variable de acuerdo al tipo de proyecto que se requiera desarrollar. Adems al terminar cada fase se realiza una evaluacin para determinar si se ha cumplido o no con los objetivos de la misma. La Figura 2.1 muestra las fases del ciclo de vida del Proceso Unificado de Rational.

Figura 2.1: Ciclo de vida de RUP

41


2.2.3 Caractersticas del ciclo de vida de RUP RUP posee una forma disciplinada de asignar tareas y responsabilidades (quin, qu, cmo, cunto se realiza). Trata de implementar las mejores prcticas de Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de la arquitectura basa en componentes Control de cambios Verificacin de la calidad del software

2.2.4 Disciplinas de RUP Una disciplina es una coleccin de actividades relacionadas con un rea de atencin dentro de todo el proyecto. El grupo de actividades que se encuentran en una disciplina principalmente son una ayuda para entender el proyecto desde la perspectiva clsica de cascada. El ciclo de vida que se desarrolla por cada iteracin, se lleva bajo dos disciplinas: 2.2.4.1 Disciplina de Desarrollo Modelado de negocio: Se comprende las necesidades del negocio. Requerimientos: Se traslada las necesidades del negocio al sistema automatizado.42


Anlisis y diseo: Se toma los requerimientos adaptndolos a la arquitectura de software. Implementacin: Se crea el sistema informtico que se ajuste a la arquitectura y que posea el comportamiento deseado. Pruebas: Se asegura que el comportamiento deseado sea el ptimo y que todos los parmetros establecidos estn presentes. Despliegue: Se realiza lo necesario para la salida del proyecto.

2.2.4.2 Disciplina de Soporte Gestin del cambio y configuraciones: Se guarda todas las versiones del proyecto. Gestin del proyecto: Se administra horarios y recursos. Ambiente: Se administra el ambiente de desarrollo.

A continuacin en la Fig. 2. 2 se muestra las disciplinas de RUP dentro del ciclo de vida del mismo:

43


3

Figura 2.2: Disciplinas de RUP y su ciclo de vida

Adems la Figura 2.2 en el eje horizontal se representa el tiempo y los aspectos del ciclo de vida del proceso. Representa el aspecto dinmico del proceso a travs de fases, iteracin y productos intermedios. Mientras que en el eje vertical se representa las disciplinas que agrupan actividades por su naturaleza. Representa el aspecto esttico del proceso a travs de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles.

3

Tomado de http://commons.wikimedia.org/wiki/File:Rup_espanol.gif

44


2.2.5 Actividades que se realizan en las Fases de RUP RUP establece nueve actividades que se efectan en cada fase del proyecto: 2.2.5.1 Modelado del negocio En esta etapa, se definen cuales son los procesos y procedimientos que van a estar en el escenario para el cual se va a desarrollar el software, es decir la estructura y dinmica de la organizacin. Esto permite identificar los casos y los procesos del negocio que van a ser automatizados, la relacin que debe existir entre la ingeniera de software y el negocio permite tener un enfoque claro y preciso que es lo que quiere el cliente con el software. El modelado del negocio se enfoca en conocer el funcionamiento actual de los procesos, entender la estructura y la dinmica del negocio que permite dar soluciones con beneficios en la organizacin.

2.2.5.2 Requerimientos El anlisis de requerimientos es la etapa ms importarte del desarrollo del software, aqu se establece lo que el sistema debe hacer (Especificacin de Requisitos), se determinan las condiciones o capacidades que debe cumplir el sistema que se va a disear.

45


El requerimiento se puede entender como la descripcin informal de las necesidades y deseos que tiene el usuario final respecto al software que desea. Despus de que se obtiene cada uno de los requerimientos, se debe plasmar la Especificacin de Requerimientos del Software ERS, IEEE 830.

2.2.5.3 Anlisis y Diseo En la etapa de anlisis y diseo se debe trasladar cada uno de los

requerimientos documentados en la Especificacin de Requerimientos del Software (ERS), los mismos que deben ser transformados a diseos del sistema con el fin de alcanzar una arquitectura robusta para el software. Se debe adaptar el diseo para que sea consistente con el entorno de implementacin. Se debe usar los diagramas de casos de uso, secuencia, estados, clases, de colaboracin y el modelo de despliegue; se define con cada uno de estos diagramas la arquitectura del sistema.

2.2.5.4 Implementacin En esta etapa se debe implementar clases y objetos, los mismos que debern dar como resultado un sistema de calidad, para ello se deber realizar la planificacin de manera tal que se implemente cada subsistema.

46


A cada subsistema se le deber realizar pruebas y validaciones que garanticen el fiel cumplimento de las necesidades funcionales que se requieren por el usuario final.

2.2.5.5 Pruebas En la etapa de pruebas se deber verificar la integracin de los componentes mediante pruebas de integracin, los mismos que debern verificar que todos los requerimientos estn implementados. Las pruebas aseguran que los defectos, errores sean detectados y corregidos a tiempo, debido a que si no hay correccin de los mismos, el sistema representar costos elevados al momento de la correccin en un futuro, antes de la distribucin final del software. Esta etapa se enfoca en la evaluacin y aseguramiento de la calidad del software final, mismo que ser sometido a pruebas. Se valida y prueba las suposiciones hechas durante el diseo y la especificacin de requisitos.

2.2.5.6 Despliegue La etapa del despliegue se basa en realizar las pruebas al software final, antes de ser distribuido o ponerlo en produccin, se asegura que el mismo

47


este preparado para el cliente, procediendo as su entrega y recepcin por el cliente. Adems aqu se realiza la migracin de datos para dar paso a la distribucin del software a cada uno de los usuarios finales, lo que implica que el software tenga la aprobacin en su entorno final. Se determina tambin el proveer de asistencia tcnica a los usuarios, es decir se capacita en el manejo del nuevo aplicativo.

2.2.5.7 Gestin del cambio y configuracin Esta etapa consiste en controlar los cambios y mantener la integridad del producto. Los cambios debern ser previamente analizados para ver si se pueden realizar. En cada ocasin que se realice un cambio en los requerimientos del software, se deber documentar. Los controles sobre los cambios son de mucha ayuda ya que evitarn las confusiones como la compostura de algo que ya se haba arreglado etc., y de esta manera se asegurara que los resultados de los cambios efectuados no generen conflictos como: Actualizacin simultanea. Notificacin limitada. Versiones mltiples.

48


2.2.5.8 Gestin del proyecto En esta etapa se deber vigilar el fiel cumplimiento de los objetivos, gestin de riesgos y restriccin para la entrega del proyecto que satisfaga las necesidades tanto de los clientes (pagan el dinero) y los usuarios finales (utilizan el sistema). De esta manera se mantendr un conocimiento global de la evolucin del proyecto. Adems en esta etapa se lograr la mejora en el manejo de una entrega exitosa del software. Esta etapa proveer pautas para: Administrar proyectos de software intensos. Planear, dirigir personal, ejecutar accin y supervisar proyectos. Administrar el riesgo.

2.2.5.9 Entorno En esta etapa se enfocan las actividades necesarias que permitan la configuracin del proceso del proyecto, se determina el ambiente bajo el cual se va a desarrollar el proyecto. Se establece las herramientas, proceso y mtodos que darn soporte al equipo de desarrollo para la implementacin de la aplicacin.

49


2.3 IEEE 830 Especificacin de Requisitos de Software (ERS)

2.3.1 Introduccin a la ERS En el desarrollo de los sistemas informticos es comn encontrar algn tipo de problema al no seguir estndares para el diseo del mismo, una vez que se detecten los problemas, los cuales afectarn a la calidad del producto/ servicio, o la satisfaccin del usuario, es conveniente analizar si hay alguna manera de resolver dichos problemas mediante el uso de alguna tecnologa de informacin o estndar. Si el problema se resuelve con alguna tecnologa o estndar de metodologa de desarrollo de software; es difcil conocer el origen de cada problema, la mejor opcin es relacionar la causa del problema con: Almacenamiento de datos Procesamiento de datos Transferencia de datos Si el problema se resuelve por mtodos ms econmicos sin necesidad de invertir en ningn tipo de tecnologa ser mucho mejor para la organizacin. Pero si el problema se relaciona con alguno de los tres puntos anteriormente dichos, es conveniente definir los requisitos especficos dicho sea de paso son las necesidades que se tenga para el desarrollo del software.

50


Se puede definir claramente los requisitos que sern tomados para el desarrollo del software de una manera tal que satisfaga ambas partes tanto para el usuario como para el desarrollador del software, de esta manera se puede facilitar: La estimacin de su costo. La estimacin del tiempo para el anlisis, diseo y desarrollo. La decisin para el desarrollo por nuestra parte, el outsourcing o definitivamente la compra del software. La bsqueda de algn proveedor que venda el software de acuerdo a las necesidades que tiene la organizacin. La definicin de los requisitos de software puede parecer una tarea muy sencilla, pero es comn que el usuario o el desarrollador cometan errores u omisiones importantes. Adems muchos de los problemas en los sistemas informticos se deben a una inadecuada especificacin de requerimientos, Para la definicin de los requerimientos de un software se puede apoyar en una norma que permita realizar preguntas pertinentes a la IEEE 830; esta norma le servir al usuario y al desarrollador del software, para que haya un consenso en el software y despus no se encuentre ningn tipo de inconveniente en el desarrollo final del software.

51


2.3.2 Definicin de la ERS La IEEE 830 es la Especificacin de Requerimientos del Software (ERS), cuyo propsito principal es el proporcionar la ayuda pertinente para la elaboracin del documento muy til de Especificacin de Requerimientos de Software. Esta Especificacin es esencialmente una gua para la redaccin del documento de especificacin de requerimientos del software. La Especificacin (IEEE, 1990) dice que el ERS 4Documento que define, de forma completa, precisa y verificable, los requisitos, el diseo, el

comportamiento u otras caractersticas de un sistema o componente de un sistema.

2.3.3 Quin puede usar la ERS? El usuario que vaya a definir requerimientos o caractersticas del software que necesita. El desarrollador (interno o externo), que haga un software a la medida de dicho proyecto. El desarrollador que realiza el software de paquete, es decir el que va a ser vendido de forma masiva.

4

IEEE Std 610.12-1990 Standard Glossary of Software Engineering Terminology

52


2.3.4 Para qu sirve la ERS? La ERS sirve para que: Un cliente describa claramente las necesidades que tiene, es decir lo que quiere del software. Un proveedor entienda claramente lo que el usuario/ cliente quieren del software. Se establezca la base para el contrato del desarrollo o de compra/venta. Se reduzca el esfuerzo de anlisis, diseo y desarrollo; de manera que se evite realizar de nuevo el trabajo ya hecho. Se tenga una base o una referencia para realizar las pruebas del software solicitado o para realizar la validacin del mismo. Para realizar nuevas versiones, que mejoren el sistema ya establecido. En un proyecto software los requerimientos son las necesidades del producto que se va a desarrollar. En la fase del anlisis de requerimientos o requisitos se debe tener claras las necesidades de los usuarios, las cuales deben ser documentadas. Como el producto de esta fase se obtiene el documento de la especificacin de requisitos. El documento que se obtiene es el que proporciona las pautas necesarias para el desarrollo de un conjunto de requerimientos que satisfacen las necesidades especficas de una organizacin. En este documento se encuentran las

53


condiciones necesarias para incorporar conceptos operaciones, restricciones de diseo y requerimientos de la configuracin del diseo. La especificacin de requerimientos de software es una de las tareas ms importantes en el ciclo de vida del desarrollo de software, debido a que en esta se determina los planos que tendr el software. Adems contiene la descripcin de lo que el software debe hacer, en trminos de las interacciones del sistema o las interfaces con sus ambiente externo. La especificacin de requerimientos del software describe las entradas, salidas y las relaciones requeridas entre las entradas y las salidas, en este entorno el usuario es el ente o agente activo que proporciona la informacin necesaria de los procesos que se llevan a cabo dentro de la institucin. Los requisitos descritos en el documento, permiten que los usuarios y los desarrolladores los entiendan sin ningn tipo de dificultad, por lo tanto el lenguaje utilizado en la documentacin es claro y fcil de comprender. Se debe tener en cuenta que la especificacin de requerimientos del software no describe ningn tipo de detalle del diseo, metodologa de desarrollo del software, modo de implementacin o gestin del proyecto. Al no realizar una buena especificacin de requisitos del software, los costos del desarrollo se pueden ver incrementados al realizar cambios durante el desarrollo del software, esto llevara a un gran desperdicio de recursos de las dos partes involucradas en el desarrollo del software.

54


2.3.5 Caractersticas de la ERS Correcto El ERS debe ser correcto si los requerimientos escritos son aquellos que el software deber cumplir, no hay un mtodo para determinar si el ERS es correcto, lo importante es que se pida lo que realmente se necesita. Completa De manera que la ERS debe detallar todas las funcionalidades que debe cumplir el sistema, cuya finalidad es tener claro el alcance que tendr el software. No ambigua En el documento los requerimientos del software deben estar detallados en forma clara y precisa, de modo que cada requisito debe tener una sola interpretacin y se evite los malos entendidos de dichos requisitos. Verificable Al momento de poder comprobar cada uno de los requisitos del software mediante procesos no excesivamente costos en las que interviene una persona o un equipo, se puede decir que el ERS es verificable. Consistente Cuando los requerimientos no poseen ningn tipo de contradiccin ni redundancias, se puede decir que el ERS es consistente.

55


Ordenado con base en importancia y/o estabilidad Cada requerimiento especificado deber tener alguna identificacin (nmero, letra, secuencia alfanumrica) para indicar su grado de importancia o estabilidad. Fcil de modificar La ERS es fcil de modificar, si ante cualquier tipo de cambio que se presente en los requerimientos, la realizacin no implicara el desperdicio de tiempo; es por esto que se deber contar con un tipo de estructura consistente con presencia de un ndice y existencia de referencias cruzadas. Facilidad para identificar el origen y consecuencia de cada requisito La ERS debe especificar si el requisito viene tomado como consecuencia de uno anterior, u originado de un resulto posterior. Esto implica que el trabajo de los desarrolladores se facilite al momento que se deba realizar el mantenimiento del software. Facilidad de uso durante las fases de explotacin y

mantenimiento La ERS debe ser elaborada tomando en consideracin que la explotacin y mantenimiento es distinto al del desarrollo, por tal razn los requerimientos deben ser documentados, para que en un futuro se pueda modificar sin mayor dificultad.

56


2.3.6 Beneficios al desarrollar la ERS Permite que el cliente y el desarrollador determinen de manera clara y precisa las necesidades del software que se va a desarrollar, para que en el futuro se implemente sin ningn tipo de dificultad. Ayuda a que todas las fases del ciclo de vida del software se desarrollen de manera eficiente.

Facilita al usuario y al desarrollador en la deteccin de problemas para poder corregirlos, cuidando que los costos sean relativamente econmicos. Es una base para calificar la calidad del sistema y verificar que hay cumplimiento en las necesidades o caractersticas que son solicitadas por los usuarios. Es una proteccin para el equipo desarrollador, proporciona una lnea de referencia para conocer cules son las capacidades del software, con lo cual no se puede exigir una funcionalidad que no se haya especificado en la ERS.

2.3.7 Descripcin del proceso de desarrollo de la ERS La Figura 2.3 muestra el proceso de desarrollo en la Especificacin de Requerimientos del Software. Se muestra la relacin que tienen entre los tres agentes externos cliente, ambiente y comunidad tcnica o desarrolladores.57


5

Figura 2.3: Descripcin del proceso de desarrollo de la ERS

En la figura 2.4 se observa el flujo de proceso que existe para obtener los requerimientos del usuario; para ello interacta el cliente con los

desarrolladores, analistas y diseadores.

6

Figura 2.4: Flujo del proceso de desarrollo de la ERS

5

Tomado de http://iteso.mx/~juanjo/materiales/IEEE_Std1233_1998_esp_desarrollo_de_especificacion_de_reque.pdf

58


2.3.8

7

Contenido de la ERS

Entre el contenido que abarca el ERS estn: 1. INTRODUCCIN

1.1. Propsito Propsito del documento. Audiencia a la que va dirigido. 1.2. Alcance Identificacin del producto mediante un nombre. Qu hace y no hace el producto. Aplicaciones del software: beneficios, objetivos y metas. 1.3 .Definiciones, acrnimos y abreviaturas Dar las definiciones de todos los trminos, acrnimos (siglas) y abreviaturas que son pertinentes a entendimiento de la ERS. 1.4. Referencias Ofrecer lista completa de todos los documentos que se haga referencia. Identificar cada documento segn su titulo, nmero de reporte, fecha y organizacin. Especificar las fuentes de las que se obtienen los documentos referenciados.

67

Tomado de www.lsi.us.es/docencia/get.php?id=2085

Tomado de http://www.infor.uva.es/~descuder/proyectos/ipo/requi.htm

59


1.5. Visin general Descripcin del contenido del resto del documento. Explicar la organizacin del documento. 2. DESCRIPCIN GENERAL 2.1. Perspectiva del producto Describir el software en perspectiva con otro software relacionados con similitudes y diferencias. Indicar si es un producto independiente o parte de un sistema mayor. Diagramas de bloques que describan relaciones del software requerido y el sistema grande. En diagramas de bloque se muestran los componentes principalmente del sistema grande y su relacin jerrquica. Interfaces del usuario, es decir lo que est entre el usuario y el software. Interfaces de hardware, es decir especificacin de que hardware utilizara el software. Interfaces del software, es decir que otros software se necesitarn para que funcione el software requerido. Interfaces de comunicacin, es decir que tecnologa de redes se usa para la comunicacin de la informacin. Restricciones de memoria, es decir especificar si hay lmites a memoria.

60


Operaciones o Modos de operacin de los distintos grupos de usuarios o Perodos de operaciones interactivas y automticas o Funciones respaldo del procesamiento de datos o Operaciones de backup y recuperacin

Adaptacin a un lugar especfico Indicar cualquier dato o secuencia de inicializacin especfico de cualquier lugar, modo de operacin. Caractersticas que se deben modificar para una

instalacin en particular.

2.2. Funciones del producto Sumario de las funciones principales, pero sin mencionar los detalles requeridos en dichas funciones. 2.3. Caractersticas de usuario Se debe describir caractersticas respecto nivel educativo,

experiencia profesional, capacidades tcnicas. 2.4. Restricciones Informacin sobre posibles limitantes que se deben respetar por los diseadores, as como: polticas regulatorias, limitante hardware, interfaz hacia otra aplicacin, funcionamiento paralelo, auditoria de software, protocolos de comunicaciones, consideracin de seguridad fsica y lgica.

61


2.5. Suposiciones y dependencias Cada uno de los factores con los que se afecta a los requerimientos especificados. 2.6. Requisitos para futuras versiones del sistema Son los requerimientos con los que se puede atender hasta versiones futuras del sistema.

3. REQUISITOS ESPECFICOS 3.1. Requisitos de interfaz externo Estos son la descripcin a detalle de todas las entradas y salidas del sistema, las mismas que se deben complementar con las: Interfaces de usuario. Interfaces hardware. Interfaces software. Interfaces de comunicaciones. 3.2. Requisitos funcionales Define los requerimientos funcionales, acciones fundamentales del sistema mediante el procesamiento de las entradas, salidas y la generacin de las salidas. Flujos de informacin. Descripcin de procesos. Diccionario de datos.

62


3.3. Requisitos de desempeo Define los requerimientos estticos y dinmicos que debe tener el software mediante la interaccin con el usuario. 3.4. Restricciones lgicos para base de datos Define la frecuencia de uso de la informacin, capacidad de acceso, entidades y relaciones, limitaciones de integridad, requisitos de persistencia. 3.5. Restricciones de diseo Sealar si el hardware limita al diseo de interfaz y de datos, sealar que otros estndares se deben aplicar y que limiten funciones de diseo. 3.6. Atributos de sistemas software Define como se dar cumplimiento de atributos en cuanto tiene que ver con la: Confiabilidad Disponibilidad Seguridad Facilidad de mantenimiento Portabilidad 3.7. Otros requisitos Define la inclusin de requerimientos adicionales, tales como: Diagramas de flujo de datos. Diccionario de datos.

63


2.4 LENGUAJE UNIFICADO DE MODELADO (UML, UNIFIED MODELING LANGUAGE) 2.4.1 Introduccin al UML El desarrollo de UML se comienza a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empiezan a unificar sus metodologas. La Metodologa de Grady Booch para la descripcin de conjuntos de objetos y relaciones y la Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique), se unificaron, para ms tarde a finales de 1995, permitir a Ivar Jacobson y su compaa Objectory que pueda incorporar a Rational en su unificacin, aportando el mtodo OOSE (Object- Oriented Software Engineering). UML se fomenta y se acepta como estndar desde la formacin de OMG (Object Management Group). En 1997 UML 1.1 se aprueba por la OMG y se convierte en la notacin estndar para el anlisis objetos. En Septiembre de 2001 se publica la especificacin de la versin 1.4. Es importante recalcar que slo se trata de una notacin, es decir, de una serie de reglas y recomendaciones para representar modelos. UML no es un proceso de desarrollo, es decir, no describe los pasos sistemticos a seguir para desarrollar software. UML slo permite documentar y especificar los y diseo orientado a

64


elementos creados mediante un lenguaje comn describiendo modelos. En la Figura 2.5, se observa el desarrollo de UML y sus versiones en los aos dados.

8

Figura 2.5: Evolucin UML

2.4.2 Definicin del UML9

UML es un lenguaje estndar de modelado de sistemas, que proporciona

los planos de la arquitectura del sistema, puede utilizarse para visualizar, especificar, construir, y documentar procesos de negocios, funciones del sistema, lenguajes de programacin, esquemas de bases de datos y componentes de software reutilizables. UML es un lenguaje que ayuda en la interpretacin de grandes sistemas mediante grficos o mediante texto obteniendo modelos explcitos que permiten la comunicacin durante el desarrollo ya que al ser estndar, los8 9

Tomado de http://es.wikipedia.org/wiki/UML Tomado de http://es.wikipedia.org/wiki/UML

65


modelos pueden ser interpretados por personas que no participaron en su diseo (e incluso por herramientas) sin ninguna ambigedad. En este contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos.

2.4.3 Inconveniente en el UML Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc., los ejemplos aislados, el monopolio de conceptos, tcnicas y mtodos en torno a UML.

2.4.4 Bloques de construccin en el UML UML consta de tres clases de bloques: los elementos, las relaciones y los diagramas. Los elementos son las abstracciones de un modelo; las relaciones vinculan los elementos entre si y los diagramas agrupan colecciones de elementos.

2.4.5 Elementos en el UML Hay cuatro tipos de elementos en UML: Elementos estructurales. Elementos de comportamiento. Elementos de agrupacin.

66


Elementos de anotacin.

2.4.5.1 Elementos estructurales Estos son en la mayora partes estticas de un modelo, que representan elementos conceptuales o fsicos. Hay siete tipos de elementos estructurales a continuacin se describe a los mismos:

Clase: Descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Se

representa como en la Figura 2.6.

10

Figura 2.6: Clase

Interfaz: Es una coleccin de operaciones que especifican un servicio de una clase o componente, se lo representa con un circulo con nombre como en la Figura 2.7.

Figura 2.7: Interfaz10

Francisco Mora (DCCIA, Universidad de Alicante, 2002)

67


Colaboracin: Una implementacin de patrones que forman un sistema. Una colaboracin se representa como se observa en la Figura 2.8.

Figura 2.8: Colaboracin

Caso de uso: Es una descripcin de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de inters para un actor ejecutor. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo, se representa como en la Figura 2.9.Verificacin de Usuario

Figura 2.9: Caso de uso

Clase activa: Es una clase cuyos objetos tienen uno o ms procesos concurrentes. Grficamente una clase activa se

representa como muestra la Figura 2.10.

Figura 2.10: Clase activa68


Componente: Es una parte fsica de un sistema que ofrece un conjunto de interfaces y proporciona la implementacin de dicho conjunto. Representa tpicamente el empaquetamiento fsico de diferentes elementos lgico, como clases interfaces y

colaboraciones. Grficamente un componente se representa como se muestra en la Figura 2.11.

Figura 2.11: Componente

Nodo:

Elemento

fsico

que existe en tiempo de ejecucin y

representa un recurso computacional, que dispone de algo de memoria y, con frecuencia, capacidad de procesamiento. Se representa como en la Figura 2.12.

SERVIDOR

Figura 2.12: Nodo

2.4.5.2 Elementos de comportamiento Son las partes dinmicas de los modelos UML, estos son los verbos de un modelo que representan la funcin sobre tiempo y espacio. Hay dos tipos principales de elementos de comportamiento.69


Interaccin: Intercambio de mensajes entre objetos en un contexto particular y con un propsito especfico. Se representa como se muestra en la Figura 2.13.

Figura 2.13: Interaccin

Mquina de estados: Es una secuencia de estados por las que pasa un objeto o una interaccin en respuesta a eventos. Se representa como se muestra en la Figura 2.14.

ESPERANDO

Figura 2.14: Mquina de Estados

2.4.5.3 Elementos de agrupacin Son las partes de organizacin de los modelos UML. Estos son cajas dentro de las cuales un modelo puede ser descompuesto. Paquete: Sirve para organizar elementos en grupos. Un paquete es puramente conceptual (slo existe en tiempo de desarrollo). Se representa como se muestra en la Figura 2.15.

70


Figura 2.15: Paquetes

2.4.5.4 Elementos de anotacin Son las partes explicativas de los modelos de UML. Son los comentarios que se pueden aplicar para describir, iluminar y remarcar algunos elementos de un modelo. El principal elemento es la llamada nota. Una nota es simplemente un smbolo para mostrar restricciones y comentarios junto a un elemento o una coleccin de elementos. Se representa como se muestra en la Figura 2.16.

Figura 2.16: Nota 2.4.6 Relaciones en el UML Hay cuatro tipos de relaciones en UML. Dependencia. Asociacin. Generalizacin Realizacin

71


Dependencia: Es una relacin entre dos elementos, tal que un cambio en uno puede afectar a la semntica del otro. Se representa como se muestra en la Figura 2.17.

Figura 2.17: Dependencia

Asociacin: Es una relacin estructural que describe un conjunto de conexiones entre objetos, Se representa como se muestra en la Figura 2.18.

Figura 2.18: Asociacin

Generalizacin: Es una relacin taxonmica entre un elemento ms general (el padre) y un elemento ms especfico (el hijo). Se usa tanto en diagramas de clases como en diagramas de casos de uso. Se representa como se muestra en la Figura 2.19.

Figura 2.19: Generalizacin

Realizacin: Un clasificador especifica un contrato que otro garantiza que cumplir. Se representa como se muestra en la Figura 2.20.

Figura 2.20: Realizacin72


2.4.7 Diagramas del UML Un diagrama es la representacin grfica de un conjunto de elementos. Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema, Hay varios tipos de diagramas los cuales se muestran en diferentes aspectos de las entidades representadas:

Diagramas de Estructura: Son los principales elementos que deben existir en el sistema modelado. Diagrama de clases Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (UML 2.0) Diagrama de despliegue Diagrama de paquetes

Diagramas de Comportamiento: Su principal funcin es observar lo que sucede en el sistema modelado. Diagrama de actividades Diagrama de casos de uso Diagrama de estados

73


Diagramas de Interaccin: Se los llama tambin diagramas de comportamiento, su funcin es observar el flujo de control y de datos entre los elementos del sistema modelado Diagrama de secuencia Diagrama de colaboracin Diagrama de tiempos (UML 2.0) Diagrama de vista de interaccin (UML 2.0).

2.5 OBJECT ORIENTED HYPERMEDIA DESIGN METHODOLOGY OOHDM

2.5.1 Introduccin al OOHDM Normalmente al momento de desarrollar aplicaciones web, el programador no pone la atencin debida a las actividades tales como el modelado o anlisis, diseo, implementacin, prueba y mantenimiento, razn por la cual, si no se pone especial nfasis en stos temas se convierten en obstculos dentro del proceso de desarrollo de la aplicacin.

2.5.2 Definicin de OOHDM OOHDM como tcnica de diseo de aplicaciones hipermedia, propone un conjunto de tareas que pueden resultar costosas a corto plazo, pero a mediano y largo plazo reducen notablemente los tiempos de desarrollo al tener como74


objetivo principal la reusabilidad de diseo, y as simplificar el costo de evoluciones y mantenimiento. El uso de una metodologa de diseo es de vital importancia para el desarrollo de aplicaciones Web. OOHDM es una metodologa que se enfoca en el proceso incremental, iterativo y que se basa en prototipos. Los modelos orientados a objetos se construyen en cada paso en el cual se mejora a los modelos diseados en iteraciones anteriores y consta de las siguientes fases: Fase Conceptual, Fase Navegacional, Fase de Interfaz Abstracta, Fase Implementacin Para el desarrollo del proyecto slo se utilizar la fase de Diseo Navegacional. En OOHDM, la navegacin se considera un paso crtico en el diseo de una aplicacin de hypermedia. Un Modelo de navegacin se construye como una vista ms de un modelo conceptual y permite la construccin de modelos diferentes segn los perfiles diferentes de los usuarios. Cada modelo de navegacin proporciona una vista "Subjetiva" del modelo conceptual El diseo de navegacin es expresado en dos esquemas: Esquema de clases navegacionales. Esquema de contextos navegacionales.75


2.5.3 Tipos de clases de navegacin en OOHDM En OOHDM, existen algunos tipos pre-definidos de clases de navegacin: nodos, links o enlaces, y estructuras de acceso. Nodos: Los nodos son contenedores bsicos de informacin de las aplicaciones hipermedia. Los nodos contendrn tanto atributos de tipos bsicos (donde se pueden encontrar tipos como imgenes o sonidos) y enlaces. Enlaces: Los enlaces reflejan la relacin de navegacin que puede explorar el usuario. Las clases enlaces sirven para especificar los atributos de enlaces y estos a su vez para representar enlaces entre clases nodos o incluso entre otros enlaces. En cualquier caso, el enlace puede actuar como un objeto intermedio en un proceso de navegacin o como un puente de conexin entre dos nodos. Estructuras de Acceso: Las estructuras de acceso actan como ndices o diccionarios que permiten al usuario encontrar de forma rpida y eficiente la informacin deseada. Los mens, los ndices o las guas de ruta son ejemplos de estas estructuras. Contexto Navegacional: Para disear bien una aplicacin hipermedia, hay que prever los caminos que el usuario puede seguir, as es como nicamente se podr evitar informacin redundante o que el usuario se pierda en la navegacin. En OOHDM un contexto navegacional est compuesto por un conjunto de nodos, de enlaces de clases de contexto y de otros contextos navegacionales.

76


Clase de

Contexto: Es otra clase

especial

que sirve para

complementar la definicin de una clase de navegacin. Por ejemplo, sirve para indicar qu informacin est accesible desde un enlace y desde dnde se puede llegar a l. Un Diseo Navegacional se representa como en la figura 2.21.

Figura: Diseo Navegacional.

11

Figura 2.21: Diseo Navegacional

2.6 APLICACIN EN CAPAS

2.6.1 Introduccin a la Aplicacin en Capas12

La estrategia tradicional para desarrollar aplicaciones compactas causa una

enorme cantidad de desafos de integracin en las aplicaciones empresariales,11

Tomado de http://es.wikipedia.org/wiki/OOHDM

77


por lo general estas aplicaciones suelen tener importantes problemas de escalabilidad, disponibilidad, seguridad, integracin. Una manera de solucionar este tipo de problemas que se detallan, ha sido la generalizacin de la divisin de las aplicaciones en capas que normalmente son tres. Una aplicacin en capas requiere la utilizacin de una tcnica de programacin multinivel, es decir separa los componentes primarios de la aplicacin para programarlos o codificarlos por separado y despus unirlos en tiempo de ejecucin, por lo tanto una capa es un conjunto de componentes de software.

2.6.2 Definicin de la Aplicacin en Capas Esta tcnica de programacin permite crear aplicaciones a nivel empresarial gracias a la fcil administracin que implica la separacin de los componentes de la aplicacin en capas, debido a que se separa la lgica de negocios de la lgica de diseo, de esta manera se separa el cdigo fuente segn su funcionalidad dentro de la aplicacin. El diseo de una aplicacin en capas, permite a cada capa mostrar servicios que otras aplicaciones o capas pueden consumir. Una aplicacin se divide en varias capas, lo cual proporciona una separacin adecuada de la funcionalidad, adems permite tener mayor escalabilidad dando como resultado aplicaciones robustas.12

Tomado de http://oness.sourceforge.net/proyecto/html/ch03s02.html

78


Una de las mayores ventajas de realizar una aplicacin en capas es el alto grado de encapsulamiento que maneja por lo tanto permite la reutilizacin de sus componentes para el desarrollo de nuevas aplicaciones, que brinda un soporte y mantenimiento ms sencillo. A continuacin se detalla las aplicaciones n capas utilizados comnmente:

2.6.3 Modelo Cliente- Servidor El modelo cliente servidor13

es un modelo de computacin en el

procesamiento requerido para ejecutar una aplicacin o conjunto de aplicaciones relacionadas se divide entre dos o ms procesos que cooperan entre si1. Comnmente la mayor parte del trabajo pesado se ejecuta en el proceso llamo servidor y el (los) procesos(s) cliente(s) solo se ocupan de la interaccin con el usuario, aunque no siempre es de este manera. Los clientes solicitan los servicios y los servidores son los que se encargan de proporcionarlos. Generalmente un servidor ejecuta mltiples peticiones al mismo tiempo, como se observa en la Fig. 2.22.

13

Datapro Client/Server Analyst, cliente server computing : emerging trends, solutions and strategies, 1994.

79


14

Figura 2.22: Cliente- Servidor

El modelo cliente servidor es la base sobre la que se sustentan las aplicaciones en tres, cuatro, n capas. En cada una de estas, se maneja el concepto de ejecutar peticiones para obtener una respuesta. Cliente: se puede decir que consiste en ser la capa donde el usuario interacta con su PC. Servidor: es la capa donde se encuentra el servidor de la base de datos.

2.6.4 Modelo tres capas Este tipo de modelo sucesor del modelo cliente servidor, la cual implementa entre otras cosas la encapsulacin de las reglas del negocio asociadas con el sistema y realiza la separacin de la presentacin y del cdigo de la base de datos. Adems este modelo es una forma lgica de agrupar los componentes que se crea, el cual est basado en el concepto de que todos los niveles de la14

Tomado de http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/cliente-servidor.html

80


aplicacin, son una coleccin de componentes que proporciona servicios entres si o a otros niveles adyacentes.

15

Figura 2.23: Modelo lgico tres capas

Como podemos observar el modelo tres capas cuenta con las siguientes capas: Capa de presentacin: Capa que muestra la interfaz de usuario (formularios Web, paginas HTML) y controles visuales (buttons, textBox, comboBox, dataGrids); son elementos que facilitan al usuario el uso del sistema. Capa de negocio: Capa que se encarga de centralizar el modelo, es decir el cdigo que define las reglas del negocio (clculos, validaciones). Provienen de los procesos encontrados dentro de la etapa de anlisis. Capa de acceso de datos: Capa que se encarga de permitir el acceso a las fuentes de datos (Base de Datos).15

Tomado de http://www.ptbsl.com/diferencial_metodologa_1.php#metodologa

81


Con las aplicaciones tres capas, se obtiene una robusta y potente arquitectura que otorga varias ventajas: No existe una confusin entre las capas loicas y las fsicas que corresponden al lugar donde se instalar los componentes del software. No hay una replicacin de lgica de negocio en los clientes: esto permite que se realice la modificacin y mejoras de forma automtica aprovechadas por el conjunto de los usuarios, as se reduce los costos de mantenimiento. La centralizacin de los aspectos de transaccionalidad y seguridad, son responsabilidad del modelo.

En el modelo fsico podemos diferenciar los siguientes componentes de la arquitectura: Front-End: donde se ejecutan las Interfaces de usuario del cliente. (Browsers). MiddleWare: recibe solicitudes de las Interfaces de Usuario a travs de la red. Estos son mensajes

Documents

Bolsa de Trabajo Hecha