prototipo de aplicaciÓn web de gestion de documentacion y...

91
i PROTOTIPO DE APLICACIÓN WEB DE GESTION DE DOCUMENTACION Y EVALUACION COMO SOPORTE ORIENTADO AL APRENDIZAJE DE IDIOMAS HENRY ANDRES ARIAS CORREA 20052020007 Mediante la modalidad de monografía para optar a título de Ingeniero de sistemas Director: JOSE DAVID ÁLVAREZ UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C

Upload: dangkhanh

Post on 11-Feb-2018

216 views

Category:

Documents


1 download

TRANSCRIPT

i

PROTOTIPO DE APLICACIÓN WEB DE GESTION DE DOCUMENTACION Y EVALUACION COMO SOPORTE

ORIENTADO AL APRENDIZAJE DE IDIOMAS

HENRY ANDRES ARIAS CORREA

20052020007

Mediante la modalidad de monografía para optar a título de Ingeniero de sistemas

Director: JOSE DAVID ÁLVAREZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C

i

1. CONTENIDO

1. CONTENIDO .................................................................................................. I

2. TABLA DE GRÁFICOS ................................................................................ IV

3. INTRODUCCIÓN ........................................................................................... 5

4. OPORTUNIDAD O PROBLEMÁTICA ........................................................... 6

4.1. Descripción del contexto ........................................................................................... 6

4.2. Formulación del problema ......................................................................................... 7

5. DESCRIPCIÓN DEL PROYECTO ................................................................. 8

5.1. Justificación ................................................................................................................ 8

5.2. Objetivo general ........................................................................................................ 10

5.3. Objetivos específicos ............................................................................................... 10

6. RESUMEN EJECUTIVO .............................................................................. 11

7. MARCO TEÓRICO ...................................................................................... 12

7.1. Introducción............................................................................................................... 12

7.2. El entorno e-learning ................................................................................................ 14

7.3. Implicación didáctica y la estrategia de aprendizaje ............................................ 16

7.4. Bloques de implementación de documentación. .................................................. 17

7.5. Roles ........................................................................................................................... 18 7.5.1. Administradores. ................................................................................................. 18 7.5.2. Capacitadores y maestros .................................................................................. 19 7.5.3. Aprendices y estudiantes. ................................................................................... 19

8. MARCO CONCEPTUAL .............................................................................. 20

8.1. Ingeniería de software .............................................................................................. 20

8.2. Proceso de negocio .................................................................................................. 20

8.3. UML (Unified Modeling Language) .......................................................................... 22

ii

8.4. Sistema de gestión de base de datos (SGBD) ....................................................... 22

8.5. Inteligencia de negocios .......................................................................................... 22

8.6. Cadena lógica de negocio (CLN) ............................................................................. 24

8.7. Dependencia funcional (DF) ..................................................................................... 26 8.7.1. Propiedades ACID (Atomicity, Consistency, Isolation, Durability: Atomicidad, Consistencia, Aislamiento, Durabilidad) ............................................................................. 26

8.8. Modelo entidad – relación ........................................................................................ 27

8.9. Modelo relacional ...................................................................................................... 28

8.10. Modelo - vista - controlador ................................................................................. 29

8.11. Arquitectura Cliente – Servidor ........................................................................... 30

8.12. PHP ......................................................................................................................... 31

8.13. Cambios en el desarrollo. .................................................................................... 31 8.13.1. Entorno de desarrollo .......................................................................................... 31 8.13.2. Apache ................................................................................................................ 33 8.13.3. MySQL ................................................................................................................ 33 8.13.4. CakePHP ............................................................................................................. 33

9. METODOLOGÍA .......................................................................................... 34

9.1. Implementación de UML ........................................................................................... 34

9.2. Modelo funcional ....................................................................................................... 35 9.2.1. Levantamiento de requerimientos ....................................................................... 35

9.3. Alcance del sistema .................................................................................................. 36 9.3.1. Seguridad y accesibilidad: .................................................................................. 36 9.3.2. Esquemas y formato estandarizado.................................................................... 36 9.3.3. Gestión de contenido .......................................................................................... 37 9.3.4. Gestión de búsqueda .......................................................................................... 37 9.3.5. Generación de cuestionarios y talleres ............................................................... 37

9.4. Limitaciones .............................................................................................................. 37

9.4.1 RESTRICCIONES Y SUPOSICIONES .......................................................... 37

9.5. Metodología RUP ...................................................................................................... 39

9.6. Requerimientos ......................................................................................................... 41 9.6.1. Requerimiento de aplicación de enseñanza ....................................................... 41 9.6.2. Requerimiento del administrador y del tutor de la aplicación ............................. 42 9.6.3. Requerimiento de estudiantes ............................................................................ 46 9.6.4. Requerimiento de funcionales de transacciones ................................................ 48 9.6.5. Requerimientos no funcionales. .......................................................................... 48 9.6.6. Pseudorequerimientos. ....................................................................................... 52 9.6.7. Definición de actores ........................................................................................... 52

iii

9.6.8. Casos de uso de la aplicación. ........................................................................... 52

9.7. Modelado de objetos ................................................................................................ 62 9.7.1. Diagrama de clases ............................................................................................ 63 9.7.2. Diagrama de actividades ..................................................................................... 65 9.7.3. Diagramas de secuencia. .................................................................................... 69 9.7.4. Implementación modelo base de datos. ............................................................. 70

10. IMPLEMENTACIÓN PROTOTIPO ............................................................... 72

11. RECURSOS ................................................................................................. 85

11.1. Recursos humanos ............................................................................................... 86

11.2. Hardware ................................................................................................................ 86

11.3. Software ................................................................................................................. 86

11.4. Servicio de red ...................................................................................................... 87

11.5. Costo del proyecto ................................................................................................ 87

12. BIBLIOGRAFÍA .......................................................................................... 88

13. ANEXO A..................................................................................................... 90

iv

2. TABLA DE GRÁFICOS

Figura 1 Esquema TPACK Tomado de [5] .............................................................. 13 Figura 2 Esquema interacción e-learning Tomado de [11] y [13] ............................ 16 Figura 3 Proceso de la información en la organización, tomado de Fernando Dávila consultado en [16] .................................................................................................. 23 Figura 4 Esquema básico de la cadena lógica de negocio monofuncional, sin dependencia funcional. Basado en [17] .................................................................. 25 Figura 5 Ejemplo de una CLN bifuncional compuesta. Dos bloques de grupos transaccionales están enlazados a un mismo sujeto, mas no están relacionadas entre sí. Se muestran los grados de dependencia funcional. Basado en [17] ......... 26 Figura 6 Ejemplo de una CLN monofuncional simple. La multiplicidad del grupo transaccional es de 1-* , se asienta en el concepto que dicho grupo afecta a varios sujetos. Basado en [17]. ......................................................................................... 26 Figura 7 Componentes Modelo Entidad – Relación, basado en [17] ....................... 28 Figura 8 Esquema modelo Entidad – Relación, basado en [17] .............................. 28 Figura 9 Componentes estándar del Modelo relacional. Basado en [17] ................. 29 Figura 10 Tipos de relaciones: Fuertes donde hay relación FK-PK con una PK, débil donde hay una relación FK-PK. Basado en [17]. .................................................... 29 Figura 11 Esquema Modelo - vista – controlador de acuerdo con [20] .................... 30 Figura 12 Modelo Cliente –Servidor basado en [22]. .............................................. 31 Ilustración 1 Caso de uso manejo aplicación .......................................................... 61 Ilustración 2 Caso de uso manejo documentación .................................................. 61 Ilustración 3 Caso de uso manejo diccionar ............................................................ 61 Ilustración 4 Caso de uso Registro curso ................................................................ 62 Ilustración 5 Diagrama de clases ............................................................................ 64 Ilustración 6 Diagrama actividades registro tutor .................................................... 66 Ilustración 7 Diagrama actividades registro tutor .................................................... 67 Ilustración 8 Diagrama actividades registro estudiantes.......................................... 67 Ilustración 9 Diagrama actividades creación curso ................................................. 68 Ilustración 10 Diagrama actividades creación curso ............................................... 69 Ilustración 11 Interfaz de inicio Langee ................................................................... 72 Ilustración 12 Interfaz inicio registro tutores ............................................................ 73 Ilustración 13 Interfaz registro estudiantes .............................................................. 73 Ilustración 14 Interfaz registro tutor ......................................................................... 74 Ilustración 15 Menú administrador .......................................................................... 75 Ilustración 16 Menú administrador .......................................................................... 75

5

3. INTRODUCCIÓN En un mundo globalizado donde las interrelaciones y las comunicaciones conectan seres humanos interrelacionando culturas, éstas implican unos factores dentro de la información y la comunicación, como las formas de expresarlos o que quiere dar a entender al interlocutor, independientemente del tema que se aborde. Adicional a eso se suma los elementos utiliza para la interrelación con otras personas o entes ya sean reglas, formas de expresión y elementos culturales para entender el mensaje. Por lo tanto, la importancia de aprender idiomas, pero en general el método y la herramienta a utilizar cobran una importancia cada vez mayor para que las personas puedan tener buenas bases de aprendizaje, a su vez debe ser eficiente para agilizar y volver más fácil y asequible el aprendizaje. Las TIC’s hoy en día son responsables por ende de la difusión por un interés cultural y/o comercial de estos saberes, dado que la sociedad demanda una mayor interacción y un mayor entendimiento. Por tanto, es crítico el entender que requiere para que se pueda satisfacer una demanda más creciente y que requiera una pronta respuesta sin caer en vicios o en redundancias que no aporten al aprendizaje a nivel general y que impida en caso contrario que las personas puedan mejorar en su camino. Por ende, es menester ofrecer una oportunidad donde puedan evaluar su desempeño y garantizar así mismo que el camino sea creciente para evitar confusiones y que puedan caer en vicios, sin subestimar el método y acercar a la persona a una cultura nueva y a posibilidades de expandir su nivel.

6

4. OPORTUNIDAD O PROBLEMÁTICA

4.1. Descripción del contexto La entrada de las TIC1 en el entorno educativo mas en el aspecto de la filología2 y en general de la lingüística, ha permitido la facilidad de las personas de aprender nuevas culturas y nuevas interacciones, casi sin salir de casa, mediante la interacción multimedia y ha permitido aproximar el aprendizaje a un plano más asequible y al alcance de todas las personas sin requerir más que un dispositivo, este complemento ha permitido un soporte más sólido para quienes desean profundizar el aprendizaje de uno o más idiomas. Sin embargo, las integraciones de las TIC en el entorno educativo han exigido replantear los estándares de enseñanzas ya que por sí solo la aplicación no resuelve todos los planteamientos exigidos bajo la lógica de negocio que en este caso serían los estándares educativos que requiere para que el aprendizaje se lleve a cabo. Por ende, la metodología requerida es tan variable y es consecuente a los requerimientos que se piden, el estilo, el método y el modelo que se imparte para la enseñanza y el estudio para mostrar resultados y además que satisfaga los intereses de los estudiantes dando fortalezas a los puntos más altos y superando los puntos más débiles. Sus antecedentes van más allá del aspecto meramente informático o del uso de computadores, según varios investigadores de acuerdo a [1], ésto se debe a que los medios de comunicación fueron gran parte responsables de la expansión de los métodos de enseñanza a través del s. XX mediante el uso de la radio y posteriormente la televisión, que ya eran complementarios con el uso de los libros en especial en los años 40’s en los EEUU con base en desarrollos militares. A partir de estos avances es que se ha forjado un interés en buscar una tecnología acorde con las necesidades de enseñanza y que resolviera problemas de fondo en la enseñanza por medio de la tecnología. De allí se desprenden problemas como la delimitación entre la educación y la tecnología y que es lo que representan éstas en la educación, el carácter multimedia y como los profesores aplican estos elementos para hacer al profesor un usuario de dichos recursos. Igualmente es un dilema la concepción del concepto nuevas TIC’s el cual entra en ambigüedades de forma y definición como:” todos aquellos medios de comunicación y el tratamiento de la información propiciados por el desarrollo de la tecnología electrónica y las herramientas conceptuales, tanto conocidas como aquellas otras que vayan siendo desarrolladas como consecuencia de la utilización de estas mismas tecnologías y de avance del conocimiento humano” [1]. Estas ambigüedades también hacen que se cuestionen por detalles de redundancia. Finalmente, el último dilema radica en el alcance en el tiempo, si es funcional a largo plazo como una fuente de información verificable.

1 Tecnologías de la información y la comunicación

2 Estudio de la lengua

7

El entender estos aspectos brevemente, traen impactos grandes dentro del paradigma de la educación y formación, no sólo en un aspecto meramente académico sino también en un entorno productivo, donde la comunicación está enlazada con la preparación y capacitación a todos los niveles, en la preparación y capacitación de una potencial mano de obra; también en la preparación de profesionales a todos los niveles académicos e industriales, evaluando su influencia desde un aspecto cualitativo en todos los niveles productivos, así como el impacto en la formación.

4.2. Formulación del problema ¿Cómo lograr de forma práctica el manejo de documentación, dando las bases para la creación de nuevos cursos que permitan una evaluación más dinámica, avanzando mediante recursos y materiales accesibles a todo público y personalizados en casos exclusivos por docentes, sirviendo a las exigencias y requerimientos de enseñanza por medio de TIC’s?

8

5. DESCRIPCIÓN DEL PROYECTO

5.1. Justificación Hablar del concepto pedagógico y de la enseñanza de los idiomas tiene diversas aristas debido a la gran cantidad de requerimientos, exigencias y demás ofertas ofrecidas en el mercado donde se enfocan cada uno de forma particular a un nicho específico. Hablar de desarrollo multimedia en torno a la educación ha generado a un sinfín de metodologías que han de alguna manera satisfecho a los aprendices pero que dejan vacíos en cuanto a la metodología impartida, al contacto con los ejercicios o de forma más rigurosa se ven limitados en cuanto a la temática recibida debido a la dispersión de muchas temáticas. Sin mencionar que el paradigma de segunda lengua es un tanto limitante a las exigencias modernas, subestimando el potencial de la persona que quizá pueda aprender más, además la limitación de las ofertas al basarse en una verticalización del aprendizaje de una lengua según conceptos comerciales y/o culturales, han dejado enormes y vacuas soluciones que lejos de ofrecer satisfacción han dejado serias dudas del funcionamiento de la aplicación. La aplicación por si sola puede satisfacer una solicitud o puede responder a algunas soluciones; sin embargo, éstas nunca se podrán satisfacer debido a las particularidades humanas, al contacto, a la forma de recepción y cuestiones aptitudinales por parte de la persona como la disciplina. La concepción errónea del relego del maestro o instructor en un marco tecnológico ante la avalancha de las TIC’s habrá de vencerse ante el concepto de la asimilación y la actualización de su experiencia adaptándola a los nuevos tiempos para acercar al alumno a lo que quiere aprender, según su estrategia. Potenciando destrezas y mejorar estrategias; no reinventando la rueda, debido a la densidad de material en diferentes medios como internet sino de enfocar a los requerimientos que éstos tengan, brindando la información necesaria, siendo ágiles y permitir ser evaluados según conceptos del docente, tutor o evaluador sin un único estándar limitante, siendo coherente con los criterios del profesor dentro de su metodología establecida y los requisitos que él tenga. [2], [3] De acuerdo con [2], ésto supone la consecución de un método de aprendizaje personalizado que pueda ser tomado por sí mismo con una concepción metodológica previa y sea complementario para el aprendizaje de idiomas en la escuela o instituto particular, con base en el acompañamiento del tutor al estudiante brindando sus propios materiales proponiendo una metodología de enseñanza con sus recursos, a su vez él pueda diseñar sus talleres para que se resuelvan según el criterio del tutor, personalizando cada vez más la enseñanza, priorizando las falencias y fortalezas del estudiante y que pueda tener mayor control sobre el desempeño del estudiante. Dado que los usuarios objetivo recaen sobre el tutor y el estudiante, se debe diseñar un prototipo que sirva de base para que los estudiantes tengan un desenvolvimiento más intuitivo donde pueda recopilar sus materiales de forma más eficiente y sea

9

menos engorrosa, que sea explícito, acorde y accesible para todo público permitiendo un acercamiento por parte de docentes externos sirviendo como complemento para la enseñanza en caso que los materiales puedan ser utilizados de forma didáctica y no comercial, adaptando el diseño para docentes cuya enseñanza sea personalizada pueda impartir sus cursos, aportando materiales y que él pueda dar la ruta a seguir teniendo en cuenta la temática y los puntos para evaluar en casos que requieran una capacitación particular. Para la capacitación particular se requiere que el tutor disponga de documentación, diseñe sus talleres y la evaluación para aportar a la biblioteca para disponibilidad de los usuarios; a su vez que tenga una sección dedicada a la evaluación que mide su desempeño. Para ello se requiere que se busquen mecanismos de interacción con el fin de evitar falencias y desavenencias en el momento de aportar información, que sea asequible y accesible para que las búsquedas sean rápidas, así mismo el diseño de la aplicación sea dinámica para adaptarse a diversos requerimientos específicos según la lógica de negocio específica y sea adaptativa a cambios, sea de requerimientos funcionales, no funcionales y pseudorequerimientos, como también de detalles de implementación, interacción y complementando con el concepto de evaluación; una buena respuesta al manejo de la herramienta. Igualmente, si se desea extender la aplicación a un diseño especifico, precisa de los potenciales usuarios quienes deben precisar los puntos para reforzar la colaboración entre los entes que facilite la operación requerida tanto para quienes administran, como para quienes desarrollan, y los usuarios finales en este caso los aprendices. En el caso de capacitación general, aplican los mismos principios, salvo que el tutor dejará un material base o materiales bases para varios idiomas, cuya orientación este dada para una consulta sin ninguna restricción, bajo la única condición de mostrar un temario especifico, con un orden y buscando ser dinámico en la enseñanza. Finalmente un detalle adicional supone la implementación de dicha aplicación siguiendo la metodología de diseño UML, la cual busca un diseño optimo que contribuya a entender más desde la perspectiva del software, la concepción, su desarrollo basándose en requerimientos básicos y construyéndose hasta mostrar mediante su diagramación el desempeño de máquina, la interacción con el usuario y concepción del sistema con base de requerimientos de un ente en específico, en este caso puede ser un usuario.

10

5.2. Objetivo general Desarrollar un prototipo de aplicación web teniendo en cuenta el modelo de tres capas que permita un diseño de una biblioteca de archivos que esté disponible para ser adaptado para la enseñanza de idiomas de forma general y gratuita y tenga una sección exclusiva que pueda moldearse según las características de los docentes y permita la evaluación en los mismos mediante talleres asistidos según la temática que se maneje.

5.3. Objetivos específicos

5.3.1. Plantear un diseño base para poder ajustar los idiomas disponibles a enseñar con un mínimo de información acerca del idioma con un temario específico y talleres estándar.

5.3.2. Analizar la metodología de distribución de idiomas que va a soportar y a los cuales va dirigida la evaluación y la biblioteca de archivos.

5.3.3. Adaptar un diseño que esté acorde a las condiciones que considere el tutor o los tutores.

5.3.4. Analizar mecanismos de soporte de información que brinde una asequibilidad y accesibilidad al usuario.

5.3.5. Identificar los módulos de evaluación y sobre él ir distribuyéndolos según el temario y el idioma a evaluar.

5.3.6. Diseñar el prototipo de aplicación web utilizando el modelo 3 capas (Modelo – Vista – Controlador), donde el administrador conceda permisos mediante negociación previa y permita a los tutores diseñar y dejar su material personalizado y la evaluación para que el aprendiz pueda acceder a la aplicación tomar su evaluación.

5.3.7. Que el aprendiz pueda tomar el o los idiomas que desee tomando el material sin alguna restricción salvo la limitación que debe superar un mínimo para pasar de unidad o completar los requerimientos del tutor.

5.3.8. Realizar el levantamiento de información para los requerimientos funcionales y no funcionales.

5.3.9. Permitir el acceso libre a la aplicación, salvo para capacitaciones particulares donde hay requerimientos personalizados por parte del tutor par servicio del aprendiz.

11

6. RESUMEN EJECUTIVO Diseñar un prototipo de una aplicación web orientado a la enseñanza de idiomas con una plataforma base donde pueda tenerse a disposición una biblioteca de archivos multimedia disponibles para que se pueda adaptar a cualquier idioma que se vaya a impartir dando una accesibilidad libre y gratuita a la enseñanza de idiomas. Adicional que haya una plataforma complementaria de capacitaciones personalizadas que se adapte a las condiciones que el maestro que la vaya a impartir considere pertinente. En ambos casos gestionando los cursos, diseñando los módulos con el fin de satisfacer el temario específico de cada idioma para que el aprendiz pueda tomar sus capacitaciones de la mejor forma. Igualmente se busca que sea ágil y no sea demasiado engorroso, garantizando flexibilidad al usuario. En cada temario se sirven de talleres y evaluaciones para medir el desempeño del estudiante y hacer una retroalimentación en caso que se requiera.

12

7. MARCO TEÓRICO

7.1. Introducción

Desde el desarrollo de las TIC’s como herramientas de aprendizaje y proliferación de conocimiento, partiendo desde los medios de comunicación existentes previos al desarrollo del computador moderno y de los dispositivos móviles. El aspecto metodológico ha sido y será un elemento fundamental para la consecución de los mismos para que los maestros y orientadores, puedan aportar conocimiento de forma eficaz sin llegar a ambigüedades y sin omitir detalles que puedan afectar a los estudiantes en su aprendizaje. La discusión de cómo abordar estos temas se han abordado principalmente desde 1940 [1] que impulsó la enseñanza y la capacitación en tiempos de guerra orientados a militares y a temas estrictamente de aprendizaje de instrumentación y temas bélicos, entendiéndose que el origen del aprendizaje al igual que muchas tecnologías tienen un origen militar. Ya hacia los años 50’s del s. XX, La Universidad de Indiana en los EEUU, implementaron bosquejos de una educación audiovisual orientada a posgrados que habían iniciado en 1946. Más adelante hacia los años 60’s del s. XX se empezó a enfatizar este concepto en la enseñanza de idiomas y fue evolucionando hasta nuestros días con un enfoque que dio lugar a una tecnología y la integración con la educación, en este caso de acuerdo con [4] surge para la enseñanza del inglés el sistema Computer- Assisted Language Learning (CALL), las cuales brindaron un avance mayor por parte de las TIC’s mas con la llegada de la internet. Una metodología de aprendizaje y desarrollo didáctico implementado fue como el modelo TPACK [5] (Technological Pedagogical Content Knowledge), de acuerdo con [6] este modelo fue concebido como un esquema que reúne tres ramas donde se asienta la enseñanza como la rama disciplinar, la tecnológica y la pedagógica. Poniendo de manifiesto que se enfoca en la enseñanza de una disciplina en particular teniendo en cuenta el conocimiento en una tecnología en específica y logra acercarlo a un modelo de enseñanza establecido e igualmente la enseñanza de una disciplina. Warschauer y Healey [7] hacen notar una serie de procesos del cual está implícito el computador en la enseñanza de los idiomas, previamente se mencionó la etapa de 1960 a la década de 1970 donde aparece el modelo «behaviorista» cuyo planteamiento fue la repetición, posteriormente surgió la «comunicativa» en la década de 1970 hasta los años 1980. En esos años se fomentaron el descubrimiento, la creatividad y el desarrollo como forma de enseñanza. [4] Con base en el «constructivismo», en los años 1980 y 1990 se formó el modelo «integrador», éste se basa en el conocimiento del contexto, del enfoque por tareas, el aprendizaje basado en proyectos y la aproximación al contenido. Con base en este modelo, se diseñaron proyectos basados en tecnología CALL.

13

Figura 1 Esquema TPACK Tomado de [5]

Después de muchos desarrollos en la década de 1990 y la década de 2000, ésta se toma a consideración en el cómo se debe usar la tecnología, que mecanismos debe tomar, que se necesita saber y cuál es su propósito. Igualmente, del por qué se hacen y que áreas se requieren investigar. Autores como Hubbard y Levy plantean: «necesitan saber por qué hacen lo que hacen» y Hong del como los maestros deben tomar el conocimiento previo para el dominio de la tecnología y así poder impartir sus clases. De acuerdo con [8] Warschauer también plantea una pregunta del uso de la herramienta CALL midiendo el alcance y sus contribuciones en el aprendizaje de idiomas basados en niveles de vulnerabilidad sobre otras cosas fuera de control. Con ésto, su propósito fue de intervenir y de plantear un modelo de producto y de perspectiva orientada a proceso. Esta dualidad de producto y perspectiva de proceso en el entorno educativo y el impacto con la teoría de desarrollo, tienen una relevancia critica; a nivel socioeconómico se tiene una perspectiva del producto terminado en el cual surge una posterior evolución donde hubo un cambio de perspectiva, en el fondo el mismo principio se atañe a otras cuestiones como el concepto social, y donde esta evolución busca un beneficio a nivel social. En síntesis, el concepto de producto final ha venido decantándose en función de una evolución más allá del mero producto terminado y busca otras salidas. Esto tiene mucho de influencia con la educación de idiomas y el impacto en el proceso de aprendizaje, cuyas salidas hacia nueva comprensiones pedagógicas y comunicativas han tenido una mayor relevancia en la evaluación competitiva, y la influencia de estas como recursos educativos. Durante esta evolución Warschauer pudo comprobar el paso desde el e-mail hasta los mecanismos más complejos a nivel tecnológico pasando por la World Wide Web, durante estos años se pudo comprobar inicialmente el impacto de la tecnología a

14

nivel social hasta pasar por la evaluación de la enseñanza de la lengua inglesa cuya participación se dio como miembro del currículo de la enseñanza de la lengua inglesa, en el desarrollo materiales electrónicos, medios multimedia, diseño de aplicaciones de búsqueda, revisando minuciosamente aspectos comunicativos e incluso desarrollando medios para la interacción del usuario con el equipo. La investigación adelantada con su equipo permitió evaluar las prioridades y la reconstrucción del currículo en función de una inclusión tecnológica en virtud de sus ventajas y desventajas. Además, concluye que el CALL funciona como una opción de asistente para aprendizaje de lenguas, mas no de transformar de lleno el que se desea aprender, el que hacer global; sin embargo, no demeritó a la tecnología como herramienta optativa sino como un baluarte muy importante dentro de la educación como herramienta de aprendizaje, tomando un desarrollo intensivo y de uso muy importante en los salones de clases. Basado en ello resaltó la importancia de la capacitación docente, el potencial que tiene dentro del crecimiento social y la ampliación en un mundo globalizado y a su vez permite examinar los estándares de aprendizaje y de enseñanza. Como consecuencia se replantearon muchas metodologías y reflexiones acerca de la interacción de la tecnología en la educación. El ministro de educación de Egipto mencionó: «El logro de los objetivos de desarrollo podrá necesitar preparación de un nuevo cuadro de profesionales que son aptos para interactuar con el lenguaje de esta era, y con la revolución de las tecnologías de la información y la comunicación… Por consiguiente, el entrenamiento tecnológico puede arrancar en una era temprana y puede incluir todos los aspectos de la comunicación». [8], [9] Para ello se requiere que todos los docentes y el entorno de aprendizaje esté familiarizado con el aspecto tecnológico, pero más importante aún es resaltar y priorizar el cómo usar la herramienta para no tener vacíos ni saltos en la utilización de la herramienta, menos que al utilizarla genere confusiones o que sea una cuestión direccional únicamente sólo por atender una solicitud del sistema, impidiendo que el estudiante interiorice lo aprendido.

7.2. El entorno e-learning

Dado que el aspecto que aborda directamente es el aspecto de enseñanza virtual, es el de gestión del conocimiento, para hacer funcional la aplicación se requieren de partes fundamentales para aplicarse en el aprendizaje, estos son:

- Portabilidad y seguridad. - Adaptabilidad - Integración de elementos en una interfaz gráfica. - Gestión académica - Adaptación de características y roles de usuario en torno a un sistema:

Administrador, profesor, tutor y estudiante. - Interacción y comunicación a doble vía entre estudiante y profesor. - Incorporación de recursos de seguimiento.

Esto a nivel general se enmarca la calidad en el diseño, implementación y seguridad de toda la aplicación a nivel de interacción, igualmente busca la flexibilidad en

15

cuanto a la adaptabilidad de lo que se quiere y lo que se está buscando dentro del diseño de la aplicación. Igualmente se analiza la lógica de negocio si se amolda a las políticas o requerimientos de un tutor en específico, así mismo se hace bajo una plataforma estándar el cual se somete a un estudio previo y se deja un diseño base el cual los maestros y estudiantes tengan a disponibilidad un espacio donde pueden importarse y descargarse las aplicaciones. La escalabilidad va según también de los requisitos, aunque inicialmente debe funcionar en iguales circunstancias sin importar el número de personas ingresadas. Pese a ello se hacen controles acerca de que temario se puede acceder y cual es de libre acceso. Por ende, tendrá cada módulo un nivel de accesibilidad externo donde puede consultarse a nivel general temas relacionados para un aprendizaje libre y de libre consulta, igualmente para una rigurosidad más estricta se dejarán secciones de consulta restringida y también de evaluaciones y talleres personalizados. Igualmente se tienen en cuenta las plataformas dadas, a donde va a estar ejecutándose, y si está accesible y tiene la disponibilidad además de la facilidad de los recursos para los estudiantes, esto a nivel de lenguajes, de plataformas, de desarrollo y de alcance del desarrollo si está disponible. Pero más allá del aspecto técnico, el e-learning va más allá de un determinismo tecnológico [10] como se refiere a la idea de una introducción de tecnologías que afecten con buenos resultados de forma automática, que implica una correlación entre las tecnologías y el aprendizaje; sin embargo, la correlación no implica causación tal como explica Paul Levinson [10] donde hace distinción al concepto de determinismo duro y suave. El duro implica una estricta causación, el suave sugiere que hay un cambio, pero éste no es automático y es más sensible al desenvolvimiento de la tecnología. Es por eso que el entendimiento y la enseñanza a través de la red involucran no sólo una relación simple con un contenido y un estudiante sino hay que entender el entorno en el que se desenvuelve el aprendizaje en red. De acuerdo con [11], según [12] se describen 4 tipos de interacción para poder aprender en este tipo de entornos:

- Profesor – Estudiante: Es la forma clásica de enseñanza donde hay una interacción personal que implican aspectos de motivación, dialogo y además un acercamiento que permite una orientación más personalizada y a su vez permite una medición cualitativa y donde hay una evolución, esto entre otros aspectos.

- Estudiante – Contenido: Es un acceso directo a los contenidos que están disponibles, a menudo relacionados a las materias de estudio y cuyos contenidos programáticos ya están previamente establecidos.

- Estudiante – Estudiante: Es el intercambio de información entre compañeros donde hay un intercambio de ideas no jerarquizadas entre otras cosas.

- Estudiante – Interfaz: Se da a través de los participantes de todo el proceso, esta comunicación se da a través de una interfaz, sea mediante documentos, redes, videoconferencias, teléfonos, teleconferencia etc. Se determina gracias a las variables que están involucradas.

16

Otra forma de representar esta interacción se da a través de la gráfica aportada por [13] se manifiesta así:

Figura 2 Esquema interacción e-learning Tomado de [11] y [13]

En definitiva, la implicación va en función un aprendizaje, pero éste tiende a ser más personalizado, donde el instructor lejos de darle una instrucción directa, éste opta por ser un guía, siendo el responsable de su propio aprendizaje el estudiante regulando sus tiempos y estando al tanto de los mismos, el maestro sólo facilita su paso siguiendo su desempeño.

7.3. Implicación didáctica y la estrategia de aprendizaje

Las estrategias de aprendizaje y mas todo lo relacionado con la pedagogía en torno al aprendizaje se conciben como formas de poder atacar un tema a la vez y el desenvolvimiento para facilitar el método de aprendizaje, estas estrategias fueron definidas por Rodríguez Diéguez como: «el proceso, reflexivo, discursivo y meditado que tiende a la determinación de prescripciones, actuaciones e intervenciones necesarias para conseguir la optimización del proceso de enseñanza –aprendizaje» [11, p. 3]. Con ésto el autor nunca pretendió afirmar que el maestro prescinde de los procesos de aprendizaje inmersos en los procesos tradicionales de aprendizaje, sino que el concepto mutaba y cambiaría a aspectos más cognitivos, basados en una metodología que hiciera más explícito el proceso de aprendizaje. Este concepto es complementario al e-learning basado en un principio de psicología cognitiva y en la aplicación de relevancia de los elementos procedimentales en cuanto a la construcción del conocimiento; esto tomado de elementos del constructivismo. Estos procesos se diversifican en varias soluciones que proponen la planificación de actividades, el qué se espera conseguir y el qué se puede conseguir, clasificando y dando un orden. En un aspecto plenamente pedagógico se propone que se proyecten los soportes de la información para que la herramienta sea útil y pueda ser de gran avance para el estudiante, diseñando diversas estrategias en cuanto a la diversificación de las mismas. El diseñar actividades que permitan el acercamiento de los estudiantes para la realización de diferentes actividades viendo

17

su constante aprendizaje y evolución, tomando en cuenta aspectos como trabajo en grupo, de forma cooperativa o simplemente de forma autónoma. Es cuando aparece la figura del tutor que puede ser a modo de moderador cuya función encabeza mas un enlace que una directriz que determina el proceso que debe seguir estrictamente para avanzar. Si bien él puede aportar sus enseñanzas, su importancia radica más en un aspecto colaboracionista como sugiere Harasim: «el énfasis tiene que estar en el propio proceso intelectual del alumno y en el aprendizaje en colaboración» [11, p. 6]. En ellos se busca entre otras cosas, establecer modelos de comunicación, donde busque que los tutores sean quienes aporten su experiencia y su colaboración en torno al aprendizaje buscando diferentes mecanismos siguiendo una dinámica buscando organizar y facilitar procesos. Es por esto que se espera del tutor que satisfaga estos roles:

Rol organizativo, establecer agendas y tiempos, además de ser un líder.

Rol social, de estar en un ambiente loable y haciendo un seguimiento.

Rol intelectual, de facilitar procesos, de enseñar y de aportar ayuda a situaciones claves y donde se puedan hacer interacciones.

Finalmente encontraríamos el de moderador, el de aportar una estrategia de interacción entre la herramienta, el estudiante y las características del aprendizaje y la información que se desea impartir, es ahí donde se esperan desarrollar talentos y el moderador debe aplicar recursos pedagógicos que faciliten la interacción y la toma de información por parte de los estudiantes.

7.4. Bloques de implementación de documentación. Para entender el modelo de accesibilidad libre y exclusiva, hay que partir de lo que se desea enseñar, para qué se desea enseñar y como se enseña. Con estos 3 ítems se inicia el planteamiento del diseño del SI y su posterior implementación. Hay dos grandes áreas que actúan de forma sinérgica ya que ambas se reparten en los módulos de enseñanza de idiomas, según el idioma que se desee impartir cada uno debe tener un área libre y otra área exclusiva, básicamente comparten módulos y comparten modalidades y temática, el detalle estará en el contenido y que procesos se llevarán a cabo en cada una de ellas Cada uno de los módulos que se desean impartir, habrá un idioma, y sobre el habrán 4 grandes bloques: Lectura, escritura, audio y habla. En ellos sólo 3 estarán disponibles en ambas plataformas libres y exclusivas. Sin embargo, la parte del habla no podrá incluirse salvo que se pida algún modulo específico en el diseño. Por ende, no se contemplará dentro de la aplicación de forma explícita, y se recurrirán a otras plataformas externas como Skype o WhatsApp en el caso más extremo. En cuanto a la sección de audios para que puedan almacenarse para acceso libre y eventualmente exclusivo organizándose según las prioridades, llegado el caso, sólo se añade como complemento mediante una plataforma como YouTube dado que no se almacenarán datos grandes, aun existiendo el material aportado.

18

Pese a que toda la aplicación se rige de un estándar, ambos tienen sus prioridades y radica en el contenido principalmente, estará al servicio un estándar que tendrá una temática amplia del idioma y estará libre y disponible para cualquier persona, el contenido exclusivo si bien podrá emular la metodología libre, se busca que el maestro o el tutor quien tenga a disposición la temática pueda interactuar con el estudiante y organizar los módulos, preferiblemente con una formalidad académica más profunda principalmente en el diseño de talleres y de contenido más exclusivo preferiblemente en las colecciones de documentos donde estarán almacenados dichos archivos o en su defecto que puedan diseñarse talleres de forma interactiva. Igualmente se busca que prioricen en las metodologías de especialización en torno de los exámenes y certificaciones de los respectivos idiomas. En cuanto a los talleres, los talleres están disponibles dentro de la colección de archivos para descargar en formatos PDF o .doc o .docx. Para la parte exclusiva igualmente se busca lo mismo, con la diferencia que dichos talleres están sujetos a cambios y modificaciones por parte del tutor, si bien se busca practicidad y la interactividad estará limitada a aportar el contenido y a generar apenas una interacción multimedia mediante sonidos sin algún detalle sobresaliente salvo la estética misma de la aplicación y evitar la saturación. Dicho contenido tendrá algunas secciones donde se preparen talleres específicos y puedan ser versátiles. Para evaluar el desempeño de los estudiantes se requiere de una evaluación cuantitativa que sirva de indicador del estado de los procesos que se efectúan, para verificarlos se requiere que todos los puntos de control puedan servir para revisar el proceso en cada fase, y de allí evaluar si se puede cumplir con una meta propuesta y poder visibilizar sus alcances; sin embargo esta evaluación no tendrá relevancia excepto en una autoevaluación para medir su desempeño y su evolución; sin embargo en el caso de la parte exclusiva puede tener cierta relevancia si este puede mostrar un desempeño y puede avanzar de nivel. En este punto la evaluación sólo se podrá hacer mediante una evaluación que hara el tutor a modo de una nota final tomando en cuenta una interacción externa fuera de la aplicación. La evaluación es meramente descriptiva. Y será el maestro y el tutor con el estudiante quienes llevarán el control del mismo fuera de la plataforma cuando el aprendiz desee medir su rendimiento.

7.5. Roles

7.5.1. Administradores. Son quienes tendrán el manejo de las BD y la administración, acceso y gestión de los archivos para ser manipulados además de llevar el registro siendo responsables del aspecto lógico y eventualmente físico del sistema de información y mantenimiento de la aplicación, cuidando y gestionando los permisos de acceso y las modificaciones. Igualmente son aquellos quienes cuadran el contenido, organiza los detalles y adicional concede los permisos de acceso a los capacitadores quienes tendrán el control de las actividades. También los administradores serán quienes tendrán el control de los materiales. Ellos administran los módulos de la aplicación y

19

quienes abran o cierren los mismos, gestionando los accesos al material libre y al material restringido con sus respectivos permisos. El administrador en compañía del tutor se encargaría de diseñar parte de las plantillas o en su defecto los talleres con los requerimientos previos.

7.5.2. Capacitadores y maestros Son quienes aportarán su material o en su defecto serán los guías quienes organicen los documentos o cuestionarios, organizando el material existente, modificando y borrando según las necesidades establecidas por las metodologías de enseñanza, las unidades y también el avance que se presente. Esto será indistinto de los módulos exclusivos y libres.

7.5.3. Aprendices y estudiantes. Serán quienes accedan a la aplicación, de forma exclusiva o de forma libre teniendo en cuenta ciertas especificaciones y exigencias, los que acceden de forma exclusiva, tendrán beneficios de accesos a talleres exclusivos y además a material adicional de preparación y una asistencia más adecuada a las exigencias del docente. El modo de acceso estará también acorde a lo que proponga el docente.

20

8. MARCO CONCEPTUAL

8.1. Ingeniería de software De acuerdo con [14], este término fue acuñado en 1968, como una respuesta para desarrollar software de calidad teniendo en cuenta optimización de recursos y criterios de calidad dentro del desarrollo de aplicaciones, planteando condiciones de desarrollo y mejora continua de aplicaciones de software. También se fundamenta en la expectativa que se tiene acerca de diseñar determinado elemento en determinados escenarios, donde puede suponer cambios abruptos y la tolerancia que se tiene para asumir sus tareas y el alcance que tiene en sus funciones, igual. Teniendo en cuenta factores de optimización de recursos en condiciones adversas, dando lugar a saber distribuir estos elementos con contratiempos y de una forma óptima y que esté acorde a los detalles relevantes y permitiendo siempre la posibilidad de mejora, modelando y facilitando la toma de decisiones para enfocar un proyecto a una solución óptima evaluando factores de complejidad y de cambio para mirar el proceso de evolución

8.2. Proceso de negocio

De acuerdo con [15], dado que el fin de un sistema, llámese empresa, universidad, estamento, etc. es existir, para ello se requiere una serie procesos tales como obtención, intercambio y salida de recursos como bienes o servicios. La importancia del mejoramiento y refinamiento de procesos se hace fundamental en la ejecución de los mismos. Este se basa en procesos bien estructurados que requieren de un grado de conexión que permita el flujo de todos los procesos de tal forma que permita la agilidad y que represente un valor. Por ello existe el proceso de negocio que sirve para la obtención, producción e identificar la salida de un producto en específico, conectadas todas mediante flujos de información. Para plantear este proceso de negocio se requiere la concepción de conceptos como la ingeniería de software, los sistemas de gestión de bases de datos, entre otros. Además de herramientas de modelamiento tales como UML (Unified Management Language) o también el BPMN (Business Process Modeling Notation) entre otras herramientas. Para la ejecución del proceso se tienen en cuenta estos conceptos:

Workflow: Se refiere al flujo de trabajo automatizado. Es decir, el paso de información a través de pocos pasos sin que se requieran mayores intermediarios donde éstos involucren actividades directas de usuarios o personas. Ésta es independiente si se da de forma parcial o completa.

Gestión del workflow: El sistema que regula el paso de información y

asegura la relación de los diferentes sistemas automatizados, además de la comunicación con otros entes externos tales como los SO (Sistemas operativos).

21

Proceso: Es la secuencia de pasos que se da para la ejecución de un evento

con una lógica y que busca la obtención de un resultado específico.

Gestión de procesos de negocio: Esta gestión se refiere a la técnica o técnicas que se requieren para aplicarse a los diversos procesos de negocio, que permite evaluar y verificar el estado del proceso en cada una de sus etapas, además de todas las variables que involucran la ejecución del mismo, como la herramienta que se requiera.

Dado que el proceso requiere dentro de sí una serie de actividades que busca la optimización, la comunicación entre otras cosas. Éstas son algunas actividades que giran en torno a los procesos.

Valor agregado: Es la transformación del recurso en salida de información, sean productos o servicios.

Traspaso: Es el intercambio de información a través de diferentes entes.

Control: Es aquel que se encarga de regular los procesos que permiten el

flujo de información, en función de recursos y tiempo. Adicional a las actividades, los procesos contemplan otros ítems:

- Subprocesos: Es una división de un proceso, el cual posee también actividades, entradas y salidas, replicando al proceso, sólo que con particularidades propias del subproceso.

- Actividades: Son pasos los cuales se deben ejecutar para hacer la transformación de entradas en una salida que es un proceso esperado; éstas están plenamente atomizadas, es decir que ya no es posible crear más pasos.

- Decisiones: Son pasos que propician el siguiente paso en pos del beneficio y

del valor de lo que busca el cliente.

- Entradas: Son los insumos, datos o información que requieren ser usados a lo largo del proyecto y sirven sea como recursos para ser transformados en una salida, o simplemente como base para obtener información que sirvan para la consecución del mismo.

- Salidas: Es el resultado o producto que resulta del proceso.

- Recursos o mecanismos: Son las herramientas que permiten que se lleve a

cabo el proceso, ayudando a la ejecución de la actividad.

- Políticas: Son la base sobre la cual se deben regir las actividades y que los procesos se ejecuten sobre esas líneas, además suponen las restricciones y requerimientos mediante manuales, controles y las mismas políticas.

22

8.3. UML (Unified Modeling Language)

Es un lenguaje de modelado principalmente gráfica el cual su notación se vale a partir del planteamiento de los métodos para expresar diseños. Mientras es el proceso el que define los pasos para concretar el diseño. Es un estándar que se maneja para unificar conceptos de diseño y refinamiento de planteamientos para el desarrollo de aplicaciones, surge a partir de la búsqueda de un estándar de desarrollo ante la cantidad de modelos planteados y que eran confusos algunas veces y fueron buscadas con un fin industrial y empresarial. A partir de allí se genera un modelo que integra diversas funciones y cuyo fin era lograr un esquema entendible y que tenga puntos en común. Este esquema se basó inicialmente en el paradigma de orientación a objetos, el cual permite un manejo estandarizado y comprensible. Dado que ambos esquemas, tanto el paradigma de desarrollo como el lenguaje de diseño fueron diseñadas en forma simultánea, permitieron la comprensión de la descentralización de los sistemas, y la comprensión de la organización. Este lenguaje se basa en la diagramación con criterio de clases, casos de uso, patrones de diseño etc., con el fin de propiciar un desarrollo iterativo y orientado hacia un replanteo de diseños. Este diseño fue pensado especialmente en el modo de ejecución de la aplicación hacia la empresa u organización, basándose en la óptica del sistema, con base en una serie de requerimientos previos. .

8.4. Sistema de gestión de base de datos (SGBD)

Este sistema está relacionado con la agrupación de recursos que se tiene para acceder a una base de datos, éste se encarga de dar un manejo de registros a través de una aplicación que permite la gestión de los mismos. Dando lugar a modificar, ejecutar, crear, recuperar, etc. Este sistema va de la mano con el modelamiento de un sistema de información. El cual se encarga de administrar los procesos de un sistema de información.

8.5. Inteligencia de negocios

Ésta se conceptualiza como la competencia que se tiene para la toma de decisiones, teniendo en cuenta la dinámica del negocio como las oportunidades y debilidades apoyado por los procesos de controlar, captar, administrar, organizar, conservar y presentar la información dada con el fin que sirva de soporte para el desarrollo de las capacidades y la optimización de recursos y procesos de la organización interna de la empresa.

23

De acuerdo con [16] esta inteligencia de negocios parte a partir de la detección de fuentes de información, para ello no se requiere una gran cantidad de datos para interpretar la información o de un gran sistema de bases de datos, sólo se requiere de aplicaciones donde la información esté almacenada. Es decir que para el manejo de la información no se requiere sino del simple hecho de encontrar una fuente confiable y asequible. A continuación, se presentan estas 4 etapas, las cuales representan el esquema de información dentro de la organización (Figura 3):

Figura 3 Proceso de la información en la organización, tomado de Fernando Dávila consultado en [16]

Con base en este esquema se ven las 4 fases de gestión de la información, las cuales son:

1. Extracción. 2. Consolidación 3. Explotación 4. Visualización.

En la extracción de datos, la prioridad está en la detección de las fuentes de información, estas pueden ser accedidas a través de cualquier medio, siempre y cuando tengan unas condiciones establecidas y puedan tener un margen de asequibilidad. Para la obtención de la información, sus fuentes pueden ser externas o internas, a su vez éstas pueden estar o no vinculadas a la rama de la empresa en específico o por la misma transaccionalidad de los eventos. Para la consolidación, la información estará almacenada, sólo para esta etapa la información que se recopila los datos relevantes dentro de un proceso profundo de recolección y selección de datos, a su vez ésta integra la información que se encuentra dispersa. Para esta etapa se requiere que la detección de información esté acorde a lo que se busca.

24

Una vez clasificada la información, empieza la utilización de herramientas para darle uso a la información captada, allí empieza una fase de clasificación más minuciosa, que permite una mayor toma de decisiones, para ello se pueden usar dos tipos de tecnologías, una de éstas son los cubos OLAP (Online Analytical Processing), es una tecnología de base de datos bidimensional, ésta organiza la información de forma jerárquica, permitiendo el manejo de la información de una forma abierta y ágil. La otra herramienta tecnológica es mediante minería de datos, ésta permite extraer y realizar un análisis matemático y estadístico mediante la elaboración de algoritmos que permiten mostrar eventos incluso que arrojen detalles que no se esperan de forma inmediata o que no se conciben dentro de una perspectiva normal. Finalmente para la etapa de visualización la compilación de los resultados se debe de dar de forma asequible, en forma de tablas o imágenes que brinde una asequibilidad a la interpretación y que sea legible para su entendimiento.

8.6. Cadena lógica de negocio (CLN) La CLN o cadena lógica de negocio del sistema CLNS3 descrito en [17], es un modelo que se concibe a través de un diagrama de procesos que sirve para entender qué necesidades tiene un cliente específico basado en una lógica. Esta cadena es complementaria al diseño de bases de datos convencional ya que mediante ésta se plantea el modelo lógico por el cual se busca satisfacer la necesidad propia del cliente, los requerimientos que éste plantea y finalmente cómo organizar el SGBD para el manejo de transacciones, a su vez está basada en la teoría de diseño por dependencias funcionales. De acuerdo con [17], para entender la CLN se deben tener en cuenta dos elementos claves para su ejecución que llamaremos entidades:

- Sujeto: Para quien se diseña y quien controla la aplicación. Siendo en este caso el Stakeholder4.

- Grupo transaccional: Que es el instrumento o aplicación que se controla.

Estos dos componentes son los que definen una relación la cual establece la funcionalidad y la sinergia entre usuario – aplicación. Esta «lógica de funcionalidad» establece cual es el grado de dependencia que existe entre ambas partes. Pero para definir esta relación, la cardinalidad que se da entre una entidad y otra, en este caso las entidades son el Sujeto y el Grupo transaccional siempre se dará de 1 – n, la razón está en que un sujeto tiende a manejar varios grupos transaccionales a nivel general sin importar si es uno o varios grupos transaccionales descartando la prioridad si es un proceso unitario o de varios procesos haciéndolo de forma genérica. [17]

3 Autor: John Jairo Londoño.

4 “Stakeholder es un término inglés utilizado por primera vez por R. E. Freeman en su obra: «Strategic Management:

A Stakeholder Approach», para referirse a «quienes pueden afectar o son afectados por las actividades de una empresa».” [35].

25

En el sentido contrario la cardinalidad entre un Grupo transaccional y un Sujeto, marca el grado de «dependencia funcional”» [17], y la multiplicidad de ésta se da por la correspondencia de las transacciones y a quien va dirigida. En este sentido una transacción es un intercambio de bienes, fondos y servicios entre entidades. La multiplicidad de éstas se basa en una relación de exclusividad, esta relación de exclusividad depende del sujeto, el cual define si estas transacciones corresponden o no a uno o varios sujetos. Si es exclusiva, es que corresponde a un solo sujeto. En caso contrario cuando son muchos, no existe exclusividad (Figura 4).

Figura 4 Esquema básico de la cadena lógica de negocio monofuncional, sin dependencia funcional. Basado en [17]

La dependencia funcional no contempla la multiplicidad n – n por la razón que en esta transacción no están involucrados varios grupos transaccionales que hacen de participantes de forma simultánea, ya que un sujeto o varios sujetos, no requieren que varios grupos transaccionales del mismo tipo generen transacciones a uno o varios sujetos de forma recíproca. Dado que este concepto es el paso previo antes de definir el modelo entidad – relación y el modelo relacional, es menester mencionar que este modelo afecta los modelos y las relaciones de cardinalidad y multiplicidad de las entidades que estarán involucradas, además de la normalización, ya que al existir dependencias funcionales, se requiere de un tratamiento especial a las tablas emergentes. La clasificación de la cadena lógica de negocio se gesta en las interacciones con los grupos transaccionales, eventualmente como puede haber un sujeto relacionado con un solo grupo transaccional, puede hacerlo con varios, pero pueden igualmente los grupos transaccionales tener más subgrupos y así sucesivamente. La clasificación basado en [17] se da de cuatro formas (Figura 5):

1) Monofuncional simple: Es aquella cadena, cuyo sujeto esta enlazado únicamente con una sola línea de negocio, es decir la cadena puede ir enlazada solamente a un grupo transaccional.

2) Monofuncional compuesto: Es aquel que adicional al enlace Sujeto –

Grupo transaccional, este grupo transaccional tiene más subgrupos transaccionales que se van enlazando con más subgrupos de forma jerárquica. Esto en una sola línea que esté enlazada a un solo sujeto.

3) Bifuncional o multifuncional simple: Contrastando al anterior, cuando

hay dos o más grupos transaccionales que dependen de un mismo sujeto, a estos se le llaman cadenas bi- multifuncionales, pero estos no tienen más subgrupos transaccionales. Estas líneas de negocio, no

26

están enlazadas directamente, sino bajo el patrón de la inteligencia de negocio.

4) Bifuncional o multifuncional compuesta: Semejante al monofuncional, es

aquella cadena cuyos grupos transaccionales tienen uno o más subgrupos transaccionales.

Figura 5 Ejemplo de una CLN bifuncional compuesta. Dos bloques de grupos transaccionales están enlazados a un mismo sujeto, mas no están relacionadas entre sí. Se muestran los grados de dependencia funcional. Basado en

[17]

8.7. Dependencia funcional (DF) La DF [17] es un tipo de generalización del concepto de una clave. Esta limita el grado de relación basado en un vínculo entre el grupo transaccional y el sujeto, el concepto de exclusividad se basa en cuantos sujetos afecta el grupo transaccional. Si es de uno a uno, existe la dependencia funcional exclusiva, mientras que si afecta a varios, seria no exclusiva. (Figura 6)

Figura 6 Ejemplo de una CLN monofuncional simple. La multiplicidad del grupo transaccional es de 1-* , se asienta

en el concepto que dicho grupo afecta a varios sujetos. Basado en [17].

8.7.1. Propiedades ACID (Atomicity, Consistency, Isolation, Durability: Atomicidad, Consistencia, Aislamiento, Durabilidad)

27

Atomicidad: Esta propiedad es la que garantiza que haya una invariancia en los datos ante cualquier evento. Haciendo que el dato permanezca sin pérdidas o modificaciones. Haciendo que no surtan cambios durante un paso a otro y que no hayan procesos intermedios. En caso tal que un dato sufra algún cambio, éste será definitivo. Es decir deben ejecutarse todas las operaciones no hacerse ninguna [18], [19]

Consistencia o integridad: Esta propiedad asegura una serie de restricciones

que aseguran que los datos se ajusten a unas reglas establecidas que se ajusten al negocio (ver Cadena Lógica de Negocio) garantizando coherencia e integridad sobre los datos que se manejan, buscando reducir la redundancia que hace que existan inconsistencias al tener dos valores o más haciendo que no haya una concordancia. Ésta hará también que sobre estos datos hayan las conversiones necesarias para que haya un resultado final que en lo posible haga que los datos queden exentos de errores. [18], [19].

Aislamiento o independencia: Esta propiedad garantiza que los datos al estar

“libres” o sin una mayor conexión excepto para una cierta manipulación. Puedan mantenerse íntegras y sin cambios. Es decir que al adoptar nuevos estándares o que se presenten a nivel físico o lógico. Mantengan una consistencia tal que no surtan efecto al momento de acomodar los registros y no haya pérdida o alteración del mismo. Esto con el fin de evitar que la dependencia de datos se mantenga sumamente cohesionada, propiciando cambios y generando pérdidas en el momento de generar algún cambio o de sufrir de alguna alteración ya sea de tipo físico, sea en el caso de modificar la forma de acceso o su representación física. Es decir, no debe haber interferencia de cada ejecución de cada proceso en concurrencia. [18], [19]

Durabilidad o persistencia: Al ser las bases de datos compartidas, éstas

mantienen su integridad, y a su vez esta compartición hace que también se busque una persistencia, garantizando la supervivencia de las mismas hasta que surja algún otro cambio. Esta persistencia tiene una durabilidad hasta cuando las condiciones de compartición cambien, esto con el fin de garantizar la integridad y que los cambios realizados no se pierdan aun con eventos anormales como fallos.

8.8. Modelo entidad – relación

El paso siguiente al diseño de la cadena lógica de negocios y el modelo por dependencias funcionales, es la implementación del modelo entidad – relación [17]. El cual parte de una noción de una percepción del mundo real, basándose en un modelo de datos. Anteriormente se usaba únicamente el esquema de dependencias funcionales con el fin de garantizar el pleno funcionamiento del diseño basado en las recomendaciones que sugería el modelo; sin embargo la garantía de normalidad no se daba plenamente, dando lugar a que se optimice el diseño mediante refinamiento y optimización. Para ello se cuenta con una herramienta grafica complementaria la cual involucra una entidad la cual viene siendo la representación gráfica de una

28

serie de entidades o tablas que se encuentran enlazadas entre sí mediante un esquema de relación, esta relación se encuentra determinada por las llaves de la tabla, primaria y foránea. Éstas dan lugar a una clasificación de las relaciones entre relaciones fuertes y débiles; el grado de dependencia es la que da finalmente la estructuralidad para definir las entidades fuertes y débiles. Para la implementación del modelo entidad- relación se tienen en cuenta estos aspectos. (Figura 7).

Figura 7 Componentes Modelo Entidad – Relación, basado en [17]

Una vez se tengan diseñados los componentes y definidas las entidades y las relaciones se tiene este esquema: (Figura 8).

Figura 8 Esquema modelo Entidad – Relación, basado en [17]

8.9. Modelo relacional

Una vez se tiene el diseño del modelo entidad relación basado en [17], el siguiente paso es establecer el diseño físico de implementación de la tabla que se alinea con el modelo por dependencias funcionales y el de entidad - relación, una vez obtenido esto se podrán efectuar operaciones de borrado, inserción, lectura y grabación de documentos. Esto conlleva a un esquema donde el planteamiento del diseño hace énfasis al posicionamiento de las entidades previamente colocadas, su grado de dependencia

Atributo (Variable)

Entidad (Representando una tabla)

Relación (Siempre de derecha a izquierda con el sentido de 1 a muchos)

29

funcional, así como de los grupos transaccionales y los sujetos, haciendo que su ubicación dependa de esos aspectos. Igualmente la relación de los primary key y los foreign key hacen que también el diseño del esquema les dé una orientación a la izquierda o a la derecha del modelo. Cada tabla ingresa también con sus respectivos atributos y su esquema para todas las tablas se da bajo el siguiente esquema (Figura 9):

Figura 9 Componentes estándar del Modelo relacional. Basado en [17]

La notación de cada una de las relaciones las cuales son las flechas que se señalan en el esquema, se tienen en cuenta que tipo de relación se da, éstas se indican - previamente en el modelo entidad – relación como relaciones fuertes y débiles, las fuertes son aquellas que tienen una relación entre la llave primaria de una entidad, con una entidad llamada fuerte ya que poseen una dualidad de llave primaria y de llave foránea, las débiles solo tienen una relación entre llave foránea y llave primaria de forma convencional. Se señalan de la siguiente forma según (Figura 10) [17]:

Figura 10 Tipos de relaciones: Fuertes donde hay relación FK-PK con una PK, débil donde hay una relación FK-PK.

Basado en [17].

8.10. Modelo - vista - controlador Creada por Trygve Reenskaug en 1979, es un patrón de arquitectura que permite separar la lógica, de la parte de los datos y de la vista. Estas tres divisiones tienen ciertas particularidades. De acuerdo con [20] el planteamiento del modelo a tres capas se da de esta forma:

30

Modelo: Es aquella interfaz que maneja las transacciones que vienen del modelo para enviarlo directamente al SGBD, y este le devuelve una respuesta si está permitida o no la operación o si la interacción cumple con los parámetros. Su salida será hacia el modelo cuya función será de interpretar dichas salidas para pasarlas a la vista.

Vista: Es la interfaz gráfica y de interacción del usuario con la máquina.

Controlador: Representa los datos, es aquella que describe el problema y recae básicamente la lógica de la aplicación, toma los datos del usuario que se ingresaron a la vista, y la información la envía al controlador para su interacción con la BD, igualmente captura su salida para enviarla a la vista en modo de respuesta a la acción del usuario.

Su funcionamiento se da de la siguiente forma:

1) El usuario hace una acción y envía una transacción mediante una petición. 2) El controlador captura la transacción y llama al controlador tomando la

petición del usuario haciendo la verificación concerniente, haciendo las validaciones correspondientes y rechazando las operaciones no permitidas, devolviendo la respuesta a la vista.

3) El modelo será quien interactúa con el SIBD, y quien tomará las transacciones para retornarlas al modelo. Allí verificará si la operación pedida puede darse, y dependerá de la estructura de la base de datos para obtener una respuesta y mostrar una información, sea una consulta o un procedimiento, una vez obtenido el resultado retornará al modelo.

4) El controlador procesa la información recibida, procesa la información y retorna la respuesta a la vista.

5) La vista capturará las interacciones de vuelta y mostrará la información esperada e igualmente mostrará el resultado de la ejecución dada.

Figura 11 Esquema Modelo - vista – controlador de acuerdo con [20]

8.11. Arquitectura Cliente – Servidor

31

Al buscar flexibilidad y que un programa gestione un recurso compartido, se debe repartir las funciones cuyas limitantes las da el entorno, en este caso es el usuario quien al tener un contacto con el entorno del cliente, éste último pide a un entorno que gestiona un recurso definido que es compartido, es allí cuando el cliente le pide al programa una función específica y que el servidor sea quien gestione ese recurso para ser devuelto al cliente o a los clientes para que accedan al recurso y puedan mostrarlos al cliente. [21], [22]

Figura 12 Modelo Cliente –Servidor basado en [22].

8.12. PHP

Es un lenguaje de programación orientado a web, es el acrónimo de Hypertext Preprocessor, que puede incluirse en aplicaciones de alto nivel y se integra con otros lenguajes como CSS3, y HTML de modo que este último se utiliza de forma incrustada del lado del cliente al ser ejecutado generando un script en HTML, éste también puede utilizar Javascript con sus elementos Ajax y JQuery del lado del cliente [23]. Al no tener un servidor, se puede utilizar tanto en los servidores Apache, como IIS, en este caso se usará el Apache para ser usado como servidor debido a que se enlazará con el motor de bases de datos MySQL como se explicará a continuación.

8.13. Cambios en el desarrollo.

8.13.1. Entorno de desarrollo

Se planteó para el desarrollo del proyecto un entorno donde se involucraran un lenguaje y un motor de BD particular para el diseño en el proyecto donde se buscara la relación entre un lenguaje libre y un paquete de desarrollo privativo donde

32

permitiera el diseño del lenguaje en un motor de BD como SQL Server con el fin de mostrar la integración de un lenguaje de programación y la versatilidad en cualquier entorno permitiendo la integración parcial o total y donde pudieran llevarse a cabo todas las operaciones y se hicieran los procesos de consulta. Inicialmente se tuvieron en cuenta los pros y los contras especialmente tratándose que PHP normalmente viene integrado a entornos de desarrollo libre en especial LAMP se buscó la integración con un entorno privativo al utilizar servido IIS y un motor SQL Server. Los pros venían de probar el modo en que se podrían integrar un lenguaje diferente a .NET y permitiera explotar las virtudes del SQL Server como un motor de BD versátil y que permitía realizar consultas de forma eficiente, además el manejo y la optimización de tablas son puntos fundamentales. Igualmente está el aspecto de la instalación que si bien demandaba un tiempo considerable, frente a otros motores implicaba una instalación más segura. También es importante destacar que IIS al venir integrado con el sistema operativo Windows podría ser configurado de una forma efectiva y al tener una alternativa como ODBC para hacer el enlace a la BD con el lenguaje o el estandarizado PDO cuya librería es relativamente sencilla de integrar podría tenerse un entorno de desarrollo que permitía la interacción del lenguaje y sus componentes. Los contras aparecen en los momentos de ser integrados, ya el aspecto del tiempo para implementar un diseño robusto que si bien es funcional no convenía para la implementación, debía hacerse simple y donde se involucraran los menores procesos posibles, esto se hace importante cuando al momento de implementarse se buscan optimizar procesos y no alargarlos. Si bien inicialmente se buscaba un desarrollo más orientado a programación pura en donde se involucran más aspectos de control y se pretende hacer un diseño más personalizado de la implementación de las clases y hacer los llamados a los objetos de una forma más controlada además de tener un mejor radio de acción e incluso un mayor control en cuanto, aspectos como conexión, validación e instanciación hacen que haya un trabajo más dilatado teniendo en cuenta los tiempos limitados; además si bien PHP cuenta con la librería PDO_SQLSRV el cual ofrece un controlador actualizado y se integra bien con el motor de BD inconvenientes en la integración del IIS así como en la conexión, aspectos en la validación, instanciación y el tiempo para solventar estos inconvenientes hace que la adaptabilidad y versatilidad se vea limitada frente a la fácil adaptabilidad de un desarrollo en un entorno PHP – Apache y MySQL. La búsqueda de encontrar un método eficaz de desarrollo cuidando aspectos como seguridad, accesibilidad, además de un diseño pensado en integrar el modelo - vista controlador, cuidando también la seguridad integrando un estándar de implementación y enfocándose más en la concepción del diseño y en las funcionalidades propias de la aplicación se hizo necesario utilizar el framework CakePHP. Para usar este servidor es necesario utilizarse el motor de base de datos MySQL y el servidor Apache, todos para ser utilizador como diseñador de plataformas basado en el modelo 3 capas. El otro aspecto importante radica en la practicidad y adaptabilidad de un entorno PHP con su motor de BD incluido, esto aunque implica en Windows un conflicto en la configuración, las prestaciones que ofrece en el desarrollo en cuanto a

33

adaptabilidad son importantes, sin mencionar el hecho que en cuanto a costos éste no tiene inconvenientes en cuanto a temas de licenciamiento, de ampliación de actualizaciones o de funcionalidades especiales. Igualmente sus controladores son fácilmente actualizables y su servidor ofrece mayores opciones de desarrollo al tener un código libre. Este aspecto de licenciamiento es fundamental ya que la implementación tendría un impacto en el costo de la aplicación aun si ésta se encuentra implementada en SQL Server Express el cual no implica un costo muy elevado el mantenimiento implica una inversión que no era viable teniendo en cuenta el tamaño del proyecto a nivel local e implicaba una inversión que no es viable tratándose de lo l

8.13.2. Apache

Es un servidor más difundido del mundo, siendo una aplicación de software libre es desarrollado y mantenido por Apache Software Foundation el cual brinda soporte a proyectos principalmente orientados a software libre aunque también brinda soporte a aplicaciones protegidas, su fin es mantener abierto el desarrollo de proyectos en servidores HTTP y mantenerse extensibles para poder ser desarrollados y puedan ser ampliamente manejables por mucho tiempo, este manejado por estándares HTTP. [24]

8.13.3. MySQL El motor de BD My SQL es un gestor de BD cuyo propósito inicial se basó en manejar pequeñas bases de datos o en organizaciones a una escala pequeña debido a su practicidad, siendo un motor relacional tiende a tener una gran adaptabilidad en un entorno de red especialmente en el cliente servidor, su fin fue establecer un sistema gestor de bases de datos abiertos para que pueda permitir desarrollar a una mayor amplitud, además tiene un licenciamiento Open Source cuyo código abierto puede ser accedido y modificable es licenciado por GPL, además que soporta muchas API. [25]

8.13.4. CakePHP El CakePHP es un framework cuyo fin es la optimización del desarrollo en un modelo a tres capas donde se busca un lenguaje más natural y una aproximación más certera al diseño que a la configuración, este framework permite la optimización y la preparación de la aplicación tomando en cuenta el modelo de negocio, el diseño y la optimización de la vista y el controlador cuya capa recae toda la funcionalidad del diseño, invocando al modelo y haciendo la interacción con la vista.

34

9. METODOLOGÍA

9.1. Implementación de UML Para la obtención de los requisitos y se orienten hacia lo que quiere el usuario, se requiere un enfoque mediante un lenguaje en común, en este caso se requiere UML, el cual permite diseñar una notación que abarque aspectos de funcionamiento del sistema para su implementación. De acuerdo con [14] para el desarrollo mediante la notación UML se tienen en cuenta tres aspectos donde está incluido el diagrama de casos de uso para la construcción del sistema, tomando en cuenta el aspecto del análisis, la funcionalidad, los tiempos de entrega y el enfoque de hacia dónde va dirigido el sistema. Por eso el desarrollo se enfoca en tres modelos que sirven desde el análisis a la implementación e interacción con el usuario final, mediante una serie de diagramas, éstos son:

Modelo funcional: Este se representa mediante los diagramas de casos de uso, definen el sistema desde el punto de vista del usuario, mas que el diagrama, es la documentación que se tiene para la concepción del negocio, para ello se requiere conocer bien sus necesidades y expectativas limitando el alcance del sistema; la obtención de lo que desea el usuario se hace mediante el levantamiento de requerimientos, los cuales definen que elementos son relevantes y no relevantes del sistema, así como que elementos son y no funcionales, finalmente que elementos no son requerimientos.

Modelado de objetos: Se representa mediante diagramas de clase y de objetos describiendo la estructura de la aplicación viéndose desde el paradigma orientado a objetos. Allí se definen las clases, los objetos, los atributos, las asociaciones y operaciones. Este análisis viene precedido por los casos de uso que definen las clases y métodos desde las extensiones e inclusiones, además de las interacciones entre clases, éso está complementado con el diagrama de actividades.

Modelamiento dinámico: Se representa mediante diagramas de secuencia, diagramas de grafica de estado y diagramas de actividad. Describe el comportamiento interno del sistema. Parte desde el diagrama de secuencia el cual describe el comportamiento mediante mensajes intercambiados entre objetos. Los diagramas de estado describen las transiciones desde una óptica de estados de un objeto individual, así como las transiciones entre estados. Mientras el de actividades define el comportamiento de los casos de uso, los objetos y las interacciones.

35

Igualmente están los diagramas de colaboración que modelan las interacciones entre objetos, el diagrama de componentes que modela a los componentes y el de implementación que modela como quedará el sistema.

9.2. Modelo funcional

9.2.1. Levantamiento de requerimientos

El objetivo de este proyecto es desarrollar un prototipo de aplicación web cuyo fin es soportar la gestión documental e igualmente facilitar el proceso de capacitación dirigido a la enseñanza de idiomas, dichas capacitaciones deben estar dirigidas y gestionadas por un administrador el cual garantizará que todos tengan un acceso manteniendo los protocolos de seguridad y brindando información oportuna para su aprendizaje. También se encargará de la gestión de documentación y marcará los límites de la accesibilidad garantizando que el usuario al presentar sus pruebas, sólo podrá acceder a la información determinada. Si bien introduce ayudas visuales complementarios igual que videos y audios, ésta no se enfocará en este ítem, como tampoco desarrolla ni implementa un sistema de colaboración profundo donde haya interacción vía web con el profesor por sí solo, mientras que la sección de video si está disponible el material, sólo se podrán proyectar si está colgado en la plataforma YouTube si éste está disponible de ser posible. Esta aplicación tampoco profundizará en satisfacer totalmente los procesos de negocio, tampoco se especializará en desarrollos amplios orientados a niños exclusivamente y un riguroso aporte didáctico ya que estará limitado solo a la parte de los documentos. Esta se dejará para un aporte futuro como también la especialización de contenidos personalizados soportados en Web 3.0. También tiene aspectos de soporte base a la enseñanza, tales como talleres, videos, audios y demás orientado a varios idiomas. Esta aplicación no contiene inicialmente manejos profundos en cuanto a la preparación de los exámenes de evaluación basados en la escala europea o preparación al IETLS, TOEFL, TestDAF o ZertifikatDeutsch, salvo que pueda introducirse elementos de descarga o de capacitación personalizada que puedan ser soportadas para una introducción a la preparación de dichos exámenes. Igualmente los talleres a realizar tendrán un alcance mínimo ya que no contaran con un exhaustivo seguimiento de notas, salvo que se puedan realizar y que el mismo alumno pueda medir sus avances a la par que el tutor podrá seguir su evolución siguiendo unos lineamientos. Inicialmente se planteó que no se introducían notas; sin embargo, debido a la necesidad de soportar la interacción entre usuario y tutor se deja una nota con una respectiva anotación. Los talleres estarán limitados a aspectos de ortografía, gramática y algunos elementos visuales para memorización de palabras, el servicio de diccionario conjugadores se incluirán aunque solo para consulta; los traductores, así como ejercicios de audio, ejercicios de estilos, dictados, correctores manuales, ejercicios de habla y de captación de sonidos para captar palabras o ejercicios de pronunciación y de pequeñas charlas, no se incluirán. Ésto para ambas plataformas, sólo se tendrá un pequeño diccionario incorporado y podrá modificarse a medida

36

que avanza la temática y estará disponible de forma libre, sólo tendrán modificaciones, si en la plataforma privativa lo requiere. Esta aplicación está disponible únicamente en el idioma español, aunque puede contener a futuro ítems relacionados en diferentes idiomas. No contiene wikis, foros, chat etc. Sólo se dejará aquella información relevante para el aprovechamiento y sus respectivos formatos para tener de guía en una consulta futura. Tampoco se incluyen servicios de almacenamiento de tareas, es decir no se subirán archivos de particulares o habrá talleres para subir tareas.

9.3. Alcance del sistema Se implementa la gestión de archivos para los documentos de consulta. Igualmente se añadirá una función para realizar ejercicios y medir el avance cualitativamente ya que será una evaluación autónoma; sin embargo, no tendrá un impacto en una evaluación ya que el reporte sólo mostrará la nota, indicando un apunte por parte del tutor, pero cuyo seguimiento sólo se hará de forma externa.

9.3.1. Seguridad y accesibilidad: Se buscará que el usuario administrador tenga los derechos y privilegios, para gestionar permisos, y dichos permisos se puedan dar bajo ciertos parámetros como la de accesibilidad, modificación, visibilidad etc. asegurando la integridad de los archivos y prevenir cambios. Igualmente el estudiante, en este caso quien desea tomar las capacitaciones, también tendrá un usuario y una contraseña cuando éste pueda matricularse a la plataforma, podrá acceder a ciertos módulos de capacitación bajo condiciones establecidas, En caso que desee otro tipo de documentación estándar, de información general e incluso de descargar información que sirva de soporte, tendrá una plataforma libre para poder realizar sus consultas sin ninguna restricción e incluso se abonará unos documentos guía estandarizados para su consulta. En caso que sea un guía-tutor, el podrá establecer las condiciones ya dentro de la plataforma que el mantendrá actualizada la biblioteca, agregando, eliminando o modificando los archivos y eventualmente modificar los quices si es menester hacerlos.

9.3.2. Esquemas y formato estandarizado

El esquema que se manejará tendrá una interfaz definida, manejando un estándar para todos los usuarios. Igualmente la búsqueda será abierta y accedida por cualquier persona que desee ingresar, puedan acceder a la información, segmentando el contenido preferencial del contenido general siendo el contenido

37

preferencial el que tiende unas restricciones establecidas según lo que se pretenda evaluar o enseñar.

9.3.3. Gestión de contenido Los contenidos están habilitados de forma permanente, sólo hasta cuando el administrador crea conveniente su mantención dentro de la aplicación. Una vez cumplido un tiempo establecido, dicha información desaparecerá, igualmente el versionamiento dará la pauta. Sólo quedará aquella información relevante, o en su defecto se modificará, además de información de carácter preferencial que quedará bajo custodia del administrador y de las partes interesadas. Estos contenidos también se encuentran enmarcados dentro de un contexto de relevancia, si es de importancia a nivel general o a nivel particular. Con el fin de evitar una saturación o en su defecto un manejo indiscriminado de los documentos dando lugar a equívocos y a una mala manipulación. Estos contenidos y documentación serán gratuitos en la medida que se referencie al autor, y se reconozca el derecho de los mismos. Salvo casos donde el autor exprese su intención de limitar su difusión a un plano privado y de restricciones por derechos de autor. En caso de información exclusiva se limitará al entorno donde vaya a ser usado y no se podrá compartir libremente debido a condiciones contractuales.

9.3.4. Gestión de búsqueda

Mediante una lista de tags o palabras definidas por defecto, éstas servirán de guías, también palabras claves que servirán de referencia en la búsqueda. Aunque esta opción solo se reservara a una lista definida. Igualmente la búsqueda se restringirá al aspecto que se desea consultar. La consulta bien podría servir también para búsqueda de palabras y sus significados en el diccionario.

9.3.5. Generación de cuestionarios y talleres Los cuestionarios y talleres son creados de acuerdo con las condiciones de los tutores, éstos podrán adaptarse a un tema establecido y a una plantilla dada, en caso de las secciones exclusivas si hay alguna adición especial, tendrán limitaciones en cuanto a la adición de elementos gráficos complejos o de elementos interactivos que requieran una considerable carga didáctica, dado que el propósito inicial es el acercamiento del aprendiz a la aplicación y gran parte de estos talleres especializados estarán contenidos y documentos a descargar. Igualmente estas plantillas están sujetas a discusión según la situación que se presente. Estarán únicamente disponibles para ejercicios de ortografía, gramática y eventualmente tendrá juegos visuales, sólo se modificará para los cursos privados y tendrá una mayor profundidad para los alumnos con privilegios; sin embargo los talleres tendrán en la medida de lo posible accesibilidad para todos.

9.4. Limitaciones

9.4.1 Restricciones y suposiciones

38

Los parámetros de modificación, escritura, lectura, acceso y eliminación, se limitan al grado de participación de los miembros, igualmente en el acceso de los datos de los usuarios, la visibilidad de los mismos, esto en el caso de miembros diferentes a los administradores

No se integra con ningún servicio de e-mail, wikis, chat, descarga de videos, video llamadas o de grabación de sonidos. Tan solo se podrá crear una zona de comentarios en zonas forales.

Las limitaciones de tiempo harán que las aplicaciones sean lo más prácticas posibles sin extenderse ni volver más robusta la aplicación de lo necesario. Solo se dejará abierta a futuras implementaciones.

No habrán componentes adicionales particulares, más allá de las características antes mencionadas.

No se integrarán procesos que no se tengan contemplados dentro de la lógica inicial del negocio, ni se implementarán funciones que no están definidas plenamente para evitar desavenencias.

No se implementaran manejo de plantillas en línea. Aunque por la metodología de inteligencia de negocio se tenga en cuenta la

una sección de videos como soporte para la enseñanza, sólo podrán ser importados desde plataformas como Youtube, y aún tendrán ciertas restricciones según el tipo de usuario, igualmente la aplicación no almacenará videos y el tamaño de los archivos de audio estará limitado, tan solo podrá almacenarse archivos .mp3, .wav u ogg.

Se manejará un estándar evitando que en el caso de los administradores no se tengan peticiones o privilegios extras a los ya establecidos.

La información allí depositada sólo podrá consultarse libremente, salvo las de contenido exclusivo que serán únicamente mediante permisos y de difusión limitada.

La limitación del tiempo hará que se deban hacer correcciones especialmente en la fase de implementación, con el fin de presentar a tiempo las mejoras.

Igualmente la limitante tecnológica implica una barrera a la implementación, dado los inconvenientes que se han presentado inicialmente en la implementación de la aplicación usándose el entorno PHO, SQL Server y el servidor IIS, se optó por modificarse al entorno PHP, MySQL, Apache. Tomandose en cuenta inconvenientes en la implementación del entorno y las limitaciones en el tiempo.

No se extiende a aplicaciones móviles. No se incluyen talleres de audio ni se implementarán extensiones para

grabación de voz o de video. No habrá seguimiento de notas o de almacenamiento de datos de

estudiantes salvo que haya un diseño particular de los tutores y ésta será independiente de la aplicación, sólo contará con una medición de los procesos. Allí los estudiantes podrán revisar su evolución basándose únicamente en las notas que le ofrece la aplicación de forma temporal. No tendrá un efecto limitante, salvo que se retome otra vez el quiz si el estudiante desea hacerlo.

No habrán secciones para que el estudiante suba tareas o archivos para enviar.

39

9.5. Metodología RUP

De acuerdo con [26] Basado en UML, el RUP se desarrolló como una metodología de desarrollo ágil tomando como base al UML, pero con mejoras en cuanto a optimización del tiempo incluso bien puede prescindir del UML; sin embargo la posibilidad de darse el desarrollo de forma simbiótica es alta, debido a que RUP puede verse como la ejecución del proyecto, mientras que UML se ve como la parte del diseño complementario al proceso que se va desarrollando. Iniciando por los casos de uso cuya función es de describir los bloques de funcionamiento del proceso cuya dinámica se ve complementada con los diagramas de secuencia, de comunicación y de estado, donde se agrega un dinamismo propio que en UML por sí solo no se encuentra, y que por el contrario ayuda al refinamiento de la metodología útil. Con la inclusión de los objetos las vistas del desarrollo de arquitectura, las llamadas vistas 4+1, se complementan agregando el aspecto “racional” que debe su nombre, y ésta a su vez se complementa a las 4 vistas mencionadas, la lógica, el proceso, la física y el desarrollo. La metodología RUP es de ciclo de vida incremental, cada bloque iniciando desde los casos de uso se van a complementarse únicamente cuando cada proceso haya sido completado, así mismo pueden subdividirse en varios subprocesos y cada uno debe ser sinérgico cosa que complete una entrega parcial sólo hasta cuando esté concluido, de ahí deriva que sea una metodología de tipo iterativa. La búsqueda de la subdivisión del proceso en varios subprocesos, obedece a la razón que debe medirse la eficiencia para evitar que hayan entregas muy posteriores, que se vayan atacando varios frentes pero darle prioridad a algunos que requieran una mayor complejidad o que en su defecto puedan ser menos prioritarias pero puedan ser necesarias y ser bastantes para después enlazarse con los procesos más densos, ésto dependiendo de las exigencias del desarrollo. El ciclo de desarrollo de acuerdo con [26] se dividen en:

Inicio. Objetivo de la elaboración. Construcción Transición.

Igualmente de acuerdo con [26] cada fase está detallada por un conjunto de actividades:

- Modelado procesos de negocio. - Gestión de los requerimientos. - Análisis y diseño. - Implantación. - Pruebas. Despliegue.-

40

Figura 13 Ciclo de desarrollo de RUP de acuerdo con [26]

De acuerdo con [27] esta metodología se basa en módulos que evalúan todos los recursos disponibles para medir su rendimiento separándolos en quien diseña el esquema, que es el esquema que esperan armar y como lo ejecutan repartidos así:

- Roles: Evalúa quien desempeña el conjunto de habilidades y competencias correspondientes a una tarea en específico.

- Productos del trabajo: Que es el resultado de la tarea que se ejecutó. - Tarea: Es la función que se asigna a cada rol y en él se analiza cómo se

debe ejecutar. Según [28] este esquema se maneja en un patrón de dos dimensiones, donde el eje X se hace el ciclo de desarrollo, mientras que en el eje Y se van llevando el conjunto de actividades y cada uno se ejecuta en una iteración establecida según el avance que esté presente.

Figura 14 Esquema de dos dimensiones del RUP consultado en [28]

Inicio Objetivo

elaboración Construcción Trancisión

41

9.6. Requerimientos Habiéndose planteado los objetivos y los lineamientos de la aplicación, se plantean los requerimientos los cuales son tomados en cuenta para desplegar cuáles son los puntos más importantes donde se identifica la ejecución del desarrollo. Para estos aspectos se tomaron en cuenta los aspectos más relevantes que pueden ser tenidos en cuenta dentro del desarrollo, tales como el CRUD, dónde se pueden ver reflejados y cómo afecta a los actores y las principales acciones y en general los aspectos más relevantes de la aplicación para ser ejecutados.

9.6.1. Requerimiento de aplicación de enseñanza Número del

Requerimiento

RF 1.1

Nombre del

Requerimiento

Inicio de la aplicación web

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción Se debe diseñar una aplicación web que pueda conectarse desde

cualquier equipo, terminal o de escritorio desde cualquier punto.

Número del

Requerimiento

RF 1.2

Nombre del

Requerimiento

Visibilidad a cualquier usuario

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción La aplicación debe ser abierta para ser consultada por cualquier

persona y debe mostrar información relevante para ser

consultada.

Número del

Requerimiento

RF 1.3

Nombre del

Requerimiento

El sistema debe alertar cuando se vence el tiempo del registro.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción La aplicación debe indicar cuando el estudiante debe renovar su

permanencia como estudiante activo.

Número del

Requerimiento

RF 1.4

Nombre del

Requerimiento

El sistema debe indicar un registro de tutores y de estudiantes

Tipo __ Restricción X Requisito

42

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción La aplicación debe indicar donde se pueden inscribir tutores y

estudiantes y el tiempo de registro.

Número del

Requerimiento

RF 1.5

Nombre del

Requerimiento

La aplicación tendrá un diccionario de consulta de palabras

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción La aplicación debe tener un diccionario para consultar palabras y

su significado.

Número del

Requerimiento

RF 1.6

Nombre del

Requerimiento

La aplicación permitirá organizar la documentación de acuerdo al

idioma.

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción La aplicación enlistará los documentos en bloques documentales

y en cursos y de acuerdo al idioma de enseñanza.

9.6.2. Requerimiento del administrador y del tutor de la aplicación

Número del

Requerimiento

RF 2.1

Nombre del

Requerimiento

El administrador del sistema visualizará los estudiantes que están

registrados para recibir material particular.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador del sistema debe ver cuales estudiantes están

activos o no, para otorgar permisos de acceso a material

especializado.

Número del Requerimiento RF 2.2

Nombre del Requerimiento El administrador del sistema registrará tutores nuevos

Tipo

__ Restricción

X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador del sistema puede crear nuevos usuarios en el

sistema para que puedan acceder a la consulta de

documentación especializada.

Número del

Requerimiento

RF 2.3

Nombre del El administrador del sistema modificará información de los tutores

43

Requerimiento

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador del sistema puede modificar los datos de un

empleado que esté activo.

Número del

Requerimiento

RF 2.4

Nombre del

Requerimiento

El administrador del sistema registrará estudiantes nuevos.

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador del sistema puede modificar los datos de un

empleado que esté activo.

Número del

Requerimiento

RF 2.5

Nombre del

Requerimiento

El administrador del sistema modificará la información de los

estudiantes.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador del sistema puede modificar los datos de un

empleado que esté activo.

Número del

Requerimiento

RF 2.6

Nombre del

Requerimiento

El administrador del sistema desactivará a los estudiantes no

acreditados para consultar documentación exclusiva.

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador del sistema puede desactivar a los estudiantes

acreditados que ya no estén matriculados para obtener

documentación de tutorías.

Número del

Requerimiento

RF 2.7

Nombre del

Requerimiento

El administrador del sistema creará cursos para asignar

documentación

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El tutor podrá registrar cursos para que los usuarios puedan entrar a

la sección documental de un tema específico.

Número del

Requerimiento

RF 2.8

Nombre del

Requerimiento

El administrador del sistema ingresará documentación.

Tipo __ Restricción X Requisito

44

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador deberá ingresar documentación general.

Número del

Requerimiento

RF 2.9

Nombre del

Requerimiento

El administrador del sistema modificará documentación

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial _ Media/Deseado __ Baja/Opcional

Descripción El administrador de cada área podrá modificar la información de la

documentación correspondiente a su área.

Número del

Requerimiento

RF 2.10

Nombre del

Requerimiento

El administrador del sistema añadirá una restricción de acceso a la

documentación de tutorías personalizadas

Tipo X Restricción __ Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador del área deberá restringir información de tutorías

personalizadas mientras no se haya registrado como tal.

Número del

Requerimiento

RF 2.11

Nombre del

Requerimiento

El administrador levanta la restricción a el acceso a documentación

personalizada

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador podrá levantar la restricción de la información

correspondiente al material personalizado una vez el estudiante se

haya registrado.

Número del

Requerimiento

RF 2.12

Nombre del

Requerimiento

El tutor no tendrá plataforma personalizada para hacer tutoriales.

Tipo X Restricción __ Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El tutor será responsable de dejar sus datos de ser necesario y

cuadrará personalmente con el estudiante su tutoría si se hará

personalizada o mediante otro medio como Skype o correo

electrónico

Número del

Requerimiento

RF 2.13

Nombre del

Requerimiento

El administrador del sistema dejará visible la información del tutor

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

45

Descripción El administrador del sistema deberá dejar una información del tutor

para ser contactado

Número del

Requerimiento

RF 2.14

Nombre del

Requerimiento

El tutor hará un seguimiento al estudiante en la plataforma únicamente

mediante las notas que le indique al alumno.

Tipo X Restricción __ Requisito

Prioridad ___ Alta/Esencial X Media/Deseado X Baja/Opcional

Descripción El tutor hará seguimiento a las notas del estudiante tomando su

evaluación que arroje el sistema al momento de hacer las pruebas.

Número del

Requerimiento

RF 2.15

Nombre del

Requerimiento

El sistema no almacenará notas parciales y sólo dejará una nota

indicando el desempeño durante el curso.

Tipo X Restricción _ Requisito

Prioridad _ Alta/Esencial X_ Media/Deseado __ Baja/Opcional

Descripción Las notas de los test tomados serán evaluados fuera de la plataforma

por parte del tutor y el estudiante.

Número del

Requerimiento

RF 2.16

Nombre del

Requerimiento

El administrador del sistema diseñará las pruebas a petición del tutor

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador de capacitación puede crear cursos, añadiendo

archivos y preguntas.

Número del

Requerimiento

RF 2.17

Nombre del

Requerimiento

El administrador del sistema borrará los documentos que queden

obsoletos o que no sean requeridos.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador de la aplicación puede eliminar documentos

obsoletos

Número del

Requerimiento

RF 2.18

Nombre del

Requerimiento

El administrador del sistema desactivará al tutor

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador de capacitación puede desactivar el acceso al tutor.

Número del RF 2.19

46

Requerimiento

Nombre del

Requerimiento

El administrador del sistema actualizará el diccionario.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El administrador de la aplicación actualizará la información del

diccionario, para ello se basa en detalles y observaciones de los

tutores.

Número del

Requerimiento

RF 2.20

Nombre del

Requerimiento

El tutor ingresará documentación.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El tutor deberá ingresar documentación correspondiente a su temática

específica.

Número del

Requerimiento

RF 2.21

Nombre del

Requerimiento

El tutor podrá modificar documentación.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El tutor podrá modificar documentación correspondiente a su temática

específica

Número del

Requerimiento

RF 2.22

Nombre del

Requerimiento

El tutor podrá eliminar documentación.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El tutor podrá eliminar documentación correspondiente a su temática

específica

9.6.3. Requerimiento de estudiantes Número del

Requerimiento

RF 3.1

Nombre del

Requerimiento

El estudiante visualizará los documentos

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El estudiante debe poder hacer una consulta de los documentos que

requiera para hacer posteriores acciones sin importar si es o no

acreditado para recibir tutorías particulares.

47

Número del

Requerimiento

RF 3.2

Nombre del

Requerimiento

El estudiante visualizará la restricción del acceso a tutorías

personalizadas.

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial __ Media/Deseado X Baja/Opcional

Descripción El estudiante podrá hacer una consulta de los cursos que querrá

tomar.

Número del

Requerimiento

RF 3.3

Nombre del

Requerimiento

El estudiante visualizará la lista de cursos que puede seleccionar.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El estudiante debe poder ver los cursos que deberá tomar y elegir

el(os) curso(s) que quiere tomar.

+ Número del

Requerimiento

RF 3.4

Nombre del

Requerimiento

El estudiante consultara las notas.

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial __ Media/Deseado X Baja/Opcional

Descripción El estudiante debe poder ver sus notas de sus ejercicios para hacer

seguimiento. No se almacenará en alguna base de datos.

Número del

Requerimiento

RF 3.5

Nombre del

Requerimiento

El estudiante podrá registrarse en el sistema.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El estudiante puede acreditarse registrándose en el sistema para

tomar tutorías personalizadas.

Número del

Requerimiento

RF 3.6

Nombre del

Requerimiento

El estudiante podrá ver quiénes serán sus tutores.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El estudiante deberá ser informado de quién es su tutor asignado con

su información para ser contactado.

Número del RF 3.7

48

Requerimiento

Nombre del

Requerimiento

La información que no sea exclusiva puede consultarse libremente

Tipo __ Restricción X Requisito

Prioridad _ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El visitante podrá consultar información en la aplicación sin ningún

costo siempre y cuando no sea documentación acreditada o exclusiva

para estudiantes.

Número del

Requerimiento

RF 3.8

Nombre del

Requerimiento

El estudiante deberá ser notificado cuando se llega el límite del

tiempo de las tutorías.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción El estudiante deberá ser notificado de cuando se expira el curso para

presentarse, antes de finalizar el mismo, con un tiempo de

anticipación.

Número del

Requerimiento

RF 3.9

Nombre del

Requerimiento

El estudiante podrá hacer descarga de documentos

Tipo __ Restricción X Requisito

Prioridad _ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El estudiante podrá hacer una descarga en el momento que quiera

siempre.

Número del

Requerimiento

RF 3.10

Nombre del

Requerimiento

El diccionario podrá consultarse libremente.

Tipo __ Restricción X Requisito

Prioridad X Alta/Esencial __ Media/Deseado __ Baja/Opcional

Descripción Cualquier usuario puede hacer uso del diccionario.

9.6.4. Requerimiento de funcionales de transacciones Número del

Requerimiento

RF 4.1

Nombre del

Requerimiento

El administrador registrará las entradas de los estudiantes

acreditados

Tipo __ Restricción X Requisito

Prioridad __ Alta/Esencial X Media/Deseado __ Baja/Opcional

Descripción El administrador almacenará registro de ingreso de los empleados a

los cursos.

9.6.5. Requerimientos no funcionales.

49

Habiendo tomado los requerimientos funcionales del sistema, se analizan los requerimientos no funcionales cuyo fin es el de preparar al sistema para ejecutarse e infiere en cuestiones de funcionamiento y desempeño de la aplicación, así como la dinámica de la operación de la aplicación y los criterios de funcionalidad del sistema y buscan controlar más la operación de la aplicación con el fin de evitar eventos nuevos y no puedan manejarse.

1. Sobre la interfaz del usuario y la funcionalidad

Identificador: RNF 1.1 Nombre: Control de tiempo de sesión

Descripción: El sistema debe permanecer abierto hasta cuando el usuario cierre sesión, sea el tutor o sea el estudiante.

Criterios de Aceptación: Sólo hasta cuando se cierre sesión o el navegador restrinja la sesión debe quedar abierta y se recordará la elección del usuario.

Identificador: RNF 1.2 Nombre: Acceso al sistema

Descripción: Para acceder al sistema se debe acceder ingresando con su identificación.

Criterios de Aceptación: Se ingresa cuando el usuario acreditado(tutor/estudiante/administrador) ingresen con un login y una contraseña. El login será el username que elija.

Identificador: RNF 1.3 Nombre: Interfaz

Descripción: Modo de mostrar la información al usuario

Criterios de Aceptación: Se debe tener una presentación bastante simple y colores sobrios pero llamativos, usando diseño responsivo y mostrando las temáticas.

2. Documentación

Identificador: RNF 2.1 Nombre: Documentación de términos y condiciones de uso

Descripción: Información acerca del uso y las condiciones de uso de la aplicación.

Criterios de Aceptación: Debe explicar los límites de la aplicación y el uso de la misma.

3. Consideraciones del software

Identificador: RNF 3.1 Nombre: Navegadores

Descripción: Soporte a navegadores

Criterios de Aceptación: Debe estar apto para usarse con cualquier navegador; sin embargo, no tendrá de momento una implementación para tablets específicamente

50

4. Consideraciones de desempeño

Identificador: RNF 4.1 Nombre: Concurrencia

Descripción: Capacidad de usuarios

Criterios de Aceptación: Debe estar acorde para ser consultado libremente por varios usuarios que pueden leerlo en cualquier momento; sin embargo, la restricción debe aplicarse para los documentos que sólo pueden ser accedidos por estudiantes acreditados.

Identificador: RNF 4.2 Nombre: Descarga de documentos

Descripción: Capacidad de descarga

Criterios de Aceptación: Los documentos para descargar libremente son limitados, la gran mayoría sólo pueden ser descargados a través de la consulta de estudiantes acreditados. Se dedicará gran parte a sección informativa relacionada con gramática y sólo habrán algunos archivos para descargar.

5. Consideraciones de seguridad

Identificador: RNF 5.1 Nombre: Seguridad

Descripción: Acceso a la información

Criterios de Aceptación: Debe de haber filtros de seguridad para la consulta y subida de documentación, igual de protegerse la información de agentes externos.

Identificador: RNF 5.2 Nombre: Seguridad de logueo

Descripción: Acceso a la plataforma.

Criterios de Aceptación: Debe validarse que el usuario acreditado es el único que puede entrar a la cuenta, sea tutor, estudiante, administrador del sistema.

Identificador: RNF 5.3 Nombre: Limitación de acceso.

Descripción: Tipos de acceso.

Criterios de Aceptación: Sólo el administrador del sistema tendrá acceso total a toda la información, para hacer cambios, el tutor sólo podrá hacer la modificación de su información y la visualización de su cuenta, mientras el usuario estudiante se limitará a consultar información acerca de su tutor y lo concerniente a la documentación.

Identificador: RNF 5.4 Nombre: Copia de información

51

Descripción: Copiar información de zonas exclusivas.

Criterios de Aceptación: Deberá haber un bloqueo para copiar y pegar información informativa en la sección exclusiva. Para evitar plagio.

Identificador: RNF 5.5 Nombre: Error de la información

Descripción: Guardar imágenes.

Criterios de Aceptación: No podrán descargarse imágenes de ilustración, sólo se puede descargar directamente de la documentación.

6. Consideraciones de errores

Identificador: RNF 6,1 Nombre: Error de la información

Descripción: Alertas

Criterios de Aceptación: Se emitirá una alerta en caso que hayan errores en la digitación de información y se podrá modificar por el administrador únicamente cuando es un caso donde los campos principales presenten errores. Igualmente podrá modificarse por los usuarios en caso que sea posible modificarse un nombre, un teléfono, etc.

7. Consideraciones de modificaciones futuras.

Identificador: RNF 7,1 Nombre: Información para modificarse

Descripción: Cambios futuros

Criterios de Aceptación: - No se implementarán modificaciones para este proyecto pero a petición del tutor debe permitirse la agregación de talleres, ejercicios y cualquier modificación que a solicitud se pueda hacer únicamente si se amerita el cambio.

- Los cambios que se permitirán estarán asociados a ejercicios, videos o inclusión de información. No se podrán añadir chats, wikis ni descarga de videos.

- No se aplicarán cambios a la forma de documentar el trabajo.

8. Consideraciones de recursos.

Identificador: RNF 7,1 Nombre: Archivos

Descripción: Tipos de archivos

Criterios de Aceptación: - Sólo se aceptan archivos .pdf y .doc y no muy pesados, deberán estar limitados a una carga pequeña.

- Archivos de audio sólo serán de un tamaño limitado. - Videos sólo podrán ser vinculados a través de Youtube, no deberán haber videos

por descargarse. - Las imágenes deberán ser de un tamaño adecuado para verse pero no deben ser

muy pesadas.

52

9.6.6. Pseudorequerimientos.

El lenguaje a utilizar es PHP.

El motor de BD es el MySQL

El servidor es Apache.

9.6.7. Definición de actores

Administrador: Es el actor que representa todo el tipo de control o de reglamentación del sistema, está al tanto de todos los movimientos del sistema y vigila a su vez los movimientos de los usuarios y éste pude ser automático.

Estudiante acreditado: Es el usuario de pago que tiene el acceso para entrar a la aplicación y tomar los cursos, contactar a su tutor y tomar sus materiales

Aprendiz: Es el actor invitado que pueden tomar la información libremente pero no puede tomar tutorías directamente y no puede acceder a consultar información privilegiada.

Tutor: Es el actor que representa al maestro y tiene como fin impartir sus tutorías aportando su material de estudio como la información para contactarlo y tomar su información para impartir sus clases.

9.6.8. Casos de uso de la aplicación. Nombre del Caso de Uso CU1: Administrar plataforma

Resumen Permite el manejo completo de la aplicación por parte del administrador

Curso básico de eventos - El administrador ingresa con un usuario y una contraseña

Caminos alternativos - Regresar al inicio - Avisar que hay fallos en el ingreso

Caminos de excepción El administrador no aparece en el sistema.

Puntos de Extensión

Suposiciones - La aplicación debe estar abierta a cambios por parte del administrador.

Precondiciones El administrador debe estar registrado.

Poscondiciones - El administrador podrá hacer cambios en el registro. - El administrador podrá visualizar listas de estudiantes y tutores.

Criterios de aceptación - El administrador podrá acceder del sistema y hacer cambios.

Autor Andrés Arias

Fecha 23 – 09 – 2016

Nombre del Caso de Uso CU2: Administrar registros de tutor

Resumen Permite el manejo completo de la aplicación por parte del administrador

53

Curso básico de eventos - El administrador entra al sistema.

- Verifica que los registros estén y no haya alguna alteración.

- Verifica los cambios en los registros de tutor.

- Ingresa datos del tutor. - Modifica cambios del tutor. - Desactiva al tutor.

- Verifica que los datos existan.

Caminos alternativos - Regresar a la búsqueda. - Que la aplicación no presente fallos.

Caminos de excepción El tutor no aparece en el sistema.

Puntos de Extensión

Suposiciones - El administrador podrá hacer todos los procesos de inserción, modificación y desactivación del tutor; sin embargo para desactivarlo se deberán eliminar los documentos si no se activa después de un tiempo determinado o que el tutor lo solicite.

Precondiciones El administrador debe estar registrado.

Poscondiciones - El administrador podrá hacer cambios en el registro, consulta, modificación

- El administrador podrá visualizar listas de estudiantes y tutores.

Criterios de aceptación - El administrador podrá acceder del sistema y hacer cambios.

Autor Andrés Arias

Fecha 23 – 09 – 2016

Nombre del Caso de Uso CU3: Dar de alta a un tutor

Resumen Permite el registro del tutor en el sistema.

Curso básico de eventos - Ingreso del administrador al sistema.

- Diligenciamiento de los datos:

o Nombre tutor o Identificación tutor o Correo electrónico o Número telefónico. o Contraseña. o Idioma

- Debe enlistarse con un número de consecutivo el cual será la guía para ubicar el documento.

- El tutor selecciona el tiempo de registro.

- Confirma los datos. - El sistema valida y registra

los datos.

- Valida la existencia del tutor. - La identificación ya existe. - Contraseña errada. - El correo electrónico ya

existe.

Caminos alternativos - Regresar al inicio - Volver a pedir información al cliente. - Verificar si tiene un carácter especial.

Caminos de excepción - El documento que quiere ingresar ya existe. - El correo electrónico ya existe

Puntos de Extensión

Suposiciones - Errores no esperados. - La página no funciona o deja de funcionar durante el registro.

Precondiciones Que el tutor tenga una interfaz accesible y que pueda ser amigable, también que cada una de las secciones de registro estén lo suficientemente claras.

Poscondiciones - Debe lanzar un aviso que está registrado en el sistema.

Criterios de aceptación - El registro está completado

Autor Andrés Arias

54

Fecha 19 – 08 – 2016

Nombre del Caso de Uso CU4: Administrar registros de estudiante

Resumen Permite el manejo de los registros del estudiante

Curso básico de eventos - El administrador entra al sistema.

- Verifica que los registros estén y no haya alguna alteración.

- Verifica los cambios en los registros del estudiante.

- Ingresa datos del estudiante.

- Modifica cambios del estudiante.

- Desactiva al estudiante.

- Verifica que el código exista. - Verifica la existencia del

nombre.

Caminos alternativos - Regresar a la búsqueda. - Que la aplicación no presente fallos.

Caminos de excepción El estudiante no aparece en el sistema.

Puntos de Extensión

Suposiciones - El administrador podrá hacer todos los procesos de inserción, modificación y desactivación del estudiante, pero si el estudiante llega a solicitar la eliminación de su cuenta sólo se puede hacer cuando él lo solicite, verificar el tiempo.

Precondiciones El administrador debe estar registrado.

Poscondiciones - El administrador podrá hacer cambios en el registro, consulta, modificación.

- El administrador podrá visualizar listas de estudiantes

Criterios de aceptación - El administrador podrá acceder del sistema y hacer cambios.

Autor Andrés Arias

Fecha 23 – 09 – 2016

Nombre del Caso de Uso CU5 - Dar de alta a un estudiante

Resumen Permite el registro del estudiante en el sistema.

Curso básico de eventos - Ingreso al sistema. - Debe diligenciarse los

datos: o Nombre del

estudiante o Identificación

estudiante o Correo electrónico o Número telefónico.

- El estudiante selecciona un idioma para registrarse.

- Selecciona el tiempo - El sistema valida y registra

la información,

- Valida la existencia del estudiante.

- Valida la existencia del correo electrónico.

- Valida la existencia del número telefónico.

Caminos alternativos Regresar al inicio

Caminos de excepción - Regresar al inicio - Volver a pedir información al cliente. - Verificar si tiene un carácter especial.

Puntos de Extensión

Suposiciones

Precondiciones Que el estudiante tenga una interfaz accesible y que pueda ser amigable, también que cada una de las secciones de registro estén lo suficientemente claras.

55

Poscondiciones - Debe lanzar un aviso cuando el estudiante ya está registrado. - Debe lanzar un aviso cuando ha tratado de registrar nuevamente.

Criterios de aceptación El documento se debe anexar al sistema.

Autor Andrés Arias

Fecha 17 – 08 – 2016

Nombre del Caso de Uso CU6- Ingreso de documentación

Resumen Permite la generación del documento, especificando su función y su tipo de formato.

Curso básico de eventos - Ingreso del archivo. - Diligenciamiento de los

datos: o Nombre

documento. o Identificación

documento. o Idioma. o Tutor. o Tipo de

documentación. o Formato.

- Debe enlistarse con un número de consecutivo el cual será la guía para ubicar el documento.

- Valida la existencia del usuario.

- Valida la existencia del documento.

Caminos alternativos

Caminos de excepción - El documento que quiere ingresar ya existe. - No se puede agregar documento si la política no lo exige.

Puntos de Extensión

Suposiciones

Precondiciones

Poscondiciones - Debe lanzar un aviso que el archivo está en el sistema. - Debe relacionar la documentación a un área en especial.

Criterios de aceptación El documento se debe anexar al sistema.

Autor Andrés Arias

Fecha 23 – 08 – 2016

Nombre del Caso de Uso CU7 - Modificación de documentación

Resumen Permite la modificación del documento, reemplazando el archivo por otro.

Curso básico de eventos - Se inicia el sistema. - El sistema revisará que el

archivo existe. - El sistema revisará de

acuerdo a una lista y hará una validación.

- El administrador seleccionará si es visible o si se redirige a obsoletos.

- El sistema valida la información.

- Valida la existencia del documento.

- El documento tiene el formato correspondiente.

Caminos alternativos Regresar al inicio

Caminos de excepción - El documento no se puede modificar si no existe. - No se puede modificar ningún documento sin permisos del tutor.

Puntos de Extensión

Suposiciones

Precondiciones El documento debe existir.

56

Poscondiciones - Debe mantenerse en una base de datos almacenada y accesible solamente para el administrador y el tutor que desee modificarlo.

- En el caso de la documentación de tutorías se debe almacenar hasta un tiempo limitado a consideración de las condiciones del curso

Criterios de aceptación El documento se debe guardar en un repositorio y estar accesible al tutor y al usuario acreditado.

Autor Andrés Arias

Fecha 12 – 07 – 2016

Nombre del Caso de Uso CU8 - Eliminación de documentación

Resumen Permite la eliminación del documento asegurándose que no quede repositorio de acceso y pueda dejar libre espacio en la base de datos.

Curso básico de eventos - Debe estar en el repositorio.

- Enlistar los documentos que se quieren borrar.

- Borrar el documento que se quiere sacar.

- Valida los documentos existentes.

Caminos alternativos Regresar al inicio

Caminos de excepción - El documento que quiere eliminar ya no existe. - El documento no se puede eliminar sin permisos de administrador.

Puntos de Extensión

Suposiciones

Precondiciones - El documento debe estar fuera del alcance de los usuarios. - El documento debe existir. - El documento debe estar en un repositorio.

Poscondiciones El documento debe desaparecer.

Criterios de aceptación El documento se debe anexar al sistema.

Autor Andrés Arias

Fecha 12 – 07 – 2016

Nombre del Caso de Uso CU9 - Descarga documentación

Resumen Permite la descarga del documento

Curso básico de eventos - El sistema debe de validar la existencia del documento.

- Deben señalarse el botón de descarga

- El estudiante podrá seleccionar el archivo a descargar

- Debe estar registrado en el curso.

Caminos alternativos - Regresar al inicio - Hacer una consulta personalizada.

Caminos de excepción - El archivo no exista. - El archivo presenta fallos

Puntos de Extensión

Suposiciones - El archivo debe advertir que es válido para estudiantes activados o no.

- Podrá ser accedido para todos en caso que esté libre.

Precondiciones - El archivo debe estar visible. - En caso que esté en el lado de los estudiantes acreditados se debe

ocultar al resto..

Poscondiciones El archivo deberá descargarse.

Criterios de aceptación El usuario podrá descargar el archivo

Autor Andrés Arias

Fecha 18 – 07 – 2016

57

Nombre del Caso de Uso CU10 Consultar documentos

Resumen Hace una lista de los documentos

Curso básico de eventos - El sistema muestra una lista de los documentos que están por descargarse mirándolo por secciones, estas secciones se manejan de acuerdo a los cursos donde se deseen agregar.

- Se consulta revisando nombre y el consecutivo del documento.

- Se verifica que la sección exista.

- Se verifica que el nombre exista.

- Se verifica que el consecutivo exista.

Caminos alternativos

Caminos de excepción - El archivo no exista.

Puntos de Extensión

Suposiciones - El archivo debe advertir que es válido para estudiantes activados.

Precondiciones - El archivo debe existir

Poscondiciones - Mostrar la lista de archivos disponibles organizados por temática.

Criterios de aceptación El usuario podrá ver la lista de los archivos disponibles

Autor Andrés Arias

Fecha 18 – 07 – 2016

Nombre del Caso de Uso CU11 Desactivación del tutor

Resumen Permite la desactivación del tutor

Curso básico de eventos - El sistema debe de validar la existencia del tutor.

- Deben señalarse la desactivación del tutor.

- Se deben eliminar uno a uno los registros del tutor.

Caminos alternativos Regresar al inicio

Caminos de excepción - El tutor no existe.

Puntos de Extensión

Suposiciones Debe preguntarse primero por qué se desactiva el tutor. En caso de darse una respuesta afirmativa debe darse de baja. El tiempo de expiración está cercano.

Precondiciones - El tutor debe estar registrado. - Debe estar activo al momento de la desactivación.

Poscondiciones - El nombre del tutor debe quedar registrado igual que el correo con el que se registró.

- No pueden quedar documentos en el sistema. - No puede quedar registros sensibles en el sistema.

Criterios de aceptación El documento se debe anexar al sistema.

Autor Andrés Arias

Fecha 18 – 07 – 2016

Nombre del Caso de Uso CU12 Desactivación del estudiante acreditado

Resumen Permite la desactivación del estudiante

Curso básico de eventos - El sistema debe de validar la existencia del estudiante

- Deben señalarse la desactivación del tutor.

- Se deben eliminar uno a uno los registros del estudiante.

58

Caminos alternativos Regresar al inicio

Caminos de excepción - El tutor no existe.

Puntos de Extensión

Suposiciones Debe preguntarse primero por qué se desactiva el estudiante. En caso de darse una respuesta afirmativa debe darse de baja. El tiempo de expiración está cercano.

Precondiciones - El tutor debe estar registrado. - Debe estar activo al momento de la desactivación.

Poscondiciones - El nombre del tutor debe quedar registrado igual que el correo con el que se registró.

- No pueden quedar documentos en el sistema. - No puede quedar registros sensibles en el sistema.

Criterios de aceptación El documento se debe anexar al sistema.

Autor Andrés Arias

Fecha 18 – 07 – 2016

Nombre del Caso de Uso CU13 Verificar identidad

Resumen Permite verificar la identidad del usuario

Curso básico de eventos - Debe verificar la existencia del usuario

- El sistema debe de diferenciar al tutor del usuario.

- Verifica mediante un código interno.

Caminos alternativos Regresar al inicio

Caminos de excepción - El usuario no existe. - El usuario es invitado

Puntos de Extensión

Suposiciones En caso que el usuario sea un invitado debe avisarse invitándolo a que se registre

Precondiciones - El tutor debe estar registrado. - Debe estar activo al momento de la desactivación. - El estudiante debe de estar registrado. - Debe de estar activado al momento de la desactivación

Poscondiciones El usuario accede a su plataforma correspondiente

Criterios de aceptación El usuario ingresa al sistema.

Autor Andrés Arias

Fecha 25 - 09 – 2016

Nombre del Caso de Uso CU14 Inserción palabra

Resumen Permite verificar la actualización del diccionario de acuerdo al idioma de origen y de destino

Curso básico de eventos - Debe verificar la existencia de la palabra.

- Insertar la palabra con su correspondiente significado.

- Clasificar la palabra según su tipo.

- Insertar el idioma de origen y de destino.

- Verificar el idioma de origen.

Caminos alternativos Si la palabra ya existe puede existir otro significado.

Caminos de excepción

Puntos de Extensión

Suposiciones - La palabra puede tener errores ortográficos. - La palabra tiene significados distintos.

Precondiciones

Poscondiciones La palabra está ingresada en el diccionario.

Criterios de aceptación

Autor Andrés Arias

59

Fecha 25 - 09 – 2016

Nombre del Caso de Uso CU15 Actualización palabra

Resumen Permite verificar la actualización del diccionario de acuerdo al idioma de origen y de destino

Curso básico de eventos - Debe verificar la existencia de la palabra.

- Modificar la palabra con su correspondiente significado.

- Clasificar la palabra según su tipo.

- Verificar si tiene un significado previo

- Verificar la existencia de un sinónimo.

Caminos alternativos Si la palabra ya existe puede existir otro significado.

Caminos de excepción

Puntos de Extensión

Suposiciones - La palabra puede tener errores ortográficos. - La palabra tiene significados distintos.

Precondiciones

Poscondiciones La palabra está ingresada en el diccionario.

Criterios de aceptación

Autor Andrés Arias

Fecha 25 - 09 – 2016

Nombre del Caso de Uso CU16 Eliminar palabra

Resumen Permite verificar la eliminación de la palabra.

Curso básico de eventos - Debe verificar la existencia de la palabra.

- Eliminar la palabra.

- Verificar si está duplicada. - Verificar si tiene error

ortográfico.

Caminos alternativos Si la palabra ya existe puede existir otro significado.

Caminos de excepción

Puntos de Extensión

Suposiciones - Este proceso es manual debido a que la verificación debe hacerse consultando de fuentes previas que no se encuentran en la aplicación.

Precondiciones

Poscondiciones La palabra desaparece de la lista.

Criterios de aceptación

Autor Andrés Arias

Fecha 25 - 10 – 2016

Nombre del Caso de Uso CU17 Consultar palabra

Resumen Permite verificar la eliminación de la palabra.

Curso básico de eventos - Debe verificar la existencia de la palabra.

- Se busca en los filtros de tipo o idioma.

Caminos alternativos Si la palabra ya existe puede existir otro significado.

Caminos de excepción

Puntos de Extensión La palabra no exista.

Suposiciones

Precondiciones

Poscondiciones

Criterios de aceptación

Autor Andrés Arias

Fecha 25 - 10 – 2016

Nombre del Caso de Uso CU18 Creación de cursos

60

Resumen Permite verificar la creación del curso

Curso básico de eventos - Debe verificar la existencia del curso

- Se busca en los filtros de tipo o idioma.

- Se añade el nombre del curso que se va a crear.

- Se asigna al tutor que va a impartir el curso.

- Se asigna el tiempo de duración del curso.

- Se verifica si el idioma al cual se le va a asignar el curso existe.

- Se verifica la categoría del documento.

Caminos alternativos - Si el curso ya existe verificar el idioma. - Si ya existe el tutor podrá crearse un curso semejante pero

asignando otro tutor.

Caminos de excepción

Puntos de Extensión El curso no existe

Suposiciones

Precondiciones

Poscondiciones Debe permitir ingresar al usuario cuando desee pero debe cumplir el tiempo máximo de permanencia en el curso

Criterios de aceptación

Autor Andrés Arias

Fecha 25 - 10 – 2016

Nombre del Caso de Uso CU19 Registro de cursos

Resumen Permite al estudiante acreditado registrarse al curso.

Curso básico de eventos - Debe verificar la existencia del curso

- Se busca en los filtros de tipo o idioma.

-

- Se verifica si el idioma al cual se le va a registrar existe.

Caminos alternativos - Si el curso ya existe verificar el idioma.

Caminos de excepción

Puntos de Extensión El curso no existe

Suposiciones

Precondiciones El usuario sólo puede estar inscrito a 2 cursos adicionales.

Poscondiciones Debe permitir ingresar al usuario cuando desee pero debe cumplir el tiempo máximo de permanencia en el curso

Criterios de aceptación

Autor Andrés Arias

Fecha 25 - 10 – 2016

De estos casos de uso se desglosan las relaciones entre los actores en tres bloques principales, en el manejo de la aplicación el cual se encarga de realizar los procesos CRUD dentro de la aplicación, la fase de gestión de documentos. Todo enfocado a los 3 grandes ítems que son el manejo de la aplicación, el registro que está implícito dentro del manejo de la aplicación, el manejo del diccionario y finalmente, la interacción con los documentos. El aspecto del registro de los cursos implica la organización de los documentos y cómo el usuario interactúa con ellos, allí será el punto de contacto con los tutores y a la par se plantea la evaluación por fuera de la plataforma y al final el tutor consignará su nota final con base en una evaluación autónoma.

61

Ilustración 1 Caso de uso manejo aplicación

Ilustración 2 Caso de uso manejo documentación

Ilustración 3 Caso de uso manejo diccionario

62

Ilustración 4 Caso de uso Registro curso

9.7. Modelado de objetos

Una vez desglosado el modelo de negocio con base en las especificaciones del proyecto, se procede a verificar cuales son las interacciones del sistema con los objetos. Éstos se enfocarán principalmente en los aspectos más relevantes como el CRUD orientado al registro, los cursos, a la documentación y al diccionario reuniendo lo más relevante de la estructura del sistema, teniendo en cuenta sólo aquellas estructuras donde se encarga de trabajar la sección del controlador que se encarga de hacer las interacciones y las operaciones y del modelo que hace los llamados y las consultas pertinentes de la BD. Para ello se plantea el diagrama de clases el cual diseña la estructura del sistema, luego se plantea el diagrama de secuencia que sirve para formalizar el comportamiento del sistema y verificar la comunicación entre objetos y luego se hace la descripción del comportamiento de forma individual tomando varios estados y transiciones entre los objetos, El diagrama de actividades la que describe al sistema desde las actividades que representan la ejecución y muestra el flujo de cada una de las acciones.

63

9.7.1. Diagrama de clases Para el diseño de los objetos que hay que realizar, se parte del patrón de diseño MVC para estructurar la funcionalidad de los objetos y de ahí se generan las clases, se parte de la funcionalidad que entrega el sistema a partir del modelo que se crea con las SDBD, luego se generan las clases que se complementan con el funcionamiento y la interacción que se hace entre el host y la base de datos a través de los controladores especificando los eventos que se generan y deben manejar cada uno de los procesos que se generan. Una vez el usuario desde la vista ejecuta una orden, el controlador escucha y desde que exista la funcionalidad, ésta la toma, la ejecuta y toma las acciones directamente del modelo gestionando su funcionalidad. Entre tanto el modelo al tener contacto con el SDBD realiza las consultas pertinentes y permiten tomar y administrar la información para ser manejados a través de los controladores y así enviarse a la vista. Basado en esto se discriminan las clases que se implementan desde los controladores y desde el modelo; la vista al ofrecer únicamente la información que se muestra al enviar las órdenes desde el controlador no requiere de una creación de clases ya que únicamente toma la información y ejecuta las órdenes que envía el usuario para ser manejados desde las clases del controlador. Debido a que los controladores y los modelos están en dos capas diferentes, cada uno de los objetos extienden de las clases AppController y AppModel del framework de CakePHP [29] que vienen por defecto y permiten la gestión independiente. Los procesos que realiza se basan en el CRUD del registro a partir del modelo están en el paquete modelo, allí se encuentran las clases relacionadas a las consultas y el llamado de los modelos para realizar operaciones que luego se realizan en el controlador. Dado que las clases heredan de la clase AppController con el fin de reducir complejidad instanciando las funcionalidades y permitir darles un comportamiento específico

64

Ilustración 5 Diagrama de clases modelo

65

9.7.2. Diagrama de actividades Son las transiciones que se dan al asignar una acción que está asociada con un estado, es decir, describen la acción a través de una serie de estados y describen el flujo de las acciones asociadas, allí también se describen las restricciones que podrían presentarse entre las acciones. A nivel general se describen los procesos tomando las posibles alternativas y describen también flujos simultáneos con varios puntos de origen y destino. Las actividades llevadas a cabo como la generación de registros, actualización de palabras actualización de datos de usuarios y de tutores, son principalmente llevados a cabo por el administrador cuya función radica también en gestionar el acceso a cada uno de los miembros que se adhieren a la aplicación, así como de la gestión de permisos y la progresiva verificación de la información por parte de los miembros que van ingresando, así como la gestión de los cursos, la subida de archivos y la manipulación de la información de los cursos. Dentro de estos procesos se encuentran el ingreso a la cuenta, el cierre de sesión de la información, la gestión de ingreso de nuevos miembros, cuyo manejo inicial se da por un administrador por defecto que permite la gestión general de la aplicación, a partir de allí se lleva a cabo una serie de procesos que permiten la generación y el registro de los demás usuarios que deseen suscribirse a la aplicación. Luego de ello, son los tutores y por último los estudiantes quienes tienen la opción de gestionar y manejar las aplicaciones. En efecto dado que el estudiante está sujeto para la consulta, tiene la opción de generar la correspondiente descarga de la información a través de los canales de acceso, así como la consulta de palabras y su correspondiente traducción. La generación de cursos y también la asignación de los mismos, están sujetos a las limitantes de tiempo, las restricciones propias de cada tutor y también el acceso a cada estudiante.

66

Ilustración 6 Diagrama actividades registro tutor

Para los siguientes procesos se describe el proceso de registro del tutor, los estudiantes y el administrador, para ello en las ilustraciones 6, 7 y 8 se describen procesos semejantes, en donde la prioridad está en dos aspectos, el registro de cada uno de los actores de los procesos y la validación de la activación de cada uno, especialmente en el tiempo de registro, tanto del tutor, como del estudiante. El estudiante en este caso, está sujeto a las políticas de cuánto tiempo permanece registrado dentro de la aplicación, el del tutor está sujeto al cambio que desee hacer, mientras que el administrador se darán por causas fuera de la plataforma las cuales están sujetas a cambios.

67

Ilustración 7 Diagrama actividades registro tutor

Ilustración 8 Diagrama actividades registro estudiantes

68

Respecto al proceso de ingreso de documentación se requiere que haya un proceso de registro del curso, el cual es con el cual se va regulando la distribución de los documentos para evitar una dispersión y organizarse para que el estudiante pueda tenerlos a disposición y esté acorde a la asignación que se tiene. Tratándose que el tutor tiene a cargo un curso a la vez, el proceso que se sigue es el siguiente:

Ilustración 9 Diagrama actividades creación curso

Una vez hecho el registro de la creación del curso, se procede luego a anexar un documento en específico. Para ello puede ingresar varios documentos relacionados con el mismo tema, y mantenerse en una organización que pueda facilitar el registro del estudiante y pueda realizar las consultas y el curso correspondiente, en el tiempo establecido y seleccionando el documento realizando su respectiva consulta.

69

Ilustración 10 Diagrama actividades creación curso

9.7.3. Diagramas de secuencia. Para los diagramas de secuencia se muestra el flujo de secuencialización o paso de mensajes entre clases, sistemas, y subsistemas, a partir del establecimiento de estados y a partir de allí se puede visualizar las instancias y los eventos de cada uno de los procesos que hace describiendo el flujo de los mensajes. [30], se pueden pasar argumentos que están asociados a parámetros de la operación e indica lo que se va a hacer. Cada paso representa un argumento el cual indica un paso a paso y da a lugar a activaciones, cada secuencia en sí indica una interacción específica en cada uno de los procesos que se llevan a cabo una vez visto la descripción general. A continuación se describe el proceso de registro, tanto el tutor, como los estudiantes y los administradores manejan procesos semejantes salvo obvias diferencias tanto en la inscripción de los cursos como de la generación de documentación, así como de la actualización de diccionarios que permiten también la consulta. Allí también se generan disponibilidades tanto para la inscripción de los cursos como de los pasos generales para activación y las limitantes en función del tiempo. Al registrarse los usuarios, tanto el administrador, como el tutor, como el estudiante, se vinculan a través de un mismo botón el cual activa y genera el proceso de registro, indicando cada uno de los datos que debe ingresar allí, tales como usuario, contraseña; dicho proceso llevado a cabo principalmente por el administrador quien toma cada uno de los registros y disponiendo de la información a cada uno de los usuarios restantes tomará a cabo

70

Ilustración 11 Diagrama de secuencia Dar alta tutor

Respecto de la validación de los documentos previamente se asigna una categorización del tipo de documentación para hacer la validación de tipo de documento que se va a ingresar.

Ilustración 12 Diagrama secuencia RegistroDocumento

9.7.4. Implementación modelo base de datos.

Una vez se tienen planteados los requerimientos se empieza a plantear el inventario ordenado de variables, este inventario permite identificar cuáles son los grupos transaccionales y las entidades que se controlan. En el (Anexo B) se puede encontrar desglosado el proceso de creación del sujeto y los grupos transaccionales los cuales orientan el modelo y la lógica del negocio. Una vez hecha esta fase, se

71

procede a organizar el inventario único de variables, éste da la orientación de la organización de las tablas en torno al modelo del negocio ubicando cuáles corresponden a cada entidad. Luego de esto se procede a organizar las tablas acorde a la organización de las llaves y una vez hecho esto se procede a armar el diagrama entidad relación explicando la relación entre entidades fuertes y débiles y una vez realizado esto se procede a hacer el modelo relacional.

72

10. IMPLEMENTACIÓN PROTOTIPO

El resultado del proyecto fue la el prototipo de aplicación Langee cuyo fin es corresponder a la alternativa de poder proveer un soporte para estudiantes cuyo fin sea de poder obtener un material completo y que sea cambiable y moldeable sin necesidad de recurrir a un complejo sistema de estudio en línea y a la par permite al maestro asistirlo a sus requerimientos sin tener que hacer complejas evaluaciones, brindando soportes complementarios donde puede respaldarse y puede ofrecer una guía al estudiante. Se buscó que el diseño se pueda adaptar a un diseño responsivo, donde además de la interfaz de presentación, pueda de entrada adaptarse a cualquier dispositivo donde pueda ser consultado. Esta es la página de inicio.

Ilustración 13 Interfaz de inicio Langee

Aunque de momento no contiene la información de acceso libre, ésta aplicación cuenta con todos los elementos básicos donde se busca implementar el modelo MVC en la consecución del desarrollo de una aplicación donde contenga los elementos principales para obtener los documentos de consulta especializada y de registro de cursos. Con los tutores, allí se podrán encontrar aspectos funcionales de cómo realizar el registro del curso y de cómo ingresar documentación, así como también suple el registro de los documentos dentro de la aplicación, así como el registro de tutores y alumnos desde la interfaz del administrador.

73

Ilustración 14 Interfaz inicio registro tutores

Ilustración 15 Interfaz registro estudiantes

En la misma pantalla de inicio se pueden acceder también al registro de tutores como de estudiantes a la aplicación. Así como un registro de contacto a la aplicación, aunque de momento únicamente se mantendrá como indicador futuro de mensajes dado el caso que se desee tener un contacto con la aplicación. En la interfaz del inicio se podrá hallar el menú de registro de tutores como de estudiantes por separado, las diferencias se dan en detalles tales como los cursos a

74

seleccionar o cursos para impartir; sin embargo, el administrador también podrá realizar el registro a través de una interfaz independiente el cual brinda un control más detallado

Ilustración 16 Interfaz registro tutor

En el caso del administrador puede obtener una interfaz más visible donde da una orientación acerca de los tutores registrados y los estudiantes que están inscritos a los cursos ofrecidos haciendo un seguimiento en el orden cronológico. Desde esta interfaz se permite también orientar el registro de los bloques de documentación, basados en el idioma, los paquetes de documentación, los cursos los cuales se crean con base al tutor y también el registro de los estudiantes en estos cursos.

75

Ilustración 17 Menú administrador

Por defecto al generar la base de datos se genera un administrador que maneja y gestiona los procesos dentro de la aplicación, en el caso de agregar un nuevo administrador basta con ingresar a la interfaz de editar administrador y allí pueden registrar o crear un nuevo usuario ingresando únicamente su cedula y su nombre.

Ilustración 18 Menú administrador

76

Dado que las clases recaen sobre el controlador ya que la lógica que se acompaña recae sobre las operaciones que se hacen, éstas al vincular al modelo lo hacen a través del controlador haciendo los llamados correspondientes a partir de la clase AppController y la clase AppModel cuyas funcionalidades son estándares dentro del framework CakePHP y cuyo fin es el de mantener el orden en el protocolo del diseño de clases y que estas a su vez puedan ser invocadas a la vista para que pueda llamar correctamente los campos de la BD desde el modelo optimizando el llamado de clases desde el modelo evitando confusión con los nombres y evitar que el modelo se vea afectado con el uso incorrecto de alguna función que directamente afecte a la BD. Para ello se desprenden las clases organizadas a través de paquetes, estos paquetes hacen el llamado de acuerdo a las funcionalidades que presentan, Esta es la implementación del CRUD de estudiantes en donde el sistema hace la verificación campo a campo haciendo el correspondiente llamado a la clase que se encuentra en el modelo el cual realiza el llamado a la tabla. <?php

App::uses('AppController', 'Controller');

/**

* Students Controller

*

* @property Student $Student

* @property PaginatorComponent $Paginator

*/

class StudentsController extends AppController {

/**

* Components

*

* @var array

*/

public $components = array('Paginator', 'Search');

public function beforeFilter() {

parent::beforeFilter();

$this->Auth->allow('add', 'success_register');

}

/**

* index method

*

* @return void

*/

public function admin_index() {

$conditions = $this->Search->getConditions();

$this->paginate = array(

'conditions' => $conditions,

'fields' => [

'Student.id',

77

'Student.user_id',

'Student.first_name',

'Student.last_name',

'Student.email',

'Student.language_id',

'Student.created',

],

'contain' => array(

'Language' => [

'fields' => ['Language.name']

],

'User' => array(

'fields' => [

'User.status',

'User.identification',

]

),

'Photo' => [

'fields' => [

'Photo.dir',

'Photo.photo',

]

]

),

'order' => ['Student.created' => 'desc'],

'recursive' => -1

);

$this->set('students', $this->Paginator->paginate());

}

/**

* view method

*

* @throws NotFoundException

* @param string $id

* @return void

*/

public function admin_view($id = null) {

if (!$this->Student->exists($id)) {

throw new NotFoundException(__('Invalid student'));

}

$options = array('conditions' => array('Student.' .

$this->Student->primaryKey => $id));

$this->set('student', $this->Student->find('first',

$options));

}

/**

* add method

*

* @return void

*/

public function admin_add() {

if ($this->request->is('post')) {

$this->Student->create();

$this->request->data['User']['role_id'] =

ConstUserRole::Student;

78

$this->request->data['User']['username'] = $this-

>request->data['User']['identification'];

$this->request->data['User']['name'] = $this-

>request->data['Student']['first_name'].' '.$this->request-

>data['Student']['last_name'];

if ($this->Student->saveAssociated($this->request-

>data)) {

$this->Flash->success(__('The student has been

saved.'));

return $this->redirect(array('action' =>

'index'));

} else {

$this->Flash->error(__('The student could not be

saved. Please, try again.'));

}

}

$languages = $this->Student->Language->find('list');

$this->set(compact('languages'));

}

/**

* add method

*

* @return void

*/

public function add() {

if ($this->request->is('post')) {

$this->Student->create();

$this->request->data['User']['role_id'] =

ConstUserRole::Student;

$this->request->data['User']['status'] = 0;

$this->request->data['User']['username'] = $this-

>request->data['User']['identification'];

$this->request->data['User']['name'] = $this-

>request->data['Student']['first_name'].' '.$this->request-

>data['Student']['last_name'];

if ($this->Student->saveAssociated($this-

>request->data)) {

$msg = [

'type' => 'success',

'msg' => __('The student has been

saved.')

];

unset($this->request->data);

$this->render('success_register');

} else {

$msg = [

'type' => 'danger',

'msg' => __('The student could not be

saved. Please, try again.')

];

}

$this->set('alert', $msg);

}

$languages = $this->Student->Language->find('list');

$this->set(compact('languages'));

}

79

/**

* @return array

*/

public function success_register(){

$msg = [

'type' => 'success',

'msg' => __('The student has been saved.')

];

$this->set('alert', $msg);

}

/**

* edit method

*

* @throws NotFoundException

* @param string $id

* @return void

*/

public function admin_edit($id = null) {

if (!$this->Student->exists($id)) {

throw new NotFoundException(__('Invalid student'));

}

if ($this->request->is(array('post', 'put'))) {

if (empty($this->request-

>data['Photo']['photo'])) {

unset($this->Student->Photo-

>validate['photo']);

unset($this->request->data['Photo']);

}

$this->request->data['User']['username'] = $this-

>request->data['User']['identification'];

$this->request->data['User']['name'] = $this-

>request->data['Student']['first_name'].' '.$this->request-

>data['Student']['last_name'];

if ($this->Student->saveAssociated($this->request-

>data)) {

if (!empty($this->request-

>data['Photo']['photo']) && !empty($this->request-

>data['Student']['photoOld'])) {

@unlink($this->request-

>data['Student']['photoOld']);

}

$this->Flash->success(__('The student has been

saved.'));

return $this->redirect(array('action' =>

'index'));

} else {

$this->Flash->error(__('The student could not be

saved. Please, try again.'));

}

} else {

$options = array('conditions' => array('Student.' .

$this->Student->primaryKey => $id));

$this->request->data = $this->Student->find('first',

$options);

$this->request->data['Student']['photoOld'] =

WWW_ROOT . "img" . DS . "attachment" . DS . "photo" . DS .

80

$this->request->data['Photo']['dir'] . DS . $this->request-

>data['Photo']['photo'];

}

$users = $this->Student->User->find('list');

$languages = $this->Student->Language->find('list');

$this->set(compact('users', 'languages'));

}

/**

* change_status method

*

* @throws NotFoundException

* @param int $id

* @param int $status

* @return void

*/

public function admin_change_status($id = null, $status =

0) {

if (!$this->Student->User->exists($id)) {

throw new NotFoundException(__('Invalid

student'));

}

if ($this->request->is(array('post', 'put'))) {

$this->Student->User->id = $id;

if($this->Student->User->saveField('status',

($status==1)? 0:1 )){

$this->Flash->success(__('The status of

student has been saved.'));

return $this->redirect(array('action' =>

'index'));

} else {

$this->Flash->error(__('The status of student

could not be saved. Please, try again.'));

}

}

}

/**

* delete method

*

* @throws NotFoundException

* @param string $id

* @return void

*/

public function admin_delete($id = null) {

$this->Student->id = $id;

if (!$this->Student->exists()) {

throw new NotFoundException(__('Invalid student'));

}

$this->request->allowMethod('post', 'delete');

try {

if ($this->Student->delete()) {

$this->Flash->success(__('The student has

been deleted.'));

} else {

$this->Flash->error(__('The student could not

be deleted. Please, try again.'));

81

}

}catch (Exception $e) {

$this->Flash->error("<b>".__('Delete

failed.')."</b> {$e->getMessage()}");

}

return $this->redirect(array('action' => 'index'));

}

/**

* admin_profile method

*

* @return void

*/

public function student_profile() {

$current_user = $this->Auth->user();

$id = $current_user['id'];

if ($this->request->is(array('post', 'put'))) {

if (empty($this->request-

>data['Photo']['photo'])) {

unset($this->Student->Photo-

>validate['photo']);

unset($this->request->data['Photo']);

}

$this->request->data['User']['username'] = $this-

>request->data['User']['identification'];

$this->request->data['User']['name'] = $this-

>request->data['Student']['first_name'].' '.$this->request-

>data['Student']['last_name'];

if ($this->Student->saveAssociated($this-

>request->data)) {

if (!empty($this->request-

>data['Photo']['photo']) && !empty($this->request-

>data['Student']['photoOld'])) {

@unlink($this->request-

>data['Student']['photoOld']);

}

$this->Flash->success(__('The student profile

has been saved.'));

return $this->redirect('/'.$this->request-

>prefix);

} else {

$this->Flash->error(__('The student profile

could not be saved. Please, try again.'));

}

} else {

$options = [

'conditions' => ['Student.user_id' => $id],

'contain' => ['User', 'Photo']

];

$this->request->data = $this->Student-

>find('first', $options);

$this->request->data['Student']['photoOld'] =

WWW_ROOT . "img" . DS . "attachment" . DS . "photo" . DS .

$this->request->data['Photo']['dir'] . DS . $this->request-

>data['Photo']['photo'];

}

$languages = $this->Student->Language->find('list');

82

$this->set(compact( 'languages'));

}

Respecto del modelo, está manejado a través de la clase AppModel cuyo fin es el de permitir una organización estándar que permita luego desde el controlador hacer el llamado a la clase que controla a la BD. Haciendo la instanciación y las correspondientes relaciones entre las llaves, en este caso se hace el llamado de la tabla que contiene a la tabla estudiantes a través del archivo student.php. <?php

App::uses('AppModel', 'Model');

/**

* Student Model

*

* @property User $User

* @property Language $Language

*/

class Student extends AppModel {

/**

* Validation rules

*

* @var array

*/

public $validate = array(

'first_name' => array(

'notBlank' => array(

'rule' => array('notBlank'),

//'message' => 'Your custom message

here',

//'allowEmpty' => false,

//'required' => false,

//'last' => false, // Stop validation

after this rule

//'on' => 'create', // Limit

validation to 'create' or 'update' operations

),

),

'last_name' => array(

'notBlank' => array(

'rule' => array('notBlank'),

//'message' => 'Your custom message

here',

//'allowEmpty' => false,

//'required' => false,

//'last' => false, // Stop validation

after this rule

//'on' => 'create', // Limit

validation to 'create' or 'update' operations

),

),

'user_id' => array(

'numeric' => array(

'rule' => array('numeric'),

//'message' => 'Your custom message

here',

//'allowEmpty' => false,

83

//'required' => false,

//'last' => false, // Stop validation

after this rule

//'on' => 'create', // Limit

validation to 'create' or 'update' operations

),

),

'language_id' => array(

'numeric' => array(

'rule' => array('numeric'),

),

),

'email' => array(

'Unique' => array(

'rule' => 'isUnique',

'message' => 'The email has already been taken'

),

'email' => array(

'rule' => array('email'),

'message' => 'Invalid email address',

)

),

'mobile' => array(

'notempty' => array(

'rule' => array('numeric'),

'message' => 'Mobile number not valid',

),

'lengthPassword' => array(

'rule' => array('between', 10, 10),

'message' => 'Mobile number not valid'

),

),

);

public $virtualFields = array(

'name' => 'CONCAT(Student.first_name, " ",

Student.last_name)'

);

// The Associations below have been created with all possible

keys, those that are not needed can be removed

/**

* belongsTo associations

*

* @var array

*/

public $belongsTo = array(

'User' => array(

'className' => 'User',

'foreignKey' => 'user_id',

'conditions' => '',

'fields' => '',

'order' => ''

),

'Language' => array(

'className' => 'Language',

'foreignKey' => 'language_id',

84

'conditions' => '',

'fields' => '',

'order' => '',

'dependent' => true

)

);

/**

* hasAndBelongsToMany associations

*

* @var array

*/

public $hasAndBelongsToMany = array(

'Course' => array(

'className' => 'Course',

'joinTable' => 'courses_students',

'foreignKey' => 'student_id',

'associationForeignKey' => 'course_id',

'unique' => 'keepExisting',

'conditions' => '',

'fields' => '',

'order' => '',

'limit' => '',

'offset' => '',

'finderQuery' => '',

)

);

/**

* hasOne associations

*

* @var array

*/

public $hasOne = array(

'Photo' => array(

'className' => 'Attachment',

'foreignKey' => 'foreign_key',

'conditions' => array(

'Photo.model' => 'student'

),

'dependent' => true

),

);

function beforeDelete( $cascade = TRUE ) {

$user = $this->find('first', ['conditions' => ['Student.id'

=> $this->id], 'recursive' => -1]);

if($this->User->delete($user['Student']['user_id'])){

return true;

}

return false;

}

}

85

11. CONCLUSIONES Y RECOMENDACIONES

11.1. Conclusiones Respecto al desarrollo se destaca que el prototipo ya es un prototipo funcional, extensible y modificable. Tomando en cuenta diferentes parámetros como es la organización de las clases y el planteamiento lógico, al igual permite a partir de la concepción del modelo de negocio la implementación y el conocimiento del planteamiento de las bases de datos para construir e implementar desarrollos funcionales Se destaca a partir de la obtención de los requerimientos y los casos de uso el progresivo desarrollo y la concepción del patrón MVC que permitió el ordenamiento de la aplicación en sus funcionalidades permitiendo la diversificación y la especialización al permitir cada uno de los elementos trabajar de forma independiente evitando confusiones y evitando mezclas innecesarias aplicando erróneamente algún otro patrón diferente al planteado. Al ser PHP un lenguaje interpretado y no compilado, la necesidad de implementar algún otro complemento no fue necesario en lo absoluto permitiendo mayor flexibilidad a la capa vista del patrón haciendo que la vista mantenga una independencia y llamando a los atributos únicamente cuando se requiera. Otro elemento a destacar es el uso del API, permitiendo una mayor organización al especializar las funciones, permite optimizar el tiempo y ayuda a la mejora del mismo además la amplia información permitió adaptar la aplicación rápidamente a diferencia de posibles inconvenientes al generar paquetes para suplir alguna novedad además de potenciar la optimización del trabajo frente a eventos y cambios intempestivos. Esto implica también la robustez para afrontar cambios y mantener la interacción entre las demás capas de forma independiente. De igual manera se destaca el potencial de implementación del modelo pseudomatemático desarrollado por el ing. John Jairo Londoño, cuyo propósito es optimizar el diseño de la base de datos enfocándose en las transacciones y en los sujetos, del potencial de optimización de la normalización y finalmente llegar al MER y MR optimizando cada uno de los campos y segmentando las llaves.

11.2 Recomendaciones Se recomienda extender esta aplicación a dispositivos móviles en general e implementar el uso de los chats y foros para permitir la extensión. Igualmente se recomienda ampliar el portafolio de servicios, especialmente en el sector comercial, buscando mecanismos de conectar profesores y alumnos de forma remota en la sección reservada, las posibilidades de extensión pueden ser considerables teniendo en cuenta los niveles de preparación a nivel avanzado potenciando la relación de estudiantes que no se encuentren en el país, igualmente puede ampliarse el portafolio a otros idiomas.

86

12. RECURSOS

12.1. Recursos humanos

Este será el grupo humano que participa en el proyecto:

ACTOR ROL

Henry Andrés Arias C Ejecutor del proyecto

José David Álvarez Director del proyecto

Tabla 1: Participantes del proyecto.

12.2. Hardware En este apartado no se incluyen aspectos como costos del hardware como tal, contemplados en horas de uso excepto en el precio de obtención de los mismos. Igualmente para ello, se requiere de un escritorio remoto, para el siguiente cálculo se obtuvo sólo los elementos principales ya que no se obtuvo acceso al equipo que surte la aplicación remota.

Equipo Justificación Valor del Recurso

Ctd. Costo de la

hora de uso($)

Costo total de uso por mes($)

Costo total de uso

Total ($)

Equipo de escritorio

Computador que es usado

para el desarrollo de la

aplicación.

1000000 1 200 12.000 96.000 1096000

Equipo portátil

Computador empleado para desarrollo de la

aplicación

1200000 1 200 12.000 96.000 1308200

Teclado y mouse

Dispositivos de entrada 50.000 1 - - - 50000

Total 2250000 3 400 24.000 192.000 2454200

Tabla 3: Presupuesto hardware

12.3. Software

Software Justificación Valor del Recurso ($)

Licencia Cantidad Total mes ($)

Windows 7 Professional

Sistema Operativo de los equipos y del escritorio

remoto.

395000 OEM 1 395.000

Notepad ++ El framework donde se diseñará y se programará el

proyecto.

0 Open Source

1 0

PHP Lenguaje de programación orientado a web

0 Open Source

1 0

Microsoft Office 2013

Herramientas de ofimática. 300.000 OEM 1 300.000

TOTAL 695.000

Tabla 4: Presupuesto software

87

12.4. Servicio de red

Servicio Costo mensual Numero de meses Total mes

($)

Servicio de red claro 35.000 8 280.000

12.5. Costo del proyecto Para el siguiente cálculo se sumó la totalidad de los anteriores costos y allí se consolido un costo que será el costo total del proyecto.

Rubros Costo total

Software 395.000

Hardware 1’942.000

Servicio de red 280.000

Total 2’617.000

El total estimado del proyecto es de: $2’617.000 COP.

88

13. BIBLIOGRAFÍA

[1] M. L. Cacheiro Gonzalez, Educación y tecnología: Estrategias didácticas para la integración de las TIC., 1986.

[2] C. M. Alonso Garcia, «Caldad, aprendizaje y TIC,» de Aplicaciones educativas de las tecnologías de la información y la comunicación, EGRAF. S.A.

[3] C. Coll y C. Monereo, Psicología de la educación virtual. aprender y enseñar con las tecnologías de educacíón y la comunicación, Madrid: Ediciones Morata. S.L, 2008.

[4] S. Fotos y C. M. Browne, New Perspectives on CALL for Second Language Classrooms, Mahwah, Nueva Jersey: Lawrence Erlbaum Associates, Inc., 2004.

[5] TPACK, «TPACK,» [En línea]. Available: http://www.tpack.org/. [Último acceso: 30 Octubre 2015].

[6] J. A. Solís Becerra y I. M. Solano Hernandez, «El uso de las TIC en el currículo de inglés de Educación Primaria por parte del profesorado novel,» Didáctica. Lengua y Literatura, pp. 315-331, 2013.

[7] M. Warschauer y D. Healey, «Computers and language, learning: An overview. Language teaching,» pp. 31, 57-71.

[8] M. Warschauer, A developmental perspective on technology in language education, Irvine, California: University of Irvine.

[9] Bahaa El Din, H K, «Education and the future,» Kayoub, Al Ahram Commercial Press, 1997, pp. 120-121.

[10] M. Warschauer, « Technological change and the future of CALL,» de In S. Fotos & C. Brown (Eds.), New Perspectives on CALL for Second and Foreign Language Classrooms , Mahwah, Lawrence Erlbaum Associates, 2004, pp. 15-25.

[11] D. Benito Osorio, «Estrategias y figura del e-moderador,» 15 Noviembre 2015. [En línea]. Available: http://rusc.uoc.edu/index.php/rusc/article/viewFile/v6n2-benito/v6n2_benito.

[12] M. S. McIsaac and C. N. Gunawardena, "Distance Education," in Handbook on research for educational communications and technology, Nueva York, Mc Millan, 1996, pp. 403 - 437.

[13] Cabrero Almenara, Julio; Gisbert Cervera, Merce, La formación en Internet. Guía para el diseño de materiales formativo, Sevilla: MAD S.L, 2005.

[14] B. Bruege y A. H. Dutoit, Ingeniería de software orientado a objetos, Primera ed., P. Educación, Ed., México DF: Prentice Hall, 2002.

[15] C. A. Silva Delgado y J. M. Martinez Guerrero, Guia metodologica para el levantamiento y análisis de requerimientos de software con base en procesos de negocio, Bogotá, 2010.

[16] F. Dávila, «La inteligencia del negocio Business intelligence,» Politécnico Grancolombiano, [En línea]. Available: http://sigma.poligran.edu.co/politecnico/apoyo/cuadernos/intelligence.pdf.

89

[17] J. J. Londoño, John Jairo. Modelo pseudomatematico para el diseño de las bases de datos relacionales, Editorial no comercial, to be published.

[18] «La tecla de Escape,» [En línea]. Available: http://latecladeescape.com/h/2015/07/acid#. [Último acceso: 15 Octubre 2015].

[19] O. Pons Capote , S. Acid Carrillo, N. Marín Ruiz, J. M. Medina Rodriguez y M. A. Villa Miranda, Introducción a los sistemas de bases de datos, Madrid: Departamento de Cienciasde la computación e inteligencia artificial., 2008.

[20] E. Bahit, POO y MVC en PHP. El paradigma de la programación Orientada a Objetos en PHP y el patrón de arquitectura MVC.

[21] B. Campderrich Balgueras, Ingenieria de Software, Barcelona, Cataluña: UOC, 2003.

[22] I. Sommerville, Ingeniería del software, vol. II, Pearson Addison Wesley, 2005.

[23] PHP, «¿Qué es PHP?,» [En línea]. Available: http://php.net/manual/es/intro-whatis.php.

[24] Apache, «Apache HTTP Server Project,» Junio 2016. [En línea]. Available: http://httpd.apache.org/.

[25] Á. Cobo, P. Gómez , D. Pérez y R. Rocha, «PHP y MySQL: Tecnología para el desarrollo de aplicaciones web.,» Ediciones Diaz de Santos, 2005.

[26] L. Debrauwer y F. van der Heyde, UML 2: iniciación, ejemplos y ejercicios corregidos, A. Garcia Vega, Ed., Barcelona, Cataluña: Editions CNI, 2005.

[27] I. Laboratorio Nacional de Calidad del Software , «Ingeniería de software metodologías y ciclos de vida,» 2009.

[28] P. Krutchen, The Rational Unified Process an introduction, Tercera ed., Boston, Massachussets: Addison Wesley, 2004.

[29] Cake Software Foundation, CakePHP Cookbook Documentation, 2017.

[30] Microsoft, «Diagramas de secuencia UML: Referencia,» [En línea]. Available: https://msdn.microsoft.com/es-co/library/dd409377.aspx.

[31] C. Courage and K. Baxter, "Understanding Your Users," in A practical guide to user requirements, methods, tools and techniques, Morgan Kauffman Publishers, 2005.

[32] Microsoft, «Microsoft® SQL Server® 2008 R2 SP2 - Express Edition,» [En línea]. Available: http://www.microsoft.com/es-co/download/details.aspx?id=30438 .

[33] M. Koehler, «TPACK,» 2012. [En línea]. Available: http:// www.tpack.org. [Último acceso: 27 Octubre 2015].

[34] J. M. Martinez Guerrero y C. A. Silva Delgado, «Anexo 2. Ingeniería de requerimientos,» Pontificia Universidad Javeriana, Bogotá, 2010.

[35] «Wikipedia,» [En línea]. Available: http://es.wikipedia.org/wiki/Stakeholder. [Último acceso: 11 Noviembre 2015].

90

14. ANEXO A