Proy Final Ing Software

U.T.O. F.N.I.
Universidad Tcnica de Oruro

Facultad Nacional De Ingeniera
TEMA: SISTEMA DE COBRO DE

MULTAS
BIBLIOTECA CEISI
Nombres: LEDO VARGAS ANGHELO
LLAMPA COLQUE JOSE LUIS
SUAREZ FLORES ROBERTO
DOCENTE: ING. JULIO CESAR BERMUDEZ VARGAS
Auxiliar: UNIV. SUSSY K. AJATA CACERES
Materia: INF 2720
PARALELO: A
ORURO BOLIVIA
SISTEMA DE COBRO DE MULTAS BIBLIOTECA - CEISI
INDICE
1. INTRODUCCION ..................................................................................................................................... 3
2. ANTECEDENTES DEL PROYECTO.................................................................................................... 3
3. FORMULACION DEL PROBLEMA ..................................................................................................... 4
3.1. DESCRIPCION DE SITUACIONES PROBLEMATICAS ..........................................................4
3.2. PLANTEAMIENTO DEL PROBLEMA ........................................................................................4
4. PLANTEAMIENTO DEL OBJETIVOS ................................................................................................ 5
4.1. OBJETIVO GENERAL.................................................................................................................... 5
4.2. OBJETIVOS ESPECIFICOS........................................................................................................... 5
5. DEFINICION DEL AMBITO DEL SOFTWARE .................................................................................5
5.1. PRINCIPALES FUNCIONES Y RENDIMIENTO .......................................................................5
5.2. UNIVERSO DE INFORMACION .................................................................................................. 6
5.3. CONTEXTO ...................................................................................................................................... 6
6. ORGANIZACIN DE RECURSOS ....................................................................................................... 6
6.1. RECURSOS DE SOFTWARE ......................................................................................................... 6
6.2. RECURSOS DE HARDWARE........................................................................................................ 7
6.3. ORGANIZACIN DEL PERSONAL .............................................................................................7
7. PROCESO DE DESARROLLO .............................................................................................................. 7
7.1. ANALISIS DEL SISTEMA ................................................................................................................... 7
7.2. INVESTIGACION PRELIMINAR ....................................................................................................13
7.3. METODO ISAC ................................................................................................................................... 14
7.4. MODELO DEL NEGOCIO ................................................................................................................ 18
7.4.1. MODELO DEL NEGOCIO (DIAGRAMA DE CASOS DE USO DEL NEGOCIO) .............19
7.4.2. MODELO DE ANLISIS DE NEGOCIO..................................................................................19
7.4.3. ESPECIFICACIN DE ACTORES DEL NEGOCIO ..............................................................20
7.5. DIAGRAMA DE CASOS DE USO DEL SISTEMA ........................................................................21
7.6. ESPECIFICACIN DE CASOS DE USO .........................................................................................22
7.7. DIAGRAMA DE CLASES .................................................................................................................. 28
7.8. DESCRIPCION DE LAS CLASES ....................................................................................................28
7.9. DIAGRAMA DE ANALISIS CLASES SEGN CASOS DE USO .................................................29
7.10. DIAGRAMAS DE SECUENCIA ......................................................................................................30
7.11. DISEO DE INTERFACES ............................................................................................................. 48
7.12. MODELO DE BASE DE DATOS.....................................................................................................55
1
7.12.1. DIAGRAMA DE CLASES PERSISTENTES ..........................................................................55
7.12.2. MODELO RELACIONAL ......................................................................................................... 55
7.12.3. DICCIONARIO DE DATOS......................................................................................................56
7.13. DIAGRAMA DE DESPLIEGUE ......................................................................................................58
7.14. DIAGRAMA DE COMPONENTES ................................................................................................58
8. ESTIMACION DEL PROYECTO DE SOFTWARE..........................................................................59
9. PLANIFICACION .................................................................................................................................. 66
10. GESTION DE RIESGOS ....................................................................................................................... 67
10.1. IDENTIFICACIN DE RIESGOS ..................................................................................................67
10.3. GESTIN, MONITORIZACIN Y MITIGACIN DE RIESGOS (R.M.M.M.) ......................71
11. MANUAL DE CALIDAD DEL SOFTWARE ........................................................................................76
12. LISTA DE CHEQUEOS ........................................................................................................................... 91
13. PRUEBAS DEL SOFTWARE ............................................................................................................... 108
13.1. PRUEBAS DE CAJA BLANCA .....................................................................................................108
13.2. PRUEBAS DE CAJA NEGRA ........................................................................................................ 127
14. ESTRATEGIAS DE PRUEBA............................................................................................................... 134
15. CONCLUCIONES Y RECOMENDACIONES....................................................................................136
16. BIBLIOGRAFIA ..................................................................................................................................... 136
2
1. INTRODUCCION
2. ANTECEDENTES DEL PROYECTO
La Biblioteca y Centro de Estudiantes de la carrera de Ingeniera de Sistemas Informtica
pertenecientes a la Facultad Nacional de Ingeniera, brindan sus servicios para mejorar la
enseanza y aprendizaje de los estudiantes.
Inicio sus actividades al momento de la creacin de la carrera de Ingeniera de Sistemas
Informtica en la Facultad Nacional de Ingeniera perteneciente a la Universidad Tcnica de
Oruro de la ciudad de Oruro, las cuales se establecieron normas que su correcto funcionamiento,
en caso de incumplir dichas normas se sancionara con una multa ya establecida el cual se
registrara en un sistema informtico para poder realizar su cobro respectivo.
Este sistema de cobro de multas se hizo con el objetivo de que el estudiante pueda cumplir con
las normas establecidas correctamente.
En sus inicios el sistema de cobro de multas se controlaba de manera manual, registrando en una
hoja, el cual con el tiempo la perdida de la informacin era muy recurrente y no haba forma de
realizar los cobros, desde que se implanto un sistema informtico de software ya se poda
registrar
las multas establecidas y realizar los cobros sin problemas al momento de inscripcin de los
estudiantes en la carrera.
La forma de organizacin es la siguiente:
DIRECCION DE
CARRERA
BIBLIOTECA CEI -SI
Bibliotecario/ria Ejecutivo/va
El sistema de cobro de multas es realizado por los siguientes:

a) Biblioteca, est conformado por el bibliotecario/ria, el cual registra los prstamos de libros y
tambin realiza el registro de multas a los estudiantes que no devuelven los libros en el tiempo
establecido para su prstamo.
3
b) CEI-SI, est conformado por el ejecutivo/va y dems personas, est encargada de representar
a los estudiantes en asambleas, llamar a los estudiantes a reuniones, y de acuerdo a eso se realiza
un cobro de multas para que los estudiantes puedan participar de las actividades establecidas, las
multas son implantadas en reuniones para su aprobacin y el secretario/ria a cargo realiza el
registro de las multas a los estudiantes que incumplan las normas y/o actividades del centro.
Todo el registro de las multas est centralizado en un solo sistema el cual se cobra al momento de
las inscripciones de los estudiantes.
3. FORMULACION DEL PROBLEMA

Por qu el cobro de multas en biblioteca y CEI de la carrera de ingeniera de sistemas no es eficiente y
genera registros errneos de multas de los estudiantes generando demoras en los pagos de dichas multas?
3.1.DESCRIPCION DE SITUACIONES PROBLEMATICAS

Ante la creciente poblacin y tecnologas emergentes, la Biblioteca y Centro de
Estudiantes se tiene la necesidad de adquirir tecnologas para el mejoramiento del sistema de
cobro de multas y a la vez sus procedimientos, con el fin de adaptarse a una sociedad cambiante
y de garantizar un eficaz funcionamiento.
No contando con una adecuada tecnologa, demuestra lo ineficaz del sistema en el cobro de
multas, ocasionando desorganizacin, lentitud en los registros de las multas en el sistema, registro
de multas errneas hacia los estudiantes, demoras en el pago de las multas al momento de
inscribirse ya que se solicita la firma de las tres direcciones para su aprobacin, lo que ocasiona
un malestar por parte de los estudiantes.
Por estas razones es necesario implementar un sistema automatizado que evite los errores en el
registro de las multas y las prdidas de ellas, agilizando el proceso en la recoleccin de firmas por
parte de los estudiantes para su posterior inscripcin en la Facultad Nacional de Ingeniera.
3.2.PLANTEAMIENTO DEL PROBLEMA

Cmo mejorar el proceso de registro y cobro de multas hacia los estudiantes que incumplan las
normas y reglas establecidas y las reglas por parte de la carrera de Ingeniera de Sistemas
Informtica?
Cmo tener reportes de recaudaciones para la toma de decisiones?
4
4. PLANTEAMIENTO DEL OBJETIVOS

4.1.OBJETIVO GENERAL
Desarrollar e implementar una aplicacin web para automatizar los procesos de consulta, los
procesos de registro y los procesos de impresin de Recibo de cobro de multas los cuales sern
ms confiables.
4.2.OBJETIVOS ESPECIFICOS
Para cumplir el propsito se debe:
- Crear una base de datos la cual sea segura y confiable para todos
- Agilizar los procesos de consulta para visualizacin de la informacin
- Mejorar el proceso de cobro de multas de la biblioteca y CEI para
- Hacer que los estudiantes vean las deudas que tienen con detalle
- Entregar recibos de las multas cobradas para la mayor seguridad de los estudiantes
5. DEFINICION DEL AMBITO DEL SOFTWARE
5.1.PRINCIPALES FUNCIONES Y RENDIMIENTO
REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales que debe cumplir el Sistema, junto con su descripcin, son los
siguientes:
REFERENCIA FUNCIN
R1 El usuario debe poder gestionar usuario (gestionar Usuario)
R2 El usuario debe tener acceso al sistema mediante contrasea (Validar Usuario)
R3 El Sistema debe permitir ver multa (Ver Multa)
R4 El sistema debe permitir cobrar multa Biblioteca (cobrar multa biblioteca)
R5 El sistema debe permitir cobrar multa CEI (cobrar multa CEI)
R6 El sistema debe permitir al Ejecutivo del CEI registrar actividades
(Registrar actividades)
R7 El sistema debe permitir al Ejecutivo del CEI registrar multas (Registrar Multas)
R8 El sistema debe permitir Al director de carrera ver reportes de deudores de

biblioteca actividades (ver reportes)
R9 El sistema debe permitir ver recaudaciones de multa (ver recaudaciones)

R10 El sistema debe permitir imprimir recibos (imprimir recibo)
R11 El sistema debe permitir imprimir reportes (imprimir reportes)
5
REQUERIMIENTOS NO FUNCIONALES
REFERENCIA ATRIBUTO DETALLE

El sistema debe presentar una interfaz de fcil
A1 SENCILLEZ comprensin para su manejo.
El software tendr distintos niveles de accesos:

Administrador tendrn acceso a todas las
reas.
A2 SEGURIDAD Bibliotecario ellos tendrn acceso
restringido a ciertas reas.
Estudiantes solo accedern al sistema para
verificar sus deudas.
El software debe ser amigable, robusto a la vez
A3 PORTABILIDAD liviano.
El software debe ser manejable y adaptable al

A4 ADAPTABILIDAD cambio de versiones de Windows. Adems
telefona
5.2.UNIVERSO DE INFORMACION
El registro de Multas tanto de la Biblioteca como de CEI-SI tiene una relacin directa con los
Estudiantes y Docentes en el proceso de Registro y Cobro de las Multas
5.3.CONTEXTO
La informacin proporcionada por la Biblioteca y el CEI-SI se basa a en algunos formularios y
recibos que emiten dichos establecimientos.
El sistema de informacin que ser una aplicacin web para el Cobro de Multas biblioteca y
centro
de estudiantes de la carrera de ingeniera de sistemas debe tener la capacidad de ser compartido
con todos los usuarios y tener un manejo sencillo para el adecuado funcionamiento del sistema y
as evitar problemas.
En cuanto al rea de administracin se cuenta con un equipo de computacin que rene las
caractersticas mnimas necesarias para el funcionamiento del sistema.
6. ORGANIZACIN DE RECURSOS
6.1.RECURSOS DE SOFTWARE
Arquitectura del sistema de 32 o 64 Bits.
Sistema Operativo Windows 7, Windows 8, 8.1, Windows 10
como lenguaje de programacin PHP.
Navegador internet (internet explore, mozilla Firefox, google chrome)
DBMS (Administrado de base de datos) MySql
6
6.2.RECURSOS DE HARDWARE
Capacidad del procesador Intel core 2 duo 2.66 ghz (o superior)
Memoria RAM 2 gb o superior.
Espacio en disco duro 500 Mb.
Impresora de tinta continua
6.3.ORGANIZACIN DEL PERSONAL
Coordinador del proyecto, anlisis de
Roberto Suarez Flores
requerimientos y diseo.
Jose Luis Llampa Colque Desarrollo y codificacin
Anghelo Ledo Vargas Responsable de pruebas
7. PROCESO DE DESARROLLO
Para el desarrollo del sistema de informacin se utilizar la metodologa RUP-UML basado
en el anlisis orientado a objetos.
Este proceso de desarrollo de software muestra las siguientes caractersticas:
Dirigido por los casos de uso
Centrado en la arquitectura
Iterativo e incremental
Esta metodologa utiliza a UML para definir los modelos del sistema software.
El sistema software en construccin est formado por:
Componentes software
Interconectados a travs de interfaces
7.1. ANALISIS DEL SISTEMA
Sistema de Registro y cobro de multas de Biblioteca y CEI-SI
OBJETIVO
Registrar a los estudiantes y docentes que incumplan las normas y reglas establecidas por la
carrera
de Ingeniera de Sistemas Informtica.
COMPONENTES BSICOS
ENTRADA
Recursos Financieros: el capital sale por parte de las multas que se cobran a los estudiantes y
docentes.
7
Recursos humanos: Director de Carrera, Bibliotecaria/rio, ejecutiva/ivo del CEI-SI, docente,

estudiante
Recursos fsicos: Infraestructura, mobiliario
PROCESO
- Estudiante o docente incumple una norma en la biblioteca o el estudiante no realiza las
actividades del CEI-SI.
- Se registra la multa establecida en las normas.
- El estudiante paga sus multas antes de su inscripcin semestral.
- El cobro de la multa se registra en el sistema.
SALIDA
El estudiante se inscribir luego de pagar sus multas
OTROS COMPONENTES
ENTIDADES
- Infraestructura
- Mobiliario
- Director de Carrera
- Bibliotecaria/rio
- Ejecutivo/iva
- Docente
- Estudiante
ATRIBUTOS
- Infraestructura (cdigo, tamao)
- Mobiliario (codigo, tipo, descripcin)
- Director de Carrera (ci, nombre, apellido, telfono, direccin, estado)
- Bibliotecario/ria (ci, nombre, apellido, telfono, direccin, estado)
- Ejecutivo/iva (ci, nombre, apellido, telfono, estado)
- Docente (ci, nombre, apellido, direccin, telfono, estado, materia)
- Estudiante (ci, nombre, apellido, telfono, direccin, estado, semestre)
ACTIVIDADES
ACTIVIDAD ENDOGENA
Biblioteca
- El estudiante o docente requiere de un prstamo para su casa de una bibliografa de inters.
8
- La bibliotecaria/rio requiere de documentos personales para poder realizar el prstamo

externo
de una bibliografa.
- El estudiante o docente entrega dichos documentos.
- La bibliotecaria/rio registra la bibliografa a prestar ms el tiempo mximo que el estudiante o
docente puede tener el libro.
- Pasado el tiempo la bibliotecaria/rio registra la multa establecida por tener el libro pasado el
lmite de tiempo.
- El estudiante devuelve el libro, pero su multa queda registrada y deber pagar al momento de
su inscripcin.
CEI SI
- El/la ejecutiva/ivo organiza actividades para poder fortalecer la carrera, por tal motivo
convoca
a reuniones.
- En las reuniones el/la ejecutiva/ivo propone cobrar una multa a aquellos estudiantes que no
quieran realizar dichas actividades.
- Luego de la aprobacin se registra la multa que el estudiante deber pagar si no realiza las
actividades
- Cuando el estudiante quiera inscribirse, se le pedir un certificado en donde diga que no debe
ninguna multa en su carrera.
- El estudiante deber pagar su multa y recin podr inscribirse
ACTIVIDAD EXOGENA
- Aparicin de nuevas tecnologas para que el sistema pueda ser ms eficiente al momento de
cobrar las multas.
- Nuevas normas y reglas que se establecen en la carrera de Ingeniera de Sistemas
informtica.
- En la inscripcin el estudiante siempre paga sus multas
ESTADO DEL SISTEMA

El servicio de registro y cobro de multas esta aceptablemente adecuado por algunas limitaciones
que existe ya sea por la forma de cobro, el registro de las multas es directamente puesto al
estudiante que lo incumpla, los estudiantes no realizan las actividades del CEI-SI.
MEDIO AMBIENTE
El medio ambiente en el que se desenvuelve el sistema es en la Carrera de Ingeniera de Sistemas
informtica.
9
TIPO DE SISTEMA
El servicio de registro y cobro de multas es un sistema continuo ya que los cambios tecnolgicos,
la actualizacin de los estudiantes, el ingreso de nuevos estudiantes y las renovaciones de los
ambientes de la biblioteca y el Centro de Estudiantes varan de acuerdo al tiempo en que
transcurre
RETROALIMENTACION
- Evaluar la forma de registro de multas en la biblioteca y en el Centro de Estudiantes, para que
los estudiantes no tengan problemas.
- Realizar mantenimientos peridicos a los equipos de computacin para que el registro y cobro
sea ms eficiente.
- Renovar las infraestructuras de los ambientes en el que se cobra la multa.
- Adquirir tecnologa nueva para que el registro de multas sea eficiente.
ENTROPIA
El servicio de registro y cobro de multas puede desorganizarse por la falta mantenimiento en los
equipos, la infraestructura limitada que presenta (iluminacin), exceso en el cobro de las multas
por parte del Centro de Estudiantes.
NEGENTROPIA
- Mantenimiento de los equipos
- Aportes del IDH para poder adquirir ms libros para poder prestar a varios estudiantes y as
no realizar muchos registros de multas.
- Adquisicin de nuevos equipos para que el registro sea ms eficiente
PRINCIPIOS EN LOS QUE SE BASAN LOS SISTEMAS
SUBSIDIARIEDAD
- Es subsidiario de su medio ambiente la carrera de Ingeniera de Sistemas informtica.
- Es subsidiario de los estudiantes que incumplen las normas.
- Es subsidiario de las reglas y normas que se establecen en la carrera.
INTERACCION
Todos los elementos que componen el servicio de registro y cobro de multas interactan entre s
para que as pueda ser ms eficiente.
DETERMINISMO
- Cuando el estudiante o docente no devuelve una bibliografa prestada, perjudica a los otros
estudiantes o docentes que requieren la misma bibliografa, y ocasiona una desorganizacin.
10
- El registro de multas en exceso provoca que el estudiante no realice el pago de ella.

- El corte de energa elctrica ocasiona el retraso en el cobro de las multas.
EQUIFINALIDAD
- Revisin peridica de los equipos es para mantener estable el servicio de las multas.
- La incorporacin de nuevos equipos es para que el sistema sea mucho ms eficiente. Los
ambientes mantienen a los equipos resguardados.
- Todos los elementos del sistema trabajan sin ninguna diferenciacin ya que todos cumplen un
rol especfico para lograr el mismo objetivo
CARACTERISTICAS DE LOS SISTEMAS
ESTABILIDAD
El sistema de registro de multas se mantiene estable por las normas y reglas que se establecen en
la carrera, por el cobro de las multas a los estudiantes, por la estabilidad de la energa elctrica
que
hay en ella.
ADAPTABILIDAD
El sistema puede adaptarse a las nuevas normas y reglas que sean establecidas en la carrera, en
las
reuniones que el Centro de Estudiantes realiza para poder realizar el cobro de las multas a los
estudiantes y docentes.
EFICIENCIA
Lo servicios de registro y cobro de multas se encuentra medianamente eficiente porque tiene
limitacin en cuanto al registro de las multas, ya que tanto el registro de la biblioteca como del
Centro de Estudiantes no se encuentran sincronizados, lo que provoca que los estudiantes realicen
caminatas de un lado a otro para poder conseguir las firmas necesarias para su inscripcin.
SINERGIA
El objetivo principal se logra con la participacin de todos los elementos del sistema.
ASPECTO SISTEMATICO
El cumplimiento de las normas y reglas establecidas ayudan a mejorar el registro de las multas y
sus respectivos cobros.
COLECTIVISMO
Todos los elementos del sistema trabajan en colectivo, ya que, si no existieran estudiantes,
docentes, bibliotecario/ria, director de carrera, infraestructura, el sistema no funcionara
correctamente.
11
EFECTO DE RUPTURA
El registro y cobro de multas romper sus marcos organizacionales siempre y cuando velen por el
mejoramiento del sistema
AGREGACION/DESAGREGACION
- Se puede implementar un sistema informtico para que el registro de las multas sea
sincronizado entre la biblioteca y el Centro de Estudiantes y as el estudiante no tenga que
caminar demasiado.
- Incorporar nuevos equipos que ayuden a mejorar el registro de multas.
- Adquirir un ambiente propio para el cobro de las multas.
ADICION
Adicionar un ambiente que se encargue del cobro de las multas de los estudiantes al momento del
comienzo de las inscripciones.
AUSENCIA
- La falta de sincronizacin de las multas induce a que el estudiante camine de un lado para
otro
y tarde ms en su inscripcin.
- La falta de mantenimiento e los equipos induce al mal registro de las multas.
- La falta de un ambiente que realice el cobro provoca que no se puedan sincronizar las multas
acumuladas.
INFLUENCIA
El servicio de registro de multas est influenciado por su medio ambiente y por los sistemas que
se encuentran en ella.
NO ESPONTANEIDAD
El registro de las multas se realiza verificando el incumplimiento que el estudiante o docente
haya
cometido.
Todas las actividades que realiza el Centro de estudiantes estn sujetas a normas establecidas. Por
eso el sistema no puede ser espontneo al momento de realizar un registro y cobro de la multa.
DINAMISMO
El registro de multas es dinmico debido a la renovacin constante de los equipos, estudiantes,
mobiliario.
RIGIDEZ
- El sistema reacciona al mnimo cambio que pueda existir en la Carrera:
- Nuevas normas y reglas.
12
- Nuevas actividades a realizar.

- Falta de equipos en el registro
COMPLEJIDAD
El sistema tiene una buena cantidad de elementos y las relaciones que se presentan entre ellas
reflejan una estructura compleja.
TIPO DE SISTEMA
SISTEMA ABIERTO
El sistema de registro y cobro de multas es un sistema abierto porque presenta un intercambio
constante de energa con su medio ambiente, como la lista los nuevos estudiantes, la lista de los
estudiantes antiguos inscritos, dichas lista son pedidas al Centro de Computo de la Facultad.
Por la misma razn su estado terminante no est determinado, siempre puede tender a
desarrollarse
para brindar un servicio eficiente.
7.2. INVESTIGACION PRELIMINAR
Cul es el problema?
El problema del sistema de multas se origina en el momento de que el estudiante quiere ver una
informacin detallada de sus multas pagos los cuales no existen actualmente
Cules son los detalles del problema?
Primero es que el sistema es manual y podran surgir muchas equivocaciones, estos podran ser
errores de registro de los estudiantes, errores en los costos de las multas
Segundo las multas establecidas no son lo suficientemente altos como para incitar al estudiante a
pagar
Qu tan significativo es el problema?
Los problemas mencionados ocasionaran inconformidad a los estudiantes involucrados tambin
haran que la biblioteca deje ser confiable cuando algn estudiante llegue a no devolver a tiempo
algn determinado libro
Cul cree el usuario que es la solucin?
Tener un sistema que automatice estos procesos llegando asa ser transparentes para cualquier
usuario que quiera realizar consultas pagos e impresiones de sus respectivas facturas
Cmo ayudaran los sistemas de informacin?
El sistema agilizar todos los procesos en cuanto a pago de multas y tendr una mejor
organizacin
a prueba de errores y falencias
13
Conoce a alguien que sepa del problema? Puede contactarlo?

Si, conocemos a los estudiantes los cuales estn conscientes de los que paga en la biblioteca
Conocemos a los ingenieros que tambin conocen los problemas que atraviesa y que se pueden
presentar en el futuro si podemos contactarlos.
7.3. METODO ISAC
a) Listar problemas
1. Horarios de atencin limitados
2. Mala organizacin en las polticas de mantenimiento y actualizacin.
3. Colas de espera
4. No existe orden adecuado de los libros
5. No existe una plataforma donde se pueda realizar reserva y control de libros
6. No existe una plataforma web.
7. No existe una documentacin especfica que permita realizar prstamos.
8. No existe informacin sobre libros disponibles.
9. No se tiene libros actualizados.
10. No existen copias suficientes para realizar prstamos.
11. No existen algunas bibliografas que se pide.
b) Listar grupos de inters
Problemas Universitarios Bibliotecario Docente Direccin de Carrera
P1 X X
P2 X X
P3 X X
P4 X X
P5 X X
P6 X
P7 X X
P8 X X
P9 X
P10 X X
P11 X X X
P12 X X
14
c) Analizar Problemas
P1 P2 P7 P8
P3 P4 P9 P10
P1 P12
P5 P6
1
P1. Un 50% de estudiantes manifiestan que los horarios de atencin deberan cubrir horas
fuera
de clases.
P2. EL 80% de los estudiantes afirman que hay una mala organizacin en la atencin, en
mantenimiento de libros y la actualizacin constante de ediciones recientes.
P3. La mala organizacin de la atencin provoca colas de espera.
P4. No se tienen un orden estricto y adecuado de los libros segn el autor o segn las distintas
ediciones que se tiene.
P5. Como no existe una plataforma para realizar reservas no se tiene conocimiento si el libro
an est disponible o no.
P6. Un 70% de estudiantes declaran que una pgina web seria adecuada para que facilite
informacin y reservas.
P7. No se cuenta con un documento especfico que tenga la finalidad para que se realice los
prstamos de los libros.
P8. El estudiante que se apersona a realizar el prstamo de libro no tiene conocimiento sobre
la disponibilidad del libro que requiere.
P9. En libros de algunos autores es necesario contar de su ltima edicin de acuerdo al
contenido que brinda.
P10. En ciertas ocasiones varios estudiantes se apersonan a la biblioteca con el requerimiento
de un libro que pertenece a cierto autor el prestamista solo tiene la capacidad de realizar el
prstamo solo a los primeros estudiantes que solicitaron el prstamo.
15
P11. En muchas ocasiones el docente pide bibliografas para realizar el seguimiento de las
materias, pero muchas de ellas no estn disponibles en la biblioteca.
d) Hacer modelo de actividades
Solicita prstamo
Proporciona Exige documentos
Docente bibliografa Universitario Bibliotecaria

Presenta documento
Realiza Prstamo
Direccin de carrea
e) Anlisis de metas
G1. Mantener una organizacin mejorada con mantenimientos adecuados y actualizaciones
consecutivas y proporcionar ms copias de los libros.
G2. Extender el horario de atencin para poder aprovechar el servicio que brinda a la
formacin la biblioteca.
G3. Mejorar el sistema para que sea implementando una plataforma web que brinde libros
digitales como tambin la reserva y estado de libros.
G4. Extender una documentacin que facilite el prstamo de libros.
Problemas G1 G2 G3 G4
P1 X
P2 X X
P3 X X
P4 X X
P5 X
P6 X
P7 X
P8 X
P9 X
P10 X
P11 X
P12 X
16
f) Definir necesidades de cambio

- Mantener organizada y realizar mantenimientos consecutivos incluyendo actualizaciones
con
nuevas ediciones de libros.
Problemas P2, P3, P4, P9, P10, P11 Objetivos G1, G3
- Aprobar la extensin de horario para aprovechar el servicio que brinda la biblioteca.
Problemas P1
Objetivos G2
- Desarrollar e implementar una plataforma web que brinde libros digitales como tambin la
reserva y estado de libros.
Problemas P2, P3, P4, P5, P6, P8, P12 Objetivos G3, G1
- Extender un documento que permita realizar prstamos de libros.
Problemas P7
Objetivos G4
g) Generar alternativas de cambio
A1. Organizar de una mejor manera la atencin y realizar mantenimientos frecuentes y
actualizaciones consecutivas.
A2. Se atender ms horas de lo establecido para brindar atencin a la mayora de los
estudiantes.
A3. Desarrollar e implantar una plataforma web que brinde informacin sobre el estado de
libros, que permita realizar reservas y brindar libros digitales.
A4. Extender un documento que permita realizar prstamos de libros.
h) Especificar sistemas deseados
1. Operacin cero
2. A1+A2 Organizar de una manera eficiente realizando mantenimientos consecutivos y
actualizaciones frecuentes extendiendo horarios de atencin.
3. A3+A4 Se implantar una pgina web para obtener estado y disponibilidad de libros,
realizar
reservas y proporcionar un documento que permita realizar prestamos que tambin contenga
el usuario y contrasea para autentificarse en la plataforma web.
17
i) Evaluar las alternativas

Problemas Universitarios Bibliotecario Docente Direccin de Carrera
P1 O O
P2 O O
P3 O O
P4 O O
P5 O O
P6 O
P7 O O
P8 O O
P9 O
P10 O O
j) Elegir una alternativa

1. A1+A2
2. A3+A4
7.4. MODELO DEL NEGOCIO
DESCRIPCIN DEL NEGOCIO

La Biblioteca y Centro de Estudiantes de la carrera de Ingeniera de Sistemas Informtica
pertenecientes a la Facultad Nacional de Ingeniera, brindan sus servicios para mejorar la
enseanza y aprendizaje de los estudiantes.
Inicio sus actividades al momento de la creacin de la carrera de Ingeniera de Sistemas
Informtica en la Facultad Nacional de Ingeniera perteneciente a la Universidad Tcnica de
Oruro de la ciudad de Oruro, las cuales se establecieron normas que su correcto funcionamiento,
en caso de incumplir dichas normas se sancionara con una multa ya establecida el cual se
registrara en un sistema informtico para poder realizar su cobro respectivo.
La Biblioteca realiza el prstamo de bibliografa a todos los estudiantes que lo requieran,
tambin
a los docentes, el prstamo se lo realiza de dos formas: en sala o domicilio, lo que implica que el
estudiante pueda llevar la bibliografa a su casa.
El prstamo a domicilio se lo realiza entregando documentos y registrando la fecha de
devolucin,
si el estudiante o docente incumple con la fecha de devolucin, entonces se lo registra una multa
por el tiempo extra que use la bibliografa y no podr acceder a otro prstamo de bibliografa sin
antes devolver lo prestado anteriormente.
18
El Centro de Estudiantes de la carrera de Sistema-Informtica realiza actividades que mantengan

a los estudiantes activos, estas actividades son para poder representar a la carrera y son
aprobados
en una asamblea previamente convocada, si un estudiante no participa en todas las actividades,
entonces se le registra una multa establecida en asamblea.
Los estudiantes que tengan multas deben pagarlas en las respectivas cajas al momento de su
inscripcin, ya que todas las multas son registradas en el sistema de la Facultad Nacional de
Ingeniera.
7.4.1. MODELO DEL NEGOCIO (DIAGRAMA DE CASOS DE USO DEL NEGOCIO)
Gestionar usuario
Ver Recaudacin
Director de carrera
Ver dudas
Ver reportes
Bibliotecaria
pagar deuda Ejecutiv
Estudiante o
Imprimir
cobrar deuda
Encargado
7.4.2. MODELO DE ANLISIS DE NEGOCIO

Gestionar usuario. - Todos los usuarios podrn ingresar al sistema con una contrasea
Ver deudas. - Los estudiantes podrn ver las deudas que tienen y cuanto deben ms detalle,
as
tambin La bibliotecario y ejecutivo podrn ver las deudas de los estudiantes segn su nombre
Pagar deudas. - el sistema permitir pagar deuda junto con la bibliotecaria
Cobrar deudas. - La bibliotecaria y el ejecutivo podrn realizar el cobro de multas
Ver recaudacin. - El director de carrera puede ver las recaudaciones de la biblioteca y el
ejecutivo del CEI-SI y disponer para actividades de cada sitio
Ver reportes. - Muestra reporte de deudores y estadsticas
Imprimir. - imprime recibo y reportes
19
7.4.3. ESPECIFICACIN DE ACTORES DEL NEGOCIO

ACTOR Estudiante
CASO DE USO Gestionar usuario
Ver deudas
Pagar deudas
DESCRIPCION Es el deudor, es el que paga su multa y pude consultar cuanto
debe o un mejor caso si no debe
ACTOR Bibliotecaria
Ver deudas
Cobrar deudas
Ver reportes
Imprimir
DESCRIPCION Es el encargado de cobrar las multas de la biblioteca e
imprimir un recibo adems informa de los deudores
ACTOR Ejecutivo
Ver deudas
Cobrar deudas
Ver reportes
Imprimir
DESCRIPCION Es el encargado de de cobrar las multas del CEI-SI e
imprimir un recibo ademas informa de los dedores
ACTOR Director de carrera

Ver recaudacin
Ver reportes
Imprimir
DESCRIPCION Es el que toma las deciciones segn los reportes e imprime
dichos reportes ademas dispone de las recaudaciones de la
biblioteca
20
7.5. DIAGRAMA DE CASOS DE USO DEL SISTEMA
Ver recaudaciones biblioteca

Director de carrera
Ver reportes biblioteca
Estudiante
<<extend
>>
gestionar Uusario imprimir reportes
<<include
>>
<<include
>> Ver multa
Usuario Validar Usuario
Ver multa Biblioteca
Ver MUlta CEI

Bibliotecaria <<include
>>
<<include
>>
Ver Reportes CEI
cobrar multa Biblioteca
Ejecutivo
<<extend
>> Cobrar multa CEI
ver recaudaciones CEI
<<extend
>>
<<extend
>>
21
7.6. ESPECIFICACIN DE CASOS DE USO

Nombre de caso validar
de uso usuario
Descripcin El caso de uso validar usuario permitir crear usuarios
Eliminar y modificar sus contraseas
Actores Est relacionado con los actores Usuario (Director de carrera,
Bibliotecaria, ejecutivo y Estudiante)
Precondiciones Se crea una contrasea
Flujo normal Se crea, se modifica y se elimina usuario
Sub flujos Modificar Usuario
Postcondiciones Validar usuario
Excepciones El director de carrera ser administrador general con
contrasea nica
Nombre de caso Validar

de uso usuario
Descripcin Todos los usuarios tendrn que ingresar con contrasea para
entrar al sistema y hay cuatro tipos de usuarios con distintas
opciones habilitadas
Actores Est relacionado con los actores Usuario (Director de carrera,

Bibliotecaria, ejecutivo y Estudiante)
Precondiciones Selecciona si es (Estudiante, bibliotecaria, Ejecutivo o
Director de carrera) y ingresa su contrasea
Flujo normal Al validar usuario se entra al sistema segn el usuario que
ingreso
Sub flujos Entrar al sistema

Postcondiciones Haber creado una contrasea
Excepciones Los estudiantes no crearn cuentas solo podrn modificar sus
contraseas
22
Nombre de caso Ver

de uso multa
Descripcin Los usuarios del sistema podrn ver multas de los estudiante
en cada respectiva rea (CEI y biblioteca)
Actores Est relacionado con los actores Usuario( Bibliotecaria,

ejecutivo y Estudiante)
Precondiciones Validar usuario

Flujo normal Al ingresar al sistema si es:
- Estudiante vera sus datos y la multa que debe
- Bibliotecaria y Ejecutivo vern lista de deudores y
podrn buscar por nombre
Sub flujos Preguntar por nombre

Postcondiciones Cobrar multa
Excepciones Los estudiantes solo vern sus propias multas,
Bibliotecaria y ejecutivo solo vern multas de sus reas
Nombre de caso Cobrar multa

de uso biblioteca
Descripcin La bibliotecaria cobrara multas de los estudiantes que sern
borradas dichas multas
Actores Est relacionado con los actores Usuario( Bibliotecaria y

Estudiante)
Precondiciones La bibliotecaria deber validar usuaria como bibliotecaria
Flujo normal Validar usuario (Bibliotecaria), buscar estudiante y cobrar
Sub flujos Luego de cobrar multa se imprime recibo de cobro
Postcondiciones Volver a cobrar multas de otros estudiantes
Excepciones Ninguna
23
Nombre de caso de Cobrar multa CEI

uso
Descripcin El ejecutivo cobrara multas de los estudiantes que sern
borradas dichas multas
Actores Est relacionado con los actores Usuario( Ejecutivo y

Estudiante)
Precondiciones La Ejecutivo deber validar usuaria como Ejecutivo
Flujo normal Validar usuario (ejecutivo), buscar estudiante y cobrar
Sub flujos Luego de cobrar multa se imprime recibo de cobro
Postcondiciones Volver a cobrar multas de otros estudiantes
Excepciones Ninguna
Nombre de caso Imprimir

de uso recibo
Descripcin La bibliotecaria y El ejecutivo al cobrar una multa tendr
que imprimir un recibo de la multa cobrada, que tendr
descripcin del pago
Actores
Precondiciones La bibliotecaria debe primero haber cobrado la multa de un
estudiante
Flujo normal Validar usuario (Bibliotecaria o Ejecutivo), ver multa, cobrar

multa e imprimir Esta relacionado con los actores Usuario (
Bibliotecaria, ejecutivo y Estudiante) recibo
Sub flujos Ninguno
Postcondiciones Volver a imprimir recibos de cada cobro
Excepciones Ninguna
24
Nombre de caso Registrar

de uso actividades
Descripcin El ejecutivo creara actividades las cuales los estudiantes que
no asistan a dichas actividades tendrn muta
Actores Ejecutivo
Precondiciones Validar usuario como Ejecutivo
Flujo normal EL ejecutivo crea una actividad y se registra la multa
Sub flujos Registrar multa para su posterior cobro
Postcondiciones Se beben registrar las multas de toda actividad
Excepciones Actividades no obligatorias no se cobrarn multas
Nombre de caso Registrar multa

de uso
Descripcin Despus de las actividades realizadas por el CEI
Se registrar la multa asignada a los estudiantes que no
asistieron a dicha actividad
Actores Ejecutivo
Precondiciones Haberse realizado una actividad del CEI
Flujo normal Ejecutivo validar usuario, registrar actividad y registrar multa
Sub flujos Validar usuario ejecutivo, Ver multa y Cobrar multa

Postcondiciones Poder cobrar multas registradas
Excepciones Ninguna
25
Nombre de caso Ver reporte CEI

de uso
Descripcin El ejecutivo vera reportes de los estudiantes deudores con una
consulta podr ver sus datos y descripcin
Actores Ejecutivo
Precondiciones Validar usuario como Ejecutivo
Flujo normal Validar usuario como ejecutivo y ver reporte
Sub flujos Ninguno
Postcondiciones Actualizar reportes con cada actividad realizada
Excepciones Solo vera reportes de deudores
Nombre de caso Ver reporte

de uso Biblioteca
Descripcin El director de carrera vera reportes de los estudiantes deudores
de la biblioteca con sus datos personales
Actores Director de carrera

Precondiciones Validar usuario como Director de carrera
Flujo normal Validar usuario, ver reporte
Sub flujos Ver reporte biblioteca y luego imprimir reporte
Postcondiciones Ver reporte de los deudores y que se actualice con cada cobro
Excepciones Ninguna
26
Nombre de caso Imprimir

de uso reporte
Descripcin El Director de carrera al ver los reportes debe ser capaz de
imprimir el reporte seleccionado
Precondiciones Validar usuario como director de carrera y ver reportes
Flujo normal Validar usuario como director de carrera, ver reportes e
imprimir reporte
Sub flujos Ninguno
Postcondiciones Imprimir los reportes requeridos
Excepciones No se imprimir los reportes que no estn autorizados por el
director
Nombre de caso Ver recaudaciones CEI

de uso
Descripcin El Ejecutivo tendr acceso a las recaudaciones de las multas
cobradas por el CEI y dispondr del monto para realizar
actividades
Actores Ejecutivo
Precondiciones Haber multas cobradas
Flujo normal Validar usuario como ejecutivo y ver recaudaciones
Sub flujos Ninguna
Postcondiciones Volver a ver recaudaciones
Excepciones Ninguna
Nombre de caso Ver recaudaciones

de uso Biblioteca
Descripcin El Director podr ver las recaudaciones de las multas de la
biblioteca y disponer el monto para realizar mantenimiento
o compra de artculos para la biblioteca
Precondiciones La bibliotecaria tiene que haber cobrado multas
Flujo normal Valida usuario como director de carrera, ver recaudaciones
Sub flujos Ninguno
Postcondiciones En cada cobro sumarse el monto de recaudaciones
Excepciones Ninguna
27
7.7. DIAGRAMA DE CLASES
7.8. DESCRIPCION DE LAS CLASES
Nombre de la clase Descripcin

estudiante Es el que paga la multa y que pregunta
cunto debe
bibliotecaria Es la encargada de cobrar solo las
deudas de la biblioteca
28

ejecutivo Esta clase es el que cobra las multas
que se deben al centro de estudiantes
multa Esta clase es el que da la fecha de
inicio de multa y finalizacin de multa
reporte En esta clase es donde se almacena el
reporte de multas y deudores
pago Es donde el estudiante paga al
administrador la multa que debe
Director de carrera Es el que ve reportes y puede ver
recaudaciones para tomar decisiones
7.9. DIAGRAMA DE ANALISIS CLASES SEGN CASOS DE USO
CONTROL
ACTUALIZAR
BdD
ADMINISTRADOR
UNIVERCITARIO
BORRAR
ELIMINAR
29
7.10. DIAGRAMAS DE SECUENCIA

1) Cobrar multa biblioteca
30
2) Cobrear multa CEI
31
3) Gestionar Usuario crear
32
4) Gestionar Usuario eliminar
33
5) Gestionar Usuario Modificar
34
6) Validar Usuario
: Usuario : Interfaz_Usuario : : ManejadorPrincipal : Interfaz_BaseDatos : Base_Datos

ManejadorRegistroUsuario
1 . Desplegar PantallaPrincipal(index.php )
2. Iniciar Sesion
3. Iniciar Sesion
4. Desplegar Pantalla Login
5. ok
6. ok
7. Validar Usuario
8. Validar Usuario
9. Ejecutar consulta
10 . ok
11 . ok
12 . ok
35
7) Imprimir Recibo Biblioteca
36
8) Imprimir recibo CEI
37
9) Imprimir reporte Biblioteca
38
10) Imprimir reporte CEI
39
11) Registrar Multa
40
12) Ver multas
41
13) Ver multas biblioteca
42
14) Ver multas CEI
43
15) Ver reportes biblioteca
44
16) Ver reportes CEI
45
17) Ver recaudaciones Biblioteca
46
18) Ver recaudaciones CEI
47
7.11. DISEO DE INTERFACES

Pantalla Principal
Pantalla Iniciar Sesin
48
Ver Multas CEI-SI
Ver Multas Biblioteca
49
Ver Multas
Registrar Multa CEI-SI
50
Cobrar Multa CEI-SI
Imprimir Recibo CEI-SI
51
Registrar Actividad CEI-SI
Ver Perfil
52
Ver Recaudaciones
Imprimir Reporte
53
Cobrar Multa Biblioteca
Imprimir Recibo
54
7.12. MODELO DE BASE DE DATOS

7.12.1. DIAGRAMA DE CLASES PERSISTENTES
7.12.2. MODELO RELACIONAL
55
7.12.3. DICCIONARIO DE DATOS

Usuario
Columna Tipo Nulo

ci (Primary) varchar(35) No
nombre varchar(35) No
apellido varchar(35) No
direccion varchar(55) No
sexo varchar(10) No
Estudiante
Columna Tipo Nulo
ci (FK) varchar(35) No
usuario varchar(35) No
password varchar(35) No
Director
Columna Tipo Nulo
Bibliotecario
Columna Tipo Nulo
Ejecutivo
Columna Tipo Nulo
Multa
Columna Tipo Nulo
codmulta (Primary) int No
fecha date No
total varchar(35) No
lugar varchar(5) No
estado varchar(10) No
56
Multabiblio
Columna Tipo Nulo
codmulta (FK) int No
fecha date No
descripcin varchar(35) No
monto varchar(5) No
estado varchar(10) No
Actividad
Columna Tipo Nulo
id (Primary) int No
nombre varchar(35) No
montomulta varchar(35) No
fecha date No
Multacei
Columna Tipo Nulo
id (FK) int No
codmulta (FK) varchar(35) No
fecha date No
57
7.13. DIAGRAMA DE DESPLIEGUE
GESTOR DE B A SE DE
D A TOS
SERVIDOR SQL
7.14. DIAGRAMA DE COMPONENTES
58
8. ESTIMACION DEL PROYECTO DE SOFTWARE

El software est dirigido a la compra y venta de productos de una tienda de Celulares.
ESTIMACIN MEDIANTE PUNTOS DE CASOS DE USO
DIAGRAMA DE CASOS DE USO
Ver recaudaciones biblioteca

Director de carrera
Ver reportes biblioteca
Estudiante
<<extend>>
ges tionar Uus ario im prim ir reportes
<<include>>
<<include>> Ver multa

Us uario Validar Usuario
Ver multa Biblioteca
Ver MUlta CEI

Bibliotecaria <<include>>
<<include>>
Ver Reportes CEI
cobrar multa Biblioteca
Ejecutivo
<<extend>>
ver recaudaciones CEI Cobrar multa CEI
<<extend>
<<extend>> >
Registrar Actividades Registrar Multas
59
Casos de uso
REFERENCIA DESCRIPCION CASO DE USO
CU1 El usuario debe tener acceso al sistema mediante contrasea (Validar Usuario)
CU2 El Sistema debe permitir ver multa (Ver Multa)
CU3 El sistema debe permitir cobrar multa Biblioteca (cobrar multa biblioteca)
CU4 El sistema debe permitir cobrar multa CEI (cobrar multa CEI)
CU5 El sistema debe permitir al Ejecutivo del CEI registrar actividades

(Registrar actividades)
CU6 El sistema debe permitir al Ejecutivo del CEI registrar multas (Registrar Multas)
CU7 El sistema debe permitir Al director de carrera ver reportes de deudores de
biblioteca actividades (ver reportes)
CU8 El sistema debe permitir ver recaudaciones de multa (ver recaudaciones)
CU9 El sistema debe permitir imprimir recibos (imprimir recibo)
CU10 El sistema debe permitir imprimir reportes (imprimir reportes)
Actores
ACTOR Estudiante
DESCRIPCION Es el deudor, es el que paga su multa y pude consultar cuanto debe

o un mejor caso si no debe
ACTOR Bibliotecaria
DESCRIPCION Es el encargado de cobrar las multas de la biblioteca e imprimir un

recibo adems informa de los deudores
ACTOR Ejecutivo
DESCRIPCION Es el encargado de cobrar las multas del CEI-SI e imprimir un

recibo adems informa de los deudores
ACTOR Director de carrera
DESCRIPCION Es el que toma las decisiones segn los reportes e imprime dichos
reportes adems dispone de las recaudaciones de la biblioteca
60
Clculo puntos de Casos de uso sin ajustar UUCP

UUCP = UAW + UUCW
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
Factor de Peso de los Actores sin ajustar UAW
Tipo de actor Descripcin Factor de Peso

Simple Otro sistema que interacta con el sistema a desarrollar 1
mediante una interface de programacin (API Application
Programming Interface)
Medio Otro sistema que interacta con el sistema a desarrollar 2
mediante un protocolo o una interfaz basada en texto
Complejo Una persona que interacta con el sistema mediante una 3
interface grafica
Actor Tipo Factor peso

Estudiante Complejo 3
Bibliotecaria Complejo 3
Ejecutivo Complejo 3
Director de Carrera complejo 3
UAW = 4*3= 12
Factor de Peso de casos de uso sin ajustar UUCW

Tipo de caso Descripcin Factor de
de uso Peso
Simple El caso de uso contiene de 1 a 3 transacciones. 5
Medio El caso de uso contiene de 4 a 7 transacciones. 10
Complejo El caso de uso contiene 8 o ms transacciones. 15
61
Caso de uso Tipo Factor Peso

CU 1 Simple 5
CU 2 Simple 5
CU 3 Simple 5
CU 4 Simple 5
CU 5 Simple 5
CU 6 Simple 5
CU 7 Simple 5
CU 8 Simple 5
CU 9 Medio 10
CU 10 Medio 10
UUCW =8*5+2*10=60
UUCP = UAW + UUCW
UUCP = 12 + 60 = 72
Clculo puntos de Casos de uso ajustados UCP

UCP = UUCP * TCF * EF
UCP = Puntos de Casos de uso ajustados
UUCP = Puntos de casos de uso sin ajustar
TCF = Factor de complejidad tcnica
EF = Factor del ambiente
Factor de Complejidad Tcnica TCF
Nmero de
Descripcin Peso Valor Factor Comentario
factor
El sistema es Web, por lo que posee nivel de
T1 Sistema Distribuido 2 0 0
distribucin (adems es acadmico)
El tiempo de respuesta respalda los objetivos que
T2 Tiempo de respuesta 1 3 3 se persiguen con el proyecto realizado, por lo que
es el adecuado.
Eficiencia por el Algunos roles necesitan estar relacionados con el
T3 1 3 3
usuario sistema para su mejor funcionamiento.
62
El sistema no posee clculos complejos, aunque
Proceso interno proporciona una serie de datos que necesitan un
T4 1 3 3
complejo nivel medio de conocimiento para lograr su
correcta comprensin.
No es esencial hacer reusabilidad del cdigo, a
T5 Reusabilidad 1 2 2 pesar de que este ser orientado a objetos y podr
ser usado por sistemas similares.
Facilidad de Por ser un sistema Web la complejidad de
T6 0,5 1 0,5
instalacin instalacin es mnima.
El sistema debe ser fcil de usar para cualquier

T7 Facilidad de uso 0,5 5 2,5
tipo de usuario.
El sistema se encuentra diseado para que sea

usado en cualquier dispositivo, adems como est
T8 Portabilidad 2 5 10
desarrollado web puede ser publicado en
cualquier plataforma.
El sistema encuentra estructurada para que los
T9 Facilidad de cambio 1 5 5 cambios realizados afecten lo menos posible las
funcionalidades del sistema.
T10 Concurrencia 1 5 5 La concurrencia es tratada con suma importancia.
La seguridad del sistema es un tema bastante
Objetivos especiales controlado, ya que el sistema slo permite que un
T11 1 5 5
de seguridad usuario realice las funcionalidades
correspondientes a su rol dentro del sitio.
Acceso directo a La aplicacin es accesible a cualquier usuario que
T12 1 2 2
terceras partes este autorizado.
No se hace necesario el entrenamiento de los
Facilidades
usuarios finales, debido a la facilidad de uso que
especiales de
T13 1 1 1 presenta el sistema, pero se debe incluir un
entrenamiento a
manual de usuario para garantizar la correcta
usuarios finales
usabilidad de dicho sistema.
Total
42
Factor
TCF = 0,6+0,01*FACTOR TOTAL

TCF = 0,6+0,01*42 = 1,02
63
Factor de Ambiente EF
Nmero
Descripcin Peso Valor Factor Comentario
del factor
Familiaridad con el Se est familiarizado con el modelo del
E1 modelo del proyecto 1,5 4 6 proyecto, pero la experiencia en el modelado
usado. es un poco ms que media.
No es una aplicacin que requiera de mucha

Experiencia en la experiencia, pero se necesita de un equipo
E2 0,5 4 2
aplicacin capacitado y de conocimientos suficientes
para garantizar su correcto funcionamiento.
Se considera cierto grado de experiencia en la

programacin orientada a objetos (OO),
E3 Experiencia OO. 1 4 4
debido a que esta es la que se ha estudiado y
trabajado.
Existe analista lder, los analistas que
Capacidad del analista
E4 0,5 4 2 integran el equipo de trabajo poseen
lder.
capacidad arriba del promedio.
E5 Motivacin. 1 5 5 La motivacin es alta
Aunque el sistema se encuentra sujeto a
Estabilidad de los cambios, el mismo brinda las funcionalidades
E6 2 4 8
requerimientos. esenciales que dan cumplimiento a los
objetivos que iniciaron su realizacin.
Personal media ninguno de los integrantes podr cumplir
E7 -1 0 0
jornada. media jornada
Como el lenguaje empleado fue PHP y este
Dificultad en lenguaje
E8 -1 3 -3 ofrece grandes facilidades y ventajas, se
de programacin.
considera una dificultad medio su empleo.
Total 24
EF = 1,4 0,03 *
EF = 1,4 0,03*24= 0,68
UCP = UUCP * TCF * EF
UCP = 72 * 1,02 * 0,68
UCP = 49,9392
64
Estimacin del esfuerzo

Factor Filtro Filtro
De E1 a E6 Factor < 3 0
De E7 a E8 Factor > 3 1
Para evaluar el resultado o la cantidad total segn la siguiente tabla:

Horas-Persona (CF) Descripcin
20 Si el valor es<=2 1
28 Si el valor es<=4 0
36 Si el valor es>=5 0
E = esfuerzo
E = 20 horas-hombre por cada UCP
E = UCP * E
E = 49,9392 * 20
E = 998.784 [horas-hombre]
Estimacin del tiempo
Tiempo=998.784 (hr-h)/ 3 (h)
Tiempo=332.928 hr
Estimacin del costo
Costo total = 998.784 hr-h *20 $/hr-h
Costo total = 19975.68 $
Esfuerzo total
Actividad Porcentaje Horas Hombre
Anlisis 10% 249.696
Diseo 20% 499.392
Programacin 40% 998.784
Pruebas 15% 374,544
Sobrecarga 15% 374.544
Total 100% 2496.96
65
9. PLANIFICACION
66
9.1. Asignacin de tareas.
Todos los del equipo reunidos trabajaran juntos
Realizado por Estudiante Anghelo Ledo
Realizado por Estudiante Jos Luis Llampa
Realizado por Estudiante Roberto Suarez
Realizado y revisado por todos los integrantes del grupo o

combinacin de dos
9.2. Conclusiones
Fecha inicio 10 de abril de 2017
Fecha finalizacin 2 de junio de 2017
Duracin del proyecto 53 das
10. GESTION DE RIESGOS

10.1. IDENTIFICACIN DE RIESGOS
Relacionados con el tamao del producto
RIESGO CATEGORIA PROBABILIDAD IMPACTO RMMM
Nmero de cambios de Proyecto 30% Planificacin
requerimientos previstos Marginal
antes y despus de la
entrega de los mdulos
Cantidad de software proyecto 30% Planificacin

reutilizado sea poco Critica
Con el impacto en la organizacin (en este caso de la materia)

No alcanzar la fecha de entrega Proyecto 30% Planificacin
Critica
Que la cantidad y calidad del Equipo 50% Rendimiento
software entregando no sea lo Critica
suficiente
Retraso de la entrega del Equipo 20% Rendimiento y

proyecto planificacin
critica
67
Con el tipo de cliente

El usuario no tiene Proyecto 80% Rendimiento y
experiencia en el coste
manejo de aplicaciones Critica
web
El usuario no estar Equipo 70% Planificacin

dispuesto a relacionarse Marginal
con el equipo de
desarrollo
Con la definicin del proceso de produccin

NO existen mecanismos Proyecto 20% Planificacin
para controlar los Marginal
cambios en los
requerimientos que
tienen impacto en el
software
Con el entorno de desarrollo

No exista ayuda en Proyecto 80% Planificacin
internet y documentacin Critica
disponible
La poca existencia de Entorno de 60% Planificacin

expertos a los cuales desarrollo Critica
solicitar ayuda acerca de
las herramientas
tienen formacin todos Equipo 70% Rendimiento y

los miembros del equipo Mantenibilidad
de desarrollo Critica
Estn todas las Equipo 20% Planificacin y

herramientas de Rendimiento
desarrollo integradas Marginal
La existencia de Proyecto 20% Planificacin

generadores de cdigo Marginal
apropiados para la
aplicacin
68
Con la tecnologa
Se trata de una Proyecto 10% Mantenibilidad
tecnologa nueva Marginal
para la organizacin
Existen dudas de que Proyecto 20% Coste y

el proyecto sea mantenibilidad
realizable Marginal
Con la experiencia y tamao del equipo

Tienen los miembros las Proyecto 50% Planificacin
tcnicas apropiadas Critica
Est el personal no este Proyecto 10% Planificacin

comprometido en toda la Critica
duracin del proyecto
Existencia de parte del Equipo 70% Planificacin

grupo dedicado Critica
solamente en parte al
proyecto
Abandono de un Equipo 50% Planificacin

integrante Catastrfica
Que un integrante no Proyecto 50% Planificacin

acabe su parte del Marginal
proyecto a realizar
Falta de un integrante a Proyecto 50% Planificacin

las reuniones del equipo Critica
69
10.2. Ordenacin y filtrado (segn la probabilidad de ocurrencia)

El usuario no tiene Rendimiento y
experiencia en el manejo de Proyecto 80% coste Critica
aplicaciones web
No exista ayuda en internet y Planificacin
Proyecto 80%
documentacin disponible Critica
El usuario no estar Planificacin
dispuesto a relacionarse con Equipo 70% Marginal
el equipo de desarrollo
tienen formacin todos los Rendimiento y
miembros del equipo de Equipo 70% Mantenibilidad
desarrollo Critica
Existencia de parte del grupo Planificacin
dedicado solamente en parte Equipo 70% Critica
al proyecto
La poca existencia de Planificacin
expertos a los cuales solicitar Entorno de Critica
60%
ayuda acerca de las desarrollo
herramientas
Que la cantidad y calidad del Rendimiento
software entregando no sea Equipo 50% Critica
lo suficiente
Tienen los miembros las Planificacin
Proyecto 50%
tcnicas apropiadas Critica
Que un integrante no acabe Planificacin
su parte del proyecto a Proyecto 50% Marginal
realizar
Falta de un integrante a las Planificacin
Proyecto 50%
reuniones del equipo Critica
Abandono de un integrante Planificacin
Equipo 50%
Catastrfica
Nmero de cambios de Planificacin
requerimientos previstos Marginal
Proyecto 30%
antes y despus de la entrega
de los mdulos
Cantidad de software Planificacin
proyecto 30%
reutilizado sea poco Critica
No alcanzar la fecha de Planificacin
Proyecto 30%
entrega Critica
Retraso de la entrega del Rendimiento y
proyecto Equipo 20% planificacin
critica
NO existen mecanismos Planificacin
para controlar los cambios Proyecto 20% Marginal
en los requerimientos que
70
tienen impacto en el
software
Estn todas las herramientas Planificacin y
de desarrollo integradas Equipo 20% Rendimiento
Marginal
La existencia de generadores Planificacin
de cdigo apropiados para la Proyecto 20% Marginal
aplicacin
Existen dudas de que el Coste y
proyecto sea realizable Proyecto 20% mantenibilidad
Marginal
Se trata de una tecnologa Mantenibilidad
Proyecto 10%
nueva para la organizacin Marginal
Est el personal no este Planificacin
comprometido en toda la Proyecto 10% Critica
duracin del proyecto
10.3. GESTIN, MONITORIZACIN Y MITIGACIN DE RIESGOS (R.M.M.M.)
1. Riesgo El usuario no tiene experiencia en el manejo de aplicaciones web
Evitacin
Estrategia general. - desarrollar la aplicacin web ms interactiva
Pasos para mitigar el riesgo. - Creacin de manuales
Monitorizacin
Factores a monitorizar. - Sistema
Modo de monitorizacin. - pruebas de usuarios sin conocimiento de aplicaciones
web.
Gestin
Plan de contingencias. - Capacitacin de los usuarios, creacin de videos tutoriales
Consideraciones especiales. - la mayora de los usuarios tienen conocimientos de las
aplicaciones web, solo en el caso del bibliotecario se puede presentar el riesgo
2.- Riesgo No exista ayuda en internet y documentacin disponible
Evitacin
Estrategia general. - Recolectar la mayor cantidad de informacin
Pasos para mitigar el riesgo. - Acudir a libros videos interactivos
Monitorizacin
Factores a monitorizar. - sistema y documentacin
Modo de monitorizacin. - revisin peridica de la documentacin y ver si se va de
acuerdo con lo planificado
71
Gestin
Plan de contingencias. - Buscar ayuda de personas que aprobaron la materia con
proyectos similares
Consideraciones especiales. - puede que no encontremos proyectos similares, pero se
pueden ser de mucha ayuda
3.-Riesgo El usuario no estar dispuesto a relacionarse con el equipo de desarrollo
Evitacin
Estrategia general. - forjar una relacin fuerte con el usuario

Pasos para mitigar el riesgo. - Ser amable con el usuario, ser paciente, ser muy
explicativo con lo que se necesita
Monitorizacin
Factores a monitorizar. - planeacin

Modo de monitorizacin. - reunirse con el usuario
Gestin
Plan de contingencias. - realizar encuestas a usuarios de un sistema similar

Consideraciones especiales. - con las encuestas nos aproximamos a las peticiones del
usuario, pero no al total
4.- Riesgo tienen formacin todos los miembros del equipo de desarrollo
Evitacin
Estrategia general. - asistir a clases de docencia como de auxiliatura
Pasos para mitigar el riesgo. - comprometerse con la materia, tomar apuntes de lo
avanzado
Monitorizacin
Factores a monitorizar. - planeacin
Modo de monitorizacin. - verificar con el tiempo si el proyecto va de acuerdo con
lo planeado
Gestin
Plan de contingencias. - Revisar internet para encontrar conocimiento
Consideraciones especiales. - el reviso a internet lleva tiempo y debe hacerse de
manera individual
5.- Riesgo Existencia de parte del grupo dedicado solamente en parte al proyecto
Evitacin
Estrategia general. - Informar a todos del grupo sobre lo que se hace de manera
individual
Pasos para mitigar el riesgo. - Realizar reuniones de grupo, analizar las partes
hechas
individualmente y explicar de manera entendible esas partes.
72
Monitorizacin
Factores a monitorizar. - Planificacin y proyecto
Modo de monitorizacin. - Ver si lo planeado est de acuerdo al tiempo establecido
ver si el proyecto est avanzado o si tenemos algunas dudas de su avance.
Gestin
Plan de contingencias. - Analizar individualmente las partes de los otros miembros
del grupo y dedicarle ms tiempo a ello.
Consideraciones especiales. - El anlisis se debe hacer por lo menos dos semanas
antes de la entrega del proyecto.
6.- Riesgo La poca existencia de expertos a los cuales solicitar ayuda acerca de las
herramientas
Evitacin
Estrategia general. - Practicar herramientas antes de desarrollar el software

Pasos para mitigar el riesgo. - ver apuntes de materias anteriores, buscar tutoriales,
leer manuales.
Monitorizacin
Factores a monitorizar. - entorno de desarrollo

Modo de monitorizacin. - ver las dificultades en desarrollar el software si son con
respecto al entorno de desarrollo
Gestin
Plan de contingencias. - Buscar un experto en el entorno de desarrollo
Consideraciones especiales. - se tiene que buscar de inmediato si se nota desde un
principio dificultades con el entorno de4 desarrollo.
7.- Riesgo Que la cantidad y calidad del software entregando no sea lo suficiente
Evitacin
Estrategia general. - Estar comprometido con el proyecto
Pasos para mitigar el riesgo. - asistir a clases y en las reuniones de grupo revisar
detalladamente los seguimientos del proyecto.
Monitorizacin
Factores a monitorizar. - Equipo
Modo de monitorizacin. - ver si los miembros del equipo asisten a clases y
reuniones
de grupo adems si participan en el desarrollo del proyecto.
Gestin
Plan de contingencias. - mejorar el proyecto para el inicio del siguiente semestre ya
que se podr volver a presentar.
Consideraciones especiales. - Identificar bien los errores de la documentacin y
software para su correccin
73
8.- Riesgo Tienen los miembros las tcnicas apropiadas
Evitacin
Estrategia general. - eleccin del grupo con habilidades para asignar tareas segn sus
capacidades
Pasos para mitigar el riesgo. - incluir al grupo a integrantes que tengan
conocimiento
en anlisis y diseo, y programacin
Monitorizacin
Factores a monitorizar. - Planificacin y proyecto
Modo de monitorizacin. - Ver si se tiene dificultades en el desarrollo del proyecto
de acuerdo con lo planeado.
Gestin
Plan de contingencias. - Buscar material para capacitarnos en anlisis y diseo
adems en programacin.
Consideraciones especiales. - la capacitacin debe hacerse a inicio del proyecto para
alcanzar la entrega
9.- Riesgo Que un integrante no acabe su parte del proyecto a realizar
Evitacin
Estrategia general. - Asignar tareas segn a sus habilidades y tiempo tolerante
Pasos para mitigar el riesgo. - en las reuniones identificar las habilidades de cada
integrante y los tiempos disponibles que tienen sin afectar a sus otras actividades.
Monitorizacin
Factores a monitorizar. - Proyecto y Equipo
Modo de monitorizacin. - las entregas de avances en las reuniones y el avance del
proyecto
Gestin
Plan de contingencias. - asignar un tiempo de correccin para que el lder realice lo
que no se entreg.
Consideraciones especiales. - si el integrante que no presento su parte continua con
esa actitud se dar de baja del equipo
10.-Riesgo Falta de un integrante a las reuniones del equipo
Evitacin
Estrategia general. - planificar las reuniones segn el tiempo disponible de todos los
integrantes del grupo
Pasos para mitigar el riesgo. - ver el horario de cada integrante y consultar el da de
la reunin a cada integrante y que todos estn de acuerdo.
Monitorizacin
Factores a monitorizar. - Equipo
Modo de monitorizacin. - tomar lista en reuniones
74
Gestin
Plan de contingencias. - el resto del grupo se dedicar a la parte del integrante faltante
Consideraciones especiales. - el que no asista a las reuniones peridicamente se dar
de baja del equipo
11.- Riesgo Abandono de un integrante
Evitacin
Estrategia general. - estar en contacto siempre para presionar que se comprometan en
el proyecto.
Pasos para mitigar el riesgo. - tener el nmero de celular de todos los integrantes,
estar en contacto en redes sociales la direccin de domicilio, el horario de clases y
saber los lugares que frecuenta
Monitorizacin
Factores a monitorizar. - Equipo y Proyecto

Modo de monitorizacin. - asistencia en reuniones y avance del proyecto
Gestin
Plan de contingencias. - Todos deben tener respaldo del proyecto y detectar si el

abandono de un miembro es inminente, en ese caso buscar ayuda de una persona con
las habilidades de la persona que abandono el equipo
Consideraciones especiales. - Solo se buscar ayuda si el integrante ere elemental en
el equipo
75
11. MANUAL DE CALIDAD DEL SOFTWARE

ESTNDARES DE CODIFICACIN
Consideraciones Generales
En general, se sugiere utilizar siempre nombres que sugieran lo que contiene o realiza el
objeto:
Objetos para Ejecucin
Tipo de Objeto Extensin

Documento HTML .html
Archivo Include .inc
Java Server Pages .jsp
Clase Java .class
Librera de clases empaquetadas .jar o .zip
Java Scrips .js
Objetos Multimedia

Imgenes JPG .jpg
Imgenes GIF .gif
Archivos MIF .mif
Archivos de audio .aud
Archivos flash .swf
Objetos Fuentes

Cdigo Java .java
Cdigo XML .xml
Archivo de propiedades . properties
76
Estndar de programacin en Java

Convenciones para Variables
Para la definicin de variables se debe tener presente las siguientes consideraciones:
Los nombres de las variables deben ser cortos y significativos.
La eleccin de un nombre de variable debe ser mnemotcnica, esto es, diseado para
demostrar el propsito de su uso a cualquier observador.
Los nombres de variables de un solo carcter deben ser evitados, solo usarlo para
variables temporales, como i, j o k para integres, o c, d o e para caracteres.
Los nombres de variables deben seguir siempre la siguiente estructura:
<prefijo><nombre>
Donde:
<prefijo> Describe el tipo de dato de la variable.
<nombre> Describe la variable
La siguiente tabla define los prefijos para los nombres de las variables:
Tipo de Dato Prefijo Ejemplo
Nmeros Enteros
byte byt bytRasterData
short shr shrNumber
int int intQuentity
long lon lonDistance
Nmeros Reales
float flt fltPrice
double dbl dblTotalSalary
Otros Tipos
char chr chrOption
boolean bol bolFound
String str strName
77
Convenciones para Constantes

Para la definicin de constantes debe tener presente las siguientes consideraciones:
Los nombres de variables declaradas como constante deben ser todas en maysculas
con palabras separadas por guion abajo (_).
Las constantes ANSI deben ser evitadas para facilidad de la Depuracin.
Se debe seguir las mismas convenciones que se usan para variables con respecto a
los
prefijos para tipo de dato.
Ejemplos:
public static final int IMIN_WIDTH = 4;
public static final int IMAX_WIDTH = 999;
public static final int IGET_THE_CPU = 1;
Convenciones para Clases

Para la definicin de clases debe tener en cuenta las siguientes reglas:
Tratar de que el nombre de la clase sea simple y descriptivo
Use palabras completas, evite abreviaturas o acrnimos, a menos que sean mucho
ms usadas que el nombre completo.
Los nombres de las clases deben ser sustantivos.
Los nombres de clase deben empezar con una letra mayscula y el resto de letras
deben estar escritas en minscula. En el caso que pueda tener ms de una palabra, las
primeras letras de cada palabra interna deben ser con mayscula.
Los nombres de clase no pueden ser verbos. La excepcin a esta regla son las clases
que extienden de la clase Action de Struts, los cuales si pueden tener verbos en su
nombre.
Los nombres de clase no pueden contener espacios ni caracteres especiales, slo son
permitidas las letras de la a a la z y los nmeros del 0 al 9.
Los nombres de aquellas clases que extiendan de la clase Action de Struts debern
tener el sufijo Action, como por ejemplo RolAction
Los nombres de clases tipo bean debern tener el sufijo Bean, como por ejemplo
UsuarioRolBean
Los nombres de clases tipo DAO debern tener el sufijo DAO, como por ejemplo
ExamenDAO
Lon nombres de Servlets deben incluir la funcionalidad que controlan y con el sufijo
Servlet, por ejemplo, RecepcionExpedienteServlet
Convenciones para Atributos de Clases

Para definir los nombres de los atributos deber tener en cuenta las siguientes reglas:
Los nombres de atributos deben empezar con una letra minscula y el resto de letras
deben estar escritas en minscula.
Los nombres de atributo no pueden ser verbos.
Los nombres de atributo no pueden contener espacios ni caracteres especiales, slo
son permitidas las letras de la a a la z y los nmeros del 0 al 9.
Si el nombre de atributo est compuesto por ms de una palabra, cada palabra
adicional debe empezar con mayscula
78
Convenciones para Mtodos

Para definir los nombres de los mtodos deber tener presente las siguientes reglas:
Los nombres de los mtodos deben empezar con una letra minscula y el resto de
letras deben estar escritas en minscula.
Los nombres de los mtodos deben ser verbos o palabras que identifiquen de manera
general el objetivo del mtodo
Los nombres de los mtodos no pueden contener espacios ni caracteres especiales,
slo son permitidas las letras de la a a la z y los nmeros del 0 al 9.
Si el nombre de mtodo requiere estar compuesto por ms de una palabra, cada
palabra
adicional debe empezar con mayscula.
Ejemplos:
run();
runFast();
getBackground();
Convenciones para Paquetes

Los nombres de los paquetes slo se escriben en letras minsculas, tal como se muestra en
la siguiente plantilla:
com.empresa.apli.nombremodulo.subparte
Donde
empresa, por ejemplo, cibertec, integra, vcp, uni, etc.
apli, es el cdigo de la aplicacin segn la tabla de aplicaciones.
nombremodulo, es el nombre del mdulo, por ejemplo: mantenimiento, reporte, etc.
subparte, cada mdulo ordena sus clases en subpartes segn el framework que utiliza
Estndar de programacin en PHP
GENERAL
Etiquetas PHP
El cdigo PHP debe utilizar las etiquetas largas <?php ?> o las etiquetas cortas para
imprimir salida de informacin <?= ?>; no debe emplear otras variantes.
Codificacin de caracteres
El cdigo PHP debe utilizar codificacin UTF-8 sin BOM.
Efectos secundarios
Un archivo debera declarar estructuras (clases, funciones, constantes, etc., ...) y no
causar efectos secundarios, o debera ejecutar partes de la lgica de negocio, pero no
debera hacer las dos cosas.
La frase "efectos secundarios" significa: que la ejecucin de la lgica de negocio no
est
directamente relacionada con declarar clases, funciones, constantes, etc, simplemente
la
de incluir el archivo.
"Efectos secundarios" incluyen, pero no se limitan a: generar salidas, uso explcito de
requiere o include, conexiones a servicios externos, modificacin de configuraciones
iniciales, enviar errores o excepciones, modificar variables globales o estticas, leer o
escribir un archivo, etc.
79
Archivos
Todos los archivos PHP deben usar el final de lnea Unix LF.
Todos los archivos PHP deben terminar con una lnea en blanco.
La etiqueta de cierre ?> debe ser omitida en los archivos que slo contengan cdigo
PHP.
Lneas
No debe haber un lmite estricto en la longitud de la lnea.
El lmite flexible de la lnea debe estar en 120 caracteres; los correctores de estilo
automticos deben advertir de sto, pero no deben producir errores.
Las lneas no deberan ser ms largas de 80 caracteres; las lneas ms largas de estos
80 caracteres deberan dividirse en mltiples lneas de no ms de 80 caracteres cada
una.
No debe haber espacios en blanco al final de las lneas que no estn vacas.
Pueden aadirse lneas en blanco para mejorar la lectura del cdigo y para indicar
bloques de cdigo que estn relacionados.
No debe haber ms de una sentencia por lnea.
Indentacin
El cdigo debe usar una indentacin de 4 espacios, y no debe usar tabuladores para la
indentacin.
Palabras clave y true/false/null.

Las Palabras clave de PHP deben estar en minsculas.
Las constantes de PHP true, false y null deben estar en minsculas.
ESPACIO DE NOMBRE Y DECLARACIONES USE

Cuando est presente, debe haber una lnea en blanco despus de la declaracin del
namespace.
Cuando estn presentes, todas las declaraciones use deben ir despus de la declaracin
del namespace.
Debe haber un use por declaracin.
Debe haber una lnea en blanco despus del bloque de declaraciones use.
CLASES, PROPIEDADES Y MTODOS

El trmino "clase" hace referencia a todas las clases, interfaces o traits.
Extensiones e implementaciones
Las palabras clave extends e implements deben declararse en la misma lnea del
nombre
de la clase.
La llave de apertura de la clase debe ir en la lnea siguiente; la llave de cierre debe ir
en la lnea siguiente al cuerpo de la clase.
La lista de implements puede ser dividida en mltiples lneas, donde las lneas
subsiguientes sern indentadas una vez. Al hacerlo, el primer elemento de la lista debe
estar en la lnea siguiente, y debe haber una sola interfaz por lnea.
80
Propiedades
La visibilidad debe ser declarada en todas las propiedades.
La palabra clave var no debe ser usada para declarar una propiedad.
No debe declararse ms de una propiedad por sentencia.
Los nombres de las propiedades no deberan usar un guin bajo como prefijo para
indicar si son privadas o protegidas.
Mtodos
La visibilidad debe ser declarada en todos los mtodos.
Los nombres de los mtodos no deberan usar un guin bajo como prefijo para indicar
si son privados o protegidos.
Los nombres de mtodos no deben estar declarados con un espacio despus del
nombre
del mtodo. La llave de apertura debe situarse en su propia lnea, y la llave de cierre
DEBE ir en la lnea siguiente al cuerpo del mtodo. No debe haber ningn espacio
despus del parntesis de apertura, y no debe haber ningn espacio antes del
parntesis
de cierre.
ESTRUCTURAS DE CONTROL
Las reglas de estilo para las estructuras de control son las siguientes:
Debe haber un espacio despus de una palabra clave de estructura de control.
No debe haber espacios despus del parntesis de apertura.
No debe haber espacios antes del parntesis de cierre.
debe haber un espacio entre parntesis de cierre y la llave de apertura.
El cuerpo de la estructura de control debe estar indentado una vez.
La llave de cierre debe estar en la lnea siguiente al final del cuerpo.
El cuerpo de cada estructura debe estar encerrado entre llaves. Esto estandariza el aspecto
de las estructuras y reduce la probabilidad de aadir errores como nuevas lneas que se
aaden al cuerpo de la estructura.
CLOSURES
Las closures deben declararse con un espacio despus de la palabra clave function, y
un espacio antes y despus de la parabra clave use.
La llave de apertura debe ir en la misma lnea, y la llave de cierre debe ir en la lnea
siguiente al final del cuerpo.
No debe haber un espacio despus del parntesis de apertura de la lista de argumentos
o la lista de variables, y no debe haber un espacio antes del parntesis de cierre de la
lista de argumentos o la lista de variables.
En la lista de argumentos y la lista variables, no debe haber un espacio antes de cada
coma, y debe que haber un espacio despus de cada coma.
Los argumentos de las closures con valores por defecto, deben ir al final de la lista de
argumentos.
81
ESTNDAR PARA EL DISEO DE LA INTERFAZ.

Consideraciones Generales
El sistema debe presentar la informacin claramente al usuario, es decir mostrar un ttulo
adecuado por cada pantalla, minimizando el uso de abreviaturas y proporcionando una
retroalimentacin de usuario clara.
El sistema debe ser consistente a lo largo de sus pantallas. Se puede lograr consistencia por
medio de:
Ubicacin de ttulos, fecha, hora y mensajes de operador, en todas las pantallas.
Saliendo de cada pantalla mediante la misma opcin (a travs de enlaces, botones o
pulsando
sobre un grfico determinado).
El uso de colores de manera homognea para todas las pantallas.
El uso de iconos para operaciones establecidos de manera similar.
El Sistema debe realizar un reconocimiento de la aceptacin de entrada, es decir, el
reconocimiento que la entrada est en la forma correcta. Antes del envo de datos a servidor,
se debe validar en la medida de lo posible que lo que se desea ingresar sea correcto, o, por lo
menos, sea un valor posible.
El sistema debe informar de forma clara y explcita del problema con los datos ingresados de
forma clara al usuario, en los casos que sea necesario.
Los usuarios deben saber cundo su peticin est completa y si pueden efectuar nuevas
solicitudes.
El ttulo de la pgina debe permitir al usuario identificar claramente en qu lugar del sistema
se encuentra ubicado.
En caso de interfaces secuenciales se debe permitir al usuario acceso a la siguiente o anterior
interfaz de la gua consecutiva.
Las pginas deben tener como tamao mximo una pantalla y media, tomando como base una
pantalla que tiene una resolucin de 800 x 600 pixeles.
Los campos de solo lectura aparecern sombreados, mientras que los campos editables sern
de fondo blanco. Otra caracterstica de los campos no editables es que al estar deshabilitados
no reciben el enfoque.
El enfoque de los controles va de arriba hacia abajo y de izquierda a derecha, se tendr en
cuenta que los campos no editables no recibirn el enfoque.
Elementos Visuales de la Interfaz

La ventana principal tendr las siguientes caractersticas estructurales:
Barra de ttulo, donde se indique el ttulo de la funcionalidad que se est cargando.
Barra de men, en esta zona aparece las principales opciones de las funcionalidades del
sistema.
Pantalla funcional: en esta zona, se visualizar la interfaz propia a la funcionalidad que se est
utilizando.
Fuentes y Colores
Fuentes Aadir tipo de letra del

software
Color de la fuente Todos los colores
Color de fondo Todos los colores

82
Botones
Botones de accin
Iniciar Sesin
Ingresar
Cancelar
Reportes Generales
Imprimir
Registros
Importar
Cobrar
83
ESTNDAR PARA EL CONTROL DE LA CALIDAD INTERNA Y EXTERNA DEL

SISTEMA
Estndar para el control de la calidad Interna
De acuerdo a la norma ISO 9126 se toma en cuenta las siguientes caractersticas con las que
debe
cumplir para el control de calidad interna del sistema:
Confiabilidad: Capacidad del producto software de mantener un nivel especificado de

rendimiento cuando es usado bajo condiciones especficas.
El sistema debe ser capaz de manejar errores y de corregir los mismos en un tiempo oportuno.
Eficiencia: Representa la relacin entre el grado de rendimiento del sitio y la cantidad de

recursos
(tiempo, espacio, entre otros) usados bajo ciertas condiciones.
El Sistema debe responder de manera rpida.
El Sistema debe utilizar los recursos de manera eficiente.
Capacidad de Mantenimiento: Capacidad del producto software de ser modificado y probado.

El Sistema debe ser capaz de adaptarse a modificaciones cuando se las requiera.
El Sistema debe ser probado con facilidad.
Estndar para el control de la calidad Externa del Sistema

De acuerdo a la norma ISO 9126 sern tomadas las siguientes caractersticas para el control de
calidad Externa:
Funcionalidad: Capacidad del producto software de proporcionar funciones que ejecuten las
necesidades explcitas e implcitas de los usuarios cuando el software es usado bajo condiciones
especficas.
Las funciones requeridas deben estar disponibles en el software.
El software debe desempear las tareas requeridas.
Los resultados deben ser los esperados
El sistema debe de impedir el acceso no autorizado.
Utilidad: El producto software debe cumplir con el fin para el cual se fue desarrollado.
El Sistema debe ser de fcil comprensin para el usuario final.
El sistema debe utilizarse sin mucho esfuerzo.
Las interfaces deben mostrarse de forma clara y entendible para el usuario final.
84
ESTNDAR PARA EL CONTROL DE CALIDAD EN USO DEL SISTEMA.

Para el control de calidad en uso el sistema se basa en el estndar ISO/IEC 9126-4, que hace
referencia a la productividad, efectividad, seguridad y satisfaccin que debe tener un producto
software.
Calidad en uso de acuerdo al estndar ISO 9126-1 se define como: la capacidad de un producto
software de facilitar a usuarios especficos alcanzar metas especficas con eficacia,
productividad,
seguridad y satisfaccin en un contexto especfico de uso.
Adems, agrega que calidad en uso es la visin de calidad de los usuarios de un ambiente
conteniendo software y es medida sobre los resultados de usar el software en el ambiente, antes
que sobre las propiedades del software en s mismo.
Las caractersticas de calidad en uso se agrupan en cuatro categoras:
Caractersticas para el control de Calidad en Uso segn la ISO/IEC 9126-1
Eficacia: La capacidad del producto de software para facilitar a los usuarios alcanzar metas
especficas con exactitud y completitud en un contexto especfico de uso.
El Sistema debe cumplir con los requerimientos de acuerdo a los procesos que se desarrollan
en su contexto especifico de uso.
Productividad: La capacidad del producto de software para invertir la cantidad apropiada de

recursos en relacin a la eficacia alcanzada en un contexto especifico de uso.
El Sistema debe trabajar de manera conjunta a las actividades que se desarrollan dentro de la
organizacin a la cual pertenece.
Seguridad: La capacidad del producto de software para alcanzar niveles aceptables de riesgo de
daar a las personas, el negocio, el software, la propiedad o el ambiente en un contexto
especifico
de uso.
El Sistema no debe tener niveles de riesgo que causen dao al Usuario final y a su contexto
especifico de uso.
Satisfaccin: La capacidad del producto de software para satisfacer a los usuarios en un

contexto
especfico de uso.
El sistema debe satisfacer los requerimientos del usuario final y responder a su contexto
especfico de uso de manera adecuada.
85
ESTNDARES DE SEGURIDAD
Consideraciones Generales De Seguridad
En la misma medida que las aplicaciones y servicios Web estn creciendo en el mundo, estn
creciendo los ataques a los mismos, aprovechando sus vulnerabilidades. Esto obliga a realizar
acciones de seguridad, no solamente a nivel de configuracin de routers, instalacin de firewalls,
inclusin de seguridad en servidores, sino tambin durante el diseo y construccin de los
sistemas.
Principios fundamentales a considerar durante el diseo:
Validar Input y Outputs del sistema

Los campos de input y output del sistema deben ser validados, para permitir solo las
caractersticas explcitamente definidas para ellos, y eliminar cualquier otro tipo de data.
Falla segura
Los mecanismos de seguridad, deben ser diseados, de tal manera que cuando fallen,
rechacen
los requests de seguridad subsecuentes incorporados en la transaccin.
Mantenerlo simple
Si un sistema de seguridad es muy complejo, puede no ser usado o buscar medidas para
bypassearlo. Normalmente la seguridad ms efectiva es la ms simple.
Reusar componentes probados

No crear rutinas de seguridad propias para cada aplicacin, sino reusar rutinas slidas y
probadas para este efecto.
Defensivo en profundidad
Confiar en un componente, para que realice su funcin adecuadamente el 100% de las veces,
no siempre es real. Se debe planear o prever los eventos inesperados de acuerdo a la criticidad
del sistema.
El sistema es tan seguro como el punto ms dbil del sistema

De nada vale poner mucha seguridad en la puerta de entrada a una aplicacin, si dejamos
puertas falsas por donde se pueda vulnerar la seguridad.
Seguridad no es igual a oscuridad

Oscurecer la informacin es diferente a asegurarla, tarde o temprano puede ser descubierta.
Privilegios mnimos
Los sistemas deben ser diseados y construidos con el mnimo nivel de seguridad que
requieren para funcionar. No se deben asignar privilegios asumiendo que en un futuro lo
necesitaran.
Separacin de privilegios
Compartimentalizacin, asignar privilegios a grupos de usuarios segn las funciones que
puede realizar en el sistema, en lugar de asignar privilegios a cada usuario.
86
Adoptar una arquitectura por capas

Se deben usar capas (tiers) separadas, entre la presentacin de contenido, seguridad y control
de las sesiones de usuario, el almacenamiento de datos, servidor de contenido. Es importante
que solo los servicios de entrega de contenido que estn previstos entregar sean los que estn
permitidos para los requests de los usuarios
Seguridad de la infraestructura de red

Los sistemas Web corren en sistemas operativos que dependen de redes para compartir datos
con el exterior. La capa de red es la capa fundamental de seguridad y control.
Se debe prever que la instalacin cuente con controles adecuados, desde ACLs (listas de
control de accesos), firewalls (basados en Proxy o inspeccin de paquetes).
Se debe habilitar solo los puertos 80 o 443 (seguro) para las conexiones externas. Se debe
evaluar si se requiere de un firewall entre el servidor de aplicaciones y el servidor de datos.
Tamao de URLs
Con el fin de prevenir que nuestros clientes estn expuestos a ataques de phishing, pharming
o web spoofing, se considera como regla que el tamao del URL de nuestras aplicaciones
no exceda a 120 caracteres.
Consideraciones para Principales Vulnerabilidades
Se describen las consideraciones para las principales vulnerabilidades de seguridad existentes a
la fecha para sistemas Web, as como consideraciones para prevenirlas.
Buffer overflow
Esto ocurre cuando la aplicacin no realiza un adecuado chequeo de la data de entrada,
pudiendo exceder el tamao del buffer previsto, y comprometer otros espacios de memoria.
Se deben incluir los chequeos de tamao adecuado en los campos de input del usuario que
sern enviados va el request http
Cross site script (XSS) injection

Esto ocurre cuando un atacante puede incluir comandos script en los requests de los
clientes,
y estos scripts pueden ser ejecutados por la aplicacin. Esto, en combinacin con tcnicas de
ingeniera social, permite redireccionar informacin del usuario hacia el atacante, que luego
puede obtener informacin sensitiva del usuario.
La aplicacin debe validar todas las cabeceras (headers), cookies (si existieran), parmetros
enviados como parte del request (Query strings), campos de los formularios (incluso los
hidden).
En lo posible, las aplicaciones deben contar con un mdulo nico de validacin para chequeo
de textos, que incluya la validacin en el cliente y en el servidor.
En la construccin de pginas las variables deben usar el juego de caracteres permitido y
deben
chequear estas variables durante la generacin del output. Se deben usar filtro para asegurarse
un juego de caracteres seguro antes de mostrar la pgina.
87
En el servidor Web se debe fijar el juego de caracteres. Usar, por ejemplo:

<HTML>
<HEAD>
<META http-equiv=Content-Type content=text/html; charset=ISO-8859-1>
Los caracteres especiales deben ser codificados usando su valor numrico, por ejemplo
&#169
para el copyright.
Los caracteres con uso potencial en cross site scripting deben ser eliminados o convertidos al
cdigo HTML adecuado:
< en &lt
> en &gt
( en &#40
) en &#41
# en &#35
& en &#38
Segn la aplicacin se debe determinar si otros caracteres son incluidos en esta lista.
Broken access control

Esto ocurre, si de alguna manera se rompe el mecanismo de control de acceso. Se debe tomar
medidas para:
Evitar que se bypasee el uso de una clave cuando esta se requiera.
Evitar que se disponga de informacin de rutas de directorios en el servidor mediante
URLs
Manejar los permisos de accesos a los files. Solo los archivos que se busca mostrar a los
usuarios web, deben ser marcados para ser ledos en modo lectura en el Sistema Operativo,
el resto de directorios del servidor web no debe ser accesible por los usuarios web.
Eliminar los archivos ejecutables (.ocx, .dll, .exe, .com, .bat) de los directorios a los que se
permite el acceso a los usuarios web.
Setear PRAGMA-NOCACHE, para evitar ataques a las pginas cache. Usar multiples
mecanismos como headers http y meta tags, para asegurar que las pginas que contienen
informacin sensitiva no sean guardadas en el cache de los browsers de los usuarios (o de
su red).
Cuando se usen componentes para seguridad, confirmar el nivel de control que realiza. El
nivel no controlado debe ser realizado por la aplicacin.
Broken authentication and session management

Dado que las aplicaciones usan las sesiones para manejar variables relacionadas con los
requests de los usuarios, los atacantes pueden utilizar una sesin activa para asumir la
identidad
de un usuario. Para prevenir esto considerar lo siguiente:
Manejo de reglas sobre la clave, su tamao, caractersticas, periodo de cambio y
prevencin
del reuso de passwords anteriores.
El nmero de logins fallidos debe ser limitado, la razn del login fallido no debe ser
detectable, y al momento del loggeo exitoso la fecha del ltimo login debe ser desplayado,
as como los intentos fallidos desde esa fecha.
88
El cambio de password debe ser un mecanismo nico, que solicite al usuario el password
antiguo y el nuevo (doblemente). El cambio de e-mail debe ser autenticado, cuando los
passwords olvidados son enviados por va e-mail.
Los passwords deben ser almacenados en forma encriptada
La transaccin completa de login debe realizarse usando SSL
En el caso de transacciones NO-SSL, el id de session no debe enviarse en el URL.
Para las pginas de autenticacin debe usarse el mtodo POST, no usar el mtodo GET.
Estas pginas deben marcarse con no cache tags y auto complete=false para prevenir el uso
del back button.
Improper error handling

Un manejo inadecuado de los errores puede llevar a mensajes que proporcionen cierta
informacin de implementacin a los posibles atacantes. Las principales recomendaciones
son:
Falla segura, ante un error la aplicacin no debe continuar ejecutando las siguientes
instrucciones, debe preverse un manejo seguro de este error, registrndolo en un log para
posterior anlisis.
Mostrar una pgina estndar para errores, indicando el mensaje adecuado pero que solo
indique que ha ocurrido un problema y no de mayor informacin.
Simular errores durante el testing
El manejo de errores debe ser estndar en toda la aplicacin, y cada pieza debe ser parte de
un esquema adecuadamente diseado. Este manejo debe ser documentado.
Insecure storage
El almacenamiento de informacin sensitiva (password, saldos, remuneraciones) es un punto
importante, pudiendo optarse por encriptacin de los mismos segn la clasificacin de
seguridad que se realice.
Esto debe incluir un adecuado almacenamiento de las keys, certificados y passwords; Evitar
guardar datos sensitivos en memoria, seleccin del algoritmo de encriptacin adecuado.
Unvalidated input
Los atacantes pueden hacer uso de cualquier parte de un request http, incluyendo el URL,
querystring, headers, cookies, campos del formulario, campos escondidos, para bypassear los
mecanismos de seguridad de un site. Ante esto se recomienda:
Validar los inputs si la aplicacin recibe requests fuera de la red interna.
Un elemento central en el diseo de la aplicacin, debe ser la estrategia de validacin de los
inputs. Esto no solo debe basarse en la validacin en el lado cliente, sino tambin en el lado
servidor.
La validacin de los inputs en el lado cliente y servidor debe considerar:
Tipo de datos (string, integer, etc.)
Juego de caracteres permitido
Longitud mnima y mxima
Si el parmetro es requerido o no
Patrones para alfanumricos y rangos para numricos
89
Asegurarse que los usuarios no puedan manipular los parmetros en el URL para bypassear la
seguridad
Injection Flaws
Esto permite al atacante ejecutar cdigo malicioso a travs de la aplicacin web a otro sistema.
Para protegerse de esto se debe:
Evitar acceso a componentes interpretes
Validar data asociada a llamadas externas a las bases de datos, y usar para esto stored
procedures. Mecanismos para controlar cualquier posible error, timeout o bloqueo durante la
llamada.
La aplicacin debe correr con los privilegios mnimos que requiere para su ejecucin. No
ejecutar con usuario administrador de base de datos.
Denial of service
Es el proceso de hacer que una aplicacin no est disponible, por ejemplo, con un bombardeo
de requests para consumir todos los recursos.
A nivel de la red se realizan actividades de aplicacin de los ltimos service packs, y el uso de
un sistema IDS (Intrusin Detection System).
Las aplicaciones deben ser diseadas tomando en cuenta un posible denial of service, debe ser
capaz de manejar altos volmenes de trfico y poder manejar cargas anormales. Esto debe
realizarse en combinacin con el adecuado manejo de los inputs y el manejo de errores.
Insecure configuration management

Esta vulnerabilidad es mayormente responsabilidad del administrador de la red y los
servidores
web y de aplicaciones.
Sin embargo, al momento de disear las aplicaciones evitar la administracin remota de la
misma, esta debe hacerse en forma local. Los archivos de configuracin deben alojarse fuera
del espacio de la aplicacin web, para prevenir posibles downloads de estos archivos.
Consideraciones Especficas de Seguridad
La longitud de los URLs de nuestras aplicaciones no debe exceder a 120 caracteres. Esto con el
fin de acostumbrar a los clientes que el sistema normalmente usa URLs cortos y prevenir
posibles
ataques de phishing a los clientes, haciendo referencia a URLs que contengan el nombre del
sistema.
Las aplicaciones desarrolladas para web normalmente contaran con 2 zonas, una zona de acceso
libre y otra zona de acceso restringido mediante el uso de un usuario y clave.
Todas las aplicaciones que incluyen logueo y que pueden ser accedidos fuera de la red interna de
la empresa, deben contar con el uso de certificados digitales. Para cada caso se evaluar la
longitud de la clave.
Para el acceso al Website cada cliente (persona natural o jurdica) contar con un usuario y clave.
90
12. LISTA DE CHEQUEOS
ANEXOS
Anexo 1
Lista de chequeo de aseguramiento de calidad
Fecha: 10 de Junio de 2017 Analista: ROBERTO SUAREZ FLORES
Revisin de aseguramiento de calidad
No Informacin
Actividad S No
aplica adicional
Existe alguien en su organizacin
responsable por los procesos de pruebas? X
Tiene y usa un estndar para el plan de

pruebas? X
Tiene y usa un estndar para las pruebas de

unidad? X
Tiene y usa un estndar para el reporte de la

ejecucin de las pruebas? X
La planeacin y ejecucin de pruebas se

realiza en paralelo con el proceso de X
desarrollo de software?
Se verifica que las especificaciones estn
correctame nte implementadas? X
Se verifica que las e x p e c t a t i v a s del cliente

sean satisfechas? X
Los probadores verifican la precisin y

completitud de productos internos tales como
el documento de requerimientos o los diseos? X
Los probadores reportan los defectos al

equipo de desarrollo de software para X
correccin?
Los probadores identifican la prioridad de los
riesgos del negocio para el desarrollo de l plan X
de pruebas?
Existen objetivos de pruebas medibles para
cada sistema de software que est siendo X
probado?
Los objetivos estn alineados con los riesgos
del negocio? X
91
No Informacin
Actividad S No
aplica adicional
Se usan mtricas para mejorar el proceso de
aseguramiento de la calidad? X
Los probadores han definido pronsticos de

defectos basndose en datos y experiencias X
previos?
Existe un proceso de mejoramiento continuo

para su proceso de pruebas? X
Los tipos de defectos estn identificados?

X
Se registra, acumula y se usan los datos de

fallas para evaluar la efectividad del proceso
de pruebas y producir un software libre de X
defectos?
Se usan mtricas para planear y evaluar el

proceso de pruebas? X
Tiene un proceso de entrenamiento de

probadores? X
El uso de una herramienta automatizada de

pruebas es parte significativa de su proceso? X
92
Anexo 2
Lista de chequeo de estndares de presentacin y funcionalidad de la
aplicacin para formas
Fecha: 10 de Junio de 2017
Forma: General Descripcin: Revisin de la forma general
Analista: ROBERTO SUAREZ FLORES Revisor: ANGHELO LEDO VARGAS
Revisin de estndares de presentacin
No Informacin
Actividad S No
aplica adicional
Estn claramente definidos los bloques d e
informacin? X
Tiene los encabezados de ttulo y nombre de

aplicacin correctos? X
Las etiquetas de los campos son claras y

representativas? X
Los campos de despliegue estn

completamente inhabilitados y del color X
respectivo?
Los campos de solamente despliegue estn
claramente identificados? X
Tiene los colores estndar? X

Los campos fecha t i e n e n el formato DD-
MON-YYYY y se puede ingresar los datos X
como Ej: 12ago2001?
Cuando se tiene una forma con mltiples
tabs, se conoce cul es el registro padre de los X
tabs?
La forma tiene la dimensin correcta? X
Los Radio Groups tienen un frame que los
abarca? X
Los campos estn alineados en forma

correcta? X
Los campos requieren y tienen Tooltip? X

Los LOVs tienen el tamao y la posicin
adecuados (que no requieran ser movidos)? X
Los LOVs estn heredados?

X
93
No Informacin
Actividad S No
aplica adicional
Los barras de Scroll son blancas y de ancho

X
15?
Estn los RadioButtons azules y heredan
de la propiedad VA_RadioButtons?
X
Estn habilitados los botones del toolbar de

manera adecuada y corresponden con las
teclas de funcin? X
Revisin de funcionalidad
No Informacin
Actividad S No
aplica adicional
La forma realiza la funcin que se necesita?
X
La forma ha sido ingresada a SIABD con todas

las f u n c i o n e s , tablas y roles asociados? X
Los datos de la forma cambian en forma

X
sincronizada?
Es rpido y fcil el manejo de la forma?
X
Cuando se cambia el valor de un campo de

entrada, se modifica tambin el campo de X
despliegue?
Los bloques hijos est n coordinados con el
bloque padre en consulta, borrado y cuando se X
limpia la forma?
Los campos que hacen referencia a datos de
otras tablas tienen cada uno su lista de X
valores?
Las listas de valores son lentas para
recuperar la informacin? X
94
El tiempo de respuesta es adecuado?
X
Revisin de funcionalidad
No Informacin
Actividad S No
aplica adicional
El orden de navegacin de los campos es el
correcto? X
Los mensajes graves son ma n ej a d os

adecuadamente? X
Los campos Validate from LOV funcionan

adecuadamente? X
Si el reporte requiere mucho tiempo, esto le

es notificado al usuario? X
Est la forma documentada? X

Si llama reportes, la extensin de los reportes
es la correcta? (NO rdf, debe estar sin X
extensin).
Revisin del cdigo y los datos que retorna
No Informacin
Actividad S No
aplica adicional
Se ha realizado el proceso de prueba formal?

X
Est la mayor cantidad de cdigo en la base

de datos? X
Se ha r e a l i z a d o el proceso de afinamiento
SQL? X
95
Anexo 3
Lista de chequeo de estndares de presentacin y funcionalidad de la
aplicacin para reportes
Fecha: 10 de Junio de 2017 Reporte: General

Analista: ROBERTO SUAREZ FLORES Revisor: ANGHELO LEDO VARGAS
Revisin de estndares de presentacin
Informacin
Actividad S No No aplica
adicional
El reporte tiene el nombre del sistema
correcto? X
El reporte tiene los encabezados de ttulo y

X
nombre de aplicacin correctos?
El reporte tiene la fecha d e generacin? X
El reporte tiene el nmero de pgina y el
total de pginas? X
Estn claramente definidos los bloques de
informacin? X
Las etiquetas de los campos son claras y
representativas? X
El reporte tiene los colores estnda res? Negro
y tonos de grises. X
Los campos fecha t i e n e n el formato
DD-MON-YYYY? X
Los campos estn alineados en forma X

correcta?
Se ha ut i l i z a d o la indentacin para mejorar X
la legibilidad del reporte?
El reporte tiene enumeradas las filas? X
El reporte tiene subtotales y totales de
control? X
El reporte tiene, en la parte superior, las
condiciones de generacin del listado? X
El reporte tiene el visto b u e n o del usuario?
Se ha hecho revisin por pares? X
Se ha r e a l i za d o el proceso de afinamiento X
SQL?
Est la mayor cantidad de cdigo en la base X
de datos?
El cdigo cumple con los estndares? X
Est el reporte registrado en SIABD? X

96
Anexo 4
Lista de chequeo de estndares de tablas
Tabla: GENERAL Descripcin: R e v is i n d e la s t ab l a s e n ge ne r a l
Analista: ROBERTO SUAREZ FLORES
Estndares de las tablas
No Informacin
Actividad S No
aplica adicional
El nombre de la tabla es correcto segn los X

estndares?
Tiene las d e s c r i p c i o n e s de la columna en X
la base de datos?
Tiene las llaves e ndices adecuados? X
La tabla ha si d o recreada teniendo en cuenta
su uso? X
97
Anexo 5
Lista de chequeo de estndares de funciones y procedimientos

Func/Proc: GENERAL Descripcin: Revisin de las funciones en general
Analista: ROBERTO SUAREZ FLORES Revisor: ANGHELO LEDO FLORES
Revisin de estndares
No Informacin
Actividad S No
aplica adicional
El nombre cumple con los estndares? X
El cdigo cumple con los estndares? X
Est la funcin o procedimiento
documentado? X
Se ha rea l i zad o el proceso de afinamiento

SQL? X
Se ha registrado en SIABD? X
Se usan todas las variables , constantes y
X
parmetros?
La asignacin de valores a las variables,
X
constantes y parmetros tiene un propsito?
Son correctas las validaciones de condiciones?
Por ejemplo: cdigo no alcanzable, ciclos X
infinitos, divisin por cero, verificacin de
rangos, redondeos.
Faltan validaciones? X
Se manejan todas las posibles excepciones?
X
Las variables que guardan datos de columnas
de tablas se han definido de acuerdo con
esto? X
Tabla.columna%type
Si se llaman otras funciones y/o
procedimientos, tienen el nmero de par- X
metros y el tipo de datos adecuado?
98
Anexo 6
Lista de chequeo de estndares de Programacin-Cdigo
Objeto: GENERAL
Fecha de revisin: 10 de Junio de 2017
Revisado por: JOSE LUIS LLAMPA COLQUE Aprobado: SI
No Informacin
Elemento a revisar S No
aplica adicional
Cdigo en general
Est el cdigo indentado a, por lo menos dos
espacios? X
Estn ordenadas alfabticamente las

X
constantes, variables y cursores?
Estn alineados a la izq ui er da las
constantes, variables y cursores? X
Estn alineados a la izquierda la definicin

del tipo de dato de las constantes, variables y X
cursores?
Est definida sola una constante, variable o
cursor por lnea? X
Documentacin
Est toda la documentacin en una lnea
d i f e r e n t e al cdigo que se est documentando? X
Comprende la documentacin de
funciones/procedimiento tres partes: una
descripcin general de lo que h a c e l a funcin
o procedimiento, la descripcin de los X
parmetros de entrada y la descripcin de los
posibles valores y/o parmetros de salida?
Parmetros
El nombre de los parmetros empieza con la
letra p minscula y es significativo? X
Constantes
El nombre de las constantes empieza con la X
letra c minscula y es significativo?
99
No Informacin
aplica adicional
Variables
El nombre de las variables empieza con la X
letra v minscula y es significativo?
Cursores
El nombre de los cursores empieza con las X
letras cur minsculas y es significativo?
Estn los nombres de los cursores alineados
a la izquierda junto con la definicin del tipo X
de dato d e las constantes y variables?
Instrucciones Select, Insert, Update y
Delete Estn en mayscula,
Estn todas las instrucciones Select, ya que las
X
Insert, Update y Delete escritas en diferenciamos con las
minsculas, a excepcin de variables que sentencias SQL
hagan referencia a campos de las formas?
Instrucciones Select
Estn las c l u s u l a s Select, Into, From,
X Una sola lnea
Where, Order BY, Group BY y Having
escritas en lneas diferentes?
Instrucciones Insert
Estn las c l u s u l a s Insert Into y
X Una sola lnea
Values escritas en lneas diferentes?
Instrucciones Update
Estn las c l u s u l a s Update, SET y X Una sola lnea
Where escritas en lneas diferentes?
Est cada c o l u m n a que se actualice en una X Una sola lnea
lnea diferente?
Estn todas las columnas que se actualicen X Una sola lnea
alineadas a la izquierda?
Instrucciones Delete
X Una sola lnea
Estn las clusulas Delete y Where escritas
en lneas diferentes?
100
Anexo 7
Lista de chequeo de estndares de presentacin - Formas
Forma: GENERAL
No Informacin
aplica adicional
Forma
X
Tiene la forma la descripcin y su ttulo de
acuerdo con los estndares?
Tiene la forma la dimensin correcta? X
Cuando se tiene una forma con mltiples tabs,
se conoce cul es el registro padre de los tabs? X
Ttulo del frame

X
Est el ttulo en mayscula inicial?
Si el frame es de un solo registro, est su X
ttulo en singular?
Si el frame es multirregistro, est su ttulo X
en plural?
Est localizado el ttulo en la parte superior
izquierda del frame? X
Campos
Tiene el contenido del campo la alineacin X
adecuada, de acuerdo con su tipo de dato?
Si existen varios campos organizados
verticalmente, estn alineados todos a la X
izquierda?
Etiquetas
Si la organizacin NO es tabular, estn X
situadas las etiquetas a la izquierda del
campo a l que pertenecen?
Si la organizacin S es tabular, estn
situadas las etiquetas en la parte superior del X
campo a l que pertenecen?
101
No Informacin
aplica adicional
Etiquetas
Si la organizacin S es tabular, estn las X
etiquetas centradas?
Estn las etiquetas en mayscula inicial? X
Estn las etiquetas sin los dos puntos al
final? X
Si existen varios campos organizados
verticalmente, estn alineadas todas las X
etiquetas a la derecha?
Estn las etiquetas formadas de manera
que no utilicen abreviaturas ni expresiones X
de solicitud?
Radio Buttons y Check Box

X
Emplean mayscula inicial?
En cuanto a su estructura, emplean
X
orientacin en forma de columna?
En cuanto a su estructura, emplean
X
alineamiento a la izquierda?
Estn organizadas las opciones en el orden
esperado, de mayor a menor frecuencia de X
ocurrencia?
Es t n enmarcados de nt r o de u n frame? X
Listas de valores
Estn organizados los descriptores X
alineados a la izquierda en forma de
columna?
Estn organizados los descriptores en orden
X
alfabtico o numrico, segn sea el caso?
Estn los descriptores en mayscula
inicial? X
El ancho es suficiente para evitar el uso de

X
scroll horizontal?
Tienen las listas de valores la posicin
adecuada, de forma que no requieran ser X
movidas?
102
No Informacin
aplica adicional
Scroll
X
Estn las barras de scroll vertical ubicadas a
la derecha?
Estn las barras de scroll vertical iguales a la X
altura de sus campos asociados?
Estn las barras de scroll horizon t al
X
ubicadas en la parte inferior?
Estn las b a r r a s de scroll h o r i z o n t a l iguales
X
al ancho de sus campos asociados?
Son las barras de scroll blancas? X
Botones
Si estn ubicados horizontalmente, X
estn en la parte inferior de la pantalla?
Si e s t n ubicados verticalmente,
X
estn a la derecha de la pantalla?
Los botones organizados horizontalmente, X
tienen la misma altura?
Los botones organizados verticalmente, X
tienen el mismo ancho?
Est colocada la opcin m s f r e c u e n t e a X
la izquierda o en el tope, segn corresponda?
Usan los botones mayscula inicial? X
Incluye puntos suspensivos (...) si la accin

despliega otra ventana? X
103
Anexo 8
Lista de chequeo de programacin - Formas
Forma: GENERAL
No Informacin
aplica adicional
Nombres de los o b j e t o s
Cumplen los siguientes objetos con los
estndares?
Alert X
Bloques X
Canvas X
Forma o reporte X
Funciones y/o procedimientos X
Grficos X
Libreras X
Listas de valores X
Object Group X
Parmetros X
Push Button X
Radio Group X
RecordGroup X
Relacin X
Variables X
Atributos visuales X
Ventanas X
Ttulo del frame

Hereda el ttulo del frame el atribu- to
visual VA_TITULO? X
104
No Informacin
aplica adicional
Campos
Hereda el campo el atributo visual X
correspondiente?
Hereda el prompt del campo el atributo
visual VA_ETIQUETA? X
Si el campo p e r t e n e c e a un bl oq ue
multirregistros, hereda el atributo visual
X
VA_CURRENTRECORD?
Si el campo es tipo date, tiene el formato
DD-MON-RRRR? X
Si el campo es numrico y representa dinero,
lleva d e l a nt e de l el signo de pesos ($)? X
Si el campo indica hora, tiene el formato
HH24: MI (hora militar)? X
Si el campo e s un p o r c e n t a j e , est ubicado
el smbolo % despus del nmero? X
Heredan los radio_buttons el atributo
Visual VA_RADIO_BUTTON? X
Heredan las listas de valores el atributo
visual VA_LOV? X
Scroll
Tienen las barras de scroll un ancho de 15
puntos? X
Canvas
Heredan los canvas el atributo visual
VA_CANVAS? X
105
INFORME DE REVISIN DEL SOFTWARE
De acuerdo con las revisiones que se realiz al software con ayuda del manual de calidad que se tiene, el
software se encuentra en un estado aceptable para su implantacin ya que existen an desperfectos que se
deben
de corregir. A continuacin, se presenta la tabla de errores encontrados:
Anexo 9
Formato de registro de defectos - Inspecciones
Objeto: GENERAL Revisor: ANGHELO LEDO VARGAS

Fecha: 10 de Junio de 2017 Inspeccin No.: 1
Tabla de tipos estndar de defectos
Cdigo Nombre Descripcin

10 Documentacin Comentarios, mensajes
20 Sintaxis Ortografa de los comandos, puntuacin, errores de

tecleo, formato de las instrucciones
30 Manejo de versiones Manejo de cambios, libreras, control de
versiones
40 Asignacin Interfaces Declara c iones , iden tif i cadore s dup l ic ad os , alcance
y lmites de los mismos
Validacin Datos Llamadas y referencias a procedimientos , I/O,
50
interfaz de usuario
60 Mensajes de error, validaciones incorrectas

70 Estructuras, contenidos, inicializaciones
Funciones
Defectos de lgica, puntero, ciclos
80 recursividad, clculo y funcionamiento
Configuracin, memoria, tiempo de respuesta

Sistema
90 P r o b l e m a s de d is e o , compilacin, pruebas del
ambiente de desarrollo
100 Entorno
106
Listado de defectos encontrados

Cdigo
Localizacin Descripcin del defecto encontrado
Defecto
20 SINTAXIS Errores en la ortografa de la programacin

VALIDACION DENo muestra las validaciones correspondientes
50
DATOS
No muestran mensaje de error al momento de introducir un dato
70 FUNCIONES
invalido
80 FUNCIONES No se hace uso de cursores
90 SISTEMA El tiempo de respuesta es un poco lento debido a la red

El software an necesita ser probado para ver la cantidad
100 ENTORNO
mxima de usuarios conectados paralelamente
107
13. PRUEBAS DEL SOFTWARE

13.1. PRUEBAS DE CAJA BLANCA
LOGIN.PHP
<?php
session_start(); include("libreria.php");
$con=conexions(); $nombre=$_POST['nombre']; $password= md5($_POST['clave']);
$c=mysql_query("SELECT * FROM bibliotecario WHERE nombre='$nombre' AND
password='$password'");--------------------------------------------1
if(mysql_num_rows($c)==1){----------------------------------2
$f=mysql_fetch_array($c); $_SESSION['nombre']=$f['nombre'];
$_SESSION['ci']=$f['ci']; $_SESSION['tipo']='b';
header("location: bibliotecario.php");---------------------------------------------3
}
else{
$c=mysql_query("SELECT * FROM ejecutivo WHERE usuario='$nombre' AND
password='$password'");---------------------------------------------4
if(mysql_num_rows($c)==1){--------------------------------------5
$f=mysql_fetch_array($c); $_SESSION['nombre']=$f['usuario'];
$_SESSION['ci']=$f['ci']; $_SESSION['tipo']='ej';
header("location: ejecutivo.php");---------------------------------------------6
}
else{
$c=mysql_query("SELECT * FROM estudiante WHERE usuario='$nombre' AND
password='$password'");-----------------------------------------------------------7
if(mysql_num_rows($c)==1){-----------------------------------------8
$_SESSION['ci']=$f['ci']; $_SESSION['tipo']='e';
header("location: estudiante.php");-----------------------------------------9
}
else{
$c=mysql_query("SELECT * FROM director WHERE usuario='$nombre' AND
password='$password'");-------------------------------------------------------10
if(mysql_num_rows($c)==1){--------------------------------------------11
$_SESSION['ci']=$f['ci']; $_SESSION['tipo']='d';
header("location: director.php");----------------------------------------12
}else
echo "<script>alert('Usuario o Password incorrectos');
window.location.href='index.php';</script>;";-------------------------------------------------------13
}
}
}------------------------------------------------14
?>
108
1.1 GRAFO DE FLUJO
4 3
7 6
10 9
11
13 12
14
109
1.2. COMPLEJIDAD CICLOMATICA
Es una mtrica de software que proporciona una medicin cuantitativa de la complejidad

lgica
de un programa
COMPLEJIDAD CICLOMATICA V (G)

V (G) = A N + 2
V (G) = 17 14 + 2
V (G) =5
V (G) = C + 1
V (G) = 4+ 1
V (G) = 5
V (G) = R
V (G) = 5
DONDE:
A: # De Arcos O Aristas Del Grafo. A=17
N: # De Nodos. N=14
R: # De Regiones Cerradas Del Grafo. R=5
C: # De Nodos Condicin. C=4
1.3 CAMINOS INDEPENDIENTES

c1= 1 2 3 14
c2= 1 2 4 5 6 14
c3= 1 2 4 5 7 8 9 14
c4= 1 2 4 5 7 8 10 11 12 14
c5= 1 2 4 5 7 8 10 11 13 14
1.4 CASOS DE PRUEBA
ENTRADA CAMINO RESULTADO ESPERADO

Se inicia sesin en
mysql_num_rows($c) == 1 Se Cumple 1
bibliotecario
mysql_num_rows($c) == 1 no se Cumple Se inicia sesin en
2
mysql_num_rows($c) == 1 Se cumple ejecutivo
mysql_num_rows($c) == 1 No se cumple
Se inicia sesin en
mysql_num_rows($c) == 1 No se cumple 3
estudiante
mysql_num_rows($c) == 1 Se cumple
4 Se inicia sesin en director
mysql_num_rows($c) == 1 Se cumple
mysql_num_rows($c) == 1 No se cumple Usuario o Password
mysql_num_rows($c) == 1 No se cumple 5
mysql_num_rows($c) == 1 No se cumple incorrectos
110
IMPORTAR.PHP
<?php
session_start();
include "libreria.php";
$con=conexion();
$tipo = $_FILES['archivo']['type'];
$tamanio = $_FILES['archivo']['size'];
$archivotmp = $_FILES['archivo']['tmp_name'];
$lineas = file($archivotmp);
$i=0;---------------------------------------------------------1
while ($lineas as $linea_num => $linea){ ---------------------------------2
if($i != 0) { ---------------------------------------------3
$datos = explode(";",$linea);
$ci = trim($datos[0]);
$nombre = trim($datos[1]);
$apellido = trim($datos[2]);
$direccion = trim($datos[3]);
$sexo = trim($datos[4]);
mysql_query("INSERT INTO usuario VALUES($ci,'$nombre',
'$apellido', '$direccion','sexo')");
mysql_query("INSERT INTO estudiante VALUES($ci,'$nombre
$apellido',MD5('$ci'))");---------------------------------------------------4
}
$i++;--------------------------------------------5
}---------------------------------------------6
header("location: ../est.php");--------------------------------------------7
?>
1.1 GRAFO DE FLUJO
7
3
111
1.2 COMPLEJIDAD CICLOMATICA V (G)
V (G) = A N + 2
V (G) = 8 7 + 2
V (G) =3
V (G) = C + 1
V (G) = 2 + 1
V (G) = 3
V (G) = R
V (G) = 3
DONDE:
N: # De Nodos. N=7

c1 = 1 2 7
c2 = 1 2 3 5 6 2 7
c3 = 1 2 3 4 5 6 2 7
1.4 CASOS DE PRUEBA
$lineas as $linea_num => $linea 1 Se termine el ciclo while

se Cumple
$lineas as $linea_num => $linea No se realiza la importacin de
No se cumple 2
$i != 0 datos
Se no cumple
$lineas as $linea_num => $linea
No se cumple Se realiza la importacin de
3
$i != 0 datos
Se cumple
112
CONSULTA.PHP
<?php
$c=mysql_query("SELECT * FROM multacei");------------------------------------1
{while($f=mysql_fetch_array($c)){-------------------------------------------2
$ci=consulta("ci","multa","codmulta",$f[0]);
$estado=consulta("estado","multa","codmulta",$f[0]);
$nombre=consulta("concat(nombre,' ',apellido)","usuario","ci",$ci);
$monto=consulta("montomulta","actividad","id",$f[2]);
$nombrep=consulta("nombre",'actividad','id',$f[2]);-----------------------------------3
if($estado=='porcobrar'){---------------------------------------------4
echo "<tr><th>$ci</th><th>$nombre</th><th>$f[3]</th>";
echo"<th>$nombrep</th><th>$f[4]</th><th>$montoBs</th><th>$estado</th
></tr>";------------------------------------------------5
}
}------------------------------------------------6
}------------------------------------------7
?>
1.1 GRAFO DE FLUJO
7
3
6
113
V (G) = A N + 2
V (G) = 8 7 + 2
V (G) =3
V (G) = C + 1
V (G) = 2 + 1
V (G) = 3
V (G) = R
V (G) = 3
DONDE:

N: # De Nodos. N=7
c1 = 1 2 7
c2 = 1 2 3 4 6 2 7
c3 = 1 2 3 4 5 6 2 7
1.4 CASOS DE PRUEBA
$f = mysql_fetch_array($c) 1 Se termine el ciclo while

No se Cumple
$f = mysql_fetch_array($c)
Se cumple 2 Vuelve al ciclo while
$estado == 'por cobrar'
No se cumple
$f = mysql_fetch_array($c)
Se cumple
3 Muestran datos de la consulta
$estado == 'por cobrar'
Se cumple
114
VERMULTA.PHP
<?php
$c=mysql_query("SELECT * FROM multa WHERE ci='".$_SESSION['ci']."'");-----1
while($f=mysql_fetch_array($c)){--------------------------------------2
$nombre=consulta("nombre","usuario","ci",$f[0]);
$id=consulta("id","multacei","codmulta",$f[1]);
$nombrep=consulta("nombre",'actividad','id',$id);
$mc=consulta("montomulta","actividad","id",$id);
$mb=consulta("monto","multabiblio","codmulta",$f[1]);
$desc = consulta("descripcion","multacei","codmulta",$f[1]);
$desb = consulta("descripcion","multabiblio","codmulta",$f[1]);---------------3
if($mc!=''){------------------------------------------------4
$mc="".$mc;
$desc = "CEISI - ".$desc;--------------------------------5
}
Else{
if($mb!=''){-------------------------------------------6
$mb="".$mb;
$desb = "BIB - ".$desb;--------------------------------------7
}
}
if ($f[5]=='porcobrar') {--------------------------------------8
echo "<tr><th>$f[1]</th><th>$f[2]</th><th>$nombrep</th>";
echo "<th>$desc $desb</th><th>$mc $mbBs</th><th>$f[5]</th></tr>";----9
}
}---------------------------------------------10
}----------------------------------11
?>
115
1.1 GRAFO DE FLUJO
11 3
6 5
10
116
V (G) = A N + 2
V (G) = 14 11 + 2
V (G) =5
V (G) = C + 1
V (G) = 4 + 1
V (G) = 5
V (G) = R
V (G) = 5
DONDE:

N: # De Nodos. N=11
c1 = 1 2 11
c2 = 1 2 3 4 5 8 9 10 2 11
c3 = 1 2 3 4 5 8 10 2 11
c4 = 1 2 3 4 6 8 10 2 11
c5 = 1 2 3 5 6 8 9 10 2 11
c6 = 1 2 3 4 6 7 8 9 10 2 11
c7 = 1 2 3 4 6 7 8 10 2 11
1.4 CASOS DE PRUEBA
$f=mysql_fetch_array($c) 1 Sale de ciclo while

No Se Cumple
$f=mysql_fetch_array($c))
Clculo del valor de la
Se Cumple
($mc != ' ') 2 multa, se muestra el nombre y
Se cumple
el monto de la multa
($f[5] == 'por cobrar')
Se cumple
117
$f=mysql_fetch_array($c))Se Cumple
($mc != ' ') Clculo del valor de la multa
Se cumple 3
($f[5] == 'por cobrar') con descuento del CEISI
Se cumple
($mc != ' ')
Clculo del valor de la multa
No se cumple
($mb != ' ') 4 sin descuento de la
No se cumple
BIBLIOTECA
No se cumple
($mc != ' ')
Clculo del valor de la multa
No se cumple
($mb != ' ') 5 con descuento de la
Se cumple
BIBLIOTECA
No se cumple
$f=mysql_fetch_array($c))Se Cumple Clculo del valor de la multa

($mc != ' ') sin descuento de la
No se cumple
($mb != ' ') 6 BIBLIOTECA y se muestra el
Se cumple monto de la multa
Se cumple
$f=mysql_fetch_array($c))Se Cumple Clculo del valor de la multa

($mc != ' ') sin descuento de la
No se cumple
7
($mb != ' ') BIBLIOTECA
No se cumple
Se cumple
118
PERFIL.PHP
<?php
if($_SESSION['tipo']=="b")---------------------------------1
include"templates/bibliotecario.php";-----------------------------2
elseif($_SESSION['tipo']=="ej")---------------------------------------3
include"templates/ejecutivo.php";---------------------------------4
elseif($_SESSION['tipo']=="e")-----------------------------------5
include"templates/estudiante.php";-----------------------------6
else($_SESSION['tipo']=="d")---------------------------------7
include"templates/director.php";------------------------------------8
$ci=$_SESSION['ci'];
$c=mysql_query("SELECT * FROM usuario WHERE ci='$ci'");
$f=mysql_fetch_array($c);
$nombre=$f['nombre'];
$apellido=$f['apellido'];
$direccion=$f['direccion'];
$sexo=$f['sexo'];-------------------------------------------9
?>
1.1 GRAFO DE FLUJO

1
3 2
5 4
7 6
9
119
V (G) = A N + 2
V (G) = 11 9 + 2
V (G) =4
V (G) = C + 1
V (G) = 3 + 1
V (G) = 4
V (G) = R
V (G) = 4

c1 = 1 2 9
c2 = 1 3 4 9
c3 = 1 3 5 6 9
c4 = 1 3 5 7 8 9
1.4 CASOS DE PRUEBA

Se inicia sesin en bibliotecario

$_SESSION['tipo'] == "b" 1
Se Cumple " Se obtiene datos de usuario"
$_SESSION['tipo'] == "b" Se inicia sesin en ejecutivo

No se Cumple 2
$_SESSION['tipo'] == "ej" " Se obtiene datos de usuario"
Se Cumple
$_SESSION['tipo'] == "b"
No se Cumple Se inicia sesin en estudiante
$_SESSION['tipo'] == "ej" 3
No se Cumple " Se obtiene datos de usuario"
$_SESSION['tipo'] == "e"
Se Cumple
$_SESSION['tipo'] == "b"
No se Cumple
$_SESSION['tipo'] == "ej" Se inicia sesin en director
No se Cumple 4
$_SESSION['tipo'] == "e" " Se obtiene datos de usuario"
No se Cumple
$_SESSION['tipo'] == "d"
Se Cumple
120
NUMERO_A_LETRA.PHP
function num_a_let($xcifra){
$xarray = array(0 => "Cero",1 => "UN", "DOS", "TRES", "CUATRO", "CINCO", "SEIS", "SIETE", "OCHO",
"NUEVE","DIEZ", "ONCE", "DOCE", "TRECE", "CATORCE", "QUINCE", "DIECISEIS", "DIECISIETE",
"DIECIOCHO", "DIECINUEVE", "VEINTI", 30 => "TREINTA", 40 => "CUARENTA", 50 => "CINCUENTA",
60 => "SESENTA", 70 => "SETENTA", 80 => "OCHENTA",90 => "NOVENTA",100 => "CIENTO", 200 =>
"DOSCIENTOS", 300 => "TRESCIENTOS", 400 => "CUATROCIENTOS",500 => "QUINIENTOS", 600 =>
"SEISCIENTOS",700 => "SETECIENTOS", 800 => "OCHOCIENTOS", 900 => "NOVECIENTOS");
$xcifra = trim($xcifra);
$xlength = strlen($xcifra);
$xpos_punto = strpos($xcifra, ".");
$xaux_int = $xcifra;
$xdecimales = "00";-------------------------------------------1
if(!($xpos_punto === false)) {-------------------------------------------2
if ($xpos_punto == 0) {-------------------------------------------3
$xcifra = "0" . $xcifra;
$xpos_punto = strpos($xcifra, ".");-------------------------------------------4
}
// obtengo el entero de la cifra a convertir
$xaux_int = substr($xcifra, 0, $xpos_punto);
// obtengo los valores decimales
$xdecimales = substr($xcifra . "00", $xpos_punto + 1, 2); -------------------------------------------5
}
// ajusto la longitud de la cifra, para que sea divisible por centenas de miles (grupos de 6)
$XAUX = str_pad($xaux_int, 18, " ", STR_PAD_LEFT);
$xcadena = "";
$xz=0; -------------------------------------------6
while ($xz< 3) {-------------------------------------------7
$xaux = substr($XAUX, $xz * 6, 6);
$xi = 0;
// inicializo el contador de centenas xi y establezco el lmite a 6 dgitos en la parte entera
$xlimite = 6;
// bandera para controlar el ciclo del While

$xexit = true; -------------------------------------------8
while ($xexit) {-------------------------------------------9
// si ya lleg al lmite mximo de enteros
if ($xi == $xlimite) { -------------------------------------------10
break; // termina el ciclo-------------------------------------------11
}
// comienzo con los tres primeros digitos de la cifra, comenzando por la izquierda
$x3digitos = ($xlimite - $xi) * -1;
// obtengo la centena (los tres dgitos)
$xaux = substr($xaux, $x3digitos, abs($x3digitos));
$xy = 1; -------------------------------------------12
121
// ciclo para revisar centenas, decenas y unidades, en ese orden
while ($xy< 4) { -------------------------------------------13
switch ($xy) {-------------------------------------------14
case 1: // checa las centenas
if (substr($xaux, 0, 3) < 100) { -------------------------------------------15
// si el grupo de tres dgitos es menor a una centena (< 99) no hace
nada y pasa a revisar las decenas
}
else {
$key = (int) substr($xaux, 0, 3); --------------------------------16
// busco si la centena es nmero redondo (100, 200, 300,
400, etc..)
if (TRUE === array_key_exists($key, $xarray)){ --------------17
$xseek = $xarray[$key];
// devuelve el subfijo correspondiente (Milln, Millones, Mil
o nada)
$xsub = subfijo($xaux); -------------------------------------------18
if (substr($xaux, 0, 3) == 100) -------------------------------------19
$xcadena = " " . $xcadena . " CIEN " . $xsub; -------20
else
$xcadena = " " . $xcadena . " " . $xseek . " " . $xsub;
// la centena fue redonda, entonces termino el ciclo
del for y ya no reviso decenas ni unidades
$xy = 3; -------------------------------------------21
}
else{ // entra aqu si la centena no fue numero redondo

(101, 253, 120, 980, etc.)
$key = (int) substr($xaux, 0, 1) * 100;
// toma el primer caracter de la centena y lo multiplica por
cien y lo busca en el arreglo
$xcadena = " " . $xcadena . " " . $xseek; --------------------22
} // ENDIF ($xseek)
} // ENDIF (substr($xaux, 0, 3) < 100)
break; -------------------------------------------23
case 2: // checa las decenas (con la misma lgica que las centenas)
if (substr($xaux, 1, 2) < 10) {-------------------------------------------24
} else {
$key = (int) substr($xaux, 1, 2); -------------------------------25
if (TRUE === array_key_exists($key, $xarray)) {---------------26
$xsub = subfijo($xaux); -----------------------------------------27
if (substr($xaux, 1, 2) == 20) -----------------------------------28
$xcadena = " " . $xcadena . " VEINTE " .$xsub; ------29
else
122
$xcadena = " " . $xcadena . " " . $xseek . " " . $xsub;
$xy = 3; -------------------------------------------30
}-------------------------------------------31
else {
$key = (int) substr($xaux, 1, 1) * 10;
$xseek = $xarray[$key]; ------------------------------------------32
if (20 == substr($xaux, 1, 1) * 10) -------------------------------33
$xcadena = " " . $xcadena . " " . $xseek; -------------34
else
$xcadena = " " . $xcadena . " " . $xseek . " Y ";-------35
} // ENDIF ($xseek) -------------------------------------------36
break; -------------------------------------------37
case 3: // checa las unidades

38-------------if (substr($xaux, 2, 1) < 1) { // si la unidad es cero, ya no hace nada
} else {
$key = (int) substr($xaux, 2, 1);
$xseek = $xarray[$key]; // obtengo directamente el valor de
la unidad (del uno al nueve)
$xsub = subfijo($xaux);
$xcadena = " " . $xcadena ." " . $xseek . " " . $xsub; ---------39
break; -------------------------------------------4 0
} // END SWITCH
$xy++;-------------------------------------------41
} // END FOR
$xi = $xi + 3; -------------------------------------------42
} // ENDDO
// si la cadena obtenida termina en MILLON o BILLON, entonces le agrega al final la
conjuncion DE
if (substr(trim($xcadena), -5, 5) == "ILLON") -------------------------------------------43
$xcadena.= " DE";-------------------------------------------44
// si la cadena obtenida en MILLONES o BILLONES, entoncea le agrega al final la conjuncion
DE
if (substr(trim($xcadena), -7, 7) == "ILLONES") -------------------------------------------45
$xcadena.= " DE";-------------------------------------------46
// ----------- esta lnea la puedes cambiar de acuerdo a tus necesidades o a tu pas -------
if (trim($xaux) != "") {-------------------------------------------47
switch ($xz) {-------------------------------------------48
case 0:
if (trim(substr($XAUX, $xz * 6, 6)) == "1")-------------------------------------------49
$xcadena.= "UN BILLON ";-------------------------------------------50
else
$xcadena.=" BILLONES ";-------------------------------------------51
123
break; -------------------------------------------52
case 1:
if (trim(substr($XAUX, $xz * 6, 6)) == "1")-------------------------------------------53
$xcadena.= "UN MILLON ";-------------------------------------------54
else
$xcadena.=" MILLONES ";-------------------------------------------55
break; -------------------------------------------56
case 2:
if ($xcifra< 1) {-------------------------------------------57
$xcadena = "CERO Bolivianos $xdecimales/100 ";--------------------58
}
if ($xcifra>= 1 && $xcifra< 2) {-------------------------------------------59
$xcadena = "UN Boliviano $xdecimales/100 ";----------------------60
}
if ($xcifra>= 2) {-------------------------------------------61
$xcadena.= " Bolivianos $xdecimales/100 "; -------------------------62
}
break; -------------------------------------------63
} // endswitch ($xz)
} // ENDIF (trim($xaux) != "")
// ------------------ en este caso, para Mxico se usa esta leyenda ----------------
// quito el espacio para el VEINTI, para que quede: VEINTICUATRO, VEINTIUN, etc
$xcadena = str_replace("VEINTI ", "VEINTI", $xcadena);
$xcadena = str_replace(" ", " ", $xcadena); // quito espacios dobles
$xcadena = str_replace("UN UN", "UN", $xcadena); // quito la duplicidad
$xcadena = str_replace(" ", " ", $xcadena); // quito espacios dobles
$xcadena = str_replace("BILLON DE MILLONES", "BILLON DE", $xcadena); // corrigo la
leyenda
$xcadena = str_replace("BILLONES DE MILLONES", "BILLONES DE", $xcadena); // corrigo la
leyenda
$xcadena = str_replace("DE UN", "UN", $xcadena); // corrigo la leyenda
$xz++;-------------------------------------------64
} // ENDFOR ($xz)
return trim($xcadena); -------------------------------------------65
}------------------------------------------66
124
GRAFO DE FLUJO
1
10
11
12
13
14
15 24 38
16 25 39
17 26 40
18
32 27
19
33 28
22 21 20
35 34 30 29
23
36 31
37
41
42
43
4
4
45
4
6
47
48
57
49
53
58
51 50 55
54
59
52
56
60
61
62
63
64
65
125
COMPLEJIDAD CICLOMATICA V (G)
V (G) = A N + 2
V (G) = 94 66 + 2
V (G) =30
V (G) = C + 1
V (G) = 29+ 1
V (G) = 30
V (G) = R
V (G) = 30
DONDE:

N: # De Nodos. N=66
c1 = 1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-49-50-52-64-65-66
c2 = 1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-49-51-52-64-65-66
c3 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-53-54-56-64-65-66
c4 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-53-55-56-64-65-66
c5 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-59-61-63-64-65-66
c6 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-58-59-61-63-64-65-66
c7 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-58-59-60-61-63-64-65-66
c8 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-58-59-60-61-62-63-64-65-66
c9 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-49-50-52-64-7-65-66
c10 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-49-51-52-64-7-65-66
c11 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-53-54-56-64-7-65-66
c12 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-53-55-56-64-7-65-66
c13 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-59-61-63-64-7-65-66
c14 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-58-59-61-63-64-7-65-66
c15 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-58-59-60-61-63-64-7-65-66
c16 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-48-57-58-59-60-61-62-63-64-7-65-66
c17 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-64-65-66
c18 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-45-47-64-7-65-66
c19 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-44-45-46-47-64-65-66
c20 =1-2-6-7-8-9-10-12-13-14-15-16-17-18-19-20-23-41-42-43-44-45-46-47-64-7-65-66
c21 =1-2-6-7-8-9-10-12-13-14-15-22-23-41-42-43-44-45-46-47-64-65-66
c22 =1-2-6-7-8-9-10-12-13-14-15-23-41-42-43-44-45-46-47-64-65-66
c23 =1-2-6-7-8-9-10-12-13-14-24-25-26-27-28-29-31-37-41-42-43-44-45-46-47-64-65-66
c24 =1-2-6-7-8-9-10-12-13-14-24-25-26-27-28-30-31-37-41-42-43-44-45-46-47-64-65-66
c25 =1-2-6-7-8-9-10-12-13-14-24-25-26-32-33-34-36-37-41-42-43-44-45-46-47-64-65-66
c26 =1-2-6-7-8-9-10-12-13-14-24-25-26-32-33-35-36-37-41-42-43-44-45-46-47-64-65-66
c27 =1-2-6-7-8-9-10-12-13-14-38-39-40-41-42-43-44-45-46-47-64-65-66
c28 =1-2-6-7-8-9-10-12-13-14-38-40-41-42-43-44-45-46-47-64-65-66
c29 =1-2-3-4-5-6-7-8-9-10-11-12-13-42-9-43-44-45-46-47-64-65-66
c30 =1-2-3-4-5-6-7-8-9-10-11-12-13-42-9-43-44-45-46-47-64-7-65-66
126
13.2. PRUEBAS DE CAJA NEGRA
1.-Autenticar usuario. - en este cuadro es donde el estudiante, ejecutivo bibliotecaria y director de

carrera pondrn su nombre de usuario y contrasea (Password) para ingreso al sistema y las entradas
de datos son:
Nombre = max 40 solo caracteres
Password = max 20 caracteres
ENTRADA CLASES VALIDAS CLASES NO VALIDAS

NOMBRE (TIPO: CADENA) 1) Nombre >=1 carcteres 3) Nombre=0 caranteres
2) Nombre <=40 caracteres 4) Nombre>40 caranteres
PASSWORD (TIPO CADENA) 5) Password>=1 carcteres 7) Password=0 carcteres
6) Password<=20 carcteres 8) Password>=20 carcteres
CASOS DE PRUEBA
CLASE DE RESULTADO
CONDICION DE ENTRADA OBSERVACIONES
EQUIVALENCIA ESPERADO
Nombre: juan 1) OK ninguna
Passwor: 12345 5) OK
Nombre: juan jose 2) OK ninguna
Passwor: 7468234897 6) OK
Nombre: 3) Llene este ninguna
Passwor: campo
7) Llene este
campo
Nombre: juan jose sarmiento 4) Llega hasta La aplicacin no
domingo murillo de las casas del cierto punto y permitir escribir ms
paraiso no escribe de lmites
Passwor: 8) establecidos
123456789101112131415161718 Llega hasta
cierto punto y
no escribe
127
2.-Buscar (Search). - En este cuadro se buscar al estudiante filtrando la informacin que tiene y las
entradas de datos son:
Search = max 50 caracteres

Search (TIPO: CADENA) 1) Nombre >=1 carcteres 3) Nombre=0 caranteres
CASOS DE PRUEBA
CONDICION DE CLASE DE RESULTADO

OBSERVACIONES
ENTRADA EQUIVALENCIA ESPERADO
Search: ramiro 1) OK ninguna
Search: ramiro flores 2) OK ninguna

Search : 3) ninguno ninguna
Search: alejandro pinto 4) Llega hasta La aplicacin no

Cardozo de las lomas del caribe cierto punto y permitir escribir ms
aguas ardientes no escribe de lmites establecidos
128
3.- PERFIL DE USUARIO. - en este cuadro los usuarios del sistema cambiaran su contrasea de
ingreso al sistema y las entradas de datos son:
Ci = bloqueado
Nombre = bloqueado
Apellido = bloqueado
Direccin = bloqueado
Sexo = bloqueado
Password = max 20 caracteres

pasword (TIPO: CADENA) 1) Nombre >=1 carcteres 3) Nombre=0 caranteres
CASOS DE PRUEBA
CLASE DE RESULTADO
Passwor: 12345 1) OK ninguna
Passwor: 7468234897 2) OK ninguna
Llene este
Passwor: 3) campo ninguna
La aplicacin no
Llega hasta
Passwor: permitir escribir ms
4) cierto punto y
123456789101112131415161718 de lmites
no escribe
establecidos
Nota: los campos (ci nombre apellido direccin sexo) no se tomaron en cuenta para la prueba
porque son campos bloqueados
129
4.-REGISTRAR ADMINISTRADOR. - en este cuadro se registra al administrador con la entrada
de datos:
Nombre = max 20 caracteres
Apellido = max 30 caracteres
Carnet = min 1000000; max 9999999999
Direccin = max 50 caracteres
Sexo = Hombre, Mujer. Otro

Nombre (TIPO: CADENA) 1) Nombre >=1 carcteres 3) Nombre=0 caranteres
Apellido (TIPO CADENA) 5) Apellido>=1 carcteres 7) Password=0 carcteres
6) Apellido<=30 carcteres 8) Password>=30 carcteres
Carnet (TIPO: ENTERO) 9) 10000000<=Carnet<=9999999999 10) Apellido<1000000
11) Apellido>9999999999
Direccin (TIPO CADENA) 12) Direccin >=1 carcteres 14) Direccin =0 carcteres
13) Direccin <=50 carcteres 15) Direccin >=50 carcteres
130
CASOS DE PRUEBA
CLASE DE RESULTADO
Nombre: juan 1) OK ninguna
Apellido: perez 5) OK
Carnet:1234567 9) OK
Direccion: bolvar tacna 12) OK
Nombre: jose 2) OK ninguna
Apellido: Lopez 6) OK
Carnet:1234567 9) OK
Direccin: bolvar Tacna Arica 13) OK
Nombre: 3) Llene este La aplicacin no
Apellido: 7) campo permitir escribir ms
Llene este de lmites
Carnet:1234 10) campo establecidos
Escriba datos
Direccin: bolvar Tacna Arica 14) desde 1000000
a 999999999
Llene este
campo
Nombre: juan jose manuel Elmer 3) Llega hasta La aplicacin no
cierto punto y permitir escribir ms
Apellido: Arismendi de las casas 7) no escribe de lmites
y zenteno zurita de flores Llega hasta establecidos
cierto punto y
Carnet:123456745465465 10) no escribe
Escriba datos
Direccin: bolvar Tacna Arica 14) desde 1000000
pasaje zaabedra circunvalacin a 999999999
oeste Llega hasta
cierto punto y
no escribe
Nota: los campos (sexo) no se tomaron en cuenta para la prueba porque son campos
desplegables
131
5.- REGISTRAR MULTA. - es donde se le asigna una multa de CEI con las siguientes entradas de
datos:
Actividad = combobox(SELECT * FROM actividad)
Estudiante = combobox
Descripcion = max 30 caracteres

Descripcin (TIPO: 1) Descripcin >=1 carcteres 3) Descripcin =0 caranteres
CADENA) 2) Descripcin <=30 caracteres 4) Descripcin >30 caranteres
CASOS DE PRUEBA
CONDICION DE CLASE DE RESULTADO

OBSERVACIONES
ENTRADA EQUIVALENCIA ESPERADO
Descripcin: no 1) OK ninguna
asisti
Descripcin: falto a 2) OK ninguna
la actividad
Descripcin: 3) Llene este ninguna
campo
Descripcin: no 4) Llega hasta La aplicacin no

asisti a la actividad cierto punto y permitir escribir ms
de asamblea no escribe de lmites establecidos
Nota: los campos (actividad y estudiante) no se tomaron en cuenta para la prueba porque son
campos desplegables
132
6.-REGISTRAR ACTIVIDAD. - es donde el ejecutivo registra una actividad con la siguiente entrada
de datos:
Nombre = max 20 caracteres
Monto multa = min 1; max 999
Descripcin = max 30 caracteres
Fecha = min 2000; max 2020

Nombre (TIPO: 1) Nombre >=1 carcteres 3) Nombre=0 caranteres
CADENA) 2) Nombre <=20 caracteres 4) Nombre>20 caranteres
Monto (TIPO 5) 1<=Monto<=999 6) Apellido<1
ENTERO) 7) Apellido>999
Descripcin (TIPO: 8) Descripcin >=1 carcteres 10) Descripcin =0 caranteres
ENTERO) 9) Descripcin <=30 caracteres 11) Descripcin >30 caranteres
CASOS DE PRUEBA
CONDICION DE ENTRADA CLASE DE RESULTADO OBSERVACIONES

Nombre: asamblea 1 1) OK ninguna
Monto:4 5) OK
Descripcin: en sala de conferencias 8) OK
Nombre: asamblea 2 2) OK ninguna
Monto:6 5) OK
Descripcin: en el patio 9) OK
Nombre: 3) Llene este campo La aplicacin no
Escriba datos permitir escribir ms
Monto: 0 6) desde 1000000 a de lmites
999999999 establecidos
Descripcin: 10) Llene este campo
Nombre: farndula de la carrera de 3) Llega hasta cierto La aplicacin no
ingeniera de sistemas e informtica punto y no escribe permitir escribir ms
Escriba datos de lmites
Monto:1234 6) desde 1000000 a establecidos
999999999
Descripcin: iniciara en la playa de 10) Llega hasta cierto
estacionamiento y se tomara punto y no escribe
asistencia con una ficha
Nota: los campos (fecha) no se tomaron en cuenta para la prueba porque es campo de seleccin
133
14. ESTRATEGIAS DE PRUEBA

Se requiere certificar por parte del equipo de desarrollo y por parte del usuario al SISTEMA DE COBRO
DE MULTAS DE BIBLIOTECA CEISI en dos etapas, que administre y gestione las multas generadas
por las actividades desarrolladas por el CEISI. Por ende, se debe verificar:
1ra. Etapa: Que las funcionalidades de los mdulos del Sistema y de Revisin son operativas.
2da. Etapa: Que las funcionalidades integradas de los mdulos del Sistema, Revisin y Aprobacin
son operativas.
Conjuntamente los sub-objetivos para los tres mdulos se resumen de la siguiente forma:
El ingreso y la postulacin de las propuestas tcnicas
La creacin, modificacin y eliminacin de documentos asociados al Sistema de cada grupo de
estudiantes.
La creacin, modificacin y eliminacin de tareas (actividades) asociadas al Centro de
Estudiantes
de Ingeniera de Sistemas e Informtica.
La revisin y aprobacin de los entregables de cada proyecto.
La visualizacin, modificacin y eliminacin del calendario de evaluaciones y reuniones.
Que los documentos y actividades se generen con su estado correspondiente en el sistema.
Ser necesario indicar como objetivo realizar las pruebas de los mdulos para la gestin y administracin
del Sistemas de Cobro de Multas. Esto se refiere a verificar y validar los resultados o salidas generados.
Un objetivo importante es la utilizacin de tcnicas formales de prueba (RTFs.: Estticas y Dinmicas).
ESCENARIO DE LAS PRUEBAS
Para cumplir con los objetivos planteados deben existir tres escenarios, que son, Pruebas de Instalacin,
Pruebas de GUI o Interfaz y Pruebas de Operacin o Funcionales.
Para las Pruebas de Instalacin se debe comprobar que:
Aplicacin no presenta anomalas.

Que apunta al servidor y base de datos definidos.
Para las pruebas de GUI se debe comprobar que:
Comportamiento de aplicacin con casos de bordes invlidos y vlidos, donde las pruebas de
borde se definen como aquellas pruebas en las cules los datos de prueba a utilizar son valores
lmites.
Carga, despliegue, foco, modalidad, navegabilidad y usabilidad de las GUI del Sistema y sus
elementos. Donde las mtricas y Heursticas de usabilidad y funcionalidad a utilizar son las
siguientes:
Comprensin Global del Sitio.
Aspectos de Interfaces y Estticos.
Mtricas de confiabilidad.
Navegacin y Exploracin.
Para las pruebas de Operacin o Funcionales se debe comprobar:
El comportamiento de aplicacin con casos invlidos y vlidos, de flujo completo del proceso de
las propuestas y proyectos.
los documentos generados por el usuario.
134
las diferentes actividades relacionadas.
El comportamiento de la aplicacin para el mdulo de Registros.
El comportamiento de la aplicacin para el mdulo de Revisin.
El comportamiento de la aplicacin para el mdulo de Aprobacin.
ORDEN DE EJECUCIN DE PRUEBAS

Las pruebas se llevarn a cabo de la siguiente forma:
Secuencias de pasos para la Configuracin
Configuracin de los Equipos Cliente y del Servidor de Aplicacin Web y de Base de Datos
Secuencias de pasos para la generacin de archivos para los tres mdulos.
Ejecucin de proceso (manual) de generacin de archivos de salida con la informacin de los

usuarios
para alimentar al sistema.
Secuencias de pasos para la generacin de datos para los tres mdulos.
Ejecucin del proceso (manual) de generacin de datos, donde las tablas y campos a utilizar sern
llenados manualmente.
135
15. CONCLUCIONES Y RECOMENDACIONES
Se desarroll un sistema de informacin para optimizar el manejo del sistema de registro de datos y
reportes y poder sincronizar el manejo de control de cobro de multas, control de ingresos egresos que se
da en la carrera de Ingeniera de Sistemas e Informtica, brindar a los usuarios un servicio eficiente en el
registro de multas. Una vez concluido el sistema de informacin y despus de haber hecho las pruebas
respectivas se llega a la conclusin de que es un sistema que cumple con las necesidades requeridas y
cumple con los objetivos del proyecto.
16. BIBLIOGRAFIA
- Ingenieria-de-software-orientada-a-objetos-con-uml-java-e-internet
- Pressman, R.S. Ingeniera del Software
- http://www.getboostrap.com
- http://www.uml.org
136

Proy Final Ing Software

Cargado por

Información del documento

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

Proy Final Ing Software

Cargado por

Copyright:

Formatos disponibles

U.T.O. F.N.I.

Universidad Tcnica de Oruro

TEMA: SISTEMA DE COBRO DE

BIBLIOTECA CEI -SI

El sistema de cobro de multas es realizado por los siguientes:

3. FORMULACION DEL PROBLEMA

3.1.DESCRIPCION DE SITUACIONES PROBLEMATICAS

3.2.PLANTEAMIENTO DEL PROBLEMA

4. PLANTEAMIENTO DEL OBJETIVOS

R8 El sistema debe permitir Al director de carrera ver reportes de deudores de

R9 El sistema debe permitir ver recaudaciones de multa (ver recaudaciones)

REFERENCIA ATRIBUTO DETALLE

El software tendr distintos niveles de accesos:

El software debe ser manejable y adaptable al

Recursos humanos: Director de Carrera, Bibliotecaria/rio, ejecutiva/ivo del CEI-SI, docente,

- La bibliotecaria/rio requiere de documentos personales para poder realizar el prstamo

ESTADO DEL SISTEMA

- El registro de multas en exceso provoca que el estudiante no realice el pago de ella.

- Nuevas actividades a realizar.

Conoce a alguien que sepa del problema? Puede contactarlo?

Docente bibliografa Universitario Bibliotecaria

f) Definir necesidades de cambio

i) Evaluar las alternativas

j) Elegir una alternativa

DESCRIPCIN DEL NEGOCIO

El Centro de Estudiantes de la carrera de Sistema-Informtica realiza actividades que mantengan

7.4.2. MODELO DE ANLISIS DE NEGOCIO

7.4.3. ESPECIFICACIN DE ACTORES DEL NEGOCIO

ACTOR Director de carrera

7.5. DIAGRAMA DE CASOS DE USO DEL SISTEMA

Ver recaudaciones biblioteca

Ver reportes biblioteca

gestionar Uusario imprimir reportes

Ver multa Biblioteca

Ver MUlta CEI

cobrar multa Biblioteca

7.6. ESPECIFICACIN DE CASOS DE USO

Nombre de caso Validar

Actores Est relacionado con los actores Usuario (Director de carrera,

Sub flujos Entrar al sistema

Nombre de caso Ver

Actores Est relacionado con los actores Usuario( Bibliotecaria,

Precondiciones Validar usuario

Sub flujos Preguntar por nombre

Nombre de caso Cobrar multa

Actores Est relacionado con los actores Usuario( Bibliotecaria y

Nombre de caso de Cobrar multa CEI

Actores Est relacionado con los actores Usuario( Ejecutivo y

Nombre de caso Imprimir

Flujo normal Validar usuario (Bibliotecaria o Ejecutivo), ver multa, cobrar

Nombre de caso Registrar

Nombre de caso Registrar multa

Sub flujos Validar usuario ejecutivo, Ver multa y Cobrar multa

Nombre de caso Ver reporte CEI

Nombre de caso Ver reporte

Actores Director de carrera

Nombre de caso Imprimir

Nombre de caso Ver recaudaciones CEI

Nombre de caso Ver recaudaciones

7.7. DIAGRAMA DE CLASES

7.8. DESCRIPCION DE LAS CLASES

Nombre de la clase Descripcin

Nombre de la clase Descripcin

7.9. DIAGRAMA DE ANALISIS CLASES SEGN CASOS DE USO