Tesis Final

Ta l ler Integral de Proyectos Informáticos
PASM
(Plataforma administrativa de subsidios municipales)
“Trabajo de proyecto integral para optar al título de

Ingeniero en Informática”
Lucas Olate
Silvia L. Reyes Q.
Taller Integral De Proyectos Informaticos
Índice
Índice ...............................................................................................................................................2
INTRODUCCION ...........................................................................................................................1
3. IDENTIFICACIÓN DEL PROBLEMA .....................................................................................3
3.1. Identificación de la Empresa..................................................................................3
3.2. Especificación de situación actual ......................................................................3
3.3. Evaluación de situación actual .............................................................................3
FODA: .......................................................................................................................................4
CAME: .......................................................................................................................................5
4. SISTEMA A REALIZAR ..........................................................................................................6
4.1 Especificación de Requerimientos ......................................................................6
4.1.1. Requerimientos SOLICITADOS .............................................................................8
4.1.2. Clasificación de requerimientos (tipo e importancia) .....................................9
4.2 Breve Descripción De La Solución A Desarrollar............................................. 11
4.3 Objetivo General Del Sistema A Desarrollar................................................... 14
4.4 Objetivo Específico Del Sistema A Desarrollar ................................................... 14
4.5. Ámbito Y Delimitación De La Solución ............................................................ 15
5. Factibilidad del proyecto...................................................................................................... 16
5.1. Factibilidad TÉCNICA (desarrollo). ................................................................... 16
5.2 Factibilidad ECONÓMICA (desarrollo)................................................................... 17
5.3. Factibilidad OPERACIONAL (desarrollo). ....................................................... 17
5.4 Factibilidad legal (desarrollo). ................................................................................. 18
FACTIBILIDAD NUMERO 2: ................................................................................................. 19
5.1. Factibilidad TÉCNICA ........................................................................................... 19
5.2 Factibilidad ECONÓMICA (desarrollo)................................................................... 20
5.3. Factibilidad OPERACIONAL (desarrollo). ....................................................... 21
5.4 Factibilidad legal (desarrollo). ............................................................................... 22
5.5 Factibilidad de implementación (Usuario). ........................................................... 22
5.6. Identificación de solución ................................................................................... 23
5.6.1 Identificación y Justificación SELECCIÓN ..................................................... 23
5.6.2 Proyeción De Solucion A Implementar ............................................................ 24
6. Planificación de actividades................................................................................................ 25
6.1. Identificación y justificación de METODOLOGÍA de desarrollo utilizada
25
Modelo de Prototipo .......................................................................................................... 25
Desarrollo Evolutivo .......................................................................................................... 26
Justificación ........................................................................................................................ 27
6.2. Identificación De Equipo De Trabajo ....................................... 28

Roles:............................................................................................................................................ 28
Justificación del equipo de trabajo ..................................................................................... 28
6.3. Plan de Contingencia ............................................................................................ 29
6.4. Representación gráfica de planificación temporal ....................................... 31
7. Diseño LÓGICO Del Proyecto............................................................................................ 34
7.1 Diagramas Para Diseño De Sistema..................................................................... 34
7.1.2. Diagrama De Actividad ......................................................................................... 35
7.1.3 Diagrama De Estado.............................................................................................. 42
7.1.4 Diagrama De Clases .............................................................................................. 42
7.1.5 Diagrama De Componente................................................................................... 43
7.2 Modelo De Base De Datos ....................................................................................... 44
Modelo Entidad Relación .................................................................................................... 45
7.3. Layout......................................................................................................................... 46
8. PLANES DE PRUEBA .................................................................................................... 50
8.1 IDENTIFICACIÓN TIPO DE PRUEBA....................................................................... 50
9. Conclusión ........................................................................................................................ 55
10. BIBLIOGRAFIA (Norma APA) ........................................................................................... 57
11. Anexos ................................................................................................................................... 58
11.1 DOCUMENTACIÓN DE TECNICA DE RECOLECCIÓN DE DATOS
(TECNICA DE RECOLECCIÓN DE DATOS UTILIZADA, PARA SU
DESARROLLO). .................................................................................................................. 58
Encuesta ................................................................................................................................... 58
Brainstorming ........................................................................................................................... 60
Alternativa: ................................................................................................................................ 61
11.2 DOCUMENTACIÓN DE METODOLOGIA USADA (COMO MÍNIMO DEBE
DE PRESENTAR 6 HOJAS). ............................................................................................. 62
Justificación ........................................................................................................................ 68
11.3 ESTANDARIZACIÓN DE DESARROLLO (Estándares de definición de
variables, Documentación de código y Mensajes de error). .................................. 69
11.4 DICCIONARIO DE DATOS .................................................................................... 71
11.5 Diseño Físico Del Proyecto (Desarrollo De Aplicación En Lenguaje
Seleccionado)...................................................................................................................... 74
11.6 Control De Version De Sw A Entregar (Estructura Que Debe De Contener
El Documento)..................................................................................................................... 83
11.7 Controles De Tareas O Bitácora. ....................................................................... 84
11.8 Documentación De Seguimiento ....................................................................... 84
11.9 Planificación de control de riesgos identificados......................................... 85
11.10 Representación Gráfica De Planificación Temporal .................. 88

11.11 Documentación Del Plan De Prueba ................................................................. 92
INTRODUCCION
La presente investigación tiene como destino el desarrollo de una plataforma

municipal que abarque todas las necesidades que el cliente siente que no posee
en su lugar de trabajo o en las herramientas que se le facilitan para realizar su
trabajo.
Actualmente, en una sociedad donde la información se volvió parte crucial de los

procesos de la empresa, estas requieren un manejo correcto de la información ya
que esto permite mejorar la toma de las decisiones dentro de la empresa como
también tener un mejor manejo de datos y tabulación de estos mismos.
Se entiende que la necesidad principal de una empresa es localizar la información

y focalizarla de forma correcta después de su estudio o uso para satisfacer de
mejor manera al cliente o las necesidades internas de la empresa.
Existe mucha información que actualmente está siendo ingresada, alimentando

sistemas que quizás difícilmente se volverá a utilizar, por lo que una necesidad de
las empresas es reducir el almacenamiento de información, pero manteniendo la
capacidad de almacenar solo información con mucha utilidad para los procesos
necesarios en su correcto funcionamiento.
En el transcurso de este proyecto pasaremos por distintas etapas que son

cruciales para comprender las necesidades verdaderas de la empresa:
Primero se comprenderá la empresa, se analizará quienes son, que hacen y para

quien lo hacen, analizando la situación actual de la empresa, el cómo realizan sus
procesos y que herramientas utilizan, con la finalidad de lograr una conclusión de
la empresa asignando una evaluación de esta misma.
Luego la parte fundamental de cualquier desarrollo de software se hará participe,

los requerimientos serán especificados mediante distintas metodologías de
obtención de estos mismos, se analizarán los requerimientos solicitados y se
generará una importancia de estos mismos mediante una clasificación de
requerimientos. En conjunto a la especificación de los requerimientos se realizará
una descripción de la solución que contendrá los objetivos generales, objetivos
específicos y delimitaciones del sistema, todo obtenido gracias a los
requerimientos y el análisis de estos.
Para continuar con el desarrollo del proyecto se generarán factibilidades, las

cuáles serán técnica, económica, operacional, legal e implementación, las cuáles
nos darán una visión de qué es lo que el equipo de desarrollo necesitará para
hacer posible la creación de esta solución. Con distintos puntos de vista se
seleccionará entre las generadas la que más se adecue al desarrollo de este
sistema para concluir este punto con una proyección de la misma solución.
En el siguiente punto que se cubrirá en este proyecto será la planificación de las

actividades requeridas para el desarrollo del sistema, aquí se investigarán distintas
Page | 1
metodologías de desarrollo, se identificarán los equipos de trabajo,

se crearán planes de contingencia, diagramas EDT y la planificación del proyecto
elaborado en una herramienta case, además se priorizarán los riesgos,
estableciendo niveles de impacto y catalogándolos.
Continuando se realizará el diseño lógico del sistema, aquí comienza a tomar

forma con el desarrollo de distintos diagramas como casos de uso, actividades,
estados, clases, componentes y el desarrollo del modelo de base de datos en
conjunto con los layouts que corresponden a la primera impresión grafica de los
mantenedores involucrados en el sistema.
A continuación, se identificarán los tipos de prueba y los datos que se utilizarán

para estas mismas, con lo que concluirá parcialmente la gestión del proyecto para
dar paso al desarrollo de este mismo sin más preámbulos.
Page | 2
3. IDENTIFICACIÓN DEL PROBLEMA
3.1. Identificación de la Empresa
Nombre de la Empresa: MUNICIPALIDAD DE LOS ÁNGELES.

Área en la que se implementará: DEPARTAMENTO DE SUBSIDIOS.
Proceso Involucrado: ADMINISTRACIÓN DE SUBSIDIOS.
Responsable del proyecto: LUCAS ESTEBAN OLATE ZAPATA.
3.2. Especificación de situación actual
Este sistema fue solicitado por el jefe del departamento de subsidios

protestando por el poco orden que se mantiene en los procesos internos,
buscando una solución de interfaz simple pero que logre Administrar y
tabular la información que manejan en estos procesos y la información que
poseen los usuarios.
Al mencionar el poco orden que se lleva a cabo en el proceso refiere a la
recepción de documentación y a su almacenamiento sin un orden y sin
sentido, ya que los documentos se solicitan, pero se almacenan en cajas
que jamás volverán a ser abiertas, es decir, la documentación es requerida
para optar a la asignación de algunos subsidios, pero esta no vuelve a ser
utilizada por lo que sólo se convierte en un requisito de presentación y no
un requisito que vaya a ser verificado en un futuro.
El beneficiario asiste a su registro en un subsidio, este entrega la
información solicitada por este subsidio, ya sea algún tipo de
documentación como por ejemplo certificados de control de niño sano o un
certificado de alumno regular.
Estos papeles son almacenados en cajas y el registro del subsidio va a una
plataforma que provee la municipalidad, la cual posee ciertos déficits a las
necesidades de los empleados municipales, que es por uno de los puntos
por lo que se solicita este sistema.
Dejando en evidencia su necesidad del desarrollo de un sistema que
abarque la información y logre Manejarla de forma efectiva, permitiendo la
oportunidad de su desarrollo.
La cantidad de usuarios que actualmente utilizan subsidios y que se
atienden sólo en Los Ángeles son sobre 27.000 Usuarios, por lo que una
solución de esta índole, bien alimentado de información será de mucha
utilidad tanto para los usuarios de este, como para los trabajadores que
actúan directamente manipulando la plataforma.
3.3. Evaluación de situación actual
La información que se mantiene actualizada es de difícil acceso o no existe

una motivación por buscar entre decenas de kilos de papeles.
No se lleva un control de los subsidios, por lo que se hace difícil el acceso
a la información además de imposibilitar tareas de ayuda que se podrían
realizar.
No existe la posibilidad de generar información con fin de notificar sobre
eventos por los que están pasando los usuarios de los subsidios.
Page | 3
Falta facilidad para realizar consultas a los usuarios.

Además de la posibilidad nula de conocer cuáles son los subsidios que
están por vencer, lo que conlleva a que los beneficiarios o causantes no son
notificados cuando sus subsidios están vencidos o van a vencer.
FODA:
Fortalezas:
1. Procesos técnicos y administrativos establecidos.
2. Buen recurso para ordenar subsidios.
3. Innovación tecnológica.
4. Fácil utilización.
5. Desarrollo conforme a la demanda.
6. Compromiso de los trabajadores para la utilización del software.
Oportunidades:
1. Constante crecimiento de la demanda de subsidios.
2. Necesidad de los subsidios.
3. Tramites relativamente cortos.
4. Adquisición de conocimientos en el desarrollo.
5. Apoyo del municipio.
Debilidades:
1. Poca capacitación del personal en relación al uso de sistemas informáticos.
2. Software no disponible para todos los S.O
3. Falta de documentación de algunas instrucciones y/o procedimientos internos en
algunas tareas.
4. Poca tolerancia a la inclusión de nuevas tecnologías.
Amenazas:
1. Baja motivación por alimentar un sistema.
2. Mal uso del software.
3. Poca comprensión del usuario.
4. No todos desean leer para comprender.
5. No se conoce el nivel de aprendizaje cada usuario.
Page | 4
CAME:
Corregir:
1. Realizar Capacitaciones sobre el software al personal.
2. Estar seguro de estar usando el S.O indicado para que corran todas las
aplicaciones.
3. Realizar encuestas a nivel profundizado para conocer los detalles que hacen
algunos procedimientos difíciles de entender, lo que conllevará a un uso correcto
del software.
Afrontar:
1. Obligar al personal a que realice la alimentación del sistema.
2. No dejar brechas en el sistema, que su uso sea directo y no pueda utilizarse para
otras tareas.
3. Realizar un sistema fácil e intuitivo, con alertas cortas y comprensibles.
4. Remarcar de otro color las alertas, hacerlas evidentes.
5. Esperar que el sistema sea lo suficiente intuitivo.
Mantener:
1. Mantener la motivación, dándoles a entender que a la larga el sistema será de
muchísima ayuda.
2. Dar a entender que el sistema será directo y de calidad.
3. Los procesos de subsidios vienen establecidos de hace tiempo, por lo que no se
realizarán modificaciones próximas a estos.
4. Programar un gestor de subsidios completo y fácil de entender & utilizar.
5. Con la implementación del sistema se añade más tecnología al ambiente de
trabajo.
6. El sistema, al ser destinado a usuarios principiantes, será de uso fácil e intuitivo.
7. El sistema se desarrolla completamente gracias a la toma de requerimientos y
conversas con el personal administrativo.
8. Mantener motivados a los usuarios para que utilicen el sistema y lo vean como lo
que realmente es, una ayuda.
Explotar:
1. Expandir el sistema a otros subsidios y que soporte más capacidad.
2. Dar a conocer a la gente que puede optar a subsidios.
3. Aplicar ingeniería para analizar como se pueden establecer tramites más cortos.
4. Crear funciones y procedimientos que generen más conocimiento y más
imaginación al momento de programar.
5. Dar a entender al municipio que el sistema esta funcionando y que se puede
utilizar en variados departamentos, e inclusive en distintas regiones.
Page | 5
4. SISTEMA A REALIZAR
4.1 Especificación de Requerimientos
Realizar Mantenedores:
1. Subsidio Único Familiar

1.1. Regularización
1.1.1. Ingreso
1.1.1.1. Modificación
1.1.1.2. Consulta
1.2. Revisión
1.2.1. Ingreso
1.2.2. Consulta
1.2.3. Modificación
1.3. Registro en el Subsidio
1.3.1. Ingreso
1.3.2. Consulta
1.4. Extinción del Subsidio
1.4.1. Ingreso
2. Subsidio Agua Potable

2.1. Urbano
2.1.1. Ingreso
2.1.3. Consulta
2.2. Rural
2.2.1. Ingreso
2.2.3. Consulta
3. Asignación Familiar
3.1. Manejar la información de este subsidio.
3.1.1. Ingreso
3.1.2. Consulta
4. Discapacidad Mental
4.1. Manejar la información de este subsidio.
4.1.1. Ingreso
4.1.2. Consulta
5. Mantenedor Comité
5.1. Ingreso Comité
5.2. Modificación Comité
5.3. Consulta Comité
5.4. Asignar Beneficiarios a comité
Page | 6
Notificar alertas:
1. Usuarios que están por perder un subsidio por caducidad.
2. Usuarios que tienen su subsidio desactivado (por conversar).
Realizar seguimientos:
1. De Causantes
2. De Beneficiarios
3. De Subsidio Asignación Familiar.
Realizar tareas de desactivación de subsidios si no se cumplen los requisitos mínimos o

por el no cumplimiento de controles necesarios.
Page | 7
4.1.1. Requerimientos SOLICITADOS
1. Administrador de Beneficiarios
1.2. Creación
1.3. Modificación
1.4. Consulta
2. Administrador de Causantes
2.2. Creación
2.3. Modificación
2.4. Consulta
3. Administrador de Comités
3.2. Creación
3.3. Modificación
3.4. Consulta
3.5. Asignación de Beneficiarios
4. Administrador de Subsidios
-AP
-Rural
-Ingreso
-Modificación
-Urbano
-Ingreso
-Modificación
-SUF
-Ingreso
-Revisión
-Regularización
-Extinción
-AS
-Ingreso Subsidio
-Modificación tramite
-Consulta tramite
-DM
-Ingreso
-Consulta
5. Reportes
-SUF Atendidos
-Ingresados
-Regularizados
-Revisiones
-Extinciones
Beneficiarios Atendidos
-Todos los subsidios
Page | 8
4.1.2. Clasificación de requerimientos (tipo e importancia)
*Tabla 1, Clasificación de requerimientos

Requerimiento Tipo de Requerimiento Importancia
Mantenedor Funcional Alta

Regularización(SUF)
Mantenedor Revisión(SUF) Funcional Alta
Mantenedor Extinción(SUF) Funcional Alta
Mantenedor Registro(SUF) Funcional Alta
Mantenedor Registro(A. Funcional Alta
Potable)
Mantenedor Comité Funcional Alta
Mantenedor Registro(D. Funcional Alta
Mental)
Mantenedor Registro(A. Funcional Alta
Social)
Alertas Numérica de Funcional Alta
Usuarios Por Vencer
Alertas Numérica de Funcional Alta
Usuarios Vencidos
Listar Alertas Funcional Alta
Generar Cartas de Funcional Alta
Notificación
Usar Arial 12 en Cartas de No Funcional Baja
Notificación
Generar Informes Funcional Alta
Usar Arial 12 en Informes No Funcional Baja
Usar Logo Municipalidad en No Funcional Baja
Informes
Usar Logo Municipalidad en No Funcional Baja
Mantenedores
Usar fondo Blanco No Funcional Baja
Usar Letra Celeste o Negra No Funcional Baja
Asignar Causantes a Funcional Baja
Beneficiarios
Mantenedor de Acceso Funcional Alta
Dar formato a los R.U.T No Funcional Baja
Desactivar Subsidios Funcional Media
Inactivos al Iniciar la
aplicación
Page | 9
*Tabla 1.1, importancia requerimientos

TABLA DE IMPORTANCIA
IMPORTANCIA DESCRIPCION
ALTA El impacto en la funcionalidad, usabilidad
del sistema es alto, por lo que este
requerimiento es de vital importancia para
el buen funcionamiento de este.
MEDIA El impacto en la funcionalidad, usabilidad
del sistema es medio, por lo que este
requerimiento es necesario pero se
considera un requerimiento que afecta el
funcionamiento de algunas tareas pero las
principales funcionan sin necesidad de
esta.
BAJA El impacto en el funcionamiento y la
usabilidad son bajos, el sistema puede
seguir funcionando sin problema a pesar
de que este requerimiento esté
implementado de forma deficiente.
Page | 10
4.2 Breve Descripción De La Solución A Desarrollar
Mantenedor Acceso:
Descripción: Este mantenedor controlará, mediante filtros de autenticación, la

entrada al sistema solamente a usuarios que posean credenciales de entrada.
Objetivo: El usuario ingresará sus credenciales para generar una solicitud de

entrada al sistema.
Mantenedor Beneficiario:
Descripción: Este mantenedor permitirá el ingreso, modificación y consulta de los

beneficiarios que se harán participes del sistema.
Objetivo: ingresar los datos solicitados en sus respectivas operaciones con el fin
de alimentar con información el sistema.
Mantenedor Causante:

causantes que se harán participes del sistema.
Mantenedor Comité:

comités que se harán participes del sistema, además de la asignación de
beneficiarios a los comité.
Mantenedor Agua Potable(RURAL-URBANO):

Descripción: Este mantenedor permitirá el ingreso al subsidio, modificación
y consulta del estado del subsidio.
Objetivo: ingresar los datos solicitados para interactuar con el mantenedor,
ya sea solicitando información, modificando información de los subsidios
asignados a un beneficiario/comité o asignándole a estos por primera vez un
subsidio.
Mantenedor Subsidio Único Familiar:

Descripción: Este mantenedor permitirá el ingreso, modificación y consulta
del estado del subsidio en sus distintas operaciones (Regularización, Revisión).
Page | 11
Objetivo: realizar la asignación de subsidio a un causante,

alimentando de información al sistema.
Mantenedor Discapacidad Mental:
Descripción: Este mantenedor permitirá el ingreso, modificación y consulta del

estado del subsidio.
Objetivo: la asignación del subsidio a un causante, alimentando al sistema de

información.
Mantenedor Subsidio Asignación Social:
Descripción: Este mantenedor permitirá el ingreso, modificación y consulta del

estado del subsidio.
Objetivo: asignación del subsidio a un Beneficiario, alimentando al sistema con

información.
Informes:
Subsidios Activos:
Descripción: Este informe realizará un display de información.
Objetivo: Mostrará la información que coincida con el criterio de búsqueda.
Operaciones
Causantes:
-Subsidios Activos
Resultado ordenado de la información (subsidios activos) solicitada en una plataforma de
Reportes, Alerta de falta de datos en la búsqueda.
-Subsidios Inactivos
Resultado ordenado de la información (subsidios inactivos) solicitada en una plataforma
de Reportes, Alerta de falta de datos en la búsqueda.
-Revisiones Atendidas
Resultado ordenado de la información (revisiones atendidas) solicitada en una plataforma
de Reportes, Alerta de falta de datos en la búsqueda.
-Regularizaciones Atendidas
Resultado ordenado de la información (regularizaciones atendidas) solicitada en una
plataforma de Reportes, Alerta de falta de datos en la búsqueda.
-Registros Atendidos
Page | 12
Resultado ordenado de la información (registros atendidos) solicitada en

una plataforma de Reportes, Alerta de falta de datos en la búsqueda.
-Beneficiarios Atendidos
Resultado ordenado de la información (beneficiarios atendidos) solicitada en una
plataforma de Reportes, Alerta de falta de datos en la búsqueda.
Alertas
Descripción: Este menú mostrará botones con un número que significará la
cantidad de alertas existentes por tipo de alerta.
Objetivo: Mostrar numéricamente la cantidad de individuos con sus respectivos
tramites en estado crítico.
Alertas Listado
Descripción: Este listado mostrará a los individuos que están con sus subsidios
por vencer.
Objetivo: Mostrar un listado de los Causantes/Beneficiarios que tienen sus
subsidios en estado crítico.
Carta de Notificación:
Descripción: Se genera una carta pre-definida con el fin de notificar al Beneficiario
sobre el vencimiento de su subsidio.
Objetivo: Notificar al Beneficiario sobre el vencimiento de su subsidio o de su
causante.
Seguimiento Tramite: Este mantenedor permitirá realizar un seguimiento del trámite de

COMPIN exigido para optar al subsidio asignación social.
Page | 13
4.3 Objetivo General Del Sistema A Desarrollar
Mantener un control de los actores en el proceso de la toma de un subsidio. Además de

la necesidad de realizar un análisis de estos al momento de, que presencialmente, un
usuario la solicite.
Además, se requiere del sistema para realizar un control de la documentación que
entregan los usuarios de estos subsidios, que antiguamente, se tenía que buscar entre
montones de cajas de documentación, llegando casi todas las búsquedas de estos
archivos a un mismo resultado, no se encuentra o nadie quiere ir a buscarlos.
4.4 Objetivo Específico Del Sistema A Desarrollar
Mantener el control de los Beneficiarios.

Mantener el control de los Causantes.
Mantener el control de los Comités.
Asignar beneficiarios a los Comité.
Realizar un seguimiento de los Beneficiarios.
Realizar un seguimiento de los Comités.
Realizar un seguimiento de los Causantes.
Realizar un seguimiento al trámite COMPÍN para optar a asignación social.
Notificar distintas alertas a los usuarios.
Generar documentos pre-diseñados.
Realizar acciones de desactivación de subsidios cuando sea necesario.
Realizar acciones de re-activación de subsidios cuando sea necesario.
Mantener un control sobre los subsidios.
Estas operaciones se realizarán a través de los mantenedores tanto informativos como

sus respectivos mantenedores de ingreso y modificación de información.
El control de los subsidios se mantendrá a través de los informes que se diseñarán

además de los mantenedores informativos que son de fácil uso.
Además, al poseer alertas se podrá mantener al empleado municipal atento a los cambios
que ocurren en el sistema y le da la posibilidad de realizar notificaciones a los usuarios
de los subsidios, manteniendo la comunicación activa.
Page | 14
4.5. Ámbito Y Delimitación De La Solución

 El sistema se limita a trabajar en la gestión de usuarios en el área de subsidios.
 El sistema realiza un seguimiento de los usuarios en el área de los subsidios.
 El sistema trae alertas pre-configuradas.
 El sistema trabaja con cuatros subsidios actualmente.
1. Subsidio Único Familiar
2. Subsidio Asignación Social
3. Subsidio Agua Potable
4. Subsidio Discapacidad Mental
 El sistema trabaja de forma local en el departamento municipal.
 El sistema no realiza consultas a sitios externos ni a bases de datos externas de
la que este requiere para funcionar.
 El sistema solo se implementa en los PC de los empleados municipales.
 El sistema no funcionará de forma óptima sin los componentes necesarios.
 El sistema no funcionará al público, es sólo de uso interno.
 El sistema no envía correos electrónicos.
 El sistema posee un menú principal el cuál le permite el uso de todas las
funcionalidades visibles.
 El sistema posee 1 tipo de usuario.
 Solo existen 2 usuarios capaces de generar otros usuarios.
 El sistema no realiza tareas fuera de las especificadas en el objetivo específico.
 El sistema no modifica subsidios, estos vienen pre-seleccionados.
 El sistema no borra usuarios ni detalles de subsidio, sólo los desactiva.
 El sistema posee un mantenedor de usuarios.
o El cuál solo permite el ingreso del Administrador de Base de Datos y el
Programador.
Page | 15
5. Factibilidad del proyecto
FACTIBILIDAD NUMERO 1:
5.1. Factibilidad TÉCNICA (desarrollo).

*Tabla 2, Factibilidad Técnica.
Software: Descripción: Especificaciones Minimas:
Microsoft Este será el software usado para el Microsoft Windows XP SP3, 1.6
Visual Studio desarrollo de la plataforma ya que es Hz, 1 GB,
2010 gratuito y pagado. 3 GB(HDD).
SQL Server Se ocupará este software como 1.0 GHz, 512 MB, Windows 7.
2000/2008 gestor de la base de datos, además
de ser una de las mejores bases de
datos para el uso de múltiples
plataformas.
Argo UML Para el desarrollo de modelos UML, Java Version 1.4
es de código libre, además deja
diagramar de distintas formas,
diagrama de caso de uso, diagrama
de clases, diagrama de secuencias,
diagrama de colaboración, diagrama
de estados, diagrama de actividades
y diagramas de despliegue.
Bizagi Este software lo utilizaremos para 6 GB, 10GB HDD, 2.4gHz,
diagramar los procesos de la Windows 7.
empresa o ir editando los mismos si
es necesario.
Windows 10 Este sistema operativo lo 1GB,16GB HDD,1GHz.
Ultimate utilizaremos como base ya que es de
preferencia del programador.
Adobe Este software nos ayudara en la 1,5 GHz,Windows 7, 380 MB

Reader impresión de informes o fichas de los HDD.
pacientes.
Office 365 Microsoft Office es una suite 1 GHz, 2GB RAM, 3GB HDD,
ofimática que abarca el mercado .NET 3.5.
completo en Internet e interrelaciona
aplicaciones de escritorio, servidores
y servicios
Page | 16
*Tabla 2.1, Factibilidad técnica.

Descripción: Especificaciones:
Notebook ACER RAM 6 GB Disco duro: Procesador
EST-532G-P77E 1 TB Pentium Inside 1.8gHz
Impresora Epson Para la impresión de informes diagramas, cartas gants, etc.
5.2 Factibilidad ECONÓMICA (desarrollo).

*Tabla 2.2, Factibilidad económica
INVERSION CANTIDAD VALOR TOTAL
Notebook 1 $310.000 $310.000
ACER EST-
532G-P77E
Impresora 1 $10.000 $10.000
Epson
Total: $320.000
*Tabla 2.3, Factibilidad económica.
Desarrollador $300.000
Administrador BD $250.000
Mano de obra directa $200.000
Total $750.000
5.3. Factibilidad OPERACIONAL (desarrollo).

*Tabla 2.4, Factibilidad operacional, RRHH.
1 Administrador de Persona que este constantemente
BD preocupado de la base de datos,
realizando mantenciones,
correcciones, pruebas de estrés
control de datos.
Con manejo en SQL Server
2000/2008.
1 Seguridad Persona encargada de toda la
seguridad de la plataforma
preocupado más que nada de que
nadie vulnere la base de datos y la
plataforma, con conocimientos
avanzados, que asegure además
que solo los usuarios del sistema
acceden a este y que cada usuario
tiene y utiliza los privilegios que se le
asignan.
Con conocimientos en planes de
prueba y tipos de prueba para aplicar
los conocimientos en la etapa de
testeo de la seguridad e integridad
del sistema y el trabajo de datos.
1 Programadores Un programador con conocimientos
en php.
Page | 17
5.4 Factibilidad legal (desarrollo).
Licencias de Microsoft Windows 10 Ultimate.

Licencia SQL Server 2008 (10.0.6000.29)
Licencias de Microsoft Office.
Licencia de Microsoft Visual Studio.
Los cuáles son claves para el uso del S.O, revisión de informes y programación del
sistema.
Page | 18
FACTIBILIDAD NUMERO 2:
5.1. Factibilidad TÉCNICA

*Tabla 2.5, Factibilidad técnica 2.
Software: Descripción: Especificaciones mínimas:
Sublime Text: Este será el software usado para el Microsoft Windows XP SP3, 1.6
desarrollo de la plataforma ya que es Hz, 1 GB,
gratuito y pagado, la diferencia entre 3 GB(HDD).
los dos es que en la versión pagada
tenemos soporte 24x7, en el cual
podremos programar en php, Ajax,
jquery, entre otros lenguajes.
MySQL: Se ocupará este software como 1.0 GHz, 512 MB, Windows 7.
gestor de la base de datos, por ser
una de las mejores bases de datos
para el uso de plataformas webs.
Argo UML Para el desarrollo de modelos UML, Java Version 1.4
es de código libre, además deja
diagramar de distintas formas,
diagrama de caso de uso, diagrama
de clases, diagrama de secuencias,
diagrama de colaboración, diagrama
de estados, diagrama de actividades
y diagramas de despliegue.
Bizagi Este software lo utilizaremos para 6 GB, 10GB HDD, 2.4gHz,
diagramar los procesos de la Windows 7.
empresa o ir editando los mismos si
es necesario.
Windows 7 Este sistema operativo lo 1 GHz, 2GB, 16GB HDD.
Ultimate utilizaremos como base ya que es de
preferencia del programador.
Adobe Este software nos ayudara en la 1,5 GHz,Windows 7, 380 MB

Reader impresión de informes o fichas de los HDD.
pacientes.
Office 365 Microsoft Office es una suite 1 GHz, 2GB RAM, 3GB HDD,
ofimática que abarca el mercado .NET 3.5.
completo en Internet e interrelaciona
aplicaciones de escritorio, servidores
y servicios
*Tabla 2.6, Factibilidad técnica 2.

Descripción: Especificaciones:
Notebook Sony RAM 4 gb Disco duro: Procesador
VAIO 1 TB I3 2.0
Impresora HP Para la impresión de informes diagramas, cartas gants, etc.
Page | 19
5.2 Factibilidad ECONÓMICA (desarrollo).

*Tabla 2.7, Factibilidad económica 2.
INVERSION CANTIDAD VALOR TOTAL
Notebook 1 $440.000 $440.000
Sony VAIO
Impresora 1 $30.000 $30.000
Epson
Total: $470.000
*Tabla 2.8, factibilidad económica 2.

Desarrollador $300.000
Administrador BD $350.000
Seguridad $300.000
Jefe de Proyecto $400.000
Mano de obra directa $200.000
Total $1.550.000
Page | 20
5.3. Factibilidad OPERACIONAL (desarrollo).

*Tabla 2.9, Factibilidad operacional RRHH 2.
Cant. Cargo Descripción
1 Administrador Persona que este
de BD constantemente preocupado
de la base de datos,
realizando mantenciones,
correcciones, pruebas de
estrés control de datos.
Con manejo en SQL Server
2000/2008.
1 Seguridad Persona encargada de toda la
seguridad de la plataforma
preocupado más que nada de
que nadie vulnere la base de
datos y la plataforma, con
conocimientos avanzados,
que asegure además que solo
los usuarios del sistema
acceden a este y que cada
usuario tiene y utiliza los
privilegios que se le asignan.
Con conocimientos en planes
de prueba y tipos de prueba
para aplicar los conocimientos
en la etapa de testeo de la
seguridad e integridad del
sistema y el trabajo de datos.
1 Programadores Un programador con
conocimientos en c#.
1 Jefe de Ingeniero en informática, con
proyecto aptitudes de liderazgo además
de su capacidad de liderar y
guiar a un grupo de trabajo.
Page | 21
5.4 Factibilidad legal (desarrollo).
Licencias de Microsoft Windows 10 Ultimate.

Licencias Sublime Text.
Licencias de Microsoft Office.
Los cuáles son claves para el uso del S.O, revisión de informes y programación del
sistema.
5.5 Factibilidad de implementación (Usuario).
*Tabla 3, Factibilidad de implementación 2.

Especificaciones Mínimas del Sistema
Sistema Operativo Windows XP
RAM 1 GB
Disco Duro 256 MB
NET Framework 4.0
ReportViewer 2010
Especificaciones De Usuario
Nivel de manejo informático Básico
Page | 22
5.6. Identificación de solución
5.6.1 Identificación y Justificación SELECCIÓN
Si bien el desarrollo en PHP podría ser considerado el más apto para un desarrollo
de software o solución de sistema, ya que este es un lenguaje de fácil entendimiento y
de fácil adaptación, y además de que al tener la posibilidad de ser relativamente gratuito
en lo que es su base de datos y plataforma de programación, existen ciertas
discrepancias con respecto a estos beneficios en la Municipalidad de Los Ángeles.
El sistema se solicitó en C#, ya que esta solución es necesitada en un ambiente
de escritorio, el cuál será utilizado por solamente los trabajadores del Departamento de
Subsidios de Los Ángeles, los cuáles son entre cinco y siete trabajadores que realizan
atención al público en el área de subsidios.
Con respecto a la elección, se escogió la factibilidad número uno, ya que el
hardware que se utiliza es más barato y esto conlleva a una reducción de costos por parte
de la municipalidad, además de cumplir con todas las especificaciones necesarias para
cumplir las tareas de programación y de almacenamiento de base de datos.
Con lo que respecta a la plataforma de programación, se utilizarán licencias de
estudiantes, las cuales permiten el desarrollo de forma gratuita y no genera el costoso
gasto de las licencias empresariales.
Además, al haberse solicitado un sistema en C# que trabaja de forma local en la
municipalidad, es porque además se poseía con anterioridad un servidor de SQL Server
2000, con sus licencias al día, lo que para el desarrollador reducía en un 100% los gastos
en, ya sea la adquisición del software de SQL Server, y la adquisición de una máquina
que ejecute este software y funcione como el gestor de base de datos, además, la
municipalidad al poseer un departamento de informática, inclusive se ahorra el
administrador de base de datos MySQL que se debería haber contratado, lo que era un
plus adicional, ya que el ahorro de costos en estos días es lo que más se busca, por lo
que C# trabaja de forma natural con servidores SQL Server, lo que lo hace la opción más
compatible con las necesidades de la empresa, por lo que en resumen las pertenencias
actuales de la empresa justifican la viabilidad de la opción.
Con respecto a los usuarios finales, estos conocen más de sistemas de escritorios
que de aplicaciones en una plataforma de navegación online, por lo que, en un asunto de
comodidad, los trabajadores se sienten más cómodos con una aplicación amigable y de
escritorio, que no necesita una conexión a internet ni un gestor de por medio que
necesiten para abrirla.
Page | 23
5.6.2 Proyección De Solución A Implementar
Lo que este sistema actualmente realiza por la empresa es una gestión ordenada
de los usuarios, reemplazando el antiguo sistema que se utilizaba y dándole un formato
a la información que se gestiona de los usuarios, además de gestionarlos en sí de forma
ordenada, así en conjunto a sus sub-usuarios ligados a estos y a sus subsidios.
Actualmente para la empresa el comenzar con este sistema significa hacer un re-
ingreso de la información a esta nueva plataforma, lo que se realizará de forma gradual,
ingresando día a día lo mismo que se ingresaba en una plataforma Excel, directo al
sistema, alimentándolo con información y dándole la utilidad a este mismo.
Actualmente el sistema trabaja con cuatro subsidios:
-Subsidio único familiar.
-Subsidio agua potable.
-Subsidio discapacidad mental.
-Subsidio asignación social.
El sistema comenzó realmente con un subsidio, el único familiar, con sus sub-
procesos de Ingreso, Regularización, Revisión y Extinción, al conversar más el tema se
extendió a agua potable y sus derivados, rural e urbano, y a lo que se llegó a intentar
cubrir el de asignación social y discapacidad mental.
Lo que se intenta lograr con este software es cubrir la mayor cantidad de subsidios
posibles, y sacarlo de una red interna y poder extenderlo en diferentes municipios fuera
de Los Ángeles.
Este software podría extenderse a SUF Madre, Subsidio Único Maternal, SUF
Recién Nacido, SUF Duplo, Pensión básica solidaria vejez, Pensión básica solidaria
invalidez, Programa de medicamentos y otros, Programa de Ayuda Social, Programa de
Emergencia social, Programa de rebaja o exención de derechos de aseo domiciliario,
Registro social de hogares (antigua ficha de protección social).
Por lo que, el sistema podría crecer de forma exponencial si se agregasen esos
subsidios, por lo que además la cantidad de usuarios que abarcaría el sistema sería
mucho más grande, si actualmente se trabaja con más de 27.000 usuarios, al abarcar
todos esos subsidios el número de usuarios aumentaría increíblemente, dándole al
sistema más utilidad con respecto a sus alertas y dándole más oportunidades de reportes
y alertas.
Además, se puede proyectar la inclusión de las nuevas tecnologías con la finalidad
de una creación de usuarios más rápida e inteligente y la consulta de otras
funcionalidades con estas.
Page | 24
6. Planificación de actividades
6.1. Identificación y justificación de METODOLOGÍA de desarrollo utilizada
Modelo de Prototipo
Su objetivo es que el sistema, o alguna de sus partes, se construyan rápidamente para
comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el
desarrollador, el usuario y el cliente estén de acuerdo en lo que se necesita, así como
también la solución que se propone para dicha necesidad y de esta forma minimizar el
riesgo y la incertidumbre del desarrollo.
Este modelo se podría aplicar ya que el cliente define un conjunto de objetivos generales
para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada
procesamiento y salida, es decir, cuando el responsable no está seguro de la eficacia de
un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa hombre y
máquina.
Etapas para la elaboración:

 Identificar requerimientos básicos de usuario.
 Desarrollar prototipo inicial
 Usar el prototipo
 Revisión y mejora del prototipo
Etapas de ciclo de vida del sistema:

Definición del proyecto: Identificación de problemas, oportunidades y objetivos. Se
determinan requerimientos de información de manera objetiva.
Se analiza si es preciso implementar un nuevo sistema o modificar el existente.
Análisis de sistemas: Se analizan los problemas, necesidades del sistema utilizando
diagramas de flujo, entrevistas, análisis de documentos e informes.
Diseño: Se elabora el diseño lógico, se hacen descripciones formales.
Programación: Etapa técnica, consiste en traducir las especificaciones de diseño en un
código de programación.
Instalación: Consiste en comprobar el sistema, se analiza la forma en la que se
implantará, se capacita al personal, se documenta y se hacen las primeras evaluaciones.
Post-Implantación: Se evalúa el sistema después de entrar en funcionamiento, incluyen
actualizaciones y se puede llegar a una auditoria formal para ver si el sistema cumple los
requisitos.
Page | 25
Desarrollo Evolutivo
Prototipos Desechables
Donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos
del cliente y entonces desarrollar una definición mejorada de los requerimientos para el
sistema.
Ya que los requerimientos no están bien definidos y se debe realizar la toma de estos,
procesarlos y realizar una solución en base a los requerimientos de forma mejorada.
Además de que se puede mostrar de forma creciente.
Definición del problema y especificación inicial en

Especificación base a los requerimientos definidos
Inicial
Desarrollo del software en base a un proceso con

Desarrollo del énfasis en la rapidez de la liberación
Producto
Implantación y uso del software en un ambiente de

explotación, además de un monitoreo de los nuevos
Implementación, uso requerimientos.
y evaluación
Versiones de
Software
Re-especificación Re-definición del problema en base a los nuevos

requerimientos
Page | 26
Justificación
Se escogió la metodología evolutiva, específicamente sus prototipos desechables, debido

a la falta de seguridad de la persona encargada del departamento de subsidios con
respecto al sistema que se estaba solicitando.
Los prototipos desechables fueron de mucha utilidad en la creación del sistema ya que,
el encargado al no conocer bien lo que se necesitaba, dio muchos requerimientos y
solicitudes, ideas y opiniones de lo que él creía necesario que un sistema debería cubrir
satisfaciendo específicamente los vacíos y vulnerabilidades que existían.
Por aquello se tomaron los requerimientos y se empezaron a trabajar y a pulir hasta llegar
a un sistema, el cual cubría las necesidades ya explicadas anteriormente, pero que, al
trabajar con un cliente con conocimiento basto en informática y procesos de desarrollo,
este solicitó el agregar más subsidios al sistema, por lo que se realizó una nueva toma
de requerimientos la cual arrojó resultados distintos a lo que se tenía, obviamente
conservando la base actualmente existente.
Al realizarse sus cambios se realizó un nuevo prototipo el cuál se presentó y, que con
éxito se aceptó, se observó la necesidad de ciertos requerimientos extras, como
mantenedores que, si bien no se notaron antes, el cliente realizó una nueva
especificación del subsidio de agua potable, el cuál no trabajaba solo con beneficiarios,
sino que también con comités, y se subdividió en dos procesos más, rurales y urbanos,
los cuáles se ligaban a los comités. Por lo que al mostrar este prototipo se tuvo que
realizar una nueva toma de requerimientos y se realizó el nuevo prototipo el cual ya
cumpliendo con las expectativas necesitó una nueva iteración para el subsidio de
discapacidad mental.
Page | 27
6.2. Identificación De Equipo De Trabajo
Roles:
*Tabla 3.1, Roles del equipo de trabajo.
Cargo Descripción
Administrador Realiza mantenciones en la BDD
de BD Realiza Correcciones
Realiza pruebas de control de datos
Seguridad Realiza pruebas de seguridad en el sistema
Realizar inyecciones e informa vulnerabilidades
Realiza pruebas que ayuden a impedir el ingreso
malintencionado a la plataforma
Programadores Realiza las tareas de creación de la plataforma.
Realiza las tareas de diseño de la plataforma.
Realiza tareas de seguridad para impedir acciones
malintencionadas.
Jefe de Realiza la gestión del proyecto
proyecto Motiva al equipo de trabajo a cumplir sus metas y
objetivos.
Aporta al equipo con las decisiones necesarias para
el buen funcionamiento del sistema.
Equipos de trabajo multifuncionales: combinan expertos de varias áreas. Estos

especialistas se integran en el equipo de forma independiente, o como parte, a su vez,
de un equipo funcional. Su principal característica viene definida por el hecho de que
todos ellos desarrollan su labor cooperativamente, orientándola hacia algún objetivo
concreto de la organización o centrándose en alguna de las metas de proyecto. Este es
uno de los tipos de equipos de trabajo más completos ya que:
 Debido a que sus miembros son considerados expertos en su área funcional, por
lo general están capacitados para tomar decisiones por su cuenta, sin necesidad
de consultar a la dirección de proyecto.
 La distribución de la responsabilidad sobre los entregables y tareas a realizar en
un proyecto en equipos multifuncionales mejora la coordinación de las actividades
interdependientes entre las diferentes subunidades.
 Cada miembro del equipo aporta una perspectiva única al grupo, que enriquece
los resultados, aunque puede, en ocasiones, dificultar la gestión.
Justificación del equipo de trabajo

Se decidió usar un equipo de trabajo multifuncional por el hecho de ser el más apto para
el desarrollo de este proyecto, en el sentido de que todo el equipo apunta a un objetivo
en común desarrollando diferentes módulos y tareas tomando sus propias decisiones y
abarcando y respetando el trabajo de sus compañeros. Además, al tener distintas
perspectivas del software este apoya a enriquecer la toma de requerimientos,
agregándole valor al código ya que las funciones se trabajan y se mejoran en el
transcurso del desarrollo, brindando funcionalidades aprobadas desde distintos puntos
Page | 28
de vista, pero apuntando a un mismo objetivo con la misma metodología y

los mismos estándares.
6.3. Plan de Contingencia
6.3.1. Identificación De Riesgos
*Tabla 3.2, Identificación de riesgos.
Riesgos Prob Magn Total
 No existieron pruebas de que el programador realmente 1 4 4

tenia todos los conocimientos
 No se hicieron pruebas adecuadas para probar 2 4 8
 Mala estimación del tiempo de desarrollo del proyecto 2 4 8

 Diseño inadecuado 2 4 8
 Mala especificación del proyecto 2 4 8
 Mala especificación del alcance del proyecto 1 4 4
 La no comunicación de los Estándares 1 4 4
 La no comunicación entre los involucrados en el 2 4 8
proyecto
 La interfaz del sistema es inestable 2 4 8
 Los informes necesitan más tiempo del previsto 1 4 4
 No se sigue la metodología seleccionada 2 4 8
 No cumple con la planificación 2 4 8
 No se ejecutan los controles necesarios 1 4 4
 No se realizan las pruebas necesarias 1 8 8
 No se definen riesgos dentro del proyecto 4 2 8
 Riesgos no controlados 4 3 12
 Mala estimación del tiempo de desarrollo del proyecto 2 4 8
 Diseño inadecuado 1 4 4
 La interfaz del sistema es inestable 1 4 4
 Los informes necesitan más tiempo del previsto 2 4 8
 Canales de información mal definido 1 4 4
 No definición acciones correctivas 2 2 4
 No definición actividades de retroalimentación 1 1 1
 No se crearon actividades revisión 2 1 2
 No existencia de planes de contingencia 3 3 9
 Los avances no cumplen las expectativas 1 4 4
 Los componentes utilizados no rinden como se 1 1 1
esperaba
 Problema de hardware 1 1 1
Page | 29
6.3.2. PRIORIZACIÓN DE RIESGOS
Imagen 1: Tabla de riesgos.
*Tabla 3.3, significado de riesgos.

Valor Definicion
Insignificante No tiene un impacto en el funcionamiento
del sistema.
Baja Tiene un impacto leve en el
funcionamiento del sistema
Mediana El impacto es Medio, este tipo de riesgo
debe ser mitigado, ya que afecta
medianamente al funcionamiento del
sistema.
Alta El impacto es muy grande, este tipo de
riesgo debe ser mitigado rapidamente, ya
que este afecta directamente al
funcionamiento del sistema.
Page | 30
6.4. Representación gráfica de planificación temporal
6.4.1. EDT
Imagen 2, EDT.
Page | 31
6.4.2. PLANIFICACIÓN DE PROYECTO

Carta Gantt del proyecto desarrollada en una herramienta CASE.
Page | 32
Imagen 4, Carta Gantt.
Imagen 4.1, Carta Gantt.
Page | 33
7. Diseño LÓGICO Del Proyecto
7.1 Diagramas Para Diseño De Sistema
7.1.1. DIAGRAMA DE CASO DE USO
Imagen 5, Casos de uso.
Page | 34
7.1.2. Diagrama De Actividad

CONSULTAR
Imagen 6, Diagrama de actividad.
Page | 35
EXPORTAR CARTA
Imagen 6.1, Diagrama de actividad.
Page | 36
EXPORTAR REPORTE
Page | 37
GENERAR REPORTE
Page | 38
INGRESAR
Page | 39
MODIFICAR
Page | 40
VER ALERTAS
LOGIN

Page | 41
7.1.3 Diagrama De Estado
SUBISIDIO
Imagen 7, Diagrama de estado.
USUARIO
Imagen 7.1, Diagrama de estado.
7.1.4 Diagrama De Clases
Imagen 8, Diagrama de clases.
Page | 42
7.1.5 Diagrama De Componente
Imagen 9, Diagrama de componentes.
Page | 43
7.2 Modelo De Base De Datos
Imagen 10, M odelo de base de datos.

Page | 44
Modelo Entidad Relación
Imagen 11, M ER.

Page | 45
7.3. Layout
LOGIN
Imagen 10, Layout Login
MENU
Imagen 10.2, Layout M enu
Page | 46
INGRESO DE BENEFICIARIO
Imagen 10.3, Layout Ingreso Beneficiario
INGRESO CAUSANTE
Imagen 10.4, Layout Ingreso causante Login
Page | 47
MODIFICAR USUARIO
Imagen 10.5, Layout M odificar usuario
MENSAJE DE ALERTA
Imagen 10.6, Layout Alerta
Page | 48
INFORME
Imagen 10.7, Layout Informe
Page | 49
8. PLANES DE PRUEBA
8.1 IDENTIFICACIÓN TIPO DE PRUEBA
PRUEBA DE ACEPTACIÓN(UAT1)
Las pruebas de aceptacion de usuario (User Acceptance Testing o Pruebas UAT)
Se enfocan en verificar si el sistema es “apto para el uso”. Se diseñan
principalmente a partir de las especificaciones de requerimientos, casos de uso y
de los procesos de negocio definidos.
Los usuarios y clientes suelen involucrarse en la ejecución de las pruebas de

aceptación de software, siendo esto un mecanismo muy útil para ganar su
confianza en el nuevo sistema o funcionalidad.
Sin embargo, para que esta premisa se pueda cumplir, deben presentarse muy
pocas o ninguna incidencia (bug) durante las pruebas de aceptación, pues de no
ser así, lejos de crear confianza más bien podría tener el efecto contrario
(desconfianza en el nuevo sistema).
Dentro de las buenas prácticas de las pruebas de usuario, existen tipos de pruebas
de caja negra que se adaptan perfectamente a los objetivos de las pruebas de
aceptación de usuario, como lo son las de tablas de decisión y casos de uso.
El encontrar defectos (bugs) no es el enfoque principal de las pruebas de

aceptación, de hecho, deben evitarse a toda costa, pues además de significar que
se ha perdido buena parte del trabajo en la fase de análisis de requerimientos,
afectan negativamente la confianza del usuario.
Para realizar las pruebas de aceptación se utilizarán los casos de uso como datos
de prueba:
1 http://www.pmoinformatica.com/2016/08/pruebas-aceptacion-software-istqb.html
Page | 50
PRUEBAS DE CAJA NEGRA2: REQUERIMIENTOS

FUNCIONALES/CASOS DE USO
Las pruebas de caja negra, es una técnica de pruebas de software en la cual la
funcionalidad se verifica sin tomar en cuenta la estructura interna de código,
detalles de implementación o escenarios de ejecución internos en el software.
En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas
del sistema, sin preocuparnos en tener conocimiento de la estructura interna del
programa de software. Para obtener el detalle de cuáles deben ser esas entradas
y salidas, nos basamos únicamente en los requerimientos de software y
especificaciones funcionales.
PRUEBAS DE ACCESIBILIDAD
Pruebas de accesibilidad son pruebas para determinar la facilidad con la que un
usuario con discapacidades puede usar un componte o sistema. También se usan
para descubrir la facilidad con la que se puede utilizar una aplicación y utilizar esta
información para mejorar futuros diseños e implementaciones.
PRUEBAS DE INTEGRACIÓN
Las pruebas de integración comprenden verificaciones asociadas a grupos de
componentes, generalmente reflejados en la definición de subsistemas de
construcción o en el plan de integración del sistema de información y tienen como
objetivo verificar el correcto ensamblaje entre los distintos componentes.
PRUEBAS UNITARIAS
En programación, una prueba unitaria es una forma de comprobar el correcto
funcionamiento de una unidad de código. Por ejemplo en diseño estructurado o
en diseño funcional una función o un procedimiento, en diseño orientado a
objetos una clase. Esto sirve para asegurar que cada unidad funcione
correctamente y eficientemente por separado. Además de verificar que el código
hace lo que tiene que hacer, verificamos que sea correcto el nombre, los nombres
y tipos de los parámetros, el tipo de lo que se devuelve, que si el estado inicial es
válido entonces el estado final es válido
PRUEBA DE GUI
La prueba de interfaz de usuario verifica la interacción del usuario con el
software. El objetivo es asegurar que la interfaz tiene apropiada navegación a
través de las diferentes funcionalidades.
2 http://www.pmoinformatica.com/2017/02/pruebas-de-caja-negra-ejemplos.html
Page | 51
PRUEBAS ALFA Y BETA

Las pruebas alfa se llevan a cabo por usuarios finales, el desarrollador toma nota
de los errores que va pillando el usuario además de sus problemas de uso.
Las pruebas beta se llevan a cabo por el usuario final, pero en este caso el
desarrollador no está presente. El usuario se compromete a registrar los
problemas y los reporta al desarrollador en la ocasión correspondiente y en un
formato que se le entrega.
Datos de prueba: Datos*
PRUEBAS DE REGRESIÓN
El objetivo de las pruebas de regresión es garantizar que, ante cualquier
modificación al código actual, ya sea por mantenimiento o por la incorporación de
nueva funcionalidad, no se vea afectada en el resto de las secciones que integran
a la aplicación.
PRUEBAS DE FUNCIONABILIDAD
Prueba que el sistema cumple las funcionalidades especificadas en los
requerimientos.
Page | 52
PRUEBAS DE FUNCIONALIDADES Y OPERACION

Las actividades de esta etapa se refieren a hacer chequeos completos respecto
de las funcionalidades y aplicaciones que ofrece el sitio, ya sean de aplicaciones
simples como formularios hasta más complejas, como consultas y modificaciones
de registros en base de datos.
En este sentido, las pruebas se deben hacer sobre diferentes elementos, siendo
uno de los más importantes la validación de los formularios.
Datos*
Campos de RUT: sólo caracteres numéricos 1-9 y con longitud máxima de 9

caracteres.
el formato Rut se configura automáticamente al abandonar el campo.
Ejemplo Valido de ingreso: 185701379, 103186307, 85620770, 16872277k
Ejemplo Invalido de ingreso: 18.570.137-9, 10..318-630.7
Campo Teléfono: Sólo caracteres numéricos 1-9 con longitud máxima de 11

números.
Ejemplo valido de ingreso: 989064986, 56989064986, 89064986
Ejemplo invalido de ingreso: 9890649-86, +56989064986, +569
Campo Nombre: Sólo caracteres alfabéticos A-Z, a-z.

Ejemplo valido de ingreso: Lucas Esteban, Lucas.
Ejemplo invalido de ingreso: Lucas Esteban, Lucas-Esteban, Lucas.Esteban.
Campo Apellidos: Sólo caracteres alfabéticos A-Z, a-z.

Ejemplo valido de ingreso: Olate Zapata, Olate.
Ejemplo invalido de ingreso: Olate.Zapata, Olate-Zapata.
Campo Dirección: Sólo caracteres alfabéticos A-Z, a-z con longitud máxima de
30 caractéres.
Ejemplo valido de Ingreso: Las tórtolas, Las golondrinas, Estados Unidos.
Ejemplo invalido de ingreso: Las tórtolas 578, Las golondrinas.899, Estados
Unidos 882.
Campo Numero dirección: Sólo caracteres numéricos 1-9 con longitud máxima
de 5caractéres.
Ejemplo valido de ingreso: 987, 882, 4523, 52939.
Ejemplo invalido de ingreso: Nueve Ocho Siete, Ochocientos ochenta y dos,
Cincuenta y dos mil novecientos treinta y nueve.
Campo Observación: Caracteres Alfabéticos y numéricos A-Z, a-z, 1-9.
Campo Usuario: Sólo caracteres numéricos 1-9 y con longitud máxima de 9

caracteres.
Debe ser un RUT valido.
Page | 53
Si el RUT termina en K, se debe reemplazar por un cero.

Ejemplo Valido de ingreso: 185701379, 103186307, 85620770
Ejemplo Invalido de ingreso: 18.570.137-9, 10..318-630.7, 9909101k
Campo Contraseña: Caracteres numéricos 1-9 mezclado con caracteres

alfabéticos A-Z,a-z.
Ejemplo Valido de ingreso: 999v7mx, chile2989, lucas1993
Ejemplo Invalido de ingreso: 1_22vl, 49SIX.TWENTYFOUR, 900999-999
PRUEBA DE SEGURIDAD Y CONTROL DE ACCESO
Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las
funciones y datos que su usuario tiene permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al
sistema y a la aplicación están habilitados para accederla.
Datos de prueba:
Usuarios del sistema de la plataforma administrativa de subsidios registrados y
válidos.
PRUEBAS DE USABILIDAD
Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las
áreas de diseño que hacen al sistema de difícil uso para el usuario.
La prueba de usabilidad detecta problemas relacionados con la conveniencia y
practicidad del sistema desde el punto de vista del usuario.
Datos de prueba:
Manejo del Usuario
Conocimiento del Usuario
PRUEBAS DE CONFIABILIDAD
Refiere a la precisión con la que proporciona una aplicación, sin errores, los
servicios que se establecieron en las especificaciones originales.
El objetivo es conseguir un software de calidad que abarque el ciclo vital del
desarrollo de este.
Consiste en probar una aplicación para descubrir y eliminar errores antes de que
se implante en el ambiente de trabajo.
Datos de prueba: Grado de progresión
PRUEBAS DE EFICIENCIA
Comprueba los tiempos de respuesta y la respuesta del sistema funcionando con

grandes volúmenes de datos.
Datos de prueba:
Tiempos mínimos
Tiempos máximos
Page | 54
9. Conclusión
El desarrollo de este software ha sido sin duda un desafío y una meta muy
productiva de alcanzar, el hecho de tener la posibilidad de aplicar los
conocimientos actuales, ya sea en programación e ingeniería en informática, y
alimentarlos con nuevos conocimientos ha sido una tarea realmente grata e
importante para un punto en la vida en la que sólo queremos evolucionar, así tal
como un software.
La oportunidad que tengo y que se me otorgó de poder tomar una problemática

que una empresa quería solucionar, analizarla, comprenderla, estudiarla y darle
una solución ha llenado de conocimientos nuevos y frescos el conocimiento actual.
La forma en la que, un problema se convierte en una solución, y de esa solución

poder mejorarla e ir intentando nuevas cosas hasta lograr un trozo de código que,
quizás nadie más que el mismo programador vaya a entender, llene algún tipo de
satisfacción extraña dentro de uno, es una sensación recomendable.
El desarrollo de la Plataforma Administrativa de Subsidios dio a conocer la

importancia de la gerencia de un proyecto, el lado B del desarrollo de un software,
ya que muchas veces el programador piensa, diseña y maquetea de forma mental
muchos procesos y mantenedores que se utilizarán.
Por lo que la gerencia de un proyecto permite una mejor visión de los procesos de
desarrollo del software, dando ideas concretas y estableciendo estándares en este
sin que sea sólo un individuo planeando mentalmente un sistema.
Con la ingeniería y la gestión de proyectos informáticos podemos comprender que

un proyecto no sólo es un rol, ni dos ni tres, son muchos roles en conjunto
trabajando en equipo para un objetivo en común, el desarrollo de un software que
cumpla las necesidades del cliente, un software que cubra las necesidades de la
empresa, un software que al fin pueda tapar ese agujero generado por la mala
gestión de procesos.
PASM logró cautivar el interés en la documentación de este software, el interés en

un tipo de programación distinta, un tipo de programación que provoca una interfaz
ordenada, legible, segura y maleable al gusto del cliente.
Desde un análisis FODA, hasta documentación de planes de prueba, creación de

casos de uso, utilización de esos mismos casos, creación de diagramas que en un
pasado quizás no se comprendieron del todo, ahora ha sido una experiencia
maravillosa el poder entender y sentir una emoción incontenible por lograr
implantar este sistema para que pueda apoyar muchos procesos de una empresa.
Durante el proceso de elaboración también se tuvo y se optó por la posibilidad de

generar criterios y metodologías ad-hoc a los distintos procesos con respecto a la
seguridad informática, que aseguran más confiabilidad y calidad del software,
provocando una estabilidad más grande del sistema y un mejor uso de la
Page | 55
información y de los procedimientos generados después de proceso

ingenieriles de informática, con la finalidad de generar una entrada limpia a la base
de datos.
Además, gracias a la metodología usada se logró observar el desarrollo del

sistema, ya que se fueron agregando incrementos que hacían que el sistema
creciera y abarcara más procesos y entregara información más valiosa y directa al
cliente, que para empezar es la función más valiosa de un sistema e este tipo, el
solicitar poca información y entregar una cantidad razonable y obviamente
seleccionada por el cliente.
La importancia de la metodología es vital para el desarrollo del sistema, ya que

esta nos informa de cuánto tiempo se requiere y cuánto plazo existe para la
entrega, cuántos entregables y cuáles procesos se requieren para completarlo.
El problema es cuándo la metodología y los estándares se escogen tarde y ya es

difícil volver a re-ordenar todo el sistema, por eso hay que ser metódicos desde un
principio.
PASM ya dejó de ser un bebé en pañales, y va tomando cada vez mas forma de
software robusto y completo, y claramente con muchas oportunidades de
expandirse a distintos subsidios, de seguir creciendo y evolucionando para cubrir
más necesidades de la empresa y solucionar más problemas de una forma
amigable, simple y accesible.
Page | 56
10. BIBLIOGRAFIA (Norma APA)

PMO informatica (2016). Pruebas de aceptación de software según el ISTQB.
Recuperado de: http://www.pmoinformatica.com/2016/08/pruebas-aceptacion-software-
istqb.html
PMO informatica (2017). Pruebas de caja negra: Ejemplos. Recuperado de:

http://www.pmoinformatica.com/2017/02/pruebas-de-caja-negra-ejemplos.html
Gazafatonario IT (2012). Ventajas y desventajas del uso de prototipos. Recuperado de:

http://www.gazafatonarioit.com/2012/07/ventajas -y-desventajas-del-uso-de.html
Informatica y calidad sw (2017). Modelo evolutivo. Recuperado de:

http://informaticaycalidadsw.wikispaces.com/file/view/MODELO+EVOLUTIVO.pptx
GestionRRHHUSM(2011). Modelo Prototipo. Recuperado de:

http://gestionrrhhusm.blogspot.cl/2011/05/modelo-de-prototipo.html
PMO informatica (2017). 5 herramientas de testing de servicios web. Recuperado de:

http://www.pmoinformatica.com/
SlideShare (2009). Control de riesgo Ing. Teresa Cossío. Recuperado de:

https://es.slideshare.net/tcossiop/control-de-riesgo-sesion-4
Blogspot(2010). Modelo Evolutivo. Recuperado de:

http://jorgetrejos.blogspot.cl/2010/08/modelo-evolutivo.html
Page | 57
11. Anexos
11.1 DOCUMENTACIÓN DE TECNICA DE RECOLECCIÓN DE DATOS (TECNICA
DE RECOLECCIÓN DE DATOS UTILIZADA, PARA SU DESARROLLO).
Encuesta
1. ¿Cuál es el principal problema que existe en el proceso actual?

-Poca organización de la información.
-Dificultad al consultar por información.
-Poco control sobre beneficiarios y causantes.
-Hay más subsidios que necesitan el mismo apoyo que el SUF y la Asignación Social, y
no se les ha entregado.
2. ¿Cómo controlan actualmente la información que manejan?

-Estamos llenando Excel's con información, con la finalidad de algún día intentar
gestionarla, pero la información se pierde y cuando se intenta consultar generalmente
toma mucho tiempo encontrarla y muchas veces, al no tener un formato obligatorio el Rut,
al realizar búsquedas no se sabe si es que exactamente ese registro lo ingresaron con
puntos o guion, o sin puntos ni guion.
-Además, nos llenamos de papeles con los subsidios que trabajamos, nos serviría
trabajar esa información directamente en una aplicación que almacene esos datos que
se llenan en los formularios y así nos ahorraríamos el papeleo, ya que quedará registrado
localmente y además podríamos consultarlos, cosa que actualmente cuesta mucho,
sabiendo que tenemos una bodega llena de cajas y llena de formularios que nadie quiere
ir a hurgar para encontrar un especifico.
4. ¿Cuántos tipos de usuarios actúan en el sistema?

-Dos tipos, el beneficiario y el causante, siendo el beneficiario el tutor de un causante.
-En el caso del subsidio de agua potable, este se puede asignar a un beneficiario como
también a un comité, que es una entidad que solo participa en ese subsidio, y puede
poseer varios beneficiarios.
5. En el caso de los beneficiarios

5.1 ¿Qué información desea almacenar de los beneficiarios?
Nombre, Apellidos, Rut, Fecha de Nacimiento, Sexo, Domicilio, Código
Postal, Ciudad, Edad, si es que es Seguridad Oportunidades, Teléfono, Tipo de Tutor.
6. En el caso de los causantes

6.1 ¿Qué información desea almacenar de los causantes?
Nombre, Apellidos, Rut, Fecha Nacimiento, Fecha Probable Concepción,
Tipo de Causante, Sexo, Estado, si es que es Seguridad Oportunidades, Edad.
7. ¿Cuántos subsidios debe controlar esta aplicación?

-Cuatro Subsidios.
-Subsidio Único Familiar, Subsidio Agua Potable, Subsidio Discapacidad Mental,
Subsidio Asignación Social.
7.1 ¿Qué información desea almacenar de los subsidios?
El Causante/Beneficiario o Comité que se relaciona con el, la fecha del
Registro o la fecha de su Regularización o Revisión, el Estado y una Observación.
Page | 58
8. ¿Los subsidios tienen distintos requerimientos, o todos se pueden solicitar con la

misma información?
-Todos tienen distintos requerimientos.
9. En el caso del subsidio único familiar, ¿cuáles son los requisitos para optar a él?
-Solicitan Carné de Niño Sano o Certificado de Alumno Regular, todo dependerá de la
edad del causante(SUF).
10. En el caso del subsidio asignación social, ¿cuáles son los requisitos para optar a él?
-Filtran por el estado de Seguridad Oportunidades(AS).
11. En el caso del subsidio de agua potable, ¿cuáles son los requisitos para optar a él?
-No tiene mayores requisitos.
12. En el caso del subsidio discapacidad mental, ¿cuáles son los requisitos para optar a
él?
-Filtran por edad(DM).
13. ¿El subsidio de agua potable es otorgado a un beneficiario?

-Si.
14. En el caso del subsidio de agua potable, los comités a los que también se les puede
asignar, ¿que información poseen?
-Rut, Nombre del Comité, Dirección, Fecha en que se registró.
15. ¿Qué tipo de operaciones desearía realizar en la gestión de actores en el sistema?

-El ingreso de ellos, la modificación y la consulta.
16. ¿Qué tipo de información le gustaría recibir en el caso de consultar información a un

beneficiario/causante?
-Beneficiarios: Nombre, Apellidos, Edad, Dirección, Teléfono, Tipo de Tutor, los subsidios
que este posee y los Causantes que están asignados a él/ella.
-Causantes: Nombre, Apellidos, Edad, Subsidios que posee y el Beneficiario que es su
tutor.
17. ¿Le gustaría realizar informes?

-Si.
17.1 ¿Que informes le gustaría visualizar?
Causantes: Subsidios Activos e Inactivos, Revisiones Atendidas entre
fechas, Regularizaciones atendidas entre fechas, Registros atendidos entre fechas.
Beneficiarios: Solo las atenciones que se realizaron.
17.2 ¿Que información es la que usted desea visualizar en los respectivos

informes?
-La misma que se utiliza para la consulta, quizás algo más resumido.
18. ¿Le gustaría recibir alertas sobre los casos críticos, para tener un control más
preciso?
Page | 59
-Si.
18.1 En las alertas, ¿qué información le gustaría visualizar?
-Información relevante del Usuario.
19. En las alertas, ¿Le gustaría que la grilla que muestre a los beneficiarios/causantes
que necesiten atención le dirija a un formulario pre-definido como una carta de citación?
-Si.
20. ¿Cuáles subsidios son asignados a Causantes?

-Todos excepto agua Potable.
21. ¿Cuáles subsidios son asignados a Beneficiarios?

-Todos, los beneficiarios poseen los mismos subsidios que son otorgados a los
causantes. n
22. ¿Necesita controlar cuáles actores pertenecen a Seguridad Oportunidades?

-Si.
Brainstorming
¿Cómo crear un sistema para cubrir las necesidades actuales?
Algo ordenado para alimentar con información.

Realizar consultas expeditas sobre Causantes o Beneficiarios y que muestren
información útil.
Que las asignaciones sean rápidas a los causantes o beneficiarios.
Hacer una interfaz simple.
Que muestre alertas.
Que las alertas conlleven a un formulario que se utilice para ser enviado como carta de
notificación.
Que muestre informes sobre usuarios que se atendieron entre rango de fechas.
Que muestre informes sobre usuarios que estén inactivos.
Que no solo se utilice para el SUF, sino que también se puedan implementar otros
subsidios.
Que distinga entre beneficiarios y comités.
Page | 60
Alternativa:
¿El sistema será usado por usuarios con conocimientos de computación medio/bajo?
[x] SI [ ] NO
¿Desea que el sistema sea de escritorio?

[x] SI [ ] NO
¿Desea que el sistema almacene información de los usuarios?

[x] SI [ ] NO
¿Desea que el sistema maneje información de morosidad de los usuarios?

[ ] SI [x] NO
¿Desea que el sistema realice reportes?

[x] SI [ ] NO
¿Desea que el sistema le otorgue control sobre usuarios en estado crítico?

[x] SI [ ] NO
¿Desea que el sistema le permita generar cartas con solo un clic?

[x] SI [ ] NO
Page | 61
11.2 DOCUMENTACIÓN DE METODOLOGIA USADA

Modelo de Prototipo3
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se
construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los
que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que
se necesita así como también la solución que se propone para dicha necesidad y de esta
forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del
desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que
se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero
no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos

generales para el software a desarrollarse sin delimitar detalladamente los requisitos de
entrada procesamiento y salida, es decir cuando el responsable no está seguro de la
eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa
el hombre y la máquina. Este modelo se encarga principalmente de ayudar al ingeniero
de sistemas y al cliente a entender de mejor manera cuál será el resultado de la
construcción cuando los requisitos estén satisfechos.
Su objetivo es que el sistema, o alguna de sus partes, se construyan rápidamente para

comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el
desarrollador, el usuario y el cliente estén de acuerdo en lo que se necesita, así como
también la solución que se propone para dicha necesidad y de esta forma minimizar el
riesgo y la incertidumbre del desarrollo.
Este modelo se podría aplicar ya que el cliente define un conjunto de objetivos generales
para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada
procesamiento y salida, es decir, cuando el responsable no está seguro de la eficacia de
un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa hombre y
máquina.
Etapas para la elaboración:

Identificar requerimientos básicos de usuario.
Desarrollar prototipo inicial
Usar el prototipo
Revisión y mejora del prototipo
Etapas de ciclo de vida del sistema:
Definición del proyecto: Identificación de problemas, oportunidades y objetivos. Se

determinan requerimientos de información de manera objetiva.
Se analiza si es preciso implementar un nuevo sistema o modificar el existente.
Análisis de sistemas: Se analizan los problemas, necesidades del sistema utilizando

diagramas de flujo, entrevistas, análisis de documentos e informes.
Diseño: Se elabora el diseño lógico, se hacen descripciones formales.
3 http://gestionrrhhusm.blogspot.cl/2011/05/modelo-de-prototipo.html
Page | 62
Programación: Etapa técnica, consiste en traducir las especificaciones de diseño en un

código de programación.
Instalación: Consiste en comprobar el sistema, se analiza la forma en la que se

implantará, se capacita al personal, se documenta y se hacen las primeras evaluaciones.
Post-Implantación: Se evalúa el sistema después de entrar en funcionamiento, incluyen

actualizaciones y se puede llegar a una auditoria formal para ver si el sistema cumple los
requisitos.
Ventajas
1. Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes.
Esto ocurre con cierta frecuencia en muchos proyectos de software.
2. Como información complementaria a los requisitos constituyen un gran apoyo a las
estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
3. Son más fáciles de abordar con los usuarios finales.
4. El usuario participa más activamente en la construcción del producto de software
(La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo, lo puede
“utilizar” desde el primer momento.
5. Se reduce el riesgo o la incertidumbre sobre la implementación del software.
6. Su uso redunda en una mayor satisfacción del usuario con el producto final, ya que
él o ella han participado activamente de su diseño.
7. Proporciona al usuario un mayor conocimiento del sistema con una curva menor
de aprendizaje.
8. Permite a todos los involucrados entender bien y mejor el problema antes de la
implementación final.
Desventajas
1. El usuario quiere empezar a trabajar desde el primer momento con el prototipo para
solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será
el producto.
2. Los prototipos generan o pueden generar otro tipo de problemas si su presentación
y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los
usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar
inconformes luego de verlos por primera vez. También es posible que se pierda mucho
tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los
prototipos.
3. Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y
mucho más involucramiento si queremos que participe en su creación.
4. Una desventaja importante a tener en cuenta es la falta de experiencia que tienen
muchos Analistas Funcionales en programación y en actividades de diseño de interfaces
de usuario.
Page | 63
Desarrollo Evolutivo
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más
completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más
allá, durante la fase de operación. Los modelos “Iterativo Incremental” y “Espiral” (entre
otros) son dos de los más conocidos y utilizados del tipo evolutivo.
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle
el sistema adecuado. Una ventaja de este modelo es que se obtiene una rápida
realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas
se ejecutan en cada iteración.4
Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para
explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las
partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos
atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es

comprender los requerimientos del cliente y entonces desarrollar una definición mejorada
de los requerimientos para el sistema. El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más
ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando
a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios
requerimientos.
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle
el sistema adecuado. Una ventaja de este modelo es que se obtiene una rápida
realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas
se ejecutan en cada iteración.
El cliente recibe incrementos del sistema a medida que van siendo liberados por el
desarrollador, los cuáles se identifican como distribución incremental
4 http://jorgetrejos.blogspot.cl/2010/08/modelo-evolutivo.html
Page | 64
Ventajas5:
La especificación puede desarrollarse de forma creciente.
Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja
en una mejora de la calidad del software.
Es interactivo, ya que con cada incremento se entrega al cliente un producto operacional,

que puede evaluarlo
Es más efectivo que el modelo de cascada, ya que cumple con las necesidades
inmediatas del cliente.
Ajuste de personal, refiere a que permite variar el personal asignado a cada interacción
Desventajas:
El proceso no es visible. Los administradores tienen que hacer entregas regulares para
medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir
documentos que reflejen cada versión del sistema.
A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden
a corromper la estructura del software. Incorporar cambios en él se convierte cada vez
más en una tarea difícil y costosa.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para

sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el
desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos
grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan
grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques
evolutivos y de cascada.
1 2 3 4 5
*Grafico representativo de los incrementos convertidos en entregables. 6
Entregas incrementales implican no solo código, si no también manuales de uso
5 http://www.gazafatonarioit.com/2012/07/ventajas -y-desventajas-del-uso-de.html
6 http://informaticaycalidadsw.wikispaces.com/file/view/MODELO+EVOLUTIVO.pptx
Page | 65
Este modelo va por etapas que entregan al cliente algo útil, se puede medir
el valor agregado a cada incremento y se ajusta al diseño y a los objetivos en base a las
mediciones.
En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza

evolutiva del software, se plantea como estático con requisitos bien conocidos y definidos
desde el inicio.
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más
completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más
allá, durante la fase de operación.
Page | 66
Prototipos Desechables
Donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos

del cliente y entonces desarrollar una definición mejorada de los requerimientos para el
sistema.
Ya que los requerimientos no están bien definidos y se debe realizar la toma de estos,
procesarlos y realizar una solución en base a los requerimientos de forma mejorada.
Además de que se puede mostrar de forma creciente.
Definición del problema y especificación inicial en

Especificación base a los requerimientos definidos
Inicial
Desarrollo del software en base a un proceso con

Desarrollo del énfasis en la rapidez de la liberación
Producto
Implantación y uso del software en un ambiente de

explotación, además de un monitoreo de los nuevos
Implementación, uso requerimientos.
y evaluación
Versiones de
Software
Re-especificación Re-definición del problema en base a los nuevos

requerimientos
Page | 67
Justificación
Se escogió la metodología evolutiva, específicamente sus prototipos desechables, debido

a la falta de seguridad de la persona encargada del departamento de subsidios con
respecto al sistema que se estaba solicitando.
Los prototipos desechables fueron de mucha utilidad en la creación del sistema ya que,
el encargado al no conocer bien lo que se necesitaba, dio muchos requerimientos y
solicitudes, ideas y opiniones de lo que él creía necesario que un sistema debería cubrir
satisfaciendo específicamente los vacíos y vulnerabilidades que existían.
Por aquello se tomaron los requerimientos y se empezaron a trabajar y a pulir hasta llegar
a un sistema, el cual cubría las necesidades ya explicadas anteriormente, pero que, al
trabajar con un cliente con conocimiento basto en informática y procesos de desarrollo,
este solicitó el agregar más subsidios al sistema, por lo que se realizó una nueva toma
de requerimientos la cuál arrojó resultados distintos a lo que se tenía, obviamente
conservando la base actualmente existente.
Al realizarse sus cambios se realizó un nuevo prototipo el cuál se presentó y, que con
éxito se aceptó, se observó la necesidad de ciertos requerimientos extras, como
mantenedores que, si bien no se notaron antes, el cliente realizó una nueva
especificación del subsidio de agua potable, el cuál no trabajaba solo con beneficiarios,
sino que también con comités, y se subdividió en dos procesos más, rurales y urbanos,
los cuáles se ligaban a los comités. Por lo que al mostrar este prototipo se tuvo que
realizar una nueva toma de requerimientos y se realizó el nuevo prototipo el cual ya
cumpliendo con las expectativas necesitó una nueva iteración para el subsidio de
discapacidad mental.
Page | 68
11.3 ESTANDARIZACIÓN DE DESARROLLO (Estándares de

definición de variables, Documentación de código y Mensajes de error).
Controles:
Los textBox, Checkbox, DateTimePicker, Labels, se crearán y se programarán con sus
nombres por defecto, siendo guiado por la visualización del Windows Form.
No se repetirán los mismos nombres de variables dentro de un mismo form.

Correcto:
Int edad;
If(edad == 0){
MessageBox.Show(“Su edad es “+edad+””)
Incorrecto:
Int edad; If(edad == 0) {
Int edad = 1 MessageBox.Show(“Su edad es “+edad+””)
Se utilizará el símbolo “+” para concatenar variables dentro de una sentencia o alerta.
Se comentará con //COMENTARIO en las funciones que se encuentren necesarias de

documentar.
Se incluirán espacios en la codificación.

Correcto:
If(edad == 0){
MessageBox.Show(“Hola”);
Incorrecto:
Int edad; If(edad == 0) { Int edad = 1 MessageBox.Show(“Su edad es “+edad+””)}
Se tabulará el código según el siguiente formato:
While (Valor < N){
If(valor % 3 == 0){
MultiploTres++;
Page | 69
Else{
//otra cosa
Valor++
}
Las variables creadas tendrán el nombre explícito de la variable requerida, en caso de
ser de dos frases se utilizará la primera letra en minúscula de la primera palabra y la
segunda estará anexada a esta sin espacio con su primera letra en Mayúscula separadas
por un guion bajo o sin este.
Correcto:
String RutUsuario;
String nombreUsuario;
String Apellido_usuario
Incorrecto;
String rut usuario;

String nombre-Usuario;
Excepciones:
Para el control de errores se utilizará siempre en las sentencias SQL y métodos que lo
requieran el uso de try y catch respectivos.
La conexión a la base de datos se usará mediante código dirigiéndose a un archivo local

dónde se encuentra el string de conexión que se invocará siempre al inicio de cada form.
Las consultas serán llamadas desde una clase SQL creada en un .cs.
Query.insertar, query.Actualizar, query.consultar para sus respectivas funciones.
Mensajes de error:
Cuándo el sistema encuentre una falla dentro de las operaciones o detecte un fallo en
alguna validación enviará un error al usuario con el problema especifico en forma de
alerta.
Ejemplo:
if (validarRut(textBox1.Text).Equals(false))
{
MessageBox.Show(“El Rut no es válido, verifique”);
}
Page | 70
11.4 DICCIONARIO DE DATOS

NOTA: El diccionario de datos debe de contener la descripción de todos los
casos de uso que conforman su diagrama de caso de uso.
*Tabla 4, caso de uso modificar.
Caso de uso Modificar
Autor Lucas Olate
Versión y fecha 0001, 25/11/2017
Descripción El empleado realiza tareas de modificación en la
base de datos, ya sea en Beneficiarios, Causantes,
Comités o en Subsidios
Actores: Usuario
Flujo Normal El usuario abre el mantenedor que requiere, ingresa
los datos requeridos y presiona el botón modificar.
El sistema realiza las validaciones
correspondientes y una modificación en la base de
datos al ser aceptado el ingreso.
Flujo alternativo: El usuario ingresa datos invalidos u erróneos y no
puede continuar
Poscondiciones: ------------------------------
*Tabla 4.1, caso de uso ingreso.

Caso de uso Ingresar
Autor Lucas Olate
Descripción El usuario selecciona el mantenedor y realiza un
ingreso de un usuario o subsidio.
Actores: Usuario
Flujo Normal El usuario abre uno de los mantenedores de
ingreso, rellena la información solicitada, el sistema
realiza las funciones de validación y realiza un
ingreso de datos a la base de datos.
Flujo alternativo: El usuario intenta asignar un subsidio a un usuario
no existente y el sistema no permitirá el ingreso de
este.
Poscondiciones: ------------------------------
Page | 71
*Tabla 4.2, caso de uso consultar.

Caso de uso Consultar
Autor Lucas Olate
Descripción El usuario realiza una consulta de ya sea en los
mantenedores de Usuarios o Subsidios.
Actores: Usuario
Flujo Normal El usuario entra en el mantenedor del que requiere
solicitar información, ingresa los datos solicitados
por este y el sistema carga los labels informativos
con la información consultada.
Flujo alternativo: El usuario realiza una consulta pero no existe
información para mostrar.
Poscondiciones: ------------------------------
*Tabla 4.3, caso de uso generación de reportes.
Caso de uso Generar Reportes
Autor Lucas Olate
Descripción El usuario del sistema genera reportes informativos
según su necesidad.
Actores: Usuario
Flujo Normal El usuario va a la pestaña reportes y realiza la
generación de uno, este se carga y muestra la
información solicitada por el usuario.
Flujo alternativo: El informe no tiene información para ser rellenado.
Poscondiciones: ------------------------------
*Tabla 4.4, caso de uso exportación de reporte.
Caso de uso Exportar Reporte
Autor Lucas Olate
Descripción El usuario al generar un reporte puede seleccionar
la opción de exportar este mismo, para mas tarde
realizar otras operaciones con este.
Actores: Usuario
Flujo Normal El usuario va a la pestaña reportes y al generar uno,
presiona el botón exportar, el cuál le genera un
archivo del reporte en formato pdf.
Flujo alternativo: El usuario no presiona el botón
Poscondiciones: ------------------------------
Page | 72
*Tabla 4.5, caso de uso ver alertas.

Caso de uso Ver Alertas
Autor Lucas Olate
Descripción El usuario revisa la sección alertas y puede
seleccionar entre las disponibles, la que desee
revisar para conocer más información respecto a la
generación de la alerta.
Actores: Usuario
Flujo Normal El usuario va a la sección de alertas y selecciona las
regularizaciones vencidas, hace click y le aparece
información sobre todas las regularizaciones
vencidas.
Flujo alternativo: El usuario va a la sección de alertas pero no existe
ninguna alerta de momento.
Poscondiciones: ------------------------------
*Tabla 4.7, caso de uso generar carta.

Caso de uso Generar Carta
Autor Lucas Olate
Descripción El usuario puede generar una carta de notificación
con los datos del usuario para posteriormente ser
enviada o comunicada al personal para que se
pongan en contacto con el/la individuo/a
Actores: Usuario
Flujo Normal El usuario selecciona las Revisiones vencidas y al
ver las personas que están listadas, selecciona una
y oprime generar carta, este genera una carta con un
formato predefinido el cuál puede imprimir.
Flujo alternativo: El usuario no selecciona ninguna registro en la grilla
por lo que no puede generar una carta.
Poscondiciones: ------------------------------
Page | 73
11.5 Diseño Físico Del Proyecto (Desarrollo De Aplicación En

Lenguaje Seleccionado)
11.5.1 Pantallas (Menú Principal, Pantalla De Ingreso, Pantalla De Consulta Simple

Y Compleja, Pantalla De Modificación, Mensaje De Advertencia, Mensaje De
Confirmación De Operación, Informe)
Imagen 11, Login.
Imagen 11.1, Login.

Page | 74
Imagen 11.2, Ingreso Beneficiario.
Page | 75
Imagen 11.2, Ingreso Causante.
Page | 76
Imagen 11.3, Consultar Beneficiario.
Imagen 11.4, M odificar Beneficiario.
Imagen 11.5, Alertas.
Page | 77
Imagen 11.6, Reporte Causantes atendidos
Imagen 11.7, M enu.
Page | 78
11.5.2 INFORMES IMPRESOS
Imagen 12, Informe Subsidios inactivos.
Page | 79
Page | 80
Imagen 12.1, Informe Causantes atendidos regularización
Page | 81
Imagen 12.2, Informe Causantes atendidos
Page | 82
11.6 Control De Version De Sw A Entregar (Estructura Que Debe De

Contener El Documento).
*Tabla 5, control de versión de SW. 7
# Fecha Versión Autor Organización Descripción
Ejemplo:
*Tabla 5.1, control de versión de SW EJEM PLOS.

# Fecha Versión Autor Organización Descripción
1 18-12- 0.8 Lucas Municipalidad -Se agregó la funcionalidad para
2017 Olate de Los verificar el estado del subsidio de agua
Ángeles potable para los comité.
-Se quitó un label visible de
funcionamiento interno en el formulario
de asignación social
2 18-12- 0.9 Lucas Municipalidad -Se creó el formulario para realizar
2017 Olate de Los seguimiento de tramite compín.
Ángeles -Se agregaron validaciones a todos los
campos de RUT existentes en la
aplicación.
3 18-12- 0.9.1 Lucas Municipalidad -Se arregló validación incorrecta de
2017 Olate de Los RUT en formulario de Ingreso de
Ángeles Causante.
-Se arregló alerta regularizaciones que
no mostraba el numero de alertas en el
botón.
7 http://www.pmoinformatica.co m
Page | 83
11.7 Controles De Tareas O Bitácora.

*Tabla 6, control de tareas o bitácora.
Datos de la Bitácora
Fecha Inicio Numero de Hora
Fecha bitácora
Termino
Persona a cargo
Nombre Completo
RUT Fono
Cargo
Datos Tarea
Breve
descripción
Actividad
Comentarios
11.8 Documentación De Seguimiento
*Tabla 7, Documentación de seguimiento.

Documentación de seguimiento
Fecha de revisión
ID Descripción tarea Versión Estado(% ) Responsable
Comentarios:
Page | 84
11.9 Planificación de control de riesgos identificados

*Tabla 8, Planificación de control de riesgos identificados
Riesgo Asociado Tarea de control Tarea de control en
anticipado emergencia
 No existieron pruebas Realizar pruebas de Buscar nuevo programador
programación a los especializado en el lenguaje
de que el programador candidatos a utilizado
realmente tenia todos programador en el
proyecto
los conocimientos
 No se hicieron pruebas Realizar un plan de Realizar un plan de pruebas

pruebas estable y con urgencia barcando solo
adecuadas para probar concreto que permita los riesgos mas
la identificacion y potencialmente peligrosos
mitigacion de los para el sistema
riesgos
 Mala estimación del Realizar una carta Solicitar a la empresa una
gant con las horas de extensión del tiempo de
tiempo de desarrollo del holgura necesarias y desarrollo, acudiendo a la
proyecto plazos alargados justificacion de esta con
todas las tareas faltantes de
desarrollar.
 Diseño inadecuado Realizar bosquejos Re diseñar la GUI del
con alta usabilidad y sistema bajo una evaluación
accesibilidad del mismo cliente
 Mala especificación del Realizar la toma de Lograr hacer funcionar los
requerimientos al requerimientos principales y
proyecto cliente siendo realizar una nueva toma de
especificos en sus requerimientos para
necesidades completar el sistema
 Mala especificación del Realizar una correcta Consultar al cliente sobre la
toma de funcionalidad principal y re-
alcance del proyecto requerimientos especificar el alcance del
proyecto
 La no comunicación de Realizar y entregar Entregar un sistema que
documentación de funcione completo e intentar
los Estándares estandares a los cumplir con la mayoria de
programadores antes estandares.
del comienzo del
desarrollo
 La no comunicación Promover la Solicitar entregables y
comunicación y el modulos individualmente e
entre los involucrados trabajo en equipo en intentar solucionar la no
en el proyecto la presentacion del comunicación
equipo.
 La interfaz del sistema Realizar un diseño de Corregir problemas que
la GUI en base a la hacen la interfaz inestable
es inestable usabilidad, con urgencia
funcionalidad y
accesibilidad.
 Los informes necesitan Diseñar informes Alivianar la carga de datos
simples y concisos. reduciendo el numero de
más tiempo del previsto datos pero manteniendo la
cantidad de información.
Page | 85
 No se sigue la Realizar y entregar la Exigir el uso de la

metodologia a los metodología y en caso
metodología programadores antes extremo forzar el uso de
seleccionada de comenzar su esta.
desarrollo.
 No cumple con la Realizar la carta gantt Exigir los entregables o
y entregarla a los buscar otro programador
planificación encargados del interesado en cumplir
desarrollo. planificaciones.
 No se ejecutan los Establecer Buscar un nuevo encargado
checkpoints del que realice los controles
controles necesarios sistema y ejecutarlos necesarios al sistema.
cuando se deba.
 No se realizan las Establecer un plan de Planificar un plan de pruebas
pruebas y entregarlo y realizarlo de forma
pruebas necesarias a los desarrolladores exhaustiva.
y tester antes de su
comienzo.
 No se definen riesgos Establecer riesgos Realizar una revisión de los
antes del comienzo requerimientos y establecer
dentro del proyecto del desarrollo del riesgos importantes o
proyecto. graves.
 Riesgos no controlados Establecer un plan de Realizar una analisis de
riesgo antes del riesgos y generar un plan de
comienzo del riesgo eficiente y expedito.
desarrollo del
proyecto.
 Mala estimación del Hacer entrega de los Apurar las tareas de
plazos estipulados en desarrollo y como ultimo
tiempo de desarrollo del la carta gantt antes recurso solicitar una
proyecto del comienzo del extension de tiempo
desarrollo.
 Diseño inadecuado Hacer entrega de los Organizar los elementos y
layouts requeridos realizar un re-diseñado del
antes del comienzo sistema.
del diseñado del
sistema.
 Canales de información Estandarizar los Establecer un canal
canales de estandar y realizar un
mal definido información en las bombardeo de información
reuniones de
proyecto
 No definición acciones Establecer acciones Definir acciones correctivas
correctivas antes del express y realizar su
correctivas comienzo del ejecución
proyecto
 No definición Establecer en las Incentivar o Exigir
reuniones grupales retroalimentacion entre los
actividades de las actividades que se participantes del proyecto.
retroalimentación realizaran para
generar
retroalimentacion
 No se crearon Establecer las Establecer actividades de
actividades de revisión acorde al desarrollo
actividades revisión revisión o el estandar actual del sistema.
de estas antes del
comienzo del
proyecto
Page | 86
 No existencia de planes Establecer los planesElaborar un plan de

de contingencia antes
contingencia de forma
de contingencia del desarrollo del rapida y ingresarlo en la
proyecto. documentacion
 Los avances no Establecer los plazos
Realizar una re-
y las fechas de los especificaicon de los
cumplen las entregables y lo querequerimientos y realizar
expectativas deben contener. revisión de estos con
respecto al desarrollo actual
y comenzar a solicitar las
tareas que se deben realizar.
 Los componentes Instalar los Aumentar la potencia de los
componentes ordenadores que ejecutan
utilizados no rinden recomendados tareas y componentes del
como se esperaba siguiendo las sistema.
especificaciones de
software y hardware
minimas.
 Problema de hardware Especificar el Realizar cambio de
hardware requerido a hardware en caso de falla
utilizar antes del extrema.
comienzo del
proyecto.
Page | 87
11.10 Representación Gráfica De Planificación Temporal
Imagen 13,Carta Gantt.

Page | 88
Imagen 13.1,Carta Gantt.

Page | 89
Page | 90

Page | 91
11.11 Documentación Del Plan De Prueba
DATOS DE PRUEBA:
Campos de RUT: sólo caracteres numéricos 1-9 y con longitud máxima de 9

caracteres.
Campo Teléfono: Sólo caracteres numéricos 1-9 con longitud máxima de 11

números.
Ejemplo valido de ingreso: 989064986, 89064986
Ejemplo invalido de ingreso: 9890649-86, +56989064986, 56989064986
Campo Nombre: Sólo caracteres alfabéticos A-Z, a-z.

Ejemplo valido de ingreso: Lucas Esteban, Lucas.
Ejemplo invalido de ingreso: Lucas Esteban, Lucas-Esteban, Lucas.Esteban.
Campo Apellidos: Sólo caracteres alfabéticos A-Z, a-z.

Ejemplo valido de ingreso: Olate Zapata, Olate.
Ejemplo invalido de ingreso: Olate.Zapata, Olate-Zapata.
Campo Dirección: Sólo caracteres alfabéticos A-Z, a-z con longitud máxima de
30 caractéres.
Ejemplo valido de Ingreso: Las tórtolas, Las golondrinas, Estados Unidos.
Ejemplo invalido de ingreso: Las tórtolas 578, Las golondrinas.899, Estados
Unidos 882.
Campo Numero dirección: Sólo caracteres numéricos 1-9 con longitud máxima
de 5caractéres.
Ejemplo valido de ingreso: 987, 882, 4523, 52939.
Ejemplo invalido de ingreso: Nueve Ocho Siete, Ochocientos ochenta y dos,
Cincuenta y dos mil novecientos treinta y nueve.
Campo Observación: Caracteres Alfabéticos y numéricos A-Z, a-z, 1-9.
Campo Usuario: Sólo caracteres numéricos 1-9 y con longitud máxima de 9

caracteres.
Debe ser un RUT valido.
Campo Contraseña: Caracteres numéricos 1-9 mezclado con caracteres

alfabéticos A-Z,a-z.
Ejemplo Valido de ingreso: 999v7mx, chile2989, lucas1993
Ejemplo Invalido de ingreso: 1_22vl, 49SIX.TWENTYFOUR, 900999-999.
Page | 92
PRUEBA DE ACEPTACIÓN
Ingresar: Este debe ingresar un nuevo registro en la base de datos, ya sea de
cualquier mantenedor que habilite esta función.
Modificar: Este debe ser capaz de modificar un registro en la base de datos, ya
sea de cualquiera de los mantenedores que habilita la función.
Consultar: Este debe ser capaz de mostrar los resultados predeterminados por el
mantenedor al ingresar los datos solicitados por el usuario.
Ver reportes: Este debe ser capaz de generar y mostrar reportes para el usuario.
Exportar Reportes: La aplicación debe ser capaz de exportar los reportes con
cualquier tipo de fin que el usuario le dé a este.
Ver Alertas: La aplicación debe ser capaz de Generar alertas informativas para el
usuario, estas corresponden netamente a los registros por vencer y vencidos en
la aplicación.
Generar cartas de notificación: La aplicación debe ser capaz de generar una
carta de notificación por usuario de los subsidios.
*Tabla 9, casos de prueba de acep tación.
Caso de uso Prioridad
Ingresar MUY ALTA
Modificar MUY ALTA
Consultar MEDIA
Ver Reportes MUY ALTA
Exportar Reportes MEDIA
Ver alertas ALTA
Generar cartas de notificación ALTA
*Tabla 9.1, Pruebas de aceptación.
Actividad Respo Hora Hora Duració Observación Resultad
nsable Inicio Termino n o
Ingreso Tester 19:20 19:21 1 min Exitoso
Beneficiario
Modificar Tester 20:05 20:07 2 min Exitoso
Beneficiario
Consultar Tester 21:00 21:01 1 min Exitoso
Beneficiario
Ver Reportes Tester 21:20 21:22 2 min Exitoso
Regularizaci
ón
Exportar Tester 21:35 21:35 ~1 min Exitoso
Reportes
Ver alertas Tester 21:40 21:45 5 min Exitoso
Generar Tester 21:46 21:50 4 min Exitoso
carta
Ingreso Tester 22:00 22:02 2 min El causante Fallido
Causante ya estaba
ligado a un
beneficiario
Asignación Tester 22:05 22:06 1 min Exitoso
de
Page | 93
Beneficiario a
comité
PRUEBAS DE FUNCIONABILIDAD
*Tabla 10Formulario de pruebas de funcionabilidad.
Característica Sub- Preguntas para S N Observacione
Caracteristic evaluar la calidad I O s
a de la aplicación
Adecuación ¿Al someter al X
programa a
diversas tareas
básicas, cumple
este el/los
requerimiento/s
del/los
usuario/s?
Exactitud ¿Realiza las X
tareas de
FUNCIONABILIDA manera tal que el
D resultado de las
mismas sea
correcto?
¿Se cumple con X
los estándares
Conformidad relacionados con
la aplicación y las
convenciones?
¿Son muy X
limitadas o
incompletas las
funciones que
realiza el
software?
¿Están X
protegidos los
datos que
manipula el
sistema?, ya sea
en su tiempo de
Seguridad proceso y
transito, como
así también en
sus estado de
almacenamiento
?
¿Es muy X
vulnerable al
ataque de
Page | 94
hackers/crackers
?
¿Tiene X
contemplado un
sistema de
recuperación,
ante perdida de
datos?
*Tabla 10, Pruebas de funcionabilidad
# Mantenedor Característica Encargado Estado Comentario
a Mantenedor Mantenedor
Probar
1 Login Validacion Programador Funcional Se validan los
datos
correctamente
2 Beneficiario Ingreso Programador Funcional Se realizo el
ingreso correcto
y se solicitan las
correcciones
requeridas
3 Beneficiario Modificar Programador Funcional Se realiza la
búsqueda y se
pasan los datos
necesarios, se
modifican si
todos están
correctos.
4 Beneficiario Consultar Programador Funcional Al ingresar los
datos se
rellenan los
labels
informativos.
5 Causante Ingreso Programador Funcional Al ingresar el
beneficiario se
cargan sus
labels
informativos
para proceder a
rellenar la
información del
causante, que si
es correcta se
hace un ingreso
exitoso.
6 Causante Modificar Programador Funcional Al ingresar los
datos solicitados
se rellenan los
textos
Page | 95
informativos
para proceder a
modificarlos.
7 Causante Consultar Programador Funcional Al ingresar los
datos se
rellenan los
textos
informativos
disponibles.
Page | 96
PRUEBAS DE INTEGRACIÓN
Se utilizará el método Top-Down que corresponde al test de los componentes
desde el más genérico al mas especifico.
Los datos de prueba utilizados en esta prueba serán usuarios con distintos
conocimientos en computación y el uso del sistema en cuestión.
Resultados:
Imagen 14, Prueba de integración, actividades del sistema.

Page | 97
Primera fase de la prueba de integración a los siguientes

módulos:
-Revisar alertas
-Generación de carta
Segunda Fase de la prueba de integración a los siguientes módulos:
-Ingreso de beneficiario
-Modificación de beneficiario
-Consulta de beneficiario
-Ingreso de causante
-Modificación de causante
-Consulta de causante
-Ingreso comité
-Modificación comité
-Consulta comité
Tercera Fase de la prueba de integración a los siguientes módulos:
-Asignar Subsidio a Causante
-Asignar susidio a Beneficiario
-Asignar subsidio a Comité
-Modificar Subsidio
-Extinguir Subsidios
Cuarta Fase de la prueba de integración a los siguientes módulos:
-Generar Reportes
-Exportar Reportes
Resultados
Se fue comprobando y verificando que las distintas clases que actúan en los
módulos probados en la prueba de integración no han mostrado fallos en su
comunicación y por tanto en su integración los pocos que se han encontrado no
han sido muy complicados de rectificar.
Para lo que se ha controlado el correcto funcionamiento de todos los formularios
existentes en la aplicación.
Para los formularios de registro de usuarios, el único campo verificable es el campo
de RUT, el resto de los campos ingresados no existe una posibilidad de saber si
los datos son realmente verídicos o correctos.
Otra cosa, existen una serie de acciones relacionadas con el envío de formularios
que producen situaciones de error.
Por ejemplo, el ingreso de un usuario ya existente, o el envío de un formulario
vacío, que, por necesidad de una buena integridad en la información que entra en
la base de datos, se han controlado todas estas acciones erróneas con mensajes
de errores y restricciones prohibitivas.
Page | 98
PRUEBAS DE CAJA NEGRA: REQUERIMIENTOS

FUNCIONALES
*Tabla 11, pruebas de caja negra, req. Funcionales.
N° Caso Accione Datos de Resulta Resulta Estado N° de
Prue de s prueba do do de Acció
ba Prueba Especifi Espera Obteni Prueba n
cas do do correc
tiva
1 Ingresa Rellena RUT Valido, Ingreso Resulta Comple 0
r un r todos Nombre, exitoso do tado
cliente. los Apellido, del Espera
campos Dirección, cliente. do.
solicita Telefono,
dos Fecha de
nacimiento,
etc.
2 Asignar Ingresa RUT Valido
Asigna Resulta Comple 0
un SUF r el Existente. ción do tado
RUT exitosa Espera
del del do
cliente subsidi
o.
3 Crear Ingresa Información Creaci Resulta Comple 0
un r datos solicitada en ón do tado
comité del mantenedor. exitosa Espera
Comité del do
comité.
4 Genera Selecci - Creaci Resulta Exitoso 0
r un onar on do
Report cualqui exitosa Espera
e er tipo del do
de Report
Reporte e
y
Exporta
r este.
5 Asignar Realiza RUT Comité Asigna El Exitoso 0
un r la no cion sistem
Benefic asignac existente(11.1 exitosa a alertó
iario a ión de 11.123-k), Rut del de la
Comité un comité no benefic no
Benefici valido. iario a existen
ario a (11.123.144- un cia del
un 4) comité comité
comité consult
en el ado, y
manten alertó
edor de la
Page | 99
asignac invalide
ión. z del
rut
ingresa
do.
PRUEBA DE GUI
*Tabla 12, Pruebas de GUI.

N° Caso Accion Datos de Resulta Resulta Esta N° de
Prue de es prueba do do do Acció
ba Prueba Especif Espera Obteni de n
icas do do Prue correc
ba tiva
1 Llegar Llegar al - Llegada Resulta Exito 0
al manten exitosa do sa
manten edor al Esperad
edor de manten o
ingreso edor
de
Benefici
ario
2 Llegar a Llegar a - Llegada El Exito 0
la la al botónusuario sa
Genera generac genera le costó
ción de ión de la dor de llegar
una carta la cartapero
carta de finalme
notifica nte lo
ción logró.
3 Genera Lograr Fechas(2) Genera El Exito 0
r un generar ción de usuario sa
reporte un reporte llegó al
entre reporte exitoso reporte,
fechas entre seleccio
dos nó las
fechas fechas y
su
reporte
se
generó.
4 Llegar Lograr - Llegada El Exito 0
al llegar al al usuario sa
manten manten manten logró
edor de edor de edor llegar
agua agua sin
potable potable problem
Rural Rural as al
Page | 100
manten
edor
5 Consult Llegar a RUT Consult El Exito 0
ar un la Comité(11.11 a usuario sa.
Comité pestaña 1.111-1) exitosa logró
comité, llegar y
seleccio digitar el
nar RUT, el
consulta cuál le
y entregó
visualiz informa
ar ción.
datos.
Page | 101
PRUEBAS DE ACCESIBILIDAD
Datos de prueba: Datos* + Usuario con conocimiento computacional medio-bajo.
*Tabla 13, Pruebas de accesibilidad.
N° Caso Accion Datos de Result Result Estado N° de
Pru de es prueba ado ado de Acció
eba Prueba Especif Espera Obten Prueba n
icas do ido correc
tiva
1 Ingresa Rellena RUT Ingreso Result Exitoso 0
r RUT r el Valido(18570 exitoso ado
en campo 1379) Esper
Manten RUT ado.
edor
2 Ingresa Colocar 18-12-2017 Prueba Result Exitoso 0
r fecha la fecha Fecha de exitosa. ado
de de nacimiento no Esper
Nacimi nacimie superior a la ado
ento nto en de hoy.
el
manten
edor
Usuario
3 Ingresa Ingresa RUT Valido Se Result Semi- 01
r RUT r RUT 79897159 ingresó ado Exitoso
en en el el RUT, Esper
comité manten pero ado
edor de falta un con
comité label proble
que mas
ayude menor
a su es de
ingreso usabili
en el dad.
manten
edor
4 Genera Buscar - Creació Result Comple 0
r una una n ado tado
carta alerta, exitosa Esper
de selecci de la ado
notificaonar un carta
ción cliente de
y notifica
generar ción.
una
carta.
5 Asignar Ingresa RUT Asigna Result Comple 0
un r en el Comité(79897 ción ado tado
Benefic manten exitosa
Page | 102
iario a edor 159), RUT del Esper

un asignar Beneficiario benefici ado
comité benefici (185701379)s ario al
ario y elección de la comité.
asignarl grilla para
o. datos de
beneficiario
Page | 103
PRUEBAS DE USABILIDAD
Datos de prueba: Distintos usuarios con distintos conocimientos en computación.
Funcionalidades específicas.
*Tabla 14, Pruebas de usabilidad.
# Responsable Tarea Observación Resultado
1 Miguel Ingresar un La letra quizás Exitosa.
Fuentes Beneficiario seria mejor un
poco mas
grande
2 Luciano Flores Ingresar un - Exitosa.
Causante
3 Laura Rios Asignar un - Exitosa.
SUF
4 Lorenzo Rizzo Registrar No cumplió los Fallida.
Asignacion requisitos el
Social usuario que
solicitó el
subsidio.
5 Andres Benz Finalizar el Es de fácil Exitosa.
tramite de entendimiento
COMPIN. el modulo.
6 Laura Rios Desactivar - Exitoso.
subsidio de
agua potable a
un
beneficiario.
Page | 104
Evaluación del Usuario:

*Tabla 14.2, Evaluación del usuario en pruebas de usabilidad..
Caracterís Sub- Preguntas para evaluar S N Observacion
tica Característic la calidad de la I O es
a aplicación
¿Es amigable el software X
para los desarrolladores?
¿Pueden comprender su X
estructura lógica, sus
funciones de ejecución y
procesamiento, su código
Comprensibili fuente es fácilmente
dad legible y comprensible?
USABILID
AD ¿Son cómodos los X
menús, los botones, las
ventanas, las interfaces
los cuadros de dialogo,
los formularios, etc.? ¿las
jerarquías visuales son
correctas?
¿El usuario puede X
aprender a manejar y
utilizar el prototipo en un
tiempo Xcorto?
¿Es intuitivo, y posee la X
Fácil de información y ayudas
aprender adecuadas como para
que el usuario no tenga
que depender de alguien
que explique cómo utilizar
cada función?
¿Es sencillo de entender X Después de
y manejar el software una inducción
Operabilidad para los usuarios a los el sistema es
cuáles está destinado su bastante
uso? intuitivo
¿Es sencillo buscar y X
filtrar información dentro
del programa?
Page | 105
PRUEBAS DE CONFIABILIDAD
Datos de prueba: Datos*, Tester, Modulos principales, Plan de Prueba.
*Tabla 15, Pruebas de confiabilidad.

# Modulo Acción Observación Estado Acción
Correctiva
1 Ingreso Ingresar El sistema Completado
Beneficiario RUT logra avisar
Invalido que el RUT no
22.123.422- es valido.
k
2 Ingreso Ingresar El sistema al Fallido Se realizo una
Comité RUT, darle formato mantención
abandonar al campo y correctiva
campo, luego se fixeando el
volver a vuelve a entrar error
entrar y y a salir genera mediante una
volver a un error función
salir. evasora de
traspaso de
variables no
permitidas.
3 Generar una No El sistema Fallido -
carta de seleccionar genera la carta
notificación ningún sin información
usuario y alguna.
seleccionar
generar
carta
4 Cambiar Modificar el El sistema Exitosa.
estado de estado de genera los
Subsidio de subsidio de labels
agua potable agua informativos y
potable. bloquea las
acciones que
provocarían
error en el
sistema.
Page | 106
Evaluación del usuario:

*Tabla 15.1, Pruebas de confiabilidad, evaluación usuario.
Característica Sub- Preguntas S N Observacione

Característic para evaluar la I O s
a calidad de la
aplicación
Nivel de ¿Es confiable el X
Madurez software para
el usuario final?
¿Después de X
un periodo de
uso: sucede a
veces que el
Tolerancia a usuario
CONFIABILIDA fallas ‘desconfía’
D porque en
ocasiones
anteriores ha
perdido datos
importantes
que le ha
llevado tiempo
cargar?
¿Cuándo falla, X
son fallas
graves o leves,
según las
consecuencias
que provocan?
El sistema, ¿se X El sistema está
cae muy a controlando
Fácil de menudo? gran parte de
aprender los errores
mediante
alertas.
¿Es preciso X
inhabilitarlo por
mucho tiempo
cada vez que
hay que hacer
tareas de
mantenimiento
?
Page | 107
PRUEBAS DE EFICIENCIA
Datos de prueba: Tester, Sistema.
*Tabla 16, Pruebas de eficiencia.
# Encargado Operación Resultado
1 Tester #1 Consultar un Rápido
Causante
2 Tester #2 Consultar un Rápido
Comité
3 Tester #1 Realizar un Normal-Lento
informe con fecha
de comienzo a fin.
4 Tester #3 Ligar un causante Normal
a un beneficiario
5 Tester #4 Abrir el sistema Normal
6 Tester #2 Logear Rápido
7 Tester #1 Revisar alerta y Normal-Lento
generar una carta
de notificación
Resultado del usuario:

*Tabla 16.1, Pruebas de eficiencia, resultado del usuario.
Característic Sub- Preguntas para S N Observacione
a Característica evaluar la calidad I O s
de la aplicación
Comportamient ¿Se ve afectada la X En
o con respecto productividad de comparación al
al tiempo los usuarios por otro sistema
esta lentitud? ocupado, el
sistema
EFICIENCIA funciona mejor.
Cuando el X Hay
volumen de datos operaciones
crece dentro de lo que es
Comportamient contemplado, ¿el inevitable que
o con respecto software se vuelve el sistema no
a recursos lento? se ralentice un
poco.
¿Es capaz el X
software de
procesar/almacen
ar datos de
manera eficiente?
¿Comienza a X El sistema
consumir muchos logra mantener
recursos de un bajo uso de
hardware? los recursos de
HW.
Page | 108
PRUEBAS ALFA Y BETA

ALFA:
*Tabla 17, Pruebas Alfa.
N° Caso de Accione Datos de Resultad Resultado Esta N° de
Prue Prueba s prueba o Obtenido do Acción
ba Especifi Esperad de correct
cas o Prue iva
ba
1 Ingreso Ingresar Todos los El El usuario Fallid 1
Benefici los datos ingreso puede o
ario datos solicitado exitoso llenar los
solicitad s por el de un datos pero
os para mantene Beneficia faltan
realizar dor rio labels
un informativ
ingreso os en
de estos,
benefici como en
ario el RUT,
intentan
ingresar
guiones y
puntos,
además
del guion
K.
2 Ingreso Ingresar RUT La El Fallid 2
de un los VALIDO asignaci mantened o
subsidio datos Y ón or de los
solicitad EXISTEN exitosa SUF
os para TE. de un realiza el
realizar subsidio. ingreso
el correctam
ingreso ente pero
de un hay un
subsidio pequeño
bug en la
solicitud
de
certificado
s.
3 Exporta Buscar Campos La Resultado Exito 0
ción de un de exportaci esperado. sa
un reporte Fecha(2) ón
reporte cualquie exitosa
ra y de un
exportar subsidio.
lo
Page | 109
4 Ver Revisar - La Resultado Exito 0

alertas las visualiza esperado sa
alertas y ción de la
los grilla con
clientes clientes
que la que las
provoca generan.
n
BETA:
*Tabla 17.1, Pruebas Beta.

Nombre Usuario Fecha Mantenedor Problema
Afetado encontrado
Luis Jaramillo 20/11/2017 Ingreso al Hay pocas
sistema(LOGIN) especificaciones
en cuánto al
formato que se
debe usar en el
usuario de ingreso
Alberto Ramirez 27/11/2017 Mantenedor Agua Hay errores en la
Potable comprobación del
RUT
Luis Jaramillo 29/11/2017 Mantenedor SUF Se ve una etiqueta
con nombre
‘label9’ en la
esquina superior
derecha del
mantenedor.
Bernardo 30/11/2017 Mantenedor Si se rellena la
Retamal Causante información del
causante primero,
y después la del
beneficiario se
genera un error
grande.
Page | 110
PRUEBA DE SEGURIDAD Y CONTROL DE ACCESO
*Tabla 18, Pruebas de seguridad y control de acceso.

Característica Sub- Preguntas para SI NO Observaciones
Característica
evaluar la
calidad de la
aplicación
¿Tiene X
Login Usuario habilitadas todas
las funciones el
usuario?
¿Puede gestionar X
PRUEBA DE usuarios del
SEGURIDAD sistema?
Y CONTROL ¿Tiene X
DE ACCESO Login Super habilitadas las
Usuario funciones del
super usuario?
¿Puede añadir X
usuarios al
sistema?
Page | 111

Tesis Final

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

Tesis Final

Cargado por

Copyright:

Formatos disponibles

Ta l ler Integral de Proyectos Informáticos

“Trabajo de proyecto integral para optar al título de

6.2. Identificación De Equipo De Trabajo ....................................... 28

11.10 Representación Gráfica De Planificación Temporal .................. 88

La presente investigación tiene como destino el desarrollo de una plataforma

Actualmente, en una sociedad donde la información se volvió parte crucial de los

Se entiende que la necesidad principal de una empresa es localizar la información

Existe mucha información que actualmente está siendo ingresada, alimentando

En el transcurso de este proyecto pasaremos por distintas etapas que son

Primero se comprenderá la empresa, se analizará quienes son, que hacen y para

Luego la parte fundamental de cualquier desarrollo de software se hará participe,

Para continuar con el desarrollo del proyecto se generarán factibilidades, las

En el siguiente punto que se cubrirá en este proyecto será la planificación de las

metodologías de desarrollo, se identificarán los equipos de trabajo,

Continuando se realizará el diseño lógico del sistema, aquí comienza a tomar

A continuación, se identificarán los tipos de prueba y los datos que se utilizarán

3. IDENTIFICACIÓN DEL PROBLEMA

3.1. Identificación de la Empresa

Nombre de la Empresa: MUNICIPALIDAD DE LOS ÁNGELES.

3.2. Especificación de situación actual

Este sistema fue solicitado por el jefe del departamento de subsidios

3.3. Evaluación de situación actual

La información que se mantiene actualizada es de difícil acceso o no existe

Falta facilidad para realizar consultas a los usuarios.

4.1 Especificación de Requerimientos

1. Subsidio Único Familiar

2. Subsidio Agua Potable

Realizar tareas de desactivación de subsidios si no se cumplen los requisitos mínimos o

4.1.1. Requerimientos SOLICITADOS

4.1.2. Clasificación de requerimientos (tipo e importancia)

*Tabla 1, Clasificación de requerimientos

Mantenedor Funcional Alta

*Tabla 1.1, importancia requerimientos

4.2 Breve Descripción De La Solución A Desarrollar

Descripción: Este mantenedor controlará, mediante filtros de autenticación, la

Objetivo: El usuario ingresará sus credenciales para generar una solicitud de

Descripción: Este mantenedor permitirá el ingreso, modificación y consulta de los

Descripción: Este mantenedor permitirá el ingreso, modificación y consulta de los

Descripción: Este mantenedor permitirá el ingreso, modificación y consulta de los

Mantenedor Agua Potable(RURAL-URBANO):

Mantenedor Subsidio Único Familiar:

Objetivo: realizar la asignación de subsidio a un causante,

Mantenedor Discapacidad Mental:

Descripción: Este mantenedor permitirá el ingreso, modificación y consulta del

Objetivo: la asignación del subsidio a un causante, alimentando al sistema de

Mantenedor Subsidio Asignación Social:

Descripción: Este mantenedor permitirá el ingreso, modificación y consulta del

Objetivo: asignación del subsidio a un Beneficiario, alimentando al sistema con

Resultado ordenado de la información (registros atendidos) solicitada en

Seguimiento Tramite: Este mantenedor permitirá realizar un seguimiento del trámite de

4.3 Objetivo General Del Sistema A Desarrollar

Mantener un control de los actores en el proceso de la toma de un subsidio. Además de

4.4 Objetivo Específico Del Sistema A Desarrollar

Mantener el control de los Beneficiarios.

Estas operaciones se realizarán a través de los mantenedores tanto informativos como

El control de los subsidios se mantendrá a través de los informes que se diseñarán

4.5. Ámbito Y Delimitación De La Solución

5. Factibilidad del proyecto

5.1. Factibilidad TÉCNICA (desarrollo).

Adobe Este software nos ayudara en la 1,5 GHz,Windows 7, 380 MB

*Tabla 2.1, Factibilidad técnica.

5.2 Factibilidad ECONÓMICA (desarrollo).

5.3. Factibilidad OPERACIONAL (desarrollo).

5.4 Factibilidad legal (desarrollo).