Practica Hoy

Universidad Nacional de Ucayali
UNIVERSIDAD NACIONAL DE UCAYALI

FACULTAD DE INGENIERIA DE SISTEMAS Y DE INGENIERIA CIVIL
Escuela Acadmica Profesional de Ingeniera de Sistemas
ANLISIS Y DISEO DEL SISTEMA CONTROL DE DOCUMENTACIN DE PRACTICAS PRE-POFESIONALES DE LA UNIVERSIDAD NACIONAL DE UCAYALI
INFORME DE PRCTICA PRE-PROFESIONAL I REALIZADO EN LA OFICINA GENERAL DE PRACTICAS PRE-PROFESIONALES DE LA UNIVERSIDAD NACIONAL DE UCAYALI
AUTOR ASESOR
: :
May R. Hoyos Tello Ing. Pascual Aguirre Gamboa
Pucallpa, 30 abril del 2013
RECONOCIMIENTO
Mi mayor reconocimiento al Ing. Ing. Pascual Aguirre Gamboa por su asesoramiento y recomendaciones en el desarrollo del proyecto, adems por compartir sus conocimientos en cada momento.
NDICE
Pgina
RECONOCIMIENTO
CAPITULO I 1.1. 1.2 1.3 1.2
PRESENTACION 7 7 7 7
Objetivo del informe Periodo de prcticas Institucin y rea de prcticas Funciones del rea donde realizo sus Practicas ASPECTOS GENRALES DE LA INSTITUCION
CAPITULO II 2.1 2.2 2.3
Razn social Actividades que realiza Aspectos tcnicos 2.3.1 Ubicacin geogrfica 2.3.2 Plano de ubicacin 2.3.3 Organizacin 2.3.4 Infraestructura Tecnolgica: Hardware y Software 2.3.4.1 Software 2.3.4.2 Software MARCO TEORICO
10 10 11 11 11 12 13 13 13
CAPITULO III 3.1
3.2 3.3 3.4 3.5
Sistemas de Informacin 3.1.1 Actividades del Sistema de Informacin 3.1.1.1 Entrada de Datos 3.1.1.2 Almacenamiento de informacin 3.1.1.3 Procesamiento de datos 3.1.1.4 Salida de informacin 3.1.1.5 Retroalimentacin Tecnologas De Informacin Aplicaciones Web Arquitectura web Arquitectura cliente servidor
15 16 16 16 16 16 17 17 18 19 19 20 20 21 22 22 22 22 22 22 22 23
3.5.1 Arquitectura cliente servidor de 2 capas 3.5.2 Arquitectura cliente servidor de 3 capas 3.5.3 Aquitectura n capas 3.6 Proceso unificado rational 3.6.1 principios bsicos del rup 3.6.1.1 Dirigido por casos de uso 3.6.1.2 Centrado en la arquitectura 3.6.1.3 Proceso iterativo e incremental De structura del rup 3.6.21 El eje horizontal 3.6.1.2 El eje vertical
3.6.3 Fases del rup 3.6.3.1 Fase de inicio 3.6.3.2 Fase de elaboracin 3.6.3.3 Fase de construccin 3.6.3.4 Fase de transicin 3.7 Lenguaje unificado de modelado 3.7.1 Bloques de construccin de uml 3.7.2 Elementos de uml 3.7.3 Relaciones en uml 3.7.4 Diagramas uml 3.8 Diseo de pginas Web 3.8.1 HTML (Hipertexto Markup Language) 3.8.2 Javascript 3.9 Programacin de aplicaciones web 3.9.1 lenguaje de programacin java 3.9.1.1 Caractersticas 3.9.1.2 Java servlets 3.9.1.3 Java Server pages CAPITULO IV 4.1 Fase inicial FASE INICAL DEL ANALISIS Y DISEO
23 23 23 23 24 24 24 25 28 29 30 30 30 31 31 31 33 33
4.1.1 Modelamiento de Visin del negocio: A) Documento de visin del negocio: A.1) Introduccin: A.1.1 Propsito A.1.2 Alcance A.2) Posicionamiento: A.2.1 Oportunidad del Negocio A.2.2 Exposicin de Problema A.3) Descripcin de Stakeholder y Usuarios A.3.1 Mercado Demogrfico A.3.2 Sumario de Stakeholder A.3.3 Sumario de Usuarios A.3.4 Ambiente Usuarios A.3.5 Necesidades de Usuarios A.4) Objetivos de Modelamiento del Negocio A.5) Rangos de Calidad A.6) Panorama del Producto A.7) Requerimientos A.7.1 Funcionales A.7.2 No Funcionales B) PLAN DE DESARROLLO DEL SOFTWARE B.1) Introduccin B.1.1 Propsito B.1.2 Alcance B.1.3 Referencias B.1.4 Apreciacin Global B.2) La Apreciacin Global del Proyecto B.2.1 Propsito del Proyecto, Alcance y Objetivos
36 36 36 36 36 36 36 36 37 42 42 42 43 43 44 45 46 46 46 46 47 47 47 47 47 47 47 47 47
B.2.2 Entregables del Proyecto. B.3 La Organizacin del Proyecto B.3.1 Estructura Orgnica B.3.2 Interfaces Externas B.3.3 Papeles y Responsabilidades B.4 El Proceso de Direccin B.4.1 Estimacin del Proyecto B.4.2 Plan de Proyecto a) Plan de la Fase B.5 Recursos para el Proyecto B.5.1 Plan de Adquisicin de Recursos B.5.2 Entrenamiento que se planean B.6 Presupuesto B.7 Entorno de trabajo B.8 Vistas Use Case B.8.1 Modelo Use Case del Negocio a) Modelo Use case b) Modelo de objeto del negocio CAPITULO V: FASE DE ELABORACIN 5.1 REQUERIMIENTOS A) Modelo Use Case B) Diagramas de Actividades C) Especificaciones de los Use-Case 5.2 ANLISIS Y DISEO A) Diagrama de Colaboracin B) Diagrama de Paquetes del Anlisis C) Diagrama de clases D) paquetes RECOMENDACIONES BIBLIOGRAFIA
48 48 48 48 49 49 49 49 49 50 50 50 50 51 52 52 53 54
54 56 61 63 64 65 67 68 68 69 70
CAPITULO I PRESENTACION
Universidad Nacional de Ucayali OBJETIVO DEL INFORME. El objetivo principal de Este informe es realizar el anlisis y diseo del Sistema de Control de documentacin de prcticas Pre-Profesionales de la Universidad Nacional de Ucayali , aplicando las metodologas, patrones y estndares establecidos para el desarrollo de software, adquiridos en el transcurso de mi formacin profesional, y que sern empleados en este proyecto para obtener mi prctica pre-profesional N 01.Siendo los objetivos los siguientes:
Aplicar tcnicas de recopilacin de informacin para determinar los requerimientos de informacin de los usuarios del sistema.
Aplicar el Proceso Unificado de Rational para el Anlisis y Diseo orientado a objetos del sistema.
Realizar el anlisis y diseo del Sistema de Informacin en un entorno Cliente/Servidor utilizando Java y SQL Server.
Satisfacer las necesidades de informacin para la toma de decisiones.
Desarrollar una interfaz amigable, comprensible de fcil uso y utilidad completa para el usuario.
PERIODO DE PRCTICAS. La Practica Pre Profesional N 1 desarrollado en la Universidad Nacional de Ucayali, tuvo un periodo de 3 meses, desde el 30 de Diciembre del 2012 al 30 de marzo del 2011.
INSTITUCIN Y REA DONDE DESARROLL SUS PRCTICAS. La Institucin donde desarroll mi prctica pre profesional I fue en la Universidad Nacional de Ucayali, en la Oficina General de Practicas Pre-Profesionales de dicha Institucin.
FUNCIONES DEL REA DONDE REALIZ SUS PRCTICAS. La Direccin General de encargo de: Practicas Pre-Profesionales es un rgano de apoyo
Desarrollar, Implementar y Mantener el control de la Documentacin delos Alumnos de la Universidad Nacional de Ucayali y el software a utilizarse en publicar la informacin correspondiente a las actividades de dicha institucin.
Evaluar y supervisar la utilizacin de los recursos Informticos.
Universidad Nacional de Ucayali Promover, desarrollar e implementar procesos informticos y de comunicaciones a travs de la administracin de base de datos corporativas, redes de interconexin y sistemas de informacin (software) para la automatizacin y mejora continua de los procesos.
Implementar y mantener a los sistemas y equipos informticos, estableciendo un plan de accin para su modernizacin.
Implementar mecanismos de control y de monitoreo as como de procedimientos y mtodos de trabajo para la operacin de los equipos y la seguridad de la informacin.
CAPITULO II ASPECTOS GENERALES DE LA INSTITUCION
Universidad Nacional de Ucayali 2.1. RAZN SOCIAL.
UNIVERSIDAD NACIONAL DE UCAYALI
2.2. ACTIVIDADES QUE REALIZA. La Universidad Nacional de Ucayali, fue creada mediante el Decreto Ley N 22804, del 18 de Diciembe de 1979, con el nombre de "Universidad Nacional de Pucallpa" durante el gobierno militar del General Francisco Morales Bermdez Cerruti, como resultado de las gestas heroicas del Pueblo Ucayalino expresados en las picas jornadas denominadas "Los Grandes Pucallpazos" de 1978 y 1979.
Por Ley N 23261 del 16 de Julio de 1981, el gobierno democrtico del Arq. Fernando Belaunde Terry, ratific la creacin de la UNIVERSIDAD NACIAONAL DE PUCALLPA.
El 9 de Diciembre de 1983, entra en vigencia la actual Ley Universitaria N 23733; esta Ley seala en su Art. 97 que en adelante La Universidad Nacional de Pucallpa se denominar Universidad Nacional de Ucayali.
A 30 aos de su creacin la Universidad Nacional de Ucayali, cuenta con seis Facultades y diez escuelas profesionales y una poblacin estudiantil de aproximadamente 3000 alumnos.
Su misin es la de formar profesionales altamente calificados en ciencias, tecnologa y humanidades con sensibilidad social, capaces de dar solucin a los problemas regionales, nacionales y organizacionales, comprendidos con la bsqueda de la verdad, produccin y difusin del conocimiento. Tiene como funciones generales lo siguiente:
Preparar profesionales altamente calificados; investigadores, innovadores, conservadores y protectores del medio ambiente, capaces de crear conocimientos para contribuir a mejorar el nivel de vida de la poblacin, y asegurar la provisin de infraestructura fsica y el equipamiento para la formacin profesional.
Realizar acciones, mediante la aplicacin de programas asistenciales en las reas de salud, alimentacin, transporte, cultura, deporte y recreacin para lograr su bienestar. Propagar acciones para lograr una eficiente gestin institucional, tendiente a incrementar su prestigio, y mejorar la estructura orgnica que conlleve al cumplimiento de la misin institucional.
Certificar una eficiente y oportuna asistencia a los beneficiarios de los sistemas provisionales que tiene a su cargo la institucin.
10
2.3. ASPECTOS TCNICOS: 2.3.1. Ubicacin Geogrfica. La Universidad Nacional de Ucayali esta ubicado en la Av. Centenario Km. 6 de la ciudad de Pucallpa, Departamento de Ucayali.
2.3.2. Plano de Ubicacin.
FIGURA N 01. Ubicacin de la Universidad Nacional de Ucayali
Fuente: Universidad Nacional de Ucayali
11
2.3.3. Organizacin. FIGURA N 02: Estructura Orgnica de la Universidad Nacional de Ucayali
Fuente: Universidad Nacional de Ucayali
12
Universidad Nacional de Ucayali 2.3.4. Infraestructura Tecnolgica: Hardware y Software. La institucin cuenta con lo siguiente en: 2.3.4.1 Software 2.3.4.1.1 Sistemas Operativos. 1. Para Terminales. Windows XP Professional. Windows vista 2. Para Servidores. Windows Server 2003. Linux Mandrake 10.0 Linux Turstix. 2.3.4.1.2 Para Desarrollo. 1. Base de Datos. Sql Server 2000. 2. Aplicaciones. Apache Tomcat Microsoft Visual Studio 2005. Java Netbeans 5.5
2.3.4.1.3 Ofimtica. Office 2003. Office 2007.
2.3.4.1.4 Especializado. AutoCAD, Ms Projects. Software para presupuestos SIAF. McAfee. 2.3.4.2 Hardware 1. Servidores. 3 Marca IBM que son de: Dato y Dominio (Windows 2003), Proxy (Linux Squid), Correo y Web (Red Hat 10).
13
CAPITULO III FUNDAMENTO TERICO
14
3.1 SISTEMAS DE INFORMACIN. Un Sistema de informacin es un conjunto de personas, datos y procedimientos que funcionan en conjunto. El nfasis en sistemas significa que los variados componentes buscan un objetivo comn para apoyar las actividades de la organizacin Por otra parte, el desarrollo de sistemas informticos implica el uso creativo de la tecnologa de informacin para la adquisicin de datos, la comunicacin, coordinacin, anlisis y la ayuda en la toma de decisiones. Existen mtodos, tcnicas, tecnologas y metodologas para esta actividad. La creacin de sistemas de informacin para organizaciones necesita utilizar conocimientos de innovacin, calidad, sistemas hombre-mquina, interfaces hombre-mquina, diseo sociotecnolgico y gestin del cambio.
1
En informtica, un sistema de informacin es cualquier sistema o subsistema de equipo de telecomunicaciones o computacional interconectados y que se utilicen para obtener, almacenar, manipular, administrar, mover, controlar, desplegar, intercambiar, transmitir o recibir voz y/o datos, e incluye tanto los programas de computacin ("software" ) como el equipo de cmputo.2
La funcin de los sistemas de informacin tiene la responsabilidad de desarrollar, implementar y administrar una infraestructura de tecnologa de informacin (computadores y comunicaciones), de datos (internos y externos) y sistemas de informacin corporativos. Adems, esta funcin es responsable de seguir los avances de las nuevas tecnologas de informacin y de asistir para incorporarlas en la estrategia de la organizacin, en su planificacin y en sus prcticas. Por ltimo, esta funcin tambin apoya la utilizacin de tecnologa de informacin en sistemas departamentales e individuales
3
Los sistemas de informacin abarcan dos amplias reas: 1.-La adquisicin, despliegue y gestin de los recursos y servicios de tecnologa de informacin, llamada funcin de los sistemas de informacin. 2.- El desarrollo y evolucin de la infraestructura y de los sistemas para ser utilizados en los procesos de la organizacin, llamada desarrollo de sistemas informticos
4
El futuro ambiente tecnolgico (que ya comenz), deber considerar la adopcin de modelos de negocio centrados en la web, que utilizan herramientas y estndares de Internet, y garantizan la omnipresencia de los servicios y la informacin (cualquier momento - cualquier lugar), organizndose
1
2
Mario G. Piattini, Jos A. Calvo-Manzano, Joaqun Cervera, Lus Fernndez, 2000 Sistema de informacin [en lnea]. W ikipedia, La enciclopedia libre, 2009 [fecha de consulta: 20 de mayo del 2009]. <http://es.wikipedia.org/w/index.php?title=Sistema_de_informaci%C3%B3n&oldid=26490799>. 3 Raymond McLEOD Jr. Sistemas de Informacin Gerencial 7. Edicin. Editorial Prentice Hall, Mxico DF, Mxico 2000 4 Kenneth C. Laudon & Jane Laudon, 2002.
15
Universidad Nacional de Ucayali en forma federalizada y con una arquitectura de tres niveles claramente separados: la interface al usuario, la lgica de negocios y la gerencia transaccional de las bases de datos. 3.1.1 ACTIVIDADES DEL SISTEMA DE INFORMACIN
5
Un sistema de informacin realiza 5 actividades que producen la informacin que las organizaciones necesitan:
3.1.1.1 Entrada de Datos La data se define como el componente impulsor o indicador con el cual funciona el sistema. La entrada es el proceso mediante el cual el sistema de informacin obtiene los datos que requiere para procesarla. 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. Este ltimo se denomina interfaces automticas.
3.1.1.2 Almacenamiento de informacin Cuando la data entrante al sistema esta libre de errores esta debe ser almacenada de manera que pueda ser recordada la informacin guardada en la sesin o proceso anterior. Esta informacin suele ser almacenada en estructuras de informacin como archivos, bases de datos u otros. La unidad tpica de almacenamiento son los discos magnticos o discos duros, los discos flexibles o diskettes y otros discos compactos (CD-ROM). Sin embargo, existen otras formas de almacenamiento. 3.1.1.3 Procesamiento de datos Es el conjunto de operaciones que se realiza sobre los datos ingresados con el fin de obtener los resultados esperados para cumplir con los objetivos de la organizacin en la cual se halla inmerso el sistema. Mediante el procesamiento de datos se le permite a los sistemas la transformacin de los mismos en la informacin que puede ser utilizada para la toma de decisiones.
3.1.1.4 Salida de informacin La salida es la capacidad de un Sistema de Informacin para sacar la informacin procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las
5 Tendencias en tecnologa de informacin,Dr. Benjamn Tripier, http://www.gestiopolis.com/canales/emprendedora/articulos/48/tti.htm
16
Universidad Nacional de Ucayali impresoras, terminales, diskettes, cintas magnticas, la voz, los graficadores y los plotters, entre otros. Es el fin para el cual fue construido el sistema y esta debe guardar una relacin coherente con los objetivos de la organizacin. La salida debe ser recibida por las personas que realmente emplean la informacin dentro de la organizacin. 3.1.1.5 Retroalimentacin
Es una forma de control del sistema, para ser realizada se toman las salidas del sistema para comparar su desempeo con los objetivos de la organizacin.
FIGURA N 03 ACTIVIDADES EFECTUADAS EN UN SISTEMA DE INFORMACIN
Fuente: Laudon, K; Laundon, J., 2002
Los Sistemas de informacin son desarrollados con propsitos diferentes dependiendo de las necesidades del negocio.
6
3.2 TECNOLOGIAS DE INFORMACION Se conoce como tecnologa de informacin (TI) a la utilizacin de tecnologa especficamente computadoras y ordenadores electrnicos - para el manejo y procesamiento de informacin especficamente la captura, transformacin, almacenamiento, proteccin, y recuperacin de datos e informacin. Los orgenes de la TI son recientes. Aunque el nombre de tecnologa de informacin se remonta a los aos 70, su utilizacin en los negocios se remonta a mediados del siglo XX, durante la segunda guerra mundial. Sin embargo, ha sido en los ltimos 20 aos donde ha alcanzado niveles de uso y aplicaciones tan variadas y ubicuas, que se ha convertido en un rea de gran amplitud e impacto en todos los aspectos de la vida cotidiana incluyendo la gerencia de cualquier empresa, en la cual hoy en da es casi indispensable.
Kenneth E. Kendall & Julie E. Kendall, 1999
17
Universidad Nacional de Ucayali Desde el surgimiento de Internet, se ha incorporado masivamente a la TI el aspecto de comunicacin, con lo cual se suele hacer referencia a un tema an ms amplio, conocido como Tecnologa de Informacin y Comunicaciones, o TIC.7 Aquella tecnologa que no tenga un resultado favorable para los objetivos de negocio, por ms moderna que sea, no tiene sentido. La plataforma es la que mantiene con vida una empresa, pues es sta la que mantenindose en la base, debe ser lo suficientemente robusta, confiable y escalable para adaptarse a los cambios que enfrentan las organizaciones. Las Tecnologas de la Informacin estn al servicio de las personas y nos la reemplaza, es slo una herramienta que la gente y el ser humano tiene que utilizar de manera diferente en funcin de su capacidad y la creacin de cada una de ellas. La tecnologa puede ser igual de empresa a empresa, puede tener una empresa mejor tecnologa que la otra, y no significa que sea mejor. La diferencia no es tanto la tecnologa, sino la capacidad de la persona que la utilice y el uso pasa por la aplicacin de los conceptos ms intangibles como son la capacidad del ser humano para imaginarse, para desarrollar nuevas ideas a travs del uso de la tecnologa
8
3.3 APLICACIONES WEB En la ingeniera software se denomina aplicacin web a aquellas aplicaciones que los usuarios pueden utilizar accediendo a un servidor web a travs de Internet o de una intranet mediante un navegador. En otras palabras, es una aplicacin software que se codifica en un lenguaje soportado por los navegadores web (HTML, Java Script, Java, etc.) en la que se confa la ejecucin al navegador.
9
Una aplicacin web est comnmente estructurada como una aplicacin de tres-capas. En su forma ms comn, el navegador web es la primera capa, un motor usando alguna tecnologa web dinmica (ejemplo: CGI, PHP, Java Servlets o ASP) es la capa de en medio, y una base de datos como ltima capa. El navegador web manda peticiones a la capa media, que la entrega valindose de consultas y actualizaciones a la base de datos generando una interfaz de usuario
10
Las interfaces Web tienen ciertas limitantes en la funcionalidad del cliente. Mtodos comunes en las aplicaciones de escritorio como dibujar en la pantalla o arrastrar-y-soltar no estn soportadas por las tecnologas Web estndar. Los desarrolladores Web comnmente utilizan lenguajes interpretados del lado del cliente para aadir ms funcionalidad, especialmente para crear una experiencia interactiva que no requiera recargar la pgina cada vez (cosa que suele molestar a los usuarios). Recientemente se han desarrollado tecnologas para coordinar estos lenguajes con tecnologas del lado del servidor, como por ejemplo AJAX, que es una tcnica de desarrollo Web que usa una combinacin de varias tecnologas 9
7
8 9
Tecnologa de Informacin, http://www.degerencia.com/tema/tecnologia_de_informacion Tecnologa de Informacin y Comunicacin, es.wikipedia.org/w/tecnologias Aplicacin web [en lnea]. Wikipedia, La enciclopedia libre, 2009 [fecha de consulta: 28 de abril del 2009]. Disponible en <http://es.wikipedia.org/w/index.php?title=Aplicaci%C3%B3n_web&oldid=25915846>. 10 HUNTER, Jason Java Servlet Programming, 2nd Edition, 2004
18
3.4 ARQUITECTURA WEB La arquitectura de un sitio Web tiene tres componentes principales: un servidor Web, una conexin de red, y uno o ms clientes (browsers). El servidor Web distribuye pginas de informacin formateada a los clientes que las solicitan. Los requerimientos son hechos a travs de una conexin de red, y para ello se usa el protocolo http . 3.5 ARQUITECTURA CLIENTE SERVIDOR La arquitectura elegida para el desarrollo del sistema es Cliente Servidor, ya que es una arquitectura descentralizada que permite a los usuarios finales obtener acceso a la informacin de forma transparente; es decir que el usuario le es indiferente de donde viene la informacin. Clientes y servidores son entidades lgicas independientes que operan en conjunto a travs de una red para realizar una tarea. La arquitectura cliente-servidor llamado modelo cliente-servidor o servidor-cliente es una forma de dividir y especializar programas y equipos de cmputo a fin de que la tarea que cada uno de ellos realice se efecte con la mayor eficiencia, y permita simplificarlas. En esta arquitectura la capacidad de proceso est repartida entre el servidor y los clientes. En la funcionalidad de un programa distribuido se pueden distinguir 3 capas o niveles: 1. 2. 3. Manejador de Base de Datos (Nivel de almacenamiento), Procesador de aplicaciones o reglas del negocio (Nivel lgico) y Interfase del usuario (Nivel de presentacin) Fig. N 04 ARQUITECTURA CLIENTE SERVIDOR
11
Fuente: HUNTER, Jason 2004.
11
CUEVA LOVELLE, Juan Manuel Web Engineering, 1ra Edition, 2005
19
3.5.1 ARQUITECTURA CLIENTE SERVIDOR DE 2 CAPAS
La arquitectura Cliente Servidor de dos capas ha sido la ms utilizada con los lenguajes de cuarta generacin. En este tipo de aplicaciones se desarrollan dos capas: Una capa llamada front-end (la interfaz de usuario), que normalmente est constituida de aplicaciones de escritorio que hacen llamadas a un servidor SQL. La otra capa se conoce como back-end, normalmente constituida por un servidor de base de datos con interfaz SQL y un sistema operativo multitarea.
Aunque este tipo de arquitectura es fcil de implementar, el hecho de que la lgica del negocio y la presentacin se encuentren almacenados en el cliente (front-end), lleva a que cambios en la base de datos o en la lgica de negocios implique hacer actualizaciones en todos los clientes. Otra desventaja es la dificultad de compartir procesos comunes.
Fig. N 05 ARQUITECTURA CLIENTE/SERVIDOR 2 CAPAS
3.5.2
ARQUITECTURA CLIENTE SERVIDOR DE 3 CAPAS
Una arquitectura de tres capas provee adicionalmente una capa explcita para las reglas del negocio, que se sita entre el front-end y el back-end. Esta capa intermedia encapsula el modelo de negocio asociado con el sistema y lo separa tanto de la presentacin como del manejo de la base de datos. Normalmente las reglas del negocio se encapsulan en componentes, en cada uno de los cuales radican servicios al usuario. Las ventajas de esta arquitectura son: 1. Los servidores del negocio pueden compartirse. 2. Las plataformas de software y hardware entre clientes y servidores son independientes: precisamente una de las principales ventajas de esta arquitectura es
20
Universidad Nacional de Ucayali la posibilidad de conectar clientes y servidores independientemente de sus plataformas. 3. Se mantiene la independencia entre el cdigo de la aplicacin (reglas y conocimiento del negocio) y los datos, mejorando la portabilidad de las aplicaciones. 4. Se puede modificar la lgica del negocio sin hacer cambios a la interfaz del usuario o la base de datos. 5. Provee escalabilidad horizontal y vertical. La escalabilidad horizontal permite agregar ms estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las caractersticas del servidor o agregar mltiples servidores.
Fig. N 06 ARQUITECTURA CLIENTE/SERVIDOR 3 CAPAS
Fuente: HUNTER, Jason 2004 3.5.3 ARQUITECTURA N CAPAS
Consiste en que la red es considerada como un pool de servicios distribuidos, un concepto mucho ms completo que el simple acceso de un cliente a un servidor. La separacin de la presentacin, lgica de negocio y datos es realizada en un nmero indefinido de capas lgicas, permitiendo a cada capa ser desarrollada, mejorada, gestionada y desplegada de forma independiente. Esta es precisamente la base para el modelo de informtica de red en n-capas. Las plataformas multicapa funcionan consistentemente a lo largo de un variado conjunto de hardware, permitiendo escalar las operaciones del negocio desde un simple porttil, hasta un datacenter, desde el dispositivo ms simple hasta el ms complejo de los mainframes12
12
Bosak J. XML, Java and the future of the Web. http://www.xml.com/pub/a/w3j/s3.bosak.html
21
Universidad Nacional de Ucayali 3.6 PROCESO UNIFICADO DE RATIONAL (RUP) El Proceso Unificado es un proceso de la Ingeniera del Software, el cual provee un enfoque disciplinario para asignar tareas y responsabilidades durante la organizacin del desarrollo del software. El RUP es una gua de cmo utilizar de manera efectiva UML. Crea y mantiene modelos, en lugar de enfocarse en la produccin de una gran cantidad de papeles de documentacin.
3.6.1 PRINCIPIOS BASICOS DEL RUP
3.6.1.1
Dirigido por casos de uso. Los casos de uso dirigen y controlan el proceso de desarrollo en su totalidad. A travs de la captura de los requisitos que tiene dos objetivos: Encontrar los verdaderos requisitos y representarlos de un modo adecuado. Un verdadero requisito es aquello que cuando es implementado aade el valor esperado por el Usuario.
3.6.1.2 Centrado en la arquitectura.
Es la pieza clave que permite comprender el sistema, organizar el desarrollo, fomentar la reutilizacin y hacer evolucionar el software.
3.6.1.3 Proceso iterativo e incremental.
El desarrollo se plantea de manera progresiva, de tal modo que se atenen los riesgos, se planteen las cuestiones en el instante en que se est capacitado para resolverlas, se obtenga una arquitectura robusta, se pueda gestionar los requisitos cambiantes y exista una integracin continua 3.6.2 ESTRUCTURA DEL RUP El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: 3.6.2.1 El eje horizontal Representa tiempo y muestra el aspecto dinmico del proceso, expresado en trminos de ciclos, fases, iteraciones, y metas.
22
3.6.2.2 El eje vertical Representa el aspecto esttico del proceso; como est descrito en trminos de actividades, artefactos, trabajadores y flujos de trabajo.
Fig. N 08: ESTRUCTURA DEL RUP
Fuente: JACONSON, Ivar; RUMBAUG, James; BOOCH, Grady, 1999
3.6.3 FASES DEL RUP 3.6.3.1 Fase Inicio Su objetivo principal es establecer los objetivos para el ciclo de vida del producto. En esta fase se establece el caso del negocio con el fin de delimitar el alcance del sistema, saber qu se cubrir y delimitar el alcance del proyecto.
3.6.3.2 Fase Elaboracin Su objetivo principal es plantear la arquitectura para el ciclo de vida del producto. En esta fase se realiza la captura de la mayor parte de los requerimientos funcionales, manejando los riesgos que interfieran con los objetivos del sistema, acumulando la informacin necesaria para el plan de construccin y obteniendo suficiente informacin para hacer realizable el caso del negocio.
3.6.3.3 Fase Construccin Su objetivo principal es alcanzar la capacidad operacional del producto. En esta fase a travs de sucesivas iteraciones e incrementos se desarrolla un producto software, listo para operar, ste es frecuentemente llamado versin beta.
23
Universidad Nacional de Ucayali 3.6.3.4 Fase Transicin Su objetivo principal es realizar la entrega del producto operando, una vez realizadas las pruebas de aceptacin por un grupo especial de usuarios y habiendo efectuado los ajustes y correcciones que sean requeridos. 3.7 LENGUAJE UNIFICADO DE MODELADO (UML) El Lenguaje Unificado de Modelado (UML) es una tcnica para la especificacin de sistemas en todas sus fases. Esta ha sido desarrollado por los ms importantes autores en materia de Anlisis y Diseo de Sistemas y ha sido usada con xito en sistemas hechos para toda clase de industrias alrededor del mundo: Salud, Bancos, Comunicaciones, Aeronutica, Finanzas, etc. UML sirve para hacer modelos que permitan: Visualizar grficamente como es un sistema o como queremos que sea. Especificar la estructura y/o comportamiento de un sistema. Hacer una plantilla que gue la construccin de los sistemas. Documentar las decisiones que hemos tomado.
13
El modelado sirve no solamente para los grandes sistemas; an en aplicaciones de pequeo tamao se obtienen beneficios de modelar, sin embargo, es un hecho que entre ms grande y ms complejo es el sistema, el modelado juega un papel ms importante. Esto se debe a una razn simple: Hacemos modelos de sistemas complejos porque no podemos entenderlos en su totalidad.
Hay lmites para el entendimiento de la complejidad. A travs del modelado reducimos el mbito del problema de estudio al enfocar solo un aspecto a la vez. UML puede ser usado extensivamente en: Recopilacin de requerimientos, Anlisis de aplicaciones, Diseo de sistemas, en pruebas, en implementacin, en reingeniera y prcticamente en cualquier actividad de desarrollo que sea susceptible de ser modelada.
Cabe aclarar que aunque UML es orientado a objetos preferentemente, es til en cualquier modelo tecnolgico ya que es independiente de lenguajes de programacin o tecnologa determinada. 3.7.1 BLOQUES DE CONSTRUCCION DE UML. El vocabulario UML incluye tres clases de bloques de construccin: 1. Elementos. 2. Relaciones. 3. Diagramas.
14
13
JACONSON, Ivar; RUMBAUG, James; BOOCH, Grady, Proceso Unificado Rational, 1999
24
Universidad Nacional de Ucayali 3.7.2 ELEMENTOS DE UML Existen cuatro tipos de elementos de UML: 1. Elementos Estructurales. Son los nombres de los modelos UML. En su mayora son las partes estticas de un modelo y representan cosas que son conceptuales o materiales. Existen Sietes tipos que son: Clases. Una Clase es una descripcin de un conjunto de clase que comparten los mismos atributos, relaciones y semntica.
Fig. N 10 REPRESENTACION DE UN CLASE
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) Interfaz. Es una coleccin de operaciones que especifican un servicio de una clase o componente.
Fig. N 11 REPRESENTACION DE UNA INTERFAZ
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) Colaboracin. Define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos.
Fig. N 12 REPRESENTACION DE UNA COLABORACION
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) 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 particular.
25
Universidad Nacional de Ucayali Fig. N 13 REPRESENTACION DE UN CASO DE USO
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) Clase Activa. Es aquella cuyos objetos tienen uno o ms procesos o hilos de ejecucin y por lo tanto puede dar origen a actividades de control. Fig. N 14 REPRESENTACION DE UN CLASE ACTIVA
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) Componente. Es una parte fsica y reemplazable de un sistema que conforma un conjunto de interfaces y proporciona la implementacin de dicho conjunto.
Fig. N 15 REPRESENTACION DE UN COMPONENTE
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) Nodo. Es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional.
Fig. N 16 REPRESENTACION DE UN NODO
Fuente: RUMBAUG, JACOBSON, BOCH, (1999)
26
2. Elementos de Comportamiento. Son las partes dinmicas de los modelos UML, Estos son los verbos de un modelo y representan comportamiento en el tiempo y espacio. Existen dos tipos de Elementos de comportamiento: Interaccin. Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para alcanzar un propsito especfico.
Fig. N 17 REPRESENTACION DE UNA INTERACCION
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) Maquina de Estados. Comportamiento que especifica la secuencia de estados por las que pasa un objeto o interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.
Fig. N 18 REPRESENTACION DE UN ESTADO
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) 3. Elementos de Agrupacin. Son las partes organizativas de los modelos UML. Estos son las cajas en las que puede descomponerse un modelo. Existen solo un elemento o tipo: Paquete. Es un mecanismo de propsito general para organizar elementos en grupos. Un paquete es puramente conceptual (en tiempo de desarrollo) y un componente es existen en tiempo de ejecucin.
Fig. N 19 REPRESENTACION DE UN PAQUETE
27
Universidad Nacional de Ucayali 4. Elementos de Anotacin. Son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. Existe solo un tipo: Nota. Es simplemente un smbolo para mostrar restricciones y comentarios. Fig. N 20 REPRESENTACION DE UNA ANOTACION
3.7.3 RELACIONES EN UML. Se utilizan para escribir modelos bien formados y existen cuatro tipos de Relaciones: 1. Dependencia. Relacin semntica entre dos elementos, en la cual un cambio en un elemento afecta al otro elemento. Fig. N 21 REPRESENTACION DE UNA DEPENDENCIA
2. Asociacin. Relacin estructural que describe un conjunto de enlaces, que son conexiones entre objetos. Fig. N 22 REPRESENTACION DE UNA ASOCIACION
Fuente: RUMBAUG, JACOBSON, BOCH, (1999) 3. Generalizacin. Relacin de especializacin/generalizacin en la cual los objetos del elemento especializado pueden sustituir a los objetos del elemento general.
Fig. N 23 REPRESENTACION DE UNA GENERALIZACION
28
Universidad Nacional de Ucayali 4. Realizacin. Relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir.
14
Fig. N 24 REPRESENTACION DE UNA REALIZACION
3.7.4 DIAGRAMAS UML.
Un diagrama es la representacin grfica de un conjunto de elementos y la relacin entre ellos. Los diagramas se especifican para ver un sistema desde distintos puntos de vista, por tanto, un diagrama es una proyeccin de un sistema y representa una vista resumida de los elementos que lo constituyen. UML incluye nueve diagramas: 1. Diagrama de casos de uso Representa los requerimientos de los usuarios del sistema, y muestran un conjunto de casos de uso, actores y relaciones. Estos diagramas son importantes en el modelado y organizacin del comportamiento de un sistema. 2. Diagrama de clases Muestra un conjunto de clases, Interfaces y Colaboraciones as como sus relaciones. Cubren la vista de diseo esttica de un sistema, y son los diagramas ms comunes en el modelado de sistemas orientado a objetos.
3. Diagrama de objetos Muestra un conjunto de objetos y sus relaciones. Representan las instantneas de instancias de los elementos encontrados en los diagramas de clases. 4. Diagrama de secuencia El diagrama de secuencia es un diagrama de interaccin que cubre la vista dinmica de un sistema. Y Resalta la ordenacin temporal de los mensajes.
5. Diagrama de colaboracin El diagrama de colaboracin es un diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes.
6. Diagrama de estados Muestra una mquina de estados por los que pasa un objeto, y consta de eventos, transiciones y actividades.
14
BOOCH, G; RUMBAUCH, J; JACOBSON, I. El Lenguaje Unificado de Modelado, 2000
29
Universidad Nacional de Ucayali 7. Diagrama de actividades Es un tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema. Es una vista simplificada de lo que ocurre en un sistema.
8. Diagrama de componentes Muestra la organizacin y la dependencia entre un conjunto de componentes de un sistema. Cubre la vista de implementacin esttica de un sistema.
9. Diagrama de despliegue Muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos.
15
FIGURA N 25 DIAGRAMAS DE UML
3.8 DISEO DE PGINAS WEB.
3.8.1 HTML (HyperText Markup Language) es un lenguaje muy sencillo que permite describir hipertexto, es decir, texto presentado de forma estructurada y agradable, con enlaces (hyperlinks) que conducen a otros documentos o fuentes de informacin relacionadas, y con inserciones multimedia. 3.9.1.2 JAVASCRIPT. Javascript es el siguiente paso, despus del HTML, que puede dar un programador de la Web que decida mejorar sus pginas y la potencia de sus proyectos. Es un lenguaje de programacin bastante sencillo y pensado para hacer las cosas con rapidez, a veces con ligereza.
16
15
Jacobson -Boch- Rumbaugh - El proceso Unificado de Desarrollo de Software Primera - Mxico - Addison Wesley - 1999 16 El Lenguaje HTML. 2004. http://cdec.unican.es/libro/html.htm
30
Universidad Nacional de Ucayali Entre las acciones tpicas que se pueden realizar en Javascript tenemos dos vertientes. Por un lado los efectos especiales sobre pginas Web, para crear contenidos dinmicos y elementos de la pgina que tengan movimiento, cambien de color o cualquier otro dinamismo. Por el otro, Javascript nos permite ejecutar instrucciones como respuesta a las acciones del usuario, con lo que podemos crear pginas interactivas con programas como calculadoras, agendas, o tablas de clculo. Sus caractersticas ms importantes son: 1. Es un lenguaje interpretado, es decir, no requiere compilacin. El navegador del usuario se encarga de interpretar las sentencias JavaScript contenidas en una pgina HTML y ejecutarlas adecuadamente.
2. Es un lenguaje orientado a eventos. Cuando un usuario pincha sobre un enlace o mueve el puntero sobre una imagen se produce un evento. Mediante JavaScript se pueden desarrollar scripts que ejecuten acciones en respuesta a estos eventos.
3. Es un lenguaje orientado a objetos. El modelo de objetos de JavaScript est reducido y simplificado, pero incluye los elementos necesarios para que los scripts puedan acceder a la informacin de una pgina y puedan actuar sobre la interfaz del navegador. ( )
17
3.9 PROGRAMACIN DE APLICACIONES WEB 3.9.1 LENGUAJE DE PROGRAMACIN JAVA Java es un lenguaje de programacin orientado a objeto desarrollado por Sun Microsystems y aprovechado para el desarrollo de aplicaciones para la Internet. Es de propsito general, que puede ser usado para desarrollar cualquier tipo de aplicaciones. Java es un lenguaje: de objetos. independiente de la plataforma.
3.9.1.1 CARACTERISTICAS 1. Simple y Poderoso. Tiene conceptos bsicos de programacin orientada al objeto, lo que proporciona un paradigma de simplicidad, pero a su vez permite llegar a un nivel lo suficientemente bajo (detalle) como para poder realizar casi cualquier cosa.
17
Introduccin a JavaScript, 2002,www.elcodigo.net/tutoriales/javascript/javas.html
31
Universidad Nacional de Ucayali 2. Seguro. Los programas de Java no pueden llamar a funciones globales y ganar acceso a recursos del sistema arbitrarios. Entonces se puede ejercer un control sobre los programas ejecutables de Java, lo que no es posible en otros sistemas. 3. Robusto Java verifica el cdigo mientras se escribe y una vez ms antes de ejecutarlo. Esto permite que el programa se comporte de una manera predecible, bajo diversas condiciones. Java ayuda a evitar fallas por condiciones excepcionales (divisin por cero, acceso a archivo no existente, etc.) mediante un manejo de excepciones orientado a objetos integrados.
Java prcticamente elimina la posibilidad de falla en la gestin de memoria (no liberarla o, peor aun, liberar aquella que no corresponde) mediante la facilidad de recojo de basura. 4. Interactivo Java tiene varias caractersticas que permiten escribir programas que hacen muchas cosas al instante, sin perder el control de lo que debera suceder y cundo. El intrprete de Java soluciona esta necesidad de sincronizacin entre mltiples procesos con hilos mltiples (multithreading) de sencilla utilizacin, que permiten pensar en el comportamiento especfico, sin tener que integrarlo en el clsico modelo de programacin global de bucle para el evento. 5. Entorno con Muchas Facilidades. El entorno Java provee varias clases necesarias para la interaccin de un programa con otros.
6. Arquitectura Neutral. Cuando se dise Java se tomaron consideraciones, tanto para el lenguaje como para el intrprete, de manera que un programa pueda escribirse una sola vez, ejecutarse en cualquier sitio, en cualquier momento y para siempre. Es multiplataforma: Solaris, Iris, Linux, HP/UX, OSF, Windows, OS/2, Macintosh. 7. Interpretado y de Alto Rendimiento. Java compila a una representacin intermedia llamada cdigo de byte, el que se puede interpretar en cualquier sistema que tenga un intrprete de Java. Este cdigo de byte fue diseado de tal manera que sea sencilla la necesaria traduccin a cdigo de mquina nativo. Con esto se logr que un intrprete sea de alto rendimiento. Cada parte de un programa Java se reduce a una secuencia de bytes que representan instrucciones en una mquina virtual y no en una mquina (procesador) especfica.
32
Universidad Nacional de Ucayali 8. Optimo Para Internet. TCP/IP: Java provee clases para gestionar limpiamente protocolos de Internet. Incluye implementaciones de ftp, http, nntp, smtp junto con conectores de red de bajo nivel (sockets) e interfaces de nombrado. WWW y HTML: Java est diseado para cumplir los requisitos de entrega de contenidos interactivos usando applets insertadas en sus pginas HTML. Las clases bsicas de manejo de cadenas son especialmente adecuadas para el tipo de manejo de texto basado en HTML. DISTRIBUCIN POR LA RED: las clases de Java se envan con facilidad e incluso pueden actualizarse en el proceso, resolviendo el clsico problema de control de versiones. 3.9.1.2
18
JAVA SERVLETS.
Los servlets son clases Java que se ejecutan en un servidor de aplicacin, para contestar a las peticiones de los clientes. Los servlets no se encuentran limitados a un protocolo de comunicaciones especfico entre clientes y servidores, pero en la prctica podemos decir que se utilizan nicamente con el protocolo HTTP, por lo que el servidor de aplicacin pasa a denominarse entonces servidor Web.
Fig. N 21 CICLO DE VIDA DE UN SERVLET
Fuente: HUNTER, Jason, 2004
3.9.1.3 JAVA SERVER PAGES (JSP) Una pgina JSP va a ser un fichero de texto con la extensin JSP, que combina etiquetas HTML con nuevas etiquetas de script pertenecientes a la especificacin JavaServer Pages.
Una pgina JSP va a tener un aspecto muy similar al de una pgina HTML, pero se transformarn en clases de Java que son servlets para compilarse y generar los ficheros de
18
HUNTER, Jason Java Servlet Programming, 2nd Edition, 2004
33
Universidad Nacional de Ucayali clase correspondientes, esta operacin se dar cuando se ejecute una pgina JSP por primera vez, o cuando se modifique una pgina JSP existente.
Un pgina JSP podemos decir que presenta un mayor nivel de abstraccin de los servlets, ya que en muchos aspectos se puede considerar que el API JavaServer Pages es de ms alto nivel que el API Java servlet.
19
Fig. N 22 FUNCIONAMIENTO DE UN JSP
19
HUNTER, Jason Java Servlet Programming, 2nd Edition, 2004
34
CAPITULO IV FASE INICIAL DEL ANALISIS Y DISEO
35
Universidad Nacional de Ucayali 4.1 FASE INICIAL 4.1.1 MODELO DE VISIN DEL NEGOCIO A. DOCUMENTO VISION DEL NEGOCIO. A.1 Introduccin A.1.1 Propsito El propsito de este documento es ofrecer un esquema del funcionamiento del sistema, a nivel de procesos, actores, y diagramas del Sistema de Control de Documentacin de prcticas Universidad Nacional de Ucayali Pre-Profesionales de la
A.1.2
Alcance En este trabajo se realizar el modelamiento de un Sistema de Control de documentacin de prcticas Nacional de Ucayali Pre-Profesionales de la Universidad , desarrollado por un alumno practicante de la
Escuela Profesional de Ingeniera de Sistemas, estudiante de la escuela con una arquitectura cliente servidor es decir de tres capas. La gestin de trmite documentario se realiza de la siguiente manera:
El alumno solicitara carta de presentacin a la Decanatura de la Facultad La Facultad Remite carta de Presentacin El alumno presenta carta de presentacin al Institucin donde realizara sus practicas La institucin remitir a la comisin de prcticas pre profesionales la carta de aceptacin. El alumno solicita asesor de prcticas. La comisin asigna asesor. El alumno solicita aprobacin de plan de trabajo. Comisin aprueba plan de trabajo. El alumno solicita aprobacin de prcticas. La comisin asigna jurado evaluador a la prctica.
Se aprueba la practica pre profesional.
A.2
Posicionamiento A.2.1 Oportunidad del negocio
36
Hoy en da las instituciones reconocen que un sistema informtico es una herramienta vital para la toma de decisiones y para mejorar el Funcionamiento de los procesos administrativos de su organizacin. La universidad de Ucayali no cuenta con un Sistema de Control de documentacin de prcticas Pre-Profesionales que le permita agilizar el proceso de control de la Documentacion , por lo cual existe un saturacin y exceso en el proceso, generando prdida de tiempo, gastos administrativos administrativos). y gastos al usuario final (alumnos, docentes,
Por esto es necesario que se cuente con un sistema informtico que ayude a realizar el control de la documentacion en tiempo real, adems permitir a la UNU mejorar: la Imagen de Esta Institucin frente a las dems universidades convirtindose as en una Universidad Tecnolgica. A.2.2 Exposicin del Problema Realidad Problemtica
Deficiencia en el proceso de control de documentos. Demoras en el proceso de sustentacin de las Practicas. Perdida de tiempo para la recepcin de la documentacin . No disponibilidad de consulta de del avance de la documentacin en tiempo real. Anlisis del problema
El proceso para generar la Control De la Documentacin se realiza a travs de un sistema documento. manual que solo registra la recepcin del
No existe sistema actual
que cuenta con los requerimientos
necesarios para brindar un buen servicio como: consultas ,etc. Sobre el Proceso de agilizacin de la Documentacin se hace luego de saber Si fue aprobado con una respectiva resolucin
37
Todos estos procesos generados por el sistema actual de forma manual generan deficiencia y demora en el proceso de control de Documentos de Practicas Pre-Profesionales causando prdida de tiempo, gastos administrativos y gastos al usuario final (alumnos, docentes, administrativos).
38
Afecta a:
Universidad Nacional de Ucayali. Alumnos. Docentes. Personal administrativo. Coordinador de Laboratorio. Coordinador de Biblioteca Alumnos y profesores.
Impacto
Imagen institucional. Proceso lento y mal definido que dificultan el control de la Documentacin. Carga de trabajo al personal encargado del Control de Documentos. Ocasiona prdida de tiempo y dinero al alumno al consultar si su documentos esta avanzando para la futura Sustentacin de Dichas Practicas . Presencia obligada del profesor para la entrega de notas. Demora en los requerimientos de informacin.
39
Solucin exitosa podra:

Realizar el proceso de Control De Documentacin desde cualquier punto del mundo y realizar sus consultas de horarios, permitidos, etc.
Mejorar el proceso de control de Documentos a travs de un sistema que permita, administrar y salvaguardad la seguridad de los datos.
Mejorar el registro de Recepcin de Documentos . Centralizar la informacin para acceder a ella en cualquier momento y contar con informacin relevante y oportuna para la eficiente toma de decisiones y brindar un mejor servicio a los usuarios.
40
41
A.3
Descripcin de Stakeholder y usuarios
A.3.1
Mercado demogrfico
La Universidad Nacional de Ucayali actualmente cuenta con ms de n estudiantes y docentes, los cuales no tienen un sistema de Control De Documentacin Para Practicas Pre-Profesionales eficiente que permita realizar este proceso de manera rpida y precisa ya que uno de los fines primordiales de la UNU es mejorar constantemente los servicios de atencin tanto para alumnos como para docentes.
A.3.2
Sumario de Stakeholder
Tabla N 01 SUMARIO DE STACKEHOLDER
Decano
La Facultad Universitaria
de cada Carrera
-Evala y monitorea los procesos acadmicos -Crea soluciones que puedan suscitarse en el Proceso de Matrcula
Director Escuela Admisin
de
La Escuela de cada Carrera Universitaria El rea de Admisin de la Universidad Nacional de Ucayali
Monitorea los procesos acadmicos Brindar la informacin de los nuevos alumnos
Banco
Entidad Privada
Brindar Informacin de los depsitos realizados a la cuenta de la Universidad.
Vicerrector Acadmico
Representa
la
parte
Emite una resolucin sobre la taza y calendario acadmico.
administrativa de la UNU
Fuente: Elaboracin propia
42
Universidad Nacional de Ucayali A.3.3
Sumario de Usuarios
Tabla N 02 SUMARIO DE USUARIOS
NOMBRE
Vicerrector Acadmico Jefe Departamento de
DESCRIPCIN
Maneja la seguridad y el acceso de los usuarios al Sistema. Realiza el registro y monitoreo de alumnos y profesores. Tambin realiza el registro de los horarios, as como el registro de un plan de estudio.
STAKEHOLDERS
Representa as mismo
Representa as mismo
Docente jefe de Practicas
Realiza ,la
consultas
de de
los los
Representa as mismo
recepcin
Documentos de los alumnos Alumno Realizar consultas de los Su Documento de Consulta acadmica Fuente: Elaboracin propia A.3.4 informacin Representa as mismo
Director Escuela
Representa as mismo
Ambiente de Usuarios
Docente: Tendr acceso al sistema de control de documentacin de ordenador que tenga
prcticas Pre-profesionales desde cualquier
acceso a Internet las 24 horas del da y desde cualquier lugar, Jefe de Departamento: Tendr los privilegios de acceder a la base de datos realizada en SQL. Identificndose con un nombre de usuario y su respectiva contrasea
43
Alumno: Tendr acceso al sistema de control de documentacion desde cualquier ordenador que tenga acceso a Internet las 24 horas del da y desde cualquier lugar, para poder matricularse.
Direccin de coordinacin acadmica: Tendr un Terminal para registrar el cronograma acadmico de los alumnos de la universidad. Vicerrector Acadmico: Tendr una Terminal seguridad y el acceso de los usuarios al sistema para controlar la
A.3.5
Necesidades de los Usuarios
Tabla N 04 NECESIDADES DE USUARIOS
NECESIDAD
PRIORIDAD
CONCERNIENTE
SOLUCION ACTUAL
Es un sistema de escritorio automatizado pero no en su totalidad
Realizar control
Tiempo de respuesta Alta lento y carga del trabajo
Realizar Horarios
Alta
Tiempo de respuesta lento e ineficiente
El sistema es manual
Se realiza Registrar documentos de los alumnos Alta Tiempo de respuesta y carga del trabajo Manualmente a medio ciclo y al final del ciclo
44
Universidad Nacional de Ucayali No se cuenta Consultar estado de los alumnos. Alta Tiempo de respuesta con un historial en formato digital de los alumnos
Fuente: Elaboracin propia A.4 Objetivos de Modelamiento del Negocio Proceso de Preparacin de documentacin Registrar Facultad Registrar Escuela. Registrar alumno. Registrar Director de Practicas.
Proceso de control Registrar ingreso de Documentos . Registrar Plan de trabjao Proceso de Gestin Acadmica Consultar avance d e s u d o c u m e n t o s
Proceso de Administracin General Registrar usuarios del sistema.
45
Universidad Nacional de Ucayali A.5 Rangos de Calidad Disponibilidad: El Sistema de control deber estar disponible las 24 horas del da en un Servidor Web para la atencin de los usuarios del sistema. Uso: El Sistema de control ser fcil de usar con interfaces sencillas y
entendibles para el usuario.
A.6
Panorama del Producto Perspectiva: El Sistema de Control De Documentacion de Practicas Pre-
Profesional se implementar en la PCs en un rea adecuado de la Universidad Nacional de Ucayali. Cada usuario tendr acceso al sistema conectndose con su nombre de usuario y contrasea.
Restricciones: El sistema de Control no realizara lo siguiente: A.7
El sistema no incluye control de almacn de equipos de laboratorio. No compartir la base de datos de escalafn, Admisin, biblioteca. No admite traslado externo e interno (convalidacin). No admite grupo de alumnos por cursos. El sistema no contempla la reprogramacin de cursos. Requerimientos A.7.1 Funcionales
Un requerimiento funcional es la descripcin de lo que el sistema debe hacer o una funcionalidad que debe proveer. A continuacin se listan los requerimientos funcionales del sistema: El registrador es un perfil de un nivel de registro, debe ingresar la informacin del documento en el sistema y adjuntar el documento digitalizado. Si el documento de trmite tiene un documento de referencia el sistema debe mostrar la informacin contenida en la interfaz con el sistema de referencia correspondiente. El sistema seleccionar el flujo de trmite que debe seguir el documento dependiendo del nivel de registro en que se encuentre, del tipo de documento de referencia al que se encuentre relacionado (tambin existe un flujo cuando el documento no tiene referencia) y a la unidad responsable del documento. El flujo de aprobacin que deber seguir el documento de trmite ser definido por el sistema. El registrador puede cambiar los datos generales del documento de trmite en caso de error de registro. El registrador enva el documento de trmite al siguiente nivel del flujo de
46
Universidad Nacional de Ucayali aprobacin cuando concluye satisfactoriamente el registro. El encargado de unidad es un perfil del nivel unidad, pueden revisar y aprobar los documentos de trmite que lleguen a su nivel. El encargado de unidad enva el documento de trmite al siguiente nivel del flujo de aprobacin cuando concluye satisfactoriamente la revisin. El documento de trmite puede ser devuelto desde cualquier nivel al nivel de registro correspondiente. El trmite del documento puede ser anulado en cualquier nivel. El acceso al software estar restringido mediante una clave de acceso al sistema que nicamente contarn los que participen en este y as mantener una mayor seguridad de la informacin.
A.7.2
No Funcionales
Un requerimiento no funcional es la especificacin de cmo debe ser implementado el sistema. A continuacin se listan los requerimientos no funcionales del sistema. El sistema debe tener una interfaz de usuario amigable e intuitivo. Se debe poder acceder al sistema desde cualquier computador, sin importar el sistema operativo o navegador de Internet. El tiempo de respuesta del sistema no debe exceder el time-out que el navegador WEB tiene para respuestas HTTP, y debe estar dentro de los lmites de la intranet institucional. Usar la plataforma J2EE y el gestor de base de datos MySQL. El sistema no debe ser demasiado pesado. Los tiempos de carga deben ser mnimos. Las tareas deben estar muy bien distribuidas para el usuario del sistema. Las consultas de informacin de cualquier tipo dentro del sistema, debern realizarse de manera veloz. El sistema debe realizar copias de seguridad de informacin importante e imprescindible para el mismo. El acceso a la informacin del sistema en su totalidad deber ser realizado nica y exclusivamente por el administrador de la institucin (director). El sistema debe ser de fcil entendimiento para el usuario evitando complicaciones. Se har uso de un servidor local con el propsito de evitar colas al momento del seguimiento del trmite documentario.
B. PLAN DE DESARROLLO DEL SOFTWARE B.1 INTRODUCCIN B.1.1 Propsito El objetivo de este Plan de Desarrollo de Software es definir las actividades realizadas durante el desarrollo de las iteraciones requeridas para llevar a cabo el Sistema Propuesto (Control de Documentos de Practicas PreProfesionales).
47
Universidad Nacional de Ucayali B.1.2 Alcance Este Plan de Desarrollo de Software sirve de base para ser usado en el desarrollo del proyecto de implementacin de un Sistema de Matrcula va web.
B.1.3
Referencias Las referencias aplicables son: La visin para la implementacin del Sistema de Control De la documentacin de practicas pre-profesionales.
B.2
LA APRECIACIN GLOBAL DEL PROYECTO B.2.1 Propsito del Proyecto, Alcance y Objetivos
48
Universidad Nacional de Ucayali El propsito, alcance y objetivo de este Plan de Desarrollo de Software es definir las fases e iteraciones requeridas para implementar el Sistema a Realizar.
B.2.2
Entregables del Proyecto. Los entregables siguientes se desarrollaran durante el proyecto Tabla N 05 ENTREGABLES DEL PROYECTO
FASES
WORKFLOWS
ARTEFACTOS Documentos de visin. Plan de desarrollo de Software. Modelo de Use Case del Negocio. Modelo de Use Case. Especificacin de los Use Case. Diagrama de Colaboracin. Paquetes del Diseo. Diagrama de Clases. Diagrama de Secuencia.
INICIAL
MODELO DEL NEGOCIO REQUERIMIENTOS
ELABORACIN ANLISIS Y DISEO
Fuente: Elaboracin propia. B.3 LA ORGANIZACIN DEL PROYECTO B.3.1 Estructura Orgnica El trabajo comprende el anlisis y diseo de un de estudiante practicante de Ingeniera de Sistemas y un Asesor Ingeniero de Sistemas (docente), para el desarrollo del proyecto.
B.3.2
Interfaces Externas El Encargado del proyecto tambin actuar recprocamente con otro stakeholder para solicitar las entradas y revisin de los datos e identificar mejor el manejo de informacin.
49
Universidad Nacional de Ucayali B.3.3 Papeles y Responsabilidades La tabla siguiente identifica las unidades orgnicas que sern responsables para cada uno de los flujos de trabajo, y el detalle de los procesos de apoyo.
Tabla N 06 PAPELES Y RESPONSABILIDADES
PAPEL Practicante(Encargado del Proyecto)
RESPONSABILIDAD Responsabilidad del manejo del flujo del sistema y de direccionar el proyecto. Responsable principal de manejar el modelado y el flujo de trabajo de los requisitos, proporciona el apoyo en la organizacin y control de tareas de Proyecto.
Responsable principal para el anlisis y diseo y aplicacin
Asesor del Proyecto
Realiza
la
asesora, de
seguimiento entregables
Y de
correcciones proyectos.
Fuente: Elaboracin propia
B.4
El Proceso de Direccin B.4.1 Estimacin del Proyecto
Las estimaciones del proyecto son basadas en el Estudio de Factibilidad aplicado al proyecto. El tiempo y el esfuerzo estimado en este informe es la base del presupuesto del proyecto y horario.
B.4.2
Plan de Proyecto A) Plan de la Fase Tabla 07.- FASES DEL PROYECTO FASE DESCRIPCIN En esta Etapa se define el modelo INICIO del negocio, los requerimientos del producto, se elabora el plan de desarrollo de
50
Universidad Nacional de Ucayali Software. La fase de Elaboracin analizar los requisitos y se desarrollar el ELABORACIN prototipo arquitectnico que
probar la viabilidad y actuacin de la arquitectura
Fuente: Elaboracin propia B.5 Recursos para el Proyecto:
B.5.1
Plan de Adquisicin de Recursos
La UNU deber asignar a personal especializado para lograr el objetivo. B.5.2 Entrenamiento que se planean Se entrenar al responsable en las siguientes habilidades, al comienzo de las actividades del plan: Anlisis Orientado al Objeto Proceso Unificado Racional Java Net beans 7.2 SQL Server 2005 B.6 Presupuesto:
El siguiente presupuesto se basa en estimaciones inciales
51
Tabla N 08.- PRESUPUESTO DEL PROYECTO.
Sistema de Matricula y Notas Trabajo del Personal Actividades Desarrollo del Sistema de Matrcula Esfuerzo 3200horas/ hombres *Use Case Total Trabajo del personal Costo $ 4500.00
Gastos de Aprovisionamiento Transporte Servicios Materiales Otros gastos directos Total Gastos de Aprovisionamiento: Total del Presupuesto
Fuente: Elaboracin propia B.7 ENTORNO DE TRABAJO
$ 250.00 250.00 300.00 300.00 $ 1100.00 $ 5600.00
B.7.1 Informacin de Servidores Para elegir el tipo de servidor se ha tenido en consideracin el software que se instalar en l y las caractersticas Actuales del Sistema Operativo (Windows Server 2003). Este esta instalado en el Centro de Cmputo e Informtica
Tabla N 09 CARACTERSTICAS DEL SERVIDOR DE BASE DE DATOS.
Procesador Memoria Memoria Bus entrada/Salida Puerto
Intel Xeon IV 3.60 GHz. Cach Interna 1GB RAM 2GB PCI/EISA 1 Paralelo, 2 Seriales
52
Universidad Nacional de Ucayali Puerto Disco Duro Unidad CD-ROM Unidad de Diskettes Tarjeta de RED Tarjeta Video Monitor : Mouse: Teclado 3 USB 5 discos de 180 GB SCSI Lectora 48x 3 1.44MB Dual Gigabit Ethernet 10/100 Base T Ati Radeon 7000-M 16mb Sdram LG 17 Sleek 2 botones Genius PS/2
Fuente: Elaboracin propia Tabla N 10 CARACTERSTICAS DEL SERVIDOR WEB. Procesador Memoria Memoria Bus entrada/Salida Puerto Puerto Disco Duro Unidad CD-ROM Unidad de Diskettes Tarjeta de RED Tarjeta Video Monitor : Mouse: Teclado Fuente: Elaboracin propia Intel Xeon IV 3.40 GHz. Cach Interna 512MB RAM 1GB PCI/EISA 1 Paralelo, 2 Seriales 4 USB 1 disco de 73.4 GB SCSI Lectora 48x 3 1.44MB Gigabit Ethernet 10/100/1000 Base T PCI 7000-M 16MB SDRAM LG 15 Genios 2 botones Genios PS/2
53
5.1REQUERIMIENTOS

a) Modelo Use Case.

El proyecto consiste en un sistema de gestin de registro, adems de la gestin va web.
El mbito de gestin de la institucin est referido a la programacin, brindar informacin, realizar trmites y registrar los mismos.
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ver
uc Modelo deVersion Casos de Uso EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial EA 8.0 Unregistered Trial Ver
Modelo de Casos de Uso
Administrar
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered EA 8.0 Unregistered Trial Ver Documento Trial Version
Consultar EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ver Documento
Administrador
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered EA 8.0 Unregistered Trial Ver Gestion de RegistroTrial Version
de Referencia
include EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ver Buscar Documento
include EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ver Consultar Documento Via ExtraNet
Anlisis y Diseo Preliminar
En base a los casos de uso mencionados anteriormente,Trial se procede a generar los diagramas de EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Version EA 8.0 Unregistered Trial Ver robustez. Aqu se detalla cada gestin paso a paso dentro del sistema.
5.11Diagramas de Robustez: Consultar Documento.
54
Descripcin El caso de uso permite consultar los documentos en los que tenga autorizacin el usuario. Actores: Administrador. Precondicin El usuario debe encontrarse dentro del sistema.
Flujo Bsico Consultar documento
1. El caso de uso comienza cuando el usuario ingresa a la opcin Documento > Consulta. 2. El sistema le muestra un formulario con los siguientes criterios de bsqueda: a. Nmero de documento fsico (tipo, serie y nmero del documento fsico) b. Periodo de emisin del documento. c. Nmero de documento de referencia (tipo y nmero del documento de referencia) d. Remitente. Incluir Buscar remitente. e. Nmero de trmite f. Estado h. Clasificacin del trmite 3. El usuario selecciona uno o ms criterios. 4. El usuario selecciona la opcin Consultar. 5. Si el usuario coloc el nmero de documento fsico el sistema automticamente le mostrar la informacin del documento indicado y el caso de uso se da por finalizado. 6. Si el usuario coloc el nmero de trmite el sistema automticamente le mostrar la informacin del documento indicado y el caso de uso se da por finalizado. 7. Si el usuario coloc el nmero de documento de referencia el sistema automticamente le mostrar la informacin del documento indicado y el caso de uso se da por finalizado. 8. Caso contrario el sistema mostrar un listado con los documentos que cumplan los criterios seleccionados. Este listado mostrar los siguientes datos: a. Nmero de trmite b. Nmero de documento de referencia (tipo y nmero). c. Remitente (DNI, R.U.C. y razn social). d. Nmero de documento fsico (tipo, serie y nmero). g. Nivel actual h. Estado actual.
55
9. El usuario selecciona el nmero de trmite que desea visualizar.
10. El sistema le mostrar informacin del documento indicado, y se da por finalizado el Version E A 8.0 Unregistered Trial Version EAtoda 8.0 la Unregistered Trial Version EA 8.0 Unregistered Trial caso de uso.
A 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E
Pos condicin: El usuario el documento deseado. A 8.0 Unregistered Trial Version EA visualiza 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E
uc C-U Requerimientos: Consultar Documento A 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E
C-U Requerimientos: Consultar Documento
Documento
A 8.0 Unregistered Trial Version EA 8.0 Unregistered Consultar Trial Version EA 8.0 Unregistered Trial Version E Buscar Documento
include
A 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E Administrador
5.1.2Diagramas de Robustez: Gestin de Registro.
Descripcin El caso de uso permite registrar, editar y anular el EA trmite un documento de Version E A 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version 8.0 de Unregistered Trial pago a proveedores en el sistema y los datos de un alumno. Actores: Administrador.
Precondicin El usuario encontrarse dentro del sistema, y tener aun nivel de Version E A 8.0 Unregistered Trial Version EA debe 8.0 Unregistered Trial Version EA 8.0 accesos Unregistered Trial registro.
FlujoTrial Bsico Gestin de Registros A 8.0 Unregistered Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E 1. El caso de uso comienza cuando el usuario ingresa a la opcin Documento > Registro.
2. El Trial sistema le muestra un 8.0 formulario donde le sugiere los siguientes A 8.0 Unregistered Version EA Unregistered Trial Version EA campos: 8.0 Unregistered Trial Version E a. Nmero de trmite, que es el identificador del documento dentro del sistema, le sugiere el correlativo que son los 4 ltimos dgitos, los cuales pueden ser modificados.
(Automtico) A 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E b. Fecha de recepcin, que contendr la fecha actual. d. Siguiente nivel, este campo ser sugerido por el sistema despus que el usuario haya
seleccionado Flujo permitido. A 8.0 Unregistered Trial Version el EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E 3. El usuario debe ingresar los siguientes datos: a. Nivel, el sistema le mostrar un listado de niveles donde puede registrar un
A 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version E 56
documento b. Nmero de documento de referencia, compuesto por el tipo de documento de referencia y el nmero de documento. Incluir Buscar documento de referencia. c. Nmero de documento fsico, compuesto por el tipo de comprobante o documento de pago slo si no fue sugerido por el sistema despus de seleccionar el documento de referencia (slo se sugiere en caso se cuente con interfaz con el sistema correspondiente), serie y nmero del documento fsico enviado por el emisor. d. Fecha de emisin del documento fsico. e. Archivo, que contenga el documento digitalizado. f. Observaciones, este campo ser llenado si el usuario desea. Ingresados por el usuario los siguientes datos: a. Remitente, cdigo de RUC. Incluir Buscar Remitente. d. Clasificacin del trmite. 4. El sistema seleccionar el flujo de trmite que debe seguir el documento dependiendo del nivel de registro en que se encuentre, del tipo de documento de referencia al que se encuentre relacionado (tambin existe un flujo cuando el documento no tiene referencia) y a la unidad responsable del documento. 5. El usuario selecciona la opcin Grabar. 6. El sistema verifica que todos los datos obligatorios sean llenados, en caso exista algn campo con un valor invlido el sistema enviar un mensaje de alerta. 7. Si todas las verificaciones son correctas el sistema almacenar la informacin.
Pos condicin: El documento es almacenado en el sistema y se encuentra enestado REGISTRADO. Flujo Alternativo Modificar documento 1. El usuario se encuentra visualizando un documento y selecciona la opcin Editar. 2. El sistema le muestra un formulario donde le permite modificar los siguientes datos: a. Nmero de documento de referencia b. Nmero de documento fsico, se puede modificar la serie y nmero del documento. c. Fecha de emisin. d. Flujos permitidos.
57
e. Archivo. f. Observaciones.
Caso contrario el usuario puede modificar los siguientes campos: a. Remitente. d. Clasificacin del trmite. 3. El usuario realiza los cambios que crea conveniente. 4. El usuario selecciona la opcin Grabar. 5. El sistema verifica que todos los datos obligatorios sean llenados, en caso exista algn campo con un valor invlido enviar un mensaje de alerta. 6. Si todas las verificaciones son correctas el sistema almacenar la informacin modificada.
Pos condicin: El documento es modificado.
Flujo Alternativo Enviar documento 1. El usuario se encuentra visualizando un documento y selecciona la opcin Enviar. 2. El sistema le solicita que confirme que desea enviar el documento hacia el siguiente nivel del flujo correspondiente. 3. El usuario selecciona la opcin Aceptar. 4. El sistema es enviado hacia el siguiente nivel del flujo correspondiente y se muestra el documento con el estado EN PROCESO.
Pos condicin: El documento se encuentra en el siguiente nivel del flujo correspondiente en estado EN PROCESO.
Flujo Alternativo Anular el trmite del documento 1. El usuario se encuentra visualizando un documento y selecciona la opcin Anular. 2. El sistema le solicita que confirme que desea anular el trmite del documento. 3. El usuario selecciona la opcin Aceptar. 4. El sistema muestra el documento con el estado ANULADO.
58
Universidad Nacional de Ucayali EA 8.0 Unregistered Trial
Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria
EA 8.0 Unregistered Trial Version en EA 8.0 Unregistered Pos condicin: El documento se encuentra estado ANULADO. Trial Version EA 8.0 Unregistered Tria
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria
uc C-U Requerimientos: Registrar Documentos
C-U Requerimientos: Gestion de Registros
buscar alumno EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria
include EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria registrar alumno Buscar Documento
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria de Remitente
include
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria Buscar Documento
de Referencia Administrador
include Gestion de Registro registrar documentos EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria include
include Modificar
Anular
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria 5.1.3Diagramas de Robustez: Administrar Documento
Descripcin: El caso de uso permite aprobar, anular el trmite, devolver y enviarlos EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria documentos que son revisados en el nivel unidad en el que se encuentre el actor. EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria Actores: Administrador.
Precondicin El usuario debe encontrarse delUnregistered sistema, y tener accesos aun nivel del Unregistered tipo EA 8.0 Unregistered Trial Version dentro EA 8.0 Trial Version EA 8.0 Tria unidad. EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria
8.0 Unregistered Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria FlujoEA Alternativo Aprobar Trial documento individual
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria 1. El usuario se encuentra visualizando un documento, y selecciona la opcin Aprobar. EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria 2. El sistema le solicita que confirme que desea aprobar el documento.
EA 8.0 selecciona Unregistered Trial Aceptar. Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria 3. El usuario la opcin
4. El sistema guarda el registro de la aprobacin del documento en el nivel en el que se EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Tria
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 59 Unregistered Tria
encuentra, enva el documento al siguiente nivel del flujo correspondiente. 5. El sistema muestra el documento aprobado.
Pos condicin: El documento es enviado al siguiente nivel del flujo correspondiente y se encuentra en estado EN PROCESO.
Flujo Alternativo Anular el trmite del documento 1. El usuario se encuentra visualizando un documento, y selecciona la opcin Anular. 2. El sistema le solicita que confirme que desea anular el trmite del documento. 3. El usuario selecciona la opcin Aceptar. 4. El sistema muestra el documento con el estado ANULADO, y notifica al nivel donde se encuentre el documento fsico que debe gestionar la entrega al proveedor.
Pos condicin: El documento se encuentra en estado ANULADO.
Flujo Alternativo Devolver documento 1. El usuario se encuentra visualizando un documento, y selecciona la opcin Devolver. 2. El sistema le solicita que confirme que desea devolver el documento al nivel de registro correspondiente. 3. El usuario selecciona la opcin Aceptar. 4. El sistema muestra el documento con el estado REGISTRADO en el nivel de registro, y lo marca como DEVUELTO.
Pos condicin: El documento es devuelto al nivel de registro, se encuentra enestado REGISTRO y marcado como DEVUELTO
60
Unregistered Trial Version EA 8.0 Unregistered Trial Version Universidad Nacional de Ucayali EA 8.0 Unregistered Trial Version
EA 8.0 Unregistered Trial Ve
Unregistered Trial Version
Unregistered Trial Version EA 8.0 Unregistered Trial Version uc C-U Requerimientos: Administrar Documento
Unregistered TrialC-U Version EAAdministrar 8.0 Unregistered Trial Version Requerimientos: Documento
Aprobar EA 8.0 Unregistered Trial Version
EA 8.0 Unregistered Trial Version

include

C-U Requerimientos: Administrar Documento
EA 8.0 Unregistered Trial Version

Administrar Documento EA 8.0 Unregistered Trial Version include

Administrador
EA 8.0 Unregistered include Trial Version

Dev olv er EA 8.0 Unregistered Trial Version
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version
Unregistered 5.1.4Diagramas Trial Version EA 8.0 Unregistered TrialVa Version de Robustez: Consultar Documento Extranet EA 8.0 Unregistered Trial Ve EA 8.0 Unregistered Trial Version
Descripcin El caso de uso permite consultar los documentos en los que tenga autorizacin el Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ve usuario. Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ve Actores Administrador.
Precondicin El usuario debe dentro del sistema. Unregistered Trial Version EA 8.0encontrarse Unregistered Trial Version
Unregistered Trial Version EA 8.0 Unregistered Trial Version Flujo Bsico Consultar documento Unregistered Trial Version EA 8.0 Unregistered Trial Version
1.Trial El caso de uso comienza cuando el usuario ingresa a la opcin Documento > Consulta. Unregistered Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ve
2. El sistema le muestra un formulario con los siguientes criterios de bsqueda: Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ve e. Nmero de documento fsico (tipo, serie y nmero del documento fsico) Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ve f. Periodo de emisin del documento.
Unregistered Trial Version EAuno 8.0 Unregistered Trial Version 11. El usuario selecciona o ms criterios.
12. El usuario seleccio na la opcin Consultar. Trial Version EA 8.0 Unregistered Trial Ve Unregistered Trial Version EA 8.0 Unregistered 13. Caso contrario el sistema mostrar un listado con los documentos que cumplan los criterios Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Ve seleccionados. Este listado mostrar los siguientes datos:
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version
EA 8.0 Unregistered Trial Ve 61
a. Nmero de documento fsico (tipo, serie y nmero). b. Remitente (DNI, R.U.C. y razn social). e. Nivel actual f. Estado actual. i. Nmero de trmite j. Nmero de documento de referencia (tipo y nmero).
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Versio 14. El usuario selecciona el nmero de trmite que desea visualizar.
15. El sistema le mostrar toda la informacin del documento indicado, y se da por finalizado el caso de uso.
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Versio
Pos condicin: El usuario visualiza el documento deseado.
uc C-U Requerimientos: Consultar Documento Via ExtraNet
C-U Requerimientos: Consultar Documento Via ExtraNet
Via ExtraNet include
Documento Consultar Documento EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version Buscar EA 8.0 Unregistered Trial Versio de Referencia
Administrador EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Versio
5.2 Diseo Detallado
En este captulo se hace un diseo ms detallado y profundo del sistema, mediante esta son los diagramas de secuencia. 5.2.1Diagrama de Secuencia Diagrama de Secuencia Agregar Alumno
EA 8.0 Unregistered Trial Version EA control 8.0 Unregistered Trial de Version Unregistered herramienta que brinda el proceso de documentacin practicasEA Pre8.0 profesionales que Trial Versio
62
sd Diagrama de Secuencia Agregar Alumno
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
Form Modificar Alumno Jsp. Alumno S. Alumno C. Alumno T. ALumno EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T Administrador
1. Click en Agregar
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T Alumno()
2. Link()
3. build()
4. Mostrar()
5. Ingresar Datos()
6. Tiempo()
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T 7. Submit()
8. Crear() EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T 9. Crear()
10. Registrar()
5.2.2Diagrama de Secuencia Modificar Alumno EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T 63
sd Diagrama de Secuencia Modificar Alumno
Universidad Nacional de Ucayali EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
Form Modificar Alumno Jsp. Alumno S. Alumno Alumno T. ALumno EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA C. 8.0 Unregistered Trial Version EA 8.0 Unregistered T Administrador
1. Click en Modificar Alumno() 2. Link()
EA 8.0 Unregistered Trial Version EA3.8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T build()
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T 4. Mostrar()
5. Ingresar Datos()
6. Tiempo()
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T 7. Submit()
8. Modificar() EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
9. Modificar() EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T EA 8.0 Unregistered Trial Version 5.2Diagrama de Clases
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
El presente diagrama de clases fue reestructurado tomando en base los diagramas de EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T robusticidad y secuencia.
5.3Gestiones EA 8.0 Unregistered Trial Version
EA 8.0 Unregistered Trial Version EA 8.0 Unregistered Trial Version EA 8.0 Unregistered T
64
5.3.1Administrar Documento Este apartado est orientado para administrar los documentos de los alumnos. Individualmente, cada documento registrado cuenta con atributos como: Apellidos del alumno Nombres del alumno Tipo de practica Empresa a realizar las practicas Nombre del ejecutivo de la empresa a realizar las practicas Cargo del ejecutivo de la empresa Nombre del asesor de practicas Nombre de los jurados de la evaluacin
Adicionalmente se pueden tener informacin para contactar con ellos, por ejemplo: Direccin del alumno Telfono del alumno E-mail del alumno
5.3.2Consultar documento Para consultar un documento se tendr que buscar por datos especficos brindados a la hora del registro del documento. 5.3.3Registrar documento Para poder ser registrado el documento esta tendr que cumplir con los requisitos estandarizados por la facultad. 5.3.4Consultar documento va Extranet El administrador podr consultar el documento registrado en la base de datos desde cualquier punto de internet. 5.3.5Buscar documento de referencia El administrador tendr acceso a datos de otros documentos con mucha facilidad.
5.3.6Herramientas En el desarrollo de este proyecto se han utilizado las siguientes herramientas en cada mbito.
5.37Desarrollo
65
Netbeans apache Tomcat 6.020 Plataforma J2EE y el gestor de base de datos MySQL. 5.3.8Ejecucin El software requerido para la ejecucin del sistema es: 1. MySQL Y SQL SERVER Management como base de datos. 2. Netbeans para la ejecucin del proyecto. 3. Un navegador web (Internet Explorer Google Crome) para la actualizacin de datos y la visualizacin del sistema va web.
66
A) Diagrama de Paquetes
Preparar
documento s
Realizar Docume nto
interfaz
controladores
Entidad
Ges tion Academ ica
Administracion General
67
CONCLUSIONES
1.
Se llevo a cabo el anlisis y diseo del sistema mediante la utilizacin del Proceso Unificado de Rational y el Lenguaje de Modelamiento Unificado.
2.
La Implementacin se llevo a cabo respetando los principios de la arquitectura cliente servidor para lo cual se utiliz Java, Servlets, JSP y Microsoft SQL Server 2005
3.
Las Interfaces han sido desarrolladas de acuerdo al usuario, de manera que navegue por el sistema de modo fcil y sencillo.
RECOMENDACIONES 1. Se Recomienda Implementar el sistema de control De documentacin de practicas Pre-Profesional , personalizadas de acuerdo a la funcin de cada usuario. 2. Se recomienda Implementar el Sistema respetando los principios de la arquitectura cliente servidor utilizando Java, Servlets, JSP y Microsoft SQL Server 2005 3. 4. Se debe desarrollar Interfaces de acuerdo al gusto del usuario, de manera que navegue por el sistema de modo fcil y sencillo. Se debe realizar las pruebas correspondientes para verificar el correcto funcionamiento del sistema
BIBLIOGRAFA
1. CUEVA LOVELLE, Juan Manuel, Web Engineering, 1ra Edition, 2005 2. HAMILTON, Bill. Programming SQL Server 2005, 2005 3. HUNTER, Jason Java Servlet Programming, 2nd Edition, 2004
4. BOOCH, Grady; RUMBAUCH, Jim; JACOBSON Ivar. El Lenguaje Unificado de Modelado, 2000 5. CONALLEN, J. Building Web applications with UML, 2nd ed. Boston: AddisonWesley, 2003. 6. KRUCHTEN, Philippe. The Rational Unified Process And Introduction. Addison Wesley Iberoamericana,Canad, 2000. 7. KENDALL, Kenneth E; JULIE, E. Anlisis y Diseo de Sistemas, 3ra Edicin. Mexico, 1999. 8. LAUDON, Kenneth C; LAUNDON, Jane. Sistemas de Informacin Gerencial, Organizacin y Tecnologa , 7 edition, Prentice Hall, 2001. 9. PIATTINI, Mario; CALVO-MANZANO, Jos; CERVERA, Joaqun; FERNNDEZ, Lus. Anlisis y Diseo detallado de Aplicaciones Informticas de Gestin, 2000

Practica Hoy

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Practica Hoy

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad Nacional de Ucayali

UNIVERSIDAD NACIONAL DE UCAYALI

May R. Hoyos Tello Ing. Pascual Aguirre Gamboa

Pucallpa, 30 abril del 2013

Universidad Nacional de Ucayali

Universidad Nacional de Ucayali

CAPITULO I 1.1. 1.2 1.3 1.2

CAPITULO II 2.1 2.2 2.3

CAPITULO III 3.1

3.2 3.3 3.4 3.5

Universidad Nacional de Ucayali

Universidad Nacional de Ucayali

Universidad Nacional de Ucayali

Satisfacer las necesidades de informacin para la toma de decisiones.

Evaluar y supervisar la utilizacin de los recursos Informticos.

Universidad Nacional de Ucayali

CAPITULO II ASPECTOS GENERALES DE LA INSTITUCION

Universidad Nacional de Ucayali 2.1. RAZN SOCIAL.

UNIVERSIDAD NACIONAL DE UCAYALI

Universidad Nacional de Ucayali

2.3.2. Plano de Ubicacin.

FIGURA N 01. Ubicacin de la Universidad Nacional de Ucayali

Fuente: Universidad Nacional de Ucayali

Universidad Nacional de Ucayali

2.3.3. Organizacin. FIGURA N 02: Estructura Orgnica de la Universidad Nacional de Ucayali

Fuente: Universidad Nacional de Ucayali

2.3.4.1.3 Ofimtica. Office 2003. Office 2007.

Universidad Nacional de Ucayali

CAPITULO III FUNDAMENTO TERICO

Universidad Nacional de Ucayali

FIGURA N 03 ACTIVIDADES EFECTUADAS EN UN SISTEMA DE INFORMACIN

Fuente: Laudon, K; Laundon, J., 2002

Kenneth E. Kendall & Julie E. Kendall, 1999

Universidad Nacional de Ucayali

Fuente: HUNTER, Jason 2004.

CUEVA LOVELLE, Juan Manuel Web Engineering, 1ra Edition, 2005

Universidad Nacional de Ucayali

3.5.1 ARQUITECTURA CLIENTE SERVIDOR DE 2 CAPAS

Fig. N 05 ARQUITECTURA CLIENTE/SERVIDOR 2 CAPAS

ARQUITECTURA CLIENTE SERVIDOR DE 3 CAPAS

Fig. N 06 ARQUITECTURA CLIENTE/SERVIDOR 3 CAPAS

Fuente: HUNTER, Jason 2004 3.5.3 ARQUITECTURA N CAPAS

Bosak J. XML, Java and the future of the Web. http://www.xml.com/pub/a/w3j/s3.bosak.html

3.6.1 PRINCIPIOS BASICOS DEL RUP

3.6.1.2 Centrado en la arquitectura.

3.6.1.3 Proceso iterativo e incremental.

Universidad Nacional de Ucayali

Fig. N 08: ESTRUCTURA DEL RUP

Fuente: JACONSON, Ivar; RUMBAUG, James; BOOCH, Grady, 1999

Fig. N 10 REPRESENTACION DE UN CLASE

Fig. N 11 REPRESENTACION DE UNA INTERFAZ

Fig. N 12 REPRESENTACION DE UNA COLABORACION

Universidad Nacional de Ucayali Fig. N 13 REPRESENTACION DE UN CASO DE USO

Fig. N 15 REPRESENTACION DE UN COMPONENTE

Fig. N 16 REPRESENTACION DE UN NODO

Fuente: RUMBAUG, JACOBSON, BOCH, (1999)

Universidad Nacional de Ucayali

Fig. N 17 REPRESENTACION DE UNA INTERACCION

Fig. N 18 REPRESENTACION DE UN ESTADO

Fig. N 19 REPRESENTACION DE UN PAQUETE

Fuente: RUMBAUG, JACOBSON, BOCH, (1999)

Fuente: RUMBAUG, JACOBSON, BOCH, (1999)

Fuente: RUMBAUG, JACOBSON, BOCH, (1999)

Fig. N 23 REPRESENTACION DE UNA GENERALIZACION