Capítulo 5 especificacion de requerimientos
En este nivel veremos ampliamente como se ejecuta el análisis de la metodología de cascada iterativo incremental. Todo comienza un levantamiento de requerimientos que se detalla a continuación:
Capítulo 5.1 Requerimientos funcionales.
RF1.-El sistema deberá permitir autenticar las credenciales de usuario
RF2.- El sistema deberá permitir ingresar Pedidos.
RF3.- El sistema deberá modificar Pedidos.
RF4.- El sistema deberá permitir eliminar el Pedido.
RF5.-El sistema deberá permitir consultar Pedido.
RF6.-El sistema deberá Permitir adjuntar documento.
RF7.-El sistema deberá permitir buscar Pedido.
Una vez hecho esto se le abrirá una página solicitando usuario y contraseña
después se le desplegara un formulario que tendrá que llenarlo y adjuntar documentos adicionales, si es que el pedido lo amerita.
Una vez ingresados los datos, el usuario apretara un botón “siguiente” el cual le dará un numero de memo y enviara los datos a administración y personal. Este memo digital o recibirá el Gerente de Administración y personal, avisándole a este por intermedio de un mail
Capítulo 5.2 Requerimientos no funcionales.
RNF1.-Por otra parte los requerimientos no funcionales serian el respaldo. Este sistema de base de datos haría una vez al día, a las 11:00 de la noche, una copia que se enviaría a un servidor externo como respaldo.
ENF.2-El control de acceso al administrador se realizara asignando una página web la cual ingresara su nombre de usuario y contraseña. Una vez validado el administrador, el sistema le abrirá un grupo de herramientas, como modificación de usuarios y permisos, sacar carpetas hechas por error.
Capítulo 6 analisis y diseño de la aplicación
En este nivel veremos ampliamente como se ejecuta el análisis y el diseño de la metodología de cascada iterativo incremental.
Capítulo 6.1
Diseño Lógico
El diseño pertenece a a la metodología representada con los requerimientos funcionales.
Capítulo 6.1.1
Casos de uso y casos de uso extendido
El caso de uso es como se muestra en la figura 6.1.1
Figura 6.1.1
Caso de uso Extendido
A continuación se mostrara el sistema de caso de uso extendido
-
Caso de Uso:
Autentificar Usuario.
Actores:
Usuario, Operario de Administración y Administrador
Propósito:
Validarse en el sistema
Resumen:
El sistema validara si el usuario esta correcto.
Sección
Principal
Acción de los Actores
Respuesta del Sistema
Flujo normal de los eventos
1. El usuario invoca el sitio web de intranet
2. El sistema solicita las credenciales (Usuario y contraseñas)
3. El usuario ingresa nombre de usuario y contraseña.
4. el sistema ingresa a página de pedidos.
Flujos Alternativos
Línea 4. Los datos ingresados para el sistema de pedidos no son válidos. El sistema muestra mensaje y el usuario puede intentarlo de nuevo o salir.
-
Caso de Uso:
Modificar Pedidos.
Actores:
Administrador
Precondiciones
El Usuario debe estar logeado en el sistema.
Propósito:
Modificar datos en el sistema.
Resumen:
El administrador es el encargado de modificar datos que estén el sistema.
Sección
Principal
Acción de los Actores
Respuesta del Sistema
Flujo normal de los eventos
1. El administrador entra en la página donde modifica el pedido.
2. El sistema advierte que va a modificar datos.
3. El administrador ingresa los datos a modificar y guarda.
4. El sistema entrega el mensaje que “Los datos han sido guardados exitosamente”
Flujos Alternativos
Línea 4. Los datos ingresados no son válidos, intente nuevamente o salga del editor.
-
Caso de Uso:
Ingresar Pedidos.
Actores:
Usuario y Operario Administrador
Precondiciones
El Usuario debe estar logeado en el sistema.
Propósito:
Introducir los datos requeridos en el sistema.
Resumen:
Son los datos que el sistema requiere para poder iniciar el proceso de compras de bienes y servicios.
Sección
Principal
Acción de los Actores
Respuesta del Sistema
Flujo normal de los eventos
1. El administrador entra en la página donde modifica el pedido.
2. El sistema advierte que va a modificar datos.
3. El administrador ingresa los datos a modificar y guarda.
4. El sistema entrega el mensaje que “Los datos han sido guardados exitosamente”
Flujos Alternativos
Línea 4. Los datos ingresados no son válidos, intente nuevamente o salga del editor.
-
Caso de Uso:
Adjuntar Documentos
Actores:
Usuario y Operario Administrador
Precondiciones
El Usuario debe estar logeado en el sistema.
Propósito:
Adjuntar documentos que se necesitan para complementar los pedidos.
Resumen:
Son los documentos que el proceso requiere para validar la compra del bien o servicio.
Sección
Principal
Acción de los Actores
Respuesta del Sistema
Flujo normal de los eventos
1. El usuario presiona el botón que adjunta documento.
2. El sistema despliega una ventana de exploración donde el usuario dirá que archivo ocupa.
3. El usuario elige el archivo y adjunta.
4. El sistema entrega el mensaje que “Los datos han sido guardados exitosamente”
Flujos Alternativos
Línea 4. Los datos ingresados no son válidos, intente nuevamente o salga del editor.
-
Caso de Uso:
Eliminar Pedidos
Actores:
Usuario, Operario Administrador y administrador.
Precondiciones
El Usuario debe estar logeado en el sistema.
Propósito:
Eliminar pedidos de sistema.
Resumen:
Es la eliminación de pedidos que por algún problema deben cancelarse.
Sección
Principal
Acción de los Actores
Respuesta del Sistema
Flujo normal de los eventos
1. El usuario presiona el botón que elimina el pedido.
2. El sistema despliega una ventana donde se le advierte al usuario que se eliminara el Pedido.
3. El usuario acepta eliminar el Pedido
4. El sistema entrega el mensaje que “Los datos han sido borrados exitosamente”
Flujos Alternativos
-
Caso de Uso:
Buscar Pedidos
Actores:
Usuario y Operario Administrador
Precondiciones
El Usuario debe estar logeado en el sistema.
Propósito:
Busca los documentos específicos en el sistema.
Resumen:
Los pedidos son buscados por fecha o número de memo en el sistema.
Sección
Principal
Acción de los Actores
Respuesta del Sistema
Flujo normal de los eventos
1. El usuario presiona el botón Buscar y entrega los datos para la búsqueda.
2. El sistema el sistema muestra los resultados.
3. El usuario elige el pedido de la búsqueda
4. El sistema entrega el mensaje que “Los datos han sido guardados exitosamente”
Flujos Alternativos
Línea 2. El sistema muestra “los datos entregados no arrojan resultados.”
Capítulo 6.1.2
Diagrama de Clases
El diagrama de clases muestra cómo será implementado el sistema con las bases de datos y con los atributos de cada tabla. Como se muestra en la figura 6.1.2
Figura 6.1.2
Flujo de Proceso
Este es el proceso de flujo del directorio de transporte público metropolitano, para generar un pedido, como se muestra en la figura 6.1.1.2
Figura 6.1.1.2
Capítulo 6.1.3
Diagrama de Colaboración
E
l
diagrama nos mostrara como el sistema colabora con los distintos
actores del sistema de pedidos. Como se muestra en la imagen 6.1.3
Imagen 6.1.3
Capítulo 6.1.5
Diseño de Interfaces
Figura 6.2
Diseño Físico
La imagen a continuación nos muestra como esta el diseño físico de la base de datos del sistema.
Imagen 6.2
Capítulo 6.2.1
Diccionario de Datos
Tablas |
Columna |
Atributos |
Escritura |
Tipo de llave |
Gerente |
gerente_key |
Varchar 10 |
NO NULL |
Primare key |
|
email_gey |
Varchar 45 |
NULL |
|
|
fono_ger |
Varchar 10 |
NULL |
|
|
Nombre_ger |
Varchar 45 |
NULL |
|
Proyecto |
enar_proy |
Varchar 20 |
NO NULL |
Primare Key |
|
emal_proy |
Varchar 45 |
NULL |
|
|
fono_proy |
Varchar 10 |
NULL |
|
|
Nombre_proy |
Varchar 45 |
NULL |
|
Recibidor |
recibidor_key |
Varchar 10 |
NO NULL |
Primare Key |
|
email_prov |
Varchar 45 |
NULL |
|
|
fono_prov |
Varchar 10 |
NULL |
|
|
Nombre_prov |
Varchar 45 |
NULL |
|
Ingreso |
rut |
Int |
NO NULL |
Primare Key |
|
dig_ver |
Int |
NULL |
|
|
Nombre |
Varchar 45 |
NULL |
|
|
Apellido |
Varchar 45 |
NULL |
|
Procesos |
idProceso |
Int |
NO NULL |
Primare Key |
|
Licitacion |
Varchar 45 |
NULL |
|
|
Trato_dir |
Varchar 45 |
NULL |
|
|
conv_marc |
Varchar 45 |
NULL |
|
Adquisición |
memo |
Varchar 5 |
NO NULL |
Primare Key |
|
Nombre_Adquisicion |
Varchar 45 |
NULL |
|
|
Objeto_adquirir |
Varchar 45 |
NULL |
|
|
Proceso_idProceso |
Int |
NO NULL |
Foreign key |
Datos |
idDatos |
int |
NO NULL |
Primare Key |
|
memo |
Varchar 5 |
NULL |
|
|
Gerente_gerente_key |
Varchar 10 |
NO NULL |
Foreign key |
|
Proyecto_encar_proy |
Varchar 20 |
NO NULL |
Foreign key |
|
Recibidor_recibidor_key |
Varchar 10 |
NO NULL |
Foreign key |
|
Fecha_lim |
Date |
NULL |
|
|
Ingreso_Rut |
Decimal (10.1) |
NOT NULL |
Foreign key |
|
Adquisicion_memo |
Varchar 5 |
NOT NULL |
Foreign key |