Ingeniería del Software Avanzada

Índice Requisitos de Usabilidad Requisitos de Accesibilidad Requisitos de Rendimiento Métricas Resumen Requisitos Conclusiones

Requisitos Usabilidad

VIDEO Camtasia Studio Captura de la página Web Cambio de formato iMovie Montaje del video

Usabilidad (I)  INTECO ity/Accesibilidad/a ccesibilidad_servici os/intav_home/ ity/Accesibilidad/a ccesibilidad_servici os/intav_home/ Web Developer Tools (plug in de Mozilla Firefox)

Usabilidad (II) Directrices de  Google Analytics: es necesario incorporar un código en la web de la empresa que le permita a esta herramienta obtener los datos más relevantes del uso de la web

Usabilidad (III) Eye tracking e.com/watch?v=lo_ a2cfBUGc e.com/watch?v=lo_ a2cfBUGc Recomendada para testar la usabilidad de la página al final del desarrollo.

Requisitos Accesibilidad

Accesibilidad (I) Norma une: :2004 y requisitos WCAG 2.0 HERA-XP

Accesibilidad (II) W3C (World Wide Web Consortium) TAW wdis/online wdis/online

Accesibilidad (III) Fangs: lector de pantalla.(Plug-in mozilla)

Accesibilidad (IV) Color Oracle (Aplicación independiente)

Requisitos Rendimiento

REN1 y REN2 REN1: El sistema debe soportar un mínimo de anuncios de alquiler REN2: El sistema debe soportar un mínimo de usuarios registrados

REN1 y REN2: Herramientas

REN1 y REN2: App Introducir datos

REN1 y REN2: Scripts

REN1 y REN2 : SQLyog

La BBDD de HomeRent es capaz de soportar perfectamente la cantidad mínima de usuarios y anuncios que requieren los requisitos.

REN3 Ren3: El Sistema debe soportar un mínimo de iteraciones simultáneas.

REN3: BadBoy

REN3: JMeter

Podemos observar que las pruebas se han realizado sin errores. Esto se deduce de la columna representativa del tanto por ciento de errores para cada una de las peticiones asociadas a cada conjunto de muestras. El rendimiento nos muestra que para una simulación de 2000 usuarios junto a un periodo de subida de 10 segundos el servidor es capaz de aceptar una media de peticiones por segundo. Por lo tanto superamos el requisito.

Métricas

JavaNcss: Comparación (I) Al finalizar el Sprint 1Al finalizar el Sprint 2

JavaNcss: Comparación (II) Comparando las dos imágenes anteriores vemos: Tenemos el mismo número de paquetes Han aumentado las clases, funciones por ello la complejidad ciclomática. Los paquetes con más clases son Model y Dao. Aunque han aumentado las funciones nuestro proyecto sigue teniendo una complejidad baja.

JavaNcss: Complejidad Ciclomática La escala para medir la CC que más se adecua a nuestro proyecto es la siguiente:

JavaNcss: Análisis CCN Podemos observar que los métodos que usamos tienen una complejidad ciclomática muy baja, prácticamente todos tienen un valor de 1. Estos valores nos indican que nuestro código es muy fácil de mantener, probar y modificar.

JavaNcss: Conclusiones Con el análisis de JAVANCSS hemos podido comprobar: Los paquetes “model” y “dao” son los más complejos, ya que model tiene los “get” y “set” de comunicación con la base de datos. La clase “anuncio” es la que más atributos tiene, además de los métodos “get” y “set”. Los métodos “login” y “crear anuncio”, situados en el paquete “bean” son los que más líneas tienen, ya que son los que actualmente están en uso.

CJKM Al finalizar Sprint 1Al finalizar Sprint 2

CKJM : Indicadores y Resultados MPC: Las clases que hemos creado (dao y bean) siguen teniendo valores muy bajos por lo tanto la mantenibilidad del código es muy sencilla. PAH :Todas las clases tienen un valor de 1. El tamaño del código es pequeño y nada complejo. Nuestras clases heredan pocos métodos, por lo tanto es muy fácil de mantenerlas. NDD: Todas las clases tienen un valor de 0. No tenemos ninguna clase dependiente por herencia, por lo tanto como punto negativo tenemos poca reutilización del código, mientras que como punto positivo no vamos a tener problemas en el mantenimiento.

CKJM: Indicadores y Resultados ACO: El valor más alto sigue siendo 8. El acoplamiento de nuestro código es bajo y las clases no son complejas. RPC: El valor máximo sigue siendo 60 en la clase model.anuncio. Es un valor aceptable, pero hay que evitar que aumente, así no será una clase demasiado extensa y compleja. Un valor muy alto aumentaría el esfuerzo de pruebas y verificaciones. CCM: La clase model.anuncio presenta un valor de 1513, lo que quiere decir que es una clase muy grande y es aconsejable dividirla en varias. Mantener un numero bajo de CCM nos indica que tenemos una elevada cohesión en el código.

CKJM: Conclusiones Según esta métrica, nuestra aplicación no tiene complejidad, porque: Tenemos una arquitectura por capas donde separamos el modelo, la vista y el controlador. No tenemos clases complejas. La mantenibilidad del código es muy sencilla. Elevada cohesión en el código y bajo acoplamiento.

JHAWK Sólo analizamos las clases que hemos creado nosotros además de la clase “model.anuncio” del paquete “model”, que es la más problemática.

JHAWK: Paquetes Al finalizar Sprint 1 Al finalizar Sprint 2: ha aumentado la CC pero sigue siendo baja y tenemos un buen índice de mantenibilidad.

JHAWK: Clases Al finalizar Sprint 1 Al finalizar Sprint 2: Las clases presentan una CC muy baja, el esfuerzo de Halstead es alto en las clases “crearAnuncio” y “managedBean”, el acoplamiento de las clases es muy bajo y el índice de mantenibilidad es muy bueno para todas.

JHAWK: paquete Model Al finalizar Sprint 1 Al finalizar Sprint 2 : encontramos que la clase Anuncio sigue teniendo 59 métodos, una cantidad importante, con falta de cohesión grande entre objetos, pero complejidad ciclomática baja.

JHAWK: Clase Anuncio Al finalizar Sprint 1 Al finalizar Sprint 2: el mayor problema sigue siendo la cantidad de métodos que contiene.

JHAWK: Conclusiones Al igual que con las anteriores métricas, los resultados son: Tenemos pocas clases. La complejidad ciclomática es muy baja. El código dispone de un buen índice de mantenibilidad.

FindBugs Volvemos a utilizar el Plugin de NetBeans para obtener: Análisis de problemas en el código fuente Vulnerabilidades Malas prácticas o código duplicado.

FindBugs: Resultados

FindBugs: Conclusiones Como hemos podido ver en la captura anterior, tenemos 122 problemas variados en el código. Han aumentado respecto a las métricas anteriores (105), debido a aumentado también el código del proyecto.

Resumen de Requisitos

Terminados (I) Empleo de lenguajes de programación estandarizados_ Java, C#, etc.Estructura estandarizada de la documentaciónWindowsEstructura del software fácil de comprenderDocumentación de la fase de diseño Durante los 3 Sprints

Terminados (II) Los propietarios deben ser capaces de aprender a registrar un anuncio en 10 minutosUn propietario debe poder dar de alta un anuncio en 15 minutosLas interfaces gráficas de la página deben ser utilizables por personas con daltonismo Las interfaces gráficas de usuarios deben usar un tamaño de fuente adecuado, para poder ser usados por personas con agudeza visual limitada Contemplar las directrices de accesibilidad W3C El SAA debe facilitar la navegación a través de sus páginas, así como la utilización de formularios, etc. Sprint 3

Terminados (III) El sistema debe soportar un mínimo de anuncios de alquilerEl sistema debe soportar un mínimo de usuarios registradosEl sistema debe soportar un mínimo de iteraciones simultáneasRegistro de propietarios en el sistemaPruebas de testingMétricas a la finalización del Sprint 2Presentación.ppt Sprint 3 Sprint 3

Sin terminar Editar un anuncioEliminar un anuncioBúsqueda sencilla de apartamentosDetalle de información de un apartamentoCrear perfil de usuario Sprint 3

Resumen sprint 3

Resumen por Sprint

Resumen Final

RealizadosEmpezadosSin Hacer Propietarios de Apartamentos 422 Usuarios de Apartamentos 318 Empresa de Alquiler 001 Accesibilidad 300 Usabilidad 300 Interoperabilidad 200 Mantenibilidad 700 Capacidad 600 Portabilidad 102 Reusabilidad 001 Robusted 001 Seguridad 200 TOTAL31315

Conclusiones Hemos conocido la manera de trabajar de Scrum, y a organizarnos de una manera diferente a como nos organizamos en otros trabajos. Capacidad de autogestión y planificaciones más acertadas conforme íbamos realizando sprints. Todos los miembros han realizado las principales funciones del proyecto: BBDD, codificación, diseño, test… Aprended a buscar herramientas útiles para realizar nuestro trabajo y usar todas las herramientas propuestas en clase. La experiencia ha sido muy positiva.