Determinar una metodología de evaluación de software para portales web o

software de aplicación, hacer una explicación de cómo funciona la

metodología.

Introducción
Una mejora de la usabilidad como una calidad de uso en contexto [1] es hoy en
día quizás el objetivo más importante de la investigación actual en el campo de la
interacción humano-computadora (HCI). A medida que la usabilidad se define
dentro de una relación entre la tarea, el usuario y el propósito del sistema, no
existe una definición simple o una medida única significativa de usabilidad. La
mayoría de los métodos de evaluación utilizados se agrupan en dos categorías, p.
métodos de prueba de usabilidad; basado en el usuario que involucra usuarios
finales, incluyendo pruebas de usuario, grupos focales, entrevistas, cuestionarios y
encuestas, así como métodos de inspección de usabilidad, sin que los usuarios
finales adopten evaluaciones heurísticas y recorridos cognitivos como los que se
usan con frecuencia. Las investigaciones recientes han tendido a reunir esos dos
enfoques básicos.
Cómo hacer para evaluar el software
Los dos enfoques que usamos son complementarios; cualquiera puede usarse, y
algunas veces un enfoque tiene más sentido que el otro.
Nuestro enfoque basado en criterios es una evaluación cuantitativa del software
en términos de sostenibilidad, facilidad de mantenimiento y facilidad de uso. Esto
puede informar las decisiones de alto nivel en áreas específicas para la mejora del
software. Este enfoque forma la base de nuestra evaluación de sostenibilidad en
línea, una evaluación basada en la web que puede usar directamente.
Nuestro enfoque basado en tutoriales proporciona una evaluación pragmática de
la usabilidad del software en forma de un registro reproducible de experiencias.
Esto le brinda al desarrollador una visión práctica de cómo se aborda el software y
las posibles barreras técnicas que impiden la adopción.
Adapta tu enfoque
Recuerde que, independientemente del método que elija, la naturaleza del
software que se revisa puede variar. Puede incluir:
Un paquete de software lanzado como un binario.
Un paquete de software lanzado como fuente que el usuario debe construir.
Un portal en línea.
Un conjunto de puntos finales de servicio, p. servicios web o servicios REST.
Probablemente también habrá artefactos relacionados que estén bajo el control de
una evaluación, p. un sitio web del proyecto, wiki, blog, rastreador de problemas,
documentos del usuario, tutoriales, foros de correo electrónico, etc. Como
resultado, no debe tomar esta guía como un conjunto de reglas duras y rápidas,
todas las cuales deben aplicarse, sino más bien como pautas a seguir, algunas de
las cuales se aplicarán en ciertas situaciones y otras no. Use su mejor juicio al
seleccionar estos, teniendo en cuenta que el objetivo es producir información
valiosa sobre el estado del paquete de software.
Naturaleza y alcance de la evaluación
Una evaluación de software se hace para alguien. ¡Alguien quiere saber sobre el
estado de un paquete en particular, y hasta puede estar pagándole para
investigarlo! Entonces, al principio, debe acordar con este "alguien" el alcance de
la evaluación. Esto incluye qué software y otros recursos del proyecto se
evaluarán y las clases de usuarios desde cuya perspectiva se realizará la
evaluación. Las clases de usuario determinan las tareas que formarán la base de
cualquier evaluación, especialmente una evaluación basada en tutorial. Se pueden
suponer las siguientes clases de usuarios:
Usuario. Una persona que, dependiendo del artefacto, descarga, instala, configura
y usa el artefacto pero no escribe ningún código para usar junto con él. El software
puede ser un portal web, una GUI o una herramienta de línea de comandos.
Dentro de esta clase podría haber diferentes tipos de usuario, p. para el portal de
journalTOCs, los usuarios podrían ser investigadores que deseen utilizar el
servicio o editores de revistas que quieran descubrir cómo el servicio utilizó sus
canales RSS.
Desarrollador de usuario. Un usuario que escribe código que amplía pero no
cambia el software, p. un cliente para algunos puntos finales de servicio, o un
componente enchufable codificado en algún punto de extensibilidad. Como
analogía, un desarrollador de servicios web que utiliza Apache Axis.
Desarrollador. Un usuario que escribe código que cambia el software, p. corrige
errores, hace que el software sea más eficiente o amplía su funcionalidad. Como
analogía, alguien que cambia Apache Axis para hacer que WSDL2Java sea más
fácil de usar.
Miembro. Un desarrollador que es un miembro del proyecto y tiene acceso de
escritura al repositorio de código fuente. A diferencia de un Desarrollador, un
Miembro debe ser consciente de cuestiones tales como la política de actualización
para usar nuevas versiones de paquetes de requisitos previos, estándares de
codificación, quién es el propietario de los derechos de autor, licencias, cómo se
gestionan los cambios, si se espera que admitan componentes desarrollan, cómo
se ejecuta el proyecto, etc. Como analogía, un miembro del equipo de
desarrolladores de Apache Axis.
En términos de cuánto tiempo dedicar a una evaluación para obtener información
útil, nuestra regla de oro es que un período ideal es de 1-2 semanas de duración
(o 3-5 días de esfuerzo) dependiendo de la complejidad del software y del
naturaleza de las tareas de evaluación.

¡Los evaluadores necesitan apoyo también!

Una cosa importante que debe determinar antes de embarcarse en una evaluación
importante es el nivel y la disponibilidad del soporte en caso de que tenga
problemas técnicos. Si está realizando una evaluación por encargo para los
desarrolladores del software, entonces puede ser vital verificar y / o asegurar de
antemano la disponibilidad del equipo de desarrollo de software durante el período
de evaluación. ¡De hecho, esto es muy importante, incluso si lo estás evaluando
para otra persona! Por supuesto, la asistencia que necesite dependerá del tipo y la
profundidad de la evaluación, y de la naturaleza del software.
Sin el nivel requerido de soporte técnico, los riesgos son los siguientes:
El período de evaluación podría incrementarse considerablemente, tal vez
excediendo el esfuerzo acordado o la tolerancia de tiempo para la actividad.
Una evaluación podría fallar por completo, p. quizás debido a un error de
instrucción básico del cual los desarrolladores no están conscientes pero de lo
contrario podrían ayudarlo fácilmente. Por supuesto, una evaluación puede fallar
por completo en cualquier caso, pero es particularmente molesto para todos los
interesados si se debe simplemente a un error de documentación que podría
resolver un chat de 30 segundos con un desarrollador práctico.
Es quizás irónico que no pueda completar una evaluación porque no puede hacer
que el software funcione; pero luego, ¡ese es un resultado de evaluación válido!