Revisión de pares
En una
empresa de software se tienen como proyecto un robustecimiento sobre una página
web existente, donde intervienen el analista funcional, el arquitecto, los
desarrolladores, los tester y la gerente de proyecto.
Se
realizan fases del proyecto donde para cada una de ellas es de suma importancia
que se realicen revisiones de pares, donde se identifican las objeciones y recomendaciones
a tener en cuenta, todas estas son plasmadas en un artefacto. Con el fin de
realizar un informe de revisión a cada una de las actividades encontradas o
identificadas en dicha reunión.
A
continuación se define el proceso de Revisión de pares:
·
Proceso
·
Procedimiento
|
No
|
NOMBRE
|
DESCRIPCIÓN/POLÍTICAS/GUÍAS DE
|
ACTOR
|
ROL
|
INDICADOR
|
HERRAMIENTAS
|
|
1
|
Seleccionar
par
|
Se
realiza la selección de una persona para realizar la verificación por pares.
|
Tester
|
|
|
|
|
2
|
Explicar
proceso General
|
Se
realiza la explicación de manera general de los procesos y/o funcionalidades
del sistema, al par elegido
|
Tester
|
|
|
|
|
3
|
Realizar
Revisión
|
El
par elegido lleva a cabo la revisión asignada.
Se comunican los hallazgos (no conformidades, inquietudes y sugerencias) al Tester. |
par
elegido
|
|
|
|
|
4
|
Analizar
Hallazgos
|
Si
se presentan hallazgos, el tester realiza la gestión para cerrarlos, mediante
el proceso PR-UNE-22 Gestión de Hallazgo
|
Tester
|
|
|
|
|
5
|
Gestión
de hallazgos
|
Se
debe ir al proceso predefinido que se especifica en el documento PR-UNE-22
Gestión de Hallazgo, en el proceso se detalla las actividades que tienen que
ver con la gestión de hallazgos.
|
|
|
|
|
Para modo
de ejemplo se aplicara el proceso y procedimiento mencionados en los puntos
anteriores para la revisión de pares a
nivel de desarrollo, donde el desarrollo
X realiza una evaluación de la implementación realizada por otro desarrollador
y mediante un artefacto con criterios definidos para la revisión.
A
continuación se detalla el artefacto de lista de chequeo para la revisión de
pares de la página web.
·
Todos los elementos de la página
web en el inicio están claramente enfocados en las tareas claves de los
usuarios. Sí Parte No N/A
·
La página de inicio contiene un
campo de texto para búsquedas. Sí Parte No N/A
·
Se presentan las categorías de
productos y están claramente visibles en la página de inicio. Sí Parte No N/A
·
Existe contenido de utilidad en
la página de inicio o a un clic de distancia de la página inicial.
Sí Parte No N/A
·
La página de inicio contiene buenos
ejemplos sobre el contenido en el resto del sitio web.
Sí Parte No N/A
·
Los links de la página de inicio
empiezan con la palabra clave más importante (ej. en inglés "Sun
holidays" en vez de "Holidays in the sun"). Sí Parte No N/A
·
Existe en la página de inicio una
lista breve de elementos recientes, con un link hacia el contenido completo.
·
Sí Parte No N/A
·
Las áreas de navegación en la
página de inicio no sufren de un abuso de formato/diseño y los usuarios no las
podrían confundir con publicidad. Sí Parte No N/A
·
La proposición de valor está
claramente establecida en la página de incio (e.g. con un lema o propaganda de
bienvenida). Sí Parte No N/A
·
La página de inicio contiene
información gráfica con sentido, sin clip art por ejemplo. Sí Parte No N/A
·
Las opciones en la navegación
están ordenadas en el orden más lógico o de alguna forma orientada a las tareas
más importantes (con la información corporativa menos importante al final) . Sí Parte No N/A
·
El título de la página de inicio
va a proveer buena visibilidad a máquinas de búsqueda como Google . Sí Parte No N/A
·
Toda la información corporativa
está bien agrupada en una sola área por aparte (ej. "Acerca de"
.
Sí Parte No N/A
·
Los usuarios van a entender la
proposición de valor. Sí Parte No N/A
·
Con solo un vistazo a la página
de inicio el usuario que ingresa por primera vez puede entender por dónde
comenzar.
·
La página de inicio muestra todas
las opciones principales. Sí Parte No N/A
·
La página de inicio tiene una
dirección URL fácil de recordar.
Sí Parte No N/A
·
La página de inicio está diseñada
profesionalmente y va a crear una primera impresión positiva. . Sí Parte No N/A
·
El diseño de la página de inicio
va a animar a los usuarios a explorar más del sitio. Sí Parte No N/A
·
La página de inicio realmente
luce como una página de inicio, es decir, las páginas secundarias no se podrían
confundir con ésta.
Sí Parte No N/A
2. Disciplinados
Revisiones
El objetivo
de una Revisión de un elemento software es evaluar el software o el estado, del
proyecto para identificar las discrepancias sobre los resultados planificados y
recomendar mejoras cuando sea apropiado.* Su objetivo es evaluar el estado y
los productos de una/s actividad/es en un/os proyectos* Se realizan a nivel
gerencial y a nivel técnico y durante todo el ciclo de vida* Puede ser
realizado por cualquiera de las dos partes Una parte (parte revisora) revisa lo
actuado por la otra (parte revisada).Las revisiones sirven para:• Señalar la
necesidad de mejoras en el producto de una sola persona o un equipo.• Confirmar
las partes de un producto en las que no es necesaria o no es deseable una mejora.•
Conseguir un trabajo técnico de una calidad más uniforme, o más predecible, que
la que puede ser conseguida sin revisiones, con el fin de hacer más manejable
el trabajo técnico.
En este caso realizaremos la Revisión
de requerimientos de la página Web, en el cual se planean todas las acciones
necesarias para verificar que los documentos de requerimientos y funcional
cumplan con la información necesaria para ser suministrados a las demás áreas
del ciclo productivo del desarrollo de software.
Con los siguientes objetivos:
-Verificar que los documentos de
requerimientos y funcional cumplan con los estándares definidos.
-Detectar No conformidades de acuerdo
con un criterio de evaluación y aceptación de los requisitos.
-Verificar la existencia de la
información necesaria para las diferentes etapas de ciclo productivo de
desarrollo de software.
-Identificar Gaps entre los
requerimientos del cliente y los requerimientos incluidos en el documento
funcional.
-Reportar las no conformidades al
área funcional y/o área comercial.
-verificar el seguimiento de las no
conformidades reportados.
Adicionalmente se debe realizar un
alcance, una metodología, actividades, planeación de la revisión, ejecución de
la revisión, revisión de requerimientos según criterios de evaluación
(correcto, no ambiguo o claro, completo)
PROCESO
DE REQUERIMIENTOS:
Ejecución de la revisión:
1. Revisión de requerimientos según criterios de
evaluación.
2. Reporte de No conformidades
3. solución No conformidades.
4. Seguimiento de No conformidades.
5. Cierre de la Revisión.
Ejemplo de un requerimiento incompleto (representado
por medio de un caso de uso):
|
Caso de uso
|
Búsqueda de un cliente
|
|
Actores
|
Usuario Administrador
|
|
Tipo
|
Básico
|
|
Resumen
|
El usuario escoge la opción de búsqueda
de clientes. Se debe permitir buscar un cliente por los siguientes criterios:
1. Cedula del cliente 2. Nombres 3. Apellidos 4. Dirección 5. Teléfono Esta operación la podrá hacer un usuario administrador y también un usuario con perfil de representante de cuenta. |
|
Precondiciones
|
El usuario debe de haberse logueado
en el módulo. Deben existir datos en el sistema.
|
|
Post- condiciones
|
Visualización de datos del cliente
|
|
Ref características
|
01, 02
|
|
Flujo principal
|
|
|
Actor
|
Sistema
|
|
1. el usuario selecciona la opción búsqueda
de cliente.
2. el usuario ingresa los datos para realizar la búsqueda y hace clic en Buscar E-1 |
2. El sistema despliega las opciones
para realizar la búsqueda, con un botón de buscar y otro de limpiar.
4. Se visualizan los datos del cliente en una grilla. |
|
Flujo alternativo
|
|
|
Actor
|
Sistema
|
|
1. el usuario da clic en el botón
Limpiar
|
2. El sistema limpia la forma.
|
|
Excepciones
E-1: El cliente no existe. |
|
|
Requerimientos Especiales
|
|
No hay comentarios:
Publicar un comentario