Desarrollo de Aplicaciones Con Programacion Extrema
-
Upload
frank-luis-gallardo-cabrera -
Category
Documents
-
view
470 -
download
1
Transcript of Desarrollo de Aplicaciones Con Programacion Extrema
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