Está en la página 1de 113

Académicos del laboratorio Validar docente. Validar alumnos.

Registrar las
prácticas de laboratorio realizados por los alumnos y docentes. Proceso de Gestión
de servicios No Académicos del laboratorio Registrar a los clientes (Agricultor e
investigador). Registrar las solicitudes y análisis de suelos y tejido vegetal
realizados. Reporte de los análisis realizados.

42
A.5. Rangos de calidad Disponibilidad: El Sistema de control de los procesos de la
información del laboratorio de suelos de la UNU, deberá estar disponible las horas
del día mientras haya actividades en la universidad nacional de Ucayali para la
atención de los usuarios.

Uso: El Sistema de control de los procesos de la información del laboratorio de


suelos de la UNU, deberá ser fácil de manejar con interfaces sencillas y
entendibles para el usuario.

A.6. Panorama del producto Perspectiva: El Sistema de control de los procesos de la


información del laboratorio de suelos de la UNU se implementará en el laboratorio
mencionado. Cada usuario tendrá acceso al sistema mediante un interfaz que les
permitirá registrar datos y acceder a la información que requiera en el en el
momento necesario, contando con un usuario y contraseña.

A.7. Requerimientos A.7.1. Funcionales • • • • • • Registrar Reactivos, equipos y


materiales de laboratorio. Registrar las solicitudes y los análisis de suelos y
tejido vegetal. Consultar análisis. Reporte de los análisis realizados. Reporte de
los clientes registrados (Agricultor, investigador). Reporte de los registros
Reactivos, equipos y materiales de laboratorio.

43
A.7.2. No funcionales • El sistema se desarrollará utilizando herramientas Web:
lenguaje de programación Java (Net Beans IDE 6.5.1), framework Visual Java Server
Faces, un Servidor Web TomCat y el manejador de Base de Datos SQL Server 2000. • •
• • Definir políticas de seguridad. Registrar niveles de seguridad. El tiempo de
respuesta por consulta se realice en tiempo real. Características del Servidor PIV
3.6 Ghz HD 180 GB Ram 3 GB. (Estos están más especificados en el punto
Características de hardware y software que tiene la Universidad Nacional de
Ucayali.)

44
B. PLAN DE DESARROLLO DEL SOFTWARE B.1. Introducción B.1.1. Propósito El objetivo
de este Plan de Desarrollo de Software es definir las actividades realizadas
durante el desarrollo de las fases e iteraciones requeridas para llevar a cabo el
Sistema propuesto.

B.1.2. Alcance Este Plan de Desarrollo de Software describe el plan global a ser
usado por el personal encargado del proyecto para desarrollar el proyecto de
Implementación de un sistema de control de los procesos de la información del
laboratorio de suelos de la UNU, se describirán los detalles de los procesamientos
individuales del plan. Los planes que se dan en este documento se basan en los
requisitos del producto como esta especificado en el documento de visión.

B.1.3. Referencias Las referencias aplicables son: La visión para el “Sistema de


control de los procesos de la información de laboratorio de suelos de la UNU”
B.1.4. Apreciación Global En este Plan de Desarrollo de Software contiene la
Información siguiente: Proyecto de Apreciación Global: Proporciona la descripción
del proyecto, alcance y objetivos. También determina el entregable que se espera en
el proyecto en determinados periodos.

45
El proceso de Dirección: Explica el costo estimado y lo fija, define las fases
mayores e hitos para el proyecto, y describe el modo de supervisión para el
proyecto. Los planes del proceso técnico: Proporciona un panorama global del
proceso de desarrollo de software, incluso los métodos, herramientas y técnicas
para ser seguido.

B.2. La apreciación Global del Proyecto B.2.1. Propósito del Proyecto, Alcance y
Objetivos El propósito, alcance y objetivo de este Plan de Desarrollo de Software
es definir las actividades realizadas durante el desarrollo de 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.

Cuadro 07: Entregables del Proyecto FASES WORKFLOWS INICIAL MODELO DEL NEGOCIO
ARTEFACTOS Documentos de visión. Plan de Desarrollo de

Software. Modelo de Use Case del Negocio. Modelo de Dominio del

Problema.

46
REQUERIMIENTOS -

Modelo de Use case. Especificación de los Use case.

ELABORACIÓN ANÁLISIS Y DISEÑO CONSTRUCCIÓN ANÁLISIS DE DISEÑO -

Diagrama de colaboración. Prototipo arquitectónico. Diagrama de clases. Diagrama de


secuencia. Paquetes del diseño. Diseño de Base de Datos. Prototipo Inicial.

B.2.3. Evolución del Plan de desarrollo de software El Plan de Desarrollo de


Software se revisará anterior a la salida de cada proceso de iteración. B.3. La
organización del proyecto B.3.1. Estructura orgánica El trabajo comprende de un
practicante de la Facultad de Ingeniería de Sistemas y de Ingeniería Civil y un
Asesor (Docente), para el desarrollo del proyecto.

B.3.2. Interfaces Externas El equipo del proyecto también actuará recíprocamente


con otros stakeholders para la especificación, revisión y validación artefactos
generados.

B.3.3. Papeles y Responsabilidades La tabla siguiente identifica las unidades


orgánicas que serán responsables para cada uno de los flujos de trabajo, y el
detalle de los procesos de apoyo.

47
Cuadro 08: Papeles y Responsabilidades PAPEL RESPONSABILIDAD Responsabilidad del
manejo del flujo del producto de dirección del proyecto global. Responsable
principal de manejar el modelado comercial y el flujo de trabajo de los requisitos,
proporciona el apoyo y entradas de Workflow de ESTUDIANTE Dirección de Proyecto.
Responsable principal para el análisis y diseño, aplicación, configuración,
capacitación y flujos de trabajo de ambiente. Proporciona el apoyo al workflow de
dirección de proyección. Es el responsable para manejar la prueba, y workflows del
Despliegue. ASESOR DEL PROYECTO Realiza la asesoría, seguimiento y correcciones de
entregables de proyectos.

B.4. El Proceso de Dirección B.4.1. Estimación 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 El Sistema de control para mejorar los
procesos de la información del laboratorio de suelos de la UNU será desarrollado
usando un acercamiento escalonado teniendo en cuenta las cuatro fases de

48
interacción. Las fases y el horario relativo se muestran en la tabla siguiente:

Cuadro 09: Plan de procesos de desarrollo de acuerdo a fases FASE Fase de Inicio
(10%) EMPIEZA Martes 01 Octubre del 2009 Fase de la Elaboración (30%) Lunes 28 de
Setiembre del 2009 Fase de la Construcción (10%) TERMINA Martes 27 de Octubre del
2009 Lunes 26 de Octubre del 2009

Lunes 26 de Octubre del Lunes 07 de Diciembre del 2009 2009

Cuadro 10: Fases del proyecto e hitos principales FASE DESCRIPCIÓN


Determina

HITO
la factibilidad del proyecto desde un punto de

En esta etapa se define el modelo del negocio, producto, INICIO los se


requerimientos elabora el Plan del de

vista del negocio. Se definen los requerimientos, características, claves y

Desarrollo de Software.

principales restricciones. Estima los recursos (tiempo, costos del ambiente de


desarrollo).

49
La fase de elaboración analizará los requisitos y se desarrollará el prototipo
arquitectónico. En la realización todos de los la fase use de case El hito del
prototipo

elaboración

seleccionados para una versión 1.0 habrán completado el análisis y plan.


ELABORACIÓN Además se habrán analizado los use case de alto riesgo que para una
versión 2.0 ya se habrán diseñado. El prototipo arquitectónico probará la
viabilidad y actuación de la arquitectura que se requiere para versión 1.0

arquitectónico marca el término de la fase de la elaboración.

Se CONSTRUCCIÓN

desarrollará

un

prototipo

del

sistema.

El prototipo contendrá con todos los elementos necesarios para una implementación
inicial.

b. Horario del proyecto El horario del proyecto que contiene el nombre de las
labores, las fecha de inicio y fin se muestra a continuación.

Cuadro 11: Tareas del proyecto TAREAS Modelamiento del negocio Requerimientos
Análisis y Diseño EMPIEZA 01/10/09 28/10/09 17/11/09 TERMINA 27/10/09 13/11/09
25/12/09

50
B.5. Recursos para el Proyecto B.5.1. Plan de Adquisición de Recursos La UNU ha
proyectado asignar a personal especializado para lograr el objetivo.

B.5.2. Entrenamiento que se planean Se entrenará al equipo del proyecto en las


siguientes habilidades, al comienzo de las actividades del plan: Análisis Orientado
al Objeto. Proceso Unificado Racional 2003. Java Netbeans 6.5 SQL Server 2000

51
B.6. Presupuesto El siguiente presupuesto se basa en estimaciones iniciales:

Cuadro 12: Presupuesto (Ver anexo 1)

SISTEMA DE CONTROL PARA MEJORAR LOS PROCESOS DE LA INFORMACIÓN DE LOS ANÁLISIS DE


SUELOS EN UN LABORATORIO DE UNA UNIVERSIDAD PUBLICA Trabajo del Personal
Actividades Esfuerzo Costo

Desarrollo del Sistema Total de Trabajo del Personal de Control 3 meses


aproximadamente (con un pago de S/. 600 por mes) S/. 1,800

Gastos Aprovisionamiento

de

Transporte Servicios Materiales Otros gastos directos

S/. 200.00 S/. 200.00 S/. 100.00 S/. 100.00

Total

de

Gastos

de

S/. 600.00

Aprovisionamiento

Total de Presupuesto

S/. 2,400.00

52
B.7. Entorno de Trabajo B.7.1. Elección de Equipos y Accesorios de la Red LAN
B.7.1.1. Elección del Servidor Para elegir el tipo de servidor se ha tenido en
consideración los equipos existentes dentro de la Universidad Nacional de Ucayali,
el sistema operativo instalado es Microsoft Windows Server 2003 con un servidor
Apache TomCat 1.5.

Servidor de Base de Datos

Cuadro 13: Servidor BD Procesador Memoria Memoria Bus entrada/salida Puerto Puerto
Disco Duro Unidad CD-ROM Unidad de Diskettes Tarjeta de RED Tarjeta Video Intel
Xeon IV 3.60 Ghz. Caché Interna 1 GB RAM 2 GB PCI/EISA 1 Paralelo, 2 Seriales 3 USB
5 discos de 180 GB SCSI Lectora 48x 3½ 1.44 MB Dual Gigabit Ethernet 10/100 Base T
ATI RADEON 7000-M 16MB SDRAM

Monitor Mouse Teclado

LG 17” Sleek 2 botones Genius PS/2

53
Servidor Web

Cuadro 14: 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 Intel Xeon IV 3.40 Ghz. Caché Interna 512 MB RAM 1 GB PCI/EISA 1
Paralelo, 2 Seriales 4 USB 1 disco de 73.4 GB SCSI Lectora 48x 3½ 1.44 MB Gigabit
Ethernet 10/100/1000 Base T PCI 7000-M 16MB SDRAM LG 15” Genius 2 botones Genius
PS/2

54
B.8. Vistas de Use Case B.8.1. Modelo de Caso de Uso del Negocio

Figura 06: Modelo de Caso de Uso del Negocio

Tecnico de laboratorio

Gestión de Registros del laboratorio Jefe de Alm acen

Docente

Gestión de Servicios Académicos

Jefe de Laboratorio

Alumno Gestión de Servicios No Académ icos Persona (Terceros)

Agricultor

Investigador

55
B.8.2. Modelo de Objetos del Negocio a) Gestión de Registros del Laboratorio Figura
07: MON Registrar Reactivos, Equipos, Instrumental y Materiales del Laboratorio.

Equipo_Laboratorio CRUD

Instrumental CRUD

Lee Tipo_Reactivo_InsumoQuimi

CRUD Tecnico de laboratorio


(f rom Business Use-Case Model)

Registrador_Re_Eq_Ma de Laboratorio Reactivo_InsumoQuimi Lee

CRUD

Tipo_Material_Labora

Material_Laboratorio

56
b) Gestión de Servicios Académicos Figura 08: MON Registrar Análisis de Suelos
Docentes_Alumnos

Lee Solicitud

Docente
(f rom Business Use-Case Model)

CRUD

Solicitud_Doce_Alum Registrador_Analisis

Genera Alumno
(f rom Business Use-Case Model)

Reporte

57
c) Gestión de Servicios No Académicos Figura 09: MON Registrar Análisis de Suelos
Terceros (Investigador y agricultor)

Usuarios Lee

Lee TipoUsuario

Lee

Tecnico de laboratorio
(f rom Business Use-Case Model)

Solicitud Registrador_Solicitudes_Analisis CRUD

CRUD

Solicitud_Investigador

Solicitud_Agricultor Genera

Reporte

58
B.8.2. Modelo de Dominio Figura 10: Modelo de Dominio.

1..* Usuarios 1 1..*

Equipo_Laboratorio

Instrumental

1 Tipo_Usuario 1

1..*

Materi_Laboratorio

Tipo_Materi_Labora

1..* 1 Solicitud 1

Reactivos_InsumoQuimico

Tipo_ReactivoInsumoQuimico

1..* Solici_Agricultor

1..* Solici_Investiga

1..* Solici_DocenteAlumno

1 Reporte 1 1

59
B.9. Descripción de Procesos del Negocio Cuadro 15: Proceso del Negocio.

ESTEREOTIPO

DESCRIPCIÓN Se registran los análisis de suelos realizados por los docentes y


alumnos en sus respectivas

Gestión de Servicios Académicos

solicitudes,

además

les

permitirá

realizar

consultas de sus registros. Se registran los equipos de laboratorio, el


instrumental, los reactivos-Insumos químicos y Gestión de Registros del laboratorio
los laboratorios de laboratorio.

Se

registran

las

solicitudes

de

análisis

prestados a terceros (en este caso a los Gestión de Servicios no Académicos


agricultores y los investigadores). También se realizaran consultas sobre esos
registros.

60
6.2. FASE ELABORACIÓN 6.2.1. REQUERIMIENTOS A. Modelo de Caso de Uso

Figura 11: MCU Gestión de Servicios Académicos.

Docente

Registrar_Solicitud

Alumno

<<include>>

<<include>> Registrar_SoliciDocenAlumno

Buscar_SoliDoc enteAlumno

<<extend>> <<extend>>

<<extend>>

Crear_SoliciDoc enteAlumno Modificar_SoliD ocenteAlumno

Eliminar_SoliciD ocenteAlumno

61
Figura 12: MCU Gestión de Servicios No Académicos.

TecnicoLaboratori o

Registrar_Solicitud

<<include>>

<<include>>

<<include>>

Buscar_Solic Investigador <<include>>

Buscar_Solic Agricultor <<extend>>

Solicitud_Agricultor

<<extend>>

<<extend>> Crear_SolicI nvestigador

Crear_SolicA gricultor Solicitud_Investigador

<<extend>>

Eliminar_Solic Agricultor

<<extend>> <<extend>>

Modificar_Soli cAgricultor

Modifi_SolicI nvesti Eliminar_Soli cInvesti

62
Figura 13: MCU Gestión de Registros del laboratorio.
<<include>> <<extend>> Crear_EquiL abora Buscar_Instr umental

Buscar_Equi Labora <<extend>>

Registrar_EquipoLaboraorio <<extend>>

<<include>> Crear_Instru mental <<extend>>

Eliminar_Equ iLabora

Modificar_Eq uiLabora

Registrar_Instrumental

<<extend>>

<<extend>>

Modificar_Intr umental TecnicoLaboratori o

Eliminar_Instr umental

Crear_ReacIns umoQui <<include>> Tipo_MateriLabora Registrar_MaterialLabora


<<include>> <<extend>> <<extend>> <<include>> Buscar_Materi Labora Modificar_Mate
riLabora Tipo_ReactiInsumoQui Registrar_ReactivoInsumQui <<extend>>

Cear_MateriLa bora <<extend>>

<<extend>>

<<extend>>

<<include>> Eliminar_ReacI nsumoQui Eliminar_Mater iLabora Buscar_ReacIn sumoQui


Modificar_Reac InsumoQui

63
B. Diagrama de Actividades Figura 14: DA Registrar Materiales (Equipos,
ReactivosInsumosQuimicos, Materiales y el Instrumental) del Laboratorio

Tecnico de Laboratorio

Proceso tecnico

inicio

Recoger Material de Laboratorio

Clasificar Material de Laboratorio(Equipos, Materiales, Reactivos-InsumoQuimico y


el Instrumental)

Si

No

Rechazar Material de Laboratorio

Reactivo-Insum oQuimico

Materiales

Equipos

Instrumental

Verificar Simbologia Quimica

Verificar Nombre

Verificar Capacidad en Mililitros

Verificar Modelo

Registrar Material de Laboratorio (Equipos, Materiales, Reactivos-InsumoQuimico y


el Instrumental)

Generar Codigo de clasificación

fin

64
Figura 15: DA Registrar los análisis de suelos de los Docentes y Alumnos

Docente/Alumno

Proceso tecnico

Inicio

Generar Solicitud de Analisis

Ingresar datos de analisis

Si

No

Verif icar datos

Registrar Solicitud Docente/Alumno

Datos de solicitud son corrcetos

Fin

65
Figura 16: DA Registrar Solicitudes de análisis de tercaeros (Invesitgador y
Agricultor)

Tecnico de Laboratorio

Proceso tecnico

Inicio

Generar Solicitud de Analisis

Ingresar datos de la Solicitud de Analisis

No Si

Verificar datos

Registrar Solicitud

Datos de solicitud son corrcetos

Fin

66
C. Especificación de los Caso de Uso C.1 Descripción del modelo de caso de uso:
Gestión de Registros del Laboratorio

Nombre: Actor: Definición:

Registrar Materiales (Equipos, Reactivos-InsumosQuimicos, Materiales y el


Instrumental) del Laboratorio Técnico de Laboratorio Permite Registrar los
materiales (Equipos, Reactivos-InsumosQuimicos, Materiales y el Instrumental) del
laboratorio que ingresa al laboratorio de suelos de la UNU.

Pasos: 1. Se extraen los datos pertinentes de los materiales (Equipos, Reactivos-


InsumosQuimicos, Materiales y el Instrumental) del laboratorio, incluyendo el
código de clasificación generado por el proceso técnico. 2. El Técnico de
Laboratorio registra los materiales (Equipos, Reactivos-InsumosQuimicos, Materiales
y el Instrumental) del laboratorio

C.2 Descripción del modelo de caso de uso: Gestión de Servicios Académicos

Nombre: Actor: Definición:

Registrar Solicitud Docente/Alumno Docente y Alumno Permite registrar la solicitud


de análisis que realizan los alumnos y docentes.

Pasos: 1. Se genera la solicitud de análisis. 2. Se ingresan los datos de análisis.


3. Se registra la solicitud Docente Alumno

67
C.3 Descripción del modelo de caso de uso: Gestión de Servicios Académicos Nombre:
Registrar Solicitud de Terceros (Investigador y agricultor)

Actor: Definición:

Docente y Alumno Permite registrar la solicitud de análisis que solicitan los


agricultores e investigadores.

Pasos: 1. Se genera la solicitud de análisis. 2. Se ingresan los datos de análisis.


3. Se registra la solicitud Investigador y la solicitud Agricultor

68
6.2.2. REQUERIMIENTOS A. Diagrama de Colaboración A.1 Diagrama de Colaboración
Gestión de Registros del Laboratorio Figura 17: DC Registrar en Laboratorio

3: Leer()

: Buscador de EquiLab 2: Buscar EquiLab() 4: obj.nombre 6: Leer()

: Equipo Laboratorio

5: Buscar ReacInsuQuim() : Buscador de ReacInsuQui 7: obj.codigo 1: Registrar en


Laboratorio 8: Registrar 9: Leer() : ReacInsuQui

: Registrador de Laboratorio : Tecnico de Laboratorio

10: obj.equiLab : Buscar Material : Material

11: buscar 12: Leer

13: obj.instru : Buscar Instrumental 14: Registrar : Instrumental

16: Mnesaje de confirmación

15: Crear(), modificar(),Eliminar()

: Registrar en Laboratorio

: Registro en Laboratorio

69
A.2 Diagrama de Colaboración: Gestión de Servicios Académicos Figura 17: DC
Registrar Solicitud Docente

3: Leer

2: Buscar Solicitud : Buscar Solicitud 1: Registrar Solicitud Docente 4:


obj.solicitud : Solicitud

5: Registrar : Registrador de Solicitud : Docente 7: Mensaje de Confirmación 6:


Crear(), Modificar(),Eliminar

: Registrar Solicitud

: Solicitud Docente

A.2 Diagrama de Colaboración: Gestión de Servicios No Académicos Figura 17: DC


Registrar Solicitud Investigador
2: Leer

1: Buscar Solicitud : Buscar Solicitud 7: Registrar Solicitud Investigador 3:


obj.solicitud : Solicitud

4: Registrar : Registrador de Solicitud : Tecnico de Laboratorio 6: Mensaje de


Confirmación 5: Crear(), Modificar(), Eliminar()

: Registrar Solicitud

: Solicitud Investigador

70
B. Diagrama de Paquetes del Análisis Figura 18: Diagrama de paquetes del análisis

Entidad

Interfaz

Control

Gerstión de Registros del Laboratorio

Gestion de Servicos Academicos

Gestion de Servicos No Academicos

71
C. Diagrama de Clases Figura 19: Diagrama de clases

Instrumental Tipo_Usuario id_TipoUsuario : varchar tipoUsuario : varchar nuevo()


modificar() eliminar() id_Instrumental nombre modelo crear() modificar() eliminar()

Materiales_Lab nombre Capacidad formato crear() modificar() Eliminar()


Tipo_MateriLab id_Tipo_MateLab

Registro Usuarios id_usuario : varchar Nombre : varchar password : int 1


id_Registra cod_clasificación 1 1..* BuscarInstrumental() BuscarMaterial_Lab()
BuscarReactivo_InsumoQui() BuscarEquipos_Lab()

Reactivo_InsumoQui nombre SimbologiaQui crear() modificar() eliminar()

Tipo_Reac_InsuQui nombre simbologiaQui crear() modificar() eliminar()

Equipos_Laboratorio Registro_Solicitud id_Solicitud : varchar nsolicitud fecha


recepcion : date 1..* nuevo() modificar() eleiminar() id_EquiposLabora codigo()
modelo fabricante() crear() modificar() eleiminar()

SolicitudAgricultor id_SolicituAgri agricultor fundo ubicaciónfundo colorsuelo


quesembrar nuevo() modificar() eliminar()

SolicitudInvestigador id_SolicitudInves codExperimento especialista fecha muestreo


procedencia name nmuestra nuevo() modificar() eleiminar()

SolicitudDocenteAlumno id_DicenteSolici nombreCurso Escuela profesional nombre :


varchar nombrePractica : varchar tipo : varchar fechapractica : dete nuevo()
modificar() eliminar()

72
D. Diseño de la Arquitectura

Figura 19: Diseño de la Arquitectura

<<subsystem>> Paginas HTML

<<subsystem>> Servlets

<<subsystem>> Java server page JSP

<<subsystem>>
<<Subsystem>> Gestion de Registros <<subsystem>> del Laboratorio <<Subsystem>>
Gestion de Servicios <<subsystem>> Academicos

<<Subsystem>>

<<subsystem>> Socket cliente

Administrar usuario

Gestión de Actividades

<<Subsystem>> <<subsystem>> Gestion de servicios No Control de Academicos


asistencia

<<subsystem>> Socket servidor

<<subsystem>> Procedimientos almacenados

<<subsystem>> API-acceso a datos JBDC

<<subsystem>> Web browser

<<subsystem>> Servidor web/aplicaciones

<<subsystem>> DBMS MS SQL server

<<subsystem>> Maquina virtual JAVA

<<subsystem>> Api-java

<<subsystem>> TCP IP

73
E. Diagrama de Secuencia del Análisis Figura 20: Diagrama de secuencia registrar
solicitud docente

: Docente

: Registrador de Solicitud display

: Buscar Solicitud

: Registrar Solicitud

: Solicitud

: Solicitud Docente

ingresar solicitud

registrar enviar datos buscar en tabla

true

ya existe solicitud del docente

false

enviar datos registra solicitud

true

solicitud registrado

74
Figura 21: Diagrama de secuencia registrar solicitud Investigador

: Tecnico de Laboratorio

: Registrador de Solicitud

: Buscar Solicitud

: Registrar Solicitud

: Solicitud

: Solicitud Investigador

display

ingrsa solicitud

registrar enviar datos busca en tabla

true

enviar datos

registra solicitud

true

solicitud registrado

75
Figura 22: Diagrama de secuencia registrar en laboratorio

: Tecnico de Laboratorio

: Registrador de Laboratorio

: Buscador de EquiLab

: Buscador de ReacInsuQui

: Buscador de Materiales

: Buscar Instrumental

: Registrar en Laboratorio

: Equipo Laboratorio

: ReacInsuQui

: Material

: Instrumental

: Registro en Laboratorio

display

Registrar en laboratorio

env iar datos busca en tabla

true

env iar datos

true

env iar datos busca en tabla

true

env iar datos

busca en tabla

true

y a existe

f alse

env iar datos

registra en laboratorio

true

registrado en laboratorio
76
F. Interfaz vs. Secuencia

Figura 23: Pantalla de Inicio

Figura 24: Pantalla de Bienvenida

77
Figura 25: INTERFAZ “Mantenimiento Usuarios”

78
Figura 26: DIAGRAMA DE SECUENCIA “Mantenimiento Usuarios”

C:Usuario : Tecnico de Laboratorio : CP: Menu Adm : CP ManUsuario :f rm Reg Usuario


: SP:Reg Usuario : s:Usuario : T:Usuario

Click en mantenimiento de usuarios Enlaza buscar todos () obtener

v ector usuario

Build

Mostrar

Modif icar datos de usuario 5.1

Click en guarda

Submit Modif icar()

Modif icar

79
Figura 27: INTERFAZ “Registro Solicitud Análisis Agricultor”

80
Figura 28: DIAGRAMA DE SECUENCIA “Registro Solicitud Análisis Agricultor”

C: Regis -Solic it : Tec nic o de laborat orio : C P: MenuAdm : C P: Solic i-Anali-


Agricu : F rm : Reg-Solici-Agric u : SP: Regis -Solici : s Solic itud : T:Solic it
ud-Agric ult or

Clic k en Solic ut d Anal.. .

enlaza

build

most rar

I ngres ar datos de s olicit ud analisis agric ult or

5.1

Selec cionar f ec ha de solic itud 6.1

Selec cionar dist rit o 7.1

Selec cionar ubic ac ión 8.1

Selec ionar color de s uelo

9.1

Selec cionar f ec ha de muest reo

10. 1

Clic k en guardar

Submit Genera codigo

Crear() Crear()

81
Figura 29: INTERFAZ “Registrar Solicitud Análisis”

82
Figura 30: DIAGRAMA DE SECUANCIA “Registrar Solicitud Análisis”

C:Regis-Solicit : Tecnico de laboratorio : CP:MenuAdm : CP:Solici-Anali : Frm: Reg-


Solici : SP:Regis-Solici : sSolicitud : Solicitud

Click en Solicutd Analisis enlaza

build mostrar

Ingresar datos de solicitud analisis

5.1

Seleccionar f echa de muestreo 6.1

Seleccionar analisis solicitado 7.1

Seleccionar numero de muestra

8.1

Click en guardar Submit Genera codigo

Crear() Crear()

83
G. Diseño de la Base de datos

Figura 19: Diagrama de la Base de Datos

EquiposLaboratorio
idEquiLabora codigo modelo fabricante

TipoMateriLabora
idTipoMateri tipoMateriLabora

TipoReactivo_Insum
idTipoReac_InsuQui tipoReac_InsuQuimi

tipoUsuario
idtipousuario tipoUsuario

Instrumental
idInstru nombre modelo

MaterialesLaborato
idMateriaLaborato nombre capacidad formato idTipoMateri

Reactivos_Insumos
idReactivo_InsuQui nombre simbologiaQuimica idTipoReac_InsuQui

usuarios
id_usuario nombres password tipousuaio

solicitud
idsolicitud nsolicitud id_usuario fecharecepcion

solicitudAgricultor
idsolicitudAgricultor agricultor fundo ubicacionfundo colorsuelo quesembrar
idsolicitud

SolicitudDocenteAl
idsolicitudDocenteA nombreCurso EscuelaProfesional NombreDocente nombrePractica
nombreIntersado tipo fechaPractica idsolicitud

solicitudInvestigad
idsolicitudInvestigador codigoExperimento especialist fechamuestreo procedencia
idsolicitud nmuestras

84
CAPITULO VII CONCLUSIONES Y RECOMENDACIONES

85
CONCLUSIONES

1. La metodología Orientado a Objetos y el uso del RUP es una opción aceptable para
el desarrollo de este proyecto permitiendo realizar un desarrollo organizado del
mismo.

2. Se desarrolló una base de datos lógica que incluye toda la información necesaria
para el sistema.

3. La demora en los procesos de la información disminuirían considerablemente con


la aplicación de este sistema de control del laboratorio de suelos.

4. Para la lograr el análisis y diseño de este sistema se utilizo el

lenguaje de

programación Java (Net Beans IDE 6.5.1), haciendo uso de su herramienta Web
Framework visual Server faces, un Servidor Web TomCat del entorno java y el
manejador de Base de Datos SQL Server 2000 Developer.

86
RECOMENDACIONES

1. Concluir con la investigación hasta llegar a implementarla brindando toda la


información necesaria que necesitará el sistema para su correcto funcionamiento.

2. Buscar apoyo de las autoridades competentes para desarrollar íntegramente este


proyecto ya que tiene una incidencia a nivel institucional en al parte académica

3. Aplicar los Patrones de diseño J2EE para proyectos desarrollados bajo esta
plataforma.

4. Utilizar navegador de Internet: Internet Explorer por si se presentan problemas


de navegación con otro navegador.

87
Referencias Bibliográficas 1. Stair, R. & Reynolds, G. (2000), Principios de
sistemas de información: enfoque administrativo. Mexico: Internacional Thomson
Editores.

2. Booch, G., Rumbaugh, J. & Jacobson, I. (2000), El Lenguaje Unificado de


Modelado. Manual de Referencia. Madrid: Addison Wesley.

3. Kruchten, P. (2000). The Racional Unified Process and Introduction. Canada.


Addison Wesley Iberoamericana.

4. Aizaga, E. A., Dominguez, F. X. & Ramos W. C. (2005). Módulo StoreFront de


Eguana. Tópico de Graduación – Previa a la Obtención del Título de : Ingeniero en
Computación Especialización Sistemas Tecnológicos, Escuela Superior Politécnica del
Litoral (ESPOL), Guayaquil, Ecuador.

88
Referencias Electrónicas 1. Tu consultor, via a la excelencia. ¿Qué es un sistema?
Extraído el 11 de Agosto del 2009
http://www.tuconsultor.net/consultoriasistemica/queesunsistema/index.html desde

2. Sitio oficial de NetBeans en español. ¿Qué es NetBeans? Extraído el 22 de Agosto


del 2009 desde http://www.netbeans.org/index_es.html

3. Enciclopedia virtual Wikipedia (2009). NetBeans. Extraído el 22 de Agosto del


2009 desde http://es.wikipedia.org/wiki/NetBeans

4. Introducción a Visual Web Java Server Faces. Extraído el 23 de Diciembre del


2009 desde http://www.focalthoughts.com/images/RationalUnifiedProcess.png

5. Lenguajes de Programación (2009). Programación Java. Extraído el 24 de Agosto


del 2009 desde http://www.lenguajes-de-programacion.com/programacion-java.shtml

6. OSUM - Open Source University Meetup”. Extraído el 24 de Agosto del 2009 desde
http://osum.sun.com/group/esimeucipnosum/forum/topics/conceptos-clave-dellenguaje

7. Armstrong, E., Ball, J., Bodof S., Bode, D., Evans, I., Green D., Haase, K. &
Jendrock E. (2005). “The J2EETM 1.4 Tutorials” (Cap. 12): "Java Server Pages
Technology". Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California
95054. (Diciembre 5 de 2005). Extraído el 3 de Diciembre del 2009 desde

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html.

8.

Java en castellano. (1999). Introducción a J2EE. Extraído el 3 de Diciembre del


2009 desde http://programacion.com/java/tutorial/jspyxml/4/

9. Rational Software Corp. Rational Unified Process-Imagen. Extraído el 3 de


Diciembre del 2009 desde
http://www.focalthoughts.com/images/RationalUnifiedProcess.png

10. Introducción a Visual Web Java Server Faces. Extraído el 25 de Diciembre del
2009 desde http://www.focalthoughts.com/images/RationalUnifiedProcess.png

89
ANEXO

90
Anexo 1: Cálculo de Esfuerzo y Costo para el Presupuesto del Proyecto y Diagramas
de duración para el mismo

1. Peso de los Actores Empezaremos teniendo en cuenta a los actores del sistema y a
cada actor le denominaremos si son simples, promedio o complejos; para determinar
el total de peso de actores; pero para esto nos guiaremos de la siguiente tabla:

Tipo de Actor Simple Promedio Complejo

Descripción Interfaz del programa Manejador de interfaz con protocolo Interfaz


gráfica

Factor 1 2 3

Asignaremos a cada actor su tipo: • • • Técnico de laboratorio – Simple. Docente –


Simple. Alumno – Simple.

Por consiguiente: 3 Simple x1=3

0 Promedio x 2 = 0 0 Complejo x 3 = 0 Total de peso de actores: 3 + 0 + 0 = 3

2. Peso de los Use Case Ahora haremos algo parecido para la lista de Use Case, esto
lo basaremos en el número de transacciones que realizan cada Use Case, y
determinando si son simples, promedio o complejos. Nos guiaremos de la siguiente
tabla:

Tipo de Actor Simple Promedio Complejo

Descripción 3 o menos transacciones 4 a 8 transacciones 8 transacciones

Factor 5 10 15

91
Asignaremos a cada Use Case su tipo:

1. 2. 3. 4. 5. 6. 7. 8. 9.

Registrar Solicitudes de análisis prestados a terceros Registrar clientes


externos(terceros) Registrar análisis de los alumnos Registrar análisis de los
docentes Consultar análisis prestados a terceros Consultar análisis de los alumnos
Consultar análisis de los docentes Registrar Reactivos de laboratorio Registrar
Materiales de laboratorio

Simple Simple Simple Simple Simple Simple Simple Simple Simple Simple Simple Simple

10. Registrar Equipos de laboratorio 11. Registrar Instrumental de laboratorio 12.


Reporte de análisis de suelos

Por lo tanto obtenemos: 12 Simples x 5 = 60 0 Promedio x 10 = 0 0 Complejo x 15 = 0


Total de pesos de Use Case: 60 + 0 + 0 = 60

3. Calculando UUCP (Ajuste de Puntos para el Use Case) El UUCP refleja la


complejidad del proyecto y la experiencia de las personas en el proyecto, para
obtener el UUCP utilizaremos los pesos de los actores y los pesos de los Use Case:

3 + 60 = 63 UUCP

4. Calculando el TCF (Factor Técnico de Complejidad) El siguiente paso es calcular


la complejidad técnica del proyecto, los factores estarán entre los puntajes de 0 a
5, esto lo haremos a través de la siguiente tabla:

92
Descripción del factor

Peso del factor (Fi)

Peso(Valor asignado) 4 3 0 5 4 5 5 5 4 1 4 0 2

Fi x Peso

Sistema Distribuido Tiempo de respuesta Usuarios finales (en línea) Procesos


Internos Complejos Código reutilizables Fácil de instalar Fácil de utilizar
Portable Fácil de modificar Concurrencia Características de seguridad Acceso a
terceros Capacitación especial Total

2 1 1 1 1 0.5 0.5 2 1 1 1 1 1

8 3 0 5 4 2.5 2.5 10 4 1 4 0 2 46

TFC = 0 . 6 + ( 0 . 01 × ∑ ParaCadaFa
TFC = 0.6 + (0.01* 46) = 1.06

ctorF i

Fi × Peso i )

5. Calculando el EF (Factor Environment) El Factor de Entorno EF (Enviromental


Factor) trata de medir cómo de familiarizado está el equipo de desarrollo con el
tipo de problema del proyecto a realizar. Los factores tendrán una puntuación de 0
a 5, para calcular el EF nos guiaremos de la siguiente tabla; Teniendo en
consideración los siguientes puntos:

De F1 a F4; 0 es no experiencia, 3 es más o menos y 5 es experto F5; 0 no motivado,


3 más o menos y 5 muy motivado. F6; 0 requerimientos inestables, 3 más o menos y 5
requerimientos estables. F7; 0 no hay staff de medio tiempo, 3 más o menos y 5
todos trabajan medio tiempo. F8; 0 fácil uso de la programación, 3 más o menos y 5
mucha dificultad para la programación.

93
Número del Factor F1 F2 F3 F4 F5 F6 F7 F8

Descripción del factor

factor (Fi)

Peso

Fi x Peso

Manejo de Procesos Unificados Experiencia en aplicaciones Experiencia en


orientación a objetos Capacidad de análisis y liderazgo Motivación Requerimientos
estables Trabajadores a medio tiempo Lenguaje de programación difícil de utilizar
Total

1.5 0.5 1 0.5 1 2 -1 -1

5 3 5 4 5 3 5 0

7.5 1.5 5 2 5 6 -5 0

22

EF = 1.4 + (−0.03× ∑ParaCadaFa Fi × Peso ) i ctorF


i

EF = 1.4 + (-0.03 x 22) = 0.74

6. Calculando el UCP (Use Case Point) Los puntos de Casos de Uso UCP (Use Case
Points) se calculan de la siguiente forma:

UCP = UUCP× TFC × EF


UCP = 63 x 1.06 x 0.74 = 49.4172

7. Para elegir el factor hombre/horas Para esto examinamos los datos en los EF y
contamos del F1 a F6 los factores que son menores a 3 y contamos F7 F8 los factores
a partir de tres. Si el total es 2 o menos utilizamos 20 hombres/horas por UCP si
son mayores a tres utilizamos 28 hombres/horas por UCP. En nuestro caso
utilizaremos 20 hombres/horas, por lo que multiplicaremos: 20 hombres/horas * UCP
20 hombres/horas * 49.4172= 988.344, que considero que es el esfuerzo que voy a
necesitar para el proyecto.

94
Con esto también podremos calcular el tiempo aproximado que necesitare para el
desarrollo del proyecto, considerando que la semana tiene 40 horas (5 días x 8)
entonces: Tiempo = 988.344/ 40 = 24.7086 semanas

Interpretación: Se necesitará 25 semanas, entre dos personas que desarrollará este


trabajo de investigación el tiempo calculado es en 12.5 semanas estimado trabajando
8 horas diarias considerando 8 horas laborables al día.

8. Costo del Proyecto El costo del proyecto se calculo en base a los sueldos de los
integrantes del equipo suponiendo un pago de (S/. 600.00 c/u) que multiplicado por
el tiempo estimado para dicho proyecto (3 meses) hacen un total de S/. 1,800.00; a
este costo se le suma los gastos de aprovisionamiento que es un total de S/.
600.00, obteniendo así el Costo Total Estimado de S/. 2400.00 por todo el proyecto.

95
Anexo 2:

Glosario de Términos

Actor.- Los actores son cualquier cosa que interacciona el sistema que se
desarrolla, por ejemplo, personas, otros software, hardware, dispositivos, redes,
almacenes de datos, etc.. Cada actor define un particular “role”.

Arquitectura Cliente-Servidor.- Modelo arquitectónico para sistemas distribuidos en


el que la funcionalidad del sistema se ofrece como un conjunto de servicios
proporcionados por un servidor. Éstos son accedidos por computadoras cliente que
hacen uso de los servicios. Variantes de este enfoque, como las arquitecturas
cliente-servidor de tres capas. Utilizan múltiples servidores.

Arquitectura Software.- Modelo de la estructura y organización fundamental de un


sistema software

Caso De Uso.- Es una descripción de las acciones de un sistema desde el punto de


vista del usuario.

Componente.- Unidad de software independiente y desplegable que se ha definido


completamente y a la que se accede a través de un conjunto de interfaces.

Confiabilidad.- La confiabilidad de un sistema es una propiedad total que tienen en


cuenta la seguridad del sistema, la fiabilidad, la disponibilidad, la protección y
otros atributos. La confiabilidad de un sistema refleja el grado en el cual los
usuarios pueden confiar en el sistema.

Construcción del Sistema.- Proceso de compilar los componentes o unidades que


forman un sistema y enlazarlos con otros componentes para crear un programa
ejecutable. La construcción del sistema está normalmente automatizada de modo que
se minimiza la recopilación. Esta automatización puede ser incorporada a un sistema
de procesamiento de lenguajes (como en Java) o puede implicar herramientas CASE
para apoyar la construcción del sistema.

Diagrama.- Es una representación gráfica de una colección de elementos de modelado.

96
Diseño arquitectónico. Es un proceso creativo en el que se intenta establecer una
organización del sistema que satisfaga los requerimientos funcionales y no
funcionales del propio sistema.

Diagrama de secuencia.- consta de objetos que se representan del modo usual


rectángulos con nombre (subrayado), mensajes representados por líneas continuas con
una punta de flecha y el tiempo representado como una progresión virtual.

Diagrama de colaboración.- Es otra forma de presentar la información en un diagrama


de secuencia además muestran la forma en que los objetos colaboran entre si, tal
como sucede con un diagrama de secuencia.

Diagrama de actividad.- Es muy parecido aun diagrama de flujo, muestra los pasos,
puntos de decisión y bifurcaciones. Este tipo de diagrama es útil para representar
las operaciones de unobjeto y los procesos de negocios.

Diagrama de Clases Es el diagrama principal para el análisis y diseño, presenta las


clases del sistema con sus relaciones estructurales y de herencia

Diseño de interfaces de usuario.- Proceso de diseñar el modo en el que los usuarios


del sistema acceden a la funcionalidad del sistema y la forma en la que se
visualiza la información producida por el sistema.

Estereotipo.- Permite crear nuevos elementos apartir de otros existentes.

Extensión.- Se representa por una línea de dependencia con un estereotipo


“extender”.

Enterprise Java Beans.- Modelo de componentes basado en Java

Herramienta CASE.- Herramienta software, como un editor del diseño o un depurador


de programas, utilizada para apoyar una actividad en el proceso de desarrollo del
software.

Inclusión.- Se representa por una línea de dependencia con un estereotipo


“incluir”.

97
Ingeniería de Sistemas.- Proceso que trata de la especificación de un sistema, la
integración de sus componentes y las pruebas de que el sistema cumple sus
requerimientos. La ingeniería de sistemas no sólo trata el sistema software, sino
el sistema socio-técnico entero: software, hardware y procesos operativos.

Interfaz.- Especificación de los atributos y operaciones asociados con un


componente software. La interfaz es utilizada como el medio de tener acceso a la
funcionalidad del componente.

Java.- Lenguaje de programación orientado a objetos que fue diseñado por Sun con el
objetivo de la independencia de la plataforma.

Lenguaje de Modelado Unificado (UML).- Lenguaje gráfico utilizado en el desarrollo


orientado a objetos que incluye varios tipos de modelos del sistema que
proporcionan distintas vistas de un sistema. UML se ha convertido en un estándar de
factor para el modelado orientado a objetos.

98
UNIVERSIDAD NACIONAL DE UCAYALI
FACULTAD DE INGENIERÌA DE SISTEMAS Y DE INGENIERÍA CIVIL ESCUELA ACADÉMICA
PROFESIONAL DE INGENIERÌA DE SISTEMAS

“ANÁLISIS Y DISEÑO DE UN SISTEMA DE CONTROL DE LA INFORMACIÓN PARA EL LABORATORIO


DE SUELOS DE LA UNIVERSIDAD NACIONAL DE UCAYALI”

INFORME DE PRÁCTICA PRE – PROFESIONAL I


Autor: ALIAGA VILLANTOY, GEYS Asesor: Ing. CLOTILDE RIOS HIDALGO DE CERNA

Pucallpa, Junio 2010


DEDICATORIA

A Dios, por estar siempre conmigo, iluminar mi mente y darme la fuerza para seguir
luchando por mis ideales.

A mis queridos padres,

Fidel y que

Cirsencia por el constante apoyo

me brindan en todo momento en virtud de lograr mis objetivos personales y


profesionales

A mis hermanas, por su apoyo paciente e incondicional en las diferentes etapas de


mi vida.
AGRADECIMIENTOS

Mi

reconocimiento

al

Ing.

Clotilde

Ríos

Hidalgo,

por

su

asesoramiento y valiosas recomendaciones en el desarrollo del proyecto, además por


compartir sus conocimientos cada momento. Y también un reconocimiento al Técnico
encargado de laboratorio Sñr. Juan Huaycama Huaynaqari, por su apoyo, dedicación y
paciencia al brindarme toda la información necesaria del laboratorio de suelos de
la Universidad Nacional de Ucayali para el desarrollo de la presente proyecto.
INDICE GENERAL Página DEDICATORIA AGRADECIMIENTOS INDICE GENERAL INDICE DE FIGURAS
INDICE DE CUADROS PRESENTACIÓN RESUMEN ABSTRACT INTRODUCCIÓN II III IV V VI VII
VIII IX X

Página CAPITULO I – PRESENTACIÓN 1.1 Objetivo del informe 1.2 Periodo de la


practica 1.3 Institución y Área donde se realizo la practica 1.4 Funciones del Área
donde realizo sus practicas 2 2 2 2

CAPITULO II – ASPECTOS GENERALES DE LA EMPRESA 2.1 Razón social 2.2 Actividades que
realiza 2.3 Aspectos técnicos

4 4 4

CAPITULO III – ACTIVIDADES REALIZADAS 3.1 Actividades Realizadas 3.1.1 Análisis de


sistemas 3.1.2 Diseño de sistemas

10 10 10
CAPITULO IV – DESCRIPCIÓN DE LAS ACTIVIDADES REALIZADAS 4.1 Objetivos 4.2
Justificación 4.3 Técnicas 4.4 Cronograma de Actividades

12 12 12 13

CAPITULO IV – MARCO TEÓRICO 5.1 Sistema de Información 5.2 El lenguaje Unificado de


Modelado - UML 5.3 El proceso Unificado de Rational 5.4 Programación Java 5.5
Conceptos clave del lenguaje de programación java 5.6 Netbeans. IDE (Entorno de
desarrollo integrado)

15 19 22 26 27 30

CAPITULO IV - PROCESO DE DESARROLLO DE SOFTWARE 6.1 FASE INICIAL 6.1.1 Modelamiento


de Visión del negocio: A) Documento de visión del negocio: A.1) Introducción: A.1.1
Propósito A.1.2 Alcance A.2) Posicionamiento: A.2.1 Oportunidad del Negocio A.2.2
Exposición de Problema A.3) Descripción de Stakeholder y Usuarios A.3.1 Mercado
Demográfico A.3.2 Sumario de Stakeholder A.3.3 Sumario de Usuarios A.3.4 Ambiente
Usuarios A.3.5 Necesidades Principales de Usuarios A.3.6 Alternativas 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) Introducción B.1.1 Propósito B.1.2 Alcance B.1.3
Referencias B.1.4 Apreciación Global B.2) La Apreciación Global del Proyecto
B.2.1 Propósito del Proyecto, Alcance y Objetivos B.2.2 Entregables del Proyecto.
B.2.3 Evaluación del Plan de desarrollo de Software. B.3) La Organización del
Proyecto B.3.1 Estructura Orgánica B.3.2 Interfaces Externas B.3.3 Papeles y
Responsabilidades B.4) El Proceso de Dirección B.4.1 Estimación del Proyecto B.4.2
Plan de Proyecto a) Plan de la Fase b) Horario del Proyecto B.5) Recursos para el
Proyecto B.5.1 Plan de Adquisición de Recursos B.5.2 Entrenamiento que se planean
B.6) Entorno de trabajo B.6.1 Elección de equipos y accesorios de la Red LAN
B.6.1.1 Elección de las tarjetas de Red 7 B.6.1.2 Accesorios de la Red B.7) Vistas
Use Case B.8.1 Modelo Use Case del Negocio B.8.2 Modelo de Objeto del Negocio B.8.3
Modelo de Dominio B.8) Descripción de procesos del negocio 6.2 FASE ELABORACION
6.2.1 REQUERIMIENTOS A) Modelo Use Case B) Diagramas de Actividades C)
Especificaciones de los Use-Case 6.2.2 ANÁLISIS Y DISEÑO A) Diagrama de
Colaboración B) Diagrama de Paquetes del Análisis C) Diagrama de Clases D) Diseño
de la Arquitectura E) Diagrama de Secuencia del Análisis F) Interfaz VS. Secuencia
G) Diseño de la Base de datos
INDICE DE FIGURAS Página Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6
Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Plano de
ubicación de la UNU Organigrama de la Universidad Nacional de Ucayali Componentes
de un sistema de información Métodos de Apoyo al UML Fases del Proceso Unificado de
Rational – RUP Modelo de Caso de Uso del Negocio MON Registrar Reactivos, Equipos,
Instrumental y Materiales del Laboratorio. MON Registrar Análisis de Suelos
Docentes_Alumnos Registrar Análisis de Suelos Terceros (Investigador y agricultor)
Modelo de Dominio MCU Gestión de Servicios Académicos MCU Gestión de Servicios No
Académicos MCU Gestión de Registros del laboratorio DA Registrar Materiales
(Equipos, Reactivos- InsumosQuimicos, Materiales y el Instrumental) del Laboratorio
DA Registrar los análisis de suelos de los Docentes Y Alumnos DA Registrar
Solicitudes de análisis de tercaeros (Invesitgador y Agricultor) DC Registrar en
Laboratorio DC Registrar Solicitud Docente DC Registrar Solicitud Investigador
Diagrama de paquetes del análisis Diagrama de clases 5 6 16 21 24 55 56 57 58 59 61
62 63 64 65 66 69 70 70 71 72 73 74

Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21


Figura 22

Diseño de la Arquitectura Diagrama de la Base de Datos


INDICE DE CUADROS Nro. Cuadro 1 Cuadro 2 Cuadro 3 Cuadro 4 Cuadro 5 Cuadro 6 Cuadro
7 Cuadro 8 Cuadro 9 Cuadro 10 Cuadro 11 Cuadro 12 Cuadro 13 Cuadro 14 Cuadro 15
Cuadro 16 Servidor BD Servidor Web Población Sumario de Stakeholders Sumario de
Usuarios Necesidades de usuarios Entregables del Proyecto Papeles y
Responsabilidades Plan de procesos de desarrollo de acuerdo a fases Fases del
proyecto e hitos principales Tareas del proyecto Presupuesto Servidor BD Servidor
Web Proceso del Negocio Descripción del modelo de caso de uso: Gestión de Registros
del Laboratorio Cuadro 17 Descripción del modelo de caso de uso: Gestión de
Servicios Academicos Cuadro 18 Descripción del modelo de caso de uso: Gestión de
Servicios No Academicos 68 67 Descripción Pág. 7 8 39 40 40 41 46 48 49 49 50 52 53
54 60 67
RESUMEN

El presente proyecto aborda el problema del control de los registros de datos de


las muestras de suelos, de sus análisis respectivos y la forma de almacenar estos
registros en el laboratorio de suelos de la Universidad Nacional de Ucayali. Por lo
que se realizó un análisis cuidadoso de la situación actual de los procesos
mencionados en el laboratorio de suelos de la UNU, donde se observo e identificó
que el laboratorio no dispone de un proceso automatizado haciendo uso de una
herramienta con la tecnología apropiada que satisfaga los requerimientos de control
y procesamiento de la información que satisfaga los servicios de análisis de
suelos. Este proyecto de investigación tiene como objetivo mejorar el control de
los registros de datos de las muestras de suelos, de sus análisis respectivos y la
forma de almacenar estos registros en el laboratorio de análisis de suelos de la
UNU.

Para el desarrollo de este sistema se utilizo la metodología Orientado a objetos y


el uso del RUP - Racional Unified Process, a través de las fases inicial y de
elaboración usando la notación UML - Unified Modeling Language y Racional Rose 2003
para el desarrollo del software. Para la construcción del sistema se utilizó el
lenguaje de programación Java (Net Beans IDE 6.5.1), haciendo uso de su herramienta
Web - Framework visual Server faces, un Servidor Web TomCat del entorno java y el
manejador de Base de Datos SQL Server 2000 Developer.

Finalmente con los resultados de la presente investigación podemos demostrar que la


implementación de este sistema de control permitirá al laboratorio de suelos de la
UNU mejorar el control de los registros y almacenamiento de datos de las muestras
de suelos, de sus análisis respectivos y la forma de almacenar estos registros para
brindar un buen servicio académico a los alumnos y docentes; y servicio no
académico prestados

a los Investigadores y agricultores.

Palabras claves: sistema, control, análisis de suelos


ABSTRAC This project addresses the problem of control of the data records of soil
samples, their respective analysis and how to store these records in the soil
laboratory at the National University of Ucayali. As did a careful analysis of the
current status of the processes in the soil laboratory of the UNU, and identified
where it was observed that the laboratory does not have an automated process using
a tool with appropriate technology that meets control requirements and information
processing services that meets the soil analysis. This research project aims to
improve the control of the data records of soil samples, their respective analysis
and how to store these records in the soil testing laboratory of the University.

For the development of this system will use the object-oriented methodology and the
use of RUP - Rational Unified Process, through the initial stages of development
using the UML - Unified Modeling Language and Rational Rose 2003 for software
development. For the construction of the system is used the Java programming
language (Net Beans IDE 6.5.1), using its Web tool - visual Server Faces Framework,
a Web server environment TomCat java and database manager SQL Server 2000
Developer.

Finally the results of this investigation we demonstrate that implementation of


this control system will allow the soil laboratory of UNU improve control of
records and data storage of soil samples, their respective analysis and form of
store these records to provide good service to students and academic teachers and
non-academic services provided to researchers and farmers.

Keywords: computer system, control, soil analysis


INTRODUCCIÓN

En la actualidad el uso de la información es indispensable para el crecimiento


Institucional y una mejor toma de decisiones, haciendo uso de un control de datos
ingresados y un control de la información procesada apoyándose de herramientas
tecnológicas necesarias que facilite y mejore el control de datos y procesamiento
de la información, que es necesario para mejorar la calidad del servicio de
análisis de suelos en el laboratorio de suelos de la Universidad Nacional de
Ucayali lo cual aumentará la eficiencia, la confiabilidad y la reducción de costos.
La Universidad Nacional de Ucayali en la actualidad ha modernizado la
infraestructura de los nuevos locales de laboratorio en la cual tenemos el
laboratorio de suelos de la Facultad de Ciencias Agropecuarias. Teniendo la
infraestructura necesaria para brindar un mejor servicio en lo académico a los
alumnos y docentes, y en la investigación a la comunidad Regional y Nacional.

El sistema de control es el conjunto de hardware, software y de un soporte humano.


Este sistema de control necesita de una computadora que usa dispositivos
programables para capturar, almacenar y procesar datos de la muestra de suelos y de
sus análisis respectivos. Con el presente proyecto de investigación se quiere
mejorar el control de los registros de datos de las muestras de suelos, de sus
análisis respectivos y la forma de almacenar estos registros en el laboratorio de
suelos de la UNU para brindar un buen servicio de análisis de suelos, ya que esta
información es la principal fuente para la toma de decisiones para proseguir con el
trabajo en un área de una extensión de terreno determinada de la cual se extrajo la
muestra de suelo. Por lo expuesto en este párrafo la implementación de un sistema
de control en el laboratorio de suelos de la UNU pueda mejorar el control de los
registros de datos de las muestras de suelos, de sus análisis respectivos y la
forma de almacenar estos registros.
Para el desarrollo de este sistema se utilizo la metodología Orientado a objetos y
el uso del RUP - Racional Unified Process, a través de la fase inicial,
elaboración, construcción y transición usando la notación UML - Unified Modeling
Language y Racional Rose 2003 para el desarrollo del software. Para la construcción
del sistema se utilizó el lenguaje de programación Java (Net Beans IDE 6.5.1),
haciendo uso de su herramienta Web Framework Visual Java Server Faces, un Servidor
Web TomCat del entorno java y el manejador de Base de Datos SQL Server 2000
Developer.

Los procesos de la información en el laboratorio de suelos de la Universidad


Nacional de Ucayali en la actualidad se realizan de manera manual en hojas (tipo
bulki, bond, etc.), cuaderno de apuntes, etc., disponibles en ese momento. El uso
de estas hojas de notas, cuaderno de apuntes, etc., que no tiene un formato
adecuado para el llenado de la información de la muestra de suelos, da como
consecuencia un traspapelado entre otras hojas de apuntes que ocasionan demora al
recurrir a la información de los análisis de suelos y también ha la perdida de la
información. Esto se debe, ya que el laboratorio no cuenta con un control de
fichero, sistema de información, un sistema informático, etc.

A continuación se describe un resumen de la presente tesis:

En el Capítulo I: Presentación; En esta parte se describe el objetivo del informe,


el periodo de la practica, la institución y área donde se desarrollo las prácticas
así como las funciones de esta.

En el Capitulo II: Aspectos Generales de la Empresa; En esta parte se describe más


en detalle los datos de la empresa.
En el Capitulo III: Actividades Realizadas; Se describe en detalle las labores
realizadas en la institución (empresa, etc.) durante la duración de las practicas
pre-profesionales.

En el Capitulo IV: Descripción de las actividades realizadas; Se detallan mas


profundamente las actividades de las practicas pre-profesionales.

En el Capitulo V: Marco Teórico; En esta parte se describe el conocimiento teórico


relacionado a la metodología Orientado a objetos, el uso del RUP - Racional Unified
Process RUP y UML - Unified Modeling Language, además de de definir conceptos sobre
análisis de suelos.

En el Capitulo VI: Proceso de Desarrollo de Software; Se detalla la aplicación del


“racional Unified Process” (RUP), mostrando los resultados del Análisis a través de
documentación, diagramas con estereotipos UML, además de las características para
la construcción del Software, abarcando las fases Inicial y de Elaboración.

Finalmente se presenta; las Conclusiones y Recomendaciones, así como las


Referencias Bibliográficas, y los Anexos necesarios correspondientes como el
cálculo del esfuerzo y costo del proyecto.
CAPITULO I PRESENTACIÓN

1
1.1. Objetivo del Informe El presente informe pretende brindar un panorama general
del desarrollo del sistema de Control de la Información para el Laboratorio de
Suelos de la Universidad Nacional de Ucayali, plasmando los conocimientos que voy
adquiriendo en el transcurso de mi carrera para el desarrollo de mi primera
práctica PreProfesional, de acuerdo al reglamento de prácticas Pre-Profesionales de
la Escuela Académica Profesional de Ingeniería de Sistemas.

1.2. Periodo de la práctica La presente práctica pre-profesional I se desarrollará


durante un periodo de 03 meses: Fecha de Inicio: 01 de Octubre del 2009 Fecha de
finalización: 1 de enero del 2010

1.3. Institución y Área donde se realizará la Práctica Institución : Universidad


Nacional de Ucayali.

Área Investigación : Laboratorio de Suelos de la UNU. Responsable : Ing. Giraldo


Almeida Villanueva.

1.4. Funciones del Área donde desarrollo la Practica El laboratorio de Suelos de la


Universidad Nacional de Ucayali tiene las siguientes funciones: • Dirigir y
supervisar permanentemente las actividades del laboratorio de suelos de la UNU. •
Soporte a las actividades de investigación y producción que desarrollan las
instituciones y agentes económicos de la región. • Apoyar las políticas de
desarrollo tanto en lo académico como en la parte de investigación utilizando
métodos analíticos para suelos usados en el trópico húmedo. • Tomar muestras de
suelo, analizarlas, procesar datos de los análisis de resultados y determinar la
capacidad, uso y fertilidad del suelo. • Brindar el asesoramiento a los
productores, productoras, uso y manejo del cultivo bajo condiciones optimas

2
CAPITULO II ASPECTOS GENERALES DE LA EMPRESA

3
2.1. Razón Social Universidad Nacional de Ucayali.

2.2. Actividades que realiza La Universidad Nacional de Ucayali, es una institución


en vías de la formación de futuros profesionales creada mediante Decreto Ley Nº
22804, el 18 de Diciembre de 1979, con el nombre de “Universidad Nacional de
Ucayali”, cuya misión es ser sostenible en lo social, política, económica y
medioambientalmente, capaz de captar, generar, transmitir ciencia y tecnología, y
cultura de calidad, insertándose institucionalmente y proyectándose a la sociedad
en un marco de democracia, equidad y desarrollo en la formación de profesionales
altamente calificados capaces de dar solución a los problemas regionales y
nacionales. Tiene como funciones generales lo siguiente: • Formar profesionales,
investigadores conservadores y protectores del medio ambiente, capaces de crear
conocimientos para contribuir a mejorar el nivel de vida de la población. •
Implementar acciones, mediante la aplicación de programas asistenciales en las
áreas de salud, alimentación, transporte, cultura, deporte y recreación para lograr
su bienestar. • Desarrollar acciones para lograr una eficiente gestión
institucional, tendiente a incrementar su prestigio, y mejorar la estructura
orgánica que conlleve al cumplimiento de la misión institucional. • Garantizar una
eficiente y oportuna asistencia a los beneficiarios de los sistemas provisionales
que tiene a su cargo la institución.

2.3. Aspectos técnicos 2.3.1. Ubicación Geográfica

Departamento Provincia Distrito Localidad

: Ucayali. : Coronel Portillo. : Callería. : Pucallpa Carretera Federico Basadre KM


6.

4
2.3.2. Croquis de Ubicación Figura 01: Plano de ubicación de la UNU

5
2.3.3. Organización

Figura 02 ORGANIGRAMA DE LA UNIVERSIDAD NACIONAL DE UCAYALI

6
2.3.4. Infraestructura Tecnológica Hardware y Software A. Software La institución
cuenta con lo siguiente: • • Sistemas operativos para terminales: Ms Windows XP
Profesional Service Pack 2, MS Windows 98se. Sistemas operativos para servidores:
Ms Windows Server 2003 (Servidor de base de datos y dominio), Linux Mandrake v.
10.0 (servidor weby correo) y Linux Trustix 4.1 con Squid 2.5 (Serviodr proxi). • •
• • • Office empresarial: Ms Office Profesional 2003, MS Office2000. Antivirus:
McAfee v 8.0i Enterprise Base de datos: SQL Server 2000 y 2005 Desarrollo: NetBeans
6.5.1 Software especializado: Ms Project 2003

B. Hardware • Servidores

Servidor de Base de Datos

Cuadro 01: Servidor BD Procesador Memoria Memoria Bus entrada/salida Puerto Puerto
Disco Duro Unidad CD-ROM Unidad de Diskettes Tarjeta de RED Tarjeta Video Monitor
Mouse Teclado Intel Xeon IV 3.60 Ghz. Caché Interna 1 GB RAM 2 GB PCI/EISA 1
Paralelo, 2 Seriales 3 USB 5 discos de 180 GB SCSI Lectora 48x 3½ 1.44 MB Dual
Gigabit Ethernet 10/100 Base T ATI RADEON 7000-M 16MB SDRAM LG 17” Sleek 2 botones
Genius PS/2

7
Servidor Web

Cuadro 02: 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 Intel Xeon IV 3.40 Ghz. Caché Interna 512 MB RAM 1 GB PCI/EISA 1
Paralelo, 2 Seriales 4 USB 1 disco de 73.4 GB SCSI Lectora 48x 3½ 1.44 MB Gigabit
Ethernet 10/100/1000 Base T PCI 7000-M 16MB SDRAM LG 15” Genius 2 botones Genius
PS/2

Computadoras Clientes: Un parque Informático: 250 PC’s en funcionamiento

8
CAPITULO III ACTIVIDADES REALIZADAS

9
3.1. Análisis de Sistema Se realizo el levantamiento de la información necesaria
para el Análisis del Sistema de Control en el Laboratorio de Suelos de la
Universidad Nacional de Ucayali.

3.2. Diseño de sistemas Se diseño las interfaces y diagramas respectivos para el


desarrollo de software haciendo uso de RUP necesarios para la implementación del
Sistema.

10
CAPITULO IV DESCRIPCIÓN DE LAS ACTIVIDADES REALIZADAS

11
4.1. Objetivos A. General Análisis y Diseño para modelar el Sistema de control de
la información para el laboratorio de suelos de la UNU.

B. Específicos 1. Analizar los procesos los procesos en el Laboratorio de Suelos de


La UNU y su relación con las demás áreas de la organización. 2. Modelar los datos
que no van ha permitir obtener información consolidada y agrupada técnicamente del
laboratorio de suelos de la Universidad Nacional de Ucayali. 3. Mejorar la
administración de los datos para tener un mejor control de los procesos en el
laboratorio de suelos de la UNU. 4. Entender los mecanismos de registro y manejo de
los datos para mejorar los procesos de la información. 5. Determinar la tecnología
necesaria para el desarrollo de la implementación del sistema de control para
mejorar los procesos de información en el laboratorio de suelos de la UNU. 6.
Desarrollar una interfaz amigable, comprensible de fácil uso y utilidad para el
usuario.

4.2. Justificación Las actividades enumeradas anteriormente, son las necesidades a


tener en cuenta para el desarrollo del sistema que permitirá mejorar el control del
registro de los datos, realizar consultas necesarias con referente a los análisis
de suelos realizados en tiempo real para la toma de decisiones en el Laboratorio de
Suelos de la UNU.

4.3. Técnicas Para el desarrollo del presente proyecto se han usado diversas
técnicas de recolección de datos tales como: las entrevistas y la observación para
la toma de la información

12
4.4. Cronograma de Actividades

13
CAPITULO V MARCO TEÓRICO

14
5.1. Sistema de Información Según Stair, R & Reynolds, G. (2000)1, Un sistema de
información (SI) es un con junto de componentes interrelacionados para recolectar
(entrada), manipular (proceso) y diseminar (salida) datos e información y para
disponer de un mecanismo de retroalimentación útil en el cumplimiento de un
objetivo. Todos interactuamos en forma cotidiana con sistemas de información, para
fines tanto personales como profesionales; utilizamos cajeros automáticos, los
empleados de las tiendas registran nuestras compras sirviéndose de códigos de
barras y escáners u obtenemos información en módulos equipados con pantallas
sensibles al tacto. Conocer el potencial de estos sistemas y poseer la capacidad
para aplicarlos puede resultar en una exitosa trayectoria profesional personal, en
el cumplimiento de las metas de las organizaciones y en una mayor calidad de vida
para la sociedad. Computadoras y sistemas de información no cesan de producir
cambios en la manera de trabajar de las organizaciones. Vivimos inmersos en una
economía de información. La propia información posee valor, y el comercio implica a
menudo el intercambio de información más que de bienes tangibles. Los sistemas
basados en computadoras son de uso creciente como medios para la creación,
almacenamiento y transferencia de información.

________________________
1

“Principios de sistemas de información”:

15
ENTRADA, PROCESAMIENTO, SALIDA, RETROALIMENTACIÓN

Figura 03: Componentes de un sistema de información

Entrada. En sistemas de información, la entrada es la actividad que consiste en


recopilar y capturar datos primarios. Cuando se elaboran cheques de pago, por
ejemplo antes de proceder a su cálculo o impresión debe recolectarse información
sobre el número de horas trabajadas por cada empleado. En un sistema universitario
de calificaciones, los profesores deben proporcionar las calificaciones de sus
alumnos para que sea posible reunirlas en un reporte semestral o trimestral
destinado a los estudiantes. La entrada puede adoptar muchas formas. En un sistema
de información diseñado para la producción de cheques de pago, por ejemplo, la
tarjeta de registro de llegada y salida de cada empleado podría ser la entrada
inicial. En un sistema de teléfono de emergencia, toda llamada recibida se
consideraría una entrada. Las entradas de un sistema de mercadotecnia pueden
contener las respuestas de clientes a encuestas. Adviértase que, más allá del
sistema de que se trate, el tipo de entrada está determinado por la salida que se
desea obtener del sistema. La entrada puede ser un proceso manual o automatizado.
El escáner para leer códigos de barras e introducir el precio e información para
identificar el producto en las cajas registradoras computarizadas de un
supermercado es ejemplo de un tipo de proceso de entrada automatizado. Pero
independientemente del método plano de entrada que se utilice, la exactitud de la
entrada es decisiva para obtener la salid deseada.

Procesamiento. En sistemas de información, el procesamiento supone la conversión o


transformación de datos versión o transformación de datos en salidas útiles. Esto

16
puede implicar ejecutar en salidas útiles cálculos, realizar comparaciones y
adoptar acciones alternas, y el almacenamiento de datostos para su uso posterior.
El procesamiento puede llevarse a cabo de manera manual o con la asistencia de
computadoras. En el caso de la aplicación en el pago de nómina a la que nos
referimos anteriormente, el número de horas trabajadas por cada empleado debe
convertirse en un pago neto. El procesamiento requerido puede implicar primero que
nada multiplicar el número de horas trabajadas por el índice salarial por hora del
empleado, con lo que se obtendría la cifra correspondiente al pago bruto. Si en una
semana determinada el empleado trabajó más de 40 horas, también tendría que
considerarse el pago de horas extras. Por último, se resta al pago bruto las
deducciones que procedan, lo cual da la cifra del pago neto. Es posible, por
ejemplo, que deban retenerse, o restarse al pago bruto, impuestos federales y
estatales; asimismo, muchos empleados cuentan con seguro de salud y de vida,
participan en planes de ahorro o están sujetos a otras deducciones que también
deben restarse al pago bruto para obtener la cifra del pago neto.

Salida. En sistemas de información, la salida implica producir información útil,


por lo general en forma de documentos y/o reportes. Entre las salidas pueden
contarse los cheques de pago de los empleados, reportes dirigidos a administradores
y la información que debe suministrarse a accionistas, bancos, organismos

gubernamentales y otros grupos. En algunos casos, la salida de un sistema bien


podría ser la entrada de otro. La salida de un sistema para el procesamiento de
pedidos de ventas, por ejemplo, podría servir de entrada a un sistema para elaborar
las facturas de los clientes. A menudo es común que la salida de un sistema sirva
como entrada para el control de otros sistemas o dispositivos. Por ejemplo, en la
compleja fabricación de muebles de oficina deben tomarse en cuenta muchas
variables; así, cliente, vendedor y diseñador deben repetir varias veces el proceso
de diseño para cerciorarse de la efectiva satisfacción de las necesidades del
consumidor.

17
El empleo de software y hardware especiales de computación es de gran utilidad en
este caso tanto para la creación del diseño original como para su ágil corrección.
Una vez aprobada la maqueta final, se recurre a software propio de estaciones de
trabajo de diseño para elaborar la lista de materiales de manufactura necesarios
para surtir el pedido.

La salida puede producirse por diversos medios. En lo referente a las computadoras,


entre los dispositivos de salida más comunes están impresoras y pantallas. Sin
embargo, la salida también puede ser un proceso manual, pues a menudo supone
informes y documentos manuscritos.

Retroalimentación. En sistemas de información, la retroalimentación es la salida


que se utiliza para efectuar cambios en actividades de entrada o procesamiento. La
presencia de errores o problemas, por ejemplo, podría imponer la necesidad de
corregir datos de entrada o modificar un proceso. Volvamos a nuestro ejemplo de
pago de nómina. Supongamos que, en cuanto al número de horas trabajadas por un
empleado, se introdujo en una computadora la cantidad de 400 en vez de 40.
Afortunadamente, la mayoría de los sistemas de información disponen de recursos
para comprobar que los datos son congruentes con escalas predeterminadas. La escala
del número de horas trabajadas podría ir de 0 a 100. Es improbable que un empleado
trabaje más de 100 horas a la semana. En nuestro ejemplo, el sistema de información
determinaría que la cifra de 400 horas rebasa la escala, tras de lo cual
proporcionaría retroalimentación al respecto, en forma de un mensaje de error, por
ejemplo. Gracias a esta retroalimentación, se revisará y corregirá la entrada a fin
de fijar en 40 el número de horas trabajadas. De no detectarse este error, se
imprimirá en el cheque una cifra de pago neto muy elevada.

18
La retroalimentación también es de gran importancia para administradores y
tomadores de decisiones. La salida de un sistema de información podría indicar, por
ejemplo, que los niveles de inventario de ciertos artículos son cada vez más bajos.
Un administrador podría utilizar esta retroalimentación para decidir el pedido de
más artículos. Los nuevos pedidos para el reabastecimiento del inventario se
convertirían entonces en entradas del sistema. En este caso, el sistema de
retroalimentación reacciona a la existencia de un problema y alerta al
administrador acerca de la escasez de ciertos artículos del inventario. Además de
este método reactivo, un sistema de computación también puede adoptar un método
proactiyo y prever la futura ocurrencia de determinados hechos con el propósito de
evitar problemas. Este concepto, llamado pronóstico, puede ser útil para estimar
ventas futuras y realizar pedidos de inventario antes de que éste sea insuficiente.

5.2. El Lenguaje Unificado del Modelado – UML Según, Booch, G., Rumbaugh, J. &
Jacobson, I. (2000)2, indica que UML es un lenguaje estándar para escribir planos
de Software. UML puede utilizarse para visualizar, especificar, construir y
documentar los artefactos de un sistema que

involucra una gran cantidad de software. UML es apropiado para modelar desde
Sistemas de Información en empresas hasta aplicaciones distribuidas basadas en la
Web e incluso para sistemas empotrados de tiempo real muy exigentes. Es un lenguaje
muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego
desplegar tales sistemas. Aunque sea expresivo, UML no es difícil de

aprender ni utilizar. UML, es sólo un lenguaje y por tanto es tan sólo una parte de
la metodología para desarrollar software. UML es un Lenguaje, que proporciona un
vocabulario y las reglas para combinar palabras de ese vocabulario con el objetivo
de posibilitar la comunicación. UML es un Lenguaje para Visualizar, es algo más que
un simple montón de símbolos gráficos; detrás de cada símbolo en la notación UML
hay una semántica bien definida. De esta manera, un desarrollador puede escribir un
modelo en UML y otro desarrollador o incluso otra herramienta, puede interpretar
este modelo

19
sin ambigüedad. UML es un Lenguaje para especificar, significa construir modelos
precisos y completos. UML es un Lenguaje para construir, sus modelos pueden
conectarse de forma directa a una gran variedad de lenguajes de programación.

UML es un lenguaje para documentar, una organización produce toda clase de


artefactos que incluyen requisitos, arquitectura, diseño, código fuente,

planificación de proyectos, pruebas, prototipos y versiones.

UML está pensado principalmente para sistemas con gran cantidad de


software. Ha sido utilizado de forma efectiva en dominios tales como: - Sistemas de
información de empresas. - Bancos y servicios financieros. - Telecomunicaciones. -
Transporte. - Defensa/Industria aeroespacial. - Comercio. - Electrónica médica. -
Ámbito científico. - Servicios distribuidos basados en la Web.

________________________
2

“El Lenguaje Unificado de Modelado”. Manual de Referencia”

20
Figura 04: Métodos de Apoyo al UML

Fuente: Booch, G., Rumbaugh, J. & Jacobson, I. (2000)

UML no está limitado al modelado de software. De hecho es lo suficientemente


expresivo para modelar sistemas que no son software como flujos de trabajo
(workflows) en el sistema jurídico, estructura y comportamiento de un sistema de
vigilancia médica de un enfermo, y el diseño de hardware. El vocabulario de UML
incluye tres bloques de construcción: 1. Elementos 2. Relaciones 3. Diagramas UML
como lenguaje tiene una sintaxis y una semántica bien definida. La parte más
visible de la sintaxis de UML, es su notación gráfica. UML puede describir
cualquier tipo de sistema en términos de diagramas orientados a objetos. Los
diagramas se utilizan para dar diferentes perspectivas del problema según lo que
interesa representar en un determinado momento. Los diagramas que UML defina lo
representamos en siguiente figura.

21
5.3. El Proceso Unificado de Racional Según, Kruchten, P. (2000)3, que indica que.
El Proceso Unificado Rational es un proceso de Ingeniería de software. Este provee
un enfoque disciplinado de tareas y responsabilidades dentro de una organización
para su desarrollo. Su meta es asegurar la producción de software de una calidad
superior que satisfaga las necesidades de sus usuarios finales, dentro de una
administración y cronograma establecido.

El Proceso Unificado Rational realiza la productividad del equipo, proporcionándole


el acceso fácil a cada miembro del equipo que esta desarrollando el sistema, a una
base de conocimientos con las pautas, plantillas y guías de la herramienta para
toda actividad crítica de desarrollo. Teniendo todos los miembros del equipo el
acceso a la misma base de conocimiento, no importa si se trabaja con los
requerimientos, diseño, prueba, administración del proyecto, o administración de la
configuración, se asegura que todos los miembros del equipo comparten un lenguaje
común, un proceso común y una visión de cómo se desarrollará el software.

Las actividades del Proceso Unificado Rational crean y mantienen modelos más que
enfocarse en cantidades de producción de documentos en general. El Proceso
Unificado Rational enfatiza el desarrollo y mantenimiento de modelos, para una
representación rica en semántica para el desarrollo del software del sistema. El
proceso Unificado Rational es una guía para saber cómo usar eficazmente el Lenguaje
de Modelado Unificado (UML). El UML es una industria de un lenguaje estándar que
nos permite comunicar requisitos, arquitecturas y planes claramente.
________________________
3

“The Racional Unified Process and Introduction”.

El Proceso Unificado Rational es soportado por herramientas que automatizan partes


generales del proceso. Ellos usan, crean y mantienen los artefactos-modelos en

22
particular, del proceso de ingeniería de software: visualizando el modelo,
programando, probando, etc.

Ellos son apoyo de toda contabilidad asociada con la dirección de cambios así como
la dirección de la configuración que acompaña cada iteración.

El Proceso Unificado de Rational es un proceso configurable. Ningún proceso


individual es adecuado para todo el desarrollo del software. El Proceso Unificado
desarrolla equipos pequeños adecuados; así como el desarrollo de grandes
organizaciones. El Proceso Unificado se funda en una arquitectura del proceso
simple y claro que proporciona la comodidad para una familia de procesos. También
puede variarse para acomodarse a las situaciones diferentes. Este contiene un Kit
de desarrollo, que proporciona el soporte para la configuración del proceso,
siempre que la organización tenga la necesidad. El Proceso Unificado de Rational
captura muchas de las prácticas más adecuadas en el desarrollo del software moderno
en una forma conveniente para una gama amplia de proyectos y organizaciones.

El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje


Horizontal representa tiempo y muestra el aspecto dinámico del proceso como está
representado en el gráfico, y este es expresado en términos de ciclos, fases,
iteraciones e hitos. El eje vertical representa el aspecto estático del proceso:
cómo se representa en el gráfico, y es expresado en las actividades, artefacts,
workers y workflows.

La figura de ejemplo muestra cómo el proceso se estructura a lo largo de dos


dimensiones. Figura 05: Fases del Proceso Unificado de Rational – RUP

23
Fuente: Rational Software Corp.

El ciclo de vida del software está partido en ciclos, y cada ciclo trabaja en una
nueva versión del producto. El Proceso Unificado Rational divide un ciclo de
desarrollo en cuatro fases consecutivas: La fase inicial. La fase de elaboración.
La fase de construcción. La fase de transición.

Cada fase es terminada por un punto en el tiempo (definición del hito), se da


decisiones que deben hacerse y por lo tanto llegar a metas que deben lograrse para
conseguir soluciones.

5.3.1. La Fase Inicial

24
Durante la fase inicial, usted establece el “caso” del negocio (business case) para
el sistema y delimita el alcance del proyecto. Al final se examina los objetivos
del ciclo de vida del proyecto y decidir si se continúa con el desarrollo del
sistema.

5.3.2. La Fase de Elaboración En la fase de la elaboración, es analizado el dominio


del problema; se establecen los cimientos de una buena arquitectura, se desarrolla
el plan del proyecto y eliminación de elementos de alto riesgo del proyecto. AL
final se examina los alcances y los objetivos del sistema, la elección de la
arquitectura y la elección de los riesgos más grandes, y se decide si se deba pasar
a la construcción.

5.3.3. La Fase de Construcción. Durante la fase de construcción, todo componente


restante y característica de la aplicación es desarrollado e integrado dentro del
producto, y toda característica es probada completamente. La fase de construcción,
es en un sentido, un proceso industrial donde se enfatiza los pedidos en el manejo
de recursos y control de operaciones; para dar costos óptimos, horarios y calidad.
Al final se decide el software, los lugares donde se instalará y los usuarios están
todos preparados para empezar a funcionar.

5.3.4. La fase de Transición. El propósito de esta fase es la transición del


producto software al ámbito del usuario. Una vez que el producto se ha dado al
usuario final, usualmente surgen dificultades que se manifiestan, lo que exige que
se desarrolle nuevas versiones, corrija algunos problemas o se termine las
características que se propusieron. Se define si se han satisfecho los objetivos
del ciclo de vida del proyecto.

5.4. Programación Java4

25
El lenguaje para la programación en Java, es un lenguaje orientado a objeto, de una
plataforma independiente. El lenguaje para la programación en Java, fue
desarrollado por la compañía Sun Microsystems, con la idea original de usarlo para
la cremación de páginas WEB. Esta programación Java tiene muchas similitudes con el
lenguaje C y C++, asi que si se tiene conocimiento de este lenguaje, el aprendizaje
de la programación Java será de fácil comprensión por un programador que haya
realizado programas en estos lenguajes.

Con la programación en Java, se pueden realizar distintos aplicativos, como son


applets, que son aplicaciones especiales, que se ejecutan dentro de un navegador al
ser cargada una pagina HTML en un servidor WEB, Por lo general los applets son
programas pequeños y de propósitos específicos.

Otra de las utilidades de la programación en Java es el desarrollo de aplicaciones,


que son programas que se ejecutan en forma independiente, es decir con la
programación Java, se pueden realizar aplicaciones como un procesador de palabras,
una hoja que sirva para cálculos, una aplicación grafica, etc. en resumen cualquier
tipo de aplicación se puede realizar con ella. Java permite la modularidad por lo
que se pueden hacer rutinas individuales que sean usadas por más de una aplicación,
por ejemplo tenemos una rutina de impresión que puede servir para el procesador de
palabras, como para la hoja de calculo.
4

Lenguajes de Programación: Programación Java.

http://www.lenguajes-de-programacion.com/programacion-java.shtml

5.5. Conceptos clave del lenguaje de programación java5

26
SUN MICROSYSTEMS comenzó a desarrollar JAVA con el objeto de crear un lenguaje
independiente de la plataforma y del sistema operativo, para el desarrollo de
electrónica de consumo (dispositivos electrónicos inteligentes como televisores,
videos, etc). El proyecto original llamado <<Green>>, empezó apoyándose en C++, pro
a medida que pasaba el tiempo el equipo de desarrollo se empezó a meter con
problemas de portabilidad. Para evitar estos problemas decidieron desarrollar su
propio lenguaje y en agosto de 1991 nació un nuevo lenguaje orientado a objetos,
bautizado con el nombre de <<Oak>>. A mitad de 1993 se lanzó Mosaic, uno de los
primeros navegadores de la web y empezó a crecer el intereses por la Internet.
Entonces la idea fue rediseñar el lenguaje para aplicaciones de Internet, y en
enero de 1995 Oak se convirtió en JAVA. SUN creó el entorno JDK 1.0 en 1996, y se
lanzó a principios de 1997. En diciembre de 1998 se lanzo lo que se conoce como
java 2 (el JDK 1.2 durante su fase de pruebas). El lenguaje de programación Java
esta diseñado para ser: Orientado a objetos Distribuido Simple Multihilos Seguro
Plataforma Independiente

[OSUM]. http://osum.sun.com/group/esimeucipnosum/forum/topics/conceptos‐clave‐del‐
lenguaje

La explicación detallada es la siguiente: Orientado a objetos (Object-Oriented)

27
EL lenguaje de programación java es un lenguaje de programación Orientado a Objetos
(OOP de Object Oriented Programming), por que una de las principales
características de la programación de la Tecnología Java es la creación de objetos,
piezas autónomas de código, estas pueden interactuar con otros objetos para
resolver un problema. Cabe mencionar que Java fue basado inicialmente en el
lenguaje C++.

La OOP (Object-Orient Programming) difiere de la programación procedural, por que


la segunda subraya la secuencia de pasos de código requerido para solucionar un
problema, mientras que la OOP subraya la creación e interacción de objetos.

Distribuido El lenguaje de programación Java es un lenguaje distribuido por que el


lenguaje da soporte para tecnologías de redes distribuidas, como la invocación de
métodos remotos (RMI), CORBA, URL. Adicionalmente, las clases dinámicas cargan
capacidades de la tecnología Java que permite descargar piezas de código para ser
descargadas de Internet y ser ejecutadas en tu computadora

Simple El lenguaje de programación Java es simple por que los diseñadores


eliminaron algunas de las complejidades o programación obscura encontrada en otros
populares lenguajes de programación. Un ejemplo es la eliminación de punteros para
localidades de memoria, utilizados en el lenguaje C. Tiene una característica
llamada Garbage Collector (Recolector de basura) que permite monitorear y eliminar
objetos que ya no son monitoreados.

28
Multihilos El lenguaje Java soporta multihilos. Esto es la realización de varias
tareas al mismo tiempo, como una query a una base de datos y desplegarla en una
interfaz de usuario. Multihilos permite que los programas en Java sean muy
eficientes en el uso de los recursos de sistema.

Seguro Los programas hechos con la tecnología Java son seguros por que el lenguaje
de programación Java, en el entorno en que sus programas corren, usa medidas de
seguridad para proteger programas de ataques. Estas medidas incluyen: - Prohibida
la manipulación de memoria usando punteros. - Prohibida la distribución de
programas, como son applets, desde leer y escribir en el disco duro de una
computadora. - Verificar que todos los programas de la tecnología Java sean código
valido. - Soporta firmas digitales, códigos de la Tecnología Java pueden ser
“firmados” por una compañía o persona en donde una persona puede recibir el código
verificando la legitimidad del mismo.

Plataforma – Independiente Programas escritos en muchos lenguajes usualmente


requieren numerosas

modificaciones para correr en mas de una plataforma, una combinación de CPU y


sistemas operativos. EL lenguaje de programación Java es plataforma independiente.
Por eso su lema “Escribes una vez. Corre en cualquier lugar”. Los programas en Java
también son compilados. Sin embargo, el resultado será el mismo para cualquier
plataforma, pues el compilador genera un archivo llamado bytecode, quien tiene las
especificaciones necesarias para correr nuestro programa en

29
cualquier CPU o sistema operativo. Después de que el bytecode es creado, es
interpretado (quien ejecuta el programa) por un interprete de bytecode llamada
maquina virtual (Virtual Machine). Por esta razón se dice que la tecnología Java es
interpretada y portable por ser ejecutada en cualquier plataforma.

Para los programas hechos en tecnología Java sean plataforma independiente, una
maquina virtual llamada Java Virtual Machine(JVM) es requerida en todas las
plataformas donde tus programas son ejecutados. a JVM es responsable de interpretar
el código, cargar las clases de Java, y ejecutar los programas. Sin embargo, los
programas Java necesitan algo mas que la JVM, para ejecutarse. La tecnología Java
también necesita de un set de clases o librerías estándar para la plataforma. Las
librerías son clases en java que son código pre-escrito que puede ser coordinado
con el código que tu escribes para crear aplicaciones robustas, estas librerías son
la API.

La combinación de ambas hace referencia al JRE (Java Runtime Environment). Este


conjunto de software es el ambiente necesario para ejecutar cualquier programa
hecho en la tecnología Java, y que será común en cualquier plataforma donde se
corra.

5.6. Netbeans. IDE (Entorno de desarrollo integrado) Se ha optado por la


utilización de Netbeans 6.5.1 para la puesta en marcha del proyecto, en primer
lugar porque se trata de una herramienta de software libre y en segundo lugar
porque es la que utilizamos en la escuela. Netbeans cuenta con una gran base de
usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en todo
el mundo.

30
Sun Microsystems fundó el proyecto de código abierto NetBeans en junio 2000 y
continúa siendo el patrocinador principal de los proyectos. Netbeans cuenta con un
plugin llamado Visual Web Java Server Faces, basado en la tecnología JSF. Para el
desarrollo del proyecto se ha optado por utilizar este framework ya que se adapta
perfectamente a sus características.

5.7. Introducción al Framework Visual Web Java Server Faces6 Con este nuevo
Framework de Java se pueden generar páginas web visualmente. El IDE de desarrollo,
al agregar una nueva página nos genera el cogido JSP necesario para generar la
respuesta HTML al cliente. Se puede desarrollar un portal al mejor estilo “drag and
drop” (arrastrar y soltar) y editando las características de los componentes desde
la pestaña “propiedades” del editor.

5.8. Framework Visual Web Java Server Faces Culebras, D & i Majó, (2008)7. La
peculiaridad de este framework perteneciente a Netbeans.org es que te facilita en
gran media tu adaptación a JavaServer Faces y a los nuevos componentes, de los que
es necesario saber cuales son sus características y comportamientos.

6 7

Introducción a Visual Web Java Server Faces. http://www.geronet.com.ar/?p=77


“Tienda Virtual en JavaServar Faces”.

A continuación, mostraremos cuales son las características más destacables del


framework Visual Web JavaServer Faces : • Se trata de una herramienta capaz de
aplicar el MVC de JavaServer Faces de una manera visual, sin apenas programar ni el
archivo de configuración faces-

31
onfig.xml, ni el comportamiento de los componentes que te facilita en su paleta.
Visual Web JSF lo hace por ti. • Las reglas de navegación se gestionan visualmente,
tampoco tienes que programarlas. Lo único que has de hacer es relacionar mediante
un simple clic cual es el origen y el destino de las diferentes peticiones del
usuario. • En el momento en que añades una página jsf, Visual Web JSF añade la
clase asociada .java de la vista a lo que se llamará “domotechonline” la cual
ejercerá de capa Aplicación, es decir de controlador. • Visual Web JSF, contiene
tres pestañas en las que te permite interactuar entre vista (.jsp), controlador
(.java) y una tercera pestaña dedicada al diseño de la jsp.

• En toda clase .java generada existen tres atributos dedicados a cada uno de los
tres posibles ámbitos Sesión, Aplicación o Petición, de manera que siempre puedes
acceder a los atributos de la Sesión a través de sus métodos get y set. • Existe la
posibilidad de añadir cualquier componente de la paleta a tu página jsf únicamente
arrastrándolo de la paleta, una vez allí puedes modificar sus características en la
ventana de propiedades y lo que es de mayor importancia puedes añadir el componente
como atributo de la clase .java asociada a tu jsp a través de la función “Add
Binding Attribute”. Esto te permitirá cambiar los comportamientos, estados o las
características de los componentes a la hora de mostrar la información o de dar
respuestas al usuario. • Otra de las características de Visual Web JSF es la
existencia de una opción llamada “Property Bindings”, la cual te permite de manera
visual editar las propiedades de los componentes relacionándolos con los atributos
de los beans de la capa Aplicación. • Las reglas de validación así como las reglas
de conversión de igual forma se gestionan visualmente.

32

Es interesante ya que te permite crear tus propias colecciones en los beans e


introducir sus contenidos de una forma muy sencilla, simplemente hemos de tener los
get y set de cada colección como condición indispensable. Visual Web JSF también
implementa a su manera el patrón DAO para su acceso a los datos de persistencia. Me
consta que Visual Web JSF te permite gestionar las transacciones de forma visual,
fácil y rápida. En mi opinión, de una forma poco mantenible y con grandes
acoplamientos. Sería interesante dicha utilización para proyectos simples y de
nulas ampliaciones siempre que se empiecen desde cero, nunca para proyectos ya
empezados. Para finalizar, comentar que para una primera toma de contacto con la
tecnología este marco de trabajo puede llegar a ser interesante puesto que te
permite llevar a cabo aplicaciones Web basadas en JavaServer Faces sin tener muchos
conocimientos de la tecnología en un tiempo razonable.

33
CAPITULO VI PROCESO DE DESARROLLO DE SOFTWARE

34
6. PROCESO DE DESARROLLO DE SOFTWARE
6.1. FASE INICIAL 6.1.1. MODELAMIENTO DE VISIÓN DEL NEGOCIO A. DOCUMENTO VISIÓN DEL
NEGOCIO A.1. Introducción A.1.1. Propósito El propósito de este documento es
ofrecer un esquema del análisis y diseño del funcionamiento del sistema, a nivel de
procesos, actores y diagramas para el “Sistema de control para mejorar los procesos
de la información de los análisis de suelos en el laboratorio de suelos de
Universidad Nacional de Ucayali”.

A.1.2. Alcance En este trabajo se realizará el modelamiento del Sistema de control


para mejorar los procesos de la información de los análisis de suelos en el
laboratorio de suelos de la Universidad Nacional de Ucayali desarrollado por un
alumno de la Facultad de Ingeniería de Sistemas y de Ingeniería Civil con una
arquitectura cliente servidor 3 capas con la modelo vista controlador 2.

El Sistema de control para mejorar los procesos de la información de los análisis


de suelos en el laboratorio de suelos de la Universidad Nacional de Ucayali,
permitirá a los usuarios tener un mejor control de los registros de las solicitudes
de análisis de suelos por parte de los prestadores de este servicio, también un
control de los registros de los análisis realizados en la parte académica por parte
de los docentes y alumnos de los cursos que se dictan en este laboratorio. Así
mismo el sistema facilitara la gestión, consultas de información en

35
tiempo real y generar reportes de los análisis realizados en el laboratorio de
suelos de la UNU.

A.2. Posicionamiento A.2.1. Oportunidad del negocio El Sistema de Control mejorará


progresivamente el registro de los datos para mejorar los procesos de la
información de los análisis de suelos realizados de las muestras. Almacenado estos
datos en una base de datos, permitiendo la automatización de las consultas con
respecto a análisis realizados con anterioridad al tener un mejor

manejo de la información y mayor velocidad al procesar la información para la toma


de decisiones.

A.2.2. Exposición del problema Realidad problemática El laboratorio de suelos de la


Universidad Nacional de Ucayali no cuenta en la actualidad con un sistema de
control que permita tener un control de los registros de las solicitudes y de los
análisis de suelos realizados con eficiencia para mejorar los procesos de la
información, tener una base de datos con la cual se puedan realizar consultas y
generar reportes

Análisis del problema 1. Los procesos de control de los registros de datos de la


prestación del servicio de análisis de suelos en el laboratorio de suelos de la UNU
en la actualidad se realizan de manera manual en hojas (tipo bulki, bond, etc.),
cuaderno de apuntes, etc, disponibles en ese momento. El uso de estas hojas de

36
notas, cuaderno de apuntes, etc., que no tiene un formato adecuado para el llenado
de la información de la muestra de suelos, da como consecuencia un traspapelado
entre otras hojas de apuntes que ocasionan demora al recurrir a la información de
los análisis de suelos y también ha la perdida de la información. Esto se debe, ya
que el laboratorio no cuenta con un control de fichero, sistema de información, un
sistema informático, etc. 2. El proceso de registro de muestras de suelos y el
registro de los análisis realizados se hace de forma manual, ocasionada un bajo
nivel de seguridad, Esto se debe, ya que el laboratorio no cuenta con un control de
fichero, sistema de información, un sistema informático, etc. 3. No hay
actualización de los datos de los usuarios porque no se cuenta registro de estos
datos. 4. Demora en los procesos de consultas de de análisis realizados con
anterioridad

Afecta a: - Universidad Nacional de Ucayali. - Alumnos. - Docentes. - Encargados


del laboratorio de análisis de suelos de la UNU.

Impacto - Imagen institucional. - Proceso lento y mal definido que dificultan el


control de los registros de los datos de los análisis de suelos inadecuado

37
procesos de consultas, generar reportes que ocasiona pérdida de tiempo a los
encargados del laboratorio, alumnos, docentes, agricultor, investigador que
necesitan de la información de los análisis de suelos.

Solución exitosa será: - Mejorar los procesos de la información teniendo un mejor


control de los registros de los datos de los análisis de suelos para poder contar
con información relevante y oportuna para una eficiente toma de decisiones

38
A.3. Descripción de Stakeholder y usuarios A.3.1. Mercado Demográfico Cuadro Nº 03:
Población N Facultad de Agronomía: Alumnos del IV ciclo del curso de Geología y
Edafología Alumnos del V ciclo del curso de Fertilidad de Suelos Alumnos del VII
ciclo del curso de Manejo y Conservación de suelos Docentes designados para estos
cursos 3 1.09% 78 83 35 28.26% 30.07% 12.68% %

Facultad de Ciencias Forestales: Alumnos de IV ciclo del curso de Edafología


Alumnos del VII ciclo del curso de Suelos Fértiles Docentes designados para estos
cursos 43 31 1 15.58% 11.23% 0.36%

Personal del Laboratorio de Suelos de la UNU Jefe de laboratorio Técnico de


laboratorio 1 1 0.36% 0.36%

Total

276

100%

Fuente: Dirección General de Servicios Académicos – Vicerrectorado Académico de la


Universidad Nacional De Ucayali.

La población del estudio estará constituida por 276 personas. El Sistema de control
para mejorar los procesos de la información de los análisis de suelos en el
laboratorio de suelos de la UNU, el sistema será ejecutado y usado desde el
laboratorio de suelos de la UNU.

39
A.3.2. Sumario de Stakeholder

Cuadro 04: Sumario de Stakeholders NOMBRE REPRESENTANTE Docente responsable del


Jefe de laboratorio laboratorio de suelos de la UNU Trabajador administrativo Jefe
de almacén responsable del área de almacén de la UNU ROL Monitorea, verifica y hace
la corrección de los procesos del laboratorio de suelos de la UNU Monitorea los
inventarios de la institución.

Terceros (agricultor, investigador).

A si mismo y a Instituciones públicas o privadas.

Solicitar servicios del laboratorio de suelos de la UNU.

A.3.3. Sumario de Usuarios Cuadro 05: Sumario de Usuarios NOMBRE Técnico de


laboratorio DESCRIPCIÓN Personal administrativo que se encarga de la gestión de
registros y servicios del laboratorio Alumnos Realiza el registro de sus practicas
de laboratorio Docentes Realiza el registro de sus practicas de laboratorio
Representa así mismo. Representa así mismo. STAKEHOLDERS Representa así mismo.

A.3.4. Ambiente de Usuarios Técnico de laboratorio: Tendrá acceso al sistema para


registrar los reactivos, equipos y materiales del laboratorio. También realizará el
registro de los servicios del laboratorio de suelos prestados a terceros.

40
Alumnos: Tendrán acceso al sistema para registrar y sus prácticas realizadas.

Docentes: Tendrán acceso al sistema para registrar y sus prácticas realizadas.

A.3.5. Necesidades de los usuarios Cuadro 06: Necesidades de usuarios. NECESIDAD


PRIORIDAD CONCERNIENTE SOLUCION ACTUAL
Gestión de registros de laboratorio Alta No hay sistema Tiempo de respuesta lento e
ineficiente. de control de los registros del laboratorio. Habrá un sistema
informático para el la gestión de actividades de los docentes.

SOLUCION PROPUESTA

Registras sus prácticas realizadas. Alta

Implementar un sistema La información no es la correcta El sistema es totalmente


manual. informático que automatice y mejore la velocidad del procesamiento de
información.

Registras sus prácticas realizadas. Alta

Implementar un sistema La adquisición de esta información es dificultosa. El


sistema es totalmente manual. informático que automatice y mejore la velocidad del
procesamiento de información.

41
A.3.6. Alternativas El desarrollo del Proyecto de implementación de un “Sistema de
control para mejorar los procesos de la información en el laboratorio de suelos de
la UNU” presenta las siguientes alternativas: Formar un equipo de trabajo dentro de
la Escuela Profesional Ingeniería de Sistemas de la UNU para el desarrollo del
proyecto. Solicitar los servicios de una empresa desarrolladora de software para
que realice el Sistema de control. Solicitar practicantes, tesistas o estudiantes
interesados en desarrollar la implementación del sistema de control para mejorar
los procesos de información del laboratorio de suelos. Solicitar los servicios de
una empresa desarrolladora de software para que realice el sistema de control.

A.4. Objetivos de Modelamiento del Negocio Proceso de Gestión de Registro del


laboratorio de suelos Registrar los reactivos, equipos y materiales del
laboratorio. Reporte de los análisis realizados. Proceso de Gestión de servicios

También podría gustarte