Está en la página 1de 14

Ingeniería en Desarrollo de Software

Universidad Abierta y a Distancia de México (UNADM)

Ingeniería en Desarrollo de Software

Unidad 2

Daniel Reyes Torres - ES1821000148


Mtra. Ivonne Enríquez Castillo
Materia: Introducción a la Ingeniería de Software
Actividad 3. Casos de uso
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

ÍNDICE
Propósito....................................................................................................................................................3
Módulo elegido..........................................................................................................................................3
Organizador................................................................................................................................................6
Conclusión...............................................................................................................................................14
Referencias...............................................................................................................................................14
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

Propósito
Diagramar casos de uso respecto a la funcionalidad del software a desarrollar, considerando a los
actores involucrados y sus interacciones con el sistema.

Módulo elegido
El módulo elegido es el de FABRICACIÓN.

Fabricación: permitirá seleccionar el diseño, y desglosará los artículos que componen el producto, así
como las cantidades que se requieren de cada uno.

“Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro en algún lugar
de su secuencia. La relación de inclusión sirve para enriquecer un caso de uso con otro y compartir
una funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un
caso de uso describiendo sus subfunciones. El caso de uso incluido existe únicamente con ese
propósito, ya que no responde a un objetivo de un actor. Estas relaciones se representan mediante
una flecha discontinua con el estereotipo <<include>> o <<uses>>” (SEAS, 2013)

“Extensión: Un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en
el lugar especificado indirectamente por este otro caso de uso. En el caso de uso base, la extensión
se hace en una serie de puntos concretos y previstos en el momento del diseño, llamados puntos de
extensión, los cuáles no son parte del flujo principal. La relación de extensión sirve para modelar: la
parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que
se pueden insertar en un punto determinado. Este tipo de relación produce confusión y no debería
utilizarse en exceso. Conviene su uso sólo para insertar un nuevo comportamiento no previsto en un
caso de uso existente. Estas relaciones se representan mediante una flecha discontinua con el
estereotipo <<extend>>.” (SEAS, 2013)

“Herencia: Especialización y generalización de los casos de uso: Un caso de uso (subcaso) hereda el
comportamiento y significado de otro, es decir las relaciones de comunicación, inclusión y extensión
del super-caso de uso. En muchas ocasiones este super-caso de uso es abstracto y corresponde a
un comportamiento parcial completado en el subcaso de uso. O dicho de otra manera, Los casos de
uso “hijo” son una especialización del caso de uso “padre”. En la medida de lo posible debería
evitarse puesto que produce cierta confusión en algunas ocasiones.” (SEAS, 2013)
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

Actores: Supervisor, Jefe producción, Almacenista, Sistema.


Casos de uso: Consulta diseño, Validar usuario, Desglosa requerimientos, Genera orden de surtido,
Baja de insumos, Registro en sistema, Imprime orden, Valida existencia insumos, Autoriza
fabricación, Reporta insuficiencia inventario.

Númro CU Caso de uso Herencia Inclusión Extensión


CU001 Consulta diseño CU006; CU002
CU002 Desglosa requerimientos CU001
CU003 Genera orden surtido CU008; CU005;
CU006
CU004 Baja de insumos CU008; CU005,
CU006
CU005 Registro en sistema
CU006 Validar usuario
CU007 Imprime orden
CU008 Valida existencia insumos
CU009 Autoriza fabricación CU006; CU007; CU003
CU005
CU010 Reporta insuficiencia inventario CU005 CU008
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

Organizador

Nombre del Fabricación


diagrama:

Elementos

Actores: Supervisor, Jefe producción, Almacenista, Sistema

Casos de uso: Consulta diseño, Validar usuario, Desglosa requerimientos, Genera orden de
surtido, Baja de insumos, Registro en sistema, Imprime orden, Valida existencia
insumos, Autoriza fabricación, Reporta insuficiencia inventario

Descripción

Existen 4 actores en el sistema, el supervisor, el jefe de producción, el almacenista y el propio sistema. El


flujo va desde que el supervisor consulta un diseño hasta que almacén da de baja las piezas para iniciar la
manufactura de las piezas.

El supervisor consulta un diseño, y al consultar diseño además de ver los diseños ve también los insumos
que lo componen. Posterior a esto, lo autoriza o no lo autoriza, en caso que lo autorice entonces el sistema
hace una validación de existencias, para ver si se puede cubrir el requerimiento de materiales de acuerdo a la
cantidad de piezas a producir así como a los insumos necesarios por unidad.

Para que el jefe de producción pueda generar una orden de surtido, tiene que estar primero autorizado el
trabajo de fabricación. Una vez autorizado, entonces el jefe de producción puede solicitar o generar una
orden de surtido, la cuál se imprime de forma automática y el almacenista hace el surtido de dicho material,
en las cantidades y especificaciones descritas en la orden de surtido.

Una vez surtido el material, el almacenista ingresa al sistema y da de baja de inventario las cantidades y
modelos de insumos que utilizó.

Todos estos movimientos tienen en común que conllevan varias validaciones; de usuarios cada vez que algún
usuario intenta interactuar con el sistema así como validación de existencia de mercancía previa a la
generación de la orden de surtido.

Si no se tiene suficiente existencia, el sistema reporta esto al supervisor y a otros usuarios definidos por el
administrador del sistema.
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

CU001 Consulta diseño


Descripción El sistema debe permitir al usuario supervisor
desplegar los diferentes modelos de diseño
registrados en la base de datos
Requerimientos asociados CU006 - Validar usuario
CU002 - Desglosa requerimientos
Secuencia normal 1. Supervisor consulta en sistema el diseño
requerido
2. Si existe diseño
1. Sistema muestra en pantalla modelo
3. Si no existe diseño
1. Sistema muestra en pantalla “Diseño
no existe”
Excepciones
Frecuencia Los supervisores consultan diseños todos los
días, en horario completo; es decir, de 9 a 6 lunes
a viernes.
Prioridad Alta
Observaciones Si no existe el diseño buscado, se deberá recurrir
al administrador, para solicitar al departamento
de diseño la carga de dicho modelo en sistema,
ya que el superisor no tiene acceso ni permisos
para cargar diseños.

CU002 Desglosa requerimientos


Descripción El sistema debe permitir al usiario supervisor
mostrar en pantalla los insumos y la cantidad
quese deben utilizar para un diseño específico
Requerimientos asociados CU001 - Consulta diseño
Secuencia normal 1. Sistema muestra diseño en pantalla
2. Al dar clic, sistema muestra el desglose
de insumos de dicho modelo de diseño.
Excepciones
Frecuencia Los supervisores consultan desgloses de diseño
todos los días, en horario completo; es decir, de 9
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

a 6 lunes a viernes.
Prioridad Alta
Observaciones No puede existir un diseño sin su desglose. El
departamento de Diseño debe cargar ambos. El
supervisor no tiene permisos de cargar desgloses
de insumos.

CU003 Genera orden surtido


Descripción El sistema debe permitir usuario Jefe de
producción generar un documento de
requerimiento de materiales de acuerdo al diseño
elegido así como a la cantidad de piezas a
fabricar
Requerimientos asociados CU008 - Valida existencia insumos
CU005 - Registro en sistema
CU006 -Validar usuario
Secuencia normal 1. Usuario Jefe de producción genera orden
surtido a partir de las autorizaciones del
supervisor.
2. Sistema imprime en papel la orden de
surtido.
Excepciones 1. Se podrá imprimir manualmente la orden
también por parte del usuario Jefe de
producción, por ejemplo en caso de que la
impresora se hubiera quedado sin papel o
se requieran imprimir más de 1 juego de
órdenes.
Frecuencia Se generan órdenes de surtido 5 veces al día,
todos los días de lunes a viernes en horario de 9
a 6pm.
Prioridad Alta
Observaciones
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

CU004 Baja de insumos


Descripción Debe permitir al usuario solicitar al sistema la
slaida de inventario del material contenido en una
orden de surtido específica
Requerimientos asociados CU008 - Valida existencia insumos
CU005 - Registro en sistema
CU006 - Validar usuario
Secuencia normal 1. Usuario Almacenista recibe la orden de
surtido en papel.
2. Surte la orden.
3. Almacenista da de baja de sistema la
mercancía descrita en la orden.
Excepciones 1. En caso de no haber algún insumo
físicamente en almacén, deberá poder
hacer una anotación al insumo en el
momento de la baja, así como poner
cantidad 0 de ese insumo.
Frecuencia Se surten órdenes 3 veces al día, todos los días
de lunes a viernes en horario de 9 a 6pm.
Prioridad Media
Observaciones El almacenista surte varias órdenes de surtido al
mismo tiempo. Por ello solo surte 3 veces al día,
mientras que le pasan 5 veces al día órdenes.

CU005 Registro en sistema


Descripción Debe registrar los movimientos solicitados en la
base de datos.
Requerimientos asociados CU004 - Baja de insumos
CU003 - Genera orden surtido
CU009 - Autoriza fabricación
CU010 - Reporta insuficiencia inventario
Secuencia normal 1. Previo a autorizarse la fabricación,
sistema revisa si se tiene existencia
suficiente, en caso negativo registra una
insuficiencia de inventario y lo reporta a
supervisor.
2. Al autorizarse la fabricación, se registra
en sistema esta información.
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

3. Posterior a la autorización, se genera


orden de surtido, la cuál también se debe
registrar en el sistema.
4. Posterior a generar la orden de surtido,
Almacenista surte y da de baja los
insumos del sistema.
Excepciones
Frecuencia Diariamente de acuerdo a las actividades
generales de la empresa; lunes viernes de 9 a
6pm.
Prioridad Alta
Observaciones El sistema debe registrar los movimientos, y debe
ser posible reportearlos posteriormente,
identificando qué usuario hizo qué movimiento en
qué timeStamp.

CU006 Validar usuario


Descripción Debe confirmar que el usuario que solicita acceso
a la información esté registrado y tenga los
permisos necesarios para realizar la acción que
solicita.
Requerimientos asociados CU001 - Consulta diseño
CU009 - Autoriza fabricación
CU003 - Genera orden de surtido
CU005 - Baja de insumos
Secuencia normal 1. Supervisor consulta diseño.
2. Supervisor autoriza fabricación.
3. Jefe de producción genera orden de
surtido
4. Almacenista surte insumos
5. Almacenista da de baja insumos
Excepciones 1. Supervisor no autoriza fabricación. Por lo
que no se sigue adelante.
2. Almacenista no da de baja la mercancía,
entonces sistema no le permite dar de
baja insumos de órdenes posteriores.
Frecuencia Constantemente
Prioridad Alta
Observaciones Administrador deberá poder dar de alta, baja,
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

modificar o editar usuarios.

CU007 Imprime orden


Descripción De acuerdo a la autorización de fabricación, y la
generación de la orden de surtidod el sistema
imprime en papel una orden que será la que se
pase a producción.
Requerimientos asociados CU009 - Autoriza fabricación
Secuencia normal 1. Supervisor autoriza fabricación
2. Jefe de producción genera orden de
surtido
3. Se imprime orden
Excepciones 1. Se termina el papel de la impresora,
sistema deberá permitir a jefe producción
reimprimir la orden de surtido.
Frecuencia 5 veces al día, lunes a viernes de 9 a 6pm.
Prioridad Media
Observaciones

CU008 Valida existencia insumos


Descripción Revisa que la cantidad y modelo de insumos
requeridos para la cantidad de diseños
requeridos para fabricar, estén en existencia en el
inventario.
Requerimientos asociados CU003 - Genera orden surtido
CU004 - Baja de insumos
CU010 - Reporta insuficiencia inventario
Secuencia normal 1. Se valida que la existencia del diseño,
para la cantidad de piezas, esté
disponible en sistema.
1. En caso de NO cubrirse existencia, no
será posible generar una orden de
surtido.
2. En caso de SÍ cubrirse existencia, sí
se podrá generar una orden de
surtido.
Excepciones Si no se tiene exitencia, se quedará autorizada la
fabricación, pero no podrá avanzarse a surtido.
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

Frecuencia Siempre antes de generar una orden de surtido.


Prioridad Alta
Observaciones

CU009 Autoriza fabricación


Descripción Marca la orden de fabricación con un identificador
que significa estar autorizada para seguir
adelante con el proceso de producción.
Requerimientos asociados CU005 - Registro en sistema
CU006 - Validar usuario
CU007 - Imprime orden
CU003 - Genera orden surtido
Secuencia normal 1. Supervisor consulta diseño.
2. Supervisor autoriza fabricación
Excepciones 1. Supervisor NO autoriza fabricación, en
ese caso no pasa nada.
Frecuencia 5 veces al día, todoslos días de la semana de 9 a
6 lunes a viernes.
Prioridad Alta
Observaciones

CU010 Reporta insuficiencia inventario


Descripción En caso de que algún insumo o no se encuentre
en existencia suficiente para poder cumplir con
una orden de fabricación, el sistema envía una
alerta para informar de esta situacón al
supervisor.
Requerimientos asociados CU005 - Registro en sistema
CU008 - Valida existencia insumos
Secuencia normal 1. Supervisor autoriza fabricación
2. Sistema valida existencia vs
requerimiento.
1. Si no hay existencia, reporta
insuficiencia a supervisor por medio
de un reporte.
Excepciones
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

Frecuencia Siempre que se detecte esta situación.


Prioridad Media
Observaciones Deberá enviarse una alerta tanto a supervisor
como a otros usuarios definidos por el
administrador.
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)

Conclusión
Sin duda esta ha sido una de las actividades más enriquecedoras, porque me han permitido viajar
desde un requerimiento platicado (audio de la actividad), hasta aterrizar dichos requerimientos dentro
de una estructura que me ha permitido disectar las distintas partes que componen el requerimiento y
poder pensar así en que tengan sentido, que estén correctamente conectadas y tengan razón de ser.
Muy interesante actividad, y si continuo desarrollando todos los módulos, veo que podría tener una
documentación de más de 200 hojas sin problema, por el grado de detalle que conlleva e implica
cada herramienta.

Referencias
1) UNADM (2019), Desarrollo de Software, Unidad 1 Ingeniería de Software, Universidad Abierta y a
Distancia de México (UNADM), Recuperado de
https://unadmexico.blackboard.com/bbcswebdav/institution/DCEIT/Bloque2/DS/03/DIIS/U1/Unidad_1_
Ingenieria_de_software.pdf
2) UNADM (2019), Desarrollo de Software, Unidad 2 Análisis y modelado de requerimientos,
Universidad Abierta y a Distancia de México (UNADM), Recuperado de
https://unadmexico.blackboard.com/bbcswebdav/institution/DCEIT/Bloque2/DS/03/DIIS/U2/Unidad_2_
Analisis_y_modelado_de_requerimientos.pdf
3) SEAS (2013), Tipos de relaciones en diagramas de casos de uso. UML., BlogSeas, recuperado de
https://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/

También podría gustarte