SERVICIO NACIONAL DE APRENDIZAJE

Tecnólogo Análisis y desarrollo de software

Actividad:
Evidencia GA2-220501093-AA1-EV02: elaboración de diagramas y plantillas para
casos de uso del proyecto

Autor:
Johnattan Elías Cabeza Osorio
C.C 1.143.436.302

Barranquilla – Atlántico

8 de enero de 2024

Versión 1.0
 Introducción

En esta evidencia nos centraremos en la aplicación de enfoques ágiles y metodologías

de desarrollo de software para la identificación y comprensión de los requisitos del
proyecto del software a construir. Se abordarán dos técnicas fundamentales: Casos de
usos e historias de usuario. Ambas metodologías permiten capturar de manera clara y
entendible las necesidades (requerimientos) del usuario, garantizando que el software se
ajuste a las expectativas y cumpla con los objetivos planteados.

A lo largo de esta evidencia se explorarán diversos casos de uso, estos casos se

convertirán en una guía fundamental para el equipo de desarrollo, proporcionando una
visión clara de cómo se debe comportar el programa. También se detallarán historias de
usuario que expresen los diferentes requerimientos desde el punto de vista del usuario o
cliente. Estas historias permiten priorizar las funcionalidades y mantienen la atención con
la experiencia del cliente durante todo el proceso de desarrollo.
 Desarrollo
Casos de uso
1. Capturar los requisitos funcionales. Los casos de uso identifican y describen
las interacciones entre el sistema y los usuarios (actores) para cumplir con un
objetivo específico. Permiten capturar de manera detallada los requisitos
funcionales del sistema y su comportamiento en diferentes escenarios.

2. Visualizar la funcionalidad del sistema. Los casos de uso proporcionan una

representación gráfica o textual de como el sistema se comportará en situaciones
reales. Esto ayuda a los analistas y desarrolladores a comprender mejor las
expectativas del cliente y a validad si el software cumplirá con las necesidades
existentes.

3. Identificar actores y sus roles: Los casos de uso ayudan a identificar los
diferentes actores que interactúan con el sistema y los roles que desempeñan.
Esto es crucial para comprender quienes utilizarán el software y como se
relacionan con este.

4. Establecer relaciones de dependencia: Los casos de uso permiten identificar

las dependencias entre distintos flujos de trabajo y funcionalidades del sistema.
Esto ayuda a garantizar la coherencia y la integridad del software.

5. Priorizar funcionalidades: Al tener una descripción detallada de las

funcionalidades del sistema en los casos de uso, se puede priorizar su
implementación en función de la importancia y el valor que aportan al negocio y a
los usuarios.
Historias de usuario:
1. Centrarse en las necesidades del usuario: Las historias de usuario se expresan
desde la perspectiva del cliente o usuario final, lo que permite comprender sus
necesidades y expectativas. Ayudan a mantener el enfoque en satisfacer a los
usuarios durante todo el proceso de desarrollo.

2. Simplificar la comunicación: Las historias de usuario son descripciones

concisas y comprensibles de funcionalidades desde el punto de vista del usuario.
Esto facilita la comunicación entre los miembros del equipo de desarrollo, los
stakeholders y los usuarios, evitando tecnicismos innecesarios.

3. Priorizar tareas y funcionalidades: Cada historia de usuario tiene una

estimación de esfuerzo y valor, lo que permite al equipo priorizar las tareas en
función de su importancia y el impacto que tienen en la experiencia del usuario y
en los objetivos del negocio.

4. Evaluar la completitud del producto: Al contar con un conjunto de historias de

usuario que representa las expectativas del cliente, el equipo de desarrollo puede
evaluar cuando del producto o sistema se ha completado y cuanto queda por
implementar.

5. Facilitar las pruebas y validación: Las historias de usuario son la base para
diseñar casos de prueba que aseguren la calidad y la funcionalidad esperada del
software. Facilitan la validación de que el sistema cumple con los criterios de
aceptación definidos por los usuarios.
Diagrama de caso de uso general

Casos de uso

CASO DE USOS RF 01 LLENAR FORMULARIO DE SOLICITUD

DESCRIPCIÓN Este caso de uso describe la forma en la

que cada postulante llena un formulario de
solicitud para realizar el examen de
admisión a la institución educativa o
universidad
PRECONDICIÓN Cada postulante debe tener a la mano toda
la documentación requerida
 Pasos
1 El postulante debe ingresar al
link dispuesto en el software
SECUENCIA NORMAL para iniciar el llenado de
formulario
2 Se debe llenar el formulario
según cada campo requerido
de manera lógica.
3 Si el sistema pide algunos
documentos se debe agregar
según se requiera
4 Cuando ya se halla llenado todo
de manera correcta hacer clic
en enviar
El o la postulante se encuentra registrado
en sistema y a la espera de que la
POST CONDICIÓN institución defina si puede o no realizar la
prueba
Pasos Acción
1 Si él o la postulante no ingresa
EXCEPCIONES
toda la documentación o
ingresa información errónea no
se podrá enviar el formulario al
servidor. Se mostrará un
mensaje de error.

CASO DE USOS RF 02 REALIZACIÓN DE PRUEBA ESCRITA

DESCRIPCIÓN Este caso de uso plantea la forma de cómo

cada postulante puede realizar la prueba
para ingreso a la institución educativa o
universidad mediante e software a construir
PRECONDICIÓN Cada postulante de estar registrado en
sistema

Pasos
 1 El postulante debe ingresar al
software con su usuario
(identificación) y contraseña
2 Aparecerá una pestaña que
SECUENCIA NORMAL
indique el inicio de la prueba
3 El postulante inicia la prueba
según la carrera escogida y
tendrá en cuenta el tiempo para
realizarla
4 Una vez terminada la prueba el
postulante debe dar clic en el
botón “enviar prueba”.
El postulante debe esperar el resultado de
la prueba, si gana pasa a matricularse, sino
POST CONDICIÓN debe volver a postular en un tiempo
requerido por la institución
Pasos Acción
1 Si el postulante ingresa un
EXCEPCIONES
usuario y contraseña errónea
saldrá un mensaje que diga
“usuario incorrecto”. Si intenta
más de tres veces debe pedir
que se le desbloquee el usuario
y pedir cambio de contraseña

CASO DE USOS RF 03 RECEPCIÓN DE DOCUMENTOS

DESCRIPCIÓN El personal secretariado administrativo se

encargará de gestionar y administrar toda la
documentación de cada postulante, tanto
para los que van a iniciar la prueba, como
aquellos que van a matricularse
PRECONDICIÓN El personal secretariado toma los datos de
cada postulante para mirar si cumple las
condiciones de ingreso
Pasos
1 El personal secretariado
ingresa al sistema para registrar
 al nuevo postulante, este le
genera un usuario y contraseña
SECUENCIA NORMAL 2 El sistema carga los datos del
postulante y la fecha para la
realización de la prueba
3 El día de la prueba el postulante
ingresa al sistema según
usuario y contraseña y realiza la
prueba
4 El sistema arroja el puntaje
indicado y un mensaje diciendo
si “aprobó” o no “aprobó”
5 El personal secretariado
obtiene el listado de los
postulantes que pasan a
matricula
El personal administrativo tiene la lista de
los postulantes que pasan a matricula
POST CONDICIÓN

Pasos Acción
1 Se debe detectar la duplicación
EXCEPCIONES
de postulantes, cuando esto
ocurra enviar un mensaje de
que ya existe el usuario
2 En cierto tiempo y dependiendo
ciertas circunstancias permitir la
eliminación de ciertos
postulantes que no logren
acceder a la matricula

CASO DE USOS RF 04 REGISTRO DE MATRICULA

DESCRIPCIÓN El personal secretariado administrativo se

encargará de verificar y adelantar todo el
proceso de matrícula para aquellos que
superaron la prueba o examen de inducción
 PRECONDICIÓN Se debe tener lista y clara los postulantes
que pasaron la prueba y las respectivas
carreras a cursar
Pasos
1 El personal secretariado
ingresa al sistema para verificar
SECUENCIA NORMAL quienes pasaron a matricula
2 El personal secretariado debe
generar la orden de matrícula
para cada postulado
3 Se le debe informar por correo
o teléfono al postulante que
revise o verifique la información
de matricula
El personal administrativo tiene la lista de
los postulantes que pasan a pagar la
POST CONDICIÓN matricula

Pasos Acción
1 Se debe detectar la duplicación
EXCEPCIONES
de matrícula, cuando esto
ocurra enviar un mensaje de
que ya existe el usuario
matriculado
2 En cierto tiempo y dependiendo
ciertas circunstancias permitir la
eliminación de ciertos
postulantes que no logren
pagar la matricula

CASO DE USOS RF 05 REVISION DEL SISTEMA

DESCRIPCIÓN El personal de sistema deberá revisar y

realizar mantenimiento al software según
requerimiento y según norma.
PRECONDICIÓN Se debe tener claro que tipo de
mantenimiento o actualización requiere el
sistema
 Pasos
1 El personal de sistema tiene las
disposiciones definidas a
SECUENCIA NORMAL realizar en el sistema
2 Se procede a realizar los
manteamientos y las
actualizaciones requeridas
3 Se debe pasar un informe de las
mejoras y las actualizaciones
efectuadas
El personal de sistema tienen ya definido
los próximos mantenimientos o
POST CONDICIÓN actualizaciones

Pasos Acción
1 Solamente el personal de
EXCEPCIONES
sistema debe y tienen la opción
de realizar los mantenimientos
2 Se les pedirá usuario y
contraseña para ingresar a
realizar las actualizaciones o
mantenimientos. Debe
aparecer “usuario de personal
de sistema incorrecto” cuando
se digite mal algún usuario

CASO DE USOS RF 06 ELABORACIÓN DE EXÁMENES

DESCRIPCIÓN El personal docente o directivo presentará o

actualizará las preguntas de los exámenes
para el ingreso a la institución o universidad
según la carrera o grado a cursar.
PRECONDICIÓN Se debe tener claridad el tipo de examen
que se va a montar en el software, a qué
carrera o curso va dirigida.
Pasos
 1 El personal docente o directivo
entrará al sistema con usuario
(identificación y contraseña)
2 Para ingresar algún examen el
SECUENCIA NORMAL
sistema le pedirá un código
(permiso) para realizar ese
evento
3 Se procede a realizar y ya
finalizado se presionará un
botón que diga “Añadir
evaluación”.
El personal docente o directiva tendrá que
añadir diferentes otro grupo de preguntas
POST CONDICIÓN para que haya diversidad en las
evaluaciones
Pasos Acción
1 Solamente el personal docente
EXCEPCIONES
o directiva debe y tienen la
opción de realizar los
exámenes
2 Se les pedirá usuario y
contraseña para ingresar a
realizar las evaluaciones. Debe
aparecer “usuario docente o
directivo incorrecto” cuando se
digite mal algún usuario
Historias de usuario

Identificación de la historia RF01: Llenar formulario de solicitud

Rol Postulantes
Funcionalidad Poder registrarse al sistema para aplicar
y acceder a la prueba o examen de
admisión de la institución educativa o
universidad
Razón/Resultado Tener la posibilidad de realizar la prueba
o examen de admisión teniendo en
cuenta las exigencias de la institución
educativa o universidad
Criterio de aceptación 1. El o la postulante debe ingresar a
la aplicación del software a
construir y acceder al link donde
aparecerá el formulario a llenar y
posteriormente para enviar.
2. El o la postulante deberá llenar
todos los campos requeridos de
forma lógica y correcta anexando
las documentaciones pertinentes
3. Cuando él o la postulante llene
todos los campos deberá darle clic
al botón de enviar formulario.
Identificación de la historia RF02: Realización de prueba escrita

Rol Postulantes
Funcionalidad Cuando la universidad acepte al
postulante este deberá presentarse a la
institución educativa o universidad para
realizar la prueba de admisión.
Razón/Resultado Realizar la prueba de admisión según la
carrera o el curso escogido con el fin de
lograr adquirir la matrícula.
Criterio de aceptación 1. El o la postulante abrirá el software
para la realización de la prueba
2. Deberá escoger el rol de
postulante y colocar su usuario y
contraseña.
3. Escogerá la pestaña “Iniciar
prueba” y leerá los criterios para la
misma.
4. Cuando termine de realizar la
prueba deberá dar clic en el botón
“Finalizar prueba”
Identificación de la historia RF03: Recepción de documentos

Rol Secretariado
Funcionalidad Recepcionar toda la documentación
requerida tanto en la etapa de solicitud
para la realización de la prueba como en
la etapa de matrícula.
Razón/Resultado Organizar la documentación de cada
postulante dependiendo la etapa de la
prueba
Criterio de aceptación 1. Cuando se esté en la etapa de
“solicitud para realizar la prueba” el
personal de secretariado deberá
descargar la documentación de
cada postulante y verificar que sea
lo requerido por la institución.
2. Cuando el sistema arroje quieren
cumplen con lo solicitado organizar
y gestionar el usuario y contraseña
para cada postulante
3. Cuando se esté en la etapa de
“matricula” verificar la
documentación requerida y
descargarlo.
Identificación de la historia RF04: Registro de matricula

Rol Secretariado
Funcionalidad Cuando ya se tenga la lista de los que
pasaron la prueba generar el registro de
matricula
Razón/Resultado Generar el registro de matrícula para
cada postulante que logró ganar el
examen de admisión.
Criterio de aceptación 1. Verificar la lista de los postulantes
que lograron pasar la prueba
2. Verificar la lista de documentación
relacionada con cada postulante
3. Generar y posteriormente enviar la
matricula a cada postulante

Identificación de la historia RF05: Revisión del sistema

Rol Equipo técnico

Funcionalidad Cada cierto tiempo el equipo técnico de la
institución educativa deberá realizar
mantenimiento al software
Razón/Resultado Lograr realizar mejorar o actualizaciones
al software.
Criterio de aceptación 1. Para ingresar sistema se deberá
hacer con usuario y contraseña
con el rol de “técnico de sistema”
2. Se deberá realizar las mejoras o
actualizaciones requeridas por la
institución y según normas.
Identificación de la historia RF06: Elaboración de examenes

Rol Docente / directivo

Funcionalidad Realizar los exámenes de admisión

Razón/Resultado Lograr Realizar los exámenes de

admisión y montarlos en el software
teniendo en cuenta el curso o carrera.
Criterio de aceptación 1. Se debe ingresar al sistema con
usuario y contraseña
2. Dar clic en la pestaña “creación de
pruebas”
3. Cuando finalice la creación de
todas las preguntas dar clic en
“anexar prueba”
 Conclusión

Mediante los casos de uso y las historias de usuario damos claridad de que será el
software a construir, estos casos nos permiten relacionar cada caso de uso con los
actores en mención. En esta evidencia explicamos cada caso de uso y lo pudimos
convertir también en historias de usuario.
 Bibliografía

SENA (s.f) Diagramas para la especificación y análisis de requisitos.

https://sena.territorio.la/content/index.php/institucion/Titulada/institution/SENA/Tecnologi
a/228118/Contenido/OVA/CF7/index.html#/

Canal Carlos A. Fuel (9 de septiembre de 2023) Elaboración de diagramas y plantillas

para casos de uso del proyecto:GA2-220501093-AA1-EV02 [Archivo de video].
https://www.youtube.com/watch?v=bu9EoVZfaNI