Universidad de las Ciencias Informáticas Facultad 4
Título: "Sistema de Gestión y Control de Pase Eventual de la Facultad Regional de Artemisa”.
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autor: Yanko Veitia Vega Tutor: Msc. Rolando Quintana Aput
La Habana, Junio de 2008
DECLARACIÓN DE AUTORÍA
Declaramos ser autores de la presente tesis y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
<nombre autor> <nombre tutor>
______________ ______________
Firma del Autor Firma del Tutor
DATOS DE CONTACTO
"[insertar breve curriculum e información de contacto del tutor]"
"[insertar breve curriculum e información de contacto del asesor]"
"[insertar breve curriculum e información de contacto del consultante]"
AGRADECIMIENTOS
Quisiera agradecer antes que nada a todos las personas que no solo me ayudaron en la elaboración de este trabajo, sino que además me soportaron durante todo el tiempo que duró su elaboración, en especial:
A Osvaldo Aguilar, Víctor Antonio Barzana y Rolando Santamaría, estudiantes integrantes del proyecto de informatización de la Facultad Regional de Artemisa (FRA) y parte del grupo de desarrollo del Framework A++, por la ayuda prestada en la implementación de la aplicación, y el empeño mostrado en la tarea.
A Rolando Quintana Aput, mi tutor, por la ayuda y orientación prestada.
A los otros cuatro del “grupo de los 5”: Geysel, Tompsom, Oscar y Carlos, por la preocupación y el apoyo durante todo el tiempo que estuvimos en la FRA.
A mi madre, por la espera y la preocupación; por decirme “no te preocupes, todo se arregla”; por ser padre y madre a la vez; por las llamadas cuando no lo hacía yo. En fin por todo lo que ha hecho en este tiempo…..
A mi novia, Lisset, por la paciencia; por fajarse conmigo cuando me “cierro”; por el amor y el cariño; por los documentos enviados para la investigación; por la preocupación y las malas noches.
A Rodolfo, por el apoyo y las “consultas” que nos hicimos antes de poder decir “al fin terminamos”, y por la música que tanta falta me hizo…
A mi abuela Ana, a mis tías, a mi tío Rodolfo, a mis primos y primas, y a mi hermano, por estar ahí siempre.
A todos gracias y que perdone alguien si se quedó, fue solo un descuido de mi desmemoriado cerebro.
DEDICATORIA
“Sólo los necios hablan de desdichas, o los egoístas. La felicidad existe sobre la tierra; y se la conquista con el ejercicio prudente de la razón, el conocimiento de la armonía, del universo, y la práctica constante de la generosidad”.
José Martí
A la memoria de mi padre, por todo lo que has representado aunque ya no estés presente: por la guía y el amor que me diste, por los sueños…
A mi madre, por el amor y la entrega, por ser todo y más aún…
A mi abuela Ana…
A Lisset, por el amor y la “paciencia”; y por revisarme el trabajo…
A Fidel, por la oportunidad…
A Migdalia por soportarme durante todo este 5to año…
A los amigos…
A la UCI…
RESUMEN
Ante la poca eficiencia del Proceso de Gestión y Control de Pase Eventual en la Facultad Regional de Artemisa (FRA) de la Universidad de las Ciencias Informática (UCI), la cual radica en Artemisa, se plantea la tarea de implementar una Aplicación WEB que permita la Automatización de este proceso con la idea de acabar con todas las deficiencias que se presentan actualmente en la ejecución de este proceso.
El resultado de este trabajo constituye la primera aplicación desarrollada por el Proyecto de Informatización de la FRA y en la implementación de la misma participan dos programadores integrantes de dicho proyecto. Este Trabajo actualmente no posee antecedentes en la FRA
Al comenzar todo el proceso investigativo en busca de la solución a la problemática planteada, no se tiene conocimiento de alguna herramienta ya implementada e implantada que permita dar solución a dicho problema.
En el desarrollo de la propuesta de solución se utilizó un framework que actualmente está en desarrollo por parte de algunos estudiantes integrantes del proyecto de informatización de esta facultad.
PALABRAS CLAVE
Aplicación WEB, Automatización, Digitalización, Framework.
ÍNDICE
INTRODUCCIÓN ... 1
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 4
1.1) Introducción ... 4
1.2) Objeto de Estudio. ... 4
1.2.1) Flujo actual de los procesos... 4
1.2.2) Análisis Crítico de la Ejecución del Proceso. ... 6
1.3) Procesos Objeto de Automatización. ... 8
1.4) Gestión de procesos. ... 9
1.5) Sistemas Automatizados existentes vinculados al campo de acción. ... 11
1.6) Aplicación a realizar: Las aplicaciones WEB. ... 12
1.6.1) Modelo Cliente - Servidor. ... 14
1.7) Tendencias sobre el desarrollo de Aplicaciones WEB. ... 16
1.7.1) Gestor de Base de datos: MySQL... 18
1.7.2) PHP: "PHP Hypertext Pre-processor". ... 19
1.7.5) Servidor Web ... 20
1.8) Fundamentación de la Metodología a usar. ... 22
1.8.1) Metodología XP. ... 23
1.8.2) Metodología MSF. ... 23
1.8.3) Metodología RUP. ... 25
1.8.4) Lenguaje Unificado de Modelado UML. ... 28
1.9) Frameworks. ... 30
1.10) Framework A++ ... 32
1.11) Tendencias sobre Estudios Estadísticos. ... 34
1.11.1) Medidas Estadísticas para estudios sobre poblaciones. ... 35
1.12) Conclusiones ... 38
CAPÍTULO 2: NEGOCIO Y ANÁLISIS DE REQUERIMIENTOS ... 39
2.1) Introducción. ... 39
2.2) Modelo de Negocio Actual. ... 39
2.2.1) Reglas de negocio a tener en cuenta. ... 39
2.3) Actores del negocio. ... 40
2.4) Diagramas de Casos de Uso del Negocio (CUN). ... 40
2.5) Trabajadores del Negocio. ... 42
2.6) Realización de los CUN. ... 42
2.7) Modelo de Objetos. ... 53
2.8) Análisis de los Requisitos de la aplicación a realizar. ... 54
2.8.1) Requisitos Funcionales de la aplicación a realizar. ... 54
2.8.2) Análisis de los Requisitos no funcionales. ... 57
2.9) Modelo de Casos de Uso del Sistema (CUS). ... 59
2.10) Descripción de los Casos de Uso del sistema a Implementar... 61
2.10.1) Casos de Uso del paquete Gestionar Entradas y Salidas de Pase. ... 61
2.10.2) Casos de Uso del paquete Reportes. ... 69
2.10.3) Casos de Uso del paquete Seguridad. ... 72
2.11) Conclusiones ... 76
CAPÍTULO 3: DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA ... 77
3.1) Introducción. ... 77
3.2) Diagramas de clases del diseño. ... 77
3.2.1) Paquete Pase_Estadía. ... 79
3.2.2) Paquete Reportes. ... 82
3.2.3) Paquete Seguridad. ... 83
3.3) Consideraciones por Capas para la Aplicación. ... 84
3.4) Principios de Diseño. ... 85
3.4.1) Interfaz de usuario... 85
3.5) Diseño de la Base de Datos. ... 87
3.5.1) Modelo lógico de los datos. ... 87
3.5.2) Modelo físico de los datos. ... 88
3.6) Modelo de Despliegue. ... 89
3.6.1) Modelo de Capas Empleado. ... 89
3.6.2) Diagrama de Despliegue. ... 89
3.7) Conclusiones. ... 90
CAPÍTULO 4: ESTUDIO DE FACTIBILIDAD ... 91
4.1) Introducción. ... 91
4.2.1) Cálculo de los Puntos de Casos de Uso sin Ajustar (UUCP). ... 91
4.2.2) Cálculo de los Puntos de Casos de Uso Ajustados. ... 93
4.2.3) Estimación de Esfuerzo. ... 95
4.5) Beneficios tangibles e intangibles. ... 97
4.6) Análisis de costos y beneficios... 98
4.7) Conclusiones. ... 98
CONCLUSIONES GENERALES ... 99
RECOMENDACIONES ... 101
REFERENCIAS BIBLIOGRÁFICAS ... 102
BIBLIOGRAFÍA ... 104
GLOSARIO DE TÉRMINOS... 107 ANEXOS ... ¡ERROR! MARCADOR NO DEFINIDO.
INTRODUCCIÓN
En la Universidad de las Ciencias Informáticas (UCI) existen algunas aplicaciones para la comunidad estudiantil, desarrolladas en diferentes vertientes; por ejemplo para el tema de la información se pueden destacar dos aplicaciones: La Intranet de la Universidad y el sitio Akademos, en los cuales se brinda información de todo tipo a los estudiantes ya sea referente a Extensión Universitaria o a la docencia, rendimiento académico, entre otras, constituyendo de esta manera una Comunidad Virtual de estudiantes. El objetivo de estas aplicaciones es el lograr la automatización de todos los procesos internos de la Universidad, logrando con ello una mayor organización, y por tanto una mayor eficiencia en la gestión y control de los mismos.
La Facultad Regional de Artemisa, radicada en el Batey del CAI Azucarero Abraham Lincoln, en el municipio de Artemisa, en la provincia La habana, presenta, por el poco tiempo que lleva funcionando, problemas en cuanto a la informatización de sus procesos. Uno de los procesos que genera actualmente más problemas es el de Control de los pases de estudiantes.
En esta facultad regional se dan dos tipos de pases, los cuales se enumeran a continuación:
1. Pase Ordinario. Este pase se otorga de forma masiva a los estudiantes generalmente cada 21 días, aunque puede sufrir cambios en dependencia de las necesidades que se presenten relacionadas con el proceso docente, a la hora de determinar la fecha de salida y entrada. Este tipo de pase dura aproximadamente 5 días y se trata siempre de que se otorgue entre el jueves de la semana planificada para la salida y el martes de la semana planificada para la entrada. Es el único tipo de pase donde se garantiza transporte para la salida y la entrada de los estudiantes.
2. Pase Eventual. Este pase abarca todas las salidas autorizadas para los estudiantes que no estén comprendidas en el pase ordinario. Aquí se determinan tres subtipos de pase:
a. Los pases hasta Artemisa. Estos pases se autorizan a los estudiantes por el Vicedecano de Beca y Extensión Universitaria o por el Especialista Superior de Residencia, y solo son válidos para viajes en horario diurno y hasta la ciudad de Artemisa, debido a la cercanía que tiene esta ciudad con la Sede Universitaria.
b. Pases de fin de semana. Estos pases se autorizan durante los fines de semana a estudiantes que deseen pasar el mismo fuera de la sede universitaria, y solo es válido desde el viernes, a la 1:00pm y hasta el lunes, a las 8:00am
c. Pases Extraordinarios. Con este tipo de pase se abarca todas las demás salidas autorizadas de los estudiantes, las cuales de una manera u otra pueden afectar la asistencia a clases.
En la sede universitaria de la Facultad Regional de Artemisa, la no informatización de este proceso, crea toda una serie de problemas que hacen que este no se realice con la debida eficiencia.
Entre estos problemas se pueden citar los siguientes:
1. Desconocimiento de dirección de servicio de la cantidad real de estudiantes presentes para los horarios de almuerzo y comida, lo cual genera el problema de que a veces sobra comida y otras falta, pues no se puede hacer un cómputo exacto de las raciones necesarias.
2. Control deficiente sobre la fecha y la hora de entrada y salida de los estudiantes de pase.
3. Incapacidad parcial para hacer reportes con información concreta, debido a que toda la información está en formato duro.
4. No existe una base de datos histórica con los pases a los estudiantes.
5. Imposibilidad de realizar estudios estadísticos relacionados a los pases de los estudiantes
Luego de visto esto se concluye que el Problema se reduce a: ¿Cómo hacer más eficiente el proceso de Gestión y Control del Pase de los estudiantes de la Facultad Regional de Artemisa y la posibilidad de realizar estudios estadísticos relacionados a los pases?
El Objeto de Estudio es la Gestión de Información sobre Estudiantes, enmarcando el Campo de Acción en el Proceso de Gestión y Control del Pase Eventual de los estudiantes de la Facultad Regional de Artemisa.
El Objetivo General consiste en mejorar la eficiencia del proceso de Gestión y Control del Pase Eventual Facultad Regional de Artemisa, a través de la propuesta e implementación de una herramienta de software.
Para lograrlo se plantean una serie de Objetivos Específicos, los cuales se enumeran a continuación:
1- Elaborar marco teórico-conceptual de la investigación.
2- Obtener el Diseño del Software para la automatización del proceso de Gestión y Control de Pases Eventuales.
3- Presentar el Software de Gestión y Control del Pase Eventual.
La Idea a Defender con este Trabajo de Diploma es que al desarrollar una herramienta de software que permita informatizar el Proceso de Gestión y Control del Pase Eventual de la Facultad Regional de Artemisa, se logrará resolver toda la situación problémica antes descrita, creando además otros servicios que en un futuro ayudarán a la digitalización de todos los procesos de dicha facultad.
Para poder cumplir con los objetivos específicos trazados se proponen las siguientes Tareas de Investigación:
1. Investigar sobre los Procesos de Desarrollo de Aplicaciones WEB orientados a la Gestión.
2. Investigar cómo se efectúa específicamente el Proceso de Gestión y Control del Pase Eventual en la Facultad Regional de Artemisa
3. Diseñar el software para la automatización del proceso de Gestión y Control de Pase Eventual.
4. Desarrollar la implementación el software de Gestión y Control del Pase Eventual.
Implementar el Diseño del software que permita automatizar el Proceso de Gestión y Control del Pase Eventual en la Facultad Regional de Artemisa.
Comprobar la funcionalidad del software que permita automatizar el Proceso de Gestión y Control del Pase Eventual en la Facultad Regional de Artemisa.
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA 1.1) Introducción
El objetivo de este capítulo es presentar todo el marco teórico conceptual asociado a la propuesta de solución al problema planteado. En él se pretende determinar cuál es la tecnología y la metodología más adecuadas a usar para desarrollar el software que dé solución al Problema ya explicado con anterioridad en la introducción: Automatizar el proceso de Gestión y Control de Pase Eventual de la Facultad Regional de Artemisa perteneciente a la Universidad de Ciencias Informáticas.
1.2) Objeto de Estudio.
El Objeto de Estudio del presente trabajo es la Gestión de Información sobre Estudiantes; el Campo de Acción es el Proceso de Gestión y Control del Pase Eventual de los estudiantes de la Facultad Regional de Artemisa.
La Gestión y el Control del Pase en la Facultad Regional de Artemisa, es un proceso en que intervienen dos actores esenciales: el estudiante y el Vice-Decano de Residencia y Extensión Universitaria de la Facultad. Como trabajadores del proceso se definen el propio Vice-Decano y el Especialista Superior de Residencia.
Todo este proceso se realiza, en su totalidad, de forma manual. Y el control de la información del mismo se lleva a cabo a través de registro físico, en papel, el cual sirve como base para la elaboración de reportes los cuales se envían vía correo a los solicitantes.
1.2.1) Flujo actual de los procesos
.Este proceso, desde la solicitud del estudiante hasta la entrega del bono de pase responde a políticas individuales para cada facultad, pues aún no hay un documento en la Universidad que lo defina y regule como tal.
En la Facultad Regional de Artemisa se definen varios tipos de pase, a continuación se describen los mismos aclarando primeramente que por razones de la dinámica propia de la Facultad y
de la Universidad a la que dicha Facultad pertenece, el Vice-Decano se ausenta frecuentemente durante el horario diurno, por lo que, aunque en la descripción que haremos del proceso se incluyen al Vice-Decano de Residencia y Extensión y al Especialista Superior de Residencia, generalmente el papel protagónico lo toma el Especialista. Los tipos de pase son:
1. Pase Ordinario:
Este tipo de pase se otorga a los estudiantes cada 21 días aproximadamente, de forma similar a los pases de las escuelas rurales del país, o sea de forma masiva y garantizando transporte en el mismo.
La fecha de salida puede variar, por lo que a veces no se cumple la regla de los 21 días, debido en la mayoría de los casos a necesidades del proceso docente.
Nadie autoriza este pase de manera particular, solo se aprueba en el consejo de dirección la fecha de salida, tratando de que esta coincida desde el jueves de una semana dada hasta el martes de la semana siguiente.
Tampoco se registra ningún tipo de información sobre esta salida, lo que se hace es registrar, en caso que se solicite, la cantidad de estudiantes que desean quedarse en la residencia de la Facultad Regional, en este período, para garantizar su alimentación durante el mismo.
Para este tipo de pase el estudiante no tiene que hacer solicitud previa.
2. Pase de Fin de Semana:
Este pase, es otorgado a cualquier estudiante, y para su obtención el estudiante debe pedirlo al Vice-Decano de Residencia y Extensión Universitaria o al Especialista Superior de Residencia, los cuales aparte de registrar los datos del estudiante también les entregan un bono que es el que oficializa su salida de la sede de la Facultad Regional.
Para este tipo de pase no se garantiza transporte y es válido solo desde los viernes, a la 1:00 p.m. y hasta los lunes, a las 8:00 a.m.
Solo se autoriza los viernes siempre y cuando no afecte al proceso docente del estudiante, o sea, sólo si éste no tiene clases después del 1:00 p.m.
La solicitud de este tipo de pase debe hacerse en horario diurno.
3. Pase Eventual:
Este pase es el otorgado a un estudiante cuando se le presenta algún problema de tipo personal o de salud, también se incluyen en este tipo de pase las salidas
a la ciudad de Artemisa, las cuales son por lo general salidas cuyas entradas son en el mismo día.
Debe ser solicitado en horario diurno y mediante el Profesor Guía del grupo al que pertenece el estudiante.
Lo autoriza el Especialista Superior de Residencia o al Vice-decano de Residencia y Extensión Universitaria, los cuales, además, lo registran.
Solo se garantiza transporte ante la muerte de un familiar, o cuando hace falta trasladar a un estudiante impedido por algún tipo de enfermedad y sin posibilidad de transporte.
Este pase se otorga aún cuando afecte la asistencia a clases del estudiante.
Figura 1: Flujo Actual de los Procesos
El Especialista Superior de Residencia debe emitir un reporte diario, vía email al Vice-Decano de Residencia y Extensión Universitaria y al Director de Servicios, sobre el proceso de pase, en el cual, entre otros datos, se deben reflejar la cantidad de estudiantes de pase y cuales han regresado.
1.2.2) Análisis Crítico de la Ejecución del Proceso.
Todo el proceso actual responde a una coyuntura marcada por la carencia de una aplicación automatizada, completamente adaptada y desarrollada en pro de las especificidades de la actividad enmarcada.
Entre los principales problemas que se dan durante el proceso se encuentran los siguientes:
No hay una política que defina y regule el proceso.
Especialisa Superior de Residencia Estudiante
Solicita Pase en Horario Diurno
Registro de los datos del pase
Bono de Pase
Como todo el proceso se hace de manera manual, incluso el registro de los datos del pase, se vuelve tedioso el hecho de tratar de obtener información concreta a partir de los registros en formato duro, sobre todo a la hora de elaborar el reporte diario que emite el Especialista Superior de Residencia.
Actualmente no se controla si el estudiante entró o no en la fecha señalada en los datos del pase.
No es requisito previo del pase el tener datos para una posible localización después de autorizado y entregado, por lo que se hace generalmente imposible localizar a un estudiante que salió de pase.
El proceso influye directamente en la elaboración de la comida a la hora del conteo diario de raciones para elaborar la misma, por lo que en ocasiones se generan problemas, por el hecho de que esta información no consta en formato digital, y la obtención de la misma depende del servidor de correo, pues ésta se emite vía email.
Esta situación hace necesario cuanto antes un sistema que permita agilizar todo este proceso y los documentos implicados. La decisión de informatizar este proceso y la de seleccionar la aplicación que le de solución a este problema debe estar acompañada de las siguientes consideraciones:
La aplicación debe ser sencilla, previendo su uso por usuarios que necesariamente no tienen que estar familiarizados con la tecnología usada.
Se debe mantener, lo más fiel posible, el formato de los documentos implicados en el proceso, para de esa forma estar más cerca de la realidad actual con la que se efectúa dicho proceso y no rediseñar algo a lo que ya está habituado el personal implicado.
Se necesita mantener la privacidad sobre algunas actividades por lo que cada persona debe poder acceder a los niveles estrictamente necesarios: la política de seguridad ha de ser estricta en ese aspecto.
Se necesita que la aplicación se adaptade a la infraestructura tecnológica actual, sin que ello vaya en detrimento de la calidad del producto final.
No es fácil elaborar un sistema de tales características por lo que se opta por una aplicación basada en los beneficios de un sistema de gestión cuyas particularidades se expondrán posteriormente.
1.3) Procesos Objeto de Automatización.
Tras el estudio del flujo del Proceso de Gestión del Pase Eventual en la Facultad se pretende automatizar:
El proceso de autorización de pase en caso de un pase de fin de semana, o un pase eventual.
El registro de todos los datos del pase y de la autorización de estadía en la residencia estudiantil de la facultad durante el pase ordinario, garantizando un acceso rápido y seguro a los mismos.
La posibilidad de que el estudiante, a través algún personal autorizado por el Vice- Decano de Residencia y Extensión o por el Especialista Superior de Residencia, informe sobre la llegada o entrada de pase.
En caso de cambio de los trabajadores que intervienen en el Proceso de Gestión y Control del Pase, la posibilidad de insertar los nuevos roles y eliminar los viejos si es necesario.
La eliminación de un pase o estadía en cualquier momento del proceso.
La obtención de tres tipos de reporte fundamentales:
a) Dado un periodo de tiempo (un día, una semana, un curso, un año) determinar:
I. Cantidad de estudiantes de pase (Eventual o de Fin de Semana).
II. Nombre, apellidos, grupo, año, de cada uno de los estudiantes registrados con pase en el período y en caso de que los posea los motivos y los datos de localización de cada uno de los pases.
b) Dado un Nombre (Estudiante) determinar:
I. Si está o no de pase (Eventual o de Fin de Semana).
II. Fecha de salida y fecha de entrada.
III. Grupo y año al que pertenece.
c) Reporte diario sobre estadía y otro sobre pase con los siguientes datos:
I. Cantidad de estudiantes que solicitan estadía durante el pase.
II. Nombre y apellidos, grupo y año de los estudiantes que solicitan estadía.
III. Nombre, apellidos, grupo, año, de cada uno de los estudiantes registrados con pase en el momento.
La realización y presentación de los siguientes estudios estadísticos:
a) Por ciento de estudiantes que salen de pase (Eventual o de Fin de Semana) por grupo, año o motivos.
b) Media (dado un rango de tiempo) de la cantidad de estudiantes que salen de pase por grupo, año y motivos.
c) Media (dado un rango de tiempo) de la cantidad de estudiantes que no entran en fecha señalada del pase por grupo, año y motivos.
d) Moda (dado un rango de tiempo) de los datos del pase.
1.4) Gestión de procesos.
La Gestión por Procesos es la forma de gestionar toda la organización basándose en los procesos. Entendiendo proceso como una secuencia de actividades orientadas a generar un valor añadido sobre una ENTRADA para conseguir un resultado, y una SALIDA que a su vez satisfaga los requerimientos del Cliente.
La Gestión de Procesos percibe la organización como un sistema interrelacionado de procesos que contribuyen conjuntamente a incrementar la satisfacción del cliente. Supone una visión alternativa a la tradicional caracterizada por estructuras organizativas de corte jerárquico - funcional, que pervive desde mitad del XIX, y que en buena medida dificulta la orientación de las empresas hacia el cliente.
La Gestión de Procesos coexiste con la administración funcional, asignando "propietarios" a los procesos clave, haciendo posible una gestión interfuncional generadora de valor para el cliente y que, por tanto, procura su satisfacción. Determina qué procesos necesitan ser mejorados o rediseñados, establece prioridades y provee de un contexto para iniciar y mantener planes de mejora que permitan alcanzar objetivos establecidos. Hace posible la comprensión del modo en que están configurados los procesos de negocio, de sus fortalezas y debilidades. (Aiteco Consultores, 2006)
La palabra proceso viene del latín processus, que significa avance y progreso.
Un proceso es un conjunto de actividades de trabajo interrelacionadas que se caracterizan por requerir ciertos insumos (inputs: productos o servicios obtenidos de otros proveedores) y tareas particulares que implican un valor añadido, con miras a obtener ciertos resultados.
Otra posible definición sería: gestión de todas las actividades de la empresa que generan un valor añadido; o bien, conjunto de actividades mutuamente relacionadas o que interactúan, las cuales transforman elementos de entrada en resultados. (Servicio de Calidad de la Atención Sanitaria.Sescam., 2002)
Un proceso se define como:” Conjunto de actividades que suceden de forma ordenada a partir de la combinación de información, materiales, maquinaria, gente, métodos, y medio ambiente, para convertir insumos en productos con valor agregado.” (ISO 9000:2000, 2008)
Proceso no es lo mismo que procedimiento. Un procedimiento es un conjunto de reglas e instrucciones que determinan la manera de proceder o de obrar para conseguir un resultado. Un proceso define lo que se hace, y un procedimiento, cómo hacerlo.
No todas las actividades que se realizan son procesos. Para determinar si una actividad realizada por una organización es un proceso o subproceso, debe cumplir los siguientes criterios:
La actividad tiene una misión o propósito claro.
La actividad contiene entradas y salidas, se pueden identificar los clientes, proveedores y producto final.
La actividad debe ser susceptible de descomponerse en operaciones o tareas.
La actividad puede ser estabilizada mediante la aplicación de la metodología de gestión por procesos (tiempo, recursos, costes).
Se puede asignar la responsabilidad del proceso a una persona.
Todas estas definiciones, de una forma u otra abordan las características generales de los procesos, así que seleccionar una de ellas solo dependería de una complacencia semántica de quien elige. (Servicio de Calidad de la Atención Sanitaria.Sescam., 2002)
Subprocesos: son partes bien definidas en un proceso. Su identificación puede resultar útil para aislar los problemas que pueden presentarse y posibilitar diferentes tratamientos dentro de un mismo proceso.
Luego de analizar estás definiciones se concluye que todas las actividades que se realizan para obtener el pase eventual quedan atrapadas en el concepto de proceso y aquellas que responden a las políticas de otorgamiento de pase, por ejemplo, la solicitud y la autorización, constituyen subprocesos del primero.
La principal característica de la Gestión de Procesos son los objetivos que ella se plantea:
• Incrementar la eficacia.
• Reducir costes.
• Mejorar la calidad.
• Acortar los tiempos y reducir, así, los plazos de producción y entrega del servicio.
Estos objetivos suelen ser abordados selectivamente, pero también pueden acometerse conjuntamente dada la relación existente entre ellos. Por ejemplo, si se acortan los tiempos es probable que mejore la calidad. (Aiteco Consultores, 2006)
Visto esto se concluye además que la proupesta para dar solución al problema planteado es de gestión, y para acabar con posibles falsas expectativas, basta señalar que el proceso a gestionar está definido de manera relativamente sencilla, en cuanto a complejidad funcional, por lo que su gestión, de igual forma, no está definida bajo la idea de incrementar funcionalidades para un “súper software”, sino hacia el mejoramiento actual del proceso, agregando funcionalidades según las necesidades y peticiones del cliente, y creando las condiciones para en caso de una posible implantación del software, se asegure toda la base para su instalación, rediseño o mejora de ser necesario.
1.5) Sistemas Automatizados existentes vinculados al campo de acción.
Hasta el momento no existe en la Facultad Regional, ni en la Universidad un Sistema Automatizado vinculado al Pase Eventual.
Existe un WEB-Services cuyo nombre es PASE, que no es más que el Servicio web del Sistema de Reservación del Pase y lo que hace es brindar la información referente a quiénes están de pase y en qué ruta de ómnibus salen y entran a la universidad, pero ésto es sólo para la Sede Central de la Universidad de Ciencias Informáticas.
Este servicio no brinda ninguna ayuda a la gestión y el control del Pase Eventual porque está destinado solamente al Pase Ordinario y a la planificación del transporte para el mismo, y como ya se explicó, el otorgamiento de estos dos tipos de pases, son dos procesos totalmente distintos.
En la Facultad Regional de Artemisa (FRA) una migración de este servicio existente en la UCI resolvería en parte la Gestión y el Control del pase ordinario, o del pase de fin de semana, pero nunca los dos al mismo tiempo, y dejaría fuera la gestión y control del pase eventual, por lo que se hace necesario un sistema que en la FRA se encargue de al menos éstos dos últimos pases mencionados:
el de fin de semana y el eventual, dejando a consideración la posibilidad de una posterior migración de la tecnología del servicio de PASE de la UCI, para intentar una adaptación al pase ordinario de la FRA.
Por tanto, queda en evidencia la no informatización del Proceso de Gestión y Control de Pase Eventual y se refuerza aún más la necesidad de crear una aplicación para dar solución a los inconvenientes que esto genera.
1.6) Aplicación a realizar: Las aplicaciones WEB.
Las aplicaciones Web son una especialización y concreción de las aplicaciones cliente-servidor, o sea, su arquitectura general es la de un sistema cliente/servidor, donde tanto el cliente (el navegador) como el servidor (el servidor Web), y el protocolo mediante el que se comunican (el HTTP:
HyperText Transfer Protocol) son estándar, y no han de ser creados por el desarrollador. (Arsys, 2007)
La parte del cliente de las aplicaciones Web está formada por el código HTML (Hyper Text Markup Language) que forma la página Web, con opción a código ejecutable mediante los lenguajes script de los navegadores (JavaScript, VBScript, PerlScript) o mediante pequeños programas. La parte de servidor está formada por un programa o script que es ejecutado por el servidor Web, y cuya salida se envía al navegador del cliente. (Arsys, 2007)
La creciente popularidad de las aplicaciones Web se debe a sus múltiples ventajas, entre las cuales se pueden citar: (Y., y otros, 2005)
Multiplataforma: Con un solo programa, un único ejecutable, las aplicaciones pueden ser utilizada a través de múltiples plataformas, tanto de hardware como de software.
Actualización instantánea: Debido que todos los usuarios de la aplicación hacen uso de un sólo programa que radica en el servidor, los usuarios siempre utilizarán la versión más actualizada del sistema.
Suave curva de aprendizaje: Los usuarios, como utilizan la aplicación a través de un navegador, hacen uso del sistema tal como si estuvieran navegando por Internet, por lo cual su acceso es más intuitivo.
Fácil de integrar con otros sistemas: Debido a que se basa en protocolos estándares, la información manejada por el sistema puede ser accedida con mayor facilidad por otros sistemas.
Acceso móvil: El usuario puede acceder a la aplicación con la única restricción de que cuente con un acceso a la red privada de la organización o a Internet, dependiendo de las políticas de dicha organización; puede hacerlo desde una computadora de escritorio, una laptop o desde una agenda electrónica; desde su oficina, hogar u otra parte del mundo.
No obstante a la serie de ventajas que presenta tiene además algunas desventajas, las cuales son (Morgado Guirola, 2006):
Acceso limitado, la necesidad de conexión permanente y rápida a Internet hacen que el acceso a estas aplicaciones no esté al alcance de todos.
La interactividad no se produce en tiempo real, en las aplicaciones Web cada acción del usuario conlleva un tiempo de espera algunas veces excesivo hasta que se obtiene la reacción del sistema.
Elementos de interacción muy limitados. En comparación con el software de escritorio, las posibilidades de interacción con el usuario que ofrecen las aplicaciones Web (mediante formularios principalmente) son muy escasas.
Diferencias de presentación entre plataformas y navegadores. La falta de estándares ampliamente soportados dificulta el desarrollo de las aplicaciones.
El Acceso Limitado no influye como desventaja pues en la Facultad Regional de Artemisa existe una red que abarca toda la infraestructura docente, productiva y de beca de la Universidad. La velocidad de la red en el interior de la Universidad es de 100 Mbps, lo cual hace que el tiempo real de la interactividad no constituya un problema grave. En cuanto a las limitaciones de elementos de
interacción, y las diferencias de presentación entre plataformas, esas son desventajas que se pueden minimizar en el proceso de implementación.
Se decide pues, a pesar de las desventajas descritas, que la aplicación a implementar para dar solución a la problemática planteada ha de ser una aplicación WEB pues en la Facultad Regional de Artemisa, existe todo el soporte tecnológico necesario para llevar a cabo tal empresa.
1.6.1) Modelo Cliente - Servidor.
Se dice que la arquitectura Cliente/Servidor es la integración distribuida de un sistema en red, con los recursos, medios y aplicaciones que, definidos modularmente en los servidores, administran, ejecutan y atienden las solicitudes de los clientes; todos interrelacionados física y lógicamente, compartiendo datos, procesos e información. Se establece así un enlace de comunicación transparente entre los elementos que conforman la estructura (Morgado Guirola, 2006).
Entre las principales características de la arquitectura Cliente/Servidor, se pueden destacar las siguientes (Méndez, y otros, 2005)
El servidor presenta a todos sus clientes una interfaz única y bien definida.
El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa.
El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo.
Los cambios en el servidor implican pocos o ningún cambio en el cliente.
Ventajas de la arquitectura cliente-servidor: (Y., y otros, 2005)
El servidor no necesita potencia de procesamiento, parte del proceso se reparte con los clientes.
Se reduce el tráfico de red considerablemente. Idealmente, el cliente se conecta al servidor cuando es estrictamente necesario, obtiene los datos que necesita y cierra la conexión dejando la red libre.
Los tres componentes son: (Y., y otros, 2005)
Interfaz de usuario al sistema. Tales como una sesión, entradas de texto, desplegado de menús, etc.
Administración de procesamiento. Tales como la ejecución de procesos, el monitoreado de los mismos y servicios de procesamiento de recursos.
Administración de bases de datos. Tales como los servicios de acceso a datos y archivos.
La arquitectura de software de tres capas emergió en la década de los noventas para solventar las limitaciones de la arquitectura de dos capas. La tercera capa (capa de servicios) se localiza entre la interfaz de usuarios (cliente) y el administrador de datos (servidor). Esta capa intermedia provee de servicios para la administración de procesos (tal como desarrollo, monitoreo y alimentación de procesos) que son compartidos por múltiples aplicaciones. (Y., y otros, 2005).
Figura 2: Modelo Cliente-Servidor en tres capas
El servidor de la capa intermedia (también conocido como servidor de aplicaciones) centraliza la lógica de las aplicaciones, haciendo que la administración de cambios sea más sencilla. En arquitecturas más simples, cualquier cambio en la lógica, implica reescribir todas las aplicaciones que dependan de ésta. (Y., y otros, 2005)
Luego de analizar este modelo, se define que lo ideal, a pesar de la relativa sencillez de nuestro problema, es usar un modelo de tres capas, haciendo más sencilla y a la vez robusta nuestra posible solución.
1.7) Tendencias sobre el desarrollo de Aplicaciones WEB.
No existe hoy en día una solución global para desarrollos de aplicaciones Web que dé respuesta a todas las necesidades de una empresa o institución. Por ello, las infraestructuras diseñadas para Internet se componen de múltiples soluciones de desarrollo para aplicaciones Web.
(Empresas HispaVista, 2007)
Las claves para el éxito de un proyecto de desarrollo de software son:
Independencia tecnológica: La utilización de tecnologías estándares y herramientas libres garantiza la independencia de plataformas y asegura la posibilidad de mantenimiento futuro de las aplicaciones.
Metodologías de desarrollo ágiles: Las metodologías de desarrollo basadas en una fuerte interacción con el cliente y usuarios, permiten obtener productos adecuados a las necesidades reales, ahorrando esfuerzo y aumentando la satisfacción del usuario final.
Uso de la tecnología adecuada: No existe un paradigma de diseño ni un lenguaje de programación que se ajuste a todas las necesidades, por lo cual debe escogerse en cada caso la tecnología que mejor satisfaga los requerimientos. Para esto, obviamente, es necesario un conocimiento amplio de las ciencias de la computación.
Utilización de código libre: Cuando es posible, la utilización de programas libres existentes (su modificación, integración o corrección), permite obtener productos de excelente calidad, en menor tiempo y, por consiguiente, con menores costos.
Utilización de licencias libres: El producto terminado debe ser entregado al cliente con toda la documentación y el código fuente. De esta manera no se impone ninguna traba a la futura extensión del mismo, asegurando un trato justo, claro y transparente.
Evidentemente se hace necesario, aparte de las claves ya mencionadas, el uso de herramientas que permitan el buen desenvolvimiento de las mismas. En la actualidad existe un criterio cada vez más generalizado - principalmente en aquello países con menos posibilidades de adquisición -, de que se debe ampliar el uso de las herramientas desarrolladas para el trabajo en una Plataforma de Software Libre.
El software libre suele estar disponible gratuitamente, o a precio del costo de la distribución de éste, sin embargo no es obligatorio que sea así y, aunque conserve su carácter de libre, puede ser vendido comercialmente.
Ahora se muestra una lista de las principales tendencias en cuanto a herramientas de desarrollo de aplicaciones orientadas a la WEB.
Manejadores de bases de datos:
MySQL: surge como un manejador de pequeñas bases de dato, rápido y ágil. Con el paso del tiempo y la reciente incorporación del código de la reconocida base de datos SapDB, se ha sumado al mercado de las bases de datos profesionales. Una de sus principales ventajas es que es soportada por la mayoría de los proveedores de alojamiento Web (web hosting), por lo cual se encuentra instalada en casi todos los servidores Web de Internet.
PostgreSQL: es uno de los "decanos" de las bases de datos. Su desarrollo se inició en 1986 y desde entonces ha incorporado características avanzadas, inclusive antes que costosos manejadores privativos líderes del mercado. Entre sus casos de éxito se encuentran bases de datos de tamaños superiores a los 50Gb, lo cual demuestra su confiabilidad y eficiencia.
Lenguajes y herramientas de desarrollo:
Ruby on Rails: es un framework para el desarrollo de aplicaciones Web basado en el lenguaje Ruby, que reduce notablemente el tiempo de desarrollo, permitiendo lograr aplicaciones robustas y de fácil mantenimiento y extensión.
PHP: es el lenguaje más utilizado en su actualidad para el desarrollo de aplicaciones Web.
Entre sus principales ventajas, se encuentran el soporte por parte de casi todos los proveedores de alojamiento Web y la gran cantidad de código desarrollado.
Perl: es un potente lenguaje de scripting, apto no solo para el desarrollo de aplicaciones Web, sino también para herramientas de administración de sistemas, herramientas de conversión de formatos, software de acceso a redes, etc.
Java: es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria. Las
aplicaciones Java están típicamente compiladas en un bytecode, aunque la compilación en código máquina nativo también es posible. En el tiempo de ejecución, el bytecode es normalmente interpretado o compilado a código nativo para la ejecución, aunque la ejecución directa por hardware del bytecode por un procesador Java también es posible.
La mayoría de las aplicaciones de pequeña, mediana y gran envergadura aparte de usar, casi siempre las herramientas ya descritas, también se adaptan a estándares internacionales a la hora de diseñar e implementar sus propios productos, para de esta forma garantizar de antemano una buena calidad en estos. Entre los estándares más reconocidos y usados en la actualidad se pueden citar:
ISO 9241 (1998): Guías sobre usabilidad.
ISO/IEC FDIS 9126-1 (2000): Ingeniería de Software, Calidad de Producto.
ISO 13407 (1999): Procesos de diseño centrado en las personas para sistemas interactivos.
1.7.1)
Gestor de Base de datos: MySQL.MySQL es un gestor de base de datos sencillo de usar e increíblemente rápido. También es uno de los motores de base de datos más usados en Internet, la principal razón de esto es que es gratis para aplicaciones no comerciales. (MySQL-Hispano.org, 2005)
1.7.1.1) Principales características de MySQL.
Las características principales de MySQL son (MySQL-Hispano.org, 2005):
Es un gestor de base de datos. Una base de datos es un conjunto de datos y un gestor de base de datos es una aplicación capaz de manejar este conjunto de datos de manera eficiente y cómoda.
Es una base de datos relacional. Una base de datos relacional es un conjunto de datos que están almacenados en tablas entre las cuales se establecen unas relaciones para manejar los datos de una forma eficiente y segura. Para usar y gestionar una base de datos relacional se usa el lenguaje estándar de programación SQL.
Es Open Source. El código fuente de MySQL se puede descargar y está accesible a cualquiera, por otra parte, usa la licencia GPL para aplicaciones no comerciales.
Es una base de datos muy rápida, segura y fácil de usar. Gracias a la colaboración de muchos usuarios, la base de datos se ha ido mejorando optimizándose en velocidad.
Por eso es una de las bases de datos más usadas en Internet.
Existe una gran cantidad de software que la usa.
Son precisamente su rapidez, su compatibilidad con una infinidad de herramientas de software libre, y el hecho de que él mismo, como gestor de bases de datos, es una herramienta de open source (código abierto), además de que consume muy pocos recursos de CPU durante su ejecución, las características que se tomaron en cuenta para decidir que la aplicación a implementar usará como gestor de bases de datos a MySQL.
1.7.2) PHP: "PHP Hypertext Pre-processor".
PHP es un lenguaje de programación usado normalmente para la creación de contenido para sitios Web con los cuales se puede programar las páginas HTML y los códigos de fuente. PHP es un acrónimo recursivo que significa "PHP Hypertext Pre-processor", y se trata de un lenguaje interpretado usado para la creación de aplicaciones para servidores, o creación de contenido dinámico para sitios Web. Últimamente también para la creación de otro tipo de programas incluyendo aplicaciones con interfaz gráfica usando las librerías Qt o GTK+.
Los principales usos del PHP son los siguientes:
Programación de páginas Web dinámicas, habitualmente en combinación con el motor de base datos MySQL, aunque cuenta con soporte nativo para otros motores, incluyendo el estándar ODBC, lo que amplía en gran medida sus posibilidades de conexión.
Programación en consola, al estilo de Perl o Shell scripting.
Creación de aplicaciones gráficas independientes del navegador, por medio de la combinación de PHP y Qt o GTK+, lo que permite desarrollar aplicaciones de escritorio en los sistemas operativos en los que está soportado.
Entre sus principales ventajas se encuentran:
Es un lenguaje multiplataforma.
Capacidad de conexión con la mayoría de los manejadores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL
Leer y manipular datos desde diversas fuentes, incluyendo datos que pueden ingresar los usuarios desde formularios HTML.
Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).
Posee una amplia documentación en su página oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.
Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.
Permite las técnicas de Programación Orientada a Objetos.
Permite crear los formularios para la Web.
Biblioteca nativa de funciones sumamente amplia e incluida
No requiere definición de tipos de variables ni manejo detallado del bajo nivel.
Puede que PHP se quede atrás en cuanto a robustez si lo comparamos con Java, pero es indudable que constituye una alternativa mucho más cómoda para desarrolladores con poca experiencia en la programación de aplicaciones WEB debido a la sencillez de la implementación de su código.
Todo lo analizado hace que se tome la decisión de que nuestra propuesta de solución sea implementada con lenguaje PHP.
1.7.5)
Servidor Web
Un servidor Web es un programa que implementa el protocolo HTTP (hyper text transfer protocol). Este protocolo está diseñado para transferir lo que se llama hipertextos, páginas web o páginas HTML (hyper text markup language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música.
Sobre el servicio Web clásico se puede disponer de aplicaciones Web. Éstas son fragmentos de código que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:
Aplicaciones en el lado del cliente: el cliente Web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo java o javascript: el servidor proporciona el código de las aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts). Normalmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden añadirse más lenguajes mediante el uso de plugins.
Aplicaciones en el lado del servidor: el servidor Web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor toma este código recién creado y lo envía al cliente por medio del protocolo HTTP.
Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayoría de las ocasiones para realizar aplicaciones Web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad adicional, como sí ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador Web básico puede utilizar este tipo de aplicaciones.
1.7.5.1) Apache Web-Server
Hoy en día Apache es el servidor Web más utilizado del mundo, encontrándose muy por encima de sus competidores, tanto gratuitos como comerciales. Es un software de código abierto que funciona sobre cualquier plataforma. Desde su origen ha evolucionado hasta convertirse en uno de los mejores servidores en términos de eficiencia, funcionalidad y velocidad, surgió en abril de 1996 y ya en julio del 2002 era utilizado por el 57% de los sitios Web de Internet. (Parra, y otros, 2005)
Tiene capacidad para servir páginas tanto de contenido estático, para lo que nos serviría sencillamente un viejo ordenador 486, como de contenido dinámico a través de otras herramientas soportadas que facilitan la actualización de los contenidos mediante bases de datos, ficheros u otras fuentes de información, es muy potente y altamente configurable. (Parra, y otros, 2005)
El servidor Apache es un software que está estructurado en módulos, es decir, está dividido en muchas porciones de código que hacen referencia a diferentes aspectos o funcionalidades del servidor
Web. Esta modularidad es intencionada ya que la configuración de cada módulo se hace mediante la configuración de las directivas que están contenidas dentro del módulo. Los módulos del Apache se pueden clasificar en tres categorías: (Parra, y otros, 2005)
Módulos Base: Módulo con las funciones básicas del Apache.
Módulos Multiproceso: Son los responsables de la unión con los puertos de la máquina, aceptando las peticiones y enviando a los hijos a atender a las peticiones.
Módulos Adicionales: Cualquier otro módulo que le añada una funcionalidad al servidor.
Las funcionalidades más elementales se encuentran en el módulo base, siendo necesario un módulo multiproceso para manejar las peticiones. Se han diseñado varios módulos multiprocesos para cada uno de los sistemas operativos sobre los que se ejecuta el Apache, optimizando el rendimiento y rapidez del código. (Parra, y otros, 2005)
El resto de las funcionalidades del servidor se consigue por medio de módulos adicionales que se pueden cargar. Para añadir un conjunto de utilidades al servidor, simplemente hay que añadirle un módulo, de forma que no es necesario volver a instalar el software. (Parra, y otros, 2005)
Todo lo ya expuesto hace de Apache el Web-Server ideal para una aplicación WEB, pero lo verdaderamente relevante para usarlo como servidor WEB, en la automatización del Proceso de Gestión y Control de pase Eventual, es su compaginación con la tecnología de software libre que se quiere seguir en este trabajo.
1.8) Fundamentación de la Metodología a usar .
El objetivo de un proceso de desarrollo es garantizar la calidad de un producto de software a través de una mayor transparencia y control sobre dicho proceso.
Es muy común en la actualidad obviar este factor y no analizar cuál es la metodología correcta para aplicar en la producción de un software, paradójicamente el éxito de un producto de software coincide con el uso de una buena metodología, que permita generar y garantizar todos los requisitos de dicho producto.
1.8.1) Metodología XP.
Extreme Programming (XP), es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.
(Mendoza Sanchez, 2004)
La metodología se basa en:
Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.
Refabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más flexible al cambio.
Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.
Lo fundamental en este tipo de metodología es:
La comunicación, entre los usuarios y los desarrolladores
La simplicidad, al desarrollar y codificar los módulos del sistema
La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales.
1.8.2) Metodología MSF.
Microsoft Solution Framework (MSF), es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas. (Mendoza Sanchez, 2004)
MSF tiene las siguientes características:
Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.
Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño de Proceso y finalmente el modelo de Aplicación. (Mendoza Sanchez, 2004)
1. Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de vida.
Este modelo define las pautas para construir proyectos empresariales a través del lanzamiento de versiones.
2. Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto.
Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles.
3. Modelo de Proceso: Diseñado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberación de versiones y explicando su relación con el Modelo de equipo.
4. Modelo de Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar.
5. Modelo de Diseño del Proceso: Diseñado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eficiente y flexible a través de un enfoque iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores.
6. Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores. (Mendoza Sanchez, 2004)
1.8.3) Metodología RUP.
El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
El Rational Unified Process (RUP) es un proceso de software de ingeniería habilitado para Internet que enriquece la productividad en equipo y proporciona prácticas óptimas de software a todos los miembros del equipo.
RUP divide el proceso de desarrollo en ciclos, donde se obtiene un producto al final de cada ciclo. Cada ciclo se divide en cuatro fases: concepción, elaboración, construcción y transición. Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones. (Camacho Pupo, 2006)(Ver Figura 3).
Concepción: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos
Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos
Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario
Transición: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.
Figura 3: Fases de RUP
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas (Ver Figura 4: RUP en dos dimensiones.):
Disciplina de Desarrollo:
o Ingeniería de Negocios: Entendiendo las necesidades del negocio.
o Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
o Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.
o Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.
o Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado está presente.
Disciplina de Soporte:
o Configuración y administración del cambio: Guardando todas las versiones del proyecto.
o Administrando el proyecto: Administrando horarios y recursos.
o Ambiente: Administrando el ambiente de desarrollo.
o Distribución: Hacer todo lo necesario para la salida del proyecto.
Figura 4: RUP en dos dimensiones.
Las características principales que lo distinguen son: (González, 2004)
Proceso Dirigido Por Casos de USO:
o Capturar, definir y validar casos de uso.
o Realizar casos de uso.
o Verificar que se satisfacen casos de uso.
Proceso Iterativo e Incremental:
o El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes.
o En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala.
o Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones.
o Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración.
Proceso Centrado en la Arquitectura:
o Arquitectura de un sistema es la organización o estructura de sus partes más relevantes. Una arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades.
o RUP establece refinamientos sucesivos de una arquitectura ejecutable.
Se define entonces, a pesar de que existan otras metodologías más acordes para la implementación de “microsistemas” -como el que constituye la posible solución del problema definido-, por ejemplo la metodología XP, así como también asumiendo todos los posibles problemas que puedan surgir durante la etapa de análisis y diseño de la aplicación, que la metodología a usar será RUP, debido a tres causas fundamentales:
1. El hecho de que RUP se basa en el modelado a través de casos de uso, hace que desde el modelado del negocio se garantice de manera eficaz la robustez del diseño de nuestra aplicación, contando además con el hecho de que RUP, a criterio de muchos especialistas es la metodología ideal para aplicaciones orientadas a la gestión.
2. Su capacidad iterativa, hace que se garantice la calidad del producto de manera más eficiente que cualquier otra metodología.
3. Por ser un proceso centrado en la Arquitectura, permite que el trabajo de implementación sea más fluido y acertado.
1.8.4) Lenguaje Unificado de Modelado UML.
UML son las siglas de Unified Modeling Languaje (Lenguaje Unificado de Construcción de Modelos), notación (esquemática en su mayor parte) con que se construyen sistemas por medios de conceptos orientados a objetos. (Larman, 1999)
El UML se define como un "lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software". Es un sistema basado en la notación -que entre otras cosas, incluye el significado de sus notaciones-, destinado a los sistemas de modelado que utilizan conceptos orientados a objetos.
Con él sus protagonistas se propusieron que:
El método debía ser capaz de modelar no solo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).
Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
Manejar los problemas típicos de los sistemas.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. (Ver Figura 5: Jerarquía de los diagramas UML 2.0, mostrados como un diagrama de clases.)
Figura 5: Jerarquía de los diagramas UML 2.0, mostrados como un diagrama de clases.
El UML brinda el lenguaje de aplicación de modelado para: (Camacho Pupo, 2006) Modelado de proceso de negocios con casos de uso.
Modelado de clases y objetos Modelado de componentes.
Modelado de distribución y despliegues.
Es el lenguaje estandarizado en la industria para especificar, visualizar, construir y documentar los dispositivos de sistemas de software. Simplifica el complejo proceso de diseño de software, haciendo planos para su construcción. (IT Era S.A. de C.V., 2000)
El UML está compuesto por tres partes: bloques de construcción (tales como clases, objetos, mensajes), relaciones entre los bloques (tales como asociación, generalización) y diagramas (por ejemplo, diagrama de actividad). Los perfiles de UML son las extensiones a las notaciones estándares del UML usando los mecanismos de extensión de UML: los estereotipos, los valores etiquetados y las restricciones. Presenta nueve diagramas estándares: diagrama de casos de uso, de clases, de secuencia, de colaboración, de actividad, de estados, de implementación (componentes), de despliegue, si fuera necesario, el diagrama de objetos se puede crear usando los diagramas de colaboración. Las diferencias existen solamente con relación al soporte de una característica específica durante la creación de los diagramas UML y los perfiles extendidos del UML.
UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas. UML es un método independiente del proceso. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas. (Instituto Novatech, 2001)
1.9) Frameworks.
Un Framework es Conjunto de APIs y herramientas destinadas a la construcción de un determinado tipo de aplicaciones de manera generalista. (González, 2004)
Una API (Application Programming Interface) es una especificación de una librería o utilidad que documenta su interfaz y permite su uso sin conocimiento de su interior. (González, 2004)
El Framework se describe de manera mucho más general como una estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, un framework puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa
