Actividades: Ciclo de vida del software

1. Define "Ciclo de vida del software"

El ciclo de vida del desarrollo de software es la estructura que contiene los procesos, actividades y tareas relacionadas con el desarrollo y mantenimiento de un producto de software, abarcando la vida completa del sistema, desde la definición de los requisitos hasta la finalización de su uso.

2) Nombra las fases principales del desarrollo de software y explica brevemente qué se hace en cada una de ellas.

• Planificación: Antes de iniciar un proyecto de desarrollo de un sistema de información, es necesario hacer ciertas tareas que influirán decisivamente en el éxito del mismo. Dichas tareas no están sujetas a plazos. Algunas de las tareas incluyen actividades como la determinación del ámbito del proyecto, la realización de un estudio de viabilidad, el análisis de los riesgos asociados, la estimación del coste del proyecto, su planificación temporal y la asignación de recursos a las diferentes etapas del proyecto.

• Análisis: Hay que averiguar qué es exactamente lo que tiene que hacer el software. Esta etapa corresponde al proceso a través del cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer).

• Diseño: En esta fase se estudian posibles opciones de implementación para el software que hay que construir, así como decidir la estructura general del mismo. El diseño es una etapa compleja y su proceso debe realizarse de manera iterativa.

• Implementación: En esta fase hay que elegir las herramientas adecuadas, un entorno de desarrollo que facilite el trabajo y un lenguaje de programación apropiado para el tipo de software a construir. Esta elección dependerá tanto de las decisiones de diseño tomadas como del entorno en el que el software deba funcionar.

• Pruebas: La fase de pruebas busca detectar los fallos cometidos en las etapas anteriores para corregirlos. Por supuesto, lo ideal es hacerlo antes de que el usuario final se los encuentre. Se dice que una prueba es un éxito si se detecta algún error.

• Instalación: La siguiente fase es poner el software en funcionamiento, por lo que hay que planificar el entorno teniendo en cuenta las dependencias existentes entre los diferentes componentes del mismo.

• Uso y mantenimiento: Esta es una de las fases más importantes del ciclo de vida de desarrollo del software. Puesto que el software ni se rompe ni se desgasta con el uso, su mantenimiento incluye tres puntos diferenciados:

-Eliminar los defectos detectados durante su vida útil (mantenimiento correctivo).

-Adaptarlo a nuevas necesidades (mantenimiento adaptativo).

-Añadirle nuevas funcionalidades (mantenimiento perfectivo).

3) Explica brevemente en qué consiste el modelo en cascada cuando hablamos de desarrollo de software.

El desarrollo en cascada es un procedimiento lineal que se caracteriza por dividir los procesos de desarrollo en sucesivas fases de proyecto. Al contrario que en los modelos iterativos, cada una de estas fases se ejecuta tan solo una vez. Los resultados de cada una de las fases sirven como hipótesis de partida para la siguiente. Este procedimiento se utiliza, especialmente, en el desarrollo de software.

4) Ventajas e inconvenientes del modelo en cascada.

Ventajas:
-Una estructura sencilla gracias a unas fases de proyecto claramente diferenciadas.
-Buena documentación del proceso de desarrollo a través de unos hitos bien definidos.
-Los costes y la carga de trabajo se pueden estimar al comenzar el proyecto.
-Aquellos proyectos que se estructuran en base al modelo en cascada se pueden representar cronológicamente de forma sencilla.

Inconvenientes:
-Por norma general, los proyectos más complejos o de varios niveles no permiten su división en fases de proyecto claramente diferenciadas.
-Poco margen para realizar ajustes a lo largo del proyecto debido a un cambio en las exigencias.
-El usuario final no se integra en el proceso de producción hasta que no termina la programación.
-En ocasiones, los fallos solo se detectan una vez finalizado el proceso de desarrollo.

5) ¿Qué se entiende por verificación? ¿Y por validación?

-La verificación de software es una disciplina de la ingeniería de software cuyo objetivo es asegurar que el software satisface por completo todos los requisitos esperados.

-La validación de software es un proceso que demuestra a partir de documentos que el sistema cumple con las funciones de las cuales fue designado, de acuerdo con las especificaciones de los requisitos del usuario y con la garantía de seguridad y trazabilidad de informaciones.

6) Explica cómo funciona el modelo de desarrollo mediante creación de prototipos.

  Un modelo prototipo o modelo de desarrollo evolutivo es utilizado principalmente en el desarrollo de software para ofrecer al usuario una visión previa de cómo será el programa o sistema. Se le dice de desarrollo evolutivo al modelo de prototipo porque evoluciona hasta convertirse en el producto final.El modelo de prototipos se centra en un diseño rápido que representa las características principales del programa que el usuario podrá ver o utilizar. De esta manera pueden probarlo y dar su opinión sobre distintos aspectos como la usabilidad, la utilidad o el rendimiento, entre otras.El prototipo se puede modificar cuando sea necesario y todos los resultados obtenidos de las presentaciones y pruebas se deben anotar para utilizar posteriormente como ayuda en el desarrollo del producto final.

## Actividades: Kanban y Scrum

1) Haz un resumen de la metodología Kanban e indica sus diferencias frente a SCRUM.

Kanban es una forma de ayudar a los equipos a encontrar un equilibrio entre el trabajo que necesitan hacer y la disponibilidad de cada miembro del equipo. La metodología Kanban se basa en una filosofía centrada en la mejora continua, donde las tareas se “extraen” de una lista de acciones pendientes en un flujo de trabajo constante. La metodología Kanban se implementa por medio de tableros Kanban. Se trata de un método visual de gestión de proyectos que permite a los equipos visualizar sus flujos de trabajo y la carga de trabajo. En un tablero Kanban, el trabajo se muestra en un proyecto en forma de tablero organizado por columnas. Tradicionalmente, cada columna representa una etapa del trabajo.

• Scrum es más estricto que Kanban. Este marco incluye un conjunto específico de reglas que los equipos deben seguir, mientras que Kanban se usa más para visualizar el trabajo. Muchos equipos implementan Scrum en un tablero Kanban, pero en esos casos, la metodología sigue siendo Scrum, no Kanban. Esta última, más que una metodología estricta, es una forma de visualizar el trabajo.
• Scrum tiene un límite de tiempo, Kanban es flexible. Scrum se ejecuta en sprints, que suelen ser ciclos de trabajo de dos semanas. Al final de un sprint, tienes un conjunto de tareas terminadas, sin importar cuáles sean. Los tableros Kanban no necesariamente tienen una fecha de inicio o finalización. De hecho a menudo se usan tableros Kanban para visualizar procesos en curso.
• Las columnas del tablero Kanban se pueden organizar de diferentes formas. Cuando implementas un Scrum, es importante realizar un seguimiento del trabajo a medida que avanzas por las diferentes etapas. Sin embargo, en un tablero Kanban que no se basa en Scrum, las columnas pueden representar diferentes aspectos, no solo el estado; como, por ejemplo, el trabajo que se realizará cada mes, una retrospectiva que identifica las tareas que se completaron anteriormente, o cualquier otra cosa que necesites. En esto se diferencia de las reglas más definidas de Scrum.

2) Explica cómo funciona SCRUM.

• Planificación del sprint: Estos suelen durar dos semanas, aunque los equipos pueden realizar sprints más rápidos o breves. Durante esta etapa, el Scrum Master y el equipo analizan el trabajo pendiente y determinan qué tareas realizar durante el Sprint.
• Reuniones diarias de actualización: Durante el transcurso del Scrum (también conocido como el “ciclo” de Scrum), los equipos suelen reunirse durante 15 minutos todos los días para hablar sobre el progreso y asegurarse de que la cantidad de trabajo asignado sea la adecuada.
• Análisis retrospectivo del sprint: Cuando finaliza el proceso, el Scrum Master organiza una reunión retrospectiva del sprint para evaluar qué trabajo se realizó, agregar cualquier tarea incompleta a la lista de trabajo pendiente y prepararse para el siguiente sprint.

3) Define los siguientes términos:

-Product backlog: El Product backlog (o pila de producto) es un listado de todas las tareas que se pretenden hacer durante el desarrollo de un proyecto. Todas las tareas deben listarse en el Product backlog, para que estén visibles ante todo el equipo y se pueda tener una visión panorámica de todo lo que se espera realizar.

-Sprint backlog: El Sprint backlog es la suma del objetivo del sprint, los elementos del Product backlog elegidos para el sprint, más un plan de acción de cómo crear el incremento de producto. Es uno de los 3 artefactos de Scrum y se construye durante el evento del Sprint Planning. Es un plan realizado por y para los Developers.

4) En la terminología Scrum qué términos se utilizan como sinónimo de:

• Jefe de proyecto: Scrum Master
• Cliente: Stakeholder
• Equipo de desarrollo: Scrum Team

5) Haz un resumen de los requisitos para poder utilizar Scrum.

• Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.
• Compromiso del cliente en la dirección de los resultados del proyecto, gestión del ROI y disponibilidad para poder colaborar.
• Compromiso de la dirección de la organización para resolver problemas endémicos y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación llevada a cabo por líderes al servicio del equipo.
• Compromiso conjunto y colaboración de los miembros del equipo.
• Relación entre proveedor y cliente basada en ganar-ganar, colaboración y transparencia.
• Facilidad para realizar cambios en el proyecto.
• Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas de planificación y coordinación cuando varios equipos trabajan en el mismo proyecto).
• Equipo trabajando en un mismoespacio c para maximizar la comunicación.
• Dedicación del equipo a tiempo completo.
• Estabilidad de los miembros del equipo.

6) Explica los 5 valores de la Programación Extrema.

• Comunicación: Como comunicación entendemos no solo una buena interacción interna entre los propios miembros del equipo de desarrolladores, sino también con los clientes. El objetivo es romper las barreras entre negocio y desarrollo. Para ello, la programación XP promueve que todos los requisitos sean comunicados y trabajados con el equipo y no mediante documentación.
• Simplicidad: Empezar con la solución más simple es clave en la programación XP. Esta metodología pone el foco en codificar las necesidades de hoy, no las de un futuro. Además, también se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Para conservar la simplicidad hay que mantener la refactorización del código, así podremos preservar el código simple a medida que va creciendo.
• Feedback: Una de las mayores ventajas de que el cliente esté integrado en el proyecto es que su opinión sobre el estado de este lo podemos conocer en tiempo real. Gracias a que se hacen ciclos muy cortos de presentación de resultados, se minimiza el riesgo de tener que rehacer partes que no cumplen con las expectativas del cliente. También, por otro lado, ayuda a los programadores a centrarse en las tareas más importantes.
• Respeto: El respeto mutuo es fundamental para que un equipo pueda trabajar de forma eficiente y ofrecer un buen rendimiento. Implica desde que un desarrollador no realice modificaciones que puedan tener un impacto negativo en el trabajo de un compañero hasta la forma de llegar al cliente. El respeto se manifiesta de varias formas y todas son cruciales para una mejor autoestima en el equipo, que lleva consigo un mayor ritmo de producción.
• Valentía: Diseñar y programar para hoy y no para mañana implica valentía en la metodología XP, así como reconocer los errores tan pronto como se detecten. Ningún miembro del equipo puede perder el tiempo en intentar hacer de menos su responsabilidad en un error cometido, ya que esto significa dejar de centrarse en otras cosas e impedirá avanzar al resto, por lo que la productividad bajará.

7) ¿Cuáles son las características distintivas de XP frente a otras metodologías ágiles? Explícalas.

• El juego de la planificación. Es un permanente diálogo entre las partes empresarial (deseable) y técnica (posible).
• Pequeñas entregas. Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión.
• Planifica para 1 mes o 2, en lugar que para seis meses o un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.
• Metáfora. Una metáfora es una historia que todo el mundo puede contar acerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas «Programa de gestión de compras, ventas, con gestión de cartera y almacén». Las metáforas ayudan a cualquier persona a entender el objeto del programa.
• Diseño sencillo. 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 (refactoring). Esto a veces nos puede llevar a hacer mas 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 cuando el sistema te lo pida.
• 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 es un programa más seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
• Refactorizació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 (refactoring). 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 cuando el sistema te lo pida.
• 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 más 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, puede 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.

• Propiedad colectiva. Cualquiera 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 paraque lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un 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.

• Integración continua. El 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% cuarenta horas semanales . Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.

• Cliente en casa. 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.
• Estándares de codificación. Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.