Pasos para la creación de la matriz de riesgos

Para nuestro proyecto estamos trabajando la matriz de riesgos de la siguiente manera:

1. Se crean una tabla para la clasificación del impacto Ejemplo:

2. Se crea una tabla con la probabilidad y porcentajes de ocurrencia, Ejm:

3. Se cuantifica la severidad con el impacto y con la probabilidad de ocurrencia aplicando calculo:

Severidad: Probabilidad + (2 * Impacto) 

4. Se crea una tabla de registro de Riesgos Proyecto donde se ingresan los posibles riesgos que pueden suceder durante el proyecto asignandole impacto, probabilidad de ocurrencia y por ende su cuantificación.

5. Se hace el seguimiento de ocurrencia a cada sprint evaluando los riesgos. Donde tenemos fechas de compromiso, responsable y estado del riesgo.

Gestión de riesgos

Buenos días

este post es para dar a conocer como se realiza el manejo de Gestión de Riesgos durante el método de scrum, los pasos a seguir son los siguientes:

• Identificación de riesgos: Se deben ir registrando los riesgos de forma iterativa.
• Análisis de Riesgos:  en los desarrollos por ciclos este se realiza basándose en el juicio, la intuición y la experiencia.
• Planificación de Respuesta al Riesgo: Se deben mantener unas opciones y acciones para mitigar los riesgos.
• Control y monitoreo del Riesgo: para los riesgos se debe realizar un seguimiento en cada iteración donde se deben discutir las opciones y acciones de mitigación.

Scrum no mitiga los riesgos que tiene que ver con proyectos externos como problemas de comunicación, adaptabilidad de las plataformas entre otros. Los riesgos que si puede mitigar son los de bajo rendimiento de los equipos de desarrollo y el cambio de las especificaciones y alcance del desarrollo.

Ejemplos de riesgos:

• El cliente no entiende o desconoce el método scrum
• Desarrollo de aplicaciones o comunicación con legados que no funcionan de la forma esperada.
• Factores del entorno que se modifican o propensos a cambiar en el tiempo
• Perdida o corrupción de la información
• La variación de gestores en el cliente.
• El agendamiento interno de los clientes que van en contra de los tiempos de desarrollo óptimos.

en los siguientes link se encuentra mas información de la gestión de riesgos en scrum:

• http://kfaday.blogspot.com.co/2011/12/administracion-de-riesgos-en-scrum.html
• https://jummp.wordpress.com/2014/03/23/gestion-de-riesgos-en-los-enfoques-agiles/
• http://geeks.ms/blogs/rcorral/archive/2007/06/28/exprimiendo-scrum-scrum-y-la-gesti-243-n-del-riesgo.aspx

En el siguiente link se encuentra un documento de ejemplo de la gestion de riesgos:

https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CCgQFjACahUKEwiW77vInIzIAhUJWx4KHQ0lDsc&url=https%3A%2F%2Fvirtualclassv2.googlecode.com%2Ffiles%2FPlan%2520de%2520Gestion%2520de%2520RiesgosVC2.doc&usg=AFQjCNHf-zcFHo4WxZ3h0fVXvGe1Mi8XFg&sig2=2cT1baQ78Pzy31dv7K3-OQ&bvm=bv.103388427,d.dmo

Cómo consumir el servicio REST del sistema acoplador (Authentication)

El siguiente post tiene como fin describir la forma de consumir el servicio REST del sistema acoplador agregando autenticación. Actualmente se tiene publicado un servicio de prueba en la siguiente url http://info1rs2.azurewebsites.net/api/values. La herramienta usada para llevar a cabo la prueba es Fiddler (http://www.telerik.com/fiddler).

Crear usuario: Para poder crear un usuario y contraseña desde fiddler, se requiere ir al tab 'Composer' y configurar lo siguiente.

• Seleccionar 'POST'.
• URL: http://info1rs2.azurewebsites.net/api/account/register.
• Header: Content-Type: application/json.
• Request Body:

                                    {

                                      "Email": "user@info1.com",

                                      "Password": "Pass+1379",

                                      "ConfirmPassword": "Pass+1379"

                                     }

Advertencia: El usuario anterior ya fue creado para el ejemplo. En caso de recrear este post agregar uno nuevo.

Solicitar un Token: Dentro de la pestaña 'Composer'. 

• Seleccionar el verbo 'POST'. 
• URL: http://info1rs2.azurewebsites.net/token.
• Request Body: grant_type=password&username=user@info1.com&password=Pass%2B1379.

Esto devuelve el token necesario para requerir la información del servicio.

Usar el Token para las peticiones subsequentes: Dentro de la pestaña 'Composer' realizar los siguientes pasos usando el token obtenido anteriormente.

• Seleccionar 'GET'.
• URL: http://info1rs2.azurewebsites.net/api/values.
• Authorization: Bearer LcLFCohr3QcXjByT_m9OMMmjlRcF9fuM5hL4HwTuBFTiJqU.

Con esto consumimos el servicio REST, obteniendo la información contenida en el controlador 'Values'.

Estrategias de cumplimento en el equipo de trabajo.

Dado que es un proyecto académico y se debe generar una auto evaluación del trabajo realizado por las diferentes personas de equipo. Se genero una estrategia en la cual se de una puntuación por las diferentes actividades que ejecuten los diferentes integrantes del equipo de trabajo durante cada uno de los sprints. 

Los aspectos a evaluar son:

• Cumplimiento: que se ejecuten las tareas planeadas durante el tiempo y con la calidad requerida.
• Blog: realizar entradas en el blog.
• Blog calidad: bonificación adicional por la calidad de los post realizados en el blog.
• Reuniones: personas que asisten a las distintas reuniones.
• Comunicación: se evalúa la comunicación constante con el equipo en cuanto a evolución y cumplimento de las tareas.
• Votación grupal: cada persona genera un voto por el compañero que considere haya realizado el mejor trabajo durante el sprint.

Cómo consumir el servicio REST del sistema acoplador (No logging)

El sistema permite requests de tipo Get para leer y Put para actualizar la ifnromación. a continuación se ejemplifica como hacerlo con la herramienta Fiddler http://www.telerik.com/fiddler.

GET: Para poder leer la información del servicio REST, simplemente se hace un request de tipo GET a la siguiente url http://info1rs.azurewebsites.net/api/modelstates/1

PUT: Para actualizar la información, se hace un request de tipo PUT a la siguiente URL http://info1rs.azurewebsites.net/api/modelstates/1.

Request Header
Host: info1rs.azurewebsites.net
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
Content-Type: application/json
Referer: http://info1ui.azurewebsites.net/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en,es;q=0.8,en-US;q=0.6,pt;q=0.4

Request Body
{"Id":1,"Temperature":60,"Valve1":0,"Valve2":"0","Valve3":"0","Bar1":0,"PumpingSystem":0,"DynamicTemp":false}

Design Patterns

Buenos días compañeros les dejo un link donde pueden encontrar la explicación los patrones de creacionales, estructural y de comportamiento.

https://sourcemaking.com/design_patterns

Para antipatrones en esl siguiente link

https://sourcemaking.com/antipatterns

y los patrones que me parecieron importantes para el proyecto que estamos realizando son los que tienen que ver con servicios REST

Entity Linking 

http://soapatterns.org/design_patterns/entity_linking 

Lightweight 

Endpoint http://soapatterns.org/design_patterns/lightweight_endpoint

Reusable 

Contract http://soapatterns.org/design_patterns/reusable_contract

Evolución

En esta etapa del proyecto se han concluido 2 Sprints, los cuales han abordado distintas funcionalidades. El primer Sprint abordo la historia de usuario que lee la temperatura desde el reactor nuclear, por medio del consumo de un servicio web rest expuesto en el servicio acoplador, y la muestra en la pantalla del aplicativo. El segundo Sprint trabaja sobre la funcionalidad asociada al encendido y apagado del reactor y la activación y desactivación de válvulas. El Sprint tres el cual esta en curso trata la funcionalidad asociada al login del aplicativo y el manejo del sistema de bombeo.