domingo, 28 de mayo de 2017

RAID


RAID

Introducción
Es este ensayo se hablará sobre qué es y que hace el sistema RAID, así mismo se mencionara como se emplea en distintos ámbitos, desde las grandes industrias hasta el uso en hogares, posteriormente se detallaran los tipos de configuraciones que existen de estos, desde la 0 hasta la 5, explicando la función que cumplen y como se encuentran configurados, además se expondrán algunas de sus ventajas y desventajas que tienen.


Redundant Array of Independent Disks, es decir, “conjunto redundante de discos independientes”. es un sistema que permite implementar un volumen de almacenamiento de datos que, al mismo tiempo, está formado por múltiples discos duros con el objetivo de conseguir más espacio o bien proteger la información y conseguir mayor tolerancia a fallos de disco (evitando pérdida de información si el disco duro sufre una avería).

Ejemplos:

En servidores se suelen usar RAID para montar un espejo entre discos duros y, de esta forma, replicar la información en dos discos duros idénticos y, si uno se estropea, no sufrir una caída del servicio por lo cual sueles ser muy útil y conocido en las grandes industrias
También se suele usar RAID en un NAS y sacrificar un poco del espacio útil para ganar en redundancia y poder reconstruir el volumen de información si un disco sufre una avería e, incluso, se deja algún disco en modo hot spare para que comience a usarse si uno de los discos falla.
Así mismo puede ser útil tener en casa algún volumen de almacenamiento con RAID para almacenar información sensible (fotos, documentos personales, etc.) que queramos que esté especialmente protegida.

Tipos:

  • RAID 0

En esta configuración lo que se hace es distribuir de manera equitativa los datos entre dos discos duros para aumentar la velocidad de acceso a los datos. Obviamente, al no existir redundancia, si uno de los discos se avería tendremos que recurrir a una copia de seguridad externa.

  • RAID 1

Es una de las mejores configuraciones en cuanto a redundancia y tolerancia a fallos. También conocida como “espejo” o “mirroring“, en esta configuración RAID lo que se hace es duplicar la información en dos discos. De esta forma, si un disco se estropea, el sistema seguirá funcionando y trabajando con el disco que aún funciona. Además, el rendimiento en lectura también aumenta porque, por ejemplo, es posible leer 2 datos a la vez (uno de cada disco).

  • RAID 2

Este usa una división a nivel de bits con un disco de paridad dedicado y usa un código de Hamming para la corrección de errores. Uno de sus efectos secundarios es que normalmente no puede atender varias peticiones simultáneas, debido a que por definición cualquier simple bloque de datos se dividirá por todos los miembros del conjunto, residiendo la misma dirección dentro de cada uno de ellos. Así, cualquier operación de lectura o escritura exige activar todos los discos del conjunto, suele ser un poco lento porque se producen cuellos de botella. Son discos paralelos, pero no son independientes. RAID 2 necesitaría 39 discos en un sistema informático moderno de 32 bits: 32 se usarían para almacenar los bits individuales que forman cada palabra y 7 se usarían para la corrección de errores.

  • RAID 3

Este tipo divide los datos a nivel de bytes en lugar de a nivel de bloques. Los discos son sincronizados por la controladora para funcionar al unísono. Éste es el único nivel RAID original que actualmente no se usa. Permite tasas de transferencias extremadamente altas.

  • RAID 4

También conocido como IDA (acceso independiente con discos dedicados a la paridad) usa división a nivel de bloques con un disco de paridad dedicado. Necesita un mínimo de 3 discos físicos. El
La división en bloques permite que cada miembro del conjunto funcione independientemente cuando se solicita un único bloque. Si la controladora de disco lo permite, un conjunto RAID 4 puede servir varias peticiones de lectura simultáneamente. En principio también sería posible servir varias peticiones de escritura simultáneamente, pero al estar toda la información de paridad en un solo disco, éste se convertiría en el cuello de botella del conjunto.

  • RAID 5

Es una de las configuraciones más comunes en la industria, por ejemplo, en un NAS; conocido como distribuido con paridad, en esta configuración se realiza una división por bloques de información y se distribuyen entre los discos que forman el conjunto. Además, se genera un bloque de paridad que, a modo de redundancia, nos permite reconstruir la información de volumen completo si, por ejemplo, uno de los discos se averiase. En este tipo de configuraciones, como mínimo debemos contar con 3 discos duros, pero solamente se tolera el fallo en uno de los discos.

  • RAID 0+1

Esta es una combinación de dos configuraciones simultáneas RAID 0 y RAID 1; se necesitan de 4 discos duros que se tomarán por parejas para que cada una de éstas forme un RAID 0 (división de la información) y, con las dos parejas, se monte un RAID 1 (un espejo). Dicho de otra forma, con esta configuración tendremos un RAID 0 redundado en espejo.

  • RAID 1+0
Es la configuración “contraria” al RAID 0+1; en este caso en vez de realizar un espejo del RAID 0, lo que se hace es aplicar el espejo a cada disco en striping. Por tanto, es una configuración de 4 discos en la que montamos un par de espejos y, por encima, repartimos la información entre dichos espejos.


Conclusión
Como se puede observar en este ensayo, la variedad tipos de sistemas RAID que existen con sus correspondientes configuraciones es muy variada, algunas con desventajas que los vuelve en la actualidad casi inutilizables, debido a que hoy en día la demanda que tienen estos dispositivos es muy alta, por lo tanto, es muy recomendable usar los RAID más actuales que tengan ciertas características con las cuales puedan atender de manera simultánea y optima todas las peticiones solicitadas, así ofreciendo una eficiente capacidad de respuesta.


Referencias


jjvelasco. (8 de Enero de 2014). hipertextual.com. Obtenido de hipertextual.com: https://hipertextual.com/archivo/2014/01/que-es-raid-discos-duros/

web.mit.edu. (s.f.). Obtenido de web.mit.edu: http://web.mit.edu/rhel-doc/3/rhel-sag-es-3/ch-raid-intro.html

www.dell.com. (16 de Junio de 2015 ). Obtenido de www.dell.com: https://www.dell.com/support/article/us/en/04/SLN179295/raid--matriz-redundante-de-discos-independientes?lang=ES

sábado, 13 de mayo de 2017

Help Desk

Introducción
En este ensayo se hablará sobre que es una Help Desk, al igual se mencionaran los servicios por medio de los cuales se basa para ofrecer asistencia. Así mismo se mencionarán los niveles de los cuales se componen y como labora el personal en cada uno de estos. También se hablará sobre las características con las que deben de contar dichas personas con el fin de proporcionar un servicio eficiente y capaz de resolver los problemas.


Help Desk o (en español Mesa de Ayuda) es un grupo establecido por una organización, el cual se encarga de prestar servicios para ofrecer asistencia y así solucionar posibles incidencias que puedan surgir tanto en el software como en los servicios que ellos o alguna empresa externa ofrece al mercado con el propósito de mantener la infraestructura activa y funcional todo el tiempo.
Estos centros de servicio cuentan con distintos niveles, los cuales se definen dependiendo del tipo de problemas que se presenten. Así mismo se asigna el personal encargado de proporcionar dicho servicio, el cual debe de saber proporcionar respuestas y soluciones a los usuarios, clientes o beneficiarios (destinatarios del servicio), y también puede otorgar asesoramiento en relación con una organización o institución, productos y servicios.
 En caso del primer nivel el personal debe de contar con los conocimientos suficientes para contestar preguntas frecuentes por parte de los usuarios
En el segundo nivel, se manejan problemas más profundos, sobre el sistema, aquí ya se involucran más personas para dar solución a dicho problema, así puede tanto el codificador como los técnicos.
La Mesa de Ayuda se basa en un conjunto de recursos técnicos y humanos que permiten dar soporte a diferentes niveles de usuarios informáticos, tales como:

  • Apoyado sobre un Sistema informático de última generación
  • Servicio de soporte a usuarios de “sistemas microinformáticos”
  • Atendido de forma inmediata e individualizada por Técnicos Especializados
  • Soporte telefónico centralizado en línea (on-line)
  • Soporte por medio de vía telefónica 

Conclusión
Como se puede observar, debido a la presencia de todos los sistemas de software de alta complejidad  que existen hoy en día, es necesaria la existencia de organizaciones como estas, con personal debidamente preparado para  brindar asistencia y así resolver cualquier incidencia, problema o dudad sobre el uso o funcionamiento que pueda surgir por parte del usuario, esto por medio de  distintas herramientas tecnológicas para así lograr el éxito del sistema y como consecuencia dejar al usuario satisfecho, debido a que este es su objetivo principal.

Referencias

artologik. (s.f.). www.artologik.com. Obtenido de www.artologik.com: http://www.artologik.com/es/HelpDesk.aspx?pageId=863
Correa, T. (14 de Agosto de 2014). es.slideshare.net. Obtenido de es.slideshare.net: https://es.slideshare.net/tomasccorrea/help-desk-38013170
InvGate. (19 de Agosto de 2014). blog.invgate.com. Obtenido de blog.invgate.com: http://blog.invgate.com/es/funcionalidades-importantes-help-desk



sábado, 1 de abril de 2017

REINGENIERÍA DE SOFTWARE


Introducción

En este ensayo se explicará que es la Reingeniería de Software y cuales es el objetivo que esta tiene, además se mencionara cuando y en qué casos se emplea, por otro lado, se señalaran los métodos por medio de los cuales funciona. Así mismo se expondrán los pasos que tiene que seguir con el fin de cumplir dichos objetivos y se concluirá mostrando los beneficios que se obtendrán al aplicar esta Reingeniería.

Se entiende por ingeniería de software al cambio aplicado a un sistema ya existente en sus diversos módulos. Estas modificaciones tienen objetivos de mejora, es decir corrigen errores en el sistema o se encargan de dar simplicidad a este para así facilitar tanto el mantenimiento como el funcionamiento.
La aplicación de la reingeniería de software se hace a sistemas los cuales ya tiene un largo tiempo de uso en el cual se ha deteriorado y vuelto inseguro y débil debido a que no se le ha aplicado el correcto mantenimiento, también este deterioro se da debido a todas la modificaciones y adaptaciones que se la han aplicado.
Es decir, la reingeniería de software se encarga de evaluar los sistemas con el fin de reestructúralos para que así estos adquieran mayor calidad.
A nivel de negocio, la reingeniería es ejercida por especialistas de negocio y a nivel de software, la reingeniería es ejecutada por ingenieros del software.

Pasos para aplicar la reingeniería de Software

1.-Formulacion de una estrategia, es decir se debe de identificar cuáles son las nuevas necesidades que hay en el mercado.
2.- Desarrollo de productos
3.- Desarrollo de una capa de manufactura para desarrollar el nuevo producto
4.-Comunicación con el cliente, esto con el fin de averiguar que es lo que desean, lo cual puede ser por medio de entrevistas o cuestionarios

Los beneficios que se obtienen al aplicar este tipo de ingeniería son la reducción de los riesgos al evolucionar una organización, también ayuda a las organizaciones las cuales por distintos motivos están perdiendo la inversión en sus softwares, el cual se vuelve más fácil de modificar y de aplicarle un mantenimiento, incluso también amplia las capacidades de las herramientas CASE.


Las Ingeniera de software implica diferentes actividades tales como:

Análisis de inventarios: Es un modelo el cual contiene toda la información que contiene información detallada las aplicaciones del sistema.
Reestructuración de Documentos: La documentación debe actualizarse, pero se tiene recursos limitados. Se utiliza un enfoque de “documentar cuando se toque”. El sistema es crucial para el negocio y debe volver a documentarse por completo.
Ingeniería Inversa: Proceso de análisis de un programa con el fin de crear una representación con un nivel de abstracción más elevado que el código fuente es decir es un proceso por medio de cual se intenta recuperar el diseño del sistema.
Reestructuración de código: Realizar modificaciones en el código, con el objetivo de mejorar su estructura interna sin alterar su comportamiento externo.
Reestructuración de datos: Se deben de identificar los objetos de datos y atributos, posteriormente se revisas las estructuras de datos con el fin de tener mayor calidad.
Ingeniería directa: Proceso de reconstrucción del software, crear un producto con una mejor funcionalidad, mejor desempeño y fiabilidad, así como una mejor facilidad de mantenimiento. 


Conclusión

Se concluye que la Reingeniería de Software es una buena opción para enfrentar que en la actualidad se realizan cambios constantes tanto en tecnología como en las preferencias y exigencias de las personas las cuales siempre buscan cosas nuevas y mejores, por lo tanto el software para que no se vuelva obsoleto debe de ser mejorado y por lo tanto modificado aplicando la Reingeniería de Software con el fin de satisfacer las necesidades ya sea del cliente o el negocio y así seguir siendo competente respecto a otros softwares nuevos.




Referencias

Garcia, F. (25 de Noviembre de 2015). prezi.com. Obtenido de prezi.com: https://prezi.com/aeooyvvwwllg/reingenieria-de-software/
isoftwareunesum.wordpress.com. (28 de Abril de 2011). Obtenido de isoftwareunesum.wordpress.com: https://isoftwareunesum.wordpress.com/2011/04/28/reingenieria-de-la-ingenieria-del-software/
Norsoft. (s.f.). www.norsoft.com.ar. Obtenido de www.norsoft.com.ar: http://www.norsoft.com.ar/servicios/servicios-reingenieria.html
Sicilia, M.-A. (s.f.). cnx.org. Obtenido de cnx.org: http://cnx.org/contents/jXj8TA20@3/Qu-es-Reingeniera-del-Software



ELEMENTO DE CONFIGURACIÓN DE SOFTWARE


Un elemento de configuración de software es la información elaborada en la parte del proceso de ingeniería, es decir es un componente simple que es una unidad en sí mismo el cual puede definirse y controlarse de forma individual por lo tanto ha logrado un estado estable en el proceso de desarrollo y en consecuencia es insertado dentro del control de configuración, así mismo es la unidad mínima de trabajo de la GCS.

Los siguientes son los elementos de configuración del Software.

  • Especificación del sistema
  • Plan de proyecto
  • Especificación de requisitos
    • Prototipo ejecutable o “en papel”
  • Manual de usuario preliminar
  • Especificación de diseños
    • Descripción del diseño de datos
    • Descripción del diseño arquitectónico
    • Descripciones del diseño de los módulos
    • Descripciones del diseño de interfaces
    • Descripciones de los objetos (si se utilizan técnicas de P.O.O)
  • Listados del código fuente
  • Plan y procedimiento de pruebas
  • Casos de prueba y resultados registrados
  • Manuales de operación de y de instalación
  • Programas ejecutables
    • Módulos, código ejecutable
    • Módulos enlazados
  • Descripción de la base de datos
    • Esquema y estructura de archivos
    • Contenido inicial
  • Manual del usuario final
  • Documentos de mantenimiento
    • Informes de problemas del software
    • Peticiones de mantenimiento
    • Ordenes de cambios e ingeniería
  • Estándares y procedimientos de ingeniería del software


Y para cada uno de estos elementos se almacenará al menos:
  • Nombre
  • Versión
  • Estado
  • Localización


Los siguientes son algunos ejemplos de los elementos de configuración de software
  • Estándares de análisis, diseño, codificación, pruebas, y auditoria
  • Ejecutables. El Código fuente del programa
  • Manual de usuario
  • Prototipos
  • Documentos (Visión, Especif. de CDU, etc.) 


Referencias




Pressman., R. (1993). Ingeniería del Software: un enfoque práctico. McGraw Hill. 
Lewi., I. H. (1989). Specifications in Software Engineering.
ecured. (s.f.). www.ecured.cu. Obtenido de www.ecured.cu: https://www.ecured.cu/Configuraci%C3%B3n_de_Software#Elemento_de_configuraci.C3.B3n_de_software_.28ECS.29

domingo, 19 de marzo de 2017

Ingeniería Inversa



Diagrama de Secuencia, Actividades, Clases, Casos de Uso y Requerimientos


https://drive.google.com/open?id=0BzgvDQ3qKQ96UTNsVGVyVjdJRkE
_________________________________________

Historias de Usuario, Tareas de Ingeniería, Caso de Prueba de Aceptación, Tarjetas CRC


Historias de Usuario, Tareas de Ingeniería, Caso de Prueba de Aceptación, Tarjetas CRC



Historia de Usuario
Número: 10
Nombre Historia de Usuario:
Venta de tarjeta dependiendo la distancia a recorrer por el usuario
Modificación (o extensión) de Historia de Usuario (Nro. y Nombre):
No existe
Usuario:
Clientes del suburbano
Iteración Asignada:
1
Prioridad en Negocio: 
------------------------
Puntos Estimados:
6
Riesgo en Desarrollo:
(Alto / Medio / Bajo)
Puntos Reales:
------------------------

Descripción:

El cliente llega a la ventanilla y pide una tarjeta del suburbano a la cual le recarga una cantidad deseada dependiendo de la distancia que recorrerá.


Observaciones:

El usuario no puede entrar sin haber comprado la tarjeta, el uso de estas es individual es decir no pueden entrar a las instalaciones más de una persona con la misma tarjeta, se debe de usar la misma tarjeta tanto para salir como para entrar.
A esta tarjeta se le deberá de abonar como minio una cantidad de 50 centavos y máximo 1000 pesos por motivos de seguridad para el cliente.



Tarea de Ingeniería
Número Tarea:
1
Historia de Usuario (Nro. y Nombre):
10, Venta de tarjeta dependiendo la distancia a recorrer por el usuario
Nombre Tarea: Venta de tarjeta dependiendo la distancia a recorrer por el usuario
Tipo de Tarea:
Desarrollo / Corrección / Mejora / Otra (especificar)
Se desarrollará el proceso de la venta de tarjetas del Suburbano, es un sistema nuevo por lo tanto se tiene que empezar desde cero
Puntos Estimados:
4
Fecha de Inicio:
03/03/17
Fecha de culminación.
-----------------

Programador Responsable:
Celaya Ordaz Marco Antonio y Peña Bustillos Jaime Víctor
Descripción:
Se creará un base de datos y se analizará el proceso de venta de tarjetas para poder mejorarlo, posteriormente se crearán los procesos correspondientes para elaborar dichas acciones.


Caso de Prueba de Aceptación
Código:
Venta
Historia de Usuario (Nro. y Nombre):
10, Venta de tarjeta dependiendo la distancia a recorrer por el usuario
Nombre: Prueba del módulo de ventas
Descripción: Recibir una tarjeta sin saldo y activada para poder hacer uso de ella.
Condiciones de Ejecución:

·         El usuario debe de acudir a las taquillas para la adquisición de una tarjeta
·         El sistema debe encontrase en servicio y con tarjetas disponibles.

Entrada / Pasos de ejecución:
El cliente pide una tarjeta por la cual deberá pagar primero una tarifa definida.
Resultado Esperado:
El sistema registrará el ID y activará la tarjeta, la cual no tendrá saldo.
Evaluación de la Prueba:
-------------------------------------------------------------

  
VENTA DE TARJETA
Responsabilidad
Colaborador
·         Añadir registro de nueva tarjeta.
·         Activarla







Historia de Usuario
Número: 20                           
Nombre: Historia de Usuario
Entrar al suburbano.
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
------------------------
Usuario:
Cliente del suburbano
Iteración Asignada:
2
Prioridad en Negocio:
--------------------
Puntos Estimados:
8
Riesgo en Desarrollo:
(Alto / Medio / Bajo)

Puntos Reales:
-------------------------------------------.
Descripción:
El cliente una vez ubicado en la entrada deberá de pasar su tarjeta en los lectores para que este pueda ingresar a las instalaciones.
Observaciones:
El usuario deberá de contar con una tarjeta previamente comprada la cual debe de contar con el saldo suficiente dependiendo de la trayectoria que valla a viajar.


Tarea de Ingeniería
Número Tarea:
2
Historia de Usuario (Nro. y Nombre):
20, Entrar al suburbano.
Nombre Tarea: Entrar al Suburbano.
Tipo de Tarea:
Desarrollo / Corrección / Mejora / Otra
Se va a crear todo el proceso para llevar la acción de entrada al suburbano.
Puntos Estimados:
8
Fecha de Inicio:
 08/03/2017
Fecha de culminación.
-----------------------------

Programador Responsable:

·         Celaya Ordaz Marco Antonio
·         Peña Bustillos Jaime Víctor

Descripción:
Se realizará el desarrollo del módulo para entrar al suburbano, en el cual se deberá validar que la tarjeta cuente con el saldo suficiente para poder pagar el viaje, ya sea con el intervalo de una zona o de dos, ya validado esto, se registrará el id de la tarjeta con el fin de corroborar que esta sea la misma para salir, y también se registrar en que zona está ingresando.


Caso de Prueba de Aceptación
Código:
Entrada
Historia de Usuario (Nro. y Nombre):
20, Entrar al suburbano
Nombre: Prueba del módulo Entrada
Descripción: Probar que se realice el registro tanto del ID como de la zona, además de validar que se cuente con saldo suficiente.
Condiciones de Ejecución:

·         Se debe de ubicar en los torniquetes
·         Se debe de contar con una tarjeta con el saldo suficiente

Entrada / Pasos de ejecución:
El usuario se ubica en los torniquetes en donde deberá de pasar su tarjeta con el saldo suficiente para que se le permita el acceso.
Resultado Esperado:
Primeramente, se validará el saldo necesario para ingresar posteriormente se realizará el registro de la zona en la cual ingreso el cliente y además se registrará el ID con el fin de validar de que este sea el mismo al salir.
Evaluación de la Prueba:
-------------------------------------------

  
ENTRAR
Responsabilidad
Colaborador

        ·         Validar que se cuente con el suficiente saldo
        ·         Registrar Zona de Acceso
        ·         Registrar ID
·         Salida






Historia de Usuario
Número: 30                           
Nombre: Historia de Usuario
Salir del suburbano.
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
------------------------
Usuario:
Cliente del suburbano
Iteración Asignada:
3
Prioridad en Negocio:
--------------------
Puntos Estimados:
10
Riesgo en Desarrollo:
(Alto / Medio / Bajo)

Puntos Reales:
-------------------------------------------.
Descripción:
Una vez terminado el viaje el cliente para salir de las instalaciones pasara su tarjeta por el lector.
Observaciones:
La tarjeta deberá de ser la misma con la que entro y según la distancia recorrida se le realizará el cargo a la tarjeta.





Tarea de Ingeniería
Número Tarea:
3
Historia de Usuario (Nro. y Nombre):
30, Salir del Suburbano.

Nombre Tarea: Salir del Suburbano.
Tipo de Tarea:
Desarrollo / Corrección / Mejora / Otra
Se elaborará el proceso para la ejecutar la salida del suburbano.
Puntos Estimados:
10
Fecha de Inicio:
08/03/2017
Fecha de culminación.
------------------------------

Programador Responsable:

·         Celaya Ordaz Marco Antonio
·         Peña Bustillos Jaime Víctor

Descripción:
Se desarrollará el modulo para la salida de las instalaciones del suburbano en donde el usuario pagará el viaje con su tarjeta y el costo de este dependerá de la distancia recorrida, es decir, si el intervalo de está fue de una zona o si fue de dos. Posteriormente el sistema verificará que el id de la tarjeta sea el mismo de la que uso para entrar, en caso contrario no se le permitirá la salida en los torniquetes.




Caso de Prueba de Aceptación
Código:
Salida
Historia de Usuario (Nro. y Nombre):
30, Salir del Suburbano
Nombre: Prueba del módulo salida
Descripción: Probar que se valide el ID de la tarjeta y que el cobro sea según la zona
Condiciones de Ejecución:

·         El usuario deberá de usar la misma tarjeta con la que entro

Entrada / Pasos de ejecución:
El usuario se deberá de dirigir a la salida del Suburbano en donde pasará por el lector la tarjeta que utilizo al entrar.
Resultado Esperado:
Se deberá de realizar el cobro según la distancia de traslado y se validará el ID con el fin de validar que la tarjeta con la que sale sea la misma que con la que entro.
Evaluación de la Prueba:
---------------------------------------------------------


SALIDA
Responsabilidad
Colaborador
      
       ·         Registrar zona de salida
       ·         Calcular costo del viaje
       ·         Validar ID
       ·         Mostrar saldo restante
·         Entrada






Historia de Usuario
Número: 40                           
Nombre: Historia de Usuario
Recargar Tarjeta
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
------------------------
Usuario:
Cliente del suburbano
Iteración Asignada:
4
Prioridad en Negocio:
--------------------
Puntos Estimados:
10
Riesgo en Desarrollo:
(Alto / Medio / Bajo)

Puntos Reales:
-------------------------------------------.
Descripción:
El cliente al solicitar una recarga se dirigirá al centro de recarga y depositara la cantidad requerida a su tarjeta
Observaciones:
El usuario deberá contar con una tarjeta para poder recargar y del caso contrario deberá adquirir una antes de poder recargar





Tarea de Ingeniería
Número Tarea:
4
Historia de Usuario (Nro. y Nombre):
40, Recargar Tarjeta.
Nombre Tarea: Recargar la Tarjeta.
Tipo de Tarea:
Desarrollo / Corrección / Mejora / Otra
Se elaborará el proceso para la ejecutar la recarga de la tarjeta.
Puntos Estimados:
10
Fecha de Inicio:
10/03/2017
Fecha de culminación.
------------------------------

Programador Responsable:

·         Celaya Ordaz Marco Antonio
·         Peña Bustillos Jaime Víctor

Descripción:
Se desarrollará el modulo para que el usuario pueda recargar la tarjeta del suburbano con la cantidad específica del costo de los viajes, el monto depositado dependerá del usuario y el sistema verificara la tarjeta y posteriormente se le recarga la cantidad indicada, si el usuario no cuenta con tarjeta deberá realizar la adquisición de esta.




Caso de Prueba de Aceptación
Código:
Recarga
Historia de Usuario (Nro. y Nombre):
40, Recarga de tarjeta
Nombre: Prueba del módulo recarga
Descripción: Se probará que se realice una recarga a la tarjeta.
Condiciones de Ejecución:

·         El usuario deberá de estar en una taquilla
·         El usuario deberá de poseer una tarjeta

Entrada / Pasos de ejecución:
El usuario se dirigirá a una taquilla, una vez ahí, pedirá una recarga según el saldo que este quiera abonar, posteriormente pagará por esta.
Resultado Esperado:
Se realizará la recarga a la tarjeta, según el monto pagado por el usuario.
Evaluación de la Prueba:
--------------------------------------------------------------
  

RECARGA DE TARJETA
Responsabilidad
Colaborador
       ·         Mostrar Saldo actual
       ·         Modificar Saldo de la tarjeta.
       ·         Mostrar saldo total







Historia de Usuario
Número: 50                           
Nombre: Venta de Boletos
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
10 , Venta de tarjeta dependiendo la distancia a recorrer por el usuario
Usuario:
Cliente
Iteración Asignada:
5
Prioridad en Negocio:
(Alta / Media / Baja)
Puntos Estimados:
10
Riesgo en Desarrollo:
(Alto / Medio / Bajo).
Puntos Reales:
-----------------------
Descripción:
El cliente al requerir un boleto para ingresar al tren deberá acudir a la taquilla y pagar el importe por la cantidad requerida
Observaciones:
El costo del boleto diferirá dependiendo del trayecto del viaje

  

Tarea de Ingeniería
Número Tarea:
5
Historia de Usuario (Nro. y Nombre):
50 ,  Venta de boletos.
Nombre Tarea: Venta de boletos.
Tipo de Tarea:
Desarrollo / Corrección / Mejora / Otra (especificar)
Se desarrollará un proceso por el cual el cliente podrá adquirir boletos para ingresar al tren.
Puntos Estimados:

10
Fecha de Inicio:
En qué momento da inicio la actividad.
Fecha de culminación.
---------------------------

Programador Responsable:

·         Celaya Ordaz Marco Antonio
·         Peña Bustillos Jaime Víctor

Descripción:
Se elaborará un módulo del sistema en el cual el usuario pueda comprar boletos para poder entrar a las instalaciones y dependiendo de la distancia a recorrer el boleto tendrá un costo diferente, este módulo será anexado al de venta de tarjetas.

  
Caso de Prueba de Aceptación
Código:
Venta de Boletos
Historia de Usuario (Nro. y Nombre):
50, venta de boletos
Nombre: Prueba del módulo venta de boletos
Descripción: Probar que los boletos funcionen según el trayecto del viaje.
Condiciones de Ejecución:

·         El usuario debe de ubicarse en una taquilla
·         El usuario debe de contar con el dinero suficiente para la compra de un boleto

Entrada / Pasos de ejecución:
Una vez ubicado el usuario en la taquilla, este pedirá un boleto, el usuario deberá tomar en consideración la distancia que viajará para pedir el boleto indicado.
Resultado Esperado:
Se otorga al usuario un boleto según sea el trayecto a viajar.
Evaluación de la Prueba:
------------------------------------------------


VENTA DE BOLETOS
Responsabilidad
Colaborador
·         Registrar cada boleto con un id diferente
·         Asignarle un valor a cada boleto
·         Venta de Tarjetas