Documentación Del Modelado de Análisis PDF

INSTITUTO TECNOLÓGICO
SUPERIOR DE COATZACOALCOS
ING. EN SISTEMAS COMPUTACIONALES
Fundamentos de Ingeniería de Software
Software educativo para el

aprendizaje en matemáticas de
alumnos de 5to y 6to nivel primaria
Que presentan:
16080813 CASTILLO VALDIVIESO ROGER

16081346 FERNÁNDEZ LÓPEZ AURORA
16081347 IGNOT ANTELE JAIR
16081337 MORALES CASTILLO ILSE ALINE
INSTRUCTORA:
L.I. ZOFIA BENITEZ ALONSO
ÍNDICE
ÍNDICE
INTRODUCCIÓN........................................................................................................................... 4
INGENIERÍA DE REQUISITOS (NORMA IEEE 830) ................................................................... 5
HISTORIAL DE REVISIONES ...................................................................................................... 7
CONTENIDO ................................................................................................................................. 8
1 INTRODUCCIÓN ................................................................................................................ 10
1.1 Propósito ....................................................................................................................... 10
1.2 Alcance .......................................................................................................................... 10
1.3 Personal involucrado ................................................................................................... 10
1.4 Definiciones, acrónimos y abreviaturas .................................................................... 11
1.5 Referencias ................................................................................................................... 11
1.6 Resumen ....................................................................................................................... 12
2 DESCRIPCIÓN GENERAL ................................................................................................ 12
2.1 Perspectiva del producto ............................................................................................ 12
2.2 Funcionalidad del producto ........................................................................................ 13
2.3 Características de los usuarios .................................................................................. 14
2.4 Restricciones ................................................................................................................ 14
2.5 Suposiciones y dependencias .................................................................................... 14
2.6 Evolución previsible del sistema ................................................................................ 14
3 REQUISITOS ESPECÍFICOS ............................................................................................ 15
3.1 Requisitos comunes de los interfaces ....................................................................... 16

3.1.1 Interfaces de usuario ................................................................................................. 16
3.1.2 Interfaces de hardware .............................................................................................. 16
3.1.3 Interfaces de software ................................................................................................ 16
3.1.4 Interfaces de comunicación ....................................................................................... 17
3.2 Requisitos funcionales ................................................................................................ 17

3.2.1 RF1: Validar usuario. ................................................................................................. 17
3.2.2 RF2: Insertar y actualizar datos de usuario. .............................................................. 17
3.2.3 RF3: Cambio de contraseña ...................................................................................... 17
3.2.4 RF4: Asignar permisos a usuario............................................................................... 17
Descripción de requisitos del software

3.2.5 RF6: Realizar operaciones matemáticas para el desarrollo matemático de los
alumnos. .................................................................................................................................. 17
3.2.6 RF7: Diferentes tipos de juegos o actividades didácticas para la compresión de los
temas de plan de estudios. ..................................................................................................... 17
3.2.7 RF9: Animaciones. ..................................................................................................... 18
3.3 Requisitos no funcionales........................................................................................... 18

3.3.1 Requisitos de rendimiento ......................................................................................... 18
3.3.2 Seguridad ................................................................................................................... 18
3.3.3 Fiabilidad .................................................................................................................... 18
3.3.4 Disponibilidad ............................................................................................................. 18
3.3.5 Mantenibilidad ............................................................................................................ 19
3.3.6 Portabilidad ................................................................................................................ 19
3.4 Otros requisitos ............................................................................................................ 19
4 APÉNDICES ....................................................................................................................... 20
DIAGRAMAS UML ..................................................................................................................... 21
ESTUDIO DE FACTIBILIDAD .................................................................................................... 31
METODOLOGÍA ......................................................................................................................... 36
CONCLUSIÓN ............................................................................................................................ 40
REFERENCIAS ........................................................................................................................... 41

INTRODUCCIÓN
En el curso anterior, vimos a los conceptos básicos de la ingeniería de software
para que como estudiantes pudiésemos comprender y llevar a cabo el
desarrollo de un proyecto de software. Actualmente nos encontramos en la
parte más cercana para comenzar con el desarrollo total de nuestro proyecto,
en la primera unidad hacemos énfasis en el análisis de los requerimientos de
software, para que así, se tenga una mejor base para comenzar con la
programación. Algo que se tiene que tomar en cuenta en esta etapa del
proyecto es la Norma IEEE 830, la cual nos da un índice de como estructurar
los elementos del proyecto y delimitar los requerimientos. Al encontrarnos
nosotros en una posición de empresa desarrolladora de softwares enfocados a
la educación, tomamos pequeñas partes de en referencia a algunos sistemas
ya existentes para lograr estructurar un diseño, y especificar los requisitos de
nuestro programa.

Ingeniería de Requisitos
(Norma IEEE 830)

1
Especificación de requisitos de
software
Proyecto: Software educativo para el aprendizaje en
matemáticas de alumnos de 5to y 6to nivel primaria
Revisión 2.0
Febrero 2019

Historial de Revisiones
Fecha Revisión Descripción Autor
24/02/2019 1.0 Estructura de la Ilse Aline Morales

documentación SRS Castillo
01/03/2019 2.0 Requerimientos funcionales y Aurora Fernández
no funcionales López
Documento validado por las partes en fecha: 07/03/19
Por el cliente Por la empresa suministradora
Escuela primaria « Calidad educativa » Tec4s
Fdo. D./ Dña Darío Alberto Mena Pan Fdo. D./Dña Aurora Férnandez López
Software educativo para el aprendizaje en
Rev. 1.0
matemáticas de alumnos de 5to y 6to nivel primaria.
Pág. 8
Especificación de requisitos de software.
Contenido
HISTORIAL DE REVISIONES 7
CONTENIDO 8
1 INTRODUCCIÓN 10
1.1 Propósito 10
1.2 Alcance 10
1.3 Personal involucrado 10
1.4 Definiciones, acrónimos y abreviaturas 11
1.5 Referencias 11
1.6 Resumen 12
2 DESCRIPCIÓN GENERAL 12
2.1 Perspectiva del producto 12
2.2 Funcionalidad del producto 13
2.3 Características de los usuarios 14
2.4 Restricciones 14
2.5 Suposiciones y dependencias 14
2.6 Evolución previsible del sistema 14
3 REQUISITOS ESPECÍFICOS 15
3.1 Requisitos comunes de los interfaces 16

3.1.1 Interfaces de usuario 16
3.1.2 Interfaces de hardware 16
3.1.3 Interfaces de software 16
3.1.4 Interfaces de comunicación 17
3.2 Requisitos funcionales 17

3.2.1 RF1: Validar usuario. 17
3.2.2 RF2: Insertar y actualizar datos de usuario. 17
3.2.3 RF3: Cambio de contraseña 17
3.2.4 Requisito funcional 4 Asignar permisos a usuario. 17
3.2.5 Requisito funcional 6. Realizar operaciones matemáticas para el desarrollo
matemático de los alumnos. 17
3.2.6 Requisito funcional 8. Diferentes tipos de juegos o actividades didácticas para la
compresión de los temas de plan de estudios. 17
3.2.7 Requisito funcional 9. Animaciones para llamar la atención de los usuarios. 18
3.3 Requisitos no funcionales 18

Rev. 1.0
Pág. 9
3.3.1 Requisitos de rendimiento 18

3.3.2 Seguridad 18
3.3.3 Fiabilidad 18
3.3.4 Disponibilidad 18
3.3.5 Mantenibilidad 19
3.3.6 Portabilidad 19
3.4 Otros requisitos 19
4 APÉNDICES 20

Rev. 1.0
Pág. 10
1 Introducción
La finalidad del presente documento será aquellos requisitos y especificaciones para la
elaboración del software Mathware como lo son los requerimientos específicos, el alcance
del proyecto, el personal involucrado, las características del proyecto, los requisitos
comunes, funcionales y no funcionales con la finalidad de dar las bases a los
desarrolladores de software y así comprender las ideas y expectativas del proyecto.
Ayudará en el desarrollo en el análisis y entendimiento de lo que el cliente desea
describiendo lo que realmente desea obtener del sistema. Con base a los datos que se
habrán de recabar se pretender tener una idea lo más cercana posible a la visión del
cliente. Para cada requerimiento se indicaran cuáles son los factores que se involucraron
para considerarlo como un factor necesario para incluirlo en la elaboración del software y
cuál es el personal involucrado con el cual estará relacionado e interactuando para cada
disposición que se requiera como manipulación del software.
Presentar un modelo a seguir para la interfaz gráfica del usuario, interfaz de hardware y
software, definir usuarios, sus características y sus privilegios en la interacción con la web.
Así como tomar en cuenta ciertos factores de restricción, suposiciones y dependencias.
Plantear los requisitos específicos, funcionales y no funcionales será la parte más
importante en este documento.
1.1 Propósito
 El objeto de las especificaciones en este documento es puntualizar de manera
clara y precisa los módulos, herramientas, funcionalidades y restricciones para
el proyecto a desarrollar.
 Poner en práctica técnicas de recolección de requisitos.
 Conocer la visión del cliente.
 Definir los requisitos operacionales y de interfaz.
 Definir requerimientos funcionales y no funcionales.
 Dirigido al personal encargado del desarrollo.
1.2 Alcance
Diseño e implementación del sistema web Mathware en la nube, en el cual podrán
accesar en cualquier equipo fuera o dentro de la institución. Los alumnos de quinto y
sexto en centros educativos se verán beneficiados al estar interactuando con el sistema.
Desarrollan sus conocimientos en las matemáticas y se adentran a las tecnologías de la
información aplicadas a la educación.
1.3 Personal involucrado

Nombre Aurora Fernández López.
Rol Líder de proyecto. Diseñadora de BD.
Categoría profesional Estudiante.
Responsabilidades Seguimiento al desarrollo del proyecto. Verificar el trabajo de
los desarrolladores y diseñadores.
Información de contacto Tel: 921 246 5236. Mail: aurora_fl97@gmail.com
Aprobación
Nombre Jair Ignot Antele.

Rol Programador.
Responsabilidades Desarrollo del sistema en lenguaje de programación.
Información de contacto Tel: 921 261 9628. Mail: jayr.ignot@gmail.com
Aprobación

Rev. 1.0
Pág. 11
Nombre Ilse Aline Morales Castillo.

Rol Analista de sistemas.
Responsabilidades Análisis de los requerimientos y especificaciones del
sistema a desarrollar.
Información de contacto Tel: 921 103 8065
Aprobación
Nombre Castillo Valdivieso Roger

Rol Analista de sistemas.
Categoría profesional Estudiante
Responsabilidades Análisis de los requerimientos y especificaciones del
sistema a desarrollar.
Información de contacto Tel: 921 865 2536
Aprobación
1.4 Definiciones, acrónimos y abreviaturas

BD: Base de datos. Cualquier conjunto de datos organizados para su almacenamiento
en la memoria de un ordenador o computadora, diseñado para facilitar su mantenimiento
y acceso de una forma estándar. La información se organiza en campos y registros. Un
campo se refiere a un tipo o atributo de información, y un registro, a toda la información
sobre un individuo.
Interfaz: Medio que permite la comunicación entre el usuario y el sistema.
Servidor: Computadora conectada a una red que pone sus recursos a disposición del
resto de los integrantes de la red. Suele utilizarse para mantener datos centralizados o
para gestionar recursos compartidos.
Sitio Web: Se canaliza a través del URL o identificador único de cada página de
contenidos. Este sistema permite a los usuarios iniciar una solicitud de trámite y
a los funcionarios del Agua Potable atender las solicitudes e ingresar datos
de las inspecciones realizadas.
SRS: Acrónimo de Software Requeriments Specifications (Especificación de
Requerimientos de Software)
SW: Software. Conjunto de programas y rutinas que permiten a la computadora realizar
determinadas tareas.
1.5 Referencias
Referencia Titulo Ruta Fecha Autor
IEEE Recommended https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf 22 de Gonzalo

Practice for Octubre Méndez
Software de 2008
Requirements
Specification

Rev. 1.0
Pág. 12
1.6 Resumen
En el presente documento SRS se encuentra información referente a requisitos la
plataforma web Mathware que se puedan tomar en cuenta en su elaboración e
implementación.
La estructura de este documento será la siguiente:
Introducción: En ésta sección se detalla los objetivos que tiene esta especificación de
requisitos y de nuestro sistema en forma general.
Descripción general: Describe una perspectiva general del producto a
desarrollarse, como también las características del usuario y las limitaciones que
podría tener.
Requerimientos específicos: Aquí encontramos todos los requerimientos que el
usuario desea que se implementen en el producto final.
2 Descripción general
Mathware es un sistema para fines educativos desarrollado a manera de plataforma web.
Permite a maestros enseñar la materia de matemáticas de forma interactiva a niños de 5to y
6to de primaria. Mathware debe lograr que los alumnos tengan más interese por las
matemáticas básicas aumentando sus conocimientos al mismo tiempo que aprenden las
tecnologías de la información aplicadas a la educación.
2.1 Perspectiva del producto

Para el funcionamiento de Mathware será necesario el uso de un servidor donde estará
almacenada la base de datos de usuarios y actividades en general. Además de un
navegador web. Al tratarse de una web necesita de las tecnologías que ofrece un
navegador para su visualización, uso y comunicación con las BD.
Servidor
Navegador
Mathwar
Respuesta Resultado html
e
Peticiones

Rev. 1.0
Pág. 13
2.2 Funcionalidad del producto
Modelado del sistema. Diagrama de casos de uso.

Mathware contará con 4 tipos de usuarios: Maestro, alumno y padre o tutor.
Cada usuario tiene ciertos privilegios siendo el maestro quien tiene más.
El maestro tiene capacidad de agregar, eliminar alumnos, asignar calificaciones y tareas,
así como premiar a alumnos.
El alumno únicamente puede visualizar actividades y entregarlas, entre otros atributos.
El padre o tutor únicamente puede visualizar en avance y tareas del alumno.

Rev. 1.0
Pág. 14
2.3 Características de los usuarios

Tipo de usuario Maestro
Formación Profesionista
Habilidades Informática básica
Actividades Agregar alumno, eliminar alumnos, calificar, asignar actividades,
establecer logros y permisos y asignar evaluación.
Tipo de usuario Alumno

Formación Estudiante
Actividades Ver actividades, ver calificaciones, entrega actividades, acumula
puntos y gana premios.
Tipo de usuario Invitado (Tutor)

Formación No necesario
Actividades Ver actividades y calificaciones.
2.4 Restricciones
 Los servidores deben ser capaces de atender consultas frecuentes.
 El sistema deberá tener un diseño e implementación sencilla, independiente de
la plataforma o del lenguaje de programación, de uso sencillo para alumnos.
 No puede haber usuarios duplicados.
 Para las consultas, inserciones, modificaciones y borrados de la BD, se utilizará
el lenguaje de consulta MySQL.
 Las características del hardware será las mínimas requeridas.
 Lenguajes y tecnologías: HTML5.
 IDE: Neatbens, Visual studio code.
 Conexión a Internet.
2.5 Suposiciones y dependencias

 Debido a que el sistema interactúa con el usuario a través de un navegador web
es necesario desarrollar la conexión con el mismo.
 Las conexiones necesarias para la comunicación del servidor web, MySql,
HTML5, se hará por medio de la configuración de estas tecnologías.
 Se asume que el sistema operativo es capaz de soportar la integración con un
navegador básico ya sea móviles o computadoras personales.
2.6 Evolución previsible del sistema

Se prevé que el software reciba futuras actualizaciones de seguridad como encriptación
de la información de cada alumno en la base de datos. A petición del usuario se harán
actualizaciones que se crea convenientes según el alcance del proyecto.

Rev. 1.0
Pág. 15
3 Requisitos específicos
Número de requisito RF01
Nombre de requisito Requisito general de la interfaz de usuario
Tipo Requisito Restricción
Fuente del requisito Diagrama de Caso de Usos.
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
RF01.- La interfaz de usuario diseñada deberá tener facilidad de uso.

Nombre de requisito Registrar Usuarios.
RF02.- El software deberá reconocer al usuario mediante su matrícula como su id único.

Nombre de requisito Autentificación de Usuario.
RF03.- El software deberá de iniciar sesión en la cuenta que se le haya pedido.

Nombre de requisito Consultar Información.
RF04.- El software deberá admitir que los alumnos consulten la información (tareas,
actividades, actividades extra), así mismo deberá permitir que los profesores consulten las
actividades de los alumnos y a su vez permitir que los padres de familia (tutores) consulten lo
que los profesores hayan puesto en clase o de tarea.

Nombre de requisito Modificar información.
RF05.- El software debe ser capaz de darle prioridad a maestro para modificar los trabajos por
si hay algún error al subir (eliminar) al igual que al alumno.

Rev. 1.0
Pág. 16

Nombre de requisito Rapidez.
RF06.- El software debe ser capaz de guardar, subir, registrar, eliminar, ingresar en menos de
15 segundos.
3.1 Requisitos comunes de los interfaces

La comunicación entre el usuario y el sistema será un factor de importancia al tratarse
de un sistema dirigido a alumnos de primaria, se debe tomar en cuenta el diseño y
formas de interactuar para evitar que los alumnos no puedan utilizarlo por ser
complicado.
3.1.1 Interfaces de usuario

La interfaz con el usuario consistirá en un conjunto de ventanas con botones,
listas y campos de textos, varios colores para que sea llamativo a la vista de los
niños junto con imágenes. Ésta deberá ser construida específicamente para el
sistema propuesto y, será ajustada a la vista y resolución de cualquier monitor
haciendo la página web adaptable.
La interface de usuario ayudara al usuario final trabajando en un ambiente
amigable, por lo que se dichas interfaces incluirán:
 Botones
 Menús despegables
 Mensajes informativos
 Mensajes de error
 Cuadros de diálogo
 Formularios para el ingreso, modificación, actualización y eliminación
de datos. Así como para las operaciones y las ayudas que se
mencionó anteriormente.
 Otros
3.1.2 Interfaces de hardware

Tomando en cuenta los requisitos mínimos con los que debe de contar el
hardware del dispositivo con el cual se podrá ingresar al sitio:
 Pantalla. Importante en la comunicación del usuario con la página web.
Es necesario que la pantalla sea nítida y represente claramente las
diversas opciones del sistema.
 Mouse. Va desde los clásicos mouses de las computadoras de escritorio
hasta los trackpad de las laptops, incluso la tecnología de pantalla touch.
 Memoria RAM. La memoria ram debe ser de un tamaño considerable
para la correcta ejecución del navegador web.
3.1.3 Interfaces de software

Al tratarse de una plataforma web es necesario el uso de un navegador para
realizar la interpretación de la página escrita en HTML y que esta sea visualizada
por el usuario.
 Un navegador con soporte a las tecnologías HTML5 para la capa de
vistas de información.

Rev. 1.0
Pág. 17
3.1.4 Interfaces de comunicación

La interfaz de comunicación entre el servidor de la base de datos y nuestra
página web se realizará mediante una petición asíncrona (AJAX), enviando el
valor de la variable consulta hacia un archivo PHP externo que reciba dicho valor,
ejecute la consulta e imprima el resultado, mismo que retornará al archivo inicial
como respuesta a la petición.
3.2 Requisitos funcionales

3.2.1 RF1: Validar usuario.
El sistema, creara un usuario con los datos que se introduzcan y lo
validará dentro del servidor. Dándole los permisos que conlleva el tipo de
usuario (maestro, profesor, tutor, administrador).
3.2.2 RF2: Insertar y actualizar datos de usuario.

Permiso para introducir los datos que se requieran, actualizar los datos.
Nos referimos a la actualización de datos, error al colocar algún dato o no
llenar el campo, tendrá el permiso de insertar los datos del usuario como
es correcto y aparecer en el perfil como el usuario quiere ser visto.
3.2.3 RF3: Cambio de contraseña

Permiso de cambiar la contraseña por seguridad y así mismo una opción
de recuperación de contraseña. Se pretende que el usuario pueda cambiar
sus contraseñas cuando quiera, con un correo electrónico como
seguridad, para verificar que sea el mismo usuario que es el que quiere
hacer el cambio de contraseña. En caso de extravió, se le enviará a su
correo electrónico el permiso, para colocar una nueva contraseña y poder
acceder a su cuenta sin ningún problema.
3.2.4 RF4: Asignar permisos a usuario.

En este apartado, nos referimos a los permisos que deberán tener los
diferentes usurarios (tutor, alumno, docente) dentro de la plataforma,
tomando el objetivo principal de software, los usuarios deberán ver la
plataforma desde una perspectiva diferente. “solo visualización, asignación
de tareas, entrega de trabajos” son algunas de las acciones que los
usuarios pueden realizar dentro de la tarea dependiendo de si es tutor,
alumno o docente. Esto es trabajo del usuario administrador del sistema.
3.2.5 RF6: Realizar operaciones matemáticas para el

desarrollo matemático de los alumnos.
El software tiene como objetivo mejorar el nivel académico de los
estudiantes de primaria. Enfocándonos en matemáticas, dicho programa
tendrá ligas para juegos con un fin educativo para que el usuario alumno
mejore su desarrollo en matemáticas.
3.2.6 RF7: Diferentes tipos de juegos o actividades

didácticas para la compresión de los temas de plan
de estudios.
Como en el requisito 6. Nuestro objetivo es que el alumno encuentre
nuestra plataforma como una forma diferente y divertida de aprender. Se

Rev. 1.0
Pág. 18
usarán diferentes técnicas de aprendizaje, para que los alumnos puedan

aprender de una forma diferente a su salón de clases.
3.2.7 RF9: Animaciones.

Para lograr uno de nuestros objetivos que es el de llamar la atención de
los niños, el software educativo contara con diferentes animaciones para
captar las miradas de los principales usuarios.
3.3 Requisitos no funcionales

3.3.1 Requisitos de rendimiento
El software debe cumplir satisfactoriamente con las acciones que le
indique los diferentes usuarios, cumpliendo con el rango de velocidad de
carga que tiene en promedio las páginas web. Tiempo de espera de
menos de 5 segundo dependiendo de la velocidad de la conexión a
internet.
Se espera que dicha aplicación soporte alrededor de 250 usuarios
conectado simultáneamente a la web.
3.3.2 Seguridad
El código de programación para la creación del software determinara las
pautas de la seguridad que mantendrá nuestro programa que almacenara
los datos de varios usuarios.
 Códigos de seguridad.
 Restricciones.
 Protección de datos.
 Licencias.
 Programación segura. Recomendaciones y revisión de código.
3.3.3 Fiabilidad
El sistema cumplirá con lo siguiente:
Madurez. Satisfacer las necesidades de todos los usuarios en las
actividades que se le indique.
Disponibilidad. Estará disponible en todo momento para que en el
momento en que quiera el usuario quiera hacer uso de su herramienta
pueda hacerlo sin problemas.
Tolerancia a fallos. El sistema tendrá la capacidad para operar según lo
previsto en presencia de fallos hardware o software.
Capacidad de recuperación. El sistema recuperará los datos
directamente afectados y reestablecer el estado deseado del sistema en
caso de interrupción o fallo.
3.3.4 Disponibilidad
Los tiempos de respuesta que se espera tenga el Mathware para posibles
acciones son:
 Carga de la página como máximo 20 segundos.
 Validación de usuario debe durar un máximo de 10 segundos.
 Carga de actividades, el tiempo dependerá del peso de la actividad.
 Consulta de información de alumno 10 segundos.
 Abrir actividad 10 segundos máximos.

Rev. 1.0
Pág. 19
3.3.5 Mantenibilidad
En lo que respecta al mantenimiento de la aplicación web deberá darse
mantenimiento a la base de datos en las tareas de respaldo y
actualización. El mantenimiento y cuidado de la base de datos es
responsabilidad del administrador de la base de datos.
Errores generados en tiempo de ejecución, respuestas erróneas y demás
será responsabilidad del desarrollador quien deberá depurar y documentar
esos errores. De la misma forma el desarrollador tiene la tarea hacer
reportes sobre estadísticas de uso de la plataforma.
3.3.6 Portabilidad
Una de las ventajas de utilizar herramientas y lenguajes basados en sw
libre es que están disponibles para la mayoría de las plataformas y
sistemas operativos.
De tal forma que el uso de tecnologías web como HTML, Javasript y PHP
para el desarrollo es de gran ayuda al ser lenguajes soportados en
cualquier dispositivo con acceso a un navegador web.
La base de datos MySql de la misma forma es un software libre y
disponible para muchos sistemas operativos.
3.4 Otros requisitos

NO APLICA
Todos los requisitos necesarios para el desarrollo y la instalación y uso han sido
definidos.

Rev. 1.0
Pág. 20
4 Apéndices
Menús que integrará el sistema
 Alumno.
 Docente.
 Invitado (padre o tutor).
MENÚ ALUMNO
 Opciones:
 Ver actividades
 Abrir actividad
 Realizar actividad
 Entregar actividad
 Ver evaluación
 Ver puntos acumulados
MAESTRO
Opciones:
 Agregar alumnos.
 Eliminar alumnos.
 Ingresar actividades.
 Calificar.
 Establecer premios.
INVITADO
Opciones:
 Ver actividades
 Visualizar avances
 Visualizar calificación
ADMINISTRADOR
Opciones:
 Agregar tipo de usuario.
 Eliminar tipo de usuario.
 Asignar privilegios.
 Creación de bitácoras.

Diagramas UML
17
DIAGRAMA DE CASOS DE USO
Mathware
Administrador
Crear tipo de
usuario
Eliminar tipo de
usuario
Asignar privilegios
Crear bitácoras
18
Núm. De caso 1
de uso
Nombre del Datos del maestro.
caso de uso
Objetivo en el Asignar actividades, poder agregar, eliminar, calificar y subir los logros a
contexto los alumnos.
El/la maestro(a) podrá asignar a los alumnos de cada grupo tareas
específicas, él es quien autorizara si el alumno entra a dicho grupo ya
Descripción establecido o no, eliminara si es necesario o por equivocación (que haya
metido a un alumno que no es del grupo) y a su vez podrá calificar las
tareas o actividades del alumno y mencionarle sus logros obtenidos.
Pre- Haber sido registrado en la base de datos por el administrador, de lo
condiciones contrario deberá ser registrado.
Post- El/la maestro(a) puede entrar a establecer asignaciones.
condiciones
Actores Administrador, maestro.
primarios
Paso Acciones
1 El administrador da de alta al maestro(a).
2 El/la maestro(a) consulta a los alumnos que se van a
ingresar al grupo.
Flujo principal 3 Los alumnos se registran y profesor lo autoriza.
4 El/la maestro(a) asigna tareas y actividades a los
alumnos.
5 Suben los alumnos lo asignado.
6 El/la maestro(a) califica y sube logros.
Núm. De caso 2
de uso
Nombre del Datos del alumno.
caso de uso
Objetivo en el Consulta las actividades y las entrega, consulta tareas y las entrega,
contexto acumula puntos y gana premios.
El alumno podrá consultar las actividades y tareas dejadas por el profesor
Descripción y deberá entregarlas, también puede acumular puntos y ganar premios.
(Esto depende del profesor).
Pre- Haber sido registrado y autorizado por él/la maestro(a) de lo contrario
condiciones deberá ser registrado y autorizado.
Post- El alumno podrá visualizar las actividades y deberá entregar lo que haya
condiciones dejado él/la maestro(a).
Actores Maestro(a), alumno.
primarios
19
Paso Acciones
1 El alumno es autorizado por él/la maestro(a).
2 El alumno consulta las actividades asignadas.
Flujo principal 3 El alumno sube las actividades asignadas.
4 El alumno consulta su calificación.
5 El alumno consulta sus puntos y logros.
Núm. De caso 3
de uso
Nombre del Datos del tutor.
caso de uso
Objetivo en el Visualizar actividades y calificaciones.
contexto
Descripción El tutor puede ingresar pero solo podrá ver las actividades que se
realizaron y las calificaciones que obtuvo su hijo.
Pre- Haber sido registrado y autorizado por él/la maestro(a) de lo contrario
condiciones deberá ser registrado y autorizado.
Post- El tutor podrá visualizar las actividades que haya dejado él/la maestro(a) y
condiciones su calificación asignada.
Actores Maestro(a), tutor.
primarios
Paso Acciones
1 El maestro(a) autoriza al tutor.
2 El tutor consulta las actividades.
Flujo principal 3 El tutor ve las calificaciones de su hijo.
Núm. De caso 4
de uso
Nombre del Datos del administrador.
caso de uso
Objetivo en el Crear tipo de usuario y bitácoras, eliminar tipo de usuario y asignar
contexto privilegios.
Descripción El administrador puede crear tipos de usuarios y a la vez puede
eliminarlos, podrá asignar privilegios y crear bitácoras para llevar el control
de las actividades de cada usuario.
Pre- Previa solicitud y autorización para dar de alta a cierto tipo de usuario.
condiciones
Post- El administrador tiene la facultad de visualizar, editar y actualizar registros
condiciones de todo tipo de usuario.
Actores Administrador, maestro, alumno, tutor
primarios
Paso Acciones
1 Administrador crea tipos de usuarios.
Flujo principal 2 El administrador da ciertos privilegios a cada usuario.
3 El administrador crea bitácoras para control.
20
DIAGRAMA DE CONTEXTO
Administrador
*Crear tipo de usuario
*Elimina tipo de usuario
*Asigna permisos
*Obtiene reportes
*Crea bitácoras
de bitácoras
Alumno Profesor
*Crear ejercicios
*Se registra *Califica ejercicios
*Realiza ejercicios *Registra alumnos

MathWare
*Elimina alumnos
*Obtiene *Obtiene el registro de alumnos
calificación *Obtiene diversas estadísticas del

*Consultar actividades
avance de los alumnos.
*Reporte de actividades *Registro de usuario
*Consultar tareas * Inicio de sesión
*Reporte de tareas
*Consultar calificaciones
*Reporte de
calificaciones
Tutor
21
DIAGRAMA DE ACTIVIDADES
22
DIAGRAMA DE SECUENCIA
23
DIAGRAMA DE CLASES
24
DIAGRAMA DE OBJETOS
25
DIAGRAMA ARQUITECTÓNICO
26
Estudio de Factibilidad
27
ESTUDIO DE FACTIBILIDAD
Varios puntos importantes que tomar en cuenta para el correcto funcionamiento

y uso de Mathware tocaremos en esta sección. Consideraremos cuatro
aspectos de la factibilidad operativa: complejidad del sistema, interés en el
sistema, adaptación al sistema y obsolescencia del sistema.
Complejidad.
Durante el desarrollo de Mathware debe tomarse siempre en cuenta el usuario

final que son los alumnos que probablemente no estén los suficientemente
preparados para manejar sistemas complejos o muy técnicos es por eso que
esta web debe ser simple y fácil de usar sin dejar a un lado lo llamativo y
funcional. Si llega a ser muy técnico y complejo podría repercutir en la
aceptación del mismo o en un mal uso de este. El uso de una interfaz
interactiva es importante para este punto.
La complejidad no solo podría presentarse en el manejo de la web también

debemos tomar en cuenta la complejidad al momento de desplegar la página
web en los servidores disponibles. La preparación técnica básica en redes es
necesaria en este apartado para lograr una buena y segura conexión con los
protocolos y estándares actuales.
Interés.
Nuevamente destacamos a los usuarios finales. En la etapa en que se

encuentran los alumnos el tomar interés por las matemáticas (que es el
problema que tratar) es algo complicado. Desde no querer adaptarse a una
nueva forma de aprender hasta el ver el sistema con mucha pereza. Otro factor
importante es si estos ya están interactuando con algún otro sistema similar y
por estar muy familiarizado con éste no tomen en cuenta a uno nuevo.
Adaptación.
Habrá que planear con mucho cuidado algunas futuras actualizaciones, que
estas no sean de gran impacto en la forma de manejar el sistema. Para las
actualizaciones debe tomarse en cuenta si son detalles necesarios los que se
resolverán, si son detalles mínimos o si es cuestión de cambios estéticos u
operacionales. Dar prioridades a los que más importan.
Obsolescencia.
Como último punto a considerar y no menos importante, la probabilidad de la

obsolescencia del sistema. Para evitarlo hay que plantear bien las tecnologías
y metodologías de trabajo con las que contará el sistema. Las nuevas
tecnologías de software forman parte importante aquí ya que es preferible
28
utilizar las últimas tecnologías, pero también las más convenientes para su
finalidad.
Mediante la evaluación del estado de los equipos de cómputo con los que
cuenta la institución educativa podemos llegar a la conclusión de que dichos
equipos cumplen con los requisitos mínimos para la implementación del
sistema Mathware.
FACTIBILIDAD TÉCNICA
Hardware
Mediante la evaluación del estado de los equipos de cómputo con los que
cuenta la institución educativa podemos llegar a la conclusión de que dichos
equipos cumplen con los requisitos mínimos para la implementación del
sistema Mathware.
EQUIPO DISPONIBLE EN LA INSTITUCIÓN

EDUCATIVA
CALIDAD EDUCATIVA
Cantidad Descripción
-Computadoras de escritorio
ensambladas.
-Procesador Intel Pentium 4
y
AMD de 64 bits.
15 -Los 15 equipos cuentan
con
2 GB de memoria RAM.
-Todos los equipos tienen
250 GB en disco duro
mínimo.
De estos equipos disponibles al menos dos de ellos funcionará como servidor

web y de base de datos.
En lo que respecta al desarrollo del sistema se usarán tecnologías disponibles

de manera gratuita, desde el entorno de desarrollo hasta el gestor de base de
datos. En este punto no habrá mayores gastos.
29
Hosting y dominio
Para la integración de la plataforma como una página web fuera de las aulas
será necesaria la compra o renta de hosting y un dominio, esto se hará por
proveedoras de este tipo de servicio.
Los paquetes básicos de hosting y dominio tienen un costo promedio de

$100.00 a $200.00 por mes.
Internet
Para el ingreso a la plataforma desde el aula será necesario contar con el

internet de la institución educativa, la cual debe de contar con una velocidad
mínima de 10Mb/s.
Cabe mencionar que fuera de las aulas si se desea conectar a la web, la

disponibilidad del internet será necesaria de igual forma.
¿Qué ocurrirá si aumenta la cantidad usuarios?
Se prevé que el sistema en una primera etapa esté disponible únicamente para
alumnos de 5to y 6to. Si se requiere que el proyecto abarque más grupos será
necesario una mayor infraestructura en lo servidores. Estos son factores que se
deben tener en cuenta para la escalabilidad del sistema.
COSTO BENEFICIO
A continuación haremos un resumen de la información presentada sobre

aquellos materiales, productos o servicios que serán necesarios para la
aplicación del sistema.
 A la web se puede ingresar desde las computadoras disponibles en la

institución.
(No hay gasto).
 La página puede ser accesible desde cualquier otro dispositivo con conexión a
internet y navegador. El acceso de servicios de internet fuera de las aulas es
responsabilidad del usuario.
 Los servicios de hosting que se han de contratar serán los básicos para
sostener la web.
Esos serían posibles gastos en la realización del proyecto. Ahora vamos a listar
aquellos beneficios que tendrá.
 Para la realización de la web no se hará cobros en el desarrollo y

mantenimiento de la misma.
 Desde casa o cualquier lugar con acceso a internet los alumnos pueden
estudiar los temas que se han visto en la clase y seguir practicando.
 El uso de un sistema web refuerza el conocimiento que los alumnos tiene con
las tecnologías de la información y su aplicación en la educación.
 Fomenta el ser autodidacta en los estudiantes.
30
Como hemos visto el desarrollo e implementación del sistema no requiere
inversiones significativas a la escuela al contrario de las ventajas que traen su
implementación. Es por esto que el proyecto en el sentido económico
representa una mínima inversión con beneficios en la mejora académica de los
alumnos.
31
Metodología
32
PROYECTO: MATHWARE
Metodología del sistema Mathware: OOHDM
En el presente documento redactaremos la metodología seleccionada para el

desarrollo de la aplicación web Mathware.
Una aplicación Web (Webbased application) es una aplicación cliente/servidor,

donde tanto el cliente (el navegador, explorador o visualizador) como el
servidor (el servidor Web) y el protocolo mediante el que se comunican
(HTTP) están estandarizados y no han de ser creados por el programador
de aplicaciones”
En una investigación por algunas de las principales metodologías para el

desarrollo de aplicaciones web concluimos que la metodología que se debe
usar para este proyecto es OOHDM (OBJECT ORIENTED HYPERMEDIA
DESIGNMETHODOLOGY) por las razones que se presentan a continuación.
Las metodologías o también llamados métodos, están compuestos por un

número de fases que cambia dependiendo de las metodologías que se
utilice, pero si el método es más complejo en sus pasos mayormente se
tiene un menor número de errores en relación a la calidad y consistencia de
datos.
Gracias al auge del internet en la actualidad la metodología OOHDM se

adaptó para el desarrollo de aplicaciones hipermedias orientadas a la Web,
como por ejemplo bibliotecas virtuales, sitios educativos, motores de
búsqueda, entretenimiento, etc.
OOHDM es una metodología orientada a objetos que propone un proceso de

desarrollo de cinco fases donde se combinan notaciones gráficas UML con
otras propias de la metodología.
A continuación una descripción de las 5 etapas de esta metodología:
Obtención de Diseño Diseño de interfaz

Diseño conceptual Implementación
requerimientos navegacional abstracta
Obtención de requerimientos: se plantea la obtención de requerimientos de

manera cuidadosa, entonces es muy importante conocer los actores y tareas
que se deben modelar en los casos de uso.
33
PROYECTO: MATHWARE
Diseño conceptual: se representa el modelo conceptual a través del
modelamiento de diagramas de clases basados en clases, relaciones y
subsistemas, enfocándose en el dominio semántico dejando de lado a los
actores y tareas.
Diseño navegacional: representa los diferentes caminos que puede

ejecutar la aplicación dependiendo del tipo de usuario. Es decir,
brinda un contexto navegacional capaz de realizar acciones a través de
enlaces, vínculos o índices que están relacionados dentro de la aplicación
Web dependiendo del perfil de usuario para mostrar sus vistas
correspondientes.
Diseño de interfaz abstracta: es ejecutada después del diseño navegacional,

donde es necesario especificar las interfaces de usuario que se visualizaran en
la aplicación Web. Dentro de este modelo se pueden identificar dos sub-
tareas tales como el diseño estructural y el diseño de comportamiento.
Implementación: implementar la aplicación Web independientemente

de la plataforma que será utilizada. Esta fase también es conocida como
puesta en marcha ya que es partir de aquí en donde los usuarios empiezan a
utilizar y sacar provecho al sistema elaborado, a través de un navegador Web y
conexión a internet.
A continuación una tabla comparativa de criterios de calidad basado en la

norma ISO/IEC 9126 con metodologías para aplicaciones web.
Metodologías
Criterios
OOHDM SODHM WSDM WAE UWE IWEB
Funcionalidad Adecuación. Adecuación. Adecuación. Adecuación. Adecuación. Adecuación.
Interoperabilida Interoperabilidad. Interoperabilida Interoperabilida Interoperabilidad. Interoperabilid
d. d. d. Seguridad ad.
Seguridad. Seguridad
Fiabilidad Recuperabilidad Recuperabilidad Baja Baja Recuperabilidad Baja
Usabilidad Aprendizaje. Operatividad. Operatividad Baja Aprendizaje. Baja

Comprensión. Comprensión.
Operatividad. Operatividad.
Eficiencia Media Media Media Baja Baja Baja

Portabilidad Adaptabilidad Adaptabilidad Adaptabilidad Adaptabilidad. Adaptabilidad Adaptabilidad.
Coexistencia. Coexistencia.
Mantenibilidad Facilidad de Media Media Baja Facilidad de Media
análisis, cambio análisis y cambio
y pruebas.
Como se puede observar en la tabla, la mayoría de las características según

los criterios de calidad establecidos por la ISO/IEC 9126 [27] son abarcados
por la metodología OOHDM, ya que presenta una mejor adaptabilidad frente a
cambios, es de fácil aprendizaje, y permite la rápida corrección de errores y
problemas presentados a lo largo del ciclo de vida.
34
PROYECTO: MATHWARE
Conclusión:
A partir del análisis de la información y comparación con otras metodologías se

obtuvo como resultados que la metodología OOHDM es la que cumple
con casi todas las características para el proceso de desarrollo de
aplicaciones Web, contando con 5 etapas y cumpliendo con ciertos criterios de
calidad.
Cronograma
Nombre de Descripción Duración Comienzo Fin

tarea
Obtención de Obtener los requerimientos funcionales y no 23 días mar jue
requerimiento funcionales directamente del cliente. 01/01/19 31/01/19
s
Diseño Creación de diagramas de contexto, clase, dominio 11 días vie vie
conceptual del sistema, etc. 01/02/19 15/02/19
Diseño Plantear las diferentes vistas o formularios a las que 21 días sáb vie
navegacional podrá acceder el usuario al interactuar con el 16/02/19 15/03/19
sistema.
Diseño de Diseño de interfaz de usuario, funcionalidad de lado 27 días sáb sáb
interfaz del servidor, codificación de la aplicación web. 16/03/19 20/04/19
abstracta
Implementació Implementación del sistema al cliente. 11 días lun sáb
n 22/04/19 04/05/19
PROYECTO: MATHWARE
Conclusión
Hay muchas cosas que podríamos mencionar que aprendimos a lo largo de

esta unidad “Modelado de análisis” y de la elaboración de cada una de sus
etapas, como la norma IEEE 830, es muy importante entenderla ya que no se
puede hacer falta de algún punto para la elaboración del proyecto, los
diagramas UML, son de gran beneficio puesto que nos abren un panorama
mejor y grafico hacia lo que queremos dar a conocer. Aprendimos que el
estudio de factibilidad es un gran instrumento que sirve para orientarnos a la
hora de la toma de decisiones en la evaluación de nuestro proyecto.
Sin embargo consideramos que lo más importante de todas las etapas es llevar
a cabo antes que nada una planeación de lo que se quiere realizar y que se
espera obtener cuando se lleva a cabo un proyecto y aquí es donde entra el
cronograma, es muy importante seguirlo al pie dela letra para no atrasarnos, y
la metodología en este caso OOHDM es excelente ya que cumple con casi
todas las características para el proceso de desarrollo de aplicaciones
Web, contando con 5 etapas y cumpliendo con ciertos criterios de calidad.
Así que podemos decir que gracias a esta unidad, a sus etapas y a la ayuda de
nuestra profesora Zofía Benítez Alonzo tenemos un amplio conocimiento de
cómo llevar a cabo una parte importante del proyecto.
PROYECTO: MATHWARE
Referencias
Desconocido, 2017. Metodologías para el desarrollo de aplicaciones Web.
Recuperado: 04/03/19. Instituto Tecnologico de Matehuala.
https://programacionwebisc.wordpress.com/2-5-metodologias-para-el-
desarrollo-de-aplicaciones-web/
Desconocido. ¿Qué significa el estudio de factibilidad de un proyecto?.

Recuperado: 04/03/19. Labor Mexicana. http://www.labormx.com/estudio-
factibilidad.html

Documentación Del Modelado de Análisis PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Documentación Del Modelado de Análisis PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

INSTITUTO TECNOLÓGICO

ING. EN SISTEMAS COMPUTACIONALES

Fundamentos de Ingeniería de Software

Software educativo para el

16080813 CASTILLO VALDIVIESO ROGER

INGENIERÍA DE REQUISITOS (NORMA IEEE 830) ................................................................... 5

HISTORIAL DE REVISIONES ...................................................................................................... 7

1.1 Propósito ....................................................................................................................... 10

1.2 Alcance .......................................................................................................................... 10

1.3 Personal involucrado ................................................................................................... 10

1.4 Definiciones, acrónimos y abreviaturas .................................................................... 11

1.5 Referencias ................................................................................................................... 11

1.6 Resumen ....................................................................................................................... 12

2 DESCRIPCIÓN GENERAL ................................................................................................ 12

2.1 Perspectiva del producto ............................................................................................ 12

2.2 Funcionalidad del producto ........................................................................................ 13

2.3 Características de los usuarios .................................................................................. 14

2.4 Restricciones ................................................................................................................ 14

2.5 Suposiciones y dependencias .................................................................................... 14

2.6 Evolución previsible del sistema ................................................................................ 14

3 REQUISITOS ESPECÍFICOS ............................................................................................ 15

3.1 Requisitos comunes de los interfaces ....................................................................... 16

3.2 Requisitos funcionales ................................................................................................ 17

Descripción de requisitos del software

3.3 Requisitos no funcionales........................................................................................... 18

3.4 Otros requisitos ............................................................................................................ 19

DIAGRAMAS UML ..................................................................................................................... 21

ESTUDIO DE FACTIBILIDAD .................................................................................................... 31

Descripción de requisitos del software

Descripción de requisitos del software

Descripción de requisitos del software

Descripción de requisitos del software

Fecha Revisión Descripción Autor

24/02/2019 1.0 Estructura de la Ilse Aline Morales

Documento validado por las partes en fecha: 07/03/19

Por el cliente Por la empresa suministradora

Escuela primaria « Calidad educativa » Tec4s

1.3 Personal involucrado 10

1.4 Definiciones, acrónimos y abreviaturas 11

2.1 Perspectiva del producto 12

2.2 Funcionalidad del producto 13

2.3 Características de los usuarios 14

2.5 Suposiciones y dependencias 14

2.6 Evolución previsible del sistema 14

3.1 Requisitos comunes de los interfaces 16

3.2 Requisitos funcionales 17

3.3 Requisitos no funcionales 18

Descripción de requisitos del software

3.3.1 Requisitos de rendimiento 18

3.4 Otros requisitos 19

Descripción de requisitos del software

1.3 Personal involucrado

Nombre Jair Ignot Antele.

Descripción de requisitos del software

Nombre Ilse Aline Morales Castillo.

Nombre Castillo Valdivieso Roger

1.4 Definiciones, acrónimos y abreviaturas

IEEE Recommended https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf 22 de Gonzalo

Descripción de requisitos del software

2.1 Perspectiva del producto

Descripción de requisitos del software

2.2 Funcionalidad del producto

Modelado del sistema. Diagrama de casos de uso.

Se registra Califica ejercicios

Realiza ejercicios Registra alumnos

Obtiene Obtiene el registro de alumnos