tutorias docentes pucesa
DESCRIPTION
PROYECTO TUTORIAS DOCENTES PUCESATRANSCRIPT
1
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
2
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
3 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
4 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
5 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
6 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
7
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
8 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.
9 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
10 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.
11 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.
12 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
13 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.
14 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
15 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
16 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.
17 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).
18 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.
19 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.
20 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:
21 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
22 (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.
23 • 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.
24 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.
25 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
26 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
27 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.
28
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.
29 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
30 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
31 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).
32 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
33 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
34 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.
35
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
36 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.
37 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
38 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.
39 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
40 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.
41 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.
42 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.
43 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
44 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
45 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,
46 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.
47 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
48 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.
49 • 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
50 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 a 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:
51 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
52
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
53 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.
54
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
55 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
56 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.
57 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.
58 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
59 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
60 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.
61 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),
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].
El presente proyecto llega a este punto
62 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).
63 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.
64 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 y el Director
General entrega un compendio
65 de todas las materias a darse
en tutorías.
2. El Administrador solicita al
sistema la creación de una
nueva materia
4. El Director De Escuela
proporciona los datos.
5. El administrador los ingresa en
el formulario.
6. El administrador indica guardar
los datos
9. Confirma la acción de
guardado
3. Crea una nueva materia y
despliega el formulario para el
ingreso de datos.
8. Pregunta si se confirma el
guardado de datos.
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.
66 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
3. El administrador selecciona el
campo por el cual se buscará la
materia a actualizarse.
5. El Administrador selecciona la
materia a actualizar
7. El administrador selecciona el
campo a actualizar y realiza el
cambio.
2. Crea una nueva actualización materia
y despliega el formulario de búsqueda
de la materia a actualizar
4. El sistema despliega una lista con
materias coincidentes en la búsqueda
(ver caso de uso Consultar Materia)
6. El sistema despliega un formulario con
los datos de la materia.
67 8. El administrador indica la
actualización los datos
10. Confirma la acción actualizar.
9. Pregunta si se confirma la
actualización de datos.
11. Guarda y visualiza un 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 y despliega el
68
3. El administrador selecciona el
campo por el cual se buscará la
materia eliminarse.
5. El Administrador selecciona la materia
a eliminarse.
6. El administrador indica la eliminación
los datos
8. Confirma la acción eliminar.
formulario de búsqueda de
materia a eliminar
4. El sistema despliega una lista
con las materias coincidentes
en la búsqueda (ver caso de
uso Consultar Materia)
7. Pregunta si se confirma la eliminación
de la materia
9. Guarda y visualiza un 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.
69 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.
3. Ingresa los datos de la materia en
el formulario.
4. Indica buscar
6. Lee la información y cierra el
formulario.
2. Muestra un formulario para
ingresar los datos de búsqueda.
5. Busca y despliega los datos de la
materia
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.
70 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
3. El administrador los ingresa en el
formulario.
4. El administrador indica guardar los
datos
2. Crea una nueva Unidad Académica
y despliega el formulario para el
ingreso de datos.
5. Pregunta si se confirma el
guardado de datos.
6. Guarda y visualiza un mensaje
indicando la acción realizada.
71 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
7. El administrador los ingresa en el
formulario.
8. El administrador indica guardar los
datos
3. Crea una nueva Facultad y
despliega el formulario para el
ingreso de datos.
9. Pregunta si se confirma el
guardado de datos.
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:
73 ACTOR SISTEMA
1. El Administrador solicita al sistema
la creación de un nuevo docente
3. El docente proporciona sus datos.
4. El administrador los ingresa en el
formulario.
5. El administrador indica guardar los
datos
7. Confirma la acción de guardado
2. Crea un nuevo docente y despliega
el formulario para el ingreso de
datos.
6. Pregunta si se confirma el
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
74 ACTOR SISTEMA
1. El Administrador solicita al sistema
la edición de un docente
3. El administrador selecciona el
campo por el cual se buscará al
docente a actualizarse.
5. El Administrador selecciona el
docente a actualizar
7. El administrador selecciona el
campo a actualizar y realiza el
cambio.
8. El administrador indica la
actualización los datos
2. Crea una nueva actualización
docente y despliega el formulario
de búsqueda del docente a
actualizar
4. El sistema despliega una lista con
los docentes coincidentes en la
búsqueda (ver caso de uso
Consultar docente)
6. El sistema despliega un formulario
con los datos del docente.
9. Pregunta si se confirma la
actualización de datos.
75
10. Confirma la acción actualizar.
11. Guarda y visualiza un 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
3. El administrador selecciona el
campo por el cual se buscará el
docente eliminarse.
2. Crea una nueva eliminación
docente y despliega el formulario
de búsqueda de docente a eliminar
5. El sistema despliega una lista
con los docentes coincidentes
en la búsqueda (ver caso de
uso Consultar Docente)
76 7. El Administrador selecciona el
docente a eliminarse.
8. El administrador indica la eliminación
los datos
9. Confirma la acción eliminar.
8. Pregunta si se confirma la eliminación
de la materia
10. Guarda y visualiza un 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 SISTEMA
1. El Administrador solicita al sistema
77 la búsqueda de un docente.
3. Ingresa los datos del docente en el
formulario.
4. Indica buscar
6. Lee la información y cierra el
formulario.
2. Muestra un formulario para
ingresar los datos de búsqueda.
5. Busca y despliega los datos del
docente
Módulo Estudiante
Caso de uso: Ingresar Estudiante
78 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
7. El Estudiante proporciona sus
datos.
8. El administrador los ingresa en el
formulario.
9. El administrador indica guardar los
datos
8. Confirma la acción de guardado
3. Crea un nuevo Estudiante y
despliega el formulario para el
ingreso de datos.
10. Pregunta si se confirma el
guardado de datos.
9. Guarda y visualiza un mensaje
indicando la acción realizada.
Caso de uso: Editar Materia
Actores: Administrador, Director de Escuela
79 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. El administrador selecciona el
campo por el cual se buscará al
Estudiante a actualizarse.
6. El Administrador selecciona el
Estudiante a actualizar
10. El administrador selecciona el
campo a actualizar y realiza el
cambio.
4. Crea una nueva actualización
Estudiante y despliega el
formulario de búsqueda del
Estudiante a actualizar
5. El sistema despliega una lista con
los Estudiantes coincidentes en la
búsqueda (ver caso de uso
Consultar Estudiante)
7. El sistema despliega un formulario
con los datos del Estudiante.
80 11. El administrador indica la
actualización los datos
11. Confirma la acción actualizar.
12. Pregunta si se confirma la
actualización de datos.
12. Guarda y visualiza un 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. El administrador selecciona el
campo por el cual se buscará el
4. Crea una nueva eliminación
Estudiante y despliega el
formulario de búsqueda de
Estudiante a eliminar
81 Estudiante eliminarse.
9. El Administrador selecciona el
Estudiante a eliminarse.
10. El administrador indica la eliminación
los datos
10. Confirma la acción eliminar.
6. El sistema despliega una lista
con los Estudiantes
coincidentes en la búsqueda
(ver caso de uso Consultar
Estudiante)
9. Pregunta si se confirma la eliminación
de la materia
11. Guarda y visualiza un 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.
82 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.
5. Ingresa los datos del estudiante en
el formulario.
6. Indica buscar
7. Lee la información y cierra el
formulario.
3. Muestra un formulario para
ingresar los datos de búsqueda.
Busca y despliega los datos del
estudiante
83
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
11. El administrador los ingresa en el
formulario.
12. El administrador indica guardar los
datos
4. Crea una nueva Tutoría y despliega
el formulario para el ingreso de
datos.
84
13. Pregunta si se confirma el
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
4. El Docente selecciona el campo
por el cual se buscará la Tutoría
a actualizarse.
3. Crea una nueva actualización Tutoría y
despliega el formulario de búsqueda
de la Tutoría a actualizar
85
5. El Docente selecciona la
Tutoría a actualizar
9. El Docente selecciona el campo a
actualizar y realiza el cambio.
10. El Docente indica la actualización
los datos
11. Confirma la acción actualizar.
11. El sistema despliega una lista con
Tutorías coincidentes en la búsqueda
(ver caso de uso Consultar Tutoría)
7. El sistema despliega un formulario con
los datos de la Tutoría.
10. Pregunta si se confirma la
actualización de datos.
12. Guarda y visualiza un 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
86 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
4. El Docente selecciona el campo
por el cual se buscará la Tutoría
eliminarse.
12. El Docente selecciona la Tutoría a
eliminarse.
13. El Docente indica la eliminación los
datos
3. Crea una nueva eliminación
Tutoría y despliega el
formulario de búsqueda de
Tutoría a eliminar
7. El sistema despliega una lista
con las Tutorías coincidentes
en la búsqueda (ver caso de
uso Consultar Empleado)
87
11. Confirma la acción eliminar.
10. Pregunta si se confirma la eliminación
de la Tutoría
12. Guarda y visualiza un mensaje
indicando la acción realizada
88 Modelado Base de Datos Tutoría
89
Tabla Alumno
Tabla Docente
Tabla Periodo académico
Tabla Unidad Académica
90 Tabla Tutorías
91 APARIENCIA DEL PROTOTIPO
Ingreso al Sistema
Administrando Docentes
92
Administrando Estudiantes
93
94
Administrando listado de Tutorías
95 Registrando una tutoría
96 Reportes
Tutoria en WORD
Tutoria Tipo Periodo académico Unidad académica Alumno Docente Información Fecha Hora de Inicio
2 0 Enero-Mayo 2012 Escuela de Sistemas Jonathan Santiago - 14/05/2012 00:00
97 Docentes en PDF
98
Docentes en Excel para exportación de datos
99 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.
100 o Administración de Unidades Académicas: que permitirá administrar los
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 de 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-02-
69.pdf
23. http://solusoftg11.googlecode.com/files/Metodologias%20de%20desarrollo.pd
f
24. http://www.inteco.es/file/N85W1ZWFHifRgUc_oY8_Xg