SlideShare una empresa de Scribd logo
1 de 6
Descargar para leer sin conexión
DISEÑO DE CASO DE PRUEBAS
1. REQUERIMIENTOS DEL SISTEMA
Para la realización de las pruebas de nuestro sistema, realizamos una lista con los
requerimientos funcionales y no funcionales solicitados para el correcto desarrollo de nuestro
proyecto.
1.1. Requerimientos Funcionales
Un requerimiento funcional define una función del sistema de software o sus
componentes. Una función es descrita como un conjunto de entradas, comportamientos y
salidas. Los requerimientos funcionales pueden ser:
CÁLCULOS,
DETALLES TÉCNICOS,
MANIPULACIÓN DE DATOS Y
OTRAS FUNCIONALIDADES ESPECÍFICAS QUE SE SUPONE, UN SISTEMA DEBE
CUMPLIR (REGISTRAR, MODIFICAR, ELIMINAR, GENERAR REPORTES, ENTRE
OTRAS).
Como se define en la ingeniería de requerimientos, los requerimientos funcionales
establecen los comportamientos del sistema.
1.2. Requerimientos No funcionales
Un requerimiento no funcional o atributo de calidad es, en la ingeniería de sistemas y
la ingeniería de software, un requerimiento que especifica criterios que pueden usarse para
juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos
corresponden a los requerimientos funcionales. Por tanto, se refieren a todos los
requerimientos que ni describen información a guardar, ni funciones a realizar.
Algunos ejemplos de requisitos no funcionales típicos son los siguientes:
 Rendimiento
 Disponibilidad
 Seguridad
 Accesibilidad
 Usabilidad
 Estabilidad
 Portabilidad
 Costo
 Operatividad
 Interoperabilidad
 Escalabilidad
 Concurrencia
 Mantenibilidad
 Interfaz
2. SELECCIÓN DE MÓDULOS A PROBAR
Una vez teniendo en cuenta el listado de los requerimientos procedemos a especificar
cuales módulos vamos a evaluar lo hacemos de acuerdo a los requerimientos solicitados y le
agregamos un identificador a cada unidad a probar. Por ejemplo, basándonos en los
requerimientos:
Unidad de Prueba Identificador
Acceso MOD1
Contenido MOD2
Interfaz
Navegación
Seguridad
Validación
Base de Datos
Configuración
Comportamiento General
NOTA: El ID puede ser cualquier termino que se decida para designar a la unidad a probar.
3. PRUEBA DE LAS FUNCIONES POR MÓDULOS
Una vez identificados las unidades o módulos del sistema a probar hacemos una tabla
en la que colocamos el identificador del módulo con las funciones que debería cumplir el
sistema. Este es un ejemplo
Modulo Registrar Eliminar Modificar Calcular Reportes Funcion6
Mod1 SI NA NA NA NA NA
Mod2 SI SI SI SI SI SI
Mod3 SI NO SI NA NA SI
Mod4 SI SI SI NA NA SI
Mod5 NA NA NO NO NA SI
Mod6 NA NA NA NA NA SI
PARA AFIRMACIÓN DE LA FUNCIÓN SE COLOCA (SI), (NO) O (N/A)= NO
APLICA
O EN SU DEFECTO UNA X O UN VIÑETE DE AFIRMACIÓN
Recuerden que las funciones pueden ser Cálculos, detalles técnicos y funciones
básicas que debe cumplir el sistema, como de la misma manera se pueden estar evaluando
los requemamientos no funciones como: interfaz, acceso, seguridad, usabilidad, entre otras.
4. VEREDICTO DE LAS PRUEBAS
Una vez realizada la prueba se hace la descripción para el veredicto y/o resultado
generado por la prueba.
ID Módulo Probado Resultado
obtenido
Veredicto observaciones
Mod1 Acceso a la interfaz principal Esperado Funcional
Mod2 Validación de formularios Esperado Funcional
Mod3 Registro de los usuarios Esperado Funcional
Mod4 Seguridad de acceso Esperado Funcional
Mod5 Conexión con la base de
datos
Esperado Funcional
Mod6 Genera el reporte solicitado Esperado Funcional
- El resultado puede ser Esperado o sin resultado (el modulo esta en construcción), o fallido.
- Veredicto puede ser Funcional o No Funcional.
- Observaciones se coloca cualquier eventualidad presentada durante la prueba.
5. DOCUMENTACIÓN DE LA PRUEBA
Por último se realiza una ficha la cual contendrá ciertos datos indispensables de la
realización de prueba la cual es la que el PROBADOR certificara y hará constar de la
ejecución de la misma.
Documentación de la Prueba
INSTITUCIÓN RESPONSABLE FECHA
NOMBRE DE LA INSTITUCIÓN
TITULO DEL PST II
DOCUMENTOS DE REFERENCIA
Identificador Título
Mod1 Acceso a la interfaz principal
Fecha de realización:
22-06-2013
Duración de la prueba: 1 hora
Requerimientos
de la prueba
LAPTOP, PENDRIVE...
Objetivo Encontrar el mayor numero de errores posibles, para la mejora
del sistema.
Resultado Esperado
Resultado Obtenido Prueba Exitosa SI(X ) NO( )
Estado del Caso de No iniciado En curso Terminado
prueba X
Personal Requerido Cargo Nombre Firma
Profesor/Ingeniero FULANITO
Comentarios En este modulo, se encontró una falla de seguridad, no esta
cifrada la contraseña.
Realizado por: Firma Fecha
NOMBRE TUTOR
TECNICO
00/00/201X
Aprobado por: Firma Fecha
TUTOR(A) ACADEMIC@ 00/00/201X

Más contenido relacionado

La actualidad más candente

Caso practico Auditoria de Sistemas Informaticos
Caso practico Auditoria de Sistemas InformaticosCaso practico Auditoria de Sistemas Informaticos
Caso practico Auditoria de Sistemas InformaticosEduardo Gonzalez
 
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Oswaldo Hernández
 
Plantilla caso prueba
Plantilla caso pruebaPlantilla caso prueba
Plantilla caso pruebaSTBG
 
Requerimientos de usuario y del sistema
Requerimientos de usuario y del sistemaRequerimientos de usuario y del sistema
Requerimientos de usuario y del sistemaIsrael Rey
 
Concepto y extensiones de negocio de Eriksson Penker
Concepto y extensiones de negocio de Eriksson PenkerConcepto y extensiones de negocio de Eriksson Penker
Concepto y extensiones de negocio de Eriksson PenkerMarcos Omar Cruz Ortrega
 
Diagrama desecuenciabiblioteca 1
Diagrama desecuenciabiblioteca 1Diagrama desecuenciabiblioteca 1
Diagrama desecuenciabiblioteca 11052403005n
 
Test y pruebas de caja Negra y caja Blanca
Test y pruebas de caja Negra y caja BlancaTest y pruebas de caja Negra y caja Blanca
Test y pruebas de caja Negra y caja BlancaManuel Murcia
 
Informe final de Auditoria Informatica
Informe final de Auditoria InformaticaInforme final de Auditoria Informatica
Informe final de Auditoria InformaticaAmd Cdmas
 
Taller casos de prueba
Taller casos de pruebaTaller casos de prueba
Taller casos de pruebaAndrés Grosso
 
Software para auditoría informática
Software para auditoría informáticaSoftware para auditoría informática
Software para auditoría informáticameme694
 
Plantilla plan pruebas_de_software
Plantilla plan pruebas_de_softwarePlantilla plan pruebas_de_software
Plantilla plan pruebas_de_softwarejoseluispt
 
Casos de Uso ejercicios
Casos de Uso ejerciciosCasos de Uso ejercicios
Casos de Uso ejerciciosWalter Chacon
 
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareTema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareSaraEAlcntaraR
 

La actualidad más candente (20)

Caso practico Auditoria de Sistemas Informaticos
Caso practico Auditoria de Sistemas InformaticosCaso practico Auditoria de Sistemas Informaticos
Caso practico Auditoria de Sistemas Informaticos
 
Auditoria De Redes
Auditoria De RedesAuditoria De Redes
Auditoria De Redes
 
Modelo de requerimientos
Modelo de requerimientosModelo de requerimientos
Modelo de requerimientos
 
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
Diagramas de Clases, Secuencia, Patrones de Diseño MVC, Disño de Interfaces d...
 
Plantilla caso prueba
Plantilla caso pruebaPlantilla caso prueba
Plantilla caso prueba
 
Requerimientos de usuario y del sistema
Requerimientos de usuario y del sistemaRequerimientos de usuario y del sistema
Requerimientos de usuario y del sistema
 
Concepto y extensiones de negocio de Eriksson Penker
Concepto y extensiones de negocio de Eriksson PenkerConcepto y extensiones de negocio de Eriksson Penker
Concepto y extensiones de negocio de Eriksson Penker
 
Plan de pruebas_inces
Plan de pruebas_incesPlan de pruebas_inces
Plan de pruebas_inces
 
Diagrama desecuenciabiblioteca 1
Diagrama desecuenciabiblioteca 1Diagrama desecuenciabiblioteca 1
Diagrama desecuenciabiblioteca 1
 
Test y pruebas de caja Negra y caja Blanca
Test y pruebas de caja Negra y caja BlancaTest y pruebas de caja Negra y caja Blanca
Test y pruebas de caja Negra y caja Blanca
 
Analisis y Diseño de Sistemas II-2
Analisis y Diseño de Sistemas II-2Analisis y Diseño de Sistemas II-2
Analisis y Diseño de Sistemas II-2
 
Informe final de Auditoria Informatica
Informe final de Auditoria InformaticaInforme final de Auditoria Informatica
Informe final de Auditoria Informatica
 
Taller casos de prueba
Taller casos de pruebaTaller casos de prueba
Taller casos de prueba
 
Software para auditoría informática
Software para auditoría informáticaSoftware para auditoría informática
Software para auditoría informática
 
Plantilla plan pruebas_de_software
Plantilla plan pruebas_de_softwarePlantilla plan pruebas_de_software
Plantilla plan pruebas_de_software
 
Casos de Uso ejercicios
Casos de Uso ejerciciosCasos de Uso ejercicios
Casos de Uso ejercicios
 
Casos De Uso
Casos De UsoCasos De Uso
Casos De Uso
 
Ejemplo
EjemploEjemplo
Ejemplo
 
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareTema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
 
2.6 Pruebas Funcionales.pdf
2.6 Pruebas Funcionales.pdf2.6 Pruebas Funcionales.pdf
2.6 Pruebas Funcionales.pdf
 

Similar a Como uso el formato de pruebas

Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Vanessa Toral Yépez
 
Unidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaUnidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaDarleneperalta
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1naviwz
 
Ciclo de vida del desarrollo de software
Ciclo de vida del desarrollo de softwareCiclo de vida del desarrollo de software
Ciclo de vida del desarrollo de softwareDulce Arenas Garzon
 
Tipos de modelos de procesos
Tipos de modelos de procesosTipos de modelos de procesos
Tipos de modelos de procesosEIYSC
 
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Gustavo Palomo Ureña
 
Segunda web conferencia
Segunda web conferenciaSegunda web conferencia
Segunda web conferencialeidymedina28
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemascardan2007i
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicionEvelin Oña
 
Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...Rodrigo Almeida
 
Auditoria de la seguridad informatica
Auditoria de la seguridad informaticaAuditoria de la seguridad informatica
Auditoria de la seguridad informaticaestudiante
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareDaniel Guaycha
 

Similar a Como uso el formato de pruebas (20)

Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1
 
Unidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaUnidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de prueba
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
 
Ciclo de vida del desarrollo de software
Ciclo de vida del desarrollo de softwareCiclo de vida del desarrollo de software
Ciclo de vida del desarrollo de software
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
Casos de pruebas
Casos de pruebasCasos de pruebas
Casos de pruebas
 
Tipos de modelos de procesos
Tipos de modelos de procesosTipos de modelos de procesos
Tipos de modelos de procesos
 
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
Presentacion del Grupo 6 analisis de sistemas II UNED Costa Rica I Cuatrimest...
 
Segunda web conferencia
Segunda web conferenciaSegunda web conferencia
Segunda web conferencia
 
Conceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseñoConceptos basicos de analisis y diseño
Conceptos basicos de analisis y diseño
 
Temario ceneval yo
Temario ceneval yoTemario ceneval yo
Temario ceneval yo
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemas
 
Trabajo 2 exposicion
Trabajo 2 exposicionTrabajo 2 exposicion
Trabajo 2 exposicion
 
Prueba a los programas
Prueba a los programasPrueba a los programas
Prueba a los programas
 
Prueba a los programas
Prueba a los programasPrueba a los programas
Prueba a los programas
 
Prueba a los programas
Prueba a los programasPrueba a los programas
Prueba a los programas
 
Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...Testing de software en instrumentos de pesar de funcionamiento no automatico ...
Testing de software en instrumentos de pesar de funcionamiento no automatico ...
 
Auditoria de la seguridad informatica
Auditoria de la seguridad informaticaAuditoria de la seguridad informatica
Auditoria de la seguridad informatica
 
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de SoftwareEstándar IEEE 830-1998 - Especificacón de requisitos de Software
Estándar IEEE 830-1998 - Especificacón de requisitos de Software
 
Manual de sistema
Manual de sistemaManual de sistema
Manual de sistema
 

Más de Yesika Rodriguez

Lineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientificoLineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientificoYesika Rodriguez
 
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelcaSistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelcaYesika Rodriguez
 
Declaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_finalDeclaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_finalYesika Rodriguez
 

Más de Yesika Rodriguez (8)

Sistemas informacion
Sistemas informacionSistemas informacion
Sistemas informacion
 
Servicios yesika
Servicios   yesikaServicios   yesika
Servicios yesika
 
Lineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientificoLineamientos generales del_conocimiento_cientifico
Lineamientos generales del_conocimiento_cientifico
 
Uml 2004 para impresion
Uml 2004 para impresionUml 2004 para impresion
Uml 2004 para impresion
 
Seguridad defensa
Seguridad   defensaSeguridad   defensa
Seguridad defensa
 
Curso de project
Curso de projectCurso de project
Curso de project
 
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelcaSistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
Sistema control-recepcion-custodia-y-salida-repuestos-almacen-edelca
 
Declaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_finalDeclaracion conocimiento condiciones_tdc_final
Declaracion conocimiento condiciones_tdc_final
 

Como uso el formato de pruebas

  • 1. DISEÑO DE CASO DE PRUEBAS 1. REQUERIMIENTOS DEL SISTEMA Para la realización de las pruebas de nuestro sistema, realizamos una lista con los requerimientos funcionales y no funcionales solicitados para el correcto desarrollo de nuestro proyecto. 1.1. Requerimientos Funcionales Un requerimiento funcional define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requerimientos funcionales pueden ser: CÁLCULOS, DETALLES TÉCNICOS, MANIPULACIÓN DE DATOS Y OTRAS FUNCIONALIDADES ESPECÍFICAS QUE SE SUPONE, UN SISTEMA DEBE CUMPLIR (REGISTRAR, MODIFICAR, ELIMINAR, GENERAR REPORTES, ENTRE OTRAS). Como se define en la ingeniería de requerimientos, los requerimientos funcionales establecen los comportamientos del sistema. 1.2. Requerimientos No funcionales Un requerimiento no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de software, un requerimiento que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requerimientos funcionales. Por tanto, se refieren a todos los requerimientos que ni describen información a guardar, ni funciones a realizar.
  • 2. Algunos ejemplos de requisitos no funcionales típicos son los siguientes:  Rendimiento  Disponibilidad  Seguridad  Accesibilidad  Usabilidad  Estabilidad  Portabilidad  Costo  Operatividad  Interoperabilidad  Escalabilidad  Concurrencia  Mantenibilidad  Interfaz 2. SELECCIÓN DE MÓDULOS A PROBAR Una vez teniendo en cuenta el listado de los requerimientos procedemos a especificar cuales módulos vamos a evaluar lo hacemos de acuerdo a los requerimientos solicitados y le agregamos un identificador a cada unidad a probar. Por ejemplo, basándonos en los requerimientos:
  • 3. Unidad de Prueba Identificador Acceso MOD1 Contenido MOD2 Interfaz Navegación Seguridad Validación Base de Datos Configuración Comportamiento General NOTA: El ID puede ser cualquier termino que se decida para designar a la unidad a probar. 3. PRUEBA DE LAS FUNCIONES POR MÓDULOS Una vez identificados las unidades o módulos del sistema a probar hacemos una tabla en la que colocamos el identificador del módulo con las funciones que debería cumplir el sistema. Este es un ejemplo Modulo Registrar Eliminar Modificar Calcular Reportes Funcion6 Mod1 SI NA NA NA NA NA Mod2 SI SI SI SI SI SI Mod3 SI NO SI NA NA SI Mod4 SI SI SI NA NA SI Mod5 NA NA NO NO NA SI Mod6 NA NA NA NA NA SI PARA AFIRMACIÓN DE LA FUNCIÓN SE COLOCA (SI), (NO) O (N/A)= NO
  • 4. APLICA O EN SU DEFECTO UNA X O UN VIÑETE DE AFIRMACIÓN Recuerden que las funciones pueden ser Cálculos, detalles técnicos y funciones básicas que debe cumplir el sistema, como de la misma manera se pueden estar evaluando los requemamientos no funciones como: interfaz, acceso, seguridad, usabilidad, entre otras. 4. VEREDICTO DE LAS PRUEBAS Una vez realizada la prueba se hace la descripción para el veredicto y/o resultado generado por la prueba. ID Módulo Probado Resultado obtenido Veredicto observaciones Mod1 Acceso a la interfaz principal Esperado Funcional Mod2 Validación de formularios Esperado Funcional Mod3 Registro de los usuarios Esperado Funcional Mod4 Seguridad de acceso Esperado Funcional Mod5 Conexión con la base de datos Esperado Funcional Mod6 Genera el reporte solicitado Esperado Funcional - El resultado puede ser Esperado o sin resultado (el modulo esta en construcción), o fallido. - Veredicto puede ser Funcional o No Funcional. - Observaciones se coloca cualquier eventualidad presentada durante la prueba. 5. DOCUMENTACIÓN DE LA PRUEBA Por último se realiza una ficha la cual contendrá ciertos datos indispensables de la realización de prueba la cual es la que el PROBADOR certificara y hará constar de la ejecución de la misma.
  • 5. Documentación de la Prueba INSTITUCIÓN RESPONSABLE FECHA NOMBRE DE LA INSTITUCIÓN TITULO DEL PST II DOCUMENTOS DE REFERENCIA Identificador Título Mod1 Acceso a la interfaz principal Fecha de realización: 22-06-2013 Duración de la prueba: 1 hora Requerimientos de la prueba LAPTOP, PENDRIVE... Objetivo Encontrar el mayor numero de errores posibles, para la mejora del sistema. Resultado Esperado Resultado Obtenido Prueba Exitosa SI(X ) NO( ) Estado del Caso de No iniciado En curso Terminado
  • 6. prueba X Personal Requerido Cargo Nombre Firma Profesor/Ingeniero FULANITO Comentarios En este modulo, se encontró una falla de seguridad, no esta cifrada la contraseña. Realizado por: Firma Fecha NOMBRE TUTOR TECNICO 00/00/201X Aprobado por: Firma Fecha TUTOR(A) ACADEMIC@ 00/00/201X