RESUMEN

Vista previa del material en texto

DOCUMENTO VISION
PROPOSITO DEL DOCUMENTO
 El documento Visión tiene como propósitos comunicar el objetivo del proyecto, los problemas a resolver, quiénes son las personas involucradas, qué necesitan, y cuáles podrían las soluciones propuestas.
DESCRIPCION DEL PROBLEMA / OPORTUNIDAD
	El Problema de
	Disminuir el error de recibir productos que no se compraron 
Información incompleta para lograr tomar las decisiones
	Afecta
	Empleados de cada área de servicio
Departamento de Compras
Proveedores
	Una adecuada solución sería
	Automatizar la recepción de los productos 
Actualizar el inventario de los productos recibidos 
Controlar y verificar que los productos recibidos coincidan con el tipo y cantidad pedida 
	El impacto sería
	Conocer en tiempo real si la solicitud de compra fue aprobada
Disminuir el error de recibir productos que no se compraron 
Control de productos más efectivo 
DESCRIPCIÓN DEL PERSONAL
 
Resumen de Usuarios
· El Jefe del Hospital o Gerente general que es el responsable de las 5 áreas de servicio, es la persona que se encarga de aprobar los presupuestos sobre la compra de los recursos materiales y la contratación de los recursos humanos del centro.
· La Gerencia de Administración que se encarga de dirigir los procesos de adquisición y suministro de elementos para las áreas de servicios.
Resumen del personal involucrado (No usuarios)
· El Jefe del Proyecto planifica, coordina y controla todas las acciones implicadas en el proyecto. Además, es el encargado del contacto directo con el Jefe del Área de Administración.
· El Analista de Sistemas que es el responsable de realizar las entrevistas, cuestionarios y observaciones para descubrir los requerimientos del sistema. Además, realiza la documentación y de los requisitos.
VISION GENERAL DEL PRODUCTO
DOCUMENTO DE ESPECIFICACION COMPLEMENTARIA
PROPOSITO DEL DOCUMENTO
 El propósito del documento de Especificación Complementaria es describir información adicional de las reglas del dominio del problema. Esa información adicional es considerada como restricciones impuestas al sistema de información. También describe la información de dominio de interés, la cual se basa en descripciones o diagramas de cómo se realizan los procesos.
REGLAS DEL DOMINIO
	ID
	REGLA
	GRADO DE VARIACION
	ORIGEN
	01
	Los días jueves se aplica un descuento del 10% a todos los artículos
	Alta
	Reglas del Proceso de ventas
	02
	Entrega anualmente de premios a los mejores proveedores
	Media
	Política de Hospital
	03
	Los productos defectuosos no se reciben.
	Baja
	Política de Hospital
	04
	Proveedores autorizados
	Baja
	Política de Hospital
INFORMACION DE DOMINIO DE INTERES
CASO DE USO
Caso de Uso: <<Logueo>>
Actor principal: Usuario.
Precondiciones: * El Actor debe estar registrado previamente y poner un ID y contraseña.
		 * El Actor debe estar activo.
Poscondiciones: * El usuario podrá realizar operaciones.
Escenario de Éxito:
	1. El usuario ingresa su nombre de usuario o ID.
	2. El usuario ingresa su contraseña.
	3. El usuario confirma sus datos haciendo clic en el botón ingresar.
	4. El sistema captura y valida los datos.
	5. El sistema abre la interfaz principal para operar.
Extensiones:
	*a: El sistema falla.
		1. El usuario reinicia el sistema.......................................................
	4a. Usuario o contraseña incorrecta.
		1. El sistema muestra el mensaje de error y solicita reingresar los datos de logueo.
	4b. Campos vacíos.
		1. El sistema muestra un mensaje de campos vacíos y solicita ingresar los datos de logueo.
	4c. Uso de mayúsculas
1. Al ingresar la contraseña, el sistema notificara al usuario si las mayúsculas están activas.
	
Caso de Uso: <<Procesar Operación>>
Actor principal: Usuario
Precondiciones: El usuario se identifica y autentica.
Poscondiciones: Se registra una nueva operación.
Escenario de Éxito:
	1. El usuario selecciona la operación.
	2. El sistema captura y valida la operación.
	3. El usuario ingresa un operando.
	4. El sistema captura y valida.
	Repite 3 y 4 para el otro operando.
	5. El sistema realiza y registra la operación.
	6. El sistema muestra el resultado.
	7. El usuario finaliza el proceso.
Extensiones:
	*a: El sistema falla.
		1. El usuario reinicia el sistema.......................................................
	2a. Operación elegida no sea válida.
		1. El sistema muestra el mensaje de error y solicita reingresar la operación.
 3.a. El segundo operando es 0, el sistema muestra el mensaje de error, solicita el reingreso del 	segundo operando.
DIAGRAMA DE SECUENCIA
CONTRATOS
	Contrato CO1: CrearNuevaDenuncia
	Operación: CrearNuevaDenuncia()
	Referencias cruzadas: Caso de Uso: Tomar Denuncia
	Precondiciones: Ninguna
Postcondiciones: * Se creó una instancia de Denuncia d (creación de instancias)
	 	 * d se asoció con el registro (formación de asociaciones)
	 	 * Se iniciaron los atributos de d.
	Contrato CO2: IngresarDenunciante
	Operación: IngresarDenunciante (apeYnom, DNI, Tel)
	Referencias cruzadas: Caso de Uso: Tomar Denuncia
	Precondiciones: Hay una denuncia en curso
Postcondiciones: * Se crea un Nuevo Denunciante (Se crea una nueva instancia).		 
		 * Se asocio denunciante con la denuncia actual d (formación de asociación).
		 	 * Se almaceno apellido y nombre en d.nombre (modificación de atributos).
			 * Se almacenó DNI en d.Dni (modificación de atributos).
		 	 * Se almacenó Teléfono en d.Teléfono (modificación de atributos).
	
	Contrato CO3: IngresarBeneficiario
	Operación: IngresarBeneficiario (apeYnom, DNI, Local)
	Referencias cruzadas: Caso de Uso: Tomar Denuncia
	Precondiciones: Hay una denuncia en curso
Postcondiciones: * Se crea un Nuevo Beneficiario (Se crea una nueva instancia).		 
		 * Se asocio Beneficiario con la denuncia actual d (formación de asociación).
		 	 * Se almaceno Legajo en d.Legajo (modificación de atributos).
	
	Contrato CO4: FinalizarDenuncia
	Operación: FinalizarDenuncia()
	Referencias cruzadas: Caso de Uso: Tomar Denuncia
	Precondiciones: Hay una denuncia en curso
Postcondiciones: * Denuncia d pasa a ser aprobada (modificación de atributos).
MODELO DE DOMINIO
LISTA DE CATEGORÍAS
	Categoría de clase conceptual
	Ejemplos
	Objetos tangibles o físicos
	Articulo 
	Descripciones o especificaciones
	Detalle de Producto
	Lugares
	Supermercado
	Transacciones
	Venta, Pago
	Línea de Transacción
	Línea de Venta
	Rol de la gente
	Cajero, Cliente
	Reglas y políticas 
	Política de reintegro
	Registro de finanzas, trabajo, contratos
	Recibo, Libro mayor
	Instrumento y servicios financieros
	Línea de Venta, Stock
FRASES NOMINALES
Escenario principal de éxito
1. El cliente llega a la caja con los artículos para la compra.
2. El cajero inicia una nueva venta.
3. El cajero escanea el código del artículo.
4. El cajero ingresa la cantidad y el sistema muestra la suma parcial y detalles de cada línea de venta.
5. El cajero introduce los datos del pago.
6. El Sistema actualiza el inventario y registra la venta en el libro mayor de ventas.
7. El Cliente recibe un recibo del Sistema y luego se va con los artículos. 
CONSERVACIÓN DE ASOCIACIONES
	Asociación
	Supermercado posee Caja
	Cajero encargado de Caja
	Venta iniciada por cliente
	Línea de Venta contenida en Venta
	Línea de Venta descripta por Detalle de Producto
	Línea de Venta registra venta de Artículo
	Detalle de Producto describen Artículo
	Venta pagada por Pago
	Venta registra en Libro Mayor
	Supermercado abastece Artículo
	Supermercado alberga Libro Mayor
	Supermercado captura Venta
MODELO DE ANALISIS
REQUERIMIENTOS FUNCIONALES
	Numero de Requerimiento
	RF 01
	Requerimiento
	El sistema permitirá registrar titular y adherentes
	Prioridad
	Alta
	
Entradas
	Datos del titular [DNI, apeYnom, Domicilio, Tel]
Datos de adherentes [DNI, apeYnom, edad, filiacion]
Datos del plan [Nombre, Descripcion]Acción / Proceso
	El empleado ingresa datos del titular [DNI, apeYnom, Domicilio, Tel]
El sistema captura y valida los datos
Si los datos no son válidos, el sistema muestra el mensaje “Datos no válidos, reingresar datos”
Sino el sistema registra titular
El empleado ingresa datos de adherentes [DNI, apeYnom, edad, filiación]
El sistema captura y valida datos
Si los datos no son válidos, el sistema muestra el mensaje “Datos no válidos, reingresar datos”
Sino el sistema registra adherentes
El empleado ingresa datos del plan
El sistema captura y valida los datos
El sistema registra los datos del plan
	Salidas
	Titular, adherentes y plan registrados
Mensaje “Datos no válidos, reingresar datos”
REQUERIMIENTOS NO FUNCIONALES
RUsab01: El sistema debería ser aprendido a utilizar en 3 horas. 
REstandar01: El sistema debería funcionar bajo Linux. 
RTRes01: El sistema podría mostrar los datos del producto en 5 seg.
AMBIGUEDADES, OMISIONES O INFORMACION INCOMPLETA
· Información incompleta para afiliación de socios nuevos o renovar membresía
· Método ambiguo para presentar denuncia de extravío del carnet.
5 PREGUNTAS PARA COMPLETAR LA INFORMACIÓN DE LOS REQUERIMIENTOS
1. ¿Qué datos son necesarios para registrar un nuevo socio?
2. ¿Cómo controlan las renovaciones de membresía?
3. ¿Piensan mejorar el método de extravío del carnet?
4. ¿Cuántos socios posee el club actualmente?
5. ¿Posee un límite máximo de socios?
PROTOTIPOS
PRIMERA INTERFAZ CON SUS DOS ALTERNATIVAS POSIBLES
SEGUNDA INTERFAZ CON SUS DOS ALTERNATIVAS POSIBLES