---
# System prepended metadata

title: Proceso de validación

---


# Proceso de validación 
## Responsables
| Nombre    | Rol               |
| --------- | ----------------- |
| Cristian     | Dueño del Proceso |
| Alexis    | Autor      |
| Charlie    | Autor      |


## Objetivo
1. Conocer el proceso, entradas y salidas que debe de tener el flujo de validación de las historias de usuario con el fin de encontrar defectos y al corregirlos lograr que el stakeholder esté deleitado con la entrega de las mismas.

## Entrada 
1. Historias de usuario a validar plasmadas en el prototipado o el sistema.

## Proceso

<table>
  <thead>
    <tr>
      <th>Fase</th>
      <th>Actividades</th>
      <th>Encargado</th>
      <th>Áreas del CMMI</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan="2">Comprobación</td>
      <td>Revisar la <strong><a href="https://github.com/novaDepto/Nova/wiki/Guía-de-validación-de-historias-de-usuario">Guía de validación de historias de usuario</a></strong> para saber qué es necesario evaluar en la historia de usuario.</td>
      <td>PO</td>
      <td>REQM,VAL</td>
    </tr>
    <tr>
    <td><b>Estrategia:</b><li>Think Aloud: Realiza un Think Aloud con el stakeholder para validar el funcionamiento o diseño del sistema con una muestra representativa.<strong><a href="https://drive.google.com/file/d/1AiwO6-m2auzmky6S-LVg5ssMjTsxumKl/view?usp=sharing"> Ver Formato de Think Aloud. </td>
      <td>PO</td>
      <td>REQM, VAL</td>
    </tr>
    <tr>
     <td>Ejecución</td>
     <td>Muestra al stakeholder el prototipo del sistema o el sistema corriendo, usa la <strong><a href="https://docs.google.com/spreadsheets/d/17N34zCkKkA4rHp_mF5eHi9PtrRDht8qFl5xqETTHyZk/edit#gid=0">plantilla para validación con cliente</a></strong> para cada user story a tratar con el socio formador y basate en la <b><a href="https://drive.google.com/file/d/1AiwO6-m2auzmky6S-LVg5ssMjTsxumKl/view?usp=sharing">Guía de validación de historias de usuario</a></b> para los criterios de validación. <br></a>
</td>
<td>PO</td>
<td>REQM, VAL</td>
    </tr>
    <tr>
      <td rowspan="3">Análisis</td>
      <td>A partir de los resultados obtenidos, al ejecutar la guía o Think Aloud se deberán tener datos para saber si es necesario hacer cambios a la estructura del código. <li> Si existen inconsistencias identificadas sigue la <strong> <a href="https://github.com/novaDepto/Nova/wiki/Gu%C3%ADa-de-identificaci%C3%B3n-de-inconsistencias"> Guía de identificación de inconsistencias.</a> </strong> </li><li>Si existen defectos anótalo en el <b><a href="https://docs.google.com/spreadsheets/d/1RpU0kmGCRSH35LN6ZTPPkAXsNAeiS_OLvBdqoJsp060/edit#gid=868244246">log de defectos</a></b></li><li>Si existen cambios detectados seguir el <a href="https://github.com/novaDepto/Nova/wiki/Proceso-de-gesti%C3%B3n-de-cambios-a-historias-de-usuario"> <b>proceso de gestión de cambios a historias de usuario.</b></a></li></td>
      <td>PO</td>
      <td>REQM, VAL</td>
    </tr>
    <tr>
        <td>De ser necesario, agendar juntas para continuar con la retroalimentación de la validación.</td>
        <td>PO</td>
        <td>REQM, VAL</td>
    </tr>
    <tr>
    <td>Redefinir acciones para las etapas de diseño y análisis dentro del ciclo de vida de la historia de usuario. Y ajustar éstas en el <b>plan actual de trabajo.</b></td>
        <td>P</td>
        <td>REQM, VAL</td>
    </tr>
  </tbody>
</table>

## Salidas
Los resultados finales son:
1. Wireframes, diagramas de actividad, diagramas de flujo y/o casos de prueba actualizados.
2. Métricas de tiempos y de satisfacción.
3. Historias de usuario actualizadas.
4. Log de defectos y/o log de incosistencias actualizados.
5. Log de cambios actualizados.

***
Versión 1.3


