1.
Introducción
Dar a conocer de qué se trata el sistema y el contexto donde se utilizará.
Objetivo Principal y Objetivos Específicos(Al menos 4)
2. Requerimientos Funcionales (Por ahora, de al menos dos módulos que incluyan
el CRUD)
<Se describen los requerimientos funcionales del sistema utilizando Casos de
Uso o bien Listados de Funcionalidades, Listados de Pantallas, Detalle del Menú
de funcionalidades>.
<Seguir el siguiente formato de ejemplo>
5 requerimientos funcionales que sea al menos 2 principales
Número: RF-# <Ejemplo: RF-1>
Título: Ingreso de cursos
Texto: El sistema(Qué) permitirá el ingreso (permitirá o elaborará qué?) de
DEFINICIÓN los datos requeridos del curso por parte de la secretaria(para qué
usuario) de cada facultad. (LO ENTIENDE EL CLIENTE)
Tipo: Funcional
Detalles de <Observar que son datos necesarios para realizar el proceso> (LO
requisitos y ENTIENDE EL EQUIPO DE DESARROLLO)
restricciones: El sistema debe mantener la siguiente información sobre los cursos:
ESPECIFICACIÓN • Precio: Campo numero real, con 2 decimales. Presentado por el
sistema.
• Título del cu|rso (Ejemplo: SOF-3-IDR): Letras y números hasta
50 caracteres.
• Tipo de Usuario: Seleccionar entre (gerente, bodeguero)
• Cedula o Pasaporte:
• Opcion de busqueda: Al encontrar al Pasajero x cedula o
pasaporte, se presenta los siguientes datos:
Nombres:
Apellidos
• Descripción del curso: Solo letras hasta 100 caracteres
• Programa de estudios. Caracteres alfanuméricos que acepta
tildes, comas y puntos. Hasta 500 caracteres
• Fecha: Selección de dia/mes/año
• Secciones. Letras y números hasta 50 caracteres.
(MATUTINO/VESPERTINO Y NOCTURNO)
• Prerrequisitos.
• Etc ………….
• Edad: Campo numérico desde 16 en adelante. Desde 16 a 22
años en NIVELACION MATUTINO, mayor a 22 años en
NIVELACION NOCTURNA
Validaciones
Fecha de 2/5/2020
revisión y Versión1.0
versión:
Prioridad: <Alta, media o baja>
3. Requerimientos No Funcionales
<La mayoría de los requerimientos no funcionales son registrados comúnmente
en lenguaje natural en esta sección de especificación. Los requerimientos
identificados en esta parte del documento son aplicables al producto en
general. Para el caso de los requerimientos no funcionales aplicables a un caso
de uso en particular se debe aclarar a qué caso de uso se refiere. Redactar
teniendo en cuenta que el RNF pueda ser probado>
<La descripción debe seguir el siguiente formato>
Número: RNF-# <Ejemplo: RN-1>
Título: Interfaz de Usuario
Texto: El sistema deberá contar con una interfaz de usuario intuitiva
y fácil de usar.
Tipo: No Funcional
Detalles de El sistema debe permitir el uso de:
requisitos y • Mensajes de confirmación al registrar, editar, eliminar
restricciones: el producto…
•
Fecha de 2/5/2020
revisión y Versión1.0
versión:
Prioridad: <Alta, media o baja para el negocio>
4. Restricciones
El sistema estará implementado en Java.
La interfaz de usuario se desarrollará utilizando las bibliotecas estándar de Java
Swing.
El programa debe ser elaborado aplicando capa MVC
5. Casos de Uso
5.1. Listado de Casos de Uso
<El listado de Casos de Uso contiene el número y nombre de cada caso de uso,
complejidad, prioridad del cliente, prioridad final.>
Ejemplo:
Id Caso de Uso Complejidad Prioridad Prioridad
del cliente Técnica
CU01 Ingresar al sistema Baja Baja Baja
CU02 Registrar Agentes Baja Alta
CU03 Registrar puntos de medición Baja Alta
CU04 Registrar novedades de Media Baja
mediciones
CU05 Registrar datos de contratos Baja Media
CU06 Registrar días feriados Baja Alta
CU07 Generar meses Baja Alta
5.2. Diagrama General de Casos de Uso
5.3. Detalle de Casos de Uso
<Detallar todos los casos de uso confeccionados a través de la siguiente
plantilla:>
A continuación se muestra un ejemplo:
Caso de Uso Registrar datos de estudiantes CU01
Actores Docente, secretaria
Propósito Registrar datos de los estudiantes a cargo del docente.
Tipo Primario y Esencial
Resumen El docente ingresa datos del estudiante.
Precondiciones El docente debe autenticarse en el sistema.
Postcondiciones Los datos del estudiante quedan registrados.
Referencias ¡Error! No se encuentra el origen de la referencia.
Curso típico de eventos
Acciones de los Actores
Respuesta del Sistema
El docente
1. Selecciona “administrar datos de 2. Presenta un formulario con campos
estudiantes/registrar estudiante”. a ser llenados. (Ver Figura N.37)
3. Ingresa: DNI/Nie o pasaporte, 4. Verifica que se haya ingresado el
nombres, apellidos, correo, número de DNI/Nie o pasaporte, los nombres y
móvil. Selecciona el sexo y elige la apellidos. Genera el usuario,
opción enviar. conformando la primera letra del
nombre y las demás del apellido.
Además, genera la contraseña siendo
la primera vez igual que el usuario.
Registra y guarda los datos.
Curso alterno de eventos
1. Si los datos de nombre, apellidos ingresados están en blanco, el sistema
presenta un mensaje de error “Error: Datos del estudiante en blanco”.
2. Si los nombres y apellidos de un usuario ya existen, el sistema presenta un
mensaje de error “Error: Nombres y apellidos del estudiante ya existen”.
4.
3. Si existe un usuario similar, se añade al usuario las dos primeras letras del
nombre seguidas por el apellido del estudiante. Si existen coincidencias
similares sigue añadiendo las siguientes letras del nombre, hasta generar
un nombre de usuario distinto y único de los demás.
6. Modelo del dominio
<Esta sección se detalla el modelo conceptual (Diagrama de clases) de todos los
temas relacionados con un problema específico. En él se describen las distintas
entidades, sus atributos, papeles y relaciones, además de las restricciones que
rigen el dominio del problema. Recuerde que no son objetos software, sino un
“diccionario visual” de conceptos del dominio>.
<Las imágenes deben tener un tamaño que permitan al menos ser entendibles a
la vista del lector, sin mayor esfuerzo (zoom).>
Ejemplo:
7. Análisis Estático y Dinámico
7.1. Análisis Estático (Usando CheckStyle, PMD y Complejidad Ciclomática)
Presentar el informe que da a conocer cada uno de los programas. Esto
debe hacerlo el integrante 1 analizando el módulo del integrante 2.
Crear una tabla mostrando el código original y el código corregido.
Además, indicar por cada línea qué se corrigió. Esto lo hace el integrante
2(Autor del código analizado por el integrante 1)
Elaborar el grafo y calcular la complejidad Ciclomática de los métodos
de las clases de la Capa Controlador. De acuerdo con la complejidad
ciclomática indicar el tipo de riesgo del código analizado, poco riesgo,
alto riesgo, riesgo moderado. (Esto debe hacerlo el integrante 2)
7.2. Análisis Dinámico (Usando Clases de Equivalencia)
De cada módulo (Son 2 integrantes, debe haber 2 módulos.)
Tabla 1.
Entrada Regla Clases válidas Clases no válidas
Tabla 2
Clases Válidas Resultado Dato de Resultado Estado
y no Válidas esperado prueba obtenido (Correcto/Incorrecto)
Nota: En caso de que sea incorrecto, se debe dar un pequeño informe de sugerencias
para que el programador corrija el código.
7.3. Conclusiones
