Informe Software Ii

UNIVERSIDAD AUTÓNOMA GABRIEL RENÉ MORENO
FACULTAD INTEGRAL DEL NORTE

(FINOR)
CARRERA INGENIERÍA DE SISTEMAS
SISTEMA DE GESTION PARA LA

DOTACION DE CARNET Y
AUTORIZACION SANITARIA
“SUB GOBERNACIÓN-MONTERO”
Docente:
Ing. Edwin Calizaya
Integrantes:
Nery Lázaro Toconás Acevedo
Eligio Eloy Vaca Flores
Oscar Emir Velarde Figueredo
Roly Ponce
Kevin Montaño Zurita
Materia:
Ingeniería del Software II
MONTERO - SANTA CRUZ – BOLIVIA

CONTROL DE CAMBIOS
INDICE
1. INTRODUCCIÓN ........................................................................................................ 1
2. ANTECEDENTES ....................................................................................................... 2
3. DESCRIPCIÓN DEL PROBLEMA............................................................................... 3
4. SITUACIÓN PROBLEMÁTICA .................................................................................... 3
5. JUSTIFICACIÓN ......................................................................................................... 4
5.1. PERSONAL .......................................................................................................... 4
5.2. TÉCNICA .............................................................................................................. 4
5.3. TEÓRICA .............................................................................................................. 4
6. OBJETIVOS ................................................................................................................ 5
6.1. Objetivo General ................................................................................................... 5
6.2. Objetivos Específicos ............................................................................................ 5
7. METODOLOGÍA.......................................................................................................... 6
7.1. Que es eXtreme Programming ............................................................................. 6
7.2. Objetivos que persigue XP .................................................................................... 6
7.3. Roles dentro de XP ............................................................................................... 7
8. ALCANCE ................................................................................................................... 7
9. CRONOGRAMA .......................................................................................................... 9
10. ANALISIS ................................................................................................................ 11
10.1. Requerimientos Funcionales (Product Backlog) ............................................... 11
10.1.1. Tabla Product blacklog ............................................................................... 12
10.2. Requerimientos no Funcionales ........................................................................ 14
10.2.1. Tiempo de Aprendizaje ............................................................................... 14
10.2.2. Identificación del usuario propio de la aplicación ........................................ 14
10.2.3. Confiabilidad ............................................................................................... 14
10.2.4. Performance ............................................................................................... 15
10.2.5. Restricciones de Diseño ............................................................................. 15
10.2.6. Interfaces .................................................................................................... 16
11. DISEÑO DEL SOFTWARE ..................................................................................... 17
11.1. Especificación de Requerimientos de Software ................................................ 17
11.2. Historias de Usuario .......................................................................................... 18
11.2.1. Historia de usuario para Gestionar Categoría ............................................. 19
11.2.2. Historia de usuario para Gestionar Empresa .............................................. 20
11.2.3. Historia de usuario para Gestionar Beneficiario .......................................... 21
11.2.4. Historia de usuario para Gestionar Recibo ................................................. 22
11.2.5. Historia de usuario para Gestionar Exámenes ........................................... 23
11.2.6. Historia de usuario para Gestionar Carnet.................................................. 24
11.2.7. Historia de usuario para Gestionar Autorización ......................................... 25
11.2.8. Historia de usuario para Gestionar Trabajador ........................................... 26
11.2.9. Historia de usuario para Gestionar Usuario ................................................ 27
12. ELABORACION ...................................................................................................... 29
12.1. Arquitectura de la Solución para el modelo de Capas ...................................... 29
12.2. DESCRIPCIÓN DE LA ARQUITECTURA......................................................... 30
12.2.1. Biblioteca de Datos ..................................................................................... 30
12.2.2. Biblioteca de Negocio ................................................................................. 30
12.2.3. Biblioteca de Presentación ......................................................................... 30
12.3. ARQUITECTURA DE LA SOLUCIÓN BASADA EN LA TECNOLOGIA .NET .. 31
12.4. DESCRIPCIÓN DE CAPAS .............................................................................. 31
12.4.1. Capa Presentación ..................................................................................... 31
12.4.2. Capa Negocio ............................................................................................. 32
12.4.3. Capa Dato................................................................................................... 32
12.5. ADO.NET .......................................................................................................... 32
12.6. Diseño Conceptual de la Base De Datos .......................................................... 33
................................................................................................................................ 33
12.7. Diseño Lógico de la Base de Datos .................................................................. 34
12.8. Diseño Físico de la base de .............................................................................. 34
13. IMPLEMENTACION ................................................................................................ 36
13.1. APLICACIÓN DE ESCRITORIO ....................................................................... 36
13.1.1. Implementación de cliente: Clase Cliente ................................................... 36
CAPITULO I
FUNDAMENTOS
TEÓRICOS
1. INTRODUCCIÓN
Los softwares de gestión hoy en día son fundamentales para las empresas porque
existen un mejor control de la información de las actividades que realiza. En este proyecto
se busca mejorar el funcionamiento de esta empresa que no contaba con este software.
La información se constituye como uno de los activos más valiosos para toda institución,
que de ella depende la toma de decisiones que puede afectar o ayudar en un papel
fundamental para el alcance de sus objetivos y metas.
El software a medida es de gran utilidad para el desarrollo normal de las actividades de

la empresa y lograr mantener un control continuo sobre las actividades comerciales,
financieras y administrativas permitiendo de esta manera crear un medio estructurado
informático que contribuye al sostenimiento de la misma.
Esto lleva a dar soluciones que faciliten la operación de las tareas mediante un software
que pueda satisfacer las necesidades del usuario en menor tiempo, brindando así una
mejor calidad en los servicios.
A si mismo tener un control estricto, para mejorar el rendimiento de la sub-gobernación.

De esta manera hacerlo más eficiente su uso, adaptándolo a las necesidades en el
ámbito de la gestión de la información, con el fin de obtener una satisfacción total por
parte del cliente.
De la misma manera los softwares constituyen un elemento de mucha utilidad en las

empresas, es por ello, que la Sub-Gobernación “Obispo Santisteban” surge la necesidad
de registrar las actividades que se realizara diariamente o sobre las cuales tiene control.
Esto lleva a dar soluciones que faciliten la operación de las tareas mediante el diseño,
construcción e implementación de un software que pueda satisfacer las necesidades de
su registro.
2. ANTECEDENTES
La sub-gobernación “Obispo Santisteban” es una institución pública la cual realizaba el

registro en un principio con máquinas de escribir y lo guardaban en folder
independientes, lo cual al momento de la búsqueda de un documento complicaba la
eficiencia del trabajo de los empleados hacia el ciudadano afectado.
La dotación de carnet y autorización Sanitaria tenía una duración de 10 días de manera

de que los solicitantes de los documentos tenían que esperar mucho para la dotación del
mismo.
Luego se mejoró el registro y admisión de documentos con la aplicación de un software,

el cual facilitaba la realización de los diferentes tramites que brinda la sub- gobernación,
pero el software es una versión muy antigua por lo cual solo acepta el sistema operativo
“XP” y no pueden utilizarlo en versiones más actuales, lo que impide la utilización de más
ordenadores y brindar un mejor servicio hacia la población.
3. DESCRIPCIÓN DEL PROBLEMA
La Sub Gobernación “Obispo Santisteban” del Municipio de Montero cuenta con los
siguientes problemas:
 Cuenta con un registro de carnet sanitario realizado en Access lo cual no brinda
un control adecuado ya que existe perdida de información por la falta de un gestor
de base de datos.
 El software fue desarrollado únicamente para el sistema operativo “XP” que ya es
un S.O obsoleto y no existe compatibilidad con las nuevas versiones como ser
Windows 7,10.
 No todo el personal tiene conocimiento sobre el funcionamiento del software por
su complejidad de interfaces.
 No realiza impresiones exactas del documento, necesita seguir una serie de pasos
de ajustes manuales para el centrado del contenido.
4. SITUACIÓN PROBLEMÁTICA
No cuenta con un software que gestione sus actividades y almacenamiento de archivos

del carnet Sanitario de la “Sub Gobernación Obispo Santisteban” de esta manera hacer
que la búsqueda de información sea más rápida y eficiente para un buen control de las
mismas.
5. JUSTIFICACIÓN
5.1. PERSONAL
El presente trabajo está enfocado con el fin de aprobar la materia software II, además de
la aplicación del conocimiento adquirido en el transcurso de los semestres pasados con
el fin de estar preparado para el campo laboral.
5.2. TÉCNICA
El presente proyecto sirve para realizar un control sobre sus registros y almacenamiento
de los mismos, mediante el uso del software el cual guarda registros al momento de
gestionar la información.
Durante el transcurso del desarrollo del sistema de información se aplicará toda la

información recolectada y los conocimientos aprendidos en materias pasadas de Base
de Datos I, II, Software I además de la investigación propia.
5.3. TEÓRICA
Esta investigación está basada en todos los conocimientos adquiridos de materias

anteriores útil para la elaboración del software, como también las referencias de libros,
internet que se realiza con el propósito de aportar al conocimiento existente, como
instrumento de evaluación del logro de competencias de indagación científica en la
formación educativa, cuyos resultados de este software podrá sistematizarse en una
propuesta para ser incorporado en muchos más municipios.
6. OBJETIVOS
6.1. Objetivo General
Desarrollar un software para gestionar la dotación de carnet sanitario y certificación de

sanidad implementando un Sistema Gestor de Dase de Datos, lenguaje de programación
y complementos adicionales en la Sub-Gobernación Obispo Santisteban de Montero.
6.2. Objetivos Específicos
 Recaudar información necesaria de la Sub Gobernación acerca del proceso de

gestión y registros para determinar el proceso de elaboración del software.
 Analizar toda la información recaudada a través de entrevistas para ver los
problemas y necesidades que tiene la Sub Gobernación “Montero.
 Diseñar los artefactos del sistema a través de diagramas UML en base a la
metodología utilizada para un buen desarrollo del sistema.
 Implementar las funciones del sistema a través de un lenguaje de programación y un
gestor de base de Datos para almacenar la información y generar una plataforma
interactiva con el cliente.
 Realizar pruebas a través de consultas para verificar la funcionalidad de la Base de
datos
7. METODOLOGÍA
El presente trabajo se basa en la metodología de Programación Extrema (XP), para el
desarrollo del producto se utiliza Framework SCRUM y el Lenguaje Unificado Modelado
(U.M.L.). Para la realización de cada tarea se realizará según el proceso que realiza la
demología XP de tal manera cada uno de las tareas (Historia de Usuario), pasará por un
proceso de:
 Análisis. Se realizará un análisis de cada tarea de manera de que sea más fácil
la detección de posibles fallas o complicaciones.
 Diseño. Se elaborará un diseño de cómo tiene que ser el resultado final, de
manera que este diseño ayude a los desarrolladores de cuál es el camino que
deben seguir para elaborar el producto.
 Código. Las transformaciones de los pasos anteriores ayudaran a los
desarrolladores a la realización del código en la herramienta correspondiente,
para cada una de las tareas.
 Pruebas. Luego de la aplicación de los anteriores pasos se procede a la
evaluación de la tarea realizada de manera que se pueda determinar si cumple
todas las especificaciones requeridas por el cliente.
7.1. Que es eXtreme Programming

Es una metodología ágil que se centra en potencial relaciones entre personales como
clave para el éxito en desarrollo de software. Durante el proceso se promueve el trabajo
en equipo, preocupándose por el aprendizaje de los desarrolladores, y se proporciona
un buen clima de trabajo. XP se basa en una retroalimentación continua entre el cliente
y el equipo de desarrollo, además requiere de comunicación fluida entre todos los
participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios. Xp es especialmente adecuada para proyectos con requisitos imprecisos y que
están sujetos a cambios.
7.2. Objetivos que persigue XP
Los objetivos de Xp son la satisfacción del cliente. Esta metodología trata de dar al cliente
el software que el necesita y cuando lo necesita. Por tanto, debemos responder muy
rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de
la programación.
7.3. Roles dentro de XP
- Programador. - Debe describir las pruebas unitarias y producir el código del sistema.
Debe existir la comunicación y coordinación adecuada entre todos los
programadores y otros miembros del equipo.
- Cliente. - Se encarga de describir las historias de usuario y las pruebas funcionales
a fin de validar su información. Además, se encarga de asignar la prioridad a las
historias de usuario y debe decidir cuales se implementan en cada iteración
centrándose en aportar mayor valor al negocio tanto al desarrollo del sistema.
- Encargado de pruebas. – es el encargado de pruebas y apoya al cliente a escribir
las pruebas funcionales que le corresponden. También ejecuta las pruebas de forma
regular, difunde los resultados al equipo y es el responsable de las herramientas de
soporte para pruebas.
- Encargado de seguimiento. - Proporciona la realimentación al equipo durante el
proceso de XP. Su responsabilidad principal es de verificar el grado de acierto entre
las estimaciones que se han realizado y el tiempo real que se ha dedicado, comunica
los resultados para mejorar estimaciones a futuro. También realiza el seguimiento
del progreso que se realizara en cada iteración y evalúa si los objetivos son
alcanzables con las restricciones de tiempo establecidas y los recursos presentes.
Determina cuando es necesario realizar algún cambio para lograr los objetivos de
cada iteración.
8. ALCANCE
El estudio se realizará en la Sub Gobernación Obispo Santisteban del Municipio de

Montero, específicamente enfocando hacia el sistema de Registros, controlando la
información general de cada reporte existente con el fin de obtener todos los datos
necesarios de una manera organizada, confiable y correcta.
Los resultados o productos esperados tras la realización del proyecto son los siguientes:
 Aplicación del Software: compatible para todos los equipos de escritorio en la

versión Windows.
 Documento del análisis del sistema: este documento contendrá todas las
historias de usuario obtenidas tras el estudio del caso y toda su evolución a lo
largo del desarrollo del sistema.
 Documento de Diseño del sistema completo: este documento contendrá el
diseño de datos, de arquitectura, de componentes y de las interfaces graficas de
usuario.
 Manual de uso del software: permitirá al usuario una mejor comprensión del
manejo del software.
Este sistema está limitado para el uso exclusivo de la Sub Gobernación lo cual permitirá
determinar reportes y un control de sus registros adecuados.
Por otra parte, el sistema no cumplirá con lo siguiente:
 El sistema no realizará un monitoreo de las actividades del personal de la alcaldía
El sistema no generará tablas de creación.
SISTEMA DE GESTION PARA LA DOTACION

DE CARNET Y AUTORIZACION SANITARIA
“JARDINES DEL NORTE”
Modulo de Modulo de Modulo de

Registros Reporte Venta Credito
Reg. de Clientes Contrato

Plan de
Pago
Reg. Empleados Descuento Pagos
Registro de
Mausoleos Cuotas
Registro de Sectores
9. CRONOGRAMA
CRONOGRAMA DE ACTIVIDADES
25 de agosto Se asignó el Sistema en el cual se trabajaría de forma grupal
Se fue al lugar para determinar la entrevista correspondiente con
05 de septiembre el encargado de la Sub-Gobernación y se recaudó información
para la implementación del sistema.
Se analizó la información recaudada especialmente en el ámbito
06 de noviembre
de desarrollo de “la Sub Gobernación”
Elaboración del perfil del sistema de gestión con los requisitos
08 de septiembre
adquiridos.
15 de septiembre Presentación del perfil de proyecto y correcciones
Se realizó el diseño conceptual de la Base de Datos e interfaces
20 de septiembre
del sistema estructurado.
Presentación del diagrama de clases con el ing. Encargado de la
22 de septiembre
materia para verificar las fallas
Implementación de la Base de Datos a un Gestor de Base de
06 de octubre
Datos SQL Server
Elaboración de la metodología en 3 capas(Capa Negocio, Capa
11 de octubre
Datos y Capa Presentación)
Presentación avance del sistema para verificar fallas por parte del
20 de octubre
ing. Encargado de la materia.
trabajo grupal para la determinación del desarrollo con las
07 de noviembre
correcciones respectivas.
Muestra y Prueba del sistema hacia el encargado de la sub
15 de noviembre
gobernación para obtener mejoras específicas.
Se realizó pruebas al software y presentación al Ing. encargado de
17 de noviembre
la materia.
21 de noviembre Correcciones de las diferentes observaciones
Presentación final del Sistema de Gestión Sanitaria Sub
24 de noviembre
Gobernación..
CAPITULO II
ANALISIS
10. ANALISIS
10.1. Requerimientos Funcionales (Product Backlog)
Identificación del documento

código: sd-wed-02
titulo: Sistema de registro de carnet sanitario y almacenamiento de
archivos Sub Gobernación - Montero
Fecha de 08 de septiembre del 2018
Creación:
Elaborado por: Nery Lázaro Toconás Acevedo
Oscar Emir Velarde Figueredo
Roly Ponce Vargas
Revisión del Documento
Revisado por: Ing. Edwin Magno Calizaya
En fecha. 15/09/2018
22/09/2017
06/10/2018
20/10/2018
27/10/2018
13/11/2018
Aprobación del Documento
Aprobado por: Ing. Edwin Magno Calizaya
En Fecha: 22/09/2018
11
Control de Cambio
Versión Causa el Cambio Responsable Fecha
V01 Requerimiento Nery Lázaro Toconás 05/09/2018
Inicial Acevedo
Oscar Emir Velarde
Figueredo
Elaboración del Oscar Emir Velarde 08/09/2018
Perfil Figueredo 12/09/2018
V02 Base de Datos Nery Lázaro Toconás 20/09/2018
Acevedo 22/09/2018
Desarrollo 3 capas Roly Ponce Vargas 11/10/2018
Eligio Eloy Vaca Flores 13/10/2018
15/10/2018
V03 Requerimiento Nery Lázaro Toconás 20/10/2018
Final Acevedo 26/10/2018
Oscar Emir Velarde 07/11/2018
Figueredo 15/11/2018
Kevin Montaño Zurita 21/11/2018
10.1.1. Tabla Product blacklog

Fuente (Elaboración Propia)
Nombre del Como probarlo Departamento

Nro.
Requerimiento (Atributos de calidad) Sección
Gestionar Permite registrar, eliminar,

HU1 Administración
Beneficiario modificar y buscar los datos del
12
beneficiario que solicitan un
servicio
Permite registrar, modificar y

Gestionar eliminar la categoría especificada
HU2 Administración
Categoría de acuerdo al arancel de salud
ambiental.
Permite registrar la empresa de

Gestionar acuerdo a su razón social el cual
HU3 Administración
Empresa determina el sector. De igual forma
se modifica y elimina.
Genera un detalle del beneficiario

Gestionar
HU4 que fue registrado de acuerdo a Administración
Recibo
sus solicitudes de servicio.
Se registra los datos del

beneficiario indicando el examen
Gestionar
HU5 de laboratorio y médico, registrado Administración
Exámenes
las diversas características como
datos personales, etc.
Asigna la validación de
Gestionar autorización mediante el registro de
HU6 Administración
Carnet carnet con los datos personales del
beneficiario.
Gestionar Permite registrar, eliminar,

Autorización modificar la autorización que
HU7 Administración
sanitaria de establece el código de salud,
funcionamiento reglamento complementario con la
13
autorización sanitaria de
funcionamiento.
Registra los datos personales, que

Gestionar
es almacenado en el sistema. El
HU8 Trabadora Administración
permite de la misma manera
Sexual
eliminar y modificar
El administrador registra el usuario

Gestionar
HU9 proporcionando código de acceso Administración
Usuarios
para su posterior uso de la misma.
10.2. Requerimientos no Funcionales

10.2.1. Tiempo de Aprendizaje
La capacitación del personal, en el manejo de software y mantenimiento del sistema
deberá considerar un tiempo considerable por lo menos 10 horas laborales de
capacitación (Como mínimo 1 hora por día), hasta que los alineamientos de manejo
del sistema y otros hayan sido debidamente adquiridos por el personal previamente
asignado.
10.2.2. Identificación del usuario propio de la aplicación

El usuario ingresará al sistema con su cuenta y contraseña, que será validadas por
el sistema, los permisos según el rol que tiene asignado.
Contraseña del usuario: Para el registro de la contraseña de usuario deberán
asegurarse que: La longitud de la contraseña debe ser de 6 caracteres mínimos y
como máximo 15, además de cambiarla gradualmente por seguridad.
10.2.3. Confiabilidad
Tiempo de disponibilidad del sistema
La aplicación puede estar disponible según indicaciones del administrador para los
empleados de la empresa.
14
Debido a que cualquier usuario con una cuenta y contraseña (Registrados en el
servidor) puede tener acceso al sistema, es necesario hacer notar que, para cumplir
con la manera de disponibilidad del sistema, se deberá analizar cierto parámetro
como: Rendimiento de servidor, calidad del enlace y calidad de conexión de red
local para el usuario final.
Tiempo fuera de servicio
El tiempo máximo de fuera de operaciones depende del funcionamiento del servidor

como ser: Hardware del ordenador, Base de Datos y la infraestructura de la red. El
mismo debe ser: Fallas comunes 10 minutos (Aprox.) o Fallas no comunes 1 hora
(Aprox.)
10.2.4. Performance
Acceso de los usuarios al sistema:
Los usuarios pueden acceder a los datos en tiempo real.
Tiempo de Respuesta
El tiempo de respuesta al acceso del usuario debe ir de 7 segundos, la primera vez
que ingresa al sistema, después menos de 5 segundos.
El tiempo de respuesta al acceso del usuario debe ir de 7 segundos, la primera vez
que ingresa al sistema, después menos de 5 segundos.
Calidad de atención al usuario

El sistema debe poder atender normalmente 2 o más usuarios al mismo tiempo.
10.2.5. Restricciones de Diseño
Estándares de diseño
Versión en Framework 4.0
Estándares de Arquitectura
 Se debe usar para el desarrollo de software la arquitectura en 3 capas.

 Para la infraestructura de red, se debe implementar la arquitectura de
Cliente/Servidor.
15
Motor de Base de Datos
Se utiliza el motor de Base de Datos SQL Server 2014 (Estándar edición) de

Microsoft.
Cliente de Escritorio
La aplicación deberá ser accesible utilizando un ordenador Dual Core, Core i3 o
superior con sistema Operativo Windows 7,8,10 o superior (Exclusivamente de
Microsoft)
Servidor de Datos
El servidor será Windows Server 2016 (Standar Edition) de Microsoft.
Lenguaje de Programación
La aplicación debe desarrollarse en Visual Studio 2015, utilizando Windows Form
de Visual C# y derivados de SQL con T/SQL para el motor de base de Datos SQL
server 2014.
10.2.6. Interfaces
Interfaz de Usuario
No debe existir presencia de imágenes distorsionadas o difíciles de entender. La
presentación de mensaje de error o de infracción al usuario deberá ser lo más
específico posible y comunicarse con el administrador del sistema.
Interfaz de Hardware
Los usuarios necesitan un dispositivo que mediante la interfaz de red (Dominio de

Control Local, Active directory, etc.) les permita acceder al sistema, vía red Local.
Este dispositivo puede estar basado en cualquier arquitectura, pero deberá disponer
al menos de un procesador con capacidad suficiente para ejecutar el sistema
contable.
16
Interfaz de Comunicaciones
Existe una conexión entre los usuarios y el servidor donde está alojado la base de
Datos:
 Los usuarios cliente se conectarán al sistema mediante red Local. Esta

conexión se realizará desde su oficina en la misma infraestructura de la Sub
Gobernación.
 Para el entorno de red: La aplicación deberá tener la capacidad de funcionar

en un entorno de red LAN.
Interfaz de Software
Cualquier usuario que desee conectarse al sistema de escritorio necesitara de un

sistema operativo Windows 7 o superior para poder acceder a ella.
Por otra parte, el servidor de la Base de Datos (SQL server 2014 Standar Edition)
se implementará bajo el sistema Operativo Windows Server 2016.
11. DISEÑO DEL SOFTWARE
11.1. Especificación de Requerimientos de Software

A diferencia de la metodología tradicional, XP utiliza las historias de usuario para la
especificación de requerimiento, permitiendo disminución. XP presenta 4 valores
que seguirlos y utilizarlos facilita la especificación de requerimientos:
 La comunicación: permite que el cliente y el programador lleguen a un
acuerdo en la especialización de requerimientos evitando los malos
entendidos.
 La sencillez: es lo que diferencia a XP con las demás metodologías

tradicionales las cuales utilizan estándares para la especificación de
requerimientos que hacen del sistema muy complejo. La sencillez evita la
documentación extensa centrándose en lo básico, en lo que se utiliza en este
momento y no en lo que se podría utilizar.
17
 La realimentación: permite que la especificación de requerimientos se
comprenda mejor con el pasar del tiempo, permitiendo que los usuarios
aprendan a escribir mejor las historias.
 Las historias de usuario: es una pequeña descripción del programa con el

fin de estimar tiempo y costo, el programador pregunta al cliente,
aumentando el detalle de cada historia.
11.2. Historias de Usuario

Las historias de usuario permiten obtener los requerimientos del sistema a
implementar los primeros requerimientos por parte del usuario, es importante no
detallar las historias del usuario porque son utilizadas solo para dar una pequeña
visión de lo que requiere obtener. Cuando se inicie la fase de desarrollo el
investigador con la ayuda del usuario detallase las historias de usuario.
18
11.2.1. Historia de usuario para Gestionar Categoría
Nro. de Historia Titulo

01 Gestionar Categoría
Descripción
Permite el registro de datos de lugar donde trabaja el cliente.
Estimación(HP) Prioridad Dependiente de
3 Media -------------------
Criterios de Aceptación
 El código será introducido manualmente por los trabajadores.
 El beneficiario puede solicitar un servicio de carnet o de beneficiario.
 No se puede eliminar los rubros existentes.
 Para realizar cualquier operación de nuevo, modificar, guardar, busca,
elimina, cancela cada uno tiene un respectivo botón.
Responsable Nery Lázaro Toconás Acevedo
Roly Ponce Vargas
Emir Velarde Figueredo
Adjunto
19
11.2.2. Historia de usuario para Gestionar Empresa

02 Gestionar Empresa
Descripción
Permite el registro de datos de la empresa y la dirección.
3 Media -------------------
 El código será introducido automáticamente.
 El beneficiario debe brindar los datos de la empresa requeridos.
Roly Ponce Vargas
Adjunto
20
11.2.3. Historia de usuario para Gestionar Beneficiario

03 Gestionar Empresa
Descripción
Permite el registro de datos del beneficiario, lugar de trabajo con su respectiva
foto del beneficiario.
3 Media -------------------
 La empresa será generada automáticamente al entrar al botón buscar.
 El beneficiario debe brindar todos sus datos personales.
 Genera una captura de foto del beneficiario.
Roly Ponce Vargas
Adjunto
21
11.2.4. Historia de usuario para Gestionar Recibo

04 Gestionar Recibo
Descripción
Permite darnos el dato de la fecha y datos de pago.
4 Media -------------------
 El código, y nombre de la persona serán generados automáticamente.
 El recibo brindara un detalle del pago de carnet o de autorización.
Roly Ponce Vargas
Adjunto
22
11.2.5. Historia de usuario para Gestionar Exámenes

05 Gestionar Exámenes
Descripción
Permite el registro dos todos los exámenes médicos y de laboratorio.
5 Alta -------------------
 El beneficiario se genera automáticamente.
 En examen laboratorio y examen médico se necesita que el empleado
introduzca los datos.
Roly Ponce Vargas
Adjunto
23
11.2.6. Historia de usuario para Gestionar Carnet

06 Gestionar Carnet
Descripción
Permite el registro de datos con una impresión.
5 Alta -------------------
 Los exámenes se generan automáticamente.
 Genera una impresión del carnet del beneficiario.
 Para realizar cualquier operación de nuevo, modificar, guara, elimina,
cancela cada uno tiene un respectivo botón.
Roly Ponce Vargas
Adjunto
24
11.2.7. Historia de usuario para Gestionar Autorización

07 Gestionar Autorización
Descripción
Permite la impresión de la autorización con el registro de datos.
4 Alta -------------------
 La empresa y la categoría se genera automáticamente.
 Registro de datos de número de autorización.
Roly Ponce Vargas
Adjunto
25
11.2.8. Historia de usuario para Gestionar Trabajador

08 Gestionar Trabajadora
Descripción
Permite el registro de datos de las trabajadoras sexuales.
3 Media -------------------
 Registro de los datos de las trabajadoras.
 Permitirá una captura de foto de la trabajadora sexual.
Roly Ponce Vargas
Adjunto
26
11.2.9. Historia de usuario para Gestionar Usuario

09 Gestionar Usuario
Descripción
Permite el registro de una contraseña y nombre del usuario si es administrador o
empleado.
3 Media -------------------
 Debe seleccionar un usuario administrador o empleado.
 Tener una contraseña propia.
Roly Ponce Vargas
Adjunto
27
CAPITULO III
DISEÑO
12. ELABORACION
12.1. Arquitectura de la Solución para el modelo de Capas
29
12.2. DESCRIPCIÓN DE LA ARQUITECTURA
A continuación, se hace una breve descripción de los distintos componentes que

forman parte de la solución en general:
12.2.1. Biblioteca de Datos

Permite hacer la conexión al motor de base de datos de SQL Server, dentro de esta
biblioteca se encuentra la clase llamada Conexion.cs en esta clase están definidos
los métodos principales para las operaciones al momento de manipular datos en la
base de datos, estos métodos son: conectar, desconectar, consultar, etc.
12.2.2. Biblioteca de Negocio

Se encuentra cada una de las clases que componen el cuerpo del sistema, estas
clases se caracterizan por tener la definición de atributos, propiedades y métodos
que permiten dar forma a los objetos del sistema para cada uno de los
requerimientos de negocios del sistema.
12.2.3. Biblioteca de Presentación

Dentro de la aplicación se encuentran todos los elementos de diseño para el
sistema, como ser Formulario Principal, los formularios de los clientes, empleados,
proveedores, productos, registro de ventas, registro de compras, almacén, ajustes,
etc. Que son la base de diseño para poder invocar a los distintos formularios que
forman parte del sistema.
30
12.3. ARQUITECTURA DE LA SOLUCIÓN BASADA EN LA TECNOLOGIA .NET
La programación por capas es un estilo de programación en la que le objetivo
primordial es la separación de la lógica de negocios de la lógica de diseño, un
ejemplo básico de esto es separar la capa de datos de la capa presentación al
usuario.
La ventaja principal de este estilo, es que en caso de algún cambio sólo se ataca al
nivel requerido sin tener que revisar entre código mezclado. Además, permite
distribuir el trabajo de creación de una aplicación por capas, de este modo, cada
grupo de trabajo está totalmente abstraído del resto de niveles.
En el diseño de sistemas informáticos actual se suele usar la arquitectura

Programación por capas.
En dicha arquitectura a cada capa se le confía una misión simple, lo que permite el
diseño de arquitecturas escalable (que pueden ampliarse con facilidad en caso de
que las necesidades aumenten).
12.4. DESCRIPCIÓN DE CAPAS
12.4.1. Capa Presentación

Es lo que ve el usuario, presenta el sistema al usuario, le comunica la información
y captura la información del usuario dando un mínimo de proceso (realiza un filtrado
31
previo para comprobar que no hay errores de formato). Esta capa se comunica
únicamente con la capa de negocio.
12.4.2. Capa Negocio

Es donde residen los programas que se ejecutan, recibiendo las peticiones del
usuario y enviando las respuestas tras el proceso. Se denomina capa de negocio (e
incluso de lógica del negocio) pues aquí donde se establecen todas las reglas que
deben cumplirse. Esta capa se comunica con la capa presentación para recibir las
solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor
de base de datos para almacenar o recuperar los datos en él.
12.4.3. Capa Dato

Es donde residen los datos. Está formada por uno o más gestores de base de datos
que realiza todo el almacenamiento de datos y reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.
12.5. ADO.NET
Los proveedores de acceso a datos ADO.NET (conocidos como “Managed Data
Providers”), representan conjuntos específicos de clases que permiten conectarse
e interactuar con una base de datos, cada uno utilizando un protocolo particular.
ADO.NET provee una arquitectura extensible, posibilitando que terceras partes

creen sus propios proveedores de acceso nativo para aplicaciones .NET.
32
12.6. Diseño Conceptual de la Base De Datos
class Modelo de dominio
Empresa
- Id_Empresa Examen_Lab
+ Razon_Social
- Id_Examen: int
+ Dirección
+ Homograma: varchar
+ Vacunas: varchar
1..* 1..*
Empresa_Beneficiario
1
+ Cargo
1..*
1
Beneficiario
Autorizacion
- CI: int 1 Carnet
- N_Certificado + Nombre: varchar
- Cod_Carnet
+ Fecha_ini + Ap_Paterno: varchar
1..* 1 + 1...* + Fecha_Inicio
+ Fecha_fin Ap_Materno: varchar 1 + Fecha_Vencimiento
+ fecha + fecha_nac: int
+ Ocupacion: varchar
+ Domicilio: varchar 1 1
1..*
1..* Examen_Medico
1
- Id_Examen_med
categoria Rubro
+ Piel_Mucuosa
- Id_categoria - Id_rubro + Sist_Cardiopulmonar
1..* + Nombre + Ant_Pat/QX
+ Nombre
+ Precio + G_Urinario/Ginocologico
+ Observacion
33
12.7. Diseño Lógico de la Base de Datos
12.8. Diseño Físico de la base de
34
CAPITULO IV
IMPLEMENTACION
13. IMPLEMENTACION
13.1. APLICACIÓN DE ESCRITORIO
13.1.1. Implementación de cliente: Clase Cliente
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Drawing;
using System.Data;
using Capa_de_Datos;
namespace Capa_de_Negocio
{
public class CNCliente : Conexion
{
private string id;
private string nombre;
private string paterno;
private string materno;
private string telefono;
static void Main()

{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
}
public CNCliente()
{
id = nombre = paterno = materno = telefono = string.Empty;//=== "

"es igual a vacio
}
public string ID
{
get { return this.id; }
set { this.id = value; }
}
public string Nombre

{
get { return this.nombre; }
set { this.nombre = value; }
}
public string Paterno
{
get { return this.paterno; }
set { this.paterno = value; }
}
public string Materno
36
{
get { return this.materno; }
set { this.materno = value; }
}
public string Telefono

{
get { return this.telefono; }
set { this.telefono = value; }
}
public void Insertar()

{
try
{
IniciarSP("insertar_cliente");
AddParametro("@nombre", nombre);
AddParametro("@paterno", paterno);
AddParametro("@materno", materno);
AddParametro("@telefono", telefono);
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al insertar cliente:" + e.ToString());
}
}
public void modificar()
{
try
{
IniciarSP("modificar_cliente");
AddParametro("@id_cliente", id);
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al modificar cliente:" + e.ToString());
}
}
public void eliminar()

{
try
{
IniciarSP("eliminar_cliente");
AddParametro("@id_cliente", id);
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al eliminar cliente:" + e.ToString());
}
37
}
public DataSet buscar()

{
string s;
s = "select * from cliente";
DataSet ds = new DataSet();
ejecutarSQL(s, "tc", ds);
return ds;
}
public DataSet buscarPorID(string criterio)

{
string s;
s = " buscar_cliente " + criterio;
return ds;
}
}
}
1.1.1. Implementación de Empleado: Clase Empleado
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNEmpleado : Conexion
{
private int id_empleado;
private string paterno;
private string materno;
private string telefono;
public CNEmpleado()
{
id_empleado = 0;
nombre = paterno = materno = telefono = string.Empty;
}
public int Ci_empleado
{
get { return this.id_empleado; }
set { this.id_empleado = value; }
}
{
38
}
public string Paterno
{
get { return this.paterno; }
set { this.paterno = value; }
}
public string Materno

{
get { return this.materno; }
set { this.materno = value; }
}
public string Telefono

{
get { return this.telefono; }
set { this.telefono = value; }
}
public void InsertarEmple()

{
try
{
IniciarSP("insertar_empleado");
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al insertar empleado:" + e.ToString());
}
}
public void Modificar()

{
try
{
IniciarSP("modificar_empleado");
AddParametro("@id_empleado", id_empleado.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al modificar el empleado:" + e.ToString());
}
}

{
try
39
{
IniciarSP("eliminar_empleado");
AddParametro("@id_empleado", id_empleado.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al eliminar el empleado:" + e.ToString());
}
}
{
string s;
s = "select *from empleado";
return ds;
}
public DataSet BuscarPorCi(string criterio)

{
string s;
s = "buscar_empleado " + criterio;
return ds;
}
}
}
1.1.2. Implementación de Sectores: Clase Sectores
using System;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data;
{
public class CNSector : Conexion
{
private string id_sector;
private string stock;
private float precio;
public CNSector()
{
nombre = id_sector = string.Empty;//=== " "es igual a vacio
stock = string.Empty;
precio = 0;
40
}
public string Id_sector
{
get { return this.id_sector; }
set { this.id_sector = value; }
}

{
}
public string Stock

{
get { return this.stock; }
set { this.stock = value; }
}
public float Precio
{
get { return this.precio; }
set { this.precio = value; }
}

{
try
{
IniciarSP("insertar_Sector");
AddParametro("@nombre",nombre);
AddParametro("@stock", stock.ToString());
AddParametro("@precio", precio.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al insertar sector:" + e.ToString());
}
}
{
try
{
IniciarSP("modificar_sector");
AddParametro("@id_sector", id_sector);
AddParametro("@stock", stock.ToString());
AddParametro("@precio", precio.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al Modificar sector:" + e.ToString());
}
}
41
{
try
{
IniciarSP("eliminar_sector");
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al eliminar sector:" + e.ToString());
}
}

{
string s;
s = "select * from Sector";
return ds;
}

{
string s;
s = "buscar_sector " + criterio;
return ds;
}
}
}
1.1.3. Implementación de Mausoleo: Clase Mausoleo
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNMausoleo : Conexion
{
private int id_mausoleo;
private string estado;
private int id_sector;
public CNMausoleo()
{
42
id_mausoleo = 0;
nombre = estado = string.Empty;
id_sector = 0;
}
public int Id_Mausoleo

{
get { return this.id_mausoleo; }
set { this.id_mausoleo = value; }
}
public string Estado

{
get { return this.estado; }
set { this.estado=value; }
}
public string Nombre_Sepulcro

{
}
public int Id_Sector

{
get { return this.id_sector; }
set { this.id_sector = value; }
}
public void insertar()

{
try
{
IniciarSP("insertar_mausoleo");
AddParametro("@estado", estado);
AddParametro("@id_sector", id_sector.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al INSERTAR el SEPULCRO:" + e.ToString());
}
}
{
try
{
IniciarSP("modificar_mausoleo");
AddParametro("@id_m", id_mausoleo.ToString());
AddParametro("@estado", estado);
AddParametro("@id_sector", id_sector.ToString());
ejecutarSP();
}
catch (Exception e)
{
43
MessageBox.Show("Error al MODIFICAR el SEPULCRO:" + e.ToString());
}
}

{
try
{
IniciarSP("eliminar_mausoleo");
AddParametro("@id_m", id_mausoleo.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al ELIMINAR el Sepulcro:" + e.ToString());
}
}
{
string s;
s = "select * from mausoleo";
return ds;
}
{
string s;
s = "buscar_mausoleo " + criterio ;
return ds;
}
}
}
1.1.4. Implementación de difunto: Clase Difunto
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNDifunto : Conexion
{
private int id_mausoleo;
private int id_difunto;
private string nombre_difunto;
private DateTime fecha_nacimiento;
44
private DateTime fecha_fallecimiento;
public CNDifunto()
{
id_difunto = 0;
id_mausoleo = 0;
nombre_difunto = string.Empty;
fecha_nacimiento = DateTime.Today.Date;
fecha_fallecimiento = DateTime.Today.Date;
}
public int Id_Mausoleo

{
}
public int Id_difunto

{
get { return this.id_difunto; }
set { this.id_difunto = value; }
}
public string Nombre_difunto

{
get { return this.nombre_difunto; }
set { this.nombre_difunto = value; }
}
public DateTime Fecha_Nacimiento

{
get { return this.fecha_nacimiento; }
set { this.fecha_nacimiento = value; }
}
public DateTime Fecha_Fallecimiento

{
get { return this.fecha_fallecimiento; }
set { this.fecha_fallecimiento = value; }
}

{
try
{
IniciarSP("insertar_difunto");
AddParametro("nombre", nombre_difunto);
AddParametro("fecha_nac", fecha_nacimiento.ToShortDateString());
AddParametro("fecha_fal", fecha_fallecimiento.ToShortDateString());
AddParametro("id_mau", id_mausoleo.ToString());
ejecutarSP();
}catch (Exception ex)
{ MessageBox.Show("Error al INSERTAR el DIFUNTO...." + ex.ToString()); }
}

{
try
45
{
IniciarSP("modificar_difunto");
AddParametro("id_dif", id_difunto.ToString());
AddParametro("nombre", nombre_difunto);
AddParametro("fecha_nac", fecha_nacimiento.ToShortDateString());
AddParametro("fecha_fal", fecha_fallecimiento.ToShortDateString());
AddParametro("id_mau", id_mausoleo.ToString());
ejecutarSP();
}
catch (Exception ex)
{ MessageBox.Show("Error al MODIFICAR el DIFUNTO......" +
ex.ToString()); }
}
public void Eliminar()

{
try
{
IniciarSP("eliminar_difunto");
AddParametro("id_dif", id_difunto.ToString());
ejecutarSP();
}
{ MessageBox.Show("Error al ELIMINAR el DIFUNTO......" + ex.ToString());
}
}

{
string s;
s = "select * from difunto";
return ds;
}

{
string s;
s = "buscar_difunto " + criterio ;
return ds;
}
}
}
1.1.5. Implementación de Servicio Venta: Clase venta
using System;
using System.Linq;
using System.Text;
using System.Data;
46
{
public class CNVentas : Conexion
{
private int id_venta;
private DateTime fecha_venta;
private int ci_cliente;
private int ci_empleado;
private string tipo;
public CNVentas()
{
id_venta = 0;
fecha_venta = DateTime.Today.Date;
ci_cliente = 0;
ci_empleado = 0;
tipo = string.Empty;
}
public int Id_Venta
{
get { return this.id_venta; }
set { this.id_venta = value; }
}
public DateTime Fecha_venta
{
get { return this.fecha_venta; }
set { this.fecha_venta = value; }
}
public int Ci_Cliente

{
get { return this.ci_cliente; }
set { this.ci_cliente = value; }
}
public int Ci_Empleado
{
get { return this.ci_empleado; }
set { this.ci_empleado = value; }
}
public string Tipo

{
get { return this.tipo; }
set { this.tipo = value; }
}
public void InsertarVenta()

{
try
{
IniciarSP("insertar_ventas");
AddParametro("@fecha", fecha_venta.ToShortDateString());
AddParametro("@tipo", tipo);
AddParametro("@id_emp", ci_cliente.ToString());
AddParametro("@id_cli", ci_empleado.ToString());
ejecutarSP();
47
}
catch (Exception e)
{
MessageBox.Show("Error al INSERTAR una venta:" + e.ToString());
}
}

{
try
{
IniciarSP("modificar_ventas");
AddParametro("@id_v", id_venta.ToString());
AddParametro("@fecha", fecha_venta.ToShortDateString());
AddParametro("@tipo", tipo);
AddParametro("@id_e", ci_empleado.ToString());
AddParametro("@id_c", ci_cliente.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al MODIFICAR una venta:" + e.ToString());
}
}

{
try
{
IniciarSP("eliminar_ventas");
AddParametro("@id_V", id_venta.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al eliminar venta:" + e.ToString());
}
}

{
string s;
s = "select *from servicio_venta";
return ds;

{
string s;
s = "buscar_ventas " + criterio ;
return ds;
48
}
}
}
1.1.6. Implementación de Serv. Venta al Contado: Clase Contado
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNContado : Conexion
{
private string id_servicio;
private string descuento;
private string monto;
private string id_mausoleo;
public CNContado()
{
id_servicio = descuento = monto = id_mausoleo = string.Empty;
}
public string IDSer

{
get { return this.id_servicio; }
set { this.id_servicio = value; }
}
public string Descuento

{
get { return this.descuento; }
set { this.descuento = value; }
}
public string Monto

{
get { return this.monto; }
set { this.monto = value; }
}
public string IDMau

{
}
49
{
try
{
IniciarSP("insertar_contado");
AddParametro("@id_servicio", id_servicio);
AddParametro("@descuento", descuento);
AddParametro("@monto", monto);
AddParametro("@id_mau", id_mausoleo);
ejecutarSP();
}
catch (Exception e)
{ MessageBox.Show("Error al insertar contado:" + e.ToString()); }
}
public DataSet BuscarProID(string criterio)

{
string s;
s = ("mostrar_contado " + criterio);
ejecutarSQL(s,"ts",ds);
return ds;
}

{
string s;
s = "select * from serv_contado";
return ds;
}
public void modificar(string criterio)

{
try
{
IniciarSP("modificar_contado");
AddParametro("@descuento", descuento);
AddParametro("@id_mau", id_mausoleo);
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("error al modificar..."+e.ToString());
}
}

{
try
{
IniciarSP("eliminar_contado");
ejecutarSP();
}
catch (Exception e)
50
{
MessageBox.Show("error al modificar"+e.ToString());
}
}
}
1.1.7. Implementación de Serv. Venta al Crédito: Clase Crédito
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNCredito : Conexion
{
string id_ser;
string monto;
string interes;
string id_mau;
public CNCredito()
{
id_ser = monto = interes = id_mau = string.Empty;
}
public string ID_Servicio

{
get { return this.id_ser; }
set { this.id_ser = value; }
}
public string Monto

{
}
public string Interes

{
get { return this.interes; }
set { this.interes = value; }
}
public string ID_Mausoleo

{
get { return this.id_mau; }
set { this.id_mau = value; }
}
51
{
try
{
IniciarSP("insertar_credito");
AddParametro("@id_ser", id_ser);
AddParametro("@interes", interes);
AddParametro("@id_mau", id_mau);
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al insertar" + e.ToString());
}
}

{
try {
IniciarSP("modificar_credito");
AddParametro("@id_ser", id_ser);
AddParametro("@interes", interes);
AddParametro("@id_mau", id_mau);
ejecutarSP();
}
{
MessageBox.Show("Error al modificar" + ex.ToString());
}
}
public DataSet Buscar()

{
string s;
s = "select *from serv_credito";
return ds;
}
public DataSet BuscarPorId(string criterio)

{
string s;
s = "buscar_credito " +criterio;
ejecutarSQL(s, "ts", ds);
return ds;
}

{
try
{
IniciarSP("eliminar_credito");
AddParametro("id_ser", id_ser);
52
ejecutarSP();
}
{
MessageBox.Show("error al eliminar" + ex.ToString());
}
}
}
}
1.1.8. Implementación de Plan de pago: Clase Plan de Pago
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNPlan_Pago : Conexion
{
private int id_plan;
private DateTime fecha_P;
private string tipo;
private string plazo;
private float monto;
private int id_servicio;
private float cuota_inicial;
public CNPlan_Pago()
{
id_plan = 0;
fecha_P = DateTime.Today.Date;
monto = 0;
cuota_inicial = 0;
id_servicio = 0;
plazo = tipo = string.Empty;
}
public int IdServicio

{
get { return this.id_servicio; }
set { this.id_servicio = value; }
}
public float Cuota_Inicial

{
get { return this.cuota_inicial; }
set { this.cuota_inicial = value; }
}
public string Plazo
53
{
get { return this.plazo; }
set { this.plazo = value; }
}
public float Monto

{
}
public int Id_Plan

{
get { return this.id_plan; }
set { this.id_plan = value; }
}
public DateTime Fecha_PlanP

{
get { return this.fecha_P; }
set { this.fecha_P = value; }
}
public string Tipo

{
get { return this.tipo; }
set { this.tipo = value; }
}

{
try
{
IniciarSP("insertar_plan");
AddParametro("@tipo_plan", tipo);
AddParametro("@id_ser", id_servicio.ToString());
AddParametro("@plazo", plazo);
AddParametro("@monto", monto.ToString());
AddParametro("@cuota_ini", cuota_inicial.ToString());
AddParametro("@fecha", fecha_P.ToShortDateString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al insertar PLAN DE PAGOS:" + e.ToString());
}
}
{
try
{
IniciarSP("modificar_plan");
AddParametro("@tipo_plan", tipo);
AddParametro("@id_ser", id_servicio.ToString());
AddParametro("@plazo", plazo);
AddParametro("@cuota_ini", cuota_inicial.ToString());
AddParametro("@fecha", fecha_P.ToShortDateString());
54
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al modificar PLAN DE PAGOS:" + e.ToString());
}
}

{
try
{
IniciarSP("eliminar_plan");
AddParametro("@id_plan", id_plan.ToString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al eliminar PLAN DE PAGOS:" + e.ToString());
}
}

{
string s;
s = "select * from plan_pago";
return ds;
}
{
string s;
s = "buscar_plan" + criterio ;
return ds;
}
}
}
1.1.9. Implementación de Cuotas: Clase Cuotas
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNCuota : Conexion
55
{
private int id_plan;
private int id_cuota;
private DateTime fecha;
private float monto;
public CNCuota()
{
id_plan = 0;
id_cuota = 0;
fecha = DateTime.Today.Date;
monto = 0;
}
public int Id_plan

{
}
public int Id_cuota
{
get { return this.id_cuota; }
set { this.id_cuota = value; }
}
public DateTime fecha_Cuota
{
get { return this.fecha; }
set { this.fecha = value; }
}
public float Monto
{
}

{
try
{
IniciarSP("insertar_cuota");
AddParametro("@id_cuota", id_cuota.ToString());
AddParametro("@fecha", fecha.ToShortDateString());
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al INSERTAR CUOTA:" + e.ToString());
}
}
{
try
{
IniciarSP("modificar_cuota");
56
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al MODIFICAR Cuota:" + e.ToString());
}
}

{
try
{
IniciarSP("eliminar_cuota");
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("Error al ELIMINAR CUOTA:" + e.ToString());
}
}
public DataSet buscarPorID(string criterio1, string criterio2)
{
string s;
s = " buscar_cuota " + criterio1 + criterio2;
return ds;
}

{
string s;
s = "select *from cuota";
return ds;
}
}
}
1.1.10. Implementación de Pagos: Clase Pagos
using System;
using System.Linq;
using System.Text;
using System.Data;
{
public class CNPagos : Conexion
57
{
private string id_pago;
private DateTime fecha;
private string monto;
private string id_plan;
private string id_cuota;
public CNPagos()
{
id_pago = monto = id_plan = id_cuota = string.Empty;
fecha = DateTime.Today.Date;
}
public string ID_Pago

{
get { return this.id_pago; }
set { this.id_pago = value; }
}
public DateTime Fecha

{
get { return this.fecha; }
set { this.fecha = value; }
}
public string Monto

{
}
public string ID_Plan

{
}
public string ID_Cuota

{
get { return this.id_cuota; }
set { this.id_cuota = value; }
}

{
try
{
IniciarSP("insertar_pagos");
AddParametro("@id_plan", id_plan);
AddParametro("@id_cuota", id_cuota);
ejecutarSP();
}
{
MessageBox.Show("Error al insertar..." + ex.ToString());
}
58
}

{
try
{
IniciarSP(" modificar_pagos");
AddParametro("@id_pago", id_pago);
AddParametro("@id_plan", id_plan);
AddParametro("@id_cuota", id_cuota);
ejecutarSP();
}
{
MessageBox.Show("error al modificar..."+ex.ToString());
}

{
try
{
IniciarSP("eliminar_pago");
AddParametro("@id_pago", id_pago);
ejecutarSP();
}
catch (Exception e)
{
MessageBox.Show("error al eliminar"+e.ToString());
}
public DataSet Buscar()

{
string s;
s = "select *from pagos";
return ds;
}
public DataSet BuscarPorId(string criterio)

{
string s;
s = "buscar_pagos " + criterio;
return ds;
}
}
}
59

Informe Software Ii

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Informe Software Ii

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD AUTÓNOMA GABRIEL RENÉ MORENO

FACULTAD INTEGRAL DEL NORTE

SISTEMA DE GESTION PARA LA

MONTERO - SANTA CRUZ – BOLIVIA

El software a medida es de gran utilidad para el desarrollo normal de las actividades de

A si mismo tener un control estricto, para mejorar el rendimiento de la sub-gobernación.

De la misma manera los softwares constituyen un elemento de mucha utilidad en las

La sub-gobernación “Obispo Santisteban” es una institución pública la cual realizaba el

La dotación de carnet y autorización Sanitaria tenía una duración de 10 días de manera

Luego se mejoró el registro y admisión de documentos con la aplicación de un software,

No cuenta con un software que gestione sus actividades y almacenamiento de archivos

Durante el transcurso del desarrollo del sistema de información se aplicará toda la

Esta investigación está basada en todos los conocimientos adquiridos de materias

Desarrollar un software para gestionar la dotación de carnet sanitario y certificación de

6.2. Objetivos Específicos

 Recaudar información necesaria de la Sub Gobernación acerca del proceso de

7.1. Que es eXtreme Programming

El estudio se realizará en la Sub Gobernación Obispo Santisteban del Municipio de

 Aplicación del Software: compatible para todos los equipos de escritorio en la

SISTEMA DE GESTION PARA LA DOTACION

Modulo de Modulo de Modulo de

Reg. de Clientes Contrato

Reg. Empleados Descuento Pagos

10.1. Requerimientos Funcionales (Product Backlog)

Identificación del documento

Revisión del Documento

Revisado por: Ing. Edwin Magno Calizaya

Aprobación del Documento

Aprobado por: Ing. Edwin Magno Calizaya

10.1.1. Tabla Product blacklog

Nombre del Como probarlo Departamento

Gestionar Permite registrar, eliminar,

Permite registrar, modificar y

Permite registrar la empresa de

Genera un detalle del beneficiario

Se registra los datos del

Gestionar Permite registrar, eliminar,

Registra los datos personales, que

El administrador registra el usuario

10.2. Requerimientos no Funcionales

10.2.2. Identificación del usuario propio de la aplicación

Tiempo fuera de servicio

El tiempo máximo de fuera de operaciones depende del funcionamiento del servidor

Calidad de atención al usuario

10.2.5. Restricciones de Diseño

 Se debe usar para el desarrollo de software la arquitectura en 3 capas.

Se utiliza el motor de Base de Datos SQL Server 2014 (Estándar edición) de

Los usuarios necesitan un dispositivo que mediante la interfaz de red (Dominio de

 Los usuarios cliente se conectarán al sistema mediante red Local. Esta

 Para el entorno de red: La aplicación deberá tener la capacidad de funcionar

Cualquier usuario que desee conectarse al sistema de escritorio necesitara de un

11. DISEÑO DEL SOFTWARE

11.1. Especificación de Requerimientos de Software

 La sencillez: es lo que diferencia a XP con las demás metodologías

 Las historias de usuario: es una pequeña descripción del programa con el

11.2. Historias de Usuario

Nro. de Historia Titulo

Nro. de Historia Titulo

Nro. de Historia Titulo

Nro. de Historia Titulo

Nro. de Historia Titulo

Nro. de Historia Titulo

Nro. de Historia Titulo