1.1.1. PROGRAMACION EXTREMA ( XP) Programacin extrema (XP), es la propuesta agil mas importante en la actualidad.

La programacin Extrema o eXtreme Programming (XP) es un enfoque de la ingeniera del software formulada por Kent Beck (Padre del XP), autor del primer libro sobre la materia, eXtreme Programming Explained: Embrace Change (1999)
Es una metodologa para el desarrollo de software y consiste bsicamente 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 tiempo La Programacin Extrema es una metodologa agil centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software Promueve el trabajo en equipo, preocupndose en todo momento del aprendizaje de los desarrolladores y estableciendo un buen clima de trabajo. Este tipo de mtodo se basa en una realimentacin continua entre el cliente y el equipo de desarrollo con una comunicacin fluida entre todos los participantes, tambin busca simplificar las soluciones implementadas y coraje para los mltiples cambios. Este tipo de programacin es la adecuada para proyectos con requisitos imprecisos, muy cambiantes y con un riesgo tcnico excesivo.

1.1.2. FASES DE LA METODOLOGIA XP. La metodologa XP consta de cuatro etapas:

Diseo simpe de cartas CRC Historias de usuarios DISEO PLANEACION Prototipos

CODIFICACION Prueba de unidad PRUEBAS Integracin continua

Prueba de aceptacin

Programacin en parejas

1.1.2.1. PLANIFICACION. XP plantea la planificacin como un permanente dialogo entre las partes la empresarial (deseable) y la tcnica (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 ? Composicin de versiones: Cunto 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 versiones Fechas de versiones: Cules son las fechas en la presencia del software o parte del mismo pudiese marcar la diferencia ? Estimaciones: Cunto tiempo lleva implementar una caracterstica ? Consecuencias: Informar sobre las consecuencias de la toma de decisiones por parte del negocio. Por ejemplo el cambiar las bases de datos. Procesos: Cmo se organiza el trabajo y el equipo?. Programacin detallada: Dentro de una versin Qu problemas se resolvern primero?. HISTORIA DE LOS USUARIOS: Es la tcnica 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 lneas de texto, hechas por el mismo cliente usando su propia terminologa sin trminos tcnicos. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se renen 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 estimacin de cunto tiempo requiere la implementacin de la historia. Difiere de los casos de uso porque son escritos por el cliente, no por los programadores, empleando terminologa del cliente. Las historias de usuario son mas amigables que formales

HISTORIA DEL USUARIO Numero: Nombre de Historia de usuario: Usuario: Iteracin Asignada: Prioridad del Negocio: Puntos Estimados : (Alta/Media/Baja) Riesgo de Desarrollo: Puntos Reales: (Alto/Medio/Bajo) Descripcin: Observaciones:

Las Historias de Usuario tienen tres aspectos: TAREAS: Las historias se dividen en tareas. En ellas se almacenan suficiente informacin 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: Puntos Estimados( es la Desarrollo/Correccin/Mejora/Otra estimacin de dificultad en el (especificar) desarrollo) Gralmente calificar entre 1,2,3,4,5 niveles de
3

Fecha inicio: Programador responsable: Descripcin:

dificultad Fecha Fin:

CONVERSION Clientes y programadores discuten la historia para ampliar los detalles, ya sea verbalmente cuando sea posible o documentada cuando se requiera confirmacin PRUEBAS DE ACEPTACION Permite 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 ACEPTACION Nro. de Prueba: Historia de usuario ( Nro. y Nombre ) Nombre: Descripcin: Condiciones de ejecucin: Entradas/ pasos de ejecucin: Evaluacin de la prueba:

1.1.2.2. -

DISEO. METAFORA. Una metfora es una historia que todo el mundo puede contar a cerca de cmo funciona el sistema.

DISEO SENSILLO El diseo adecuado para el software es aquel que : I. Funciona con todas las pruebas. II. No tiene lgica duplicada. III. tiene menor nmero. de clases y mtodos. Haz el diseo lo ms simple posible, borra todo lo que puedas sin violar las reglas(I, II, III ), Contrariamente a lo que se pensaba el

Implementa para hoy, disea para maana, no es del todo correcto si piensas que el futuro es incierto 1.1.2.3. DESARROLLO. a) Recodificacin. Cuando implementamos nuevas caractersticas en nuestros programas nos planteamos la manera de hacerlo lo ms simple posible, despus de implementar esta caracterstica, nos preguntamos cmo hacer el programa ms simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar. Esto a veces nos puede llevar a hacer ms trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas caractersticas. No debemos de recodificar ante especulaciones si no solo cundo el sistema te lo pida.

b) Programacin por parejas. Todo el cdigo de produccin lo escriben dos personas frente al ordenador, con un slo ratn y un slo 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 estratgicamente, Va a funcionar ?, Puede haber pruebas donde no funcione ?, Hay forma de simplificar el sistema global para que el problema desaparezca ?. El emparejamiento es dinmico, puedo estar emparejado por la maana 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 colectiva Cualquiera que crea que puede aportar valor al cdigo en cualquier parcela puede hacerlo, ningn miembro del equipo es propietario del cdigo. Si alguien quiere hacer cambios en el cdigo puede hacerlo. Si hacemos el cdigo propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejndonos cada vez mas de la comprensin del problema, si necesitamos un
5

cambio sobre una parte del cdigo lo hacemos y punto. XP propone un propiedad colectiva sobre el cdigo nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparar para la sustitucin no traumtica de cada miembro del equipo. d) Integracin continua El cdigo se debe integrar como mnimo una vez al da, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el cdigo 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 difcil 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) Estndar de codificacin. Si los programadores van a estar tocando partes distintas del sistema, intercambiando compaeros, haciendo refactorizacin (recodificacin), debemos de establecer un estndar de codificacin aceptado e implantado por todo el equipo

1.1.2.4. PRUEBAS. No debe existir ninguna caracterstica 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 ms seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.

2. CAPITULO III : FASE DE PLANIFICACION 2.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 pequea visin de lo que se quiere obtener. Historia de Usuario 01 Numero: 01 HISTORIA DEL USUARIO Nombre de Historia de usuario: Inicio de Sesin rea Electrificacin MDT Iteracin Asignada: 1

Usuario: rea de electrificacin Prioridad del Negocio: Alta Puntos Estimados : 1 (Alta/Media/Baja) Riesgo de Desarrollo: Bajo Puntos Reales: 1 (Alto/Medio/Bajo) Descripcin: Para Poder Ingresar al sistema, los usuarios tendrn que ingresar su identificacin de usuario y contrasea. 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 contrasea son incorrectos, se mostrara un mensaje de error y despus de 03 intentos se saldr del sistema Historia de Usuario 02 Numero: 02

Usuario: Operador del sistema Prioridad del Negocio : Alta Puntos Estimados : 1 (Alta/Media/Baja) Riesgo de Desarrollo: bajo Puntos Reales: 1 (Alto/Medio/Bajo) Descripcin: Se definen los montos de pensin fija y precio por kw del consumo de energa elctrica segn sector y casero Observaciones :

HISTORIA DEL USUARIO Nombre de Historia de usuario: Configurar Tarifas elctricas Iteracin Asignada: 1

Esta deber ser modificada cada ao

2.2. ESTIMACION DE ESFUERZO Los clientes son los que establecen la prioridad de cada historia de usuario correspondiente, Los desarrolladores (programadores) realizan una estimacin de esfuerzo necesario de cada una de ella. NRO 1 2 3 4 5 6 .. .. NOMBRE Inicio de Sesin rea Electrificacin MDT Configurar Tarifas elctricas Definir parmetros generales Definir mensaje del mes Mantenimiento de sectores y caseros Mantenimientos de conceptos de facturacin .. .. PRIORIDAD Alta Alta Alta Baja Alta Alta .. .. RIESGO Bajo Bajo Bajo Bajo Bajo Bajo .. .. ESFUERZO

2.3. PLAN DE ENTREGAS De acuerdo a la estimacin del esfuerzo se determina un cronograma de entregas al cliente. N ENTREGA FECHA DE ENTREGA AL:

HISTORIA DE OS USUARIOS IMPLEMENTADAS Inicio de Sesin rea Electrificacin MDT Configurar Tarifas elctricas Definir parmetros generales Definir mensaje del mes Mantenimiento de sectores y caseros Mantenimientos de conceptos de facturacin Mantenimiento de usuarios Mantenimiento de medidores Registro de lecturas consumo de energa elctrica

Emisin de recibos segn facturacin por consumo de energa elctrica Registro de Cortes y reconexin Mantenimiento de cuenta corriente Detalle de facturacin Detalle de facturacin Deudas Transferencias de predios Resumen de facturacin Resumen de recaudacin Resumen general de deudas Conteo de recibos Resumen de consumos Cambio de Clave Copiar / restaurar base de datos Gestin 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 Sesin rea Electrificacin MDT Nombre Tarea : Disear una estructura de datos para validar los datos de entrada de usuarios Tipo de tarea: diseo Puntos Estimados : 1 Desarrollo/Correccin/Mejora/Otra (especificar) Fecha inicio: Fecha Fin: Programador responsable: Juan Francisco Del Maestro Periche Descripcin: de desarrollara una estructura que contenga los datos de los usuarios del sistema que tendrn acceso al mismo Tarea para la historia de usuario 01 TAREA Numero de tarea: 1.2 Historia de usuario: Historia 01 , Inicio de Sesin rea Electrificacin MDT Nombre Tarea : Inicio de sesin
9

Tipo de tarea: desarrollo Puntos Estimados : 1 Desarrollo/Correccin/Mejora/Otra (especificar) Fecha inicio: Fecha Fin: Programador responsable: Juan Francisco Del Maestro Periche Descripcin: Se desarrollara una interfaz grafica para que el usuario pueda ingresar su identificacin, 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: Historia de usuario: 2.1 Historia 02, Configurar Tarifas elctricas Nombre Tarea : Disear una estructura de datos que permita registrar las diversas tarifas Tipo de tarea: diseo Puntos Estimados : 1 Desarrollo/Correccin/Mejora/Otra (especificar) Fecha inicio: Fecha Fin: Programador responsable: Juan Francisco Del Maestro Periche Descripcin: Definir la estructura de una tabla que permita registrar el valor de las tarifas existentes, tanto para los usuarios con pedidor , como as tambin a los usuarios de pensin fija

2.5. PLANIFICACON POR HISTORIAS ITERA CIONES NRO HISTORIA DE USUARIO 1 Inicio de Sesin rea Electrificacin MDT 2 Configurar Tarifas elctricas PRIMERA 3 Definir parmetros

INICIO 01/09/2011

FIN

Semanas 1 1 1
10

4 5 6 7 8 SEGUNDA 9

10

11 ..

generales Definir mensaje del mes Mantenimiento de sectores y caseros Mantenimientos de conceptos de facturacin Mantenimiento de usuarios Mantenimiento de medidores Registro de lecturas consumo de energa elctrica Emisin de recibos segn facturacin por consumo de energa elctrica Registro de Cortes y reconexin

1 1 1 1 1

3 1 ..

11

2.6. ITERACIONES En trminos de proyectos, iteracin se refiere a la tcnica de desarrollar y entregar componentes incrementales de funcionalidades de un negocio 2.7. CRONOGRAMA PLAN DE ENTREGA N Nombre Inicio fin Duraci sem n. Sema 1 nas xxxxx 5.3 8

Sem 2
xxxxx

Sem 3
xxxx

Sem 4
xxxxx

Sem 5
xxx xx

Sem 6

Sem 7

Se m 8
xxxx x

Sem 9

Sem 10

Sem 11

Sem 12

Sem 13

Sem 14

Sem 15

1 2

1ra Iteracin 2da iteracin

xxxxx

xxxx

xxxxx

xxxxx

xxxxx

xxxxx

xxx

12

2.8. REUNIONES Las reuniones con el cliente fueron permanentes, y en la misma municipalidad , en el rea de Electrificacin rural. 3. CAPITULO IV: FASE DE DISEO 3.1. METAFORA DEL SISTEMA La metfora es el marco conceptual y proporciona nombres descriptivos a los elementos del sistema, explica la arquitectura lgica del sistema, descrito en trminos 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 basndonos en las historias de los usuarios, especficamente de sus tareas, podemos sealar que se requieren disear los siguientes mdulos. Un sistema de base de datos que nos permita almacenar la informacin de tanto de usuarios del sistema de facturacin, 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 ms amplio El dominio representa la parte del negocio Se utiliza una notacin UML de diagrama de estructura esttica (Diagrama de estructura compuesta)

DIAGRAMA DEL DOMINIO

14

3.3. TARJETAS CRC (Clases, responsabilidades y colaboradores). Las tarjetas CRC reflejan la iteracin de las clases que tiene el sistema, permitiendo la obtencin del diagrama de clases. En nuestro sistema se disearon las siguientes tarjetas CRC.

RESPONSABILIDAD Registrar usuarios del sistema de facturacin Modificar datos del Usuario

USUARIO COLABORACION

RESPONSABILIDAD Registrar datos del predio Asignar medidor Modificar datos del predio

PREDIO COLABORACION

CONSUMO RESPONSABILIDAD COLABORACION Registrar consumo mensual por Usuario predio y usuario Predio Casero tarifa FACTURA COLABORACION Usuario Predio Consumo Tipo de tarifa

RESPONSABILIDAD Elaborar factura Emisin de Factura

3.4. MODELO DE DATOS : DIAGRAMA ENTIDAD RELACION XP no persigue definir ni esquematizar un diseo nico, generalmente la fase de creacin y codificacin va moldeando el diseo del sistema, aqu se presenta un Diagrama Entidad Relacin en funcin a las Iteraciones ya definidas

MODELO ENTIDAD RELACION Disear el modelo entidad relacion

3.5. SOLUCIONES PUNTUALES Se desarrollara el Sistema para la plataforma Windows que permita llevar el control de la facturacin del consumo de energa Elctrica para el rea rural del distrito de Tucume Se desarrollara una aplicacin Windows independiente al sistema que permita gestionar los usuarios del sistema los cuales tendrn diferentes opciones de acceso dentro del sistema general.

3.6. FUNCIONALIDAD MINIMA El sistema diseado tiene una funcionalidad mnima que le permite al operador del sistema cumplir con la gestin de la cobranza del servicio de consumo de energa elctrica, y llevar el estado de cuenta corriente de cada usuario. 3.7. DISEO DE LA INTERFAZ GRAFICA En este punto se presenta los criterios utilizados para el diseo de la interfaz grafica. La interfaz grafica es el medio por el cual el usuario final (operador del Sistema) interacta con nuestra aplicacin. Por lo general, la aceptacin del software depende mucho de las facilidades que el sistema otorga al usuario final en relacin a su uso y aplicacin. Las caractersticas que deber tener la interfaz grafica debe cumplir con lo siguiente: Ser Intuitivo : .la interfaz del sistema debe se visual, conceptual y lingsticamente sencillo, es por esto que se disean elementos visuales de comprensin inmediata y que este relacionadas con el mundo real, su funcionalidad debe ser de fcil comprensin 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 sensacin que se le ofrece un producto personalizado

16

Formas directas para realizar tareas: Se busca que el sistema minimice el nmero de pasos necesario para llevar a cabo una operacin 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 fcil comprensin del usuario.

Los componentes visuales del sistema se detallen a continuacin Ventanas: Existe una ventana principal que tiene el men de opciones. Las ventanas que permiten el proceso de ingreso de datos deben tener ttulos que describen su funcionalidad Mens El men de opciones se encuentra en la ventana principal, agrupado por funciona lides del sistema Se minimiza el nmero de subniveles para mejor compresin de las opciones Se usan descripciones nicas dentro del men Botones Se usaran para representar acciones comunes o frecuentes

3.8. INTERFAZ DEL USUARIO 3.8.1. Inicio de sesin: Interfaz grafica que permite el acceso a los usuarios del sistema, para ello deben ingresar su identificacin (nombre de usuario) Y una contrasea, adems de seleccionar el ao actual.

17

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

18

Formato de recibo por consumo de Energa Elctrica

. 4. CAPITULO V: FASE DE DESARROLLO DEL SISTEMA 4.1. ESTANDARES DE DESARROLLO DEL SOFTWARE Es importante establecer un estndar de programacin y nomenclatura durante la implementacin (codificacin), de tal manera obtenemos una optimizacin 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 controles La siguiente tabla muestra las convenciones que utilizamos para mostrar los controles a lo largo del desarrollo de software: Tipo de Control Formulario Cajas de texto Cajas de despliege Cajas de Fecha Botones Grillas de Vista DataGridView Radiobutton CheckBox Prefijo Form_ TextBox_ ComboBox_ DateTimePicker_ Button_ DGV_ RadioButton_ CheckBox_ Ejemplo Form_Facturacion TextBox_Mes ComboBox_Caserio DateTimePicker_Fecha_Facturacion Button_Mostrar_Facturacion DGV_Recibos RadioButton_facturados CheckBox_Por_Periodo

19

4.1.2. Nomenclatura para variables Generalmente 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 estructuras Se indica la nomenclatura de las clases y estructuras de datos a usar en nuestro codificacin ejemplo

20

4.2. DISPONIBILIDAD DEL CLIENTE Durante el desarrollo del software, el cliente fue privilegiado y como tal estuvo presente en todas las etapas del proceso de desarrollo, esta situacin facilito la realizacin de pruebas de funcionamiento del sistema y a la vez se aclararon inquietudes manifiestas en la etapa de planificacin. La circunstancia descrita permiti la consolidacin y fortificacin del funcionamiento del software, lo que quiere decir que el cliente tuvo un nivel excepcional de participacin en el proceso de desarrollo del sistema. 4.3. PROGRAMACION POR PAREJAS Este principio metodolgico no se aplico debido a que el tesista es una sola persona. 4.4. CODIFICACION

CAPITULO VI: FASE DE PRUEBA

21

5. CAPITULO VI: FASE DE PRUEBAS 5.1. PRUEBAS DE ACEPTACION El 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 solucin presente. Las pruebas se realizaron especficamente en las siguientes historias de los usuarios: Prueba de aceptacin para Historia de usuario Nro. 01 PRUEBA DE ACEPTACION Prueba : Nro. historia y Nombre: N 01 Historia N 01, Inicio de sesin rea Electrificacin MDT Nombre de Prueba: Inicio de sesin por un operador del sistema Descripcin: El sistema debe aceptar o rechazar el acceso, dependiendo de la identificacin del usuario y su clave, si est autorizado se mostrar el men principal de opciones, de lo contrario el sistema abortara la sesin. Condiciones de Ejecucin: El Software deber estar instalado y configurado en el equipo de computo Entrada / pasos de Ejecucin: - Ejecutar la aplicacin - Ingresar Nombre de usuario y clave( Login ) - Presionar el botn de aceptacin Resultado Esperado: Si el login es correcto se mostrar el men principal Evaluacin de la Prueba: Prueba satisfactoria

22

Prueba de aceptacin para Historia de usuario Nro. 02 PRUEBA DE ACEPTACION Prueba: Nro. y Nombre de historia: N 02 Historia N 02, Configurar tarifas elctricas Nombre de Prueba: Asignacin de tarifa mensual segn sector y casero Descripcin: Permite definir el valor de la tarifa mensual tanto para consumo con medidor o pensin fija, valores que se definen por sector y casero. Condiciones de Ejecucin: Entrada / pasos de Ejecucin: De l los datos definidos del mes actual, se debe copiar al siguiente mes, luego se define la fecha de corte para despus dar la actualizacin. Resultado Esperado: Se define los valores de la tarifa para la facturacin del mes siguiente Evaluacin de la Prueba: Prueba satisfactoria Prueba de aceptacin para Historia de usuario Nro. 05 PRUEBA DE ACEPTACION Prueba : Nro. y nombre historia: N 03 Historia N 05, Mantenimiento de sectores y caseros. Nombre de Prueba: Adicionar Sector y casero Descripcin: En esta prueba se ingreso un nuevo sector, un nuevo casero, tambin se procedi a editar el nombre de un casero. Condiciones de Ejecucin: ninguna Entrada / pasos de Ejecucin: - Seleccionar que es lo que se va a ingresar o editar: sector o casero, en este caso ingreso de sector - Presionar el botn nuevo, luego se muestra otra ventana de ingreso de un nuevo sector, en el cual ingresamos el nombre del nuevo sector y presionamos el botn guardar - Regresamos a la ventana de mantenimiento de sectores y caseros. - Luego procedemos a ingresar un nuevo casero - Tambin editamos el nombre del casero para modificar su nombre Resultado Esperado: Se ingreso un nuevo sector, se ingreso un nuevo casero, se edito el nombre de
23

un casero Evaluacin de la Prueba: Prueba satisfactoria

CAPITULO VII CONCLUSIONES Y RECOMENDACIONES

24

25