TUTORIAS DOCENTES PUCESA by telmo viteri

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE AMBATO Departamento de Postgrados y Autoevaluación

Análisis y Diseño de un Prototipo software para la Administración de Tutorías Docentes para la PUCESA

Ambato, Mayo – 2012

TABLA DE CONTENIDO TABLA DE CONTENIDO...................................................................................................... 2 INTRODUCCION ................................................................................................................ 6 RESUMEN DEL PROYECTO ................................................................................................ 6 CAPITULO I ........................................................................................................................ 7 EL PROBLEMA ................................................................................................................... 7 TEMA................................................................................................................................. 7 ANTECEDENTES O CONTEXTUALIZACION ......................................................................... 7 La educación universitaria en el contexto actual ......................................................... 7 Cambios significativos en los estudiantes de Hoy ........................................................ 8 PROGNOSIS ..................................................................................................................... 10 PLANTEAMIENTO DEL PROBLEMA ................................................................................. 10 DEFINICIÓN DEL PROBLEMA........................................................................................... 11 DELIMITACIÓN DEL PROBLEMA ...................................................................................... 11 OBJETIVOS DEL PROYECTO: ............................................................................................ 12 Objetivo general.......................................................................................................... 12 Objetivos específicos: ................................................................................................. 12 METAS Y RESULTADOS ESPERADOS DEL PROYECTO: ..................................................... 12 Lo que no hará el Prototipo: ....................................................................................... 12 CAPITULO II ..................................................................................................................... 14 MARCO TEORICO ............................................................................................................ 14 ANTECEDENTES INVESTIGATIVOS .................................................................................. 14 Marco legal de la Tutoría ................................................................................................ 14

Análisis Europeo.......................................................................................................... 14 El Proyecto PACENI – Secretaría de Políticas Universitarias – Gobierno Argentino .. 18 Análisis Ecuatoriano .................................................................................................... 21 El Caso PUCE-Sede Ibarra ........................................................................................ 21 El Caso Universidad San Gregorio de Portoviejo ................................................... 23 Marco de intervención de la tutoría y la orientación..................................................... 28 PERFIL DEL TUTOR UNIVERSITARIO ................................................................................ 29 SOFTWARE ...................................................................................................................... 35 Componentes del software......................................................................................... 35 DESARROLLO DE SOFTWARE .......................................................................................... 36 PROCESO ..................................................................................................................... 37 CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE ........................................................ 39 TIPOS DE MODELO DE CICLO DE VIDA ........................................................................ 40 MODELOS DE CICLO DE VIDA ...................................................................................... 40 Modelo en cascada ................................................................................................. 41 Ventajas ................................................................................................................... 42 Inconvenientes ........................................................................................................ 43 Variantes ................................................................................................................. 44 MODELO EN V ............................................................................................................. 44 Ventajas ................................................................................................................... 46 Inconvenientes ........................................................................................................ 46 MODELO ITERATIVO ................................................................................................... 46 Ventajas ................................................................................................................... 47 Inconvenientes ........................................................................................................ 47 MODELO DE DESARROLLO INCREMENTAL ................................................................. 48 Ventajas ................................................................................................................... 48

Inconvenientes ........................................................................................................ 49 MODELO EN ESPIRAL .................................................................................................. 49 Ventajas ................................................................................................................... 52 Inconvenientes ........................................................................................................ 52 Comparación con otros modelos ............................................................................ 52 MODELO DE PROTOTIPOS .......................................................................................... 53 Ventajas ................................................................................................................... 54 Inconvenientes ........................................................................................................ 54 METODOLOGÍAS DE DESARROLLO DE SOFTWARE ......................................................... 55 DEFINICIÓN DE METODOLOGÍA .................................................................................. 56 VENTAJAS DEL USO DE UNA METODOLOGÍA ............................................................. 58 CAPITULO III .................................................................................................................... 59 METODOLOGÍA ............................................................................................................... 59 Desarrollo de software por prototipos ....................................................................... 59 Selección del modelo de Prototipo Evolutivo ............................................................. 59 CAPÍTULO IV.................................................................................................................... 64 RESULTADOS ................................................................................................................... 64 Diagramas UML .............................................................................................................. 64 Módulo Materias ........................................................................................................ 64 Módulo Escuela – Unidad Académica......................................................................... 69 Módulo Curso.............................................................................................................. 71 Módulo Docente ......................................................................................................... 72 Módulo Estudiante...................................................................................................... 77 Módulo Tutorías.......................................................................................................... 83 Modelado Base de Datos Tutoría ............................................................................... 88 Tabla Alumno .................................................................................................................. 89

Tabla Docente ................................................................................................................. 89 Tabla Periodo académico ............................................................................................... 89 Tabla Unidad Académica ................................................................................................ 89 Tabla Tutorías ................................................................................................................. 90 APARIENCIA DEL PROTOTIPO ......................................................................................... 91 Ingreso al Sistema ....................................................................................................... 91 Administrando Docentes ............................................................................................ 91 Administrando Estudiantes......................................................................................... 92 Administrando listado de Tutorías ............................................................................. 94 Registrando una tutoría .............................................................................................. 95 Reportes ...................................................................................................................... 96 Tutoria en WORD .................................................................................................... 96 Docentes en PDF ..................................................................................................... 97 Docentes en Excel para exportación de datos ........................................................ 98 CONCLUSIONES: ............................................................................................................. 99 Bibliografía .................................................................................................................... 101 LINKOGRAFIA ................................................................................................................ 102

INTRODUCCION RESUMEN DEL PROYECTO El presente proyecto de Investigación generativa pretende adentrarse en el análisis de las características intrínsecas de la Tutoría universitaria, mediante un análisis comparativo de realidades mundiales con una visión de síntesis y aplicación real de los conceptos fundamentales y características más destacadas de los Conceptos pedagógicos, legales y curriculares de la aplicación de metodologías de tutorías universitarias. Se realiza un análisis en diferentes niveles, presentando ejemplo y experiencias de universidades a nivel europeo, latinoamericano y nacional

de forma que las

experiencias positivas sean recogidas como criterios de aplicación dentro de la PUCESA. La presente investigación, entonces, procura en primera instancia enmarcar una metodología de aplicación de Tutorías en la PUCESA, luego en base a los criterios recogidos de las mejores prácticas y los conceptos generales de Autoridades, Administrativos y Docentes de la PUCESA generar una propuestas innovadoras y de utilidad para el mejoramiento continuo de los procesos académicos en la PUCESA, busca la automatización y la generación de soluciones enmarcadas en las TIC’s. En esta ocasión se buscar generar un proyecto novedoso, que cubra las necesidades de la comunidad académica, mediante la determinación y automatización de los procesos de Tutorías Docentes. Se busca determinar con claridad todas las, actividades, actores, datos y detalles procedimentales utilizando la Metodología de Lenguaje Unificado de Modelado (UML) y de Desarrollo De Software por Prototipos. La determinación de procesos nos llevará a la definición de módulos y clases codificadas que

permitirán la notación de soluciones software general. La

particularidad de la investigación busca determinar; en este aspecto, la factibilidad de colocar un prototipo software en la plataforma tecnológica de la PUCESA sin que esto determine cambios significativos de soporte hardware

CAPITULO I EL PROBLEMA TEMA Análisis y Diseño de un Prototipo software para la Administración de Tutorías Docentes para la PUCESA

ANTECEDENTES O CONTEXTUALIZACION La educación universitaria en el contexto actual

El modelo de educación superior que ha permanecido relativamente estable durante más de cien años y al que estamos ya acostumbrados, está fuertemente cuestionado y forzado a adaptarse a un entorno donde los cambios se producen cada vez con más rapidez (Beede y Burnett, 1999). Como resultado, nos encontramos con que a la universidad le resulta cada vez más complejo generar nuevas estrategias y servicios que satisfagan las necesidades de sus estudiantes. Durante siglos, los estudiantes han acudido a las universidades para adquirir un mayor conocimiento, explorar nuevas teorías, descubrir nuevos conceptos, adquirir nuevas habilidades y, probablemente, seguirá siendo así en el futuro. Sin embargo, hay notables diferencias entre el ayer y el hoy. La economía global, las nuevas tecnologías y las facilidades en los desplazamientos, por ejemplo, ofrecen a los estudiantes muchas más oportunidades de aprendizaje que antes. ¿Cómo deben responder las instituciones educativas? Tenemos que aceptar el cambio como un reto actual y pasar de una enseñanza pasiva a una enseñanza que comprenda, responda y rebase las necesidades de nuestros estudiantes. Tendremos

que pasar, como sostiene Klenk (1999), de “vernos como monopolios regionales o nacionales de capital intelectual a vigorosos competidores para usuarios en un mercado global” (p. 183). Hay que transformar una enseñanza tradicional que “se enfrenta a los estudiantes” y dotar a las organizaciones de estrategias y servicios basados en los usuarios que hagan más viable nuestras instituciones. Transformación significa la idea de replantear las cosas que hacemos en nuestros centros con los estudiantes. Es moverse de la enseñanza al aprendizaje, de ver a los estudiantes como una audiencia pasiva a una audiencia colaboradora. La transformación hace referencia a las siguientes cuestiones: • Replantear qué es lo que queremos que sean nuestras instituciones. • Identificar quiénes deberían ser nuestros usuarios. • Decidir qué programas y servicios se van a ofertar. • Crear programas y servicios basados en referentes de calidad. • Asegurarse que nuestros usuarios tengan las competencias necesarias. • Construir la infraestructura tecnológica adecuada a las nuevas necesidades de información de nuestros usuarios.

Cambios significativos en los estudiantes de Hoy

Según (Upcraft y Stephens, 2000),nos encontramos con: a) Actitudes y valores cambiantes. Comparados con los estudiantes de finales de los sesenta, los estudiantes de hoy son más conservadores; menos interesados en desarrollar una filosofía de vida dotada de un sentido más profundo; más interesados en hacer dinero; más preocupados en obtener un puesto de trabajo al finalizar sus estudios universitarios; más interesados en el campo de los negocios, la informática y la ingeniería; y menos interesados en las humanidades, las artes y las ciencias sociales.

b) Dinámicas familiares cambiantes. Implicación de las situaciones familiares en los tipos de estudiantes que tenemos en las instituciones de educación superior (familias divorciadas, experiencia de vida con un solo padre, alumnos que a su vez están divorciados o son padres-madres solteros, situaciones de violencia familiar, abusos sexuales y problemas de drogas, etc…). Estas situaciones provocan determinados desajustes que inciden notablemente en el aprendizaje de los estudiantes. c) Cambios en la salud física y mental. Hace 30 años, en aquellos centros donde se ofertaban Servicios de Orientación, los principales problemas de los estudiantes estaban relacionados con la experiencia académica universitaria, como indecisiones vocacionales, dificultades académicas y problemas de relación; es decir, estudiantes “normales” con problemas “normales”. En los momentos actuales, el cuadro es distinto. Hay un aumento de trastornos emocionales, violencia, ansiedad, depresión, drogas, trastornos alimentarios, etc… que influyen y, en muchos casos, deterioran la salud física de los estudiantes. d) Cambios en la preparación académica. Disfunción de los niveles de preparación de la educación secundaria y su incidencia en el rendimiento universitario. Es ya un discurso clásico la queja del profesorado universitario respecto a la mala preparación de sus estudiantes hasta el punto de diseñar materias curriculares destinadas a lograr el “nivel requerido” en determinadas titulaciones. e) Cambios en las fuentes de financiación. Ayudas económicas diversas que reciben los estudiantes y aumento en los tipos de becas (programas nacionales, locales-propios de cada universidad, programas de matriculación difrenciada, etc…). Por otra parte, aumentan los estudiantes que trabajan y estudian. En estos momentos el tema de la financiación de las universidades está en la agenda de discusión en todos los foros universitarios. Es previsible que tenga

repercusiones en los costos de la enseñanza y esto se traduzca en un notable aumento en la aportación económica de las familias.

PROGNOSIS La realización de un prototipo de software que permita manejar los procesos de tutorías en la PUCESA permitirá enmarcar las actividades de docentes y estudiantes en un campo de acción de tutorías universitarias. El presente estudio nos dará a conocer en forma comparativa las mejores prácticas en el ámbito mundial, latinoamericano y nacional dentro de los procesos de acompañamiento docente en ambientes universitarios. Así se espera que la herramienta software provea a la comunidad universitaria mecanismos de administración, ejecución y de viabilidad a los procesos de tutorías en la PUCESA.

PLANTEAMIENTO DEL PROBLEMA

Los Cambios Universitarios en los ámbitos Legales, administrativos, Requieren adaptaciones institucionales que crean nuevos espacios de interacción y formación académica. La PUCE Sede Ambato no ajena a su responsabilidad social se viene insertando en los cambios nacional y universalmente requeridos en el ámbito de la formación universitaria. Es así que desde Agosto del 2011 viene ejecutando proyectos de tutoría con los estudiantes de todas la Unidades Académicas. Esta actividad propia del quehacer universitario ha venido generando un conjunto de datos e información que necesita ser correctamente administrada. Este es el ámbito que genera el problema de Investigación: El tratamiento adecuado de los datos e información de los procesos de tutorías en la PUCE Sede Ambato.

DEFINICIÓN DEL PROBLEMA

Los continuos procesos de cambio y adaptación académica a los requerimientos sociales ha enfrentado continuamente a la comunidad de la PUCE Sede Ambato a la redefinición de los roles de los docentes, en esta ocasión el rol de TUTOR genera para la institución un gran volumen de información que no está siendo adecuadamente procesada. En este ámbito el presente proyecto de investigación plantea la GENERACION de un PROTOTIPO SOFTWARE, adaptado a las realidades institucionales, que permita un adecuado tratamiento de los datos y presente a los diferentes usuarios institucionales información útil dentro de los procesos de toma de decisiones.

DELIMITACIÓN DEL PROBLEMA

DELIMITACIÓN DE CONTENIDO Área: NTIC’s Campo: Desarrollo de Software Tema: Sistema Informático de Tutorías Universitarias DELIMITACIÓN ESPACIAL El presente trabajo de investigación se lo realizará en las áreas de estudio de la TUTORIA UNIVERSITARIA en la PUCESA. DELIMITACIÓN TEMPORAL El presente trabajo de investigación se lo realizará en un marco de 12 meses de trabajo a razón de 12 horas de trabajo efectiva por semana.

OBJETIVOS DEL PROYECTO: Objetivo general Analizar y Diseñar un Prototipo software para la Administración de Tutorías Docentes para la PUCESA

Objetivos específicos: •

Determinar procesos, actores, flujos de datos y

clases utilizando la

metodología de Lenguaje Unificado de Modelado UML. •

Generar un modelo del proceso de Tutorías Docentes en la PUCESA.

•

Generar componentes software que permitan la automatización del Modelo.

•

Programar un prototipo software en la plataforma tecnológica de la PUCESA.

•

Publicar los resultados de la investigación en la PUCESA y recoger nuevos requerimientos para reiniciar el ciclo de vida de Prototipos de Software.

METAS Y RESULTADOS ESPERADOS DEL PROYECTO:

•

Al finalizar el proyecto se espera contar con un modelo de tutorías aplicado a la PUCESA y respectiva aplicación en un prototipo software funcional que pueda ser piloteado en cualquier unidad académica.

Lo que no hará el Prototipo:

•

El sistema no contará con dependencias con los sistemas: ESCOSOFT, Sistema de Seguimiento Académico, Sistema de Evaluación Docente, y de otros aplicados en la PUCESA, por lo que no se mostrarán datos ni se integran resultados ni procesos de las mencionadas y otras aplicaciones

software de la PUCESA. De los resultados del proyecto se desprenderán

nuevas opciones y requerimientos para una próxima versión del sistema. •

No contará con datos históricos archivados de estudiantes y/o docentes de períodos anteriores, registro académico, asistencias o evaluaciones.

CAPITULO II

MARCO TEORICO ANTECEDENTES INVESTIGATIVOS Marco legal de la Tutoría Análisis Europeo

La educación superior en Europa ha adoptado sistemas muy diferentes para responder a las necesidades de orientación de los estudiantes que acogen. En concreto, Gellert (1993) señala que las universidades inglesas tradicionalmente han mostrado un mayor interés por fomentar el desarrollo personal de sus estudiantes mientras que en las universidades germánicas ha existido una mayor tradición en el conocimiento y la investigación y el sistema francés ha puesto un mayor énfasis en el desarrollo profesional. Esta diversidad de concepciones constituye uno de los motivos principales por el que la implantación de las ideas de orientación y tutoría son tan divergentes y adoptan sistemas diferentes de unos países a otros. En España, al igual que en la mayoría de países europeos, los servicios de Orientación Psicopedagógica (de marcado carácter psicologista) y la tutoría comienzan a potenciarse en las universidades como consecuencia de las concepciones señaladas anteriormente y de la necesidad de dotar de contenido a la acción tutorial del profesorado como función complementaria a su tarea docente. Así se refleja en diversos documentos y textos legales. En Educación Primaria y Secundaria es la LOGSE quien fija el modelo organizativo a seguir (por primera vez se crean a partir de 1992 los Departamentos de Orientación en los I.E.S.). En el nivel universitario se crea un equipo que elabora el Informe Universidad 2000 (Bricall, 2000) que en el apartado 4 contempla la figura del profesor asesor o tutor del

estudiante como un recurso para que este pueda recibir una asistencia más personalizada en la búsqueda de su itinerario curricular y en su aprendizaje. Así, en el apartado 4 – dentro de los Sistemas de Apoyo a la Enseñanza – rescato algunos párrafos: 4.2. Asesoramiento. 54. En este contexto, una parte del profesorado (o una parte del tiempo que se destina a actividades docentes) deberá asignarse a tareas de asesoramiento de los estudiantes, en necesaria cooperación con técnicos y profesionales especializados en estas cuestiones. Las instituciones de enseñanza superior deberán establecer esta clase de servicios como una parte central de sus prestaciones. […] En cambio, el tipo de asesoramiento y apoyo al estudiante que aquí se postula ha de tener un alcance universal, con una consideración de servicio esencial de las universidades. A este efecto podrá encomendarse a cada profesor o tutor un número determinado e identificado de estudiantes. 55. Este asesoramiento ha de abarcar las diferentes fases de la vida académica del estudiante, es decir: Asesoramiento previo al ingreso a la Universidad […], Preparación y desarrollo de las habilidades educativas […], Planificación de los estudios […], Apoyos especiales, en casos de crisis o dificultades particulares de algunos estudiantes. Asesoramiento y apoyo al desenvolvimiento formativo de los estudiantes […], Participación en la evaluación de los estudiantes, y orientación Profesional […] 56. En ningún caso el asesor ha de suplantar al estudiante en la toma de decisiones. Su papel consiste, exclusivamente, en ayudarlo a decidir por su cuenta, guiándole a tomar alternativas y examinando, conjuntamente con él, las posibles consecuencias de sus decisiones. Tampoco los asesores han de ser considerados asesores psicológicos ni han de tratar temas emocionales que se aparten del comportamiento normal del estudiante. Por su parte la LOU (Ley Orgánica de Universidades) incorpora en el artículo 1, dentro de las funciones de la Universidad, una idea básica ( lifelong learning ) contemplada

en los distintos documentos declaratorios de la Convergencia Europea y en el artículo 46 relativo a los Derechos y deberes de los estudiantes destaca la función tutorial. Artº 1. 2. Son funciones de la Universidad al servicio de la sociedad: […] d) La difusión del conocimiento y la cultura a través de la extensión universitaria y la formación a lo largo de toda la vida. Artº. 46. Derechos y deberes de los estudiantes. 2. En los términos establecidos por el ordenamiento jurídico, los estudiantes tendrán derecho a: […] c) La orientación e información por la Universidad sobre las actividades de la misma que les afecten. […] e) El asesoramiento y asistencia por parte de profesores y tutores en el modo en que se determine. Como resultado de estas tendencias en España y el resto de universidades europeas, Watts y Esbroeck (2000) realizaron un estudio comparado sobre los servicios de Orientación en la Educación Superior de los países de la Unión Europea. En dicho estudio detectaron que dichos servicios habían aumentado en importancia los últimos años y que las transformaciones iban en una cuádruple dirección. a. Una mayor atención en los momentos previos a la entrada en la universidad como medio para facilitar la toma de decisiones del alumnado y su mayor ajuste vocacional. Tarea importante realizada en España por la colaboración establecida entre los Departamentos de Orientación de los IES y la mayoría de Universidades aunque llevada a cabo con desigual fortuna.

b. Una atención cada vez mayor a los estudiantes en el momento de su ingreso en la Universidad como medio de reducir los cambios y abandonos académicos y que permita una decisión estable y un aprendizaje efectivo. No hay universidad o facultad que se precie que no tenga ya institucionalizadas unas jornadas de bienvenida a los estudiantes. Sin embargo, cuanto de escaparate, improvisación y ausencia de norte se observa en muchos casos. c. Un aumento en la prestación de servicios de orientación durante la etapa de estudios universitarios para evitar los índices de abandono o cambio de estudios por problemas personales o de aprendizaje que permita al alumnado una correcta elección del itinerario curricular más acorde a sus posibilidades e intereses en el diseño de su carrera y su futura empleabilidad. En las universidades españolas se está tratando de responder a este reto de ayuda a los estudiantes potenciando la acción tutorial del profesorado. La tutoría constituye el instrumento educativo “natural” por la cercanía existente entre profesor y alumno. d. Prestación de servicios de orientación en la salida de los estudios facilitando la transición hacia el mercado de trabajo que justifique de alguna manera la inversión pública que se ha hecho. Las universidades españolas están abordando este tema cada vez con más seriedad. Existen Unidades de Empleo y Prácticas en Empresas que facilitan esa transición. Qué duda cabe que la tutoría constituye un caudal de información y mediación de mucho valor. De las consideraciones legales y profesionales que hemos abordado, se desprende que la tarea de orientación a través de la tutoría universitaria, es contemplada desde una perspectiva política como un instrumento importante tanto para la eficiencia como para la equidad de la educación superior e igualmente para reconciliar ambas con la autonomía de los individuos (Watts et al., 1994).

El Proyecto PACENI – Secretaría de Políticas Universitarias – Gobierno Argentino El “PROYECTO DE APOYO PARA EL MEJORAMIENTO DE LA ENSEÑANZA EN PRIMER AÑO DE CARRERAS DE GRADO DE CIENCIAS EXACTAS Y NATURALES, CIENCIAS ECONÓMICAS E INFORMÁTICA ” o PACENI Aparece en el contexto latinoamericano, en el mes de Julio del 2008 como una política de la presidencia argentina, de la cual para el presente proyecto me permito recoger algunas de sus principales características:

Mediante Decreto Presidencial 154/2007 la Presidenta de la Nación Argentina declaró al año 2008 como el “Año de la Enseñanza de las Ciencias”. Algunos de los considerandos del decreto señalan; • Que la capacitación de los recursos humanos en una sociedad está dada por el desarrollo científico y tecnológico de su población; • Que, en este sentido, la sociedad actual demanda una ciudadanía científicamente alfabetizada a efectos de la toma de decisiones; • Que se consideró fundamental declarar el año 2008 como el “año de la Enseñanza de las Ciencias” permitiendo de esta manera efectuar el primer impulso articulando los esfuerzos de todos los actores individuales y colectivos vinculados a la actividad científica e instalando en la opinión pública el debate sobre la importancia de la formación científica básica como parte de la formación ciudadana.

Por otro lado en octubre del año 2006, el entonces Ministerio de Educación, Ciencia y Tecnología lanzó el Plan Nacional de Apoyo a la Enseñanza de la Informática, mediante el cual se preveía apoyar a las universidades nacionales en la formación de recursos humanos en distintos niveles académicos. Este plan comenzó a ejecutarse en 2007 con el Proyecto de Apoyo a la Formación de Técnicos Informáticos y con la incorporación de todas las carreras de Informática en el Subprograma Becas Prioritarias del Programa Nacional de Becas Universitarias.

Atendiendo a los antecedentes mencionados, la Secretaría de Políticas Universitarias en función de los datos consolidados de todas las Universidades Nacionales, inherentes a la cantidad de alumnos que ingresan a estudiar las carreras de Ciencias Exactas y Naturales, de Ciencias Económicas y de Informática mencionadas y al rendimiento académico observado a los mismos, considera que es prioritario llevar adelante acciones de apoyo para la mejora del rendimiento de los alumnos ingresantes, durante el primer año de desarrollo de la carrera. Este apoyo tendrá además un efecto directo en los años posteriores de cursado y fundamentalmente en las tasas de egreso.

De acuerdo a los datos consolidados, alrededor de un 40% de los estudiantes que cada año ingresan a la universidad abandonan su carrera en primer año, un porcentaje menor pero todavía importante, lo hacen en el segundo año. Algunos de esos estudiantes cambian de carrera y la mayoría abandona sus estudios. Se señalan diversas causas de ese tan alto nivel de fracaso. Algunas son externas a la universidad: los problemas socioeconómicos, las deficiencias de formación que se arrastran de los niveles anteriores de la educación, la falta de adecuada orientación vocacional, entre otras. Ante esta situación las universidades están desarrollando acciones de distinta naturaleza, pero todas con la misma finalidad; mejorar las condiciones de ingreso a través de acciones remediales que permitan ayudar a superar a los alumnos los problemas cognitivos, actitudinales y/o aptitudinales que les impiden integrarse con posibilidades reales de éxito a la enseñanza universitaria. También existen factores que son atribuibles a la estructura y al desarrollo del sistema universitario. Las peores condiciones para el aprendizaje se dan muchas veces en los primeros años, incluso en carreras y universidades que no tienen matriculaciones masivas. Los recursos son en general escasos (laboratorios, acceso a equipos de computación, disponibilidad de bibliografía, etc.) y las modalidades pedagógicas no necesariamente son las apropiadas para ayudar a los estudiantes en la difícil transición hacia la educación superior.

Ante esta situación, la Secretaría de Políticas Universitarias propone al sistema universitario la puesta en marcha de un Proyecto de Apoyo para el Mejoramiento de la Enseñanza de Grado en Primer Año para las Carreras de Ciencias Exactas y Naturales, Ciencias Económicas y de Informática. Se propone que la universidad, a través de este proyecto, ponga en marcha o consolide Sistemas de Tutorías e introduzca mejoras en la intensidad de la formación práctica de los alumnos ingresantes a través de la adquisición de equipamiento, software y bibliografía, así como también pueda prever acciones que mejoren la formación pedagógica de los docentes de primer año. Con su implementación se espera: a. Mejorar la formación básica y general. b. Mejorar los procesos de enseñanza y aprendizaje con énfasis en la problemática de la inserción plena de los alumnos en la universidad. c. Mejorar los índices de retención y rendimiento académico en el primer año. COMPONENTES Y ACTIVIDADES COMPONENTE A: Implementación o consolidación de sistemas de tutorías Actividades: 1. Asistencia técnica externa a la institución para la puesta en marcha o consolidación de proyectos de tutorías y/u orientación vocacional 2. Designación de tutores para la puesta en marcha de sistemas de tutorías y/u orientación al estudiante

COMPONENTE B: Actualización y perfeccionamiento de la planta docente Actividades:

1. Capacitación para docentes en temas pedagógicos y didácticos relacionados con la enseñanza de las disciplinas 2. Actualización en desarrollos recientes de las disciplinas 3. Producción de material didáctico para actividades de enseñanza presenciales y a distancia

COMPONENTE C: Actividades, Equipamiento, Software y Bibliografía para mejorar la Formación Práctica Actividades: 1. Equipamiento multimedia para apoyo a la docencia 2. Equipamiento e instrumental didáctico para talleres y laboratorios 3. Equipamiento informático para actividades curriculares 4. Bibliografía de texto 5. Software para la enseñanza en primer año 6. Mobiliario, elementos de seguridad e instalaciones menores necesarias para el equipamiento anterior. 7. Realización de actividades prácticas fuera del ámbito de la universidad.

Análisis Ecuatoriano

El Caso PUCE-Sede Ibarra

Desde el año 2005, se aplicó como plan piloto en las siguientes Escuelas: Ciencias Agrícolas y Ambientales (ECAA), y Gestión en Empresas Turísticas y Hoteleras

(GESTURH), obteniendo buenos resultados con los estudiantes que se beneficiaron de tal servicio. Desde el período académico Septiembre 2007 – Enero 2008 se extiende el programa hacia las demás Escuelas, a través de un Plan de Mejora coordinado por Dirección Académica. Al institucionalizarse este Programa, es necesario contar con un marco conceptual, que sirva como soporte para el respectivo procedimiento.

La tutoría se realizará para ofrecer una educación compensatoria a los alumnos que afrontan dificultades académicas. Se considera la tutoría como una actividad pedagógica destinada a orientar, encaminar, apoyar a los alumnos, durante el período de su formación académica. Por ningún motivo la tutoría sustituirá la labor del docente universitario de las respectivas asignaturas, al contrario es una actividad complementaria que radica en orientar al alumno a partir del conocimiento de sus problemas y necesidades académicas, así como de sus inquietudes y aspiraciones profesionales.

La tutoría es una tarea que se realizará para ofrecer una educación compensatoria o remediadora a los alumnos que afrontan dificultades académicas. Se manejará con flexibilidad; empleándola como una herramienta de apoyo en la formación de los estudiantes, en particular cuando éstos presentan falencias en el rendimiento académico y por ende experimentan dificultades que afectan su desempeño e inclusive su permanencia en la Universidad. OBJETIVO GENERAL Contribuir con la formación integral de los estudiantes universitarios de la PUCE SI, a través del servicio de tutorías con miras a mejorar su rendimiento académico. OBJETIVOS ESPECÍFICOS •

Identificar las dificultades académicas de los estudiantes en las distintas Carreras que oferta la PUCE-SI.

•

Organizar cada semestre el plan de tutorías en función de las necesidades identificadas.

•

Prevenir posibles deserciones de los estudiantes.

El Caso Universidad San Gregorio de Portoviejo La Universidad San Gregorio de Portoviejo ha considerado algunas de las siguientes condiciones: Que el proceso de evaluación y acreditación de las Universidades ecuatorianas demandan cumplir con los siguientes Estándares mínimos de la Calidad de la Educación Superior. Que el estatuto y los reglamentos de la Institución garanticen la efectividad académica y administrativa, así como la continuidad, viabilidad y práctica de las políticas definidas en el plan estratégico de desarrollo institucional. Que el quehacer docente, de acompañamiento y consejería esté debidamente reglamentado y tenga plena aplicación. Que durante el desarrollo del currículo los y las estudiantes reciban tutorías y asesoramiento académico eficiente y riguroso. Que la Institución genere periódicamente información cuali–cuantitativa sobre matrícula, promoción, repitencia, deserción, graduación, escolaridad y separación estudiantil. Que la Institución elabore estadísticas y emita reportes periódicos sobre la situación social, económica y académica de los estudiantes, que permitan diseñar programas académicos complementarios de asistencia educativa. Que la Institución tenga diseñado y en ejecución un programa de seguimiento a los egresados y graduados con soporte estadístico, que permita la toma de decisiones para el mejoramiento de la calidad y pertinencia de la currícula. Que la Institución disponga de políticas, medios y acciones concretas, que apoyen la inserción de sus egresados en el mercado laboral.

Y han aprobado un articulado del cual recojo para el presente trabajo lo siguiente: Artículo 1.- El presente Reglamento se sustenta en la siguiente legislación universitaria: I. Ley Orgánica de Educación Superior; II. Estatuto de la Universidad San Gregorio de Portoviejo; III. Reglamento de Régimen Académico; Para efecto de este Reglamento se considerarán los objetivos establecidos en el Programa Institucional de Tutoría los cuales son: General: Contribuir a la formación integral de los y las estudiantes, para mejorar la calidad de su proceso educativo así como potenciar capacidades que incidan en su beneficio personal, adquiriendo habilidades para la toma de decisiones y construir respuestas que atiendan tanto necesidades sociales, con un alto sentido de responsabilidad y solidaridad, como las exigencias individuales de su propio proyecto de vida. Específicos: 1. Facilitar el proceso de integración a la vida universitaria de los y las estudiantes que ingresan por primera vez a la institución, a través de la orientación en el acceso a los servicios universitarios y su inducción al uso adecuado de las instalaciones. 2. Contribuir a la disminución de los índices de deserción, reprobación, rezago académico y elevar la eficiencia terminal. 3.- Elevar la calidad del proceso formativo en el ámbito de la construcción de 0PÑvalores, destrezas, actitudes, hábitos y competencias. 4. Orientar a los y las estudiantes en la resolución de problemas relacionados directamente con los aspectos de índole académico. Artículo 2. - Las siguientes disposiciones del presente Reglamento establecen y fijan las bases para la ejecución del Programa Institucional de Tutorías Académicas.

ASPECTOS CONCEPTUALES DE LA TUTORÍA Artículo 3. - Para efecto de este Reglamento, la Tutoría Académica se concibe como un proceso de acompañamiento durante la formación de los y las estudiantes, que se concreta mediante la atención personalizada o grupal que se les brinde, por parte de Profesores-Consejeros, que buscan orientarlos y proporcionarles seguimiento a su trayectoria académica, en los aspectos psico-sociales, cognitivos y afectivos del aprendizaje, para fortalecer su formación integral y asegurar su permanencia y culminación de la carrera. Tutor.- Es el profesor acreditado con el fin de promover la formación integral a sus tutorados en los campos del conocimiento, habilidades, y valores éticos. Perfil: - Tener destreza en metodología científica y experiencia laboral en la asignatura en la cual se desempeñará como tutor. - Ser profesor categorizado de la Universidad de tiempo completo, medio tiempo o parcial con experiencia docente. - Conocer y estar comprometido con la filosofía, misión y visión de la Universidad y del Programa Institucional de Tutoría. - Haber participado activamente en los cursos de formación y capacitación. Tutorados.- Estudiantes que hayan sido detectadas sus dificultades académicas por el seguimiento de las correspondientes Direcciones de Carrera de la Universidad y los que soliciten y sean aceptados para recibir tutoría de acuerdo a este Reglamento. Perfil: - Estar matriculado y al día en sus obligaciones económicas con la Universidad - Tener la disposición para recibir la orientación y apoyo del profesor tutor. - La tutoría se efectúa de manera personalizada, debiendo organizarse los horarios en los que cada estudiante deba presentarse ante su docente tutor

Sistema Tutorial.- La tutoría consiste en el trabajo extra clase que efectúa el docente con el estudiante que presenta dificultades en el proceso pedagógico, pudiendo someterse también a este proceso, los estudiantes que quisieran potenciar los conocimientos adquiridos. Artículo 4.- Vinculación de los docentes al programa de tutorías: Es obligación de cada docente informar por escrito al Director de Carrera, dentro del plazo de tres semanas de clase contados desde el inicio del programa o cuando diagnostique la necesidad, sobre los estudiantes que presentan dificultades en el proceso de enseñanza aprendizaje en la asignatura correspondiente, quienes serán considerados de forma prioritaria dentro del programa de tutorías Artículo 5.- Selección de Tutores.- Es responsabilidad de los Directores de Carrera promover esta actividad dentro de cada una de las carreras, y establecer el horario para cada proceso de tutoría. Artículo 6.- Actividad Tutorial.- El tutor deberá elaborar un expediente del tutorado que incluya las siguientes fases: - Fase Inicial: Comprende el diagnóstico inicial del estudiante en base a su desempeño académico y el establecimiento de compromisos por ambas partes. - Fase de seguimiento: Mediante la verificación del mejoramiento del rendimiento académico del estudiante en el crédito inmediato posterior al inicio de las tutorías, hasta la finalización de la asignatura. - Fase de evaluación: Comprende los resultados alcanzados por el estudiante que deben ser incluidos en el informe entregado por el tutor al Director de Carrera. Cuando el docente determine que el estudiante no tiene problemas de rendimiento académico, sino de orden psicológico, ético o de salud se lo derivará a la Dirección de Bienestar Universitario Art. 7: Metodología de las tutorías: Las tutorías deberán realizarse siempre en forma personalizada, es decir, en una reunión académica entre el tutor y el estudiante que

presenta problemas en su rendimiento. En el caso de los estudiantes que desean potenciar sus conocimientos, se podrá dar tutorías individuales o grupales. Art. 8: Evaluación de Programa Tutorial por parte de la Dirección de Carrera: Se realizarán evaluaciones sistemáticas del programa de tutorías por parte de cada Director de Carrera, en el cual se analizará el cumplimiento de los objetivos generales y específicos del mismo, tomando en cuenta los siguientes indicadores: a) Cantidad de profesores participantes en el Programa de Tutorías de las Carreras b) Cantidad de estudiantes participantes en el Programa de Tutorías Académicas. c) Cumplimiento de los objetivos. d) Impacto del Programa de Tutorías sobre los estudiantes, en base a los indicadores de tasa de deserción y permanencia. e) Nivel de satisfacción de estudiantes y docentes participantes en el programa de tutorías Art. 9: Servicios institucionales de apoyo a la actividad tutorial: Los profesores tutores, tendrán dentro de los beneficios por su participación, los siguientes: a) Educación continua (cursos y talleres de apoyo al programa tutorial), b) Los profesores tutores pueden ser los propios profesores que están dictando la asignatura en la que el estudiante presenta dificultades u otro Docente que el Director de Carrera designe. c) Participar en el Centro de Gestión de Promoción Laboral y Apoyo al Egresado y Graduado. Art. 10: La Tutoría no incluye la dirección académica del docente con calificaciones o valoraciones que le permitan acreditar una asignatura al estudiante tutorado.

Marco de intervención de la tutoría y la orientación

Siendo el desarrollo del conocimiento y de la ciencia uno de los objetivos más importantes de la universidad, la naturaleza compleja de la sociedad y la composición diversa de los estudiantes nos conduce, en estos momentos, a una nueva consideración de los procesos y resultados del aprendizaje. En una sociedad postmoderna, sostienen Baxter y Terenzini (1999), la educación superior tiene que fomentar entre sus estudiantes el sentido de la responsabilidad ética y moral que les permita enfrentarse a los problemas complejos del mundo actual y del futuro. Habilidades como pensamiento crítico y reflexivo, obtener y evaluar evidencias, y hacer juicios razonados son también objetivos de aprendizaje en un mundo de múltiples perspectivas y de verdades interdependientes. La ciudadanía y la responsabilidad cívica requieren el aprendizaje de complejas habilidades no sólo cognitivas sino también afectivas. Si reconocemos que los estudiantes son participantes activos – no recipientes pasivos – de su propio aprendizaje, que abordan este proceso de muy diversas formas y que su desarrollo académico es producto de sus experiencias no sólo “dentro” sino también “fuera” de las clases, la conexión del proceso educativo con dichas experiencias constituye el eje central del aprendizaje (Stage, 1996; Terenzini, et al., 1995). Por otra parte, enseñar a los estudiantes en la búsqueda activa del conocimiento, en la evaluación de la información y, como consecuencia, a tomar las correspondientes decisiones requiere modelar estos procesos y practicarlos. Las tendencias actuales en la educación superior sugieren que el profesorado está adoptando un nuevo rol en sus clases no ya como instructor sino como facilitador del aprendizaje (Barr y Tagg, 1995). Desde esta perspectiva, los estudiantes – con la ayuda de profesores, tutores y compañeros – descubren y aprenden por sí mismos, se convierten en miembros de comunidades de aprendizaje donde hacen descubrimientos y solucionan problemas.

Estudiantes y profesores construyen juntos el apasionado mundo del conocimiento. La colaboración, el compromiso activo y la inclusión o aceptación son aspectos fundamentales que caracterizan estas nuevas formas de concebir los procesos de enseñanza-aprendizaje. Profesores y estudiantes colaboran juntos al igual que lo hacen los estudiantes con sus propios compañeros. Esta colaboración tiene lugar en comunidades de aprendizaje donde unos aprenden de otros y trabajan en torno a metas comunes. El compromiso activo implica compartir las experiencias aprendidas, integrar nuevas perspectivas en el pensamiento de cada cual y aplicar esos nuevos conocimientos en la propia vida. Estas formas de enseñanza son inclusivas porque invitan a una puesta en común voluntaria de las experiencias mutuas en el proceso de aprendizaje. Qué duda cabe que esta forma de concebir la enseñanza universitaria no está referida a la utilización de métodos particulares sino más bien a la forma en que los profesores-educadores conciben el conocimiento, la autoridad y la capacidad del estudiante que aprende. Estas tendencias se mueven hacia una nueva cultura de la enseñanza y el aprendizaje y la razón de ser del profesor como tutor universitario (Hutchings, 1997).

PERFIL DEL TUTOR UNIVERSITARIO

Claramente, a la luz de los cambios descritos anteriormente, la tutoría tiene múltiples roles y funciones que desempeñar. Así, nuestros roles están cambiando en la medida en que cambian también las características y, por tanto, las necesidades de nuestros estudiantes. Tendremos que implicarnos más en las siguientes cuestiones: a) Conocer a nuestros estudiantes. Parece algo obvio, pero los estudiantes de hoy no son como los estudiantes de ayer ni como los del mañana. Los perfiles internacionales y nacionales pueden no parecerse a los perfiles de la PUCESA. Por ejemplo, sería muy recomendable que las PUCESA

publique perfiles anuales de sus estudiantes comparándolos con generaciones anteriores. Después de tantos años ¿Qué sabemos sobre nuestros estudiantes? A menudo, oímos expresiones como: “Nosotros no utilizamos encuestas ni análisis de grupos para saber lo que necesitan nuestros estudiantes. Sabemos lo que ellos quieren”. O bien: “ Tenemos el horario en nuestro despacho y los estudiantes no hacen uso de la tutoría”. A veces, como evaluadores finales de nuestro trabajo, les preguntamos qué es importante para ellos, qué servicios esperan recibir de nosotros y, en cualquier caso, si lo estamos haciendo bien o no. Ellos esperan que les ayudemos a obtener el conocimiento y las competencias necesarias para generar sus oportunidades profesionales de futuro. Si preguntamos a nuestros estudiantes qué es importante para ellos y determinamos qué no se está haciendo a su plena satisfacción, llegaremos a la conclusión de poder determinar qué programas y servicios tenemos que ofrecerles. b) Crear entornos de aprendizaje. Helfgot y Culp (1995), describen una organización de aprendizaje como aquella “… capaz de controlar, modificar, mejorar o abandonar sobre la marcha, los programas que está llevando a cabo; crear nuevos servicios para satisfacer las necesidades de los usuarios; cuestionar Integración del estudiante en el sistema universitario; investigar las conexiones existentes entre la visión que se tiene del trabajo que se está haciendo y los valores y la actividad de aprendizaje del día a día” (p.45). En tales entornos, las dimensiones cognitivas y afectivas son vistas por el profesorado tutor como partes de un proceso; “construcción del conocimiento, adquisición de significado y conciencia del yo son partes integradas en el desarrollo del ser humano” (King y Baxter, 1996, p. 163). Los profesores pueden ayudar a los estudiantes a reconocer que su aprendizaje “en la clase” está relacionado con sus vidas “fuera de las clases”. Dedicar un tiempo a dialogar con los estudiantes sobre lo que aprenden y cómo lo hacen (Whitt, 1994), así como ayudarles a hacer conexiones, integrar y aplicar lo que están aprendiendo a su

vida o mundo real (Schroeder y Hurst, 1996), son formas de implicarse en su aprendizaje.

c) Inculcar valores. El documento The Student Learning Imperative (ACPA, 1996) recoge varios apartados sobre la educación superior en los que sostiene que a través del aprendizaje los estudiantes universitarios adoptarán un sistema de valores basados en el proceso de su experiencia educativa dentro y fuera del campus. De forma destacada, un estudiante universitario tendrá “un sentido coherente de identidad, autoestima, confianza, integridad, sensibilidad estética y responsabilidad cívica (ACPA, 1996). Adoptar un sistema de valores no tiene nada que ver con un sistema rígido de creencias, sino más bien “un movimiento hacia el fomento de la responsabilidad personal y de los demás y la habilidad para regirse por principios éticos” (Chickering y Reisser, 1993, p. 236). En otras palabras, un movimiento hacia la integridad. En los temas que hay múltiples perspectivas y respuestas diversas, los tutores pueden ayudar a los estudiantes a discernir qué es lo correcto sino también para comprender que más de una perspectiva puede ser correcta.

d) Fomentar el desarrollo comunitario. La experiencia universitaria abarca tanto la vida dentro como fuera del recinto universitario. El campus es una comunidad donde los estudiantes van a clase, hablan con sus profesores y con sus compañeros, practican deportes, participan en actividades culturales, …. Los estudiantes tienen que aprender a vivir dentro de esa comunidad. Mediante el contacto con otros estudiantes aprenden y desarrollan su personalidad. Aprenden a vivir dentro de un contexto social que va más allá de su círculo de amistades o familiar. Como profesionales tenemos que estar preparados para ayudarles a verse a sí mismos dentro de un contexto nuevo y más amplio en contenidos y acción (Satage, Watson y Terrell, 1999).

e) Conocer los recursos de nuestra institución y cómo acceder a ellos. A menudo los profesores tutores no pueden responder de manera directa a todas las necesidades que tienen los estudiantes; son limitados en sus habilidades para responder a todos los asuntos no estrictamente académicos. Sin embargo los tutores tienen que ser habilidosos diagnosticadores para remitir a sus estudiantes a otros servicios de la institución que puedan responder mejor a dichas necesidades. Esto implica que los tutores deben conocer dichos servicios. No sólo entregar al alumno un número telefónico de un determinado servicio y remitirlo sin más, sino que los tutores actuales necesitan conocer bien dichos servicios, el personal que trabaja en ellos y la necesidad del estudiante que deben atender o el tipo de servicio de información y ayuda que es requerida.

f) Defender la creación de los recursos humanos y materiales que sean necesarios. Conocer los recursos de la institución y cómo acceder a ellos supone que la institución tiene los recursos apropiados para ayudar a los estudiantes. Sin embardo, desgraciadamente, algunos recursos institucionales no responden a los perfiles cambiantes de nuestros estudiantes. Por ejemplo, los estudiantes adultos pueden ser desviados a programas de orientación donde se asume que todos los estudiantes vienen de los centros de secundaria y se dedican plenamente al estudio. Este tipo de estudiantes necesitan programas o servicios que cubran sus necesidades específicas como transporte, cuidado de los niños, estudio a tiempo parcial, trabajo, familia, responsabilidades universitarias…

g) Establecer programas de formación de tutores que respondan a las necesidades actuales de los estudiantes. En ocasiones, el profesorado universitario se queja o se lamenta que no comprende a sus estudiantes. Algunos creen que los estudiantes de hoy no consideran que la asistencia a clase es importante, no hacen las tareas asignadas o no prestan atención en clase. Con estudiantes diversos y necesidades diversas, los programas de formación

tienen que ayudar a los tutores a desarrollar las actitudes y habilidades necesarias para enfrentarse con garantías de éxito en sus tareas tutoriales (Coriat y Sanz, 2005). La falta de formación puede ser explicada por el hecho de que para ejercer la enseñanza no se requiere habilidad especial alguna. El profesorado, en general, es seleccionado no por su experiencia o preparación profesional para ejercer la docencia sino por sus conocimientos en la disciplina y su currículum investigador. No constituye ninguna sorpresa que en la mayoría de países europeos los niveles de exigencia para ejercer la tutoría en los niveles no universitarios sea de cierto nivel y, paradójicamente, la universidad, que es donde se preparan estos profesionales, no lo exija para sus propios profesores. Esto explica por qué los esfuerzos para mejorar la profesionalización en tutoría y orientación dentro de la educación superior estén divorciados de los procesos de enseñanza y aprendizaje. En cualquier caso, el profesorado, tradicionalmente, no ha percibido la tutoría y la orientación como parte de su rol como docentes.

h) Establecer relaciones de colaboración entre profesores tutores. Es importante que los profesores tutores ayuden a los estudiantes diseñando acciones que faciliten las oportunidades de aprender sobre sí mismos, sobre las relaciones con los demás, el contexto donde se encuentran y el mundo del conocimiento. Para ello deben establecer relaciones de colaboración que les permita diseñar, ejecutar y evaluar Planes de Acción Tutorial cuyo objetivo fundamental es dotar de contenido intencional a la tutoría mediante la fijación de metas y objetivos a alcanzar a través de la realización de diversas estrategias. i) Reconsiderar las políticas y las prácticas profesionales. En estos momentos la tutoría es una actividad burocrática. El compromiso del profesorado se reduce a un número de horas “colgado” en nuestro horario y centrado en el alumnado de la asignatura que impartimos. Si somos capaces de explicar las metas y objetivos, los contenidos, la metodología docente, las estrategias de evaluación y la bibliografía de nuestro Proyecto Docente, es decir, si tenemos un Plan

Docente que ofrecer al alumnado, ¿Por qué no se incluye a la tutoría dentro de ese Plan? Habrá, pues que reconsiderar nuestras estrategias como profesionales en la educación superior. Hay unas cuestiones básicas que merecen nuestra atención: ¿Nuestras políticas y prácticas profesionales inciden positivamente en nuestros estudiantes? ¿Ven los estudiantes el ejercicio de la tutoría como algo normal y habitual y, por tanto, aumenta su uso y participación? ¿Qué y cómo debemos hacer para favorecer esta situación?

j) Estar alerta a los problemas personales que puedan inhibir el aprendizaje. Los estudiantes con problemas personales son más propensos a obtener un bajo rendimiento y un alto índice de abandono que los estudiantes con un desarrollo evolutivo sano (Pascarella y Terenzini, 1991). Hace 30 años, se remitía a estos estudiantes a servicios especializados (Servicios de Orientación) dentro o fuera de la institución hasta que resolvieran sus problemas personales. Hoy en día, la mayoría de instituciones asumen alguna responsabilidad de ayuda cuando se encuentran con estudiantes en esas situaciones. No estoy sugiriendo que los tutores se conviertan en psicoterapeutas o trabajadores sociales, sino, simplemente, que estar alerta a los problemas personales que pueden obstaculizar el éxito académico de nuestros estudiantes es una parte esencial de ser un tutor efectivo para los estudiantes de hoy en día. El fracaso a la hora de responder satisfactoriamente a los retos que acabamos de describir limitará las competencias de nuestros estudiantes para lograr sus metas educativas y disminuirá, por ello, la calidad ofrecida por nuestras instituciones universitarias.

SOFTWARE Es importante entender este concepto para poder pasar a hablar a continuación lo que es el desarrollo del software, poder establecer una metodología y aplicarla al contexto educativo. Algunas definiciones de software: IEEE Std. 610 define el software como “programas, procedimientos y documentación y datos asociados, relacionados con la operación de un sistema informático” Según el Webster’s New Collegiate Dictionary (1975), “software es un conjunto de programas, procedimientos y documentación relacionada asociados con un sistema, especialmente un sistema informático”. El software se puede definir como el conjunto de tres componentes: •

Programas (instrucciones): este componente proporciona la funcionalidad deseada y el rendimiento cuando se ejecute.

•

Datos: este componente incluye los datos necesarios para manejar y probar los programas y las estructuras requeridas para mantener y manipular estos datos.

•

Documentos: este componente describe la operación y uso del programa.

Componentes del software

Es importante contar con una definición exhaustiva del software ya que de otra manera se podrían olvidar algunos componentes. Una percepción común es que el software sólo consiste en programas. Sin embargo, los programas no son los únicos componentes del software. Programas

Los programas son conjuntos de instrucciones que proporcionan la funcionalidad deseada cuando son ejecutadas por el computador. Están escritos usando lenguajes específicos que los ordenadores pueden leer y ejecutar. Datos

Los programas proporcionan la funcionalidad requerida manipulando datos. Usan datos para ejercer el control apropiado en lo que hacen. El mantenimiento y las pruebas de los programas también necesitan datos. El diseño del programa asume la disponibilidad de las estructuras de datos tales como bases de datos y archivos que contienen datos. Documentos

Además de los programas y los datos, los usuarios necesitan también una explicación de cómo usar el programa. Documentos como manuales de usuario y de operación son necesarios para permitir a los usuarios operar con el sistema. Los documentos también son requeridos por las personas encargadas de mantener el software para entender el interior del software y modificarlo, en el caso en que sea necesario.

DESARROLLO DE SOFTWARE

Desarrollar un software no significa construirlo simplemente mediante su descripción. Está es una muy buena razón para considerar la actividad de desarrollo de software como una ingeniería. En un nivel más general, la relación existente entre un software y su entorno es clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos en el mismo.

Una de las mayores deficiencias en la práctica de construcción de software es en general que los desarrolladores se centran en la solución dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solución. Esta aproximación orientada a la solución puede funcionar en campos donde todos los problemas son bien conocidos, clasificados e investigados, donde la innovación se ve en la detección de nuevas soluciones a viejos problemas. Pero el desarrollo de software no es un campo con tales características. La versatilidad de las computadoras y su rápida evolución hace que exista un repertorio de problemas en constante cambio y cuya solución software sea de enorme importancia. Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el analista de sistema quien es el encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores quienes son las personas encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo y lo instalan al cliente. Es así como intervienen varias personas ya que una sola persona no podría determinar todo lo necesario lo mas seguro que le haga falta algún requerimiento o alguna parte del nuevo sistema y entre mas estén involucradas mejor para cubrir con todos los requerimientos del sistema. (Lamentablemente y pos la estructura adoptada para el desarrollo de proyectos de investigación de la PUCESA, el presente trabajo se ha realizado unipersonalmente)

PROCESO

El proceso de desarrollo del software se muestra gráficamente en la imagen anterior, a continuación desarrollara una breve explicación del mismo. El primer paso del proceso es el análisis, es aquí donde el analista se pone en contacto con la empresa para ver como esta conformada, a que se dedica, saber todas las actividades que realiza en si, conocer la empresa de manera general para posteriormente ver cuales son sus necesidades o requerimientos que la empresa tiene en ese momento para poder realizar un análisis de la misma. Es importante saber cuales son los requerimientos que la empresa tiene por que muchas veces los sistemas se desarrollan pero no pensando en el cliente y es ahí donde el sistema no cumple o no satisface las necesidades que existen en la empresa, según los requerimientos se empieza a realizar el diagrama relacional todo debe de llevar una secuencia lógica de las actividades, todo esto se realiza de manera manual para ver como será su diseño lógico y diseño de pantallas es en este paso donde se plasma todo y queda perfectamente bien definido como va hacer la funcionalidad del sistema. El segundo paso es el de diseño aquí entran todo el diseño del sistema es decir las pantallas, base de datos, todo esto debe de cumplir con ciertos estándares los cuales se toman en cuenta para poder desarrollar el diseño con calidad y así poder ofrecer un diseño amigable en cuestión de colores, tamaños de botones, cajas de texto, etc. El tercer paso es la codificación es aquí donde se desarrolla todo el código del sistema por parte del programador esto se hace ya dependiendo de cada programador ya que cada programador tiene sus bases o formas para realizarlo pero en si deben todos llegar al mismo objetivo de ofrecerle funcionalidad al sistema siempre y cuando apegando se a las especificaciones del cliente. El cuarto paso son las pruebas, (En el presente proyecto esta parte del proceso de software no ha sido realizada) es donde al sistema se pone a prueba como su palabra lo dice para así poder saber cuales son los posibles errores que se están generando del sistema y con ello mejorarlo para eliminar todos los errores que se puedan presentar por que un programa con menor errores mayor calidad puede llegar a tener.

CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). También se denomina a veces paradigma. Entre las funciones que debe tener un ciclo de vida se pueden destacar: Determinar el orden de las fases del proceso de software Establecer los criterios de transición para pasar de una fase a la siguiente Definir las entradas y salidas de cada fase Describir los estados por los que pasa el producto Describir las actividades a realizar para transformar el producto Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar… Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se van produciendo (realimentación). Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Entregables: son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software). Los entregables permiten evaluar la

marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos.

TIPOS DE MODELO DE CICLO DE VIDA Las principales diferencias entre distintos modelos de ciclo de vida están en: El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o en el extremo, toda la historia del producto con su desarrollo, fabricación y modificaciones posteriores hasta su retirada del mercado. Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto, o de la organización. La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).

MODELOS DE CICLO DE VIDA La ingeniería del software establece y se vale de una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del software”. El primer modelo concebido fue el de Royce, más comúnmente conocido como Cascada o “Lineal Secuencial”. Este modelo establece que las diversas actividades que se van realizando al desarrollar un producto software, se suceden de forma lineal. Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en que se ejecutan las fases. Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas etapas.

Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software Define las fases primarias esperadas de ser ejecutadas durante esas fases Ayuda a administrar el progreso del desarrollo Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo de software En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y la elección de un modelo para un determinado tipo de proyecto es realmente importante; el orden es uno de estos puntos importantes. Existen varias alternativas de modelos de ciclo de vida. A continuación se muestran algunos de los modelos tradicionales y más utilizados. Modelo en cascada Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida. Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido ampliamente en la ingeniería el software. La innovación estuvo en la primera vez que la ingeniería del software fue dividida en fases separadas. La primera descripción formal del modelo en cascada se cree que fue en un artículo publicado en 1970 por Winston W. Royce, aunque Royce no usó el término cascada en este artículo. Irónicamente, Royce estaba presentando este modelo como un ejemplo de modelo que no funcionaba, defectuoso.

En el modelo original de Royce, existían las siguientes fases: 1. Especificación de requisitos 2. Diseño 3. Construcción (Implementación o codificación) 4. Integración 5. Pruebas 6. Instalación 7. Mantenimiento

Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma puramente secuencial.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido a día de hoy. Ventajas El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación. Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.

Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar. Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables específicos y un proceso de revisión. Las fases son procesadas y completadas de una vez. Inconvenientes En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. Difícilmente un cliente va a establecer al principio todos los requisitos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. Esto también implica el tener que tratar con requisitos que no se habían tomado en cuenta desde el principio, y que surgieron al momento de la implementación, lo cual provocará que haya que volver de nuevo a la fase de requisitos. Hay muchas personas que argumentan que es una mala idea en la práctica, principalmente a causa de su creencia de que es imposible, para un proyecto no trivial, conseguir tener una fase del ciclo de vida del producto software perfecta antes de moverse a las siguientes fases. Por ejemplo, los clientes pueden no ser conscientes exactamente de los requisitos que quieren antes de ver un prototipo del trabajo; pueden cambiar los requisitos constantemente, y los diseñadores e implementadores pueden tener poco control sobre esto. Si los clientes cambian sus requisitos después de que el diseño está terminado, este diseño deberá ser modificado para acomodarse a los nuevos requisitos, invalidando una buena parte del esfuerzo. Muchas veces se considera un modelo pobre para proyectos complejos, largos, orientados a objetos y por supuesto en aquellos en los que los requisitos tengan un

riesgo de moderado a alto de cambiar. Genera altas cantidades de riesgos e incertidumbres. Variantes Existen muchas variantes de este modelo. En respuesta a los problemas percibidos con el modelo en cascada puro, se introdujeron muchos modelos de cascada modificados. Estos modelos pueden solventar algunas o todas las críticas del modelo en cascada puro. De hecho muchos de los modelos utilizados tienen su base en el modelo en cascada. Uno de estos modelos modificados es el modelo Sashimi. El modelo sashimi (llamado así porque tiene fases solapadas, como el pescado japonés sashimi) fue creado originalmente por Peter DeGrace. A veces se hace referencia a él como el modelo en cascada con fases superpuestas o el modelo en cascada con retroalimentación. Ya que las fases en el modelo sashimi se superponen, lo que implica que se puede actuar durante las etapas anteriores. Por ejemplo, ya que las fases de diseño e implementación se superpondrán en el modelo sashimi, los problemas de implementación se pueden descubrir durante las fases de diseño e implementación del proceso de desarrollo. Esto ayuda a aliviar muchos de los problemas asociadas con la filosofía del modelo en cascada.

MODELO EN V El modelo en v se desarrolló para terminar con algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar

con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de entregables de pruebas. Los productos de trabajo generados por los desarrolladores y analistas de negocio durante el desarrollo son las bases de las pruebas en uno o más niveles. El modelo en v es un modelo que ilustra cómo las actividades de prueba (verificación y validación) se pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v, las pruebas de validación tienen lugar especialmente durante las etapas tempranas, por ejemplo, revisando los requisitos de usuario y después por ejemplo, durante las pruebas de aceptación de usuario. El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el desarrollo del producto. La parte izquierda de la v representa la descomposición de los requisitos y la creación de las especificaciones del sistema. El lado derecho de la v representa la integración de partes y su verificación. V significa “Validación y Verificación”.

Realmente las etapas individuales del proceso pueden ser casi las mismas que las del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificación,

formando una v. La razón de esto es que para cada una de las fases de diseño se ha encontrado que hay un homólogo en las fases de pruebas que se correlacionan. Ventajas

Las ventajas que se pueden destacar de este modelo son las siguientes: •

Es un modelo simple y fácil de utilizar.

•

En cada una de las fases hay entregables específicos.

•

Tiene una alta oportunidad de éxito sobre el modelo en cascada debido al desarrollo de planes de prueba en etapas tempranas del ciclo de vida.

•

Es un modelo que suele funcionar bien para proyectos pequeños donde los requisitos son entendidos fácilmente.

Inconvenientes

Entre los inconvenientes y las críticas que se le hacen a este modelo están las siguientes: •

Es un modelo muy rígido, como el modelo en cascada.

•

Tiene poca flexibilidad y ajustar el alcance es difícil y caro.

•

El software se desarrolla durante la fase de implementación, por lo que no se producen prototipos del software.

•

El modelo no proporciona caminos claros para problemas encontrados durante las fases de pruebas

MODELO ITERATIVO Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.

Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente.

Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

Ventajas Una de las principales ventajas que ofrece este modelo es que no hace falta que los requisitos estén totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando en cada una de las iteraciones. Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo en pequeños ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregas…

Inconvenientes

La primera de las ventajas que ofrece este modelo, el no ser necesario tener los requisitos definidos desde el principio, puede verse también como un inconveniente ya que pueden surgir problemas relacionados con la arquitectura.

MODELO DE DESARROLLO INCREMENTAL El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación. Ventajas Entre las ventajas que puede proporcionar un modelo de este tipo encontramos las siguientes: •

Mediante este modelo se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software.

•

Es un modelo más flexible, por lo que se reduce el coste en el cambio de alcance y requisitos.

•

Es más fácil probar y depurar en una iteración más pequeña.

•

Es más fácil gestionar riesgos.

•

Cada iteración es un hito gestionado fácilmente

Inconvenientes Para el uso de este modelo se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada. Entre los inconvenientes que aparecen en el uso de este modelo podemos destacar los siguientes: •

Cada fase de una iteración es rígida y no se superponen con otras.

•

Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio.

MODELO EN ESPIRAL El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniería del software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgos, comenzando por el bucle anterior. Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de esfuerzos y tiempo que se consume en hacer productos software; y modelos de ciclo de vida, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: el Modelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgos

más asumibles y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo. Este modelo de desarrollo combina las características del modelo de prototipos y el modelo en cascada. El modelo en espiral está pensado para proyectos largos, caros y complicados. Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en explicar las iteraciones. Este modelo fue propuesto por Boehm en 1988 en su artículo “A Spiral Model of Software Development and Enhancement”. Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamente ha de ser así. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un sistema operativo.

Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos. Tareas:

Para cada ciclo habrá cuatro actividades: 1. Determinar o fijar objetivos: a) Fijar

también

los

productos

definidos

obtener:

requerimientos,

especificación, manual de usuario. b) Fijar las restricciones c) Identificación de riesgos del proyecto y estrategias alternativas para evitarlos d) Hay una cosa que solo se hace una vez: planificación inicial o previa 2. Análisis del riesgo:

a) Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos 3. Desarrollar, verificar y validar (probar): a) Tareas de la actividad propia y de prueba b) Análisis de alternativas e identificación de resolución de riesgos c) Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. 4. Planificar: a) Revisamos todo lo que hemos hecho, evaluándolo y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. El proceso empieza en la posición central. Desde allí se mueve en el sentido de las agujas del reloj.

Las cuatro regiones del gráfico son: • La tarea de planificación: para definir recursos, responsabilidades, hitos y planificaciones • La tarea de determinación de objetivos: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas • La tarea de análisis de riesgos: para evaluar riesgos tanto técnicos como de gestión • La tarea de ingeniería: para diseñar e implementar uno o más prototipos o ejemplos de la aplicación

Ventajas El análisis de riesgos se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. Entre ellos: •

Reduce riesgos del proyecto

•

Incorpora objetivos de calidad

•

Integra el desarrollo con el mantenimiento

Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con el modelo, ya que el ciclo de vida no es rígido ni estático. Mediante este modelo se produce software en etapas tempranas del ciclo de vida y suele ser adecuado para proyectos largos de misión crítica. Inconvenientes Es un modelo que genera mucho trabajo adicional. Al ser el análisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos (es bastante difícil). Esto puede llevar a que sea un modelo costoso. Además, no es un modelo que funcione bien para proyectos pequeños. Comparación con otros modelos La distinción más destacada entre el modelo en espiral y otros modelos de software es la tarea explícita de evaluación de riesgos. Aunque la gestión de riesgos es parte de otros procesos también, no tiene una representación propia en el modelo de proceso. Para otros modelos la evaluación de riesgos es una subtarea, por ejemplo, de la planificación y gestión global. Además no hay fases fijadas para la especificación de

requisitos, diseño y pruebas en el modelo en espiral. Se puede usar prototipado para encontrar y definir los requisitos. La diferencia entre este modelo y el modelo de ciclo incremental es que en el incremental se parte de que no hay incertidumbre en los requisitos iniciales; en este, en cambio, se es consciente de que se comienza con un alto grado de incertidumbre. En el incremental suponemos que conocemos el problema y lo dividimos. Este modelo gestiona la incertidumbre.

MODELO DE PROTOTIPOS Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

Ventajas Entre las ventajas que ofrece este modelo se pueden destacar las siguientes: Ofrece visibilidad del producto desde el inicio del ciclo de vida con el primer prototipo. Esto puede ayudar al cliente a definir mejor los requisitos y a ver las necesidades reales del producto. Permite introducir cambios en las iteraciones siguientes del ciclo. Permite la realimentación continua del cliente. El prototipo es un documento vivo de buen funcionamiento del producto final. El cliente reacciona mucho mejor ante el prototipo, sobre el que puede experimentar, que no sobre una especificación escrita. Este modelo reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Inconvenientes Entre los inconvenientes que se han observado con este modelo está el hecho de que puede ser un desarrollo lento. Además se hacen fuertes inversiones en un producto desechable ya que los prototipos se descartan. Esto puede hacer que aumente el coste de desarrollo del producto. Con este modelo pueden surgir problemas con el cliente que ve funcionando versiones del prototipo pero puede desilusionarse porque el producto final aún no ha sido

construido. El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

METODOLOGÍAS DE DESARROLLO DE SOFTWARE El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en muchos otros. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. Un objetivo de décadas ha sido encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software. La evolución de la disciplina de ingeniería del software ha traído consigo propuestas diferentes para mejorar los resultados del proceso de construcción. Las metodologías

tradicionales haciendo énfasis en la planificación y las metodologías ágiles haciendo énfasis en la adaptabilidad del proceso, delinean las principales propuestas presentes.

DEFINICIÓN DE METODOLOGÍA Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de software detallado y completo. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, incremental…). Definen artefactos, roles y actividades, junto con prácticas y técnicas recomendadas. La metodología para el desarrollo de software en un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de éxito. Una metodología para el desarrollo de software comprende los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado Una definición estándar de metodología puede ser el conjunto de métodos que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómo realizarlos para finalizar una tarea. Si esto se aplica a la ingeniería del software, podemos destacar que una metodología: Optimiza el proceso y el producto software. Métodos que guían en la planificación y en el desarrollo del software. Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.

Una metodología define una estrategia global para enfrentarse con el proyecto. Entre los elementos que forman parte de una metodología se pueden destacar: Fases: tareas a realizar en cada fase. Productos: E/S de cada fase, documentos. Procedimientos y herramientas: apoyo a la realización de cada tarea. Criterios de evaluación: del proceso y del producto. Saber si se han logrado los objetivos.

Una metodología de desarrollo de software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de desarrollo de sistemas de información. Una gran variedad de estos marcos de trabajo han evolucionado durante los años, cada uno con sus propias fortalezas y debilidades. Una metodología de desarrollo de sistemas no tiene que ser necesariamente adecuada para usarla en todos los proyectos. Cada una de las metodologías disponibles es más adecuada para tipos específicos de proyectos, basados en consideraciones técnicas, organizacionales, de proyecto y de equipo. Una metodología de desarrollo de software o metodología de desarrollo de sistemas en ingeniería de software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de desarrollo de un sistema de información. El marco de trabajo de una metodología de desarrollo de software consiste en: Una filosofía de desarrollo de software, con el enfoque o enfoques del proceso de desarrollo de software. Múltiples herramientas, modelos y métodos para ayudar en el proceso de desarrollo de software.

Estos marcos de trabajo están con frecuencia vinculados a algunos tipos de organizaciones, que se encargan del desarrollo, soporte de uso y promoción de la metodología. La metodología con frecuencia se documenta de alguna manera formal.

VENTAJAS DEL USO DE UNA METODOLOGÍA Son muchas las ventajas que puede aportar el uso de una metodología. A continuación se van a exponer algunas de ellas, clasificadas desde distintos puntos de vista. Desde el punto de vista de gestión: •

Facilitar la tarea de planificación

•

Facilitar la tarea del control y seguimiento de un proyecto

•

Mejorar la relación coste/beneficio

•

Optimizar el uso de recursos disponibles

•

Facilitar la evaluación de resultados y cumplimiento de los objetivos

•

Facilitar la comunicación efectiva entre usuarios y desarrolladores

Desde el punto de vista de los ingenieros del software: •

Ayudar a la comprensión del problema

•

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

•

Facilitar el mantenimiento del producto final

•

Permitir la reutilización de partes del producto

Desde el punto de vista del cliente o usuario: •

Garantía de un determinado nivel de calidad en el producto final

•

Confianza en los plazos de tiempo fijados en la definición del proyecto

•

Definir el ciclo de vida que más se adecue a las condiciones y características del desarrollo

CAPITULO III

METODOLOGÍA

En el desarrollo del presente trabajo de investigación se han recogido aportes significativos de dos tendencias ampliamente utilizadas en el desarrollo de aplicaciones, tratando de aplicarlas al desarrollo de aplicaciones en el ámbito educativo. Como ya se han esbozado en el Marco teórico, estas tendencias son: -

El desarrollo de Software por prototipos

El modelado UML.

Desarrollo de software por prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobado nosotros podemos iniciar el verdadero desarrollo del software. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Selección del modelo de Prototipo Evolutivo

Como dijo Jean Michel Lefèvre, "escribir un programa académico es como tener una aventura: generalmente conocemos el punto de partida, más o menos sabemos donde

queremos ir, pero desconocemos con exactitud lo que pasará por el camino", lo anterior nos hace reflexionar de la necesidad de desarrollar los programas académicos computarizados no de una manera rígida o cerrada que sería el caso de utilizar el modelo de cascada, sino de una manera mas abierta de manera tal que el cliente en este caso los educadores o expertos puedan ir haciendo los refinamientos o las aportaciones necesarias, inclusive podría hablarse de que aunque el producto no este terminado, puedan ellos probarlo con sus usuarios con el primer prototipo, además de realizar una breve evaluación con sus demás colegas, sin duda alguna que esto mejorará el diseño del software de manera especial la parte comunicativa o educativa. Como dice también Cataldi, la decisión se fundamenta en la ventaja de la realización de los cambios en etapas tempranas y la posibilidad de emisión varios prototipos evaluables durante el desarrollo, obteniéndose de este modo paralelamente una metodología integral también para el proceso de evaluación del programa. Lo anterior permite que los expertos educativos y educadores participen de una manera mas abierta y directa, involucrándose de este manera en el desarrollo del software, lo cual que obviamente representa una gran ventaja Existen otras razones genéricas que en si presenta el mismo modelo como son: · Cuando se trata de un software a ser desarrollado por encargo, es deseable obtener un primer esbozo de lo que será el programa tan pronto como fuera posible a fin de satisfacer la curiosidad del usuario, y para saber realmente qué es lo que éste quiere e incorporar sus sugerencias de cambio, si las hubiera, lo antes posible, es decir en etapas tempranas de la construcción. · Por otra parte, es necesario saber lo antes posible si los desarrolladores han interpretado correctamente las especificaciones y las necesidades del usuario. · En muchos casos los usuarios no tienen una idea acabada de lo que desean, por lo tanto los desarrolladores deben tomar decisiones y suponer que es lo que el usuario quiere. Por este motivo, ello la emisión de los prototipos brinda la posibilidad de efectuar refinamientos de los requerimientos en forma sucesiva a fin de acercarse al producto deseado.

Esta versión temprana de lo que será el producto, con una funcionalidad reducida, en principio, podrá incrementarse paulatinamente a través de refinamientos sucesivos de las especificaciones del sistema, evolucionando hasta llegar al sistema final. Al usar prototipos, las etapas del ciclo de vida clásico quedan modificadas de la siguiente manera: 1. Factibilidad (FAC) 2. Definición de requisitos del sistema (RES), 3. Especificación de los requisitos del prototipo (REP), 4. Diseño del prototipo (DPR), 5. Diseño detallado el prototipo (DDP), 6. Desarrollo del prototipo (codificación) (DEP),

El presente proyecto llega a este punto

7. Implementación y prueba del prototipo (IPP), 8. Refinamiento iterativo de las especificaciones del prototipo (aumentando el objetivo y/o el alcance). Luego, se puede volver a la etapa 2 o continuar si se logró el objetivo y alcance deseados. (RIT), 9. Diseño del sistema final (DSF), 10. Implementación del sistema final (ISF), 11. Operación y mantenimiento (OPM), 12. Retiro (si corresponde) (RET). Si bien el modelo de prototipos evolutivos, fácilmente modificables y ampliables es muy usado, en muchos casos pueden usarse prototipos descartables para esclarecer aquellos aspectos del sistema que no se comprenden bien. [J.Juzgado, 1996].

Este último punto es muy importante porque permite que en caso de que el software no de buenos resultados en sus diferentes pruebas esta pueda rediseñarse, quizás podemos ampliar este punto y hablar de una reingeniería sobre el mismo producto, aunque cada modelo da por terminado su producto en la última fase o etapa de su ciclo de vida. Para lo anterior se añade también el punto de que el software como cualquier otro producto resulte sino en el sentido estricto caducado cuando menos no actualizado, se requiere que todo software quede abierto a la posibilidad de mejora o de extensión del mismo. Para el caso del software académico en la parte de requisitos del sistema se debe de considerar más fondo al aspecto educativo, lo que en algunas metodologías mencionadas anteriormente en forma general se le llama diseño educativo. En la fase de requisitos del sistema que para nuestro caso es el aspecto educativo se deben de considerar los siguientes aspectos: El contenido o el eje temático del software (curricular o extracurricular). El o los objetivos educativos del software (lo que se debe de aprender con el software). El tipo de software educativo a desarrollar (tutorial, simulador, sistema experto, enciclopedia, diccionario de datos, almacén, repositorio). La población objetivo o a la que va dirigido (edad, nivel escolar, grado escolar, grado intelectual, capacidad de asimilación, en su caso discapacidad física o psicológica). Modos de uso (individual y grupal). Uso didáctico (autodidáctico, actividad de reforzamiento, apoyo de una clase, ejercitamiento, evaluativo e investigación). Teoría del aprendizaje sustentable (conductista, constructivista, cognoscitivista y las derivadas de las anteriores). Los objetivos psicopedagógicos (conocimientos, habilidades y destrezas). Actividades interactivas (ejercicios, consultas, búsquedas, pregunta respuesta).

Existen otros aspectos a considerar como el dise帽o de las interfaces, que si bien el modelo de prototipo evolutivo permite una revisi贸n constante de mejoras y extensiones.

CAPÍTULO IV

RESULTADOS Diagramas UML

Módulo Materias

Caso de uso: Ingresar Materia Actores: Administrador Objetivo: Ingresar los datos de una nueva materia al sistema. Resumen: El Director de Escuela entrega los datos de las materias a ingresarse y el Administrador los ingresa en el sistema y guarda los mismos. Precondiciones: ACTOR

SISTEMA 1. Empieza un nuevo periodo académico

Director

General entrega un compendio

de todas las materias a darse en tutor铆as. 2. El Administrador solicita al sistema la creaci贸n de una nueva materia 3. Crea una nueva materia y despliega el formulario para el ingreso de datos. 4. El

Director

Escuela

proporciona los datos. 5. El administrador los ingresa en el formulario. 6. El administrador indica guardar los datos

8. Pregunta

confirma

guardado de datos. 9. Confirma

acci贸n

guardado 10. Guarda y visualiza un mensaje indicando la acci贸n realizada.

Caso de uso: Editar Materia Actores: Administrador, Director de Escuela Objetivo: Editar los datos de una materia.

Resumen: El administrador busca la materia por medio de un identificativo y selecciona los campos a editar pertenecientes al mismo que han sido señalados por el Director General, una vez actualizados los cambios se guardan los mismos en el Sistema. Precondiciones: La materia a actualizarse deberá estar ingresada en el sistema ACTOR

SISTEMA 1. El Administrador solicita al sistema la edición de una nueva materia 2. Crea una nueva actualización materia y despliega el formulario de búsqueda de la materia a actualizar 3. El administrador selecciona el campo por el cual se buscará la materia a actualizarse. 4. El sistema despliega una lista con materias coincidentes en la búsqueda (ver caso de uso Consultar Materia)

5. El Administrador selecciona la materia a actualizar 6. El sistema despliega un formulario con los datos de la materia. 7. El administrador selecciona el campo a actualizar y realiza el cambio.

8. El

administrador

indica

actualización los datos 9. Pregunta

confirma

actualización de datos.

10. Confirma la acción actualizar. 11. Guarda

visualiza

mensaje

indicando la acción realizada

Iteraciones Desde la línea 7 hasta la línea 11, mientras existan campos de la materia a actualizar. Caso de uso: Eliminar Materia Actores: Administrador, Director de Escuela Objetivo: Eliminar una materia del sistema. Resumen: El administrador busca la materia por medio de un identificativo y realiza el proceso de borrado del mismo del sistema señalado por el Director Genral. Precondiciones: La materia a eliminarse deberá estar ingresada en el sistema ACTOR

SISTEMA

1. El administrador solicita al sistema la eliminación de una materia 2. Crea una nueva eliminación materia

despliega

formulario de búsqueda de 3. El administrador selecciona el

materia a eliminar

campo por el cual se buscará la materia eliminarse. 4. El sistema despliega una lista con las materias coincidentes en la búsqueda (ver caso de uso Consultar Materia) 5. El Administrador selecciona la materia a eliminarse.

6. El administrador indica la eliminación los datos

7. Pregunta si se confirma la eliminación de la materia 8. Confirma la acción eliminar. 9. Guarda

visualiza

mensaje

indicando la acción realizada

Caso de uso: Consultar Materia Actores: Administrador, Director General Objetivo: Buscar una materia en el sistema. Resumen: El actor ingresa en el sistema los datos de la materia a consultar y éste busca y visualiza resultados.

Precondiciones: La materia debe estar ingresada en el sistema. Conocer los datos de búsqueda. Curso de los eventos: ACTOR

SISTEMA

1. El actor solicita al sistema la búsqueda de una materia. 2. Muestra

formulario

para

ingresar los datos de búsqueda. 3. Ingresa los datos de la materia en el formulario. 4. Indica buscar 5. Busca y despliega los datos de la materia 6. Lee la información y cierra el formulario.

Módulo Escuela – Unidad Académica

Caso de uso: Ingresar Unidad Académica Actores: Administrador Objetivo: Ingresar los datos de una nueva Unidad Académica al sistema.

Resumen: El administrador ingresa los datos de la unidad académica en el sistema y guarda los mismos. Precondiciones: ACTOR

SISTEMA

1. El Administrador solicita al sistema la creación de una nueva Unidad Académica

2. Crea una nueva Unidad Académica y despliega el formulario para el ingreso de datos.

3. El administrador los ingresa en el formulario. 4. El administrador indica guardar los datos 5. Pregunta

confirma

guardado de datos.

6. Guarda y visualiza un mensaje indicando la acción realizada.

M贸dulo Curso

Caso de uso: Ingresar Curso Actores: Administrador, Director General Objetivo: Ingresar los cursos de una nueva facultad al sistema. Resumen: El administrador ingresa los cursos de la facultad en el sistema y guarda los mismos. Precondiciones: ACTOR

SISTEMA

2. El Administrador solicita al sistema la creaci贸n de una nueva Facultad 3. Crea

una

nueva

Facultad

despliega el formulario para el ingreso de datos. 7. El administrador los ingresa en el formulario. 8. El administrador indica guardar los datos

9. Pregunta

guardado de datos.

confirma

72 10. Guarda y visualiza un mensaje indicando la acci贸n realizada.

M贸dulo Docente

Caso de uso: Ingresar Docente Actores: Administrador, Docente Objetivo: Ingresar los datos de un nuevo docente al sistema. Resumen: El Docente entrega sus datos personales y el Administrador los ingresa en el sistema y guarda los mismos. Precondiciones:

ACTOR

SISTEMA

1. El Administrador solicita al sistema la creación de un nuevo docente 2. Crea un nuevo docente y despliega el formulario para el ingreso de 3. El docente proporciona sus datos.

datos.

4. El administrador los ingresa en el formulario. 5. El administrador indica guardar los datos

6. Pregunta 7. Confirma la acción de guardado

confirma

guardado de datos.

8. Guarda y visualiza un mensaje indicando la acción realizada.

Caso de uso: Editar Docente Actores: Administrador, Director de Escuela Objetivo: Editar los datos de un docente Resumen: El administrador busca al docente por medio de un identificativo y selecciona los campos a editar pertenecientes al mismo que han sido señalados por el Docente, una vez actualizados los cambios se guardan los mismos en el Sistema. Precondiciones: El docente a actualizarse deberá estar ingresado en el sistema

ACTOR

SISTEMA

1. El Administrador solicita al sistema la edición de un docente 2. Crea

una

nueva

actualización

docente y despliega el formulario de 3. El administrador selecciona el

búsqueda

del

docente

actualizar

campo por el cual se buscará al docente a actualizarse.

4. El sistema despliega una lista con los docentes coincidentes en la búsqueda

(ver

caso

uso

Consultar docente) 5. El Administrador selecciona el docente a actualizar

6. El sistema despliega un formulario 7. El administrador selecciona el

con los datos del docente.

campo a actualizar y realiza el cambio. 8. El

administrador

indica

actualización los datos

9. Pregunta

confirma

actualización de datos.

10. Confirma la acción actualizar. 11. Guarda

visualiza

mensaje

indicando la acción realizada

Caso de uso: Eliminar Docente Actores: Administrador, Director de Escuela Objetivo: Eliminar una materia del sistema. Resumen: El administrador busca al docente por medio de un identificativo y realiza el proceso de borrado del mismo del sistema señalado por el Director General. Precondiciones: El docente a eliminarse deberá estar ingresado en el sistema ACTOR

SISTEMA

1. El administrador solicita al sistema la eliminación de un docente 2. Crea

una

nueva

eliminación

docente y despliega el formulario de búsqueda de docente a eliminar 3. El administrador selecciona el campo por el cual se buscará el docente eliminarse. 5. El sistema despliega una lista con los docentes coincidentes en la búsqueda (ver caso de uso Consultar Docente)

7. El

Administrador

selecciona

docente a eliminarse.

8. El administrador indica la eliminación los datos 8. Pregunta si se confirma la eliminación de la materia 9. Confirma la acción eliminar. 10. Guarda

visualiza

mensaje

indicando la acción realizada

Caso de uso: Consultar Docente Actores: Administrador, Director General Objetivo: Buscar un docente en el sistema. Resumen: El Administrador ingresa en el sistema los datos del docente a consultar y éste busca y visualiza resultados. Precondiciones: El docente debe estar ingresada en el sistema. Conocer los datos de búsqueda. Curso de los eventos: ACTOR 1. El Administrador solicita al sistema

SISTEMA

la b煤squeda de un docente. 2. Muestra

formulario

para

ingresar los datos de b煤squeda. 3. Ingresa los datos del docente en el formulario. 4. Indica buscar 5. Busca y despliega los datos del docente 6. Lee la informaci贸n y cierra el formulario.

M贸dulo Estudiante

Caso de uso: Ingresar Estudiante

Actores: Administrador, Estudiante Objetivo: Ingresar los datos de un nuevo Estudiante al sistema. Resumen: El Estudiante entrega sus datos personales y el Administrador los ingresa en el sistema y guarda los mismos. Precondiciones: ACTOR

SISTEMA

3. El Administrador solicita al sistema la creaci贸n de un nuevo Estudiante 3. Crea

nuevo

Estudiante

despliega el formulario para el 7. El Estudiante proporciona sus

ingreso de datos.

datos. 8. El administrador los ingresa en el formulario. 9. El administrador indica guardar los datos

10. Pregunta

confirma

guardado de datos. 8. Confirma la acci贸n de guardado 9. Guarda y visualiza un mensaje indicando la acci贸n realizada.

Caso de uso: Editar Materia Actores: Administrador, Director de Escuela

Objetivo: Editar los datos de un Estudiante Resumen: El administrador busca al Estudiante por medio de un identificativo y selecciona los campos a editar pertenecientes al mismo que han sido señalados por el Estudiante, una vez actualizados los cambios se guardan los mismos en el Sistema. Precondiciones: El Estudiante a actualizarse deberá estar ingresado en el sistema ACTOR

SISTEMA

2. El Administrador solicita al sistema la edición de un Estudiante 4. Crea

4. El administrador selecciona el

una

nueva

actualización

Estudiante

despliega

formulario

búsqueda

del

Estudiante a actualizar

campo por el cual se buscará al Estudiante a actualizarse.

5. El sistema despliega una lista con los Estudiantes coincidentes en la búsqueda

(ver

caso

uso

Consultar Estudiante) 6. El Administrador selecciona el Estudiante a actualizar

7. El sistema despliega un formulario 10. El administrador selecciona el campo a actualizar y realiza el cambio.

con los datos del Estudiante.

11. El

administrador

indica

actualización los datos

12. Pregunta

confirma

actualización de datos. 11. Confirma la acción actualizar. 12. Guarda

visualiza

mensaje

indicando la acción realizada

Caso de uso: Eliminar Estudiante Actores: Administrador, Director de Escuela Objetivo: Eliminar una materia del sistema. Resumen: El administrador busca al Estudiante por medio de un identificativo y realiza el proceso de borrado del mismo del sistema señalado por el Director General. Precondiciones: El Estudiante a eliminarse deberá estar ingresado en el sistema ACTOR

SISTEMA

3. El administrador solicita al sistema la eliminación de un Estudiante 4. Crea

4. El administrador selecciona el campo por el cual se buscará el

una

nueva

eliminación

Estudiante

despliega

formulario

búsqueda

Estudiante a eliminar

Estudiante eliminarse.

6. El sistema despliega una lista con

los

Estudiantes

coincidentes en la búsqueda (ver caso de uso Consultar 9. El

Administrador

selecciona

Estudiante)

Estudiante a eliminarse.

10. El administrador indica la eliminación los datos

9. Pregunta si se confirma la eliminación de la materia

10. Confirma la acción eliminar.

11. Guarda

visualiza

mensaje

indicando la acción realizada

Caso de uso: Consultar Estudiante Actores: Administrador, Director General Objetivo: Buscar un Estudiante en el sistema. Resumen: El Administrador ingresa en el sistema los datos del Estudiante a consultar y éste busca y visualiza resultados.

Precondiciones: El Estudiante debe estar ingresado en el sistema. Conocer los datos de búsqueda. Curso de los eventos: ACTOR

SISTEMA

2. El Administrador solicita al sistema la búsqueda de un Estudiante. 3. Muestra

formulario

para

ingresar los datos de búsqueda. 5. Ingresa los datos del estudiante en el formulario. 6. Indica buscar Busca y despliega los datos del estudiante 7. Lee la información y cierra el formulario.

Módulo Tutorías

Caso de uso: Ingresar Tutoría Actores: Docente Objetivo: Ingresar los datos de una nueva Tutoría al sistema. Resumen: El Docente ingresa los datos de la Tutoría en el sistema y guarda los mismos. Precondiciones: ACTOR

SISTEMA

3. El Administrador solicita al sistema la creación de una nueva Tutoría 4. Crea una nueva Tutoría y despliega el formulario para el ingreso de datos. 11. El administrador los ingresa en el formulario. 12. El administrador indica guardar los datos

84 13. Pregunta

confirma

guardado de datos.

14. Guarda y visualiza un mensaje indicando la acción realizada.

Caso de uso: Editar Tutoría Actores: Docente Objetivo: Editar los datos de una Tutoría. Resumen: El Docente busca la Tutoría por medio de un identificativo y selecciona los campos a editar una vez actualizados los cambios se guardan los mismos en el Sistema. Precondiciones: La Tutoría a actualizarse deberá estar ingresada en el sistema ACTOR

SISTEMA 2. El Docente solicita al sistema la edición de una nueva Tutoría 3. Crea una nueva actualización Tutoría y despliega el formulario de búsqueda de la Tutoría a actualizar 4. El Docente selecciona el campo por el cual se buscará la Tutoría a actualizarse.

11. El sistema despliega una lista con

Tutorías coincidentes en la búsqueda (ver caso de uso Consultar Tutoría)

Docente

selecciona

Tutoría a actualizar 7. El sistema despliega un formulario con 9. El Docente selecciona el campo a

los datos de la Tutoría.

actualizar y realiza el cambio. 10. El Docente indica la actualización los datos

10. Pregunta

confirma

actualización de datos. 11. Confirma la acción actualizar.

12. Guarda

visualiza

mensaje

indicando la acción realizada

Iteraciones Desde la línea 7 hasta la línea 11, mientras existan campos de la Tutoría a actualizar. Caso de uso: Eliminar Tutoría

Actores: Docente Objetivo: Eliminar una Tutoría del sistema. Resumen: El Docente busca la Tutoría por medio de un identificativo y realiza el proceso de borrado. Precondiciones: La Tutoría a eliminarse deberá estar ingresada en el sistema ACTOR

SISTEMA

4. El Docente solicita al sistema la eliminación de una Tutoría 3. Crea una nueva eliminación Tutoría

despliega

formulario de búsqueda de 4. El Docente selecciona el campo

Tutoría a eliminar

por el cual se buscará la Tutoría eliminarse. 7. El sistema despliega una lista con las Tutorías coincidentes en la búsqueda (ver caso de uso Consultar Empleado) 12. El Docente selecciona la Tutoría a eliminarse.

13. El Docente indica la eliminación los datos

10. Pregunta si se confirma la eliminaci贸n

de la Tutor铆a 11. Confirma la acci贸n eliminar. 12. Guarda

visualiza

indicando la acci贸n realizada

mensaje

Modelado Base de Datos TutorĂa

Tabla Alumno

Tabla Docente

Tabla Periodo académico

Tabla Unidad Académica

Tabla TutorĂas

APARIENCIA DEL PROTOTIPO Ingreso al Sistema

Administrando Docentes

Administrando Estudiantes

Administrando listado de TutorĂas

Registrando una tutorĂa

Reportes

Tutoria en WORD Tutoria

Tipo

Periodo académico Enero-Mayo 2012

Unidad académica Escuela de Sistemas

Alumno Jonathan

Docente Santiago

Información

Fecha

Hora de Inicio

14/05/2012

00:00

Docentes en PDF

Docentes en Excel para exportaci贸n de datos

CONCLUSIONES:

•

El presente proyecto muestra un escenario de ejercicio de las actividades de tutorías dentro del ámbito universitario, tratando de relievar el gran aporte de las mismas dentro del ejercicio académico, como un elemento potenciador y dinamizador del ser mismo de la institución educativa superior.

•

Se destaca los aportes y puntos de vista de las tutorías, sus principales actividades, y algunas puntualizaciones de perfiles docentes para que esta actividad sea viable dentro de la PUCESA.

•

Se ha establecido una metodología de desarrollo de aplicaciones educativas para la aplicación web de tutorías docentes, cubriendo las necesidades institucionales.

•

Se ha logrado de manera efectiva la recolección de requerimientos de software que muestren a través del diseño de diagramas de casos de uso UML las principales actividades, actores y procedimientos que se han de llevar a cabo para la consecución de una aplicación software.

•

Se han analizado y seleccionado un conjunto de herramientas software de desarrollo rápido y de creación de ambientes web de desarrollo con licencia GNU y de prueba; con la finalidad de desarrollar un prototipo inicial que permita la recolección de datos básica que permita una primera operación dentro de la universidad, así como la recolección de nuevos requerimientos para la siguiente iteración de la metodología propuesta para el desarrollo.

•

Se han establecido dos niveles de usuario un administrador y un docente. El administrador tiene acceso a la creación y administración de características funcionales del sistema como son: o

Administración de periodos académicos: que permitiría al sistema funcionar en diferentes semestres, años académicos, etc. En función del tiempo.

o Administración de Unidades Académicas: que permitirá administrar los

100

nombres de las diferentes unidades existentes y las posibles a crearse en la PUCESA. o Administración de Docentes: Que permitirá el acceso de nuevos docentes y/o la administración del personal de las difierentes unidades académicas de la PUCESA. o Administración de Estudiantes: que permitirá el acceso y la administración de estudiantes de las diferentes unidades académicas de la PUCESA. El docente tiene asignado a su perfil: o El ingreso y administración de datos e información de las tutorías( Actualmente visualiza, edita y administra información de tutoría de todas las unidades académicas, sin embargo se deberá establecer limitaciones para acceso a información por unidad académica , alumnado, etc) o Temporalmente y con el objetivo de ingreso de datos tiene acceso a datos de Docentes para ingreso administración y actualización de datos. •

Se han realizado pruebas de funcionamiento sobre la plataforma tecnológica implantada en la PUCESA de forma que la implementación para el seguimiento del proyecto sea completamente factible.

101

Bibliografía 1. Álvarez González, M. y Rodríguez Espinar, S. (2000), Cambios socio-educativos y orientación en el s. XXI: Nuevas estructuras, roles y funciones, Actas XII Congreso Nacional y I Iberoamericano de Pedagogía. 2. Álvarez Rojo, V. y Lázaro, A. (Coords.) (2002), Calidad de las universidades y orientación universitaria, Málaga, Aljibe. 3. Bolivar, A. (2003), Diseño de planes de estudio de las titulaciones, Vicerrectorado de Planificación, Calidad y Evaluación Docente, Universidad de Granada. 4. Bricall, J. (Coord.) (2000), Informe Universidad 2000 , Madrid, Patronato de la Conferencia de Rectores. 5. Coriat, M. y Sanz, R. (2005), “Orientación y tutoría universitaria”, en Orientación y Tutoría en la Universidad de Granada , Granada, Editorial Universidad de Granada. 6. Coriat, M. y Sanz, R. (Eds.),(2005), Orientación y Tutoría en la Universidad de Granada , Granada, Editorial Universidad de Granada. 7. Gellert, C. (ed.)(1993), Higher Education in Europe , London: Jessica Kingsley. 8. González, J. y Wagenaar, R. (2003), Tuning Educational Structures in Europe. Final

Report.

Phase

One

Bilbao,

Universidad

Deusto

(http://www.relint.deusto.es/TUNNINGProject/index.htm) 9. Michavila, F. y García, J. (Eds.)(2003), La tutoría y los nuevos modos de aprendizaje en la universidad , Dirección General de Universidades de la Consejería de Educación de la Comunidad de Madrid y Cátedra UNESCO de Gestión y Política Universitaria de la Universidad Politécnica de Madrid. 10. Michavila, F., García, J. y Rodríguez, R. (Eds.)(2001), Innovaciones en la organización y gestión de las universidades , Dirección General de Universidades de la Consejería de Educación de la Comunidad de Madrid y Cátedra UNESCO de Gestión y Política Universitaria de la Universidad Politécnica de Madrid.

102

11. Rodríguez Espinar, S. (1997), Orientación universitaria y evaluación de la calidad, en Apodaca, P. y Lobato, C. (Eds.), Calidad en la Universidad: Orientación y evaluación , Barcelona, Alertes. 12. Rodríguez Espinar, S. (Coord.) (2004), Manual de tutoría universitaria. Recursos para la acción , Barcelona, Ediciones Octaedro. 13. Pressman Rogers, Ingeniería de Software (un enfoque práctico), McGrawHill, Interamericana de España. 14. Sommerville. "Ingeniería de Software 6ª Edición". Addison Wesley. 15. (Galvis, 94)"Ingeniería de Software Educativo". Alvaro Galvis Panqueva. 1994. 16. Informática Educativa UNIANDES – LIDIE, Vol 11, No, 1, 1998

LINKOGRAFIA 17. http://www.inf.udec.cl/revista/edicion6/psalcedo.htm 18. http://dewey.uab.es/pmarques/disoft.htm 19. http://www.blues.uab.es/home/material/programes/t023151/uabdisof.htm 20. http://www.somece.org.mx/simposio06/memorias/contenido/grupo3/pdf/6_G arciaAlvarezJoseLuis.pdf 21. http://www.sangregorio.edu.ec/uploads/paginas/file/archivos/reglamentos/20 11/REGLAMENTO%20DE%20TUTORIAS%20ACADEMICAS%2018%20de%20agos to%20de%202011.pdf 22. http://campus.usal.es/~ofeees/NUEVAS_METODOLOGIAS/TUTORIAS/2005-0269.pdf 23. http://solusoftg11.googlecode.com/files/Metodologias%20de%20desarrollo.pd f 24. http://www.inteco.es/file/N85W1ZWFHifRgUc_oY8_Xg