Título del Proyecto

TÉRMINOS DE REFERENCIA (TDR)

ESPECIFICACIONES DE REQUISITOS
DEL SOFTWARE (SRS)

INTEGRANTES DEL EQUIPO

Cédula de Apellidos y Nombres Dirección de

Correo
Identidad

Apellidos y Nombres del docente de proyecto:

Sección:
REVISIONES DEL PROYECTO

Fecha Nº de Revisado por Observaciones

Revisión
 Contenido

1. INTRODUCCIÓN...................................................................................................4
1.2. Propósito del documento....................................................................................4
1.3. Definiciones, siglas y abreviaciones..................................................................4

2. DESCRIPCION DEL PRODUCTO

2.1 Perspectiva del producto......................................................................................4
2.2 Funciones del Producto........................................................................................4
2.3 Limitaciones.........................................................................................................4
2.4 Personal Involucrado............................................................................................4
2.5 Características del usuario.............................................................................-.....4
2.5.1 Perfil del usuario.................................................................................................4
2.5.2 Jerarquía de Usuarios........................................................................................4
2.6 Políticas reguladoras............................................................................................4
2.7 Hardware y Limitaciones......................................................................................4
2.8 Interfaces con otras aplicaciones.......................................................................4
2.9 Funciones de auditoría.........................................................................................4
2.10 Funciones de Control.........................................................................................5
2.11 Protocolos señalados.........................................................................................5
2.12 Requisitos de fiabilidad......................................................................................5
2.13 Credibilidad de la aplicación..............................................................................5
2.14 Consideraciones de seguridad..........................................................................5

3. ESPECIFICACIONES DE LOS REQUERIMIENTOS DE INFORMACIÓN

3.1 Requerimientos Funcionales y No Funcionales...............................................5
3.2 Modelo de Casos de Uso del sistema………….................................................6
3.3 Diagramas de Actividades del sistema..............................................................8

4 RIESGOS
4.1 Estimar los riesgos...............................................................................................9
4.2 Acciones para mitigar los riesgos::....................................................................9
 4
1 Introducción
Breve descripción del contenido del presente documento.

Actualmente se podría decir que el mundo está en constante avance y que los seres humanos

han basado gran parte de sus actividades cotidianas en relación a la tecnología, lo que ha

permitido e impulsado al desarrollo de diferentes e innovadoras aplicaciones y otros

dispositivos que contribuyen en el correcto desenvolvimiento de dichas actividades.

Esta evolución se puede observar en cualquier índole y rama de especialización, ya

que de una u otra manera el ser humano necesita de la tecnología para facilitar o

complementar sus labores; así, también se puede observar en el ambiente educativo, en

todos sus niveles, ya que la tecnología no solo favorece la adquisición de conocimientos

para los estudiantes, o provee de herramientas al personal docente, si no que simplifica las

tareas diarias de todo el personal que en estos centros de conocimiento labora.

En este caso particular, el presente documento contiene una especie de mapa o

esquema, que indica el camino o proceso a seguir para el progreso del sistema propuesto

para el Colegio Presidente Kennedy, y está dirigido a la totalidad de personas involucradas

en la consecución del mismo, sirviendo de apoyo para sentar los requerimientos funcionales

y no funcionales. De este modo, se muestra la definición del producto, especificaciones

técnicas, limitaciones, estructura del proyecto, la delimitación de requerimientos de

información según las sugerencias que La Universidad Nacional Experimental de la Gran

Caracas emite para la elaboración y presentación de proyectos socio tecnológicos, entre

otros.

1.2 Propósito del documento

El presente documento tiene como propósito definir las especificaciones funcionales, no

funcionales del Sistema Informático a implementarse. Para lograr la sistematización de

gestión académica en la coordinación del Colegio Presidente Kennedy, para mejorar así el

sistema de la comunidad brindando así una mejor experiencia académica para los estudiantes

y personal de la comunidad. Es por ello que se realizaran reuniones, talleres en el personal de

la comunidad, para de esta forma recolectar información y para la generación de un sistema

viable y confiable para su uso.

1.3 Definiciones, siglas y abreviaciones. Terminología clave usada en el documento.

 Actor: Es una entidad externa al sistema que se modela y que puede interactuar con él.

 Asignación: Establecer lo que corresponde a algo o alguien para un determinado

objetivo.

 Casos de uso: Es una forma de diagrama de comportamiento UML mejorado. El

Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar

casos de uso, llamada modelo de casos de uso.

 Control: es una etapa primordial en la administración, pues, una estructura

organizacional adecuada y una dirección eficiente, el ejecutivo no podrá verificar cuál es

 la situación real de la organización y no existe un mecanismo que se cerciore e informe si

los hechos van de acuerdo con los objetivos.

 CUC: Colegio Universitario de Caracas.

 Desarrollador: Es un programador o una compañía que se dedica a uno o más aspectos

del proceso de desarrollo de software. Se trata de un ámbito más amplio de la

programación.

 Diagrama: Representación gráfica de las variaciones de un fenómeno o de las relaciones

que tienen los elementos o las partes de un conjunto.

 Gestión: Se denomina gestión al correcto manejo de los recursos de los que dispone una

determinada organización, como por ejemplo, empresas, organismos públicos,

organismos no gubernamentales, etc. El término gestión puede abarcar una larga lista de

actividades, pero siempre se enfoca en la utilización eficiente de estos recursos, en la

medida en que debe maximizarse sus rendimientos.

 Hardware: Se refiere a toda la parte física de una computadora.

 Limitaciones: Hasta dónde puede llegar un proceso de trabajo.

 Procesos: es un conjunto de actividades mutuamente relacionadas o que al interactuar

juntas en los elementos de entrada los convierten en resultados.

 Producto: Resultado de un trabajo realizado con un fin.

 Riesgos: Posibilidad de que se produzca un contratiempo o una desgracia, de que alguien

o algo sufra perjuicio o daño.

 Rup: El Proceso Unificado de Rational es un proceso de desarrollo de software

desarrollado por la empresa Rational Software, actualmente propiedad de IBM

 Sistema: un sistema es módulo ordenado de elementos que se encuentran

interrelacionados y que interactúan entre sí.

 Software: Hace referencia toda aquello intangible de un equipo de cómputo.

 SRS: Especificaciones de Requerimientos de Software.

 Tecnología: Es el conjunto de conocimientos técnicos, científicamente ordenados, que

permiten diseñar y crear bienes, servicios que facilitan la adaptación al medio ambiente y

la satisfacción de las necesidades esenciales y los deseos de la humanidad.

 TDR: Términos de Referencia.

 U.E.C.: Unidad Educativa Colegio.

 UML: Es el lenguaje de modelado de sistemas de software más conocido y utilizado en

la actualidad; está respaldado por el Object Management Group (OMG).

 UNEXCA: Universidad Nacional Experimental de la Gran Caracas.

 Usuario: Es una persona que utiliza un sistema informático. Para que los usuarios puedan

obtener seguridad, acceso al sistema, administración de recursos, etcétera; dichos

usuarios deberán identificarse.

 Web: Concepto que se utiliza en el ámbito tecnológico para nombrar a una red

informática.
2. DESCRIPCION DEL PRODUCTO

2.1 Perspectiva del Producto. Descripción del producto.

El Sistema de gestión académica al servicio de la comunidad educativa Colegio Presidente

Kennedy, tiene como propósito automatizar los procesos de inscripción, carga de notas y

consultas para el control de estudios, consultas de horarios y docentes, el mismo será factible

diseñado para trabajar en el de manera simple y sencilla, con la implementación de este sistema

permitirá una rápida adaptación del personal, generando así información oportuna, precisa y

confiable y así llevar las tareas administrativas.

2.2 Funciones del Producto. Descripción de cada de las funciones del producto.

El Sistema Automatizado, tiene como principal función automatizar los procesos de la

coordinación del colegio Presidente Kennedy, las programaciones académicas, así como a

todos los inherentes a los procesos de Control de Estudios, inscripciones de participantes,

carga de notas y consultas.

2.3 Limitaciones. Establecer el ámbito del producto y sus límites.

Este proyecto vislumbra en general, identificar la situación prioritaria que posee el Colegio

Presidente Kennedy, apoyar a la Coordinación de tercera etapa y diversificado en la

verificación, distribución, asignaciones, notas horarios de maestros, profesores y

estudiantes. Teniendo así una información actualizada.

En cuanto a los equipos, se debe facilitar la gestión integral del proceso actual, pero

los integrantes del equipo de proyecto no harán modificaciones en el sistema intranet de la

institución, no podrán realizar datos ni ingresar a maquinas o documentos sin previa

autorización o verificación. No podrán realizar modificación al hardware que se usará, ni al

software sin previa autorización.

2.4 Personal Involucrado. Descripción de los usuarios funcionales y el equipo del

proyecto, con sus roles y responsabilidades. Utilizar la siguiente plantilla

A continuación, un desglose de los datos de las personas involucradas en la realización del

proyecto, presentes en el proceso de diseña, aprobación, implementación, operación y

evaluación; estos, poseen diversos intereses según sea su afección o no con la puesta en

marcha del proceso.

Tutor Académico

Nombre

Ing. YaksonVerenzuela
Rol Consultor de Proyecto, Tutor Académico y

Asesor.

Categoría profesional

Consultor
Responsabilidades Tutor Académico, asignado por la

universidad para asesorías y consultas

Personal de la comunidad

Nombre Zenaida Rondón

Rol Analista

Categoría profesional Coordinadora de tercera etapa, media técnica

y diversificado del Colegio Presidente

Kennedy
Responsabilidades
Personal de Proyecto

Nombre Ámbar Beltrán, Daleidy Flores, Ana Gascón,

Luis Figueroa
Rol Administradores del Sistema

Categoría profesional

Técnicos Superior en Informática

Responsabilidades

Diseño, desarrollo y prueba del sistema.

2.5 Características del usuario

2.5.1 Perfil del usuario. Cada usuario tendrá un perfil específico para que su interacción con

el sistema sea correcta y no conlleve a fallas. Ejm. Administrador del Sistema, Coordinador,

operador.

En este cada usuario tendrá un perfil específico, y podrá acceder a la cuanto a limitaciones

de usuario, entre otros en el momento de crear los perfiles. información según las limitantes

de dicho acceso, esto con el fin de que su intervención en el sistema sea satisfactoria y no

genere fallas ni violaciones de seguridad y privacidad. Teniendo esto en cuenta, se prevén

diferentes factores como perisología en

2.5.2 Jerarquía de Usuarios. Se debe indicar que puede hacer cada usuario, a fin de

garantizar la seguridad e integridad de los datos.

  Usuario Administrador: Este usuario tendrá acceso a todos los módulos del

sistema, tendrá la capacidad de crear, modificar, consultar y eliminar los usuarios

para el ingreso al sistema, y los datos almacenados en este.

 Usuario Analista: Este usuario tendrá acceso a los módulos de carga y distribución

de horarios.

 Usuario Solicitante: Este usuario solo tendrá acceso al módulo de solicitudes

dentro del sistema, consultar los datos.

2 .6 Políticas reguladoras. Indicar la utilización de estos programas que se hará

mediante las políticas establecidas por el tipo de licenciamiento o bajo software libre.

En este proyecto, durante la realización del desarrollo del software, se aplican

principalmente dos estándares normativos.

ISO 25000:

El objetivo general de la creación del estándar ISO 25000 es organizar, enriquecer y

unificar las series que cubren dos procesos principales:

 Especificación de requerimientos de calidad del software.

 Evaluación de la calidad del software, soportada por el proceso de medición de

calidad del software.

La ISO 25000, proporciona una guía para el uso de las series de estándares

internacionales llamados Requisitos y Evaluación de Calidad de Productos Software

(SQuaRE). La norma establece criterios para la especificación de requisitos de calidad de

productos software, sus métricas y su evaluación, e incluye un modelo de calidad para

unificar las definiciones de calidad de los clientes con los atributos en el proceso de

desarrollo.

La implantación y certificación de un sistema de gestión de la calidad del Software,

de acuerdo a ISO 25000, aporta los siguientes beneficios:

 Diferenciarse de los competidores, asegurándose tiempos de entrega y reducción de

fallos.

 Establecer acuerdos en el ámbito del servicio, definiendo parámetros de calidad que

el producto debe cumplir antes de ser entregado.

 Detectar anticipadamente los defectos y procesar su eliminación.

 Evaluar y controlar el rendimiento del software.

2.7 Hardware y Limitaciones. Describir el hardware donde residirá el software,

conjuntamente con las limitaciones que se tengan

El Equipo donde residirá el software cuenta con las siguientes especificaciones:

  Disco Duro:

 Memoria RAM:

 Procesador:

 Sistema Operativo:

 Lenguaje de Programación:

 PostgreSQL:

Especificaciones para el desarrollo del sistema: lenguaje principal de programación PHP a

partir de la versión 5.4.31, lenguaje de manejo de base de datos SQL, Sistema gestor de base

de datos Postgresql para bases de datos relacionales orientadas a objetos. El sistema será

instalado en los servidores de la comunidad, para que todos los equipos conectados a la red

interna tengan acceso al mismo, aquellos equipos que no estén conectados al servidor que

posea instalado el sistema.

2.8 Interfaces con otras aplicaciones.

El sistema en desarrollo no tiene interactividad con ningún sistema

2.9 Funciones de auditoría

El sistema contará con una tabla de auditoría, donde se almacenarán todos los movimientos

que se realicen en el sistema, desde la creación y autenticación del usuario hasta cualquier

tipo de solicitudes.
2.10 Funciones de Control. El sistema debe controlar los permisos que tiene cada usuario

para su accesibilidad de una manera correcta, de tal forma que pueda acceder a la

información que le corresponde de acuerdo a su rol. Debe tener controles adecuados para la

validación de datos y de igual manera la programación de las actividades específicas para

cada función.

 Verificación de usuarios, de tal manera que cada uno tenga el acceso a las áreas

permitidas del sistema según su rol en el proceso.

 Normalización de la Base de Datos para optimizar el control y minimizar la redundancia

de datos

2.11 Protocolos señalados. Se deberá especificar los protocolos de comunicación.

Ejm. TCP/IP, HTTP.

2.12 Requisitos de fiabilidad.

Para que un sistema posea requisitos de fiabilidad, la veracidad de la información debe

estar ajustada a la realidad, para evitar generar información poco confiable. Es por ello que

se trabaja en base a los siguientes puntos:

 Disponibilidad de uso del sistema cuando sea necesario.

2.13 Credibilidad de la aplicación.

Para garantizar una buena credibilidad el sistema deberá ser sometido a una serie

De pruebas para establecer que se encuentra acorde a los requerimientos que se

Plasman en el documento en tanto a la consistencia de datos como al

Rendimiento de la aplicación, tales como tiempos de respuesta. Sin embargo el sistema debe

ser sometido a distintas pruebas funcionales y no funcionales para lograr la certificación del

software como uno de calidad

2.14 Consideraciones de seguridad.

Cada usuario deberá autenticarse y su acceso verificado, para su respectiva función de

acuerdo a lo que su rol especifique. Todas las claves de seguridad deberán estar seguras y en

su defecto encriptadas en la base de datos para dar una buena seguridad al sistema y su

información. Consiste en garantizar que los documentos, registros y archivos de la

comunidad mantengan siempre su confiabilidad total.

3. ESPECIFICACIÓN DE LOS REQUERIMIENTOS DE

INFORMACIÓN

3.1 Requerimientos Funcionales y No Funcionales

Se deberá describir cada uno de los requerimientos funcionales y no funcionales del

producto a desarrollar. Para ello, se debe contemplar la siguiente plantilla en cada

requerimiento:

Nombre del Sistema

Nombre de la función Grado de Necesidad : Tipo de Requerimiento:

Importante (I) Funcional (F)

Esencial (E) No Funcional (NF)

Entradas: Fuentes: Salida: Destino: Restricciones:

Descripción del

Proceso:

Efecto Colateral:
 6

3.2 Modelos de Casos de Uso del Sistema.

Describe los procesos del sistema, vinculados al campo de acción, y cómo se

benefician e interactúan los usuarios en estos procesos.

Estereotipos

Actor del sistema Caso de uso del sistema

Artefactos del Modelo de Casos de Uso del Sistema.

Modelo de Casos de uso

del sistema
 Actor: Rol que alguien o algo juega cuando interactúa con el sistema para
Diagrama de Casos de
beneficiarse de sus resultados uso del sistema

Candidatos: Rol = Actor

• Clientes o potenciales clientes

Descripción de los Casos
• Socios de uso del sistema

• Proveedores

• Autoridades

• Propietarios

• Sistemas de información externos al sistema

Diagrama de Actividades
desilos
• Otras partes de la organización, Casos
ésta de uso del
es grande.
sistema

Descripción de los casos de uso del Sistema

Caso de uso: < Nombre del caso de uso >

Actores: <Nombre de los actores>
Descripción: <Frases que describan las acciones indicando los actores involucrados

Debe quedar claro como se inicia y termina el caso de uso y de que forma

Intervienen los actores >

Referencias: < Listado de requerimientos y casos de uso asociados,

indicando tipo de asociación (include o extend >

Precondiciones < Cosas que tienen que cumplirse en el sistema para que

se ejecute el caso de uso >

Poscondiciones < Condiciones en las que queda el sistema después que

termina el caso de uso >

Requerimientos especiales < Precisar como el caso de uso es afectado por: las

restricciones de tiempos de respuesta, seguridad,

velocidad, disponibilidad, exactitud o uso de memoria >

Flujo Normal de eventos: < Enumerar la secuencia normal de cada uno de los eventos que

ocurren en el caso de uso >

Flujo alternativo de eventos: < Enumerar la secuencia alternativa de cada uno de los eventos

que ocurren en el caso de uso >

 8

EJEMPLO CASO DE USO:

Caso de uso: Aprobar/rechazar un proyecto

Actores: Jefe de Obra

Descripción: El caso de uso se inicia cuando se han realizado las evaluaciones técnica y

económica de una propuesta de un proyecto y el Jefe de obra debe valorar si se aprueba o no

su ejecución. El sistema debe permitir ver los resultados de estas evaluaciones y permitir que

se registre las conclusiones del Jefe de obra (aprobar/rechazar y alguna otra consideración

que justifique su decisión, culminando la ejecución del caso de uso).

Referencias: R4

Precondiciones Existan proyectos ya evaluados técnica y

económicamente y estén pendientes de aprobación o

rechazo
Poscondiciones Se cambia el estado del proyecto a rechazado o aprobado

y se asocian las causas que motivaron la

Decisión
Requerimientos especiales
Flujo Normal de eventos:
Flujo alternativo de eventos:

3.3 Diagramas de Actividades del Sistema

Estado de actividad: representa la ejecución de un procedimiento o el

funcionamiento de una actividad en un flujo de trabajo.

4 RIESGOS:
 “El riesgo de un proyecto es un evento o condición incierta que, de producirse, tiene

un efecto positivo o negativo en uno o más de los objetivos del proyecto, tales como el

alcance, el cronograma, el costo y la calidad” (PMI, 2013).

Sistema de gestión académica al servicio

de la comunidad educativa Colegio
Presidente Kennedy

Técnicos Externos Organizacionales Administrativos

Tecnológicos Legislación Dependencias del Estimación

proyecto

Calidad Mercado Recursos Planificación

Requerimientos Clima Fondos Control

Comunicación
Sociopolíticos Prioridades

4.1 Estimar los riesgos

Para llevar a cabo la estimación de los riegos se establece una matriz de riegos para

posteriormente exponer situaciones y ponderar su impacto, sea este positivo o negativo.

ID de Ponderación
Descripción del riesgo Impacto Probab. Riesgo
riesgo del Riesgo
Organizacionales y Administrativos
El grupo de trabajo debe ser

capacitado en un corto período de

tiempo, por tal motivo es posible 3

2 6
1 que este periodo de tiempo no sea (Catastrófico 2*3 = 6
(Moderado) (Moderado)
suficiente y se produzcan retrasos )

respecto al mantenimiento de la

aplicación.
Por desconocimiento y poca

experiencia en la lengua de

programación 3 6
2
2 seleccionada/asignada, es posible (Catastrófico 3*2 = 6 ((Moderado
(Moderado)
que se cometan errores ) )

relacionadas con nuevas

funcionalidades del software.

3 Debido a las condiciones laborales 1 3 1*3=3 3

de cada uno de los gestores de (Leve) (Moderado) (Leve)

proyecto se dificulta el acceso en
 conjunto a la comunidad.
Dadas las actuales condiciones en

las que se encuentran los equipos 3

2 5
4 informáticos del Colegio, podrían (Catastrófico 3*2=5
(Moderado) (Moderado)
sufrir algún daño y los fondos son )

insuficientes para reparar el daño.

Falta de recursos materiales y

herramientas para realizar el 2 2 4

5 2*2=4
modelo, tanto por parte del Colegio (Moderado) (Moderado) (Leve)

como de los gestores de proyecto.

Por motivos de la situación
3
pandemia puede que se genera un 2 5
6 (Catastrófico 2*3=5
atraso en comparación al tiempo de (Moderado) (Moderado)
)
desarrollo estimado.
Por diferencia horaria entre las

demás actividades de los gestores

3
de proyecto y el personal de la 1 3
7 (Catastrófico 3*1=3
comunidad, discontinuidad de la (Leve) (Leve)
)
información, y problemas de

comunicación.
Técnicos
Dado al uso de software privativo

para la elaboración de la base de 3

2 6
8 datos es posible que a la hora de (Catastrófico 3*2=6
(Moderado) (Moderado)
desarrollar el modelo, el mismo )

presente errores y no corra.

Externos
 Como resultado de posibles

inundaciones dentro de las

instalaciones de la comunidad. 2 2 4
9 2*2=4
Ocurrirían fallas tales como daños en (Moderado) (Moderado) (Leve)

los data center y en los equipos como

laptops y Pc de escritorios.
Debido a la falta de entrenamiento y

prevención en desalojos del personal

2 2 4
11 a la hora de incendio las condiciones 2*2=4
(Moderado) (Moderado) (Leve)
posibles dentro del Colegio, la vida

del personal este en riesgo.

Dadas las condiciones sociopolíticas

del país, es posible que el país quede

3
días o semanas sin actividad laboral 1 3
12 (Catastrófico 3*1=3
y académica, periodo en el que (leve) (Leve)
)
tampoco se podrá desarrollar el

proyecto.

4.2 Acciones para mitigar los riesgos

 Se determinan acciones para mitigar los riesgos identificados anteriormente de

manera preventiva, de forma tal de contar con un posible plan de contingencia en caso

tal de que el proyecto se enfrente a uno o varios de estos riesgos.

Id de Riesgo Acción para mitigar el riesgo

riesgo

1 Por falta de conocimiento y poca Incorporar los nuevos

experiencia en el lenguaje de requerimientos o los cambios

programación, es posible que se cometan necesarios de forma clara y

errores relacionados con nuevas completa para que se cumplan

funcionalidades del software con la funcionalidad solicitada.

2 Debido a la condición actual de los Se realizaran pruebas piloto en

equipos informáticos, podrían sufrir algún el ambiente. Utilizando un

daño y los fondos son insuficientes para modelo de desarrollo de

reparar el daño. acuerdo al tamaño de la

aplicación, documentación etc.

Para así evitar daños.

3 El grupo de trabajo deber ser capacitado Se realizara una buena

en un corto tiempo, lo cual podría planeación de recursos, tareas

ocasionar retrasos respecto a la y tiempo por si ocurren

utilización de la aplicación imprevistos, también se tendrá

un material donde explique

con detalle el mantenimiento

de ña aplicación.

4 Por diferencia horaria entre las demás Se implementaran reuniones

actividades de los gestores de proyecto y para la aclaración de dudas

el personal de la comunidad, sobre temas puntuales

discontinuidad de la información, y

problemas de comunicación en las

semanas flexibles de cuarentena.