1. FACULTAD NACIONAL DE INGENIERÍA
INGENIERÍA DE SISTEMAS E INGENIERÍA INFORMÁTICA
SISTEMA DE INFORMACIÓN
PARA LA PASTELERÍA
“BALOO”
INTEGRANTES: Choque Irahola Noelia Abril
Lozano Herrera Armando
Quiñones Rueda Juan Daniel
INGENIERIA DE SOFTWARE I - INF 2720 SEM I/2020
2. CONTENIDO
• PARTE I: Marco Teórico
• PARTE II: Proceso de desarrollo
• PARTE III: Estimaciones
• PARTE IV: Gestión de Riesgos
• PARTE V: Gestión de Calidad
• PARTE VI: Estrategias de Pruebas
• CONCLUSIONES
3. PARTE I: MARCO TEÓRICO
INTRODUCCIÓN
La industria pastelera tiene una gran demanda en clientela por lo que el trabajo de la
masiva cantidad de información genera que la organización sea compleja, por lo tanto,
incrementa la demora en el control económico del negocio.
En determinadas épocas del año durante las festividades (Dia del padre, día de la
madre, día del maestro, promociones, etc.) la demanda de postres se ve aumentada de
forma esporádica, teniendo un efecto colateral en la manufacturación de la
información.
Durante el manejo de sucursales existe una deficiencia, en la coordinación y
comunicación para la recepción de los postres especialmente las tortas, causando
irregularidades en la conciliación diaria.
4. ANTECEDENTES
La Pastelería a la que se hace referencia lleva el nombre
de “PASTELERÍA BALOO” que cuenta con dos
sucursales de venta, uno de ellos ubicado en la calle
Pagador y Adolfo Mier Nº 1309 y la otra en la calle
Adolfo Mier y Pagador Nº 917.
La dueña del negocio es: la Sra. Jacqueline Irahola
Fuentes, este negocio comercializa variedad de postres
dulces y las principales tortas de todo tamaño, precio y
forma.
Cada sucursal pastelera cuenta con 4 empleados/as
con un cargo de vendedores en el que trabaja un
empleado/a para cada turno ya sea mañana o tarde de
lunes a sábado, de esta manera la Pastelería se
encuentra abierta toda la semana en los horarios
indicados continuamente
POLÍTICAS DE LA INSTITUCIÓN
La puntualidad de todos los empleados.
Limpieza debida cada día al terminar su turno.
Las ventas a diario deberán ser estables o
aumentando, se realiza un control de ajuste de
las ventas al finalizar el día.
Cada venta realizada tiene su detalle en
registro manualmente en un cuadernillo
proporcionado (Actualmente).
Anotar e informar en el tiempo que se realiza
un contrato para algún cliente, teniendo en
cuenta todas sus exigencias y detalles pedidos.
Para realizar contratos se debe pedir un 50%
del pago adelantado.
5. ORGANIGRAMA MISIÓN
Somos un negocio cuya misión es ofrecer
productos de repostería y pastelería en general
usando ingrediente de la más alta calidad, con
un excelente sabor y a un precio accesible,
cumpliendo las exigencias del mercado y la de
los clientes.
VISIÓN
Baloo busca ser la mejor opción en elaboración y
comercialización de pasteles, innovando
continuamente los sabores, diseños y decoraciones
para cumplir la demanda de los clientes, con el
compromiso de utilizar los más altos estándares de
calidad y tecnología de vanguardia nuestros
procesos productivos en todas nuestras actividades.
6. FORMULACIÓN DEL PROBLEMA
DESCRIPCIÓN DE LA SITUACION
PROBLEMÁTICA
CAUSA EFECTO
La mala recepción del
pedido.
Discordancia en el pedido e
inconformidad del cliente.
La falta de conciliación en el
perfil del personal.
Genera desconfianza y
desconocimiento entre la
gerencia y los empleados.
La carencia de control y
organización en la venta.
Dificulta la auditoria
semanal.
La modificación de los
vendedores en cuanto al
precio de venta.
Ocasiona agravamento en
los productos, la pérdida
de credibilidad y clientela.
PLANTEAMIENTO DEL
PROBLEMA
¿Cómo se puede controlar el
manejo de información ante
el índice de errores por la
mala administración en el
área pedidos en la pastelería
Baloo?, ubicado en la ciudad
capital de Oruro.
7. PLANTEAMIENTO DE OBJETIVOS
OBJETIVO GENERAL
Desarrollar un sistema de información
para controlar el manejo de información
ante el índice de errores por la mala
administración en el área pedidos en la
pastelería Baloo, ubicada en la ciudad
capital de Oruro.
OBJETIVOS ESPECIFICOS
Implementar los diagramas correspondientes a
la metodología ICONIX.
Establecer una planificación utilizando el
diagrama de Gantt.
Diseñar la base de datos para el sistema de
información. (Oracle)
Diseñar prototipos interfaces.
Operacionalizar la funcionalidad del sistema
de información.
Cumplir requerimientos de calidad según
normativa
Realizar pruebas de caja blanca y negra.
8. DEFINICIÓN DEL AMBITO DEL SOFTWARE
PRINCIPALES FUNCIONES Y RENDIMIENTO
REQUERIMIENTOS
FUNCIONALES
REQUERIMIENTOS NO
FUNCIONALES
El sistema consta de una autenticación de usuario
tanto para empleado como administrador.
El sistema registra Clientes, empleados, pedidos,
productos.
El sistema emite una boleta de pago.
El sistema muestra el reporte de clientes y
empleados.
El sistema muestra el control de las
modificaciones del sistema.
El sistema muestra el reporte de inventario,
reporte de contratos y de ventas.
El sistema conserva la integridad.
El sistema es seguro.
El sistema tiene un entorno amigable.
El sistema es escalable.
El sistema tiene usabilidad.
9. ORGANIZACIÓN DE RECURSOS
ORGANIZACIÓN DEL PERSONAL PARTICIPANTES
JEFE DEL EQUIPO
EQUIPO DE SOFTWARE
COORDINACION Y COMUNICACIÓN
Es importante que los integrantes del proyecto
estén capacitados en el lenguaje de programación
C# y en el IDE Visual Studio, para poder hacer un
correcto desarrollo del software como también
tener un conocimiento de Enterprise Architect,
Word, Git, Discord y Zoom.
Promueve e incentiva la iniciativa para el
logro del equipo.
Tiene la confianza para asumir el control
del proyecto y brindar apoyo a los
integrantes del grupo.
Analista: Quiñones Rueda Juan Daniel
Programador: Choque Irahola Noelia Abril
Gestor del Proyecto: Lozano Herrera Armando
10. DIAGRAMA DE GANNT
DG PROYECT PASTELERIA
ENCARGADO DEL PROYECTO Armando Lozano Herrera
FECHAS DE INICIO Y FIN DEL
PROYECTO
13-mar-2020 - 7-jun-2020
Nº TAREAS 19
Nº RECURSOS 3
11. PARTE II: PROCESO DE DESARROLLO (ICONIX)
MODELO DEL DOMINIO
class Domain Model
Administrador
Boleta de
Pago
Cliente
Contrato
Decorador
Gerente
Hornero
Inventario
Pasteleria
Producto
Reporte
Sistema de
Información
Usuario
Vendedor
Venta
Empleado
12. DIAGRAMA DE CASOS DE USO DEL NEGOCIO
uc DCUN PASTELERIA
ADMINISTRADOR
CLIENTE
GERENTE
HORNERO
PASTELERO
REPOSTERO
VENDEDOR
ADMINISTRAR
EMPLEADOS
ELABORAR DE
POSTRES
DECORAR
POSTRE
ENVIAR PEDIDO
GENERAR
REPORTE
SEMANAL
HORNEAR
POSTRE
ORDENAR
PEDIDO
REALIZAR
VENTA
RECEPCIONAR
PEDIDO
SOLICITAR
PEDIDO
ENVIAR
REPORTE
«extend»
«include»
«include»
«extend»
13. DIAGRAMA DE CASOS DE USO DEL SISTEMA
uc DCUS PASTELERIA
Administrador
Usuario
Vendedor
Gerente
Administrar
Inventario
Almacenar
Pedido
Cliente
Contrato
Controlar
Modificaciones
Emitir Boleta de
Pago
Empleado
Específico
General
Generar Reporte
Iniciar Sesión Inventario
Venta
Registrar
Cliente
Registrar
Contrato de
Venta
Registrar
Empleado
Registrar
Productos
«extend»
«extend»
«include»
«extend»
«extend»
«include»
«extend»
«extend»
«extend»
«include»
14. DIAGRAMA DE PAQUETES DE CASOS DE USO
cmp Diagrama de paquetes
Persona
+ Persona
Capa de Presentación
+ Interfaz Administrador
+ Interfaz Usuario
Pedido
+ Registros
+ Reportes
Base de datos
+ BdDPasteleria
Contrato
+ Registro Contratos
15. DIAGRAMA DE
SECUENCIAS
Registrar
Empleado
sd Registrar Empleado
Gerente
Interfaz de
empleados
Control
Empleados
Empleados
Mostrar éxito de modificación()
«destroy»
Eliminar Empleado()
Almacenar datos()
Guardar Cambios()
Return ()
Controlar datos()
Mostrar mensaje aceptado()
«destroy»
Return()
Ingresar datos()
Seleccionar Empleado()
Mandar orden()
Return()
Mostrar mensaje de eliminación()
Seleccionar Empleado()
Eliminar datos()
Verificar datos()
Return()
Almencenar datos()
Enviar datos()
Enviar Datos()
Return()
Guardar Empleado()
Return()
16. DIAGRAMA DE SECUENCIAS: Reporte de Inventario
sd Inventario
GERENTE/ADMINISTRADOR
Interfaz
Reporte
Inventario
Control
Inventario
Producto
Return()
Mostrar reporte del Inventario()
Buscar datos del
registro Producto()
Pedir datos()
Ingresar a interfaz()
Devolver datos()
Extraer Datos()
17. DIAGRAMA DE
SECUENCIAS
Realizar Venta
sd Almacenar Pedido
Usuario
Interfaz de
Venta/Pedido
Producto Pedido
Cliente
Control Cliente Control
Producto
Control
Pedido
Return()
Seleccionar Cliente()
Buscar Productos()
Operar()
Controlar datos()
Pedir Venta()
Return()
Mostrar Clientes()
«destroy»
Return()
MostrarProductos()
«destroy»
Btn Calcular()
Return()
Return()
Return()
Pedir Datos
(NIT_CI)
Enviar datos()
Guardar datos()
Desplegar Clientes()
Mostrando Total()
«destroy»
LLenar campo de
datos()
Seleccionar Producto()
Realizar Venta()
Return()
Return()
Calcular()
Return()
Verificar datos()
Almacenar datos()
Return()
«destroy»
Enviar Producto
(PRODID)
Verificar datos(NumPed)
Controlar datos()
18. DIAGRAMA DE CLASES/MODELO DE DATOS
classDClasesPasteleria
Cliente
+ CELULARC: VARCHAR(8)
+ NIT_CI: VARCHAR(8)
+ NOMBREC: VARCHAR(50)
Contrato
+ ACUENTA: NUMBER
+ CONTID: VARCHAR(10)
+ DESCRIPCON: VARCHAR(200)
+ EMPID: VARCHAR(8)
+ FECHAEMISION: DATE
+ FECHAENTREGA: DATE
+ NIT_CI: VARCHAR(8)
+ SALDO: NUMBER
Empleados
+ CELULARE: VARCHAR(8)
+ DIREMP: VARCHAR(100)
+ EMPID: VARCHAR(8)
+ NOMBREEMP: VARCHAR(50)
+ TURNO: VARCHAR(20)
Factura
+ EMPID: VARCHAR(8)
+ FECHA: DATE
+ NIT_CI: VARCHAR(8)
+ NITF: VARCHAR(10)
+ NOAUTORIZACION: VARCHAR(12)
+ NUMF: VARCHAR(10)
+ NUMP: NUMBER
+ PRODID: VARCHAR(10)
+ TOTAL: NUMBER
Pedido
+ CANTIDAD: NUMBER
+ IMPORTE: NUMBER
+ NIT_CI: VARCHAR(8)
+ NUMP: NUMBER
+ PRODID: VARCHAR(10)
Producto
+ DESCRIPCION: VARCHAR(120)
+ PRODID: VARCHAR(10)
+ PU: NUMBER
19. PARTE III: ESTIMACIONES DEL PROYECTO
Trabajando con la siguiente fórmula:
UUCP = UAW + UUCW
Donde: UUCP = Puntos de Casos de uso sin ajustar
UAW = Factor de peso de los actores sin ajustar
UUCW = Factor de peso de los casos de uso
sin ajustar
CÁLCULO DE UAW:
ACTOR TIPO DESCRIPCIÓN
FACTOR
DE PESO
Complejo
Una Persona
interactúa con el
sistema, mediante
interfaz gráfica.
3
Complejo
Una persona
interactúa con el
sistema, mediante
interfaz gráfica.
3
Complejo
Una persona
interactúa con el
sistema, mediante
interfaz gráfica.
3
Complejo
Una persona
interactúa con el
sistema, mediante
interfaz gráfica.
3
uc Actors
Usuario
uc Actors
Administrador
uc Actors
Vendedor
uc Actors
Gerente
A partir de la tabla anterior se tiene que los cuatro actores
interactúan con el sistema, tienes un nivel factor de peso
tres, por tanto:
UAW = 4 * 3
UAW = 12
20. CÁLCULO DE UCCW Y UUCP
CASO DE USO TIPO DESCRIPCIÓN
FACTOR
DE PESO
Simple
El caso de uso
contiene de 1 a
3 transacciones.
5
Simple
El caso de uso
contiene de 1 a
3 transacciones.
5
Simple
El caso de uso
contiende 1 a 3
transacciones.
5
uc Casos de Uso
Generar Reporte
uc Casos de Uso
Venta
uc Casos de Uso
General
CASO DE USO TIPO DESCRIPCIÓN
FACTOR
DE PESO
Simple
El caso de uso
contiene de 1 a
3 transacciones.
5
Simple
El caso de uso
contiene de 1 a
3 transacciones.
5
Simple
El caso de uso
contiene de 1 a
3 transacciones.
5
uc Casos de Uso
Específico
uc Casos de Uso
Cliente
uc Casos de Uso
Contrato
21. CASO DE USO TIPO DESCRIPCIÓN
FACTOR
DE PESO
Complejo
El caso de uso
contiene más de 8
transacciones.
15
Complejo
El caso de uso
contiene más de 8
transacciones.
15
CASO DE USO TIPO DESCRIPCIÓN
FACTOR
DE PESO
Medio
El caso de uso
contiene de 4 a 7
transacciones.
10
Medio
El caso de uso
contiene de 4 a 7
transacciones.
10
Medio
El caso de uso
contiene de 4 a 7
transacciones.
10
uc Casos de Uso
Registrar
Empleado
uc Casos de Uso
Registrar Cliente
uc Casos de Uso
Registrar Contrato
de Venta
uc Casos de Uso
Almacenar Pedido
uc Casos de Uso
Controlar
Modificaciones
22. A partir del dato calculado anteriormente y de
la tabla anterior se tiene los siguientes cálculos
en cantidad de casos de uso con respecto a su
factor de peso:
CÁLCULO DEL UCCW
FACTOR DE PESO DE LOS CASOS DE USO SIN
AJUSTAR
UCCW = 11*5 + 4*10 + 2*15
UCCW = 125
CÁLCULO DEL UUCP
PUNTOS DE CASOS DE USO SIN AJUSTAR
UUCP = UAW + UCCW
UUCP = 12 + 125
UUCP = 137
CÁLCULO PUNTOS DE CASOS DE USO
AJUSTADOS UCP
UCP =UUCP * TCF * EF
Dónde: UCP = Puntos de Casos de uso ajustados
UUCP= Puntos de casos de uso sin ajustar
TCF = Factor de complejidad técnica
EF = Factor del ambiente
23. CÁLCULO TCF
Factor de complejidad
técnica
DESCRIPCIÓN VALOR
Irrelevante 0 a 2
Medio 3 a 4
Esencial 5
FACTOR DESCRIPCIÓN PESO
VALOR
ESTIMADO
PRODUCTO DESCRIPCIÓN
T1 Sistema distribuido. 2 0 0
El sistema es
centralizado
T2
Objetivos de performance o
tiempo de respuesta.
1 3 3
La respuesta depende
del usuario
T3 Eficiencia de usuario final. 1 4 4 Buenas restricciones
T4
Procesamiento interno
complejo.
1 1 1
No hay cálculos
complejos
T5 El código debe ser reutilizable. 1 5 5 En algunos casos
T6 Facilidad de instalación 0.5 0 0
No necesita
instalación
T7 Facilidad de uso. 0.5 5 2.5 Buena
T8 Portabilidad. 2 5 10 Es muy necesario
T9 Facilidad de cambio. 1 0 0
No se requiere
mucho mantenimiento
T10 Concurrencia. 1 1 1 Poca concurrencia
T11
Incluye objetivos especiales de
seguridad.
1 0 0 Ninguna
T12
Provee acceso directo a
terceras partes.
1 0 0 Usuario de escritorio.
T13
Se requiere facilidades
especiales de entrenamiento a
usuario.
1 1 1 Sistema fácil de usar
TOTAL 27,05
Con estos datos:
TCF = 0.6 + 0.01 *(total)
TCF = 0.6 + 0.01 *27.5
TCF = 0.875
24. CÁLCULO DE EF
Factor del ambiente
FACTOR DESCRIPCIÓN PESO VALOR PRODUCTO DESCRIPCIÓN
E1
Familiaridad con el
modelo de proyecto
utilizado.
1.5 3 4.5
El equipo esta
medianamente
familiarizado
E2
Experiencia en la
aplicación
0.5 3 1.5
Se tiene mucha
experiencia
E3
Experiencia en
orientación a objetos
1 5 5
Demasiada experiencia
en objetos
E4
Capacidad del analista
líder
0.5 4 2 Con algún conocimiento
E5 Motivación 1 5 5
El grupo está muy
motivado, porque quiere
aprobar.
E6
Estabilidad de los
requerimientos
2 4 8 Pocos cambios.
E7 Personal part-time -1 1 -1 Casi full-time
E8
Dificultad del lenguaje
de programación
-1 2 -2 Se usará C#.
TOTAL 23
Con estos datos:
EF = 1.4 + (-0.03 * Total)
EF = 1.4 + (-0.03 * 23)
EF = 0.71
CÁLCULOS DE UCP
Puntos de caso de uso ajustado
UCP = UUCP * TCF * EF
UCP = 137 * 0.875 * 0.71
UCP = 85.11125
25. ESTIMACIÓN DEL ESFUERZO
La estimación del esfuerzo invertido en los
casos de uso, se tiene a partir de los siguientes
datos de la tabla anterior:
Valores de E1 a E6: 3-3-5-4-5-4
Valores de E7 a E8: 1-2
FACTOR FILTRO
De E1 a E6 Factor < 3
De E7 a E8 Factor > 3
Según la tabla se tiene que:
De E1 a E6 #factores < 3 = 0
De E7 a E8 #factores > 3 = 0
Por lo tanto, el total es 0.
HORAS-
PERSONA (CF)
DESCRIPCIÓN
20 Si el valor es <= a 2
28 Si el valor es <= a 4
36 Si el valor es >= a 5
Ya que el valor obtenido es igual a 0, según
la tabla se tiene que:
CF = 20[h-per]
Por tanto, el valor del esfuerzo (E) es:
E = CF * UCP
E = 20 * 85.11125
E = 1702.225 [h-per]
26. T = 1702.225 [h-per] / 3 [per]
T = 567.408 [h]
El costo total económico, invertido en la
programación del proyecto es:
El valor del esfuerzo obtenido, lo repartimos a 3 por ser el número de integrantes del proyecto, con ello se
tiene que el tiempo en programación del proyecto es:
Costo Total = 1702.225 [h-per] * 50[bs/h-per]
Costo Total = 85111.25 [bs]
ACTIVIDAD PORCENTAJE HORAS-PERSONAS
Análisis 10.00% 268.056
Diseño 20.00% 851.113
Programación 40.00% X(1702.225)
Pruebas 15.00% 638.334
Sobrecarga 15.00% 638.334
TOTAL 100.00% 4098.062
T=4098.062[h-per]
ESTIMACIÓN DEL TIEMPO
ESTIMACIÓN DEL COSTO
ESTIMACIÓN DEL TIEMPO TOTAL
DEL PROYECTO
27. GESTIÓN DE RIESGOS
LISTA DE CHEQUEO DE RIESGOS
TAMAÑO DEL PRODUCTO
• TAMAÑO ESTIMADO EN LÍNEAS DE CÓDIGO:
1347 líneas de código aproximado
• TAMAÑO ESTIMADO DE PROGAMAS, ARCHIVOS
Y TRANSACCIONES:
255 MB, 479 archivos, 40 transacciones
• NÚMERO DE USUARIOS:
3 usuarios, vendedor, administrador y supervisor.
• CAMBIOS DEL PROYECTO REQUERIDOS:
17 cambios realizados hasta el momento.
RIESGOS RELACIONADOS CON EL
CLIENTE
PARTE IV:
¿TIENE EL CLIENTE UNA IDEA
SOLIDA DE LO QUE SE REQUIERE?
SI
¿ESTÁ EL CLIENTE DISPUESTO A
ESTABLECER ENLACES DE
COMUNICACIÓN RÁPIDOS CON EL
DESARROLLADOR?
SI
¿EL CLIENTE ESTÁ DISPUESTO A
PARTICIPAR EN LAS REVISIONES?
NO
¿EL CLIENTE ESTÁ DISPUESTO A
DEJAR QUE SU GENTE HAGA SU
TRABAJO?
SI
LISTAS DE CHEQUEO DE RIESGOS
28. RIESGOS DE IMPACTO DEL
NEGOCIO
¿HAY DISPONIBLE UNA
HERRAMIENTA DE GESTIÓN DE
PROYECTOS DE SOFTWARE?
SI
¿ESTÁN DISPONIBLES LAS
HERRAMIENTAS DE ANÁLISIS Y
DISEÑO?
SI
¿EL ENTORNO UTILIZA UNA
BASE DE DATOS O UN
REPOSITORIO?
Sí, una BdD
¿HAY EXPERTOS LOCALES
DISPONIBLES PARA
RESPONDER PREGUNTAS
SOBRE LAS HERRAMIENTAS?
SI
RIESGO DEL ENTORNO DE
DESARROLLO
• RAZONABILIDAD DEL PLAZO DE
ENTREGA:
6 meses
• SOFISTICACIÓN DE MANEJO DEL
USUARIO FINAL.
El sistema es de fácil aprendizaje y
se considera poco sofisticado
• COSTOS ASOCIADOS CON
ENTREGA TARDÍA
80 bs por cada día de retraso.
• COSTOS ASOCIADOS CON UN
PRODUCTO DEFECTUOSOS
34044 Bs
29. TABLA DE EVALUACIÓN DE RIESGOS
Nº CATEGORÍA ÁREA RIESGO PROB. IMPACTO ER PRIORIDAD
1 Técnico Implementación Falta de código limpio 80% 55% 0.44 Critico
2 Impredecible Definir área Ocurrencia de fallo del servidor. 20% 80% 0.16 Marginal
3 Proyecto Personal Ingreso de un nuevo miembro. 10% 50% 0.05 Despreciable
4 Proyecto Participantes
La falta de experiencia de los
integrantes.
25% 60% 0.15 Despreciable
5 Técnico Verificación
Intentos mal intencionados de acceder
a la información del proyecto.
30% 75% 0.23 Marginal
6 Técnico Diseño Planificación demasiado optimista. 7% 63% 0.04 Despreciable
7 Proyecto Calendario
La aprobación del proyecto tarda más
de lo esperado.
75% 80% 0.60 Critico
8 Proyecto Calendario
Los informes de estado a nivel de
directiva necesitan más tiempo del
previsto
80% 90% 0.72 Catastrófico
9 Proyecto Personal
Se enferma personal clave en el
desarrollo del proyecto.
50% 75% 0.38 Marginal
10 Empresarial Administrativo
El cliente no participa en los ciclos de
revisión de los planes y prototipos.
90% 40% 0.36 Critico
30. MITIGACIÓN:
En el tiempo actual y entorno en el que se realiza el proyecto se enfrenta una pandemia del
virus Covid-19, la salud del equipo de trabajo debe estar en un estado óptimo para continuar
con el desarrollo.
RIESGO: SE ENFERMA PERSONAL CLAVE EN
EL DESARROLLO DEL PROYECTO
MONITOREO:
Todos los integrantes del proyecto deben estar conscientes de la presencia del virus y tomar las
medidas de precaución para resguardar la salud apropiadamente, por ello se evitan reuniones
presenciales para desarrollar cada fase o acuerdo que se tenga sobre el proyecto
GESTIÓN:
La ausencia temporal de un miembro del equipo que desarrolla y conoce una fase en particular del
proyecto como es el software mismo complica el seguimiento del proyecto y lo retrasa directamente.
Se invertirá un poco más de tiempo para entender y recabar aquella información que se
desconoce por la falta de un integrante.
35. EL modulo del registro de cliente, permite registrar,
modificar y eliminar los datos de un cliente de la base
de datos del Sistema, verificando que el nombre sean
puros caracteres alfabéticos, el celular sea solamente
números enteros positivos.
REGISTRO DE CLIENTES
TABLA CLASES DE EQUIVALENCIAS
TABLA DE CASOS DE PRUEBA
PRUEBAS DE CAJA NEGRA
MENSAJE DE SALIDA
36. PRUEBAS DEL SISTEMA
CONFIRMACIÓN DE
ACCIÓN
El usuario selecciona un cliente,
cambia datos en sus campos
respectivos y se tiene un mensaje
de confirmación para la
modificación:
PRUEBAS DE VALIDACIÓN
El Software es aceptado por el
cliente, ya que cumple, con sus
requerimientos solicitados.
PRUEBAS DE SEGURIDAD
Se evidencia en el acceso
restringido al sistema y los
controles de modificaciones
realizadas a la información.
37. CONCLUSIONES
Finalizando la demostración y desarrollo del proyecto se concluye que se tiene calidad en el
proceso de desarrollo del producto software debido a que se cumplió con:
Los puntos de trabajo.
Planificación sobre el avance estimado del proyecto.
El seguimiento a la metodología de desarrollo empleada como es Iconix.
Cálculos respectivos de estimaciones tanto en esfuerzo, como en tiempo y costo.
El control y manejo de Riesgos (PLAN RMMM).
El cumplimiento con los puntos de calidad planteados por la ISO9001.
Las pruebas necesarias (CAJA BLANCA – CAJA NEGRA)
