REPASO UNIDAD III

Desarrollo de software.

Diseño de interfaces.

Usabilidad de interfaces

Verificación y validación.

Métricas de calidad.

Software tradicional.

Software ágil.

Los riesgos son asumidos por el proveedor.

Se valora más el proceso.

Pocas iteraciones que generan gran volumen de información y software para la construcción.

Requieren un plan detallado desde el inicio.

El cliente apoya el desarrollo mediante la
participación en reuniones.

El éxito es dado por el seguimiento del plan.

Atención exhaustiva a la
documentación.

Se generan entregables que requieren mucho tiempo de elaboración.

El costo del proyecto es Existe incertidumbre respecto
definido para el proyecto.

La retroalimentación es conocida al final, pudiendo
generar insatisfacción.

Existe un compromiso respecto al tiempo de entrega del proyecto no siempre se cumple esta meta.

Empodera al Gerente de proyecto para el éxito del mismo.

Hacer un cambio al alcance requiere de un proceso formal de control de cambios.

Innumerables plantillas y artefactos para cumplir con el
proceso.

Debido a la recolección inicial de requisitos es frecuente que se soliciten funcionalidades innecesarias.

Muchos roles para ejecutar el proyecto.

Requieren los requisitos detallados desde el inicio del proyecto. Los requisitos no pueden cambiar.

La arquitectura es un ejercicio que se realiza al inicio o en una etapa del proyecto.

Voluntad del cliente para compartir la responsabilidad en las decisiones y riesgos.

Se valora más el individuo y las interacciones de los mismos.

Utilización de múltiples iteraciones de desarrollo para aprender y evolucionar el producto.

Se va planeando a medida que se avanza en el proyecto.

El cliente es parte de equipo.

El éxito es dado por la entrega continua de valor y funcionalidad al cliente.

Solo se genera la documentación que genera valor al cliente y al proyecto.

Se centran en hacer entregables en tiempos cortos con alta calidad inmersa.

Existe incertidumbre respecto al costo del proyecto. Se invierte en las funcionalidades que más valor le dan al cliente y se avanza hasta que se logre.

La retroalimentación es constante a lo largo del proyecto.

Existe incertidumbre respecto al tiempo de entrega de todo el producto. pero máximo cada 2 meses hay entrega de producto de valor para el cliente.

Empodera al equipo para trabajar de forma creativa e innovadora.

El cambio es bienvenido en cualquier momento del proyecto.

Pocas plantillas y artefactos solamente los necesarios.

El enfoque continuo en el valor para el negocio no permite que se incluyan funcionalidades innecesarias.

Pocos roles.

Los requisitos son muy cambiantes.

Arquitectura es un ejercicio constante durante el proyecto

Objetos humanos

Uso de metáforas

Valores por defecto

Guardar el estado

Autonomía

Daltonismo

Legibilidad

Eficacia del usuario

Aprendizaje

Reducción de latencia

Interfaces explorables

Protege el trabajo del usuario

Consistencia

Navegación visible

Anticipación

Muestra al usuario toda la información y herramientas necesarias para cada etapa en su trabajo.

Si utilizas el color para transmitir información utiliza otros elementos para la gente con daltonismo pueden consistir en distintos tonos de gris, gráficos complementarios o etiquetas de texto.

Niveles de consistencia

Inconsistencia

1.-Interpretación del comportamiento del usuario. Ejemplo: los atajos de teclado deben funcionar siempre igual.
2.-Estructuras invisibles.
3.-Estructuras visibles pequeñas.
4.-El aspecto general de una aplicación o servicio (presentación, elementos de diseño).
5.-Una suite de productos.
6.-Consistencia interna.
7.-Consistencia con la plataforma.

Evita la uniformidad. Haz que los objetos que se comportan distinto parezcan distintos.

Los campos de texto con valores por defecto deben aparecer seleccionados, para que el usuario sólo tenga que teclear y no seleccionar todo, borrar y escribir. Los valores deben tener sentido.

Los saltos cualitativos en eficacia se encuentran en la arquitectura del sistema, no en su superficie, en el diseño visual de la interfaz.

Escribe mensajes de ayuda concisos y que ayuden a resolver el problema: un buen texto ayuda mucho en comprensión y eficacia.

Para maximizar la eficacia de un negocio u organización debes maximizar la eficacia de todos y no sólo de un grupo

Menús y etiquetas de botones deben comenzar con la palabra más importante.

Mantén ocupado al usuario

Busca la productividad del usuario, no del ordenador

Haz que las acciones sean reversibles

Siempre permite el "deshacer"

Da a los usuarios nociones estables para saber como llegar al inicio

Siempre deja una salida abierta

De todas formas, haz que sea fácil quedarse.

Ley de Fitt: El tiempo necesario para alcanzar un objeto es función de la distancia y del tamaño del objeto.

A veces es necesario ofrecer caminos bien profundos y marcados.

Los objetos humanos de la interfaz se pueden ver, escuchar, tocar o percibir de otra manera.

Limita las limitaciones

Asegúrate de que el usuario nunca pierde su trabajo como resultado de un error suyo, los problemas de internet u otro tipo de problemas inevitables, como un apagón.

Utiliza texto con alto contraste. Procura utilizar negro sobre blanco o amarillo pálido. Evita fondos grises cuando haya texto. Utiliza tamaños de letra que se lean bien.

La información debe almacenarse en una cookie durante la sesión en el ordenador cliente.

Evita la navegación invisible.

Escoge aquellas metáforas que permitan al usuario comprender los detalles del modelo conceptual.

Cuando sea posible, utiliza el multihilo para dejar la latencia en un segundo plano.

Mantén informado al usuario del estado del sistema.

Mantén la información de estado fácilmente visible y actualizada.

El ordenador, la interfaz y el entorno de la tarea pertenecen al usuario, pero esto no significa que abandonemos todas las reglas.

Confiabilidad

Tratamiento de mensajes

Distribución

Toma de decisiones

Mantenibilidad

Tiempos de respuesta

Simplicidad

El punto óptimo a alcanzar cuando la interfaz ha sido simplificada al máximo sin reducir un ápice su funcionalidad.

No establecer nunca los elementos de nuestra interfaz en posiciones absolutas. Utilizar siempre posiciones relativas.

Para los formularios, hacer “uniones lógicas” de campos, esto es que los campos que se encuentren próximos entre sí tengan relación. Idealmente los campos se colocan en orden de tabulación de izquierda a derecha y de arriba a abajo.

El usuario debe de sentirse seguro al manejar la interfaz, si el usuario tiene miedo de “equivocarse”, nunca sacará el máximo rendimiento a la interfaz.
• Pedir confirmaciones a operaciones sensibles (borrados).
• Permitir recuperar información antigua. Esto da mucha confianza al usuario.
• El mayor temor del usuario inexperto es borrar información.

Entender que hay distintos tipos de mensajes y niveles de error (informativos, preguntas, avisos, errores recuperables, no recuperables). Por lo tanto no hay que asustar con mensajes exagerados “¡Error Fatal!”, a la mínima de cambio. Otro problema bastante común es confundir los mensajes informativos con los de error.

No hay que preguntar al usuario cosas que sabemos de antemano que no va a entender.
El usuario no tiene por qué decidir lo que los informáticos no han sido capaces de decidir.
Un lenguaje demasiado especializado los desconcierta y provoca que acaben desistiendo.

Ojo con los tiempos de respuesta, también influyen en la usabilidad aunque no lo creas. Un tiempo de respuesta prolongada desespera al usuario y provoca que realice otras acciones que seguramente acaben colgando el aplicativo. Un tiempo de respuesta excesivamente corto para lo que esperábamos puede dar la sensación de que la operación no se ha realizado.

Verificación

Validación

¿Estamos construyendo el producto correctamente? Se comprueba que el software cumple los requisitos funcionales y no funcionales de su especificación.

¿Estamos construyendo el producto correcto? Comprueba que el software cumple las expectativas que el cliente espera

Técnicas

Proceso de depuración

Inspecciones del software

Inspecciones del Software

Pruebas del Software

Debe realizarse durante todo el ciclo de desarrollo.

Son técnicas de validación estáticas => No requieren que el código se ejecute

Se analizan las diferentes representaciones del sistema en búsqueda de defectos.

Técnicas de validación dinámicas => El sistema se ejecuta

Requiere disponer de prototipo ejecutables, por lo que sólo pueden utilizarse en ciertas fases del proceso

Se contrasta dinámicamente la respuesta de prototipos ejecutables del sistema.

Facilidad de mantenimiento

Flexibilidad

Usabilidad (facilidad de manejo)

Facilidad de prueba

Integridad

Portabilidad

Eficiencia

Reusabilidad: (capacidad de reutilización)

Fiabilidad

Interoperatividad

Corrección

Hasta dónde satisface un programa su especificación y consigue los objetivos de la misión del cliente.

Hasta dónde puede quedarse un programa que lleve a cabo su
función pretendida con la exactitud solicitada. Cabe hacer notar que se han propuesto otras definiciones de fiabilidad más completas.

El conjunto de recursos informáticos y de código necesarios para que un programa realice su función.

Hasta dónde se puede controlar el acceso al software o a los datos por individuos no autorizados.

El esfuerzo necesario para aprender, operar,
y preparar datos de entrada e interpretar las salida (resultados) de un programa.

El esfuerzo necesario para localizar y arreglar un
error en un programa.

El esfuerzo necesario para modificar un programa operativo.

El esfuerzo necesario para aprobar un programa para
asegurarse de que realiza su función pretendida.

El esfuerzo necesario para trasladar el programa de un entorno
de sistema hardware y/o software a otro.

Hasta dónde se puede volver a utilizar un programa (o partes) en otras aplicaciones con relación al empaquetamiento y alcance de las funciones que ejecuta el programa.

El esfuerzo necesario para acoplar un sistema con otro.

Es un proceso complicado pues no siempre los errores se detectan cerca y se utilizan herramientas de depuración, que facilitan el proceso

Después de reparar el error, hay que volver a probar el sistema (pruebas de regresión).

Proceso que localiza y corrige los errores descubiertos durante la verificación y validación.

Consisten en revisiones sistemáticas tanto de los documentos generados como de los códigos fuentes con el único objetivo de detectar fallos.

Lista de fallos

Fallos de entrada/salida

Fallos de la interfaz

Fallos de control

Fallos de gestión de almacenamiento

Fallos de datos

Fallos de gestión de las excepciones

Análisis estático automatizado

Análisis de utilización de datos

Análisis de interfaces

Análisis de flujo de control

Análisis de la trayectoria

Pruebas del software

Particiones de equivalencia

Las pruebas se realizan en cuatro etapas:
Prueba de unidades (prueba de métodos y clases)
Prueba de integración o de subsistemas
Prueba de sistema
Prueba de validación (o de aceptación)

Tipos

Las pruebas de defectos

Las pruebas estadísticas

El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema software antes de entregar el producto.

Las pruebas exhaustivas no son posibles y deben sustituirse por subconjuntos de casos de prueba.

Pruebas funcionales ( “Caja negra”)

Pruebas estructurales (“Caja blanca”)

Pruebas de integración

Las pruebas se seleccionan en función de la especificación y no de la estructura interna del software.

Clasificar los datos de entrada en grupos que tienen un comportamiento similar respecto de la lógica de programa.

Los casos de pruebas se eligen en función de las particiones:
-Se elige un caso central por partición: Caso típico.
-Se elige casos correspondientes a las fronteras con otras particiones: casos atípicos.

En las pruebas estructurales las pruebas se seleccionan en función del conocimiento que se tiene de la implementación del módulo.

Se prueban la respuesta de grupos de módulos interconectados a fin de detectar fallos resultantes de la interacción entre los componentes.

Niveles de pruebas en sistemas orientados a objetos

-Probar las operaciones individuales asociadas a los objetos.
-Probar clases de objetos individualmente (dependencias entre operaciones de la clase)
-Probar grupos de objetos. -
Probar el sistema.

Herramienta JUnit

JUnit es un conjunto de clases que permite desarrollar y ejecutar conjuntos de pruebas de forma sencilla y sistemática.

Los casos de prueba que se generan son clases Java, que pueden ser almacenadas y reejecutadas cuando sea necesario

Elementos de framework

Casos de prueba (Test Case)

Métodos de prueba

Aserciones (Asserts)

Grupos de pruebas (Test Suite)

Una aserción es una sentencia que nos permite probar una proposición que debería ser siempre cierta de acuerdo con la lógica del programa.