Formato 1.2.3.4

UNIVERSIDAD PERUANA LOS ANDES
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA SISTEMAS Y COMPUTACIÓN

TEMA:
SISTEMA DE CONTROL DE VENTAS DE UN MARKET “D’TODO” –

HUANCAYO
ESTUDIANTES:
Choque Juscamaita, Ian Demis
Olivares Torres Jean Piero Irving
ASIGNATURA:
Construcción de software
DOCENTE:
Ing. Orlando Cordova Ataucusi
PERÚ, 2021 – I
FORMATO 1
PROYECTO DE SOFTWARE
Analista-Desarrollador Choque Juscamaita, Ian Demis

Olivares Torres Jean Piero Irving
Desarrollo
Especificacion
Diseño Integración
de
de pruebas
requerimienos
1. Cliente
1.1. Nombre : Sistema de control de ventas en un market “D’TODO” – Huancayo
1.2. Giro : Amplio surtido de Productos.
1.3. Dirección : Jr. 9 de octubre 1501, augusto uduarte 15072
1.4. Misión : Satisfacer a nuestros clientes, brindando los mejores productos de primera.
Con productos de calidad y frescos, con la aplicación de buenas prácticas de
manufactura, con la mejor atención y en un agradable ambiente.
2. Problemas detectados
a. No existe un seguimiento de las boletas emitidas.

b. No se encuentra un registro de los Proveedores.
c. El dueño del market desea conocer los ingresos que se generan en un día.
d. Las boletas se hacen de manera manual.
e. No tiene un control de los productos .
3. Requerimientos
3.1. Funcionales (¿Qué debe hacer el software?)
Registro de datos
El software debe:
- Permitir el registro de los Categoria con los siguientes datos por separado:
IdCategoría, NombreCategoria, Descripcion.
- Permitir el registro de los Producto con los siguientes datos por separado:
IdProducto, IdCategoría, IdProveedor, Nombre, UnidadMedida, PrecioProveedor,
StockActual, StockMinimo.
- Permitir el registro de los Proveedor con los siguientes datos por separado:
IdProveedor, Nombre, Representante, Dirección, Ciudad, Departamento,
CodigoPostal, Teléfono, Fax.
- Permitir realizar el CRUD de Categoría (Crear, Leer, Actualizar, Eliminar)
- Permitir realizar el CRUD de Producto (Crear, Leer, Actualizar, Eliminar)
- Permitir realizar el CRUD de Proveedor (Crear, Leer, Actualizar, Eliminar)
Procesamiento
El software debe:
- Generar una lista de los Productos.
- Generar una lista de los Proveedores.
- Generar una lista de las Categorías
- Hacer el proceso de ingreso del nuevo stock más rápido
Reportes, informes
El software debe:
- Generar un reporte de Productos.
- Generar un reporte de Proveedores.
- Generar un reporte de Categoria.
3.2. No Funcionales (¿Cómo debe funcionar el software?)
Rendimiento o performance - El tiempo de respuesta No debe superar los 4

segundos.
Seguridad - Todo acceso al sistema (software y base de datos)
debe ser previa autenticación.
Recursos - El software debe operar en una convencional, que
hará las veces de servidor.
Usabilidad - El menú debe ser de fácil de uso.
- Las interfaces deben incluir una versión web para el
acceso de usuarios remotos.
Disponibilidad - El sistema deberá estar disponible los 365 días del
año, los 7 días de la semana y operar durante 24 horas
ininterrumpidas.
Confiabilidad - El software no debe detenerse inesperadamente
(colgarse)
- Todo posible mensaje de error debe estar controlado
por el mismo software.
Escalabilidad - El software debe soportar el acceso hasta por 50
personas a la vez.
Modificabilidad - El software debe ser fácilmente adaptable a futuros
lenguajes y motores de base de datos.
4. Viabilidad
Previa revisión de los requisitos funcionales y no funcionales, se concluye que el proyecto es
FORMATO 2
Analista-Desarrollador
5. Cliente
5.1. Nombre
5.2. Giro
6. Diseño de base de datos
6.1. Identificación de entidades

a. Producto
b. Categoría
c. Proveedor
6.2. Modelamiento
Modelo Lógico
Modelo físico
FORMATO 3
Diccionario de datos
El diccionario de datos describe y detalla la configuración de cada tabla y campo de la base de datos.
Este documento es de vital importancia para el posterior mantenimiento y actualización del sistema
de información.
 Nombre de columna: Nombre de cada campo o atributo. Tal y cual ha sido creado en la base
de datos.
 PK y FK: Marcar con equis (“X”) si el campo es llave primaria y/o secundaria.
 Descripción: Se detalla exactamente qué datos se almacenarán, y en algunos casos el cómo
(formato del campo). Por ejemplo:
o Tabla: tblTrabajador
Columna: Dirección
Descripción: Dirección domiciliaria del trabajador, la cual deberá ser ingresada
considerando la siguiente secuencia: Tipo de calle, nombre de calle, número de casa,
nombre de urbanización.
o Tabla: tblProducto
Columna: preVenta
Descripción: Precio de venta del producto.
 Tipo de dato: Especifica el tipo de dato genérico (no del motor de base de datos) de cada
campo. Elegir entre:
o Numérico entero
o Numérico decimal
o Texto (o cadena)
o Lógico
o Imagen
o Otro
 Dominio: Menciona o enumera los posibles valores para el campo. Se debe mencionar de
forma genérica cuando estos valores son muchos o infinitos; por ejemplo los campos
“apellido paterno” o “precio”. Al contrario, se debe enumerar cuando los posibles valores
son pocos; por ejemplo, los campo “sexo”, “categoría”, etc.
DICCIONARIO DE DATOS
7. Cliente
7.1. Nombre
7.2. Giro
8. Tablas y campos
Tabla: Producto
Tipo de dato Dominio (posibles
Nombre de columna PK FK Descripción (genérico) valores)
IdProducto X INT 5
IdCategoria X INT 5
IdProveedor X INT 5
Nombre NVARCHAR 40 25
UnidadMedida NVARCHAR 30 15
PrecioProveedor DECIMAL 3
StockActual DECIMAL 6
StockMinimo DECIMAL 6
Tabla: Proveedor

IdProveedor X INT 5
Nombre NVARCHAR 40 20
Representante NVARCHAR 30 20
Direccion NVARCHAR 60 20
Ciudad NVARCHAR 15 15
Departamento NVARCHAR 15 15
CodigoPostal DECIMAL 5
Telefono DECIMAL 9
Fax DECIMAL 9
Tabla: Categoría

IdCategoria X INT 5
NombreCategoria NVARCHAR 20 30
Descripcion NVARCHAR 40 30
ARQUITECTURA DE CAPAS
9. Cliente
9.1. Nombre
9.2. Giro
10. Arquitectura de capas
MARKET.DOMINIO
MODELO,REPOSITORIO
MARKET.INFRAESTRUCTURA
BASE, REPOSITORIO,MIGRACIONES
MARKET.UI
CONTROLADORES
LAS VISTAS

Formato 1.2.3.4

Cargado por

Copyright:

Formatos disponibles

Formato 1.2.3.4

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Formato 1.2.3.4

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PERUANA LOS ANDES

SISTEMA DE CONTROL DE VENTAS DE UN MARKET “D’TODO” –

Choque Juscamaita, Ian Demis

Olivares Torres Jean Piero Irving

Ing. Orlando Cordova Ataucusi

Analista-Desarrollador Choque Juscamaita, Ian Demis

a. No existe un seguimiento de las boletas emitidas.

3.1. Funcionales (¿Qué debe hacer el software?)

3.2. No Funcionales (¿Cómo debe funcionar el software?)

Rendimiento o performance - El tiempo de respuesta No debe superar los 4

Previa revisión de los requisitos funcionales y no funcionales, se concluye que el proyecto es

6. Diseño de base de datos

6.1. Identificación de entidades

Tipo de dato Dominio (posibles

Tipo de dato Dominio (posibles

10. Arquitectura de capas

También podría gustarte