Download Student Workbook for Assignment

Plantilla de Lista de verificación de Inspección de diseño detallado
TSP Detailed Desing Inspection Checklist – Form INS CKL
Inspector
Proyecto
Producto
Martha Elvia Jiménez Salgado
SSMCC
Redes Sociales
19 / 09 /201
Java
CR
Guiarte para llevar una inspección de diseño detallado efectiva
- Revisa el diseño completo por cada categoría de verificación; no trates de revisar
más de una categoría a la vez.
- Conforme termines cada paso de inspección, márcalo en la casilla de la derecha.
- Usa una marca de “V” para indicar que se cumple con un paso y una “X” en caso
contrario.
- Termina la lista de verificación para cada programa o clase antes de revisar el
siguiente.
Propósito
General
1.
Mantenimiento
1.
Recuperación
Lógica
Fecha
Lenguaje
Propietario
1.
Verificar que los diseños sean:
a. Correctos (Alineados a los requerimientos)
b. Entendibles
x
x
c. Reutilizables
La confrontación de que cada uno de los escenarios contra los
diagramas de actividades se verifica correcta
a. Escenario básico
b. Escenarios alternos (representan situaciones opcionales)
c. Escenarios excepcionales (representan situaciones inválidas)
x
Verificar cada uno de los algoritmos o pseudocódigos
x
v
v
X
Lista de requerimientos:
 REQ_1 –Redes Sociales
 REQ_1.1 -Crear cuenta
 REQ_1.2 -Validar datos
 REQ_1.3 -Cuentas únicas
 REQ_1.4 -Editar cuenta
 REQ_1.5 -Eliminar cuenta
 REQ_1.6 -No cambiar tipo de social web
 REQ_1.7 -Autenticar usuario
 REQ_1.8 -Reautenticar usuario
 REQ_1.9 -Desautorizar usuario
Lista de CU:
 CU_01-Crear cuenta
 CU_02-Editar cuenta
 CU_03-Eliminar cuenta
 CU_06-Autenticar usuario
Plantilla de Lista de verificación de Inspección de diseño detallado
Julio 2012
1
Infotec


CU_07-Desautenticar usuario
CU_08-Reautenticar usuario
Defectos encontrados:
En requerimientos:
Descripción del requerimiento REQ_1-Redes Sociales no me queda claro la diferencia de redes sociales
y web social.
REQ_1.1.- Crear cuenta, qué datos se consideran para crear una cuenta???
REQ_1.2.- Validar datos, que datos se consideran obligatorios
REQ_1.4-Editar cuenta, pueden editarse todos los campos, debería especificarse que datos si pueden y
cuáles no.
REQ_1.8.- Reautenticar usuario, el titulo podría mejorarse, podría ser más claro tal como "Renovación
de credenciales", considero que en la descripción podrías agregar una segunda razón por la que un token
es invalido y es debido a que el usuario remueve permisos a la aplicación desde la cuenta de la red
social, aquí me cuestionaba si este requerimiento debería manejarse como un caso excepcional. El
siguiente texto no se entiende "Sin embargo, si el usuario no ha desautorizado la aplicación, ante la web
social, y no se están solicitando más permisos de los ya establecidos, entonces la web social no despliega
ventana de diálogo y el usuario será redirijido hacia la uri de redirección con código, el cual puede ser
intercambiado por un nuevo token de acceso vigente.", qué ventana de diálogo no se despliega, estás
hablando de la vista que contendrá la opción de "Reautenticar usuario"???
REQ_1.9 -Desautorizar usuario, esta opción estará disponible desde la aplicación de social??? No he
visto que puedas retirarle los permisos al usuario para dejar de utilizar nuestra aplicación.
En User Interface
Sólo lleva dos propiedades? un título y una descripción? Según los requerimientos que Jorge envió dice
que debe tener la propiedad "red social asociada, la cual debe ser seleccionada de un combo con las
redes sociales soportadas por la herramienta" y si es de "tipo Oauthable, talvez haya un boton en esa
misma pantalla o una pantalla posterior que sea el de la autenticación por medio de Oauth a dicha red
social" y "Si no es así, debería de solicitar la pantalla un usuario y un password a la red social, para que
con ellos se autentique la herramienta a la misma red social, en lugar de autenticación por Oauth".
En casos de uso:
CU_01: En el punto “5.- El usuario introduce los demás datos requeridos en el formulario”, debería
haber una validación para saber qué tipo de datos mostrará al usuario, esto es dependiendo si la
autenticación es por OAuth o utilizando el usuario y la contraseña.
DIAGRAMA_ACTIVIDADES.- El diagrama de actividades no muestra la validación del tipo de red que
se está agregando (OAuth o no). También está mostrando que una vez que se ha creado la red social
Plantilla de Lista de verificación de Inspección de diseño detallado
Julio 2012
2
Infotec
entonces puedes autenticarte (lo cual aplicaría entonces que es en la edición cuando realizas la
verificación de credenciales y no en la creación). Adicionalmente a esto también se nota que la
autenticación siempre es por OAuth y según los requerimientos de Jorge también puedes conseguir
autenticarte a través de un usuario y una contraseña.
CU_06: En los pasos nunca se nota si el usuario presiona un botón o una liga para redireccionar a la
ventana de dialogo de Oauth. En el paso 4 dice “El sistema solicita a Social Web intercambiar el código
obtenido por un token de acceso.” A qué código te refieres que nunca se especificó. Esta es duda: Cómo
es que el sistema valida la cadena de respuesta.
DIAGRAMA_ACTIVIDADES.- En primera instancia se genera una URL pero quién detona esta
generación la hace desde el principio el sistema, existe una liga o un botón.
CU_07: No tiene diagrama de actividades y el texto no es descriptivo
CU_02 –Editar cuenta: Deberías agregar aquí que el sistema permite editar todos los datos excepto el
tipo de social web.
DIAGRAMA_ACTIVIDADES.- Duda: En qué momento se lleva a cabo la autenticación de credenciales
tienes que validar algo antes de que envíes la autenticación??? , como por ejemplo que tenga un título y
una descripción, si es así considero que debería ir como requerimiento que la renovación e incluso la
primera petición de credenciales deberían permitirse hasta que tenga datos en el título y la descripción.
ACTORES:
SocialWeb: además del tokenAccess también utiliza un tokenAccessSecret
En escenarios de CU:
Escenario de alternativo de CU-06, no describe los pasos secuenciales.
Escenarios de CU-08 deben ser iguales a los CU-06 puesto que es la misma ruta que sigue para
autenticarse, actualmente difieren.
Escenario de CU-02, en “Reautorizar usuario” es un escenario alterno o es un CU??? --- con respecto a
los pasos que tienes yo considero que la renovación de credenciales es de la misma manera como cuándo
se piden la primera vez ya sea por liga o botón.
El escenario “Web social no es editable”, es un caso alternativo??
El CU_03 debe llevar un escenario alternativo con la eliminación desde el árbol
En diagramas de clase:
La clase SocialNetwork en base a la ontología debe llevar login, password, entre otras propiedades que
no se consideran para autenticarse sin OAuth(las cuales no se han considerado a lo largo del diseño y
según los requerimientos que envió Jorge si deberían considerarse).
La subclase de SocialNetwork implementa clases que tienen propiedades genéricas como appKey,
secretKey, token de fecha de expiración, un accessToken, un accessTokenSecret, entre otras propiedades
que no están reflejadas en la clase.
En la clase OAuthable debe almacenar las propiedades específicas para autenticación OAuth como la
fecha de expiración, y los token permanentes de acceso.
No existe una clase llamada Postable para publicar puesto que esto es una acción.
La clase SocialWebComposer y SocialWebForm no existe en la ontología, sería bueno que definieras la
funcionalidad con el administrador de diseño para que este consideradas en la ontología o validadas en
su defecto.
Plantilla de Lista de verificación de Inspección de diseño detallado
Julio 2012
3
Infotec
En la clase SocialWebForm también debería ir el tipo de social web y seguramente la petición de
permisos para autenticarse de forma OAuth y por usuario y contraseña.
En pseudocódigo:
Pseudocódigo de CU-06 Autenticar usuario: Es pseudocódigo o ejemplo de código en php
CU_01 -Crear cuenta
REQ_1-Redes Sociales
REQ_1.1-Crear cuenta
REQ_1.2-Validar datos
REQ_1.3-Cuentas únicas
REQ_1.4-Editar cuenta --- Ver REQ_1.4
REQ_1.7-Autenticar usuario
CU_02 –Editar cuenta
REQ_1-Redes Sociales
REQ_1.2-Validar datos
REQ_1.3-Cuentas únicas
REQ_1.4-Editar cuenta
REQ_1.6-No cambiar tipo de social web
REQ_1.8-Reautenticar usuario
CU_03 –Eliminar cuenta
REQ_1-Redes Sociales
REQ_1.4-Editar cuenta
Debería ir el REQ_1.5
CU_06 –Autenticar usuario
REQ_1-Redes Sociales
REQ_1.1-Crear cuenta
REQ_1.4-Editar cuenta
REQ_1.7-Autenticar usuario
CU_07 –Desautenticar usuario
No tiene asociación con ningún requerimiento
CU_08 –Reautenticar usuario
REQ_1-Redes Sociales
REQ_1.4-Editar cuenta
Matriz de Trazabilidad
REQ_1 -Redes sociales
CU_01-Crear cuenta
CU_02-Editar cuenta
CU_03-Eliminar cuenta
CU_06-Autenticar usuario
CU_08-Reautenticar usuario
REQ_1.1 -Crear cuenta
Plantilla de Lista de verificación de Inspección de diseño detallado
Julio 2012
4
Infotec
CU_01-Crear cuenta
CU_06-Autenticar usuario
REQ_1.2 -Validar datos
CU_02-Editar cuenta
CU_01-Crear cuenta
REQ_1.3 -Cuentas únicas
No tiene asociado ningún CU
REQ_1.4 -Editar cuenta
CU_02-Editar cuenta
CU_08-Reautenticar usuario
CU_06-Autenticar usuario, puede almacenarse una cuenta sin haber autenticado al usuario???
CU_03-Eliminar cuenta, por qué está relacionado el Req1.4(Editar cuenta) con el caso de uso
Eliminar cuenta???
CU_01-Crear cuenta, por qué está relacionado el Req1.4(Editar cuenta) con el caso de uso Crear
cuenta???
REQ_1.5 -Eliminar cuenta
No tiene asociado ningún CU
REQ_1.6 -No cambiar tipo de social web
CU_02-Editar cuenta
REQ_1.7 -Autenticar usuario
CU_01-Crear cuenta
CU_06-Autenticar usuario
REQ_1.8 -Reautenticar usuario
CU_02-Editar cuenta
REQ_1.9 -Desautorizar usuario
No tiene asociado ningún CU
Plantilla de Lista de verificación de Inspección de diseño detallado
Julio 2012
5
Infotec