Documentos de Académico
Documentos de Profesional
Documentos de Cultura
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
___________________________
PRESIDENTE DEL JURADO
___________________________
Jurado
___________________________
Jurado
DEDICATORIA
CONTENIDO
INTRODUCCION
1 FASE DE INICIO..............................Error: Reference source not found
1.1 Antecedentes…………………………………………………….
1.2 Formulación del problema.........Error: Reference source not found
1.3 Plantamiento del problema........Error: Reference source not found
20 FASE DE IMPLEMENTACIÓN.
20.3 Factibilidad o Viabilidad.
20.3.1 Factibilidad Técnica.
20.3.2 Factibilidad Humana.
20.3.3 Factibilidad Financiera.
20.3.4 Factibilidad Legal.
20.4 Costos.
20.4.1 Costo del Proyecto.
20.4.2 Valor del Proyecto.
20.4.3 Matriz DOFA.
20.5 Requerimientos.
20.5.1 Hardware.
20.5.2 Software.
LISTA DE TABLAS
Pág.
Pág.
Pág.
1.1 ANTECEDENTES
Este proyecto es realizado con el fin de dar una solución a los problemas que
se tiene en el área de bienestar universitario hacia los estudiantes, es
proyectar y fortalecer el apoyo en el desarrollo de la institución en los ámbitos
sociales y culturales llevándoles a dar un buen conocimiento sobre ello,
ofreciéndole a demás becas universitarias, para así apoyar los procesos
académicos y psicológicos. Fortaleciendo sus actitudes y competencias
profesionales, y poderlos orientar en el transcurso de su estudio universitario.
Para tener como resultado el sentido de pertenencia en los estudiantes y la
satisfacción con los servicios que presta, desarrollar una herramienta que les
ayude a los coordinadores a realizar un seguimiento a los estudiantes por
medio de aplicativos.
1.5.1 ALCANCES:
Con la ejecución de este proyecto se beneficiará al área de bienestar y pastoral
de la CORPORACIÓN UNIVERSITARIA MINUTO DE DIOS sede soacha ya
que se brindara una herramienta donde el coordinador pueda almacenar toda
la información pertinente a los seguimientos de los estudiantes de primer año.
Además se pretende que por medio del aplicativo Web se enteren los
estudiantes de todos los beneficios y actividades que se realizan en la
universidad por parte del área de bienestar
1.5.2. DELIMITACIÓN:
1
El presente trabajo indaga sobre las diferentes actividades que se realizan en
el área de bienestar y pastoral universitario En varias oportunidades hemos
alcanzado a evidenciar la ausencia de una herramienta necesaria para el
apropiado manejo de la gestión administrativa de algunos de los procesos que
se llevan a cabo en el interior del área de bienestar universitario. Al no contar
con un aplicativo que organice y salvaguarde la información se han presentado
inconvenientes de consultas de datos que no tienen descripciones y que en
algunos casos no existen por pérdida o desactualización.
BIENESTAR UNIVERSITARIO
1
Proyectos de grado mi tecnologico
2
Bienestar universitario, universidad la gran Colombia
1.7.2 MARCO HISTORICO
Cuenta con un
espacio donde
muestran las
actividades y eventos
que van a desarrollar
durante el
semestre.Ademas
con un espacio de
convocatorias con
diferentes opciones y
enfoques.
El marco conceptual nos ayuda a explicar por qué estamos llevando a cabo un
proyecto de una manera determinada. También nos ayuda a comprender y a
utilizar las ideas de otras personas que han hecho trabajos similares.
Aplicación Web:
MySQL :
Es un sistema de gestión de base de datos relacional, multihilo y multiusuario
con más de seis millones de instalaciones. MySQL AB desde enero de 2008
una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporación
desde abril de 2009 desarrolla MySQL como software libre en un esquema de
licenciamiento dual. Por un lado se ofrece bajo la GNU GPL para cualquier uso
compatible con esta licencia, pero para aquellas empresas que quieran
incorporarlo en productos privativos deben comprar a la empresa una licencia
específica que les permita este uso. Está desarrollado en su mayor parte en
ANSI C. Al contrario de proyectos como Apache, donde el software es
desarrollado por una comunidad pública y el copyright del código está en poder
del autor individual, MySQL es propietario y está patrocinado por una empresa
privada, que posee el copyright de la mayor parte del código. Esto es lo que
posibilita el esquema de licenciamiento anteriormente mencionado. Además de
la venta de licencias privativas, la compañía ofrece soporte y servicios. Para
sus operaciones contratan trabajadores alrededor del mundo que colaboran vía
Internet. MySQL AB fue fundado por David Axmark, Allan Larsson y Michael
Widenius.
Inasistencias
1.7.5. MARCO LEGAL
NORMATIVIDAD UTILIZADA
Estudio de campo
4
Ministerio De Educación Nacional
La noción de estudio de campo es una de las nociones más importantes de
cualquier tipo de ciencia ya que es el momento en el que la teoría es puesta a
prueba para establecer si los elementos que la caracterizan son correctos o no.
El estudio de campo fue fundamental para determinar los requerimientos
utilizables en la Área de Bienestar Y pastoral de la CUMD. A partir de las
entrevistas efectuadas a las coordinadoras, se usó el método de observación
directa para conocer más profundamente el proceso de acompañamiento
psicopedagógico y de inducción.
Visita al terreno
Fecha:___________________
1 2 3 4 5 6
¿Cómo le parece la Corporación Universitaria Uniminuto en el
área de bienestar?
¿Porque?
______________________________________________________________________________
Porque
Porque
¿PORQUE?
SI NO
10- ¿Sabía usted que en bienestar estudiantil cuenta con valoración psicológica gratis?
SI NO
10- ¿Conoce las oportunidades de trabajo que ofrece el área de egresados de la
Universidad?
SI NO
Porque _____________________________________________________
Deporte Y Cultura
Futbol
Baloncesto
Voleibol
Te kondo
Otros
Cual___________________________________-
SI NO
13.- ¿Ah participado en algún campeonato de la Universidad?
SI NO
Cual_______________________________________________
14- ¿Sabe cuáles son los talleres culturales que ofrece la Universidad?
SI NO
15 ¿Tiene usted algún tipo de habilidad artística o manual?
SI NO
SI NO
Cual_______________________________________________
Comentarios sobre el producto
17.- ¿Sabía que la Corporación Universitaria Minuto De Dios Sede Soacha no tiene página
de bienestar estudiantil?
SI NO
Muchas gracias por su amabilidad y por el tiempo dedicado a contestar esta encuesta
Entrevista
Área De Bienestar
Nombre:________________________________________________________
Modelos de datos
Modelo e-r
Modelo relacional
Modelo tabular
¿??CICLO DE VIDA DEL SOFTWARE
Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de
vida del software, de forma tal que el inicio de cada etapa debe esperar a la
finalización de la inmediatamente anterior. la palabra cascada sugiere,
mediante la metafora de la fuerza de la gravedad, el esfuerzo necesario para
introducir un cambio en las fases más avanzadas de un proyecto.
Modelo en Cascada: El más conocido, está basado en el ciclo convencional de
una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:
1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA: Debido a que el software es
siempre parte de un sistema mayor, el trabajo comienza estableciendo los
requisitos de todos los elementos del sistema y luego asignando algún
subconjunto de estos requisitos al software.
2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN: Se lleva a cabo teniendo
en cuenta ciertos principios:
- Debe presentarse y entenderse el dominio de la información de un problema.
- Defina las funciones que debe realizar el Software.
Represente el comportamiento del Software a consecuencias de
acontecimientos externos y divida en forma jerárquica los modelos que
representan la información, funciones y comportamiento. Se analizan las
necesidades de los usuarios finales del Software para determinar qué objetivos
debe cubrir.
3.- DISEÑO. Traduce los requisitos en una representación del Software con la
calidad requerida antes de que comience la codificación.
Diseño del sistema: Se descompone y organiza el sistema en elementos que
pueda elaborarse por separado, aprovechando los ventajas del desarrollo en
equipo, así como la manera en que se combinan unos con otros.
Diseño del Programa: Es la fase en donde se realizan los algoritmos
necesarios para el cumplimiento de los requerimientos del usuario así como
también los análisis necesarios para saber que herramientas usar en la etapa
de Codificación.
4.- CODIFICACIÓN: El diseño debe traducirse en una forma legible para la
máquina. Se implementa el código fuente. Dependiendo del lenguaje de
programación y su versión se crean las librerías y componentes reutilizables
dentro del mismo proyecto para hacer que la programación sea un proceso
mucha más rápido.
5.- PRUEBA: Los elementos, ya programados, se ensamblan para componer el
sistema y se comprueba que funciona correctamente antes de ser puesto en
explotación. Las pruebas de Software, testing o beta testing es un proceso
usado para identificar posibles fallos. En general, los usuarios distinguen entre
errores de programación bugs y defectos de forma. En un defecto de forma, el
programa no realiza lo que el usuario espera. Por el contrario, un error de
programación puede describirse como un fallo en la semántica de un programa
de ordenador. A la versión del producto de pruebas y que es anterior a la
versión final ( o “master” ) se denomina beta, y a dicha fase de pruebas, beta
testing. Finalmente y antes de salir al mercado, es cada vez más habitual que
se realice una fase de RTM testing (Release To Market ), dónde se comprueba
cada funcionalidad del programa completo en entornos de producción.
6.- IMPLANTACIÓN: El Software obtenido se pone en producción. Se
implantan los niveles Software y Hardware que componen el proyecto. La
implantación es la fase con más duración y con más cambios en el ciclo de
elaboración de un proyecto. Es una de las fases finales del proyecto. Durante la
explotación del sistema Software pueden surgir cambios, bien para corregir
errores o bien para introducir mejorar. Todo ello recoge en los Documentos de
Cambios.
7.- MANTENIMIENTO: El Software sufrirá cambios después de que se entrega
al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que
el Software deba adaptarse a cambios del entorno externo (sistema operativo o
dispositivos periféricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento.
Modelo espiral
El modelo en espiral del proceso del software que originalmente fue propuesto
por Boehm (1988), El modelo en espiral es una delas metodologías más
recomendables para el desarrollo y creación de un programa, ya que consta de
pocas etapas o fases, las cuales se van realizando en una manera continua y
cíclica.
Determinar los objetivos: En esta fase del proyecto se definen los objetivos
específicos. Se identifican las restricciones del proceso y del sistema software,
y se traza un plan detallado de gestión. Se identifican los riesgos.
Dependiendo de estos riesgos se planean estrategias alternativas.
Análisis del riesgo: Se lleva a cabo un análisis detallado para cada uno de los
riesgos del proyecto identificados. Se definen los pasos a seguir para reducir
los riesgos.
Desarrollar y validar: Después de la evaluación de riesgos, se elige un modelo
para el desarrollo del sistema software y se desarrolla.
Planificación: El proyecto se revisa y se toma la decisión si se debe continuar
con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los
planes para la siguiente fase del proyecto.
TIPOS DE MODELOS
Describe la estructura estática (de datos), de los objetos del sistema (identidad,
atributos y operaciones) y también sus relaciones. El modelo de objetos
contiene diagramas de objetos. Un diagrama de objetos es un grafo cuyos
nodos son clases de objetos y cuyos arcos son relaciones entre las clases. El
diagrama contiene clases de objetos organizados en jerarquías que comparten
una estructura y comportamiento comunes y que están asociadas a otras
clases. Estas clases definen los atributos que lleva cada instancia de objeto y
las operaciones que efectúa o sufre cada uno. En cada instancia de la clase se
guardan los valores de esos atributos.
Modelo Dinámico
Describe los aspectos de comportamiento (de control) de un sistema que
cambian con el tiempo. El modelo dinámico se utiliza para especificar e
implementar los aspectos del control del sistema. Los modelos dinámicos
contienen diagramas de estados. Un diagrama de estados es un grafo cuyos
nodos son estados y cuyos arcos son transiciones entre estados causadas por
sucesos o eventos. Se especifican en este modelo la temporización y
secuencia de operaciones (sucesos que marcan los cambios, secuencias de
sucesos, estados que definen el contexto para los sucesos), y la organización
de sucesos y de estados. El modelo dinámico captura el control, aquel aspecto
de un sistema que describe las secuencias de operaciones que se producen
sin tener en cuanta lo que hagan las operaciones, aquello a lo que afecten o la
forma en la que estén implementadas. Las acciones de los diagramas de
estado se corresponden con funciones procedentes del modelo funcional; los
sucesos de un diagrama de estado pasan a ser operaciones que se aplican a
objetos dentro del modelo de objetos.
Diseño Estructurado.
METODOLOGÍA UML
CASOS DE USO
Es una descripción de los pasos o las actividades que deberán realizarse para
llevar a cabo algún proceso. Los personajes o entidades que participarán en un
caso de uso se denominan actores. En el contexto de ingeniería del software,
un caso de uso es una secuencia de interacciones que se desarrollarán entre
un sistema y sus actores en respuesta a un evento que inicia un actor principal
sobre el propio sistema. Los diagramas de casos de uso sirven para especificar
la comunicación y el comportamiento de un sistema mediante su interacción
con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que
muestra la relación entre los actores y los casos de uso en un sistema. Una
relación es una conexión entre los elementos del modelo, por ejemplo la
especialización y la generalización son relaciones. Los diagramas de casos de
uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo
reacciona a eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con
el desarrollo del paradigma de la programación orientada a objetos, donde se
originaron, si bien puede utilizarse con resultados igualmente satisfactorios con
otros paradigmas de programación.
Actores
Se le llama actor a toda entidad externa al sistema que guarda una relación con
éste y que le demanda una funcionalidad. Esto incluye a los operadores
humanos pero también incluye a todos los sistemas externos, además de
entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como
definiciones de rol por lo que un mismo individuo puede corresponder a uno o
más Actores. Suele suceder sin embargo, que es el sistema quien va a tener
interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben
efectuar operaciones automáticas en determinados momentos; y siendo esto
un requisito funcional obvio, resulta de interés desarrollar alguna forma de
capturar dicho requisito en el modelo de caso de uso final.
Tipos de relaciones
extiende (<< extends>>): Relación de dependencia entre dos casos de uso que
denota que un caso de uso es una especialización de otro. Por ejemplo, podría
tenerse un caso de uso que extienda la forma de pedir azúcar, para que
permita escoger el tipo de azúcar (normal, dietético o moreno) y además la
cantidad en las unidades adecuadas (cucharadas o bolsas). Se utiliza una
relación de tipo <<extends>> entre casos de uso cuando nos encontramos con
un caso de uso similar a otro pero que hace algo más que éste (variante). Por
contra, utilizaremos una relación tipo << uses>> cuando nos encontramos con
una parte de comportamiento similar en dos casos de uso y no queremos
repetir la descripción de dicho comportamiento común.
En una relación << extends>>, un actor que lleve a cabo el caso de uso base
puede realizar o no sus extensiones. Mientras, en una relación <<include>> el
actor que realiza el caso de uso base también realiza el caso de uso incluido.
En general utilizaremos <<extends>> cuando se presenta una variación del
comportamiento normal, y <<include>> cuando se repite un comportamiento en
dos casos de uso y queremos evitar dicha repetición.
Por último en un diagrama de casos de uso, además de las relaciones entre
casos de uso y actor (asociaciones) y las dependencias entre casos de uso
(<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea
entre casos de uso o entre actores.
Llamamos modelo de casos de uso a la combinación de casos de uso y sus
correspondientes diagramas. Los modelos de casos de uso se suelen
acompañar por un glosario que describe la terminología utilizada. El glosario y
el modelo de casos de uso son importantes puntos de partida para el desarrollo
de los diagramas de clases.
Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar
a diferentes realizaciones, es importante reflejar en cada representación el
motivo que nos ha llevado a descartarla, si es el caso.
Normas de aplicación
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del
usuario final o del experto del campo del saber al que se va a aplicar. Los
casos del uso son a menudo elaborados en colaboración por los analistas de
requerimientos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea
de negocio. Desde una perspectiva tradicional de la ingeniería de software, un
caso de uso describe una característica del sistema. Para la mayoría de
proyectos de software, esto significa que quizás a veces es necesario
especificar diez o centenares de casos de uso para definir completamente el
nuevo sistema. El grado de la formalidad de un proyecto particular del software
y de la etapa del proyecto influenciará el nivel del detalle requerido en cada
caso de uso.
Casos De Uso
Caso de uso: Mostrar pagina de bienestar
Actor: Estudiante
.
Registro de Datos en la BD
Actor: Estudiante
Resumen: Cuando el usuario desea ingresar los datos para la obtención de becas y
estas se almacenen en la base de datos.
Caso de Uso “Consultar Deportes”
Actor: Estudiante
Actor: Estudiante
Actor: Administrador
Actor: Administrador
2. FASE DE IMPLEMENTACIÓN.
Técnica:
* Mejora del sistema actual.
* Disponibilidad de tecnología que satisfaga las necesidades.
Factibilidad legal
COSTOS Y VALOR DEL PROYECTO
Requerimientos Valor
Mano de Obra por mes
Analista ( 2 mes) $ 800.000
Desarrollador Web (2 meses) $ 800.000
Un Computador $ 1´400.000
Una Licencia Windows 7 $ 210.000
1 Licencias office 2007 $ 400.000
Adobe Flash Player Licencia (Gratuito)
Xampp 2.6.0 (Gratuito)
Macromedia Dreamweaver 8 portable $750.000
PSPad es un Microsoft Windows (Gratuito)
Internet (por mes) $ 45.000
Resma De papel $8.000
Total $ 5´824.000
4.1. Oportunidades
4.1. Amenazas
4.1.4.3 Fortalezas
4.1.4.4 Debilidades
REQUERIMIENTOS HARDWARE
Procesador, Intel dual core 2 o superior.
Tarjeta de Red.
Espacio en disco duro de 500 GB .
1 GB de memoria RAM o superior.
Resolución estándar 1024 x 768 píxeles.
Tarjeta de audio y video.
Conexión a Internet
REQUERIMIENTOS SOFTWARE