TARJETA DEL METRO ARTEFACTOS XP

Historia de Usuario
Número: 1	Nombre Historia de Usuario: Venta de tarjeta del metro
Modificación (o extensión) de Historia de Usuario (Nro. y Nombre): Sin modificaciones actuales.
Usuario: Personas que usan el tren como medio de transporte		Iteración Asignada: 1
Prioridad  en Negocio:  Alta		Puntos Estimados: 168 horas
Riesgo en Desarrollo: Medio		Puntos Reales: No establecidos aún.
Descripción: Se requiere que a través del uso de una tarjeta se le pueda cobrar al usuario cierta cantidad en función de la distancia recorrida. El mapa de metro está dividido en tres zonas diferentes.
Observaciones: El usuario deberá pasar su tarjeta en un lector tanto para  su abordaje como  para su salida de las instalaciones del metro y de este modo calcular el cobro correspondiente.

Caso de Prueba de Aceptación
Código: 1	Historia de Usuario (Nro. y Nombre):              Venta de tarjeta del metro.
Nombre: Condiciones para el cobro de la tarifa.
Descripción: La tarjeta cobrará cierta tarifa al usuario según la distancia recorrida
Condiciones de Ejecución: La tarjeta debe estar registrada con un código único.
Entrada / Pasos de ejecución: En el mapa existen tres zonas diferentes y de estas dependerá el cobro.    Si el usuario desde su punto de partida hasta su descenso estuvo en la misma zona se le cobrara la tarifa 1  Si el usuario desde su punto de partida hasta su descenso recorre una zona (Ejemplo: De la zona 1 a la zona 2) se le cobrará la tarifa 2.  Si el usuario desde su punto de partida hasta su descenso recorre dos zonas (Ejemplo: De la zona 1 a la zona 3) se le cobrará la tarifa 3.
Resultado Esperado: Cobro realizado con éxito.
Evaluación de la Prueba: Aceptada

Tarea de Ingeniería
Número Tarea: 1	Historia de Usuario (Nro. y Nombre):            Venta de tarjeta del metro.
Nombre Tarea: Registro de tarjeta
Tipo de Tarea : Desarrollo		Puntos Estimados: 72 horas
Fecha de Inicio: 8 de Marzo 2017		Fecha de culminación. 11 de Marzo 2017
Programador Responsable: Sandra Erika  Suárez Porras
Descripción: Basándonos en el análisis de cómo funcionara la tarjeta se debe establece una manera de asegurar que la tarjeta no puede ser clonada, haciendo uso de un código para cada tarjeta y de esta forma asegurar que sea diferente para cada usuario.

Tarjeta CRC
Tarjeta Electrónica
Analizar el funcionamiento de los torniquetes por los cuales se hará el cobro de la tarifa correspondiente Validar que el usuario active la tarjeta para poder hacer uso de ella. Probar que funcione.	Programador Cajero Usuario del metro. Gestor

SISTEMAS SOCIO-TÉCNICOS. DEFINICIONES

Al hablar de sistemas nos referimos a la colección de componentes interrelacionados que trabajan en conjunto para un objetivo.

PROPIEDADES EMERGENTES DE LOS SISTEMAS

Son propiedades que surgen cuando el sistema ya esta funcionando es por eso que no se pueden atribuir a ninguna parte especifica del sistema. Existen 2 tipos de propiedades emergentes:

1. Funcionales: Aparecen cuando todas las partes de un sistema trabajan de forma conjunta para cumplir algún objetivo.
2. No funcionales: Comportamiento del sistema de acuerdo al entorno operativo en el que se encuentren Ejemplo: Seguridad, fiabilidad, rendimiento y protección.

Ejemplos de propiedades emergentes:

• Fiabilidad:                                                                                           

1. Hardware: Se refiere a que este funcionando y no se caiga. Ej. que tenga n procesadores, sistemas distribuidos, entre otras cosas. 
2.  Software: No debe presentar errores y si llegan a surgir estos deben reportarse.
3. Operadores: Se debe contar con un personal capaz

• Volumen: ¿Qué tanto tendrá el sistema? Es el espacio total que ocupara el sistema dependiendo de como se hayan montado los componentes.
• Protección: ¿Qué tan protegido el sistema en cuanto a los datos? Capacidad para resistir ataques.
• Reparabilidad: ¿Qué tan fácil se puede hacer el mantenimiento correctivo? Depende de la posibilidad de diagnosticar el problema, acceder a los componentes así como la modificación de estos.
• Usabilidad: ¿Qué tan fácil es usar el sistema? Dependerá de los componentes técnicos del sistema, sus operadores y del entorno.

EVOLUCIÓN DE UN SISTEMA

Durante el período del vida del software este se cambia para incluir nuevos requerimientos o simplemente para corregir errores en los requerimientos del sistema original.
De una forma  general puede decirse que la evolución del sistema se refiere a que tan fácil se adecua el sistema a los cambios pues si este no tiene una gran capacidad para hacerlo puede terminar como un sistema heredado.


DESMANTELAMIENTO DE UN SISTEMA

Significa poner fuera de servicio a un sistema después de que termina su periodo de utilidad operativa. Para sistemas hardware eso puede significar el desmontaje o reciclaje de materiales mientras que el software no tiene problemas físico de desmantelamiento pero si puede ser incorporado en otro software para ayudar al proceso de desmantelamiento.


ORGANIZACIONES, PERSONAS Y SISTEMAS INFORMÁTICOS 

Debido a que los sistemas socio-técnicos están dentro de un entorno organizacional pueden ser influenciados por las políticas y procedimientos de la organización y por su cultura de trabajo.
Del mismo modo  los usuarios están influenciados por la manera en que esta gestionada la organización así como las relaciones dentro y fuera de esta.

Factores humanos y organizacionales del entorno del sistema que afectan el diseño son:

1. Cambios en el proceso: ¿El sistema requiere cambios  los procesos en el entorno?
2. Cambios en el trabajo: Se refiere a si el sistema cambia la forma de trabajar de los usuarios debido a los sistemas informáticos.
3. Cambios organizacionales: Se refiere a cuando el sistema cambia la estructura de poder a una organización debido a que el sistema cambia y solo los que conozcan como operarlo correctamente son los que tienen el poder

PROCESOS ORGANIZACIONALES: 

¿De qué modo voy a  aprovechar los sistemas de información para implementarlos en mi empresa?

Se debe evaluar qué es mas caro y qué conviene mas, si comprar un software o desarrollarlo

SISTEMAS HEREDADOS

Son sistemas socio-técnicos que han sido desarrollados en el pasado a menudo con tecnología antigua y obsoleta. Estos sistemas no solo incluyen software y hardware sino también procesos y procedimientos heredados, es por eso que el querer cambiar un sistema heredado es algo riesgoso pues implicaría cambios en otros componentes y un alto costo.

SISTEMAS SOCIO-TÉCNICOS

Son sistemas empresariales con la intención de ayudar a conseguir objetivos organizacionales del negocio
un ejemplo de ello sería las ventas por la Web como lo hace WALMART donde puede garantizar seguridad al cliente

Las características con las que debe contar un sistema socio-técnico es que

• Cuente con propiedades emergentes
• No determinista, es decir que cuenta con una entrada especifica que no produce la misma salida.El comportamiento del sistema dependerá de operadores humanos
• El apoyo del sistema a los objetivos organizacionales dependerá de la estabilidad de los objetivos así como las relaciones y conflictos existentes en dichos objetivos. 

"Sistemas socio-técnicos" extraído el 3 de Marzo 2017 de la fuente:

Sommerville, I.. (2005). Sistemas socio-técnicos. En Ingeniería del Software(pp.20-38). Madrid: Pearson Educación.

Vazquez, E.. (2008). Procesos Organizacionales. Marzo 3, 2017, del Sitio web: http://www.academia.edu/9125868/PROCESOS_ORGANIZACIONALES

Sistemas Heredados. Marzo 3, 2017, del Sitio web: http://cursos.aiu.edu/REINGENIER%C3%8DA%20EN%20SISTEMAS/8/PDF/Reingenieria%20de%20sistemas%20sesion%208.pdf

ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

El ciclo de vida del software incluye varias etapas las cuales son  

1. Inicio o Planeación
2. Análisis
3. Diseño 
4. Desarrollo
5. Pruebas
6. Puesta en punto
7. Entrega

Pero nos enfocaremos solo a 2, las cuales van a ser Inicio o Planeación y a la etapa de Análisis.

En la etapa de Inicio empiezan por definirse las actividades que va a hacer cada persona así como el tiempo estimado que se tiene para la realización de esa actividad, los costos, los posibles caminos a tomar, entre otras cosas. Para eso se elaboran los siguientes documentos que se explicaran a continuación:

Documento	Responsable	Descripción
Cronograma de Actividades	Administrador/Gerente del Proyecto	En este documento se definen las actividades que se van a realizar, indicando la fecha de inicio y fin, así como el responsable de realizar dicha actividad además de que permite realizar un seguimiento al progreso del proyecto
Ruta Crítica	Administrador/Gerente del Proyecto	Es un proceso administrativo (planeación, organización, dirección y control) por el que se muestran todas  y cada una de las actividades componentes de un proyecto que se deben desarrollarse durante un tiempo crítico y al costo óptimo.
Gantt	Administrador/Gerente del Proyecto	Es una herramienta que le permite al usuario modelar la planificación de las tareas necesarias para la realización de un proyecto. A diferencia del cronograma de actividades en este documento se puede representar de manera gráfica el progreso del proyecto y ver que tareas faltan por realizar

Por su parte en la etapa de Análisis primeramente se debe preguntar a la empresa cual es el proceso de negocio, ¿como hacen las cosas?, claro que si no lo obtenemos pues tendremos que definirlo nosotros mismos. Después en base al proceso de negocio empieza por elaborarse el documento de requerimientos que es donde se describirán las funciones que tendrá el sistema así como establecer las restricciones que se puedan aplicar.

Documento	Responsable	Descripción
Documento de Requerimientos	Analista  de requerimientos	Se describen las funcionalidades que va a tener el proyecto pero estas se dividen en tres apartados  Funcionales: Se refiere a lo que hará el sistema, como va a funcionar cada modulo No funcionales: Son las características Inherentes al sistema, es decir, son esenciales pero dependerá de cada proyecto. Se resumen en tres palabras Definición- métrica-compromisos De Sistema: Aquí se definen las características que debe tener el hardware y software para que funcione el sistema, especificando para el cliente, servidor y Móvil.
Casos de Uso	Analista  de Requerimientos	Es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.  En base a eso se hace la especificación de casos de uso que son las posibles funciones que puede tener el sistema según navegue el usuario.

“Ruta Crítica” extraído el 25 de Febrero 2017 desde la fuente: https://erods.files.wordpress.com/2012/02/ruta-critica.pdf

“El cronograma de actividades: herramienta clave en project management” extraído el 25 de Febrero 2017 desde la fuente: http://www.obs-edu.com/int/blog-project-management/herramientas-esenciales-de-un-project-manager/el-cronograma-de-actividades-herramienta-clave-en-project-management

“Diagrama de GANTT” extraído el 25 de Febrero 2017 desde la fuente: http://es.ccm.net/contents/580-diagrama-de-gantt

“Caso de Uso” extraído el 25 de Febrero 2017 desde la fuente: https://es.wikipedia.org/wiki/Caso_de_uso

¿XP (Extreme Programming) VS SCRUM?

Metodologías ágiles

Las metodologías ágiles son una serie de técnicas, herramientas y procedimientos  en el desarrollo de software, las cuales surgieron como respuesta para los desarrolladores de software que buscaban implementar nuevos sistemas de información así como para los negocios pequeños los cuales tenían problema al usar las metodologías tradicionales pues terminaban centrándose más en la documentación que en la propia construcción del software.

Existen varias metodologías ágiles pero hablaremos principalmente de 2:

¿XP (Extreme Programming) VS SCRUM?

Extreme Programming (XP) ó Programación Extrema:

Se centra en las relaciones interpersonales como el éxito en el desarrollo de software. Se basa en la realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, que se entreguen trabajos de calidad, la simplicidad en las soluciones que se estén implementando  así como la aceptación del cambio.

Principalmente se preocupa por la entrega de software en lapsos de tiempo menores y con reducidos costos pero incluyendo una buena calidad dejando de lado la exhaustiva  definición de requerimientos así como la producción de una extensa documentación.

Algunas de las prácticas de XP son:

• Juego de la planificación
• Pequeñas entregas
• Diseño simple
• Pruebas
• Programación por parejas
• Integración continua
• Estándares de codificación
• Propiedad colectiva

ROLES	DESCRIPCIÓN
Cliente	Se encarga de escribir las historias de Usuario y las pruebas funcionales para validar su implementación
Programador	Escribe las pruebas unitarias y produce el código del sistema.
Encargado de Pruebas (TESTER)	Ayuda a escribir las pruebas funcionales, ejecuta las pruebas y se encarga de dar a conocer los resultados a los demás miembros del equipo.
Encargado de seguimiento (Tracker)	Da realimentación al equipo además de que lleva un seguimiento de cada iteración que se hace
Entrenador (COACH) O Tutor	Es responsable del equipo y verifica que se apliquen las prácticas de XP Ayuda en todo
Gestor(BIG BOSS)	Se encarga de coordinar de modo que entre el cliente y el equipo trabajen de forma adecuada
ARTEFACTOS	DESCRIPCIÓN
Historias de Usuarios	Breve descripción del comportamiento del sistema. Se realiza una por cada funcionalidad que se quiera.
Tareas de Ingeniería	Describe las actividades o tareas que realizara un programador conforme a las historias de Usuario. Se debe incluir el nombre y el número de historia a la que pertenece, los puntos a realizar para terminar la tarea, el nombre del responsable, fechas, etc.
Tarjetas CRC Clase-Responsabilidad-Colaborador	Es una representación en tarjetas de cartón o de papel en donde se muestra el nombre de las clases, los métodos de esta y el nombre de las clases con las que colabora.

PROCESO:

SCRUM

Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Esta especialmente diseñada para proyectos con requisitos que suelen cambiarse de manera rápida. Se caracteriza por realizar el desarrollo de software mediante iteraciones denominadas sprints así como las reuniones a lo largo del proyecto para la coordinación e integración del trabajo.

También se utiliza cuando no se entrega al cliente lo que necesita en tiempo y forma así como cuando los costes se disparan o la calidad no es la que se esperaba

ROLES	DESCRIPCIÓN
Cliente (Product Owner)	Define las funcionalidades del proyecto así como las ordena en orden de importancia junto con cada iteración
Facilitador (Scrum Master)	Representa la gestión del proyecto además de que se encarga de vigilar que el equipo trabaje de forma productiva así como la existencia de la cooperación entre todos los roles
Equipo (Team)	Típicamente de 5 a 9 personas, deben ser auto-organizados y solo puede existir un cambio de  miembros entre los sprints.
ARTEFACTOS	DESCRIPCIÓN
Lista de requisitos priorizada (Product Backlog)	Una lista de todos los trabajos que se deseen en el proyecto, esta es priorizada por el product owner.
Lista de tareas de la iteración (Sprint Backlog)	Es la lista de tareas que el equipo hace en las reuniones para la p0lanificaciópn de cada iteración con el objetivo de completar los requisitos seleccionados para la iteración. La lista permite ver las tareas en donde se esta teniendo problemas.
Gráficos de trabajo pendiente (Burndown Chart)	Muestra la velocidad a la que se está completando los objetivos/requisitos. Y así estimar si el Equipo podrá completar el trabajo en el tiempo requerido, si se quitan requerimientos o se necesita otro equipo.

PROCESO

Actividades:    

• Planificación de la iteración (Sprint Planning) El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar y Se crea el Sprint Backlog
• Ejecución de la iteración (Sprint)
• Reunión diaria de sincronización del equipo (Scrum Daily Meeting) Reunión Diaria entre el equipo que dura aproximadamente 15 minutos con el fin de coordinar.
• Demostración de los requisitos completados (Sprint Review) Se presenta lo que se ha realizado durante el sprint
• Retrospectiva (Sprint Retrospective) Participa todo el equipo y se revisa lo que funciona o no, dura normalmente de 15 a 30 minutos
• Refinamiento de la lista de requisitos y cambios en el proyecto

	Programación Extrema XP	Scrum
Roles	Cliente         Programador         Encargado de Pruebas (TESTER)         Encargado de seguimiento (Tracker)         Entrenador (COACH) o Tutor         Gestor(BIG BOSS)	Cliente (Product Owner)  Facilitador (Scrum Master) Equipo (Team)
Artefactos	Historias de Usuarios Tareas de Ingeniería Tarjetas CRC Clase-Responsabilidad-Colaborador	Lista de requisitos priorizada (Product Backlog)  Lista de tareas de la iteración (Sprint Backlog)  Gráficos de trabajo pendiente (Burndown Chart)
	Programación por parejas	Programación Individual
	Creación del Producto, programación.	Se basa más en la administración del Producto
	Pruebas	Funcionalidad

Conociendo los aspecto más importantes tanto de la programación extrema como de Scrum podemos concluir que Scrum es más formal puesto que  se va haciendo la documentación para definir los requerimientos de modo que se puedan ir elaborando los sprint  y se centra más en la funcionalidad del sistema, va más orientado a lo que viene siendo la administración del proyecto además de que durante el proceso aunque se tata de seguir el orden de las iteraciones según como las priorizó el Product owner, si el equipo de trabajo se da cuenta que es mejor modificar el orden lo harán para avanzar en el proyecto   mientras que en XP se enfoca más en las pruebas sobre el programa para así ver que es lo que falta, si funciona como se esperaba, se orienta más a la creación del producto y sigue estrictamente el orden que haya elegido el cliente, pues él es el que manda.

Otra diferencia es que en Scrum los miembros del equipo trabajan individualmente mientras que en XP se trabaja la programación por parejas pero aun así la metodología que se use dependerá del proyecto que se esté trabajando pues se tiene que establecer la metodología que se adecue más.

“¿Qué es Scrum?” extraído el 25 de Febrero de 2017 desde la fuente https://proyectosagiles.org/que-es-scrum/

Espinoza, S. (2007) Ingeniería de Software. Programación Extrema [Diapositivas PowerPoint]  Febrero 24, 2017 Sitio Web: https://es.slideshare.net/edgarespinoza/programacion-extrema

Grafeuille, E. (2008) Una Introducción a Scrum [Diapositivas PowerPoint] Febrero 25, 2017 Sitio Web: https://www.mountaingoatsoftware.com/.../Spanish-Redistributable-Intro-Scrum.ppt

Letelier, P., Sánchez,E.. (2003). Metodologías Ágiles en el Desarrollo de Software. [PDF File] Febrero 25, 2017, de Grupo ISSI Sitio web: http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf