Actividad 6: Fase de Análisis de Requerimientos.

En la fase de Análisis de Requerimientos o también conocida como Especificación de Requerimientos de Software (ERS) es, tal como lo indica su nombre, un conjunto de recomendaciones para la especificación de los requerimientos o requisitos de software el cuál tiene como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas.

Para realizar esta fase es necesario:
-Definir con los interesados en el proyecto los límites y requerimientos del mismo, y toda la información necesaria.
-Realizar el documento con toda la información recolectada. Siguiendo los pases de la siguiente plantilla:
     1 Introducción
       1.1 Propósito
       1.2 Ámbito del Sistema
       1.3 Definiciones, Acrónimos y Abreviaturas
       1.4 Referencias
       1.5 Visión general del documento
     2 Descripción General
       2.1 Perspectiva del Producto
       2.2 Funciones del Producto
       2.3 Características de los usuarios
       2.4 Restricciones
       2.5 Suposiciones y Dependencias
       2.6 Requisitos Futuros
     3 Requisitos Específicos
       3.1 Interfaces Externas
       3.2 Funciones
       3.3 Requisitos de Rendimiento
       3.4 Restricciones de Diseño
       3.5 Atributos del Sistema
       3.6 Requisitos No Funcionales
     4 Apéndices.

-Si se generan dudas, es necesario realizar otra reunión con los interesados del proyecto.

Prácticas recomendadas para una buena ERS:

Las características de una buena ERS son definidas por el estándar IEEE 830-1998.Una buena ERS debe ser:
Completa: Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas.
Consistente: Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
Inequívoca: La redacción debe ser clara de modo que no se pueda mal interpretar.
Correcta: El software debe cumplir con los requisitos de la especificación.
Trazable: Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
Priorizable: Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
Modificable: Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable.
Verificable: Debe existir un método finito sin costo para poder probarlo.

Los distintos tipos de requisitos que debe cumplir una buena ERS se pueden describir de la siguiente manera:

Requisitos de Usuarios: Las cuales son las necesidades que los usuarios expresan verbalmente.
Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas.
Requisitos Funcionales: Son los servicios que el sistema debe cumplir para el usuario.
Requisitos no funcionales: Son aquellas restricciones que afectan al sistema.

Actividad 5: Fase de planificación de proyecto en base a SCRUM.

De acuerdo con el KLC, en la fase de planificación de un proyecto se aborda la definición y el alcance del proyecto de almacenamiento de datos. Ademas, se incluye la evaluación de los resultados esperados y la justificación del proceso de negocio.

Para nuestro caso, el proyecto de Servicio Comunitario se utilizara la metodología SCRUM debido a que es un método ágil, y esta estructurado de forma que el desarrollo del proyecto sea en ciclos de trabajo.

La metodología SCRUM es un conjunto de buenas practicas que permite abordar proyectos complejos, desarrollados en entornos dinámicos y que varían en el tiempo, de una manera flexible. Esta metodología esta basada en entregas parciales y regulares del producto final en base al valor que ofrecen a los clientes.
Esta metodología es una opción de gestión ideal para acometer proyectos desarrollados en entornos que exigen rapidez en sus resultados y en los que es imprescindible la flexibilidad de desarrollo.

En esta metodologia intervienen 4 roles:

-Product Owner: representa la voz del cliente y del resto de interesados no implicados directamente en el proyecto. Este perfil es el encargado de definir los objetivos del proyecto y de garantizar que el equipo trabaja del modo adecuado para alcanzar dichos objetivos.

-Scrum Master: es el encargado de asegurar que el resto del equipo no tiene problemas para abordar sus funciones y tareas. Guía y ayuda al Scrum Team para garantizar el cumplimiento de objetivos. En otras palabras, este perfil ayuda al equipo a mantenerse activo y productivo.

-Scrum Team: es el equipo encargado de desarrollar y entregar el producto. Su trabajo es imprescindible: estamos hablando de una estructura horizontal auto-organizada capaz de auto-gestionarse a sí misma.

-Stakeholders: Este grupo comprende aquellos perfiles interesados en el producto: directores, dueños, comerciales. Se trata de perfiles que si bien no forman parte del Scrum Team deben ser tenidos en cuenta.

En Scrum se indican claramente las acciones a acometer y como acometerlas.

Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar, tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo. Las acciones fundamentales de Scrum son:

-Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar y actualizado y mantenido por el Product Owner.

-Sprint Backlog la cual corresponde con una o más tareas que provienen del Product Backlog. Es decir, del Product Backlog se saca una o más tareas que van a formar parte del Sprint Backlog. Las tareas del Sprint Backlog se deben acometer en unas 2 semanas ó 4 semanas.  Eso debe de ser marcado antes de iniciar el Sprint Backlog. Se debe tomar en cuenta que, mientras un Sprint Backlog se inicia, éste NO puede ser alterado o modificado. Hay que esperar a que concluya el Sprint Backlog para realizar la correspondiente modificación o alteración cuya tarea, formaría parte de otro Sprint Backlog.

-Daily Scrum Meeting es una tarea iterativa que se realiza todos los días que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunión operativa, informal y ágil, de un máximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo. Qué tareas ha realizado desde la última reunión (que he hecho). Sobre qué va a trabajar en el día actual (que voy a hacer hoy). Identificación de obstáculos o riesgos que impiden o pueden impedir el normal avance (que ayuda necesito). El Scrum Master, debe eliminar aquí cualquier obstáculo que encuentre.

Resumiendo es importante recalcar los fundamentos de Scrum:

-El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos(iteraciones de un mes natural y hasta de dos semanas, si así se necesita).

-La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración.

-El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.

-La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo.

-La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el cliente.

-El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados.