control de estudios fundacite

Especificación de Requerimientos del SoftwareProyecto: Sistema de Control de Estudio

Versión: 1.0

Identificador del documento: ceasl-001

Subdirección de Automatización Informática y Telecomunicaciones

Especificación de requerimientos del softwareSistema de Control de Estudio para el Programa “Academia de Software Libre” Versión: 1.0

Historial de Revisiones

Versión Fecha Autor Descripción

1.0 26/06/2008 Ing. Carla C Montilla Primera versión del documento, todavía no tiene corrección alguna

1.0 Lic. Desiree de Crescenzo

Segunda corrección del documento

1.0 16/01/2009 Ing. Carla C Montilla Tercera corrección del documento

1.01 30/04/09 Lic. Sandra Garces Revisión de los Casos de Uso

Noviembre, 2009 Pág. 2 de 33


Índice de Contenido

1 Introducción..................................................................................................................................................4

1.1 Alcance...............................................................................................................................................................4 1.2 Definiciones, Acrónimos y Abreviaturas..............................................................................................................4 1.3 Documentos relacionados..................................................................................................................................4

2 Casos de Uso...............................................................................................................................................5

2.1 Resumen y Actores.............................................................................................................................................5 2.2 Diagrama............................................................................................................................................................6 2.3 Especificaciones de Casos de Uso...................................................................................................................12 2.4 Usabilidad.........................................................................................................................................................29 2.5 Confiabilidad.....................................................................................................................................................30 2.6 Seguridad.........................................................................................................................................................30 2.7 Eficiencia..........................................................................................................................................................30 2.8 Mantenimiento y Actualización.........................................................................................................................30 2.9 Soportabilidad y Operabilidad...........................................................................................................................30 2.10 Restricción de Diseño.....................................................................................................................................30 2.11 Requerimientos de Documentación en Línea y de Sistemas de Ayuda........................................................30 2.12 Interfaces........................................................................................................................................................31

2.12.1 Interfaces de Usuario..............................................................................................................................31 2.12.2 Interfaces de Software............................................................................................................................31 2.12.3 Interfaces de Hardware...........................................................................................................................31 2.12.4 Interfaces de Comunicaciones................................................................................................................31

2.13 Aspectos Legales............................................................................................................................................31 2.13.1 Políticas de la Organización...................................................................................................................31 2.13.2 Contratos con Otras Organizaciones......................................................................................................31 2.13.3 Propiedad Intelectual..............................................................................................................................31

2.14 Estándares Aplicables....................................................................................................................................32

Noviembre, 2009 Pág. 3 de 33


Especificación de Requerimientos del Software

1 Introducción

1.1 Alcance

Describir el alcance, mencionar los proyectos asociados y determinar que se ve afectado por este documento.

El proyecto asociado es la plataforma de educación a distancia e-learning del Programa “Academia de Software Libre”

1.2 Definiciones, Acrónimos y Abreviaturas

En este apartado se debe mostrar las definiciones de todos los términos, siglas y abreviaciones requeridos para entender este documento, a su vez estas se deben reflejar en el glosario del sistema.

1.3 Documentos relacionados

Para poder visualizar las referencias a otros documentos, se debe de llenar la tabla que se muestra a continuación:

Título Fecha Organización Identificador del documento

<título> <dd/mm/aa> <nombre> <Id documento>

Noviembre, 2009

Pág. 4 de 33


2 Casos de Uso

2.1 Resumen y Actores

Código Caso de Uso Actores participantes

Colocar un código nemotécnico (ID)

Realizar un resumen del caso de uso. Identificar los actores que intervienen.

generalcontrolestudio Presenta el caso de uso general para el sistema de control de estudio, en el cual se observan todos los modulos que el mencionado sistema contempla

Coordinador Académico, instructor y estudiante

casusoadmincurso Presenta el caso de uso que administrara los requerimientos asociados al curso

Coordinador Académico e instructor

casusoadmininstructor Presenta el caso de uso que administrara los requerimientos asociados al instructor

Coordinador Académico

casusoadminlaboratorio

Presenta el caso de uso que administrara los requerimientos asociados al laboratorio


casusoadminencuesta Presenta el caso de uso que administrara los requerimientos asociados a la encuesta

Coordinador Académico y estudiante

casusoadminsistema Presenta el caso de uso que administrara los requerimientos asociados a la seguridad del sistema y perfiles de acceso de los usuarios del mismo


casusoadminestudiante Presenta el caso de uso que administrara los requerimientos asociados al estudiante


casusoadmininstitucion Presenta el caso de uso que administrara los requerimientos asociados a la institución


casusoadminconstancias

Presenta el caso de uso que administrara los requerimientos asociados a las constancias que el sistema debe emitir


Noviembre, 2009

Pág. 5 de 33


2.2 Diagrama

GENERALCONTROLESTUDIO

Noviembre, 2009

Pág. 6 de 33


CASUSO-ADMINCURSO

Noviembre, 2009

Pág. 7 de 33


CASUSO-ADMININSTRUCTOR

Nota: El caso de uso adminpago, cambiará su nombre por administrarpuntocuenta.

Noviembre, 2009

Pág. 8 de 33


CASUSO-ADMINLABORATORIO

Nota: El caso de uso adminlaboratorio, cambiará su nombre por administraraula.

El caso de uso organizar calendario, cambiará su nombre por calendarioaula.

Noviembre, 2009

Pág. 9 de 33


CASUSO-REPORTES

Nota: Definir bien los reportes que generara el sistema, el sistema no trabajara con encuestas de cursos, estas se administrarán desde el moodle

CASUSO-ADMINSISTEMA

Noviembre, 2009

Pág. 10 de 33


Nota: en el caso de uso admin cuentas de usuario, agregar ovalito: asignar permisos de usuario

CASUSO-ADMINESTUDIANTE

Nota: El caso de uso administrarestudiante, cambiará su nombre por administrarparticipante. El actor es el estudiante que asiste al curso, este formulario se ubicara en un link en el moodle, al cual se accesara cada vez que se inicie un curso, si el estudiante realiza un curso y es la primera vez que se inscribe llenara todos sus datos, pero si ya tiene por lo menos un curso realizado no será necesario llenar todos sus datos.

Noviembre, 2009

Pág. 11 de 33


CASUSO-ADMININSTITUCION

2.3 Especificaciones de Casos de Uso

Caso de Uso-casuso-manejarcurso.

Nombre: casuso-manejarcurso.

Descripción: Este caso de uso debe reflejar los distintos procesos que se llevan a cabo para lograr la administración de un curso del Programa “Academia de Software Libre” desde su inicio hasta que finaliza.

Requerimiento: Se requiere tener inscripción de participantes, inscripción de Instituciones que envían a los participantes, asignación de instructor a curso .

Precondición: Se deben cumplir las siguientes condiciones:Registro y autenticación del cliente.Los participantes que participarán en el curso, deben estar previamente pre-inscritos.Se requiere tener aprobado por parte de la dirección ejecutiva el punto de cuenta del instructor, para poder dictar un curso, este dato es requerido en el formulario curso

Flujo Normal:

Actor Sistema

1.Crea la cátedra (del curso) en el cual se especifica: nombre, código, horas y contenido.2.Realiza una planificación de cátedra en función de horarios y fechas.4.Crea un curso, en la cual se indica cátedra a dictar, nombre y datos de los participantes previamente pre-inscritos, instructor que dictara el curso, período de tiempo

3.Guarda la cátedra y lo asocia a una lista de instructores que lo pueden dictar, en función de las fechas y los horarios especificados.5.El Instructore, vacía en el formulario de curso notas obtenidas por el participante.6. El sistema genera los certificados de participación del curso en función de la asistencia de los estudiantes y las notas recibidas.

Noviembre, 2009

Pág. 12 de 33


Caso de Uso-casuso-manejarcurso.

(fechas) durante el cual se dictará el curso , horario y laboratorio.

Poscondición: Después de ejecutarse el caso de uso debe estar listo: Diferentes cátedras con sus características creadas Planificación de cátedra elaborada Formulario de curso elaborado Emisión de certificados

Puntos de Extensión:

Caso de Uso-casuso-adminstructor

Nombre: casuso-adminstructor.

Descripción: Este caso de uso debe reflejar los distintos procesos que se llevan a cabo para lograr la administración de los requerimientos asociados al instructor.

Requerimiento:

Precondición: Se deben cumplir las siguientes condiciones:Registro y autenticación del cliente.

Flujo Normal:

Actor Sistema

1.Crea el instructor e introduce los datos requeridos2.Se crea un punto de cuenta para asociar un intructor con una lista de cursos que debe dictar, una cantidad de horas que debe cumplir en un lapso de tiempo determinado3.Al crearse un curso, se asigna un instructor al mismo, el cual tiene que tener un punto de cuenta asignado, de lo contrario no podrá dictar el curso especificado

4.El sistema debe restar horas del punto de cuenta asignado a un determinado instructor cada vez que el mismo dicte un curso

Poscondición: Después de ejecutarse el caso de uso debe estar listo: Datos del instructor creados en el sistema

Puntos de Extensión: Este caso de uso se extenderá por el sistema administrativo SAID, ya que debe registrar automáticamente al instructor como beneficiario y debe registrar la solicitud de pago del instructor

Noviembre, 2009

Pág. 13 de 33


Caso de Uso-casuso-administrarparticipante

Nombre: casuso-administrarparticipante

Descripción: Este caso de uso debe reflejar los distintos procesos que se llevan a cabo para lograr la administración del ingreso de participantes a las distintas cátedras ofertadas

Requerimiento:

Precondición: Se deben cumplir las siguientes condiciones:Registro y autenticación del cliente.Cátedra a realizar estar creado dentro del sistema.

Flujo Normal:

Actor Sistema

1.El estudiante se pre-inscribe a una cátedra en particular al llenar la planilla de pre-inscripción, ubicada en la página web de la sede del Programa “ASL”3.El estudiante a través de la página Web de Fundacite Carabobo, acepta la participación al curso y realiza su registro indicando los datos solicitados por la página.6. El participante recibe por correo electrónico el login y password para iniciar sesión en la plataforma de educación a distancia del Programa “ASL”, sigue los pasos especificados en la misma y completa la inscripción al curso.

2.El Sistema envía un correo electrónico de invitación a los primeros diez y seis (16) estudiantes pre-inscritos, iniciando en orden cronológico; una vez se halla creado el curso y establecido el mismo en el cronograma de cursos4.El sistema sensa se hallan producido diez y seis (16) registros al curso especificado, de no ser así vuelve al paso dos(2) y lo realiza tantas veces sea necesario hasta lograr el registro de los participantes especificados5. Una vez se tengan los diez y seis (16) participantes registrados, se les envía por correo usuario y password de acceso a la plataforma de educación a distancia del Programa “ASL” para que realicen proceso de inscripción al curso.

Poscondición: Después de ejecutarse el caso de uso debe estar listo: Aspirante con sus datos registrados en el sistema Participante inscrito en el curso deseado

Puntos de Extensión: El sistema de control de estudio debe contar con el módulo de pre-inscripción ubicado en la página web de Fundacite Carabobo. También debe enviar el login y password al usuario para loguearse a la plataforma de educación a distancia del Programa “ASL”

Noviembre, 2009

Pág. 14 de 33


Caso de Uso-casuso-admininstitucion

Nombre: casuso-admininstitucion

Descripción: Este caso de uso debe reflejar los distintos procesos que se llevan a cabo para lograr la administración de las instituciones públicas y privadas manejadas por el sistema

Requerimiento:

Precondición: Se deben cumplir las siguientes condiciones:Registro y autenticación del cliente.Cursos de interés para la institución estar creados en el sistema.

Flujo Normal:

Actor Sistema

1.Crea la institución e introduce los datos requeridos2.Indica los cursos de interés para el personal de la Institución3.Al iniciar el curso el participante debe llenar la planilla de pre-inscripción e indicar a qué Institución pertenece.

Poscondición: Después de ejecutarse el caso de uso debe estar listo: Institución con sus datos creada en el sistema


Caso de Uso-casuso-adminaula

Nombre: casuso-adminaula.

Descripción: Este caso de uso debe reflejar los distintos procesos que se llevan a cabo para lograr la administración de los requerimientos asociados al aula, lugar en el cual se dictan los cursos.

Requerimiento:


Flujo Normal:

Actor

Sistema

1.Crea el aula de cursos e introduce los datos requeridos2.Una vez creado el aula, se procede a la elaboración del calendario del mismo en el cual se especifican las fechas

Noviembre, 2009

Pág. 15 de 33


Caso de Uso-casuso-adminaula

Nombre: casuso-adminaula.

de uso al ser dictado los cursos

Poscondición: Después de ejecutarse el caso de uso debe estar listo: Datos del aula creados en el sistema Calendario de uso de aulas especificado


Caso de Uso-casuso-generarreporte

Nombre: casuso-generarreporte

ripción: Este caso de uso debe reflejar los distintos procesos que se llevan a cabo para lograr la administración de las constancias y reportes que deban ser emitidos por el sistema

Requerimiento:


Flujo Normal:

Actor

Sistema

1.Se indica los datos y parámetros que la constancia debe tener para ser emitida por el sistema

2.El sistema emite el reporte solicitado según los parámetros establecidos por el usuario

Poscondición: Después de ejecutarse el caso de uso debe estar listo: Emisión de reportes o constancias solicitadas


Noviembre, 2009

Pág. 16 de 33


Requerimientos Funcionales

ID del Requerimiento: reqadmincursoadmincursoingresocatedra1

Nombre del Requerimiento: Ingreso de cátedra.

Identificación del requerimiento:

Características: Se debe tomar en cuenta que la definición de cursos debe ser centralizada a través de la Coordinación Nacional de la ASL, para evitar así que se definan los mismos cursos en las distintas ASL con nombres y códigos distintos los cuales nos permitirán generar reportes y estadísticas adecuados.La definición de la codificación debe tomar en cuenta la información del área, subárea y de la materia.

Registro de las cátedras que se encuentran a disposición de las ASL para ser planificadas y dictadas. La información que debe incluir:• Nombre del curso• Cod_curso• Número de horas• Área (desarrollo, administración, soporte, usuario final)• SubÁrea (Lenguajes de programación, herramientas de ofimática, Gestor de Contenidos, etc)• Prelaciones • Descripción• Requisitos del participante (público en general, conocimientos en informática, etc)• Contenido programático

La prioridad es: Alta

ID del Requerimiento: reqadmincursoadmincursoadmincatedra2

Nombre del Requerimiento: Administración de cátedra


Identificación del requerimiento funcional (con un número o un conjunto de caracteres que debe verse reflejado en el apartado de definición, acrónimos y abreviaturas).

Características: Se debe tomar en cuenta que la definición de cursos debe ser centralizada a través de la Coordinación Nacional de la ASL, para evitar así que se definan los mismos cursos en las distintas ASL con nombres y códigos distintos los cuales nos permitirán generar reportes y estadísticas adecuados.La definición de la codificación debe tomar en cuenta la información del área, subárea y de la materia.

Los datos de la materia registrada deben poder actualizarse, modificarse, agregarse y eliminarse


Noviembre, 2009

Pág. 17 de 33


ID del Requerimiento: reqadmincursoorganizacalendariocursocreacalendario3.

Nombre del Requerimiento: Crear y organizar calendario de cátedra

Identificación del requerimiento: Identificación del requerimiento funcional (con un número o un conjunto de caracteres que debe verse reflejado en el apartado de definición, acrónimos y abreviaturas).

Características:

Organización de un calendario de cursos que permita la programación de cursos a dictar durante el año. La información que debe incluir:• Nombre del curso• Horario • Fecha de inicio • Fecha de Fin (Debe calcularse automáticamente en función de la fecha de inicio, del número de horas y del horario)• Instructores • Laboratorio a usar• ObservacionesEl horario del curso debe asociarse con la disponibilidad horaria que tienen los instructores, así mismo para poder asociar un instructor a un curso este debe poseer los curso definidos en su perfil. Los horarios, instructores y espacios físicos deben validarse de manera que puedan ser asociados y a su ves que no existan colisiones ni impedimentos según los atributos de cada uno de estos conceptos.


ID del Requerimiento: reqadmincursoorganizacalendariocatedraadmincalendario3.

Nombre del Requerimiento: Administrar calendario de cátedra


Características:

Los datos del calendario de cursos creados deben poder actualizarse, modificarse, agregarse y eliminarse


Noviembre, 2009

Pág. 18 de 33


ID del Requerimiento: reqadminestudiantecrearestudianteaperturacurso4

Nombre del Requerimiento: Apertura de cursos automática


Características: Es el proceso en el cual se decide que un curso se va a dictar (osea se va realizar). Es el cambio de estatus de planificado a aperturado. La apertura del curso puede ser automática o asistida, la apertura automática es cuando el número de alumnos preinscritos supere en mínimo para aperturar ese curso y se debe notificar por correo electrónico al instructor, al responsable y a los alumnos preinscritos solicitando la confirmación de la preinscripción. La confirmación solo puede ser realizada por el responsable de la ASL y esta debe ser solicitada al participante preinscrito.

Tipos de status: Planificado Confirmado Aperturado Cancelado


ID del Requerimiento: reqadminparticipantecrearparticipanteaperturacurso4

Nombre del Requerimiento: Inicio de curso


Características: Es el proceso establecido por el Coordinador Académico en la fecha y hora que fue pautada en la planificación para dar comienzo al curso. El Coordinador académico, da apertura a un curso al crear el mismo en el sistema especificando los siguientes datos:

cod_curso cod_planificacion fecha_inicio fecha_finalizacion cod_instructor cod_aula hora_inicio hora_finalizacion cod_ptocuenta fecha observaciones Participantes inscritos en el mismo Notas obtenidas por los participantes


Noviembre, 2009

Pág. 19 de 33


ID del Requerimiento: reqadmincursoorganizacalendarioreprogramacioncurso5

Nombre del Requerimiento: Reprogramación de curso


Características: Este proceso se da cuando un curso debe ser modificado en su programación horaria o de fechas.Un curso se puede reprogramar en los siguientes casos:

Cuando un curso se aperturó y no se inicio a la fecha pautada. Cuando un curso esta iniciado y se suspendió por algún motivo.

Al reprogramar un curso no iniciado, los participantes confirmados automáticamente se desconfirman y pasan a ser preinscritos, se debe enviar un correo a todos los participantes confirmados notificando la reprogramación.


ID del Requerimiento: reqadminparticipantecrearparticipantepostulacion6

Nombre del Requerimiento: Postulación


Características: Es el proceso mediante el cual un participante se registra en algún curso de los definidos en la ASL (que no están planificados). La postulación la hace el aspirante al ingresar en la página web del Programa “ASL” y llenar el formulario de preinscripción, especificando los cursos de su interés.


ID del Requerimiento: reqadminparticipantecrearparticipanteconfirmación7

Nombre del Requerimiento: Confirmación


Características: Es el proceso donde un participante preinscrito confirma su asistencia en un curso que ya fue programado, Esta acción se realiza cuando el sistema envía un correo electrónico a todos los preinscritos en una determinada cátedra, en el cual se especifica link dirigido a un formulario de confirmación, en el cual un participante aprueba su asistencia al curso en la fecha y horario especificados . Si al momento de la confirmación el aspirante consigue los cupos de la cátedra llena procederá a anotarse en una lista de espera, la cual tendrá una longitud de siete (7) aspirantes.Una confirmación puede ser desconfirmada.


ID del Requerimiento: reqadminparticipantecrearparticipanteinscripción8

Nombre del Requerimiento: Inscripción de participante

Noviembre, 2009

Pág. 20 de 33



Características: En este momento se debe realizar la inscripción por parte del participante en el curso, habiendo previamente recibido por parte del sistema un correo electrónico de confirmación y asegurar su cupo.Una vez creado el curso, el partcipante en el primer día de clases ingrresará en la plataforma de educación a distancia del Programa “ASL”, en la cual se inscribirá formalmente en el curso.Un participante puede abandonar o retirarse de un curso, lo cual debe reflejarse de forma distinta en el sistema.Un participante no necesariamente tiene que estar postulado o preinscrito para realizar la inscripción en un curso iniciado. Para poder realizar la inscripción a un curso iniciado esta debe estar abierta. Este proceso lo realiza el participante.Los datos que debe tener el participante son los siguientes:

Nombre y apellido del estudiante CI del estudiante Cursos realizados Calificaciones obtenidas Título académico o nivel de instrucción Correo electrónico Teléfonos (habitación, oficina, celular) Dirección Empresa o Institución en la cual labora Estado, Municipio , parroquia en donde vive Género (masculino, femenino) Fecha de nacimiento Tipo de participante (APN, Comunidad, estudiante, etc)


ID del Requerimiento: reqadminsistemaadministrarsederegistrosede9

Nombre del Requerimiento: Registro de sedes


Características: Se refiere a la definición de la infraestructura física de las ASL, incluida su ubicación.

La información que debe incluir.

Código de la Sede. Nombre. Estado, Municipio. Dirección. Teléfonos. Ente Adscrito al MCT( Fundacite, CNTI, Cenditel, cualquier otro ente) Art.17 RPCTIASL.

Noviembre, 2009

Pág. 21 de 33


Director de la Sede Art.24 RPCTIASL. Coordinador Académico de la Sede Art.24 RPCTIASL. Coordinador Técnico de la Sede Art.24 RPCTIASL. Coordinador Administrativo de la Sede Art.24 RPCTIASL.

La apertura de las sedes es centralizada a través de la Coordinación Nacional de la ASL. El código de las sedes debe ser único y representativo de estas a nivel nacional, puede ser el rif de la Institución (Fundacite). Se debería mantener un histórico de autoridades.


ID del Requerimiento: reqadminsistemaadministrarsedeadminsede10

Nombre del Requerimiento: Administración de sede


Características:

Los datos de la sede registrada deben poder actualizarse, modificarse, agregarse y eliminarse


ID del Requerimiento: reqadminorganizacionadmincentrocapregistrarcentrocap11

Nombre del Requerimiento: Registro de centros de capacitación asociados


Características: Se refiere a la definición de la infraestructura física de los Centros de Capacitación de Asociados a la sede, incluida su ubicación.

La información que debe incluir: Código de Centro de Capacitación Tipo: asociado o de la sede Sede a la que pertenece. Estado, Municipio. Dirección. Teléfonos. Correo electrónico Responsable (no lo considera el Reglamento ASL, sin embargo pareciera ser necesario).

La instalación de un Centro de Capacitación Asociado (¿y Sede?) debe ser autorizado por la Sede ASL. Art.32 RPCTIASL.Si es un Centro de Capacitación de Sede se debe establecer el ente al que está adscrita la Sede.Si es un Centro de Capacitación Asociado se debe establecer si es un ente público o privado.


Noviembre, 2009

Pág. 22 de 33


ID del Requerimiento: reqadminorganizacionadmincentrocapadministrarcentrocap12

Nombre del Requerimiento: Administración de centros de capacitación asociados


Características:

Los datos de los centros de capacitación asociados deben poder actualizarse, modificarse, agregarse y eliminarse


ID del Requerimiento: reqadmininstructorcrearinstructorregistroinstructor13

Nombre del Requerimiento: Registro de instructores


Características: Se refiere a la definición de datos generales de los instructores

La información que debe incluir: Código del Instructor (CI del mismo). Nombre y Apellido. Dirección, teléfono Edad, sexo y fecha de nacimiento Nivel Profesional (o grado de instrucción). Tipo de Instructor (Contratado, Honorario Profesional (H.P.), Invitado, etc). Estado (Activo, permiso, etc). Perfil (Descripción general de conocimientos, habilidades y destrezas).

Se deben definir horarios disponibles por los instructores especialmente en los que laboran a destajo (H.P.) y estos deben tomarse en cuenta al momento de asociar un instructor a un curso de forma que los horarios sean compatibles, de igual manera un instructor debe tener asociado los cursos definidos que esta capacitado para dictar y al momento de asociar el instructor al curso el sistema debe validar que el instructor tiene ese curso dentro de sus habilidades. Los horarios asociados a un instructor deben establecerse en base a la disponibilidad en una semana.Los honorarios profesionales a percibir, la cantidad de horas y cursos a dictar, así como el período de contrato serán especificados en un punto de cuenta.


ID del Requerimiento: reqadmininstructormodificarinstructormodificainstructor14

Nombre del Requerimiento: Administración de los datos del instructor


Características:

Los datos de los instructores deben poder actualizarse, modificarse, agregarse y eliminarse

Noviembre, 2009

Pág. 23 de 33



ID del Requerimiento: reqadministraraulaadminaulacrearaula15

Nombre del Requerimiento: Registro de espacio físico (aulas o laboratorios)


Características: Se refiere a las condiciones de los espacios físicos donde se impartirán los cursos planificados.

Se refiere a las condiciones de los espacios físicos donde se impartirán los cursos planificados.La información que debe incluir:

Código del Espacio Físico. Nombre del Espacio Físico. Descripción. Centro de Capacitación al que pertenece. Capacidad. (más dirigido a número de personas, dado se puede dar el caso de uso de portátiles o varias personas por computador) Recursos con los que cuenta (Didácticos, de Infraestructura, tecnológicos,etc). Horario. Número de computadores (Distribución de GNU/Linux) Calendario de uso que especifique la disponibilidad del laboratorio Los espacio físicos son asociados a los cursos cuando se planifican, estos deben verificar y validar especificaciones del curso al

momento de la asociación, tales como número de computadores, etc.


ID del Requerimiento: reqadministraraulaadminaulamodificaraula16

Nombre del Requerimiento: Administración de los datos del aula


Características:

Los datos de las laboratorios o aulas deben poder actualizarse, modificarse, agregarse y eliminarse


Noviembre, 2009

Pág. 24 de 33


ID del Requerimiento: reqadministraraulacalendarioaulacrearcalendario17

Nombre del Requerimiento: Elaboración de calendario del aula


Características:

El control de la disponibilidad y uso de un aula se controlará a través de un calendario, en el cual se especificarán los siguientes datos:Código del aulaCódigo de planificaciónStatus de la planificaciónHorario de uso del aulaFecha de inicioFecha de finalizaciónObservaciones


ID del Requerimiento: reqadministraraulacalendarioaulamodificarcalendario18

Nombre del Requerimiento: Administración de los datos del calendario del aula


Características:

Los datos del calendario deben poder actualizarse, modificarse, agregarse y eliminarse


ID del Requerimiento: reqgenerarreportesexpedirconstancias19

Nombre del Requerimiento: Constancias

Identificación del requerimiento: Se refiere a las constancias que deben ser emitidas por el sistema

Características: Se refiere a las condiciones de los espacios físicos donde se impartirán los cursos planificados.

Las constancias que el sistema debe emitir son: Constancia de estudios Constancia de notas Constancia de inscripción en un curso o perfil específico

Estas constancias deben permitirle al estudiante monitorear el récord de su actividad académica.


Noviembre, 2009

Pág. 25 de 33


ID del Requerimiento: reqgenerarreportesexpedirreportes20

Nombre del Requerimiento: Reportes


Características: Se refiere a los reportes que deben ser emitidos por el sistema

Reporte de Aulas: (Espacio Físico) Reporte de Aulas Reporte de número de computadores por Aula Reportes de cursos planificados en las aulas en un periodo determinado (Rango de fechas).

Reporte de Cursos: Reporte de cursos dictados: por rango de fecha, por cátedra, por perfil, por horario, por instructor Reporte de catedras planificados, aperturados, iniciados y finalizados.

Estos reportes deben realizarse por fechas y otros criterios. El sistema debe permitir de alguna forma que se pueda establecer una comunicación con las demás academias a fin de generar estadísticas en tiempo real sobre los reportes de Curso.

Reportes de Participantes: Reporte de participantes por cursos: asistentes, aprobados y retirados. Reporte de participantes por Instituciones, estudiantes, municipios, otros. Reporte de cantidad de participantes: capacitadas por curso. Cursos postulados preinscritos, inscritos y culminados por un participante.

Reporte de Instituciones Reporte de cantidad de Instituciones: capacitadas por curso y por perfil Reporte de Instituciones registradas y sus datos Reporte que especifica cursos recibidos por una determinada Institución y el personal que los recibió

Reporte de Puntos de cuenta Reporte de puntos de cuenta aprobados por rango de fecha con sus respectivos datos Reporte que especifica un determinado punto de cuenta para un determinado curso Puntos de cuenta asociados a un Instructor Horas trabajadas por un Instructor, restantes del punto de cuenta

Reporte de Centros de capacitación Listado de Centros de capacitación asociados a una sede Listado de cursos dictados en un determinado centro de capacitación Listado de aulas disponibles en un centro de capacitación

Reporte de Instructores: Reporte de cursos planificados, aperturados, iniciados y cerrados. Reporte de horas laboradas.

Todos los reportes deben considerarse en periodos de tiempo, así como otros criterios


Noviembre, 2009

Pág. 26 de 33


ID del Requerimiento: reqadmininstructoradminpuntocuentacrearpago21

Nombre del Requerimiento: Crear acta de control de informe de pago al instructor


Características: Se debe crear un acta que permita realizar seguimiento de curso a pagar

Los datos que se debe manejar son: Nombre del curso fecha de inicio fecha de finalización Nombre y apellido del instructor CI del instructor Horas dictadas Fecha de entrega de informe del instructor Responsable del trámite del pago Total a pagar


ID del Requerimiento: reqadmininstructoradminpuntocuentaadminpago22

Nombre del Requerimiento: Administración de acta de control de informe de pago al instructor


Características:

Los datos del acta de pago al instructor deben poder actualizarse, modificarse, agregarse y eliminarse


ID del Requerimiento: reqadmininstructoradminpuntocuentacrearpuntocuenta23

Nombre del Requerimiento: Crear acta de control de punto cuenta de Instructor


Características: Se debe crear un acta que permita realizar seguimiento de puntos de cuenta asociados a cursos e instructores

Los datos que se debe manejar son: Nombre del curso fecha de inicio fecha de finalización Nombre y apellido y CI del instructor Horas dictadas Costo de hora del instructor Fecha de elaboración de requisición que genera el punto de cuenta


Noviembre, 2009

Pág. 27 de 33


ID del Requerimiento: reqadmininstructoradminpuntocuentaadminpuntocuenta24

Nombre del Requerimiento: Administración de acta de control de punto de cuenta del instructor


Características:

Los datos del acta de control de punto de cuenta del instructor deben poder actualizarse, modificarse, agregarse y eliminarse


ID del Requerimiento: reqadminsistemaadmincuentascuentausuario25

Nombre del Requerimiento: Crear cuenta de usuario


Características: Se debe crear una cuenta para cada usuario del sistema que controle el ingreso al mismo y que establezca los niveles y permisos de uso que tendrá el usuario

Los datos que se debe manejar son: CI usuario Permisos Login Password

Se debe establecer una jerarquía de usuarios que garantice el acceso y seguridad de la aplicación, que maneje los siguientes datos: cod_tipo descripción


ID del Requerimiento: reqadminsistemaadmincuentasadmincuentausuario26

Nombre del Requerimiento: Administración de cuentas de usuario


Características:

Los datos de la cuenta de usuario deben poder actualizarse, modificarse, agregarse y eliminarse


Noviembre, 2009

Pág. 28 de 33


ID del Requerimiento: reqadministrarorganizacionadmininstitucioncrearinstitucion27

Nombre del Requerimiento: Crear Institución


Características: Se debe crear una planilla en la cual se especifiquen los datos de Institución pública o privada que solicita cursos de adiestramiento para su personal

Los datos que se debe manejar son: Nombre o razón social de la Institución RIF de la Institución Nombre y apellido de la persona contacto en la Institución CI de la persona contacto Cargo de la persona contacto Correo electrónico de la persona contacto Teléfonos (habitación, oficina, celular) de la persona contacto Dirección de la Institución Estado, Municipio donde se ubica la Institución

Se debe establecer una jerarquía de usuarios que garantice el acceso y seguridad de la aplicación


ID del Requerimiento: reqadministrarorganizacionadmininstitucionadmininstitucion28

Nombre del Requerimiento: Administración de planilla con datos de la Institución


Características:

Los datos de la planilla con los datos de la Institución deben poder actualizarse, modificarse, agregarse y eliminarse


Noviembre, 2009

Pág. 29 de 33


ID del Requerimiento: reqadmincursoadminincertificadocrearcertificado29

Nombre del Requerimiento: Administración de certificado


Características: El sistema debe generar de forma automática los certificados de cada curso dictado

Los datos que se debe manejar son: Nombre del curso dictado Nombre y apellido del participante al cual se le hace entrega del certificado CI del participante Horas de duración del curso En la parte posterior del certificado se debe especificar el contenido programático manejado en el curso Nombre y apellido del Presidente de la Institución que firma el certificado Número correlativo del certificado que identifique: Sede y centro de capacitación

Se debe tomar en cuenta que el certificado puede ser de asistencia o de aprobación, en el caso de que el estudiante no halla cumplido con la nota mínima aprobatoria del curso se hace entrega de un certificado de asistencia, en el caso de que el estudiante halla faltado a un total del 25% de las clases no se hace entrega de ningún certificado.El instructor al vaciar las notas del estudiante deeb especificar si este cumplio con los requerimientos mínimos de asistencia especificados en el reglamento del Programa “ASL”


Requerimientos No Funcionales

Describa los requerimientos no funcionales para este documento. Los requerimientos no funcionales tienen que ver con las características que de una u otra forma puedan limitar el sistema como son: el rendimiento (en tiempo y espacio), confiabilidad, interfaces, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

2.4 Usabilidad

En este apartado se debe incluir la lista de todos los requerimientos que afecten la usabilidad. Esto debe incluir: el tiempo que se tomará un usuario en aprender a utilizar el sistema y se podría explicar por qué debe ser rápido el aprendizaje, los tiempos medibles de tarea para las tareas típicas y los requerimientos para concordar con estándares.

2.5 Confiabilidad

Aquí se deben detallar los requerimientos de confiabilidad del sistema. Describa las características de confiabilidad explicando la posibilidad del sistema de realizar las funciones para las que fue diseñado sin presentar fallos. Entre estos requerimientos puede mencionar características como la disponibilidad, el porcentaje de fallas máximo, etc.

Noviembre, 2009

Pág. 30 de 33


2.6 Seguridad

Aquí se deben detallar los requerimientos de seguridad del sistema. Esto incluye si el acceso al sistema será controlado con nombres de usuario y contraseñas, que solo los usuarios con privilegios de administrador podrán acceder a las funciones administrativas y los usuarios normales no podrán.

2.7 Eficiencia

En este apartado se debe ver reflejado las características de eficiencia del sistema. Se debe especificar: el tiempo de respuesta para una transacción (promedio), capacidad (número de clientes y transacciones), rendimiento del procesamiento (Ej. transacciones por segundo) y cuando el sistema se ha degradado cuál es el modo aceptable de operación.

2.8 Mantenimiento y Actualización

En este apartado se debe ver reflejado los requerimientos de mantenimiento y actualización. La capacidad de mantenimiento es la habilidad que se tiene para realizar cambios al producto en el tiempo y la capacidad de actualización es la habilidad que se tiene para entregar las versiones del producto a bajo costo a los clientes con un mínimo de tiempo de descarga. Una característica clave para apoyar este objetivo es la descarga automática de parches o actualizaciones y actualizaciones del equipo del usuario final. También debemos utilizar formatos para archivos de datos que incluyan suficientes metadatos para permitirnos trasformar con seguridad la información existente del usuario durante una actualización.

2.9 Soportabilidad y Operabilidad

Especificar los requerimientos de soportabilidad y operabilidad del sistema. La soportabilidad la habilidad de proveer soporte técnico eficiente y a buen precio y la operabilidad es la habilidad que se tiene de hospedar y operar el software como un ASP (Proveedor de Servicios de Aplicaciones).

2.10 Restricción de Diseño

En este apartado se debe indicar cualquier limitación de diseño en el sistema que es construido. Por ejemplo: lenguajes de software, requerimientos del proceso de software, uso de herramientas de desarrollo, componentes comprados, etc.

2.11 Requerimientos de Documentación en Línea y de Sistemas de Ayuda

En caso de que exista se debe describir los requerimientos, para la documentación en línea del usuario, sistemas de ayuda, ayuda sobre avisos, etc.

2.12 Interfaces

En este apartado se definen las interfaces que debe apoyar la aplicación, como son: las interfaces de usuario, interfaces de software, etc. En caso de que aplique es conveniente hacer referencia a estándares de la aplicación o corporativos.

Noviembre, 2009

Pág. 31 de 33


2.12.1 Interfaces de Usuario

Describir las interfaces de usuario que van a hacer ejecutadas por el software.

2.12.2 Interfaces de Software

Hay que describir las interfaces de software hacia otros componentes del sistema. Pueden ser: componentes comprados, reutilizados o realizados para subsistemas fuera del alcance de este documento.

2.12.3 Interfaces de Hardware

Aquí se describen comentarios de cualquier interfaz de hardware que debe ser apoyada por el software, esto incluye: comportamiento, estructura lógica, etc.

2.12.4 Interfaces de Comunicaciones

Se debe definir las interfaces de comunicaciones a los demás sistemas o dispositivos como: redes LAN y dispositivos seriales remotos.

2.13 Aspectos Legales

Este punto define las cuestiones legales que pudieran afectar esta entrega. No considerar cuidadosamente estas cuestiones puede poner a la organización de desarrollo en riesgo de una acción legal. Busque consejo profesional si es necesario.

2.13.1 Políticas de la Organización

Debe responder la siguiente pregunta: ¿El producto satisface las políticas de la organización (por ejemplo, de privacidad y seguridad)? Sí. Describa cómo se satisfacen cada una de estas políticas.No. Describa los pasos a tomar para hacer que el producto las cumpla. No. No hay políticas que apliquen.

2.13.2 Contratos con Otras Organizaciones

Debe responder la siguiente pregunta: ¿Fue algún componente o información producido por otra organización bajo contrato? Sí. Revise los detalles del contrato para derechos de propiedad y licenciamiento. No. No se requiere hacer nada al respecto.

2.13.3 Propiedad Intelectual

Componente Dueño Licencia Estado Comentarios

Nombre del producto NosotrosMarca Registrada

Registro pendientedebemos usar "(TM)", no "(R)"

Base de datos Distribuidor GNU GPLEn conformidad, cobra cuota estándar

Se limita a 2 procesadores/servidores

Noviembre, 2009

Pág. 32 de 33


Imágenes de clip-art NingunaDominio público

En conformidad

Librería de controladores de sonido

OS del Proyecto BSD En conformidad

Indexador de la máquina de búsqueda

OS del Proyecto GPL En conformidadEl indexador correo en un proceso aparte, no hace nuestro código GPL.

Otras librerías OS del Proyecto BSD En conformidad

Patente de algoritmo especial

NosotrosPatente pendiente

En conformidadBúsqueda de patente terminada, aplicación de patente en revisión.

2.14 Estándares Aplicables

En este apartado se debe describir por referencia cualquier estándar aplicable y las secciones específicas de dichos estándares que se apliquen al sistema, como son: estándares de calidad aspectos legales, interoperabilidad, internacionalización, estándares de seguridad de la información, compatibilidad del sistema operativo, etc.

Noviembre, 2009

Pág. 33 de 33

control de estudios fundacite

Documents