PLANEACION

PRUEBAS

CODIFICACION

DISEÑO

Historias de usuarios

Prueba de unidad

Programación en parejas

Diseño simpe de cartas CRC

Integracióncontinua

Prototipos

Prueba deaceptación

1.1.1. PROGRAMACION EXTREMA ( XP)

Programación extrema (XP), es la propuesta agil mas importante en la actualidad.La programación Extrema o eXtreme Programming (XP) es un enfoque de la ingeniería del software formulada por Kent Beck (Padre del XP), autor del primer libro sobre la materia, eXtreme Programming Explained: Embrace Change (1999) Es una metodología para el desarrollo de software y consiste básicamente en ajustarse estrictamente a una serie de reglas que se centran en las necesidades del cliente para lograr un producto de buena calidad en poco tiempoLa Programación Extrema es una metodología agil centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de

software Promueve el trabajo en equipo, preocupándose en todo momento del aprendizaje de los desarrolladores y estableciendo un buen clima de

trabajo.Este tipo de método se basa en una realimentación continua entre el cliente y el equipo de desarrollo con una comunicación fluida entre todos los participantes, también busca simplificar las soluciones implementadas

y coraje para los múltiples cambios.Este tipo de programación es la adecuada para proyectos con requisitos

imprecisos, muy cambiantes y con un riesgo técnico excesivo.

1.1.2. FASES DE LA METODOLOGIA XP.La metodología XP consta de cuatro etapas:

1.1.2.1. PLANIFICACION.XP plantea la planificación como un permanente dialogo entre las partes la empresarial (deseable) y la técnica (posible). Las personas del negocio necesitan determinar:Ámbito: ¿Qué es lo que el software debe de resolver para que este genere valor ?Prioridad: ¿ Qué debe ser hecho en primer lugar ?Composición de versiones: ¿ Cuánto es necesario hacer para saber si el negocio va mejor con software que sin el ?. En cuanto el software aporte algo al negocio debemos de tener lista las primeras versionesFechas de versiones: ¿ Cuáles son las fechas en la presencia del software o parte del mismo pudiese marcar la diferencia ?Estimaciones: ¿Cuánto tiempo lleva implementar una característica ?Consecuencias: Informar sobre las consecuencias de la toma de decisiones por parte del negocio. Por ejemplo el cambiar las bases de datos.Procesos: ¿Cómo se organiza el trabajo y el equipo?.Programación detallada: Dentro de una versión ¿Qué problemas se resolverán primero?.

HISTORIA DE LOS USUARIOS:Es la técnica utilizada en XP que permite obtener los requerimientos del sistema a implementar. Se utilizan para crear estimaciones de tiempo. Las Historias de usuario son escritas por los clientes, como los requerimientos que el cliente necesita que el sistema realice por

2

el. Deben descritas con un formato de dos o tres líneas de texto, hechas por el mismo cliente usando su propia terminología sin términos técnicos.Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 01 y 03 semanas.Estas deben proporcionar solo el detalle suficiente como para poder hacer razonable la estimación de cuánto tiempo requiere la implementación de la historia. Difiere de los casos de uso porque son escritos por el cliente, no por los programadores, empleando terminología del cliente. Las historias de usuario son mas “amigables” que “formales”

HISTORIA DEL USUARIONumero: Nombre de Historia de usuario:Usuario: Iteración Asignada:Prioridad del Negocio:(Alta/Media/Baja)

Puntos Estimados :

Riesgo de Desarrollo:(Alto/Medio/Bajo)

Puntos Reales:

Descripción:Observaciones:

Las Historias de Usuario tienen tres aspectos:

TAREAS:Las historias se dividen en tareas. En ellas se almacenan suficiente información para identificar y detallar la historia y los pasos necesarios para poder implementarla. Los desarrolladores se “ofrecen” para realizar estas tareas

TAREA Numero de tarea: Historia de usuario ( Nro y Nombre ):Nombre Tarea :Tipo de tarea:Desarrollo/Corrección/Mejora/Otra(especificar)

Puntos Estimados( es la estimación de dificultad en el desarrollo) Gralmente calificar

3

entre 1,2,3,4,5 niveles de dificultad

Fecha inicio: Fecha Fin:Programador responsable:Descripción:

CONVERSIONClientes y programadores discuten la historia para ampliar los detalles, ya sea verbalmente cuando sea posible o documentada cuando se requiera confirmación

PRUEBAS DE ACEPTACIONPermite confirmar que la historia ha sido implementada correctamente. Se utilizan en la fase de iteraciones, para verificar si el programa cumple con lo que especifica la historia del usuario

PRUEBA DE ACEPTACIONNro. de Prueba: Historia de usuario ( Nro. y Nombre )Nombre:Descripción:Condiciones de ejecución:Entradas/ pasos de ejecución:Evaluación de la prueba:

1.1.2.2. DISEÑO.- METAFORA.

Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema.

- DISEÑO SENSILLOEl diseño adecuado para el software es aquel que :

I. Funciona con todas las pruebas.II. No tiene lógica duplicada.

III. tiene menor número. de clases y métodos.Haz el diseño lo más simple posible, borra todo lo que puedas sin violar las reglas(I, II, III ), Contrariamente a lo que se pensaba el

4

“Implementa para hoy, diseña para mañana”, no es del todo correcto si piensas que el futuro es incierto

1.1.2.3. DESARROLLO.a) Recodificación.

Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo más simple posible, después de implementar esta característica, nos preguntamos cómo hacer el programa más simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar. Esto a veces nos puede llevar a hacer más trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.

b) Programación por parejas.Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa mas estratégicamente, ¿ Va a funcionar ?, ¿ Puede haber pruebas donde no funcione ?, ¿ Hay forma de simplificar el sistema global para que el problema desaparezca ?.El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera

c) Propiedad colectivaCualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un

5

cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.

d) Integración continuaEl código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%

e) Cliente in situ.Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.

f) Estándar de codificación.Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactorización (recodificación), debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo

1.1.2.4. PRUEBAS.No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa más seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.

6

2. CAPITULO III : FASE DE PLANIFICACION2.1. HISTORIA DE LOS USUARIOS

La historia de usuario representa los primeros pasos requerimientos por parte del usuario, es importante no detallar las historias de usuario porque son utilizadas solo para dar una pequeña visión de lo que se quiere obtener.

Historia de Usuario 01

HISTORIA DEL USUARIONumero: 01 Nombre de Historia de usuario:

Inicio de Sesión – Área Electrificación MDTUsuario: Área de electrificación

Iteración Asignada: 1

Prioridad del Negocio: Alta(Alta/Media/Baja)

Puntos Estimados : 1

Riesgo de Desarrollo: Bajo(Alto/Medio/Bajo)

Puntos Reales: 1

Descripción:Para Poder Ingresar al sistema, los usuarios tendrán que ingresar su identificación de usuario y contraseña. Una vez dentro del sistema, el usuario tendrá acceso a las opciones del menú, dependiendo de los permisos que este tenga asignados.Observaciones :Si el nombre de usuario o contraseña son incorrectos, se mostrara un mensaje de error y después de 03 intentos se saldrá del sistema

Historia de Usuario 02

HISTORIA DEL USUARIONumero: 02 Nombre de Historia de usuario:

Configurar Tarifas eléctricasUsuario: Operador del sistema

Iteración Asignada: 1

Prioridad del Negocio : Alta(Alta/Media/Baja)

Puntos Estimados : 1

Riesgo de Desarrollo: bajo(Alto/Medio/Bajo)

Puntos Reales: 1

Descripción: Se definen los montos de pensión fija y precio por kw del consumo de energía eléctrica según sector y caserío

Observaciones : Esta deberá ser modificada cada año

2.2. ESTIMACION DE ESFUERZO

Los clientes son los que establecen la prioridad de cada historia de usuario correspondiente, Los desarrolladores (programadores) realizan una estimación de esfuerzo necesario de cada una de ella.

NRO NOMBRE PRIORIDAD RIESGO ESFUERZO1 Inicio de Sesión – Área

Electrificación MDTAlta Bajo

2 Configurar Tarifas eléctricas Alta Bajo3 Definir parámetros generales Alta Bajo4 Definir mensaje del mes Baja Bajo5 Mantenimiento de sectores y

caseríosAlta Bajo

6 Mantenimientos de conceptos de facturación

Alta Bajo

.. .. .. ..

.. .. .. ..

2.3. PLAN DE ENTREGASDe acuerdo a la estimación del esfuerzo se determina un cronograma de entregas al cliente.

NºENTREG

AHISTORIA DE OS USUARIOS IMPLEMENTADAS

FECHA DEENTREGA AL:

1

Inicio de Sesión – Área Electrificación MDTConfigurar Tarifas eléctricasDefinir parámetros generalesDefinir mensaje del mesMantenimiento de sectores y caseríosMantenimientos de conceptos de facturación

8

Mantenimiento de usuariosMantenimiento de medidoresRegistro de lecturas consumo de energía eléctricaEmisión de recibos según facturación por consumo de energía eléctricaRegistro de Cortes y reconexiónMantenimiento de cuenta corrienteDetalle de facturaciónDetalle de facturación Deudas

2

Transferencias de prediosResumen de facturaciónResumen de recaudaciónResumen general de deudasConteo de recibosResumen de consumosCambio de Clave

3Copiar / restaurar base de datosGestión de usuario

2.4. TAREAS POR HISTORIA DE USUARIO

Tarea para la historia de usuario 01

TAREA Numero de tarea: 1.1

Historia de usuario ( Nro y Nombre ):Historia 01 , Inicio de Sesión – Área Electrificación MDT

Nombre Tarea : Diseñar una estructura de datos para validar los datos de entrada de usuariosTipo de tarea: diseñoDesarrollo/Corrección/Mejora/Otra(especificar)

Puntos Estimados : 1

Fecha inicio: Fecha Fin:Programador responsable:Juan Francisco Del Maestro PericheDescripción: de desarrollara una estructura que contenga los datos de los usuarios del sistema que tendrán acceso al mismo

Tarea para la historia de usuario 01

TAREA

9

Numero de tarea: 1.2

Historia de usuario: Historia 01 , Inicio de Sesión – Área Electrificación MDT

Nombre Tarea : Inicio de sesiónTipo de tarea: desarrolloDesarrollo/Corrección/Mejora/Otra(especificar)

Puntos Estimados : 1

Fecha inicio: Fecha Fin:Programador responsable:Juan Francisco Del Maestro PericheDescripción: Se desarrollara una interfaz grafica para que el usuario pueda ingresar su identificación, clave de usuario , validar sus datos y tener acceso a las opciones del sistema que se le han asignado

Tarea para la historia de usuario 02

TAREA Numero de tarea: 2.1

Historia de usuario: Historia 02, Configurar Tarifas eléctricas

Nombre Tarea : Diseñar una estructura de datos que permita registrar las diversas tarifasTipo de tarea: diseñoDesarrollo/Corrección/Mejora/Otra(especificar)

Puntos Estimados : 1

Fecha inicio: Fecha Fin:Programador responsable:Juan Francisco Del Maestro PericheDescripción: Definir la estructura de una tabla que permita registrar el valor de las tarifas existentes, tanto para los usuarios con pedidor , como así también a los usuarios de pensión fija

2.5. PLANIFICACON POR HISTORIAS

10

ITERA CIONES NRO HISTORIA DE USUARIO INICIO FIN Semanas

PRIMERA

1 Inicio de Sesión – Área Electrificación MDT

01/09/2011 1

2 Configurar Tarifas eléctricas

1

3 Definir parámetros generales

1

4 Definir mensaje del mes 15 Mantenimiento de

sectores y caseríos1

6 Mantenimientos de conceptos de facturación

1

SEGUNDA

7 Mantenimiento de usuarios

1

8 Mantenimiento de medidores

1

9 Registro de lecturas consumo de energía eléctrica

2

10 Emisión de recibos según facturación por consumo de energía eléctrica

3

11 Registro de Cortes y reconexión

1

….. … ..

11

2.6. ITERACIONESEn términos de proyectos, iteración se refiere a la técnica de desarrollar y entregar componentes incrementales de funcionalidades de un negocio

2.7. CRONOGRAMA PLAN DE ENTREGA

Nº Nombre Inicio fin Duración.Semanas

sem 1

Sem2

Sem3

Sem4

Sem5

Sem6

Sem7

Sem8

Sem9

Sem10

Sem11

Sem12

Sem13

Sem14

Sem15

1 1ra Iteración 5.3 xxxxx xxxxx xxxx xxxxx xxx

2 2da iteración 8 xx xxxxx xxxx xxxxx

xxxxx xxxxx xxxxx xxxxx xxx

12

2.8. REUNIONESLas reuniones con el cliente fueron permanentes, y en la misma municipalidad , en el área de Electrificación rural.

3. CAPITULO IV: FASE DE DISEÑO

3.1. METAFORA DEL SISTEMALa metáfora es el marco conceptual y proporciona nombres descriptivos a los elementos del sistema, explica la arquitectura lógica del sistema, descrito en términos familiarizados por los clientes y desarrolladores.Aquí se las historias de los usuarios se transforman en objetos o entidad.En lo que respecta al proyecto, tenemos que basándonos en las historias de los usuarios, específicamente de sus tareas, podemos señalar que se requieren diseñar los siguientes módulos.

Un sistema de base de datos que nos permita almacenar la información de tanto de usuarios del sistema de facturación, datos de los predios, consumos, facturas y otros conceptos necesarios para dar funcionalidad al sistema.

Una interfaz grafica que cumpla con los requerimientos del cliente y que interactué con el sistema centra del proyecto.

Un modulo de control de usuarios que permita definir los usuarios del sistema autorizados a realizar operaciones

-3.2. MODELO DEL DOMINIO

El modelo del dominio busca representar los objetos con sus atributos y relaciones, pero no son objetos software, sino un “diccionario visual” de conceptos del dominio.Se le denomina “de dominio” para distinguirlo del modelo de negocio que en el RUP( rational Unified Porcess) es un concepto más amplioEl dominio representa la parte del negocioSe utiliza una notación UML de diagrama de estructura estática (Diagrama de estructura compuesta)

DIAGRAMA DEL DOMINIO

14

3.3. TARJETAS CRC(Clases, responsabilidades y colaboradores).Las tarjetas CRC reflejan la iteración de las clases que tiene el sistema, permitiendo la obtención del diagrama de clases.En nuestro sistema se diseñaron las siguientes tarjetas CRC.

USUARIORESPONSABILIDAD COLABORACIONRegistrar usuarios del sistema de facturaciónModificar datos del Usuario

PREDIORESPONSABILIDAD COLABORACIONRegistrar datos del predioAsignar medidorModificar datos del predio

CONSUMORESPONSABILIDAD COLABORACIONRegistrar consumo mensual por predio y usuario

UsuarioPredioCaseríotarifa

FACTURARESPONSABILIDAD COLABORACIONElaborar facturaEmisión de Factura

Usuario PredioConsumoTipo de tarifa

3.4. MODELO DE DATOS : DIAGRAMA ENTIDAD RELACIONXP no persigue definir ni esquematizar un diseño único, generalmente la fase de creación y codificación va moldeando el diseño del sistema, aquí se presenta un Diagrama Entidad Relación en función a las Iteraciones ya definidas

16

MODELO ENTIDAD RELACION

Diseñar el modelo entidad relacion

3.5. SOLUCIONES PUNTUALESSe desarrollara el Sistema para la plataforma Windows que permita llevar el control de la facturación del consumo de energía Eléctrica para el área rural del distrito de TucumeSe desarrollara una aplicación Windows independiente al sistema que permita gestionar los usuarios del sistema los cuales tendrán diferentes opciones de acceso dentro del sistema general.

3.6. FUNCIONALIDAD MINIMAEl sistema diseñado tiene una funcionalidad mínima que le permite al operador del sistema cumplir con la gestión de la cobranza del servicio de consumo de energía eléctrica, y llevar el estado de cuenta corriente de cada usuario.

3.7. DISEÑO DE LA INTERFAZ GRAFICAEn este punto se presenta los criterios utilizados para el diseño de la interfaz grafica.La interfaz grafica es el medio por el cual el usuario final (operador del Sistema) interactúa con nuestra aplicación.Por lo general, la aceptación del software depende mucho de las facilidades que el sistema otorga al usuario final en relación a su uso y aplicación.Las características que deberá tener la interfaz grafica debe cumplir con lo siguiente:

Ser Intuitivo : .la interfaz del sistema debe se visual, conceptual y lingüísticamente sencillo, es por esto que se diseñan elementos visuales de comprensión inmediata y que este relacionadas con el mundo real, su funcionalidad debe ser de fácil comprensión

Ser Configurable: la interfaz debe ayudar al usuario final y no debe interferir con el flujo del mismo. En lo posible el sistema debe permitir organizar y ordenar el espacio de trabajo que se le otorga al usuario y de esa manera el usuario tendrá la sensación que se le ofrece un producto personalizado

17

Formas directas para realizar tareas: Se busca que el sistema minimice el número de pasos necesario para llevar a cabo una operación que el usuario tiene que realiza.

Contemplar posibles errores de los usuarios : La interfaz debe solucionar posibles errores del usuario, minimizando las posibilidades de error. Un mensaje de error deberá indicar el problema objetivo y ofrecer posibles soluciones. Dichos mensajes deben ser apropiados y de fácil comprensión del usuario.

Los componentes visuales del sistema se detallen a continuaciónVentanas:

Existe una ventana principal que tiene el menú de opciones.Las ventanas que permiten el proceso de ingreso de datos deben tener títulos que describen su funcionalidad

MenúsEl menú de opciones se encuentra en la ventana principal, agrupado por funciona lides del sistemaSe minimiza el número de subniveles para mejor compresión de las opcionesSe usan descripciones únicas dentro del menú

BotonesSe usaran para representar acciones comunes o frecuentes

3.8. INTERFAZ DEL USUARIO3.8.1. Inicio de sesión:

Interfaz grafica que permite el acceso a los usuarios del sistema, para ello deben ingresar su identificación (nombre de usuario) Y una contraseña, además de seleccionar el año actual.

18

3.8.2. Menú Principal: Interfaz grafica que permite mostrar todas las opciones del sistema según el acceso que se le a brindado a dicho usuario con el modulo de administraciones de usuarios del sistema.

19

Formato de recibo por consumo de Energía Eléctrica

.4. CAPITULO V: FASE DE DESARROLLO DEL SISTEMA

4.1. ESTANDARES DE DESARROLLO DEL SOFTWAREEs importante establecer un estándar de programación y nomenclatura durante la implementación (codificación), de tal manera obtenemos una optimización de nuestros programas, ganar velocidad de procesos y mejores presentaciones a la hora de entregar un trabajo final a nuestro usuario final.

4.1.1. Nomenclatura para controlesLa siguiente tabla muestra las convenciones que utilizamos para mostrar los controles a lo largo del desarrollo de software:

Tipo de Control Prefijo EjemploFormulario Form_ Form_FacturacionCajas de texto TextBox_ TextBox_MesCajas de despliege

ComboBox_ ComboBox_Caserio

Cajas de Fecha DateTimePicker_ DateTimePicker_Fecha_FacturacionBotones Button_ Button_Mostrar_FacturacionGrillas de VistaDataGridView

DGV_ DGV_Recibos

Radiobutton RadioButton_ RadioButton_facturadosCheckBox CheckBox_ CheckBox_Por_Periodo

20

4.1.2. Nomenclatura para variablesGeneralmente las variables definidas por el usuario incian con la letra “n”, ejemplo : Dim nNumero as integer Dim nDT_Usuario as Datatable. Dim nIdUsuario as integer Dim mUsuario as string

4.1.3. Nomenclatura para las clases y estructurasSe indica la nomenclatura de las clases y estructuras de datos a usar en nuestro codificaciónejemplo

21

4.2. DISPONIBILIDAD DEL CLIENTEDurante el desarrollo del software, el cliente fue privilegiado y como tal estuvo presente en todas las etapas del proceso de desarrollo, esta situación facilito la realización de pruebas de funcionamiento del sistema y a la vez se aclararon inquietudes manifiestas en la etapa de planificación.La circunstancia descrita permitió la consolidación y fortificación del funcionamiento del software, lo que quiere decir que el cliente tuvo un nivel excepcional de participación en el proceso de desarrollo del sistema.

4.3. PROGRAMACION POR PAREJASEste principio metodológico no se aplico debido a que el tesista es una sola persona.

4.4. CODIFICACION

CAPITULO VI: FASE DE PRUEBA

22

5. CAPITULO VI: FASE DE PRUEBAS

5.1. PRUEBAS DE ACEPTACIONEl actor principal en este tipo de pruebas es el usuario final, en vista de que es quien india que desea probar y está pendiente de los resultados que la solución presente.Las pruebas se realizaron específicamente en las siguientes historias de los usuarios:

Prueba de aceptación para Historia de usuario Nro. 01

PRUEBA DE ACEPTACIONPrueba : Nº 01

Nro. historia y Nombre:Historia Nº 01, Inicio de sesión – Área Electrificación MDT

Nombre de Prueba: Inicio de sesión por un operador del sistemaDescripción:El sistema debe aceptar o rechazar el acceso, dependiendo de la identificación del usuario y su clave, si está autorizado se mostrar el menú principal de opciones, de lo contrario el sistema abortara la sesión.Condiciones de Ejecución:El Software deberá estar instalado y configurado en el equipo de computoEntrada / pasos de Ejecución:

- Ejecutar la aplicación- Ingresar Nombre de usuario y clave( Login )- Presionar el botón de aceptación

Resultado Esperado:Si el login es correcto se mostrar el menú principalEvaluación de la Prueba:Prueba satisfactoria

23

Prueba de aceptación para Historia de usuario Nro. 02

PRUEBA DE ACEPTACIONPrueba: Nº 02

Nro. y Nombre de historia: Historia Nº 02, Configurar tarifas eléctricas

Nombre de Prueba:Asignación de tarifa mensual según sector y caseríoDescripción:Permite definir el valor de la tarifa mensual tanto para consumo con medidor o pensión fija, valores que se definen por sector y caserío.Condiciones de Ejecución:

Entrada / pasos de Ejecución:De l los datos definidos del mes actual, se debe copiar al siguiente mes, luego se define la fecha de corte para después dar la actualización.Resultado Esperado:Se define los valores de la tarifa para la facturación del mes siguienteEvaluación de la Prueba:Prueba satisfactoria

Prueba de aceptación para Historia de usuario Nro. 05

PRUEBA DE ACEPTACIONPrueba :Nº 03

Nro. y nombre historia: Historia Nº 05, Mantenimiento de sectores y caseríos.

Nombre de Prueba:Adicionar Sector y caseríoDescripción:En esta prueba se ingreso un nuevo sector, un nuevo caserío, también se procedió a editar el nombre de un caserío. Condiciones de Ejecución:ningunaEntrada / pasos de Ejecución:

- Seleccionar que es lo que se va a ingresar o editar: sector o caserío, en este caso ingreso de sector

- Presionar el botón nuevo, luego se muestra otra ventana de ingreso de un nuevo sector, en el cual ingresamos el nombre del nuevo sector y presionamos el botón guardar

- Regresamos a la ventana de mantenimiento de sectores y caseríos.

- Luego procedemos a ingresar un nuevo caserío- También editamos el nombre del caserío para modificar

su nombre

24

Resultado Esperado:Se ingreso un nuevo sector, se ingreso un nuevo caserío, se edito el nombre de un caseríoEvaluación de la Prueba:Prueba satisfactoria

CAPITULO VII CONCLUSIONES Y RECOMENDACIONES

25

26