UNIVERSIDAD CATÓLICA SANTA MARÍA

FACULTAD DE CIENCIAS E INGENIERÍAS FÍSICAS Y FORMALES

PROGRAMA PROFESIONAL DE INGENIERÍA DE SISTEMAS

PLAN DE TESIS

TECNICA PARA MEDICION DE USABILIDAD EN APLICACIONES

INFORMATICAS DURANTE EL PROCESO DE DISEÑO

Presentado por:

Daniel Bulejes ArredondoMaritza Quispe Huayta

AREQUIPA-PERÚ

2015

1. PLANTEAMIENTO DE LA INVESTIGACION

1.1. Planteamiento del Problema

1.1.1. Caracterización del Problema

La información que existe en los sitios web y la diversificación de la misma,conjuntamente con las diferentes características de los usuarios que acceden a dichainformación, así como la gran competencia existente en la red, hacen crítico que eldesarrollo de aplicaciones basadas en Web, deban contemplar no solo aspectos defuncionalidad sino también de medición, tomando en cuenta que estas aplicacionesno solo deben tener como objetivo poner a disposición de los usuarios informaciónexacta, sino orientar adecuadamente al usuario en su búsqueda. La medición en este sentido, se encuadra en una pregunta sobre si una aplicaciónWeb es lo suficientemente buena para satisfacer las necesidades y requerimientos delusuario. Es decir, la medición corresponde a una variable en el marco de laaceptación práctica de una página Web. Así, para que una página web pueda serutilizado para alcanzar alguna tarea, tiene que cumplir con criterios de utilización (esdecir referido a la funcionalidad: puede hacer lo que se necesita) y medición (cuánbien los usuarios pueden usar esa funcionalidad del sitio web).

Actualmente, existen herramientas para la aplicación de algunos métodos demedición, y aunque están basadas en un mismo método y utilizan técnicas comunesen la colección de datos, no se han establecido criterios de evaluación empírica, nisiquiera respecto a los estándares. Mayormente fueron desarrolladas para dar soportea la evaluación de una aplicación particular en un contexto muy específico,principalmente aplicaciones comerciales. A estas alturas se han desarrollado algunas metodologías para llevar a cabo estamedición de aplicaciones basadas en páginas web, en su mayoría orientadasprincipalmente a sitios comerciales. Ante esta situación se considera la construcciónde una técnica de medición empírica orientada a las páginas web, que contemple losobjetivos desde el diseño de los mismos, y otros aspectos como necesidades de losusuarios finales.

1.2. Objetivos de la Investigación

1.2.1. GeneralElaborar una técnica para medir empíricamente páginas web comerciales durante elproceso de diseño.

1.2.2. Específicos Evaluar la medición empírica mediante métodos de inspección.

Evaluar la medición empírica mediante métodos de indagación paradefinir incidencias críticas de medición que permita mejorar la técnica propuesta.

Definir un conjunto de ítems, basadas en los casos, condiciones yparticularidades que permitan obtener criterios para obtener medidas empíricas.

1.3. Preguntas de Investigación

¿Las medidas empíricas obtenidas a partir de factores de análisis y diseño de páginasweb comerciales, permitirán obtener una técnica adecuada para evaluar las mismas?¿Los métodos de evaluación seleccionadas permitirán obtener medidas empíricasadecuadas?¿Las medidas empíricas obtenidas a partir del proceso de diseño de las páginas webrepresentarán las medidas adecuadas para calificar las mismas?

1.4. Área Científica a la que corresponde el Problema

Área: Ingeniería de Software.Subárea: Interfaces humano - computador

1.5. Tipo y Nivel de la Investigación

Tipos de investigación científica: Aplicada porque se desea obtener un conjunto deindicadores de medición empírica a través de métodos seleccionados para sucomprobación.

Nivel de Investigación: Exploratorio porque la concepción de métricas se encuentranen una fase insípida, descriptiva porque se pretende realizar un análisis del estado delobjeto de estudio y experimental porque se intenta ensayar una nueva solución con lafinalidad de ayudar a resolver situaciones concretas en la definición de medidasempíricas.

2. FUNDAMENTOS TEÓRICOS

2.1. Estado del artePedro Valero Mora (Valero, 1996) indica que el mecanismo de representación delproblema es, probablemente, la cuestión que su trabajo de investigación afronta demanera más central. Por medio de un mecanismo de representación adecuado, elproceso de diseño puede ser realizado sobre un medio genérico: Una representaciónformal. Los posibles prototipos rechazados son sólo considerados en abstracto, yaque es imposible crearlos todos ellos y simplemente probarlos para ver qué es lo queocurre, y a partir de ello tomar las decisiones correspondientes. Esto es así incluso enajedrez, en el que cada prueba sólo necesita el esfuerzo físico de mover una ficha enun tablero, por lo que, en un dominio como el diseño de interfaces, en el que cadamodificación necesita un esfuerzo mucho mayor esta situación es indiscutible. Porello, es necesario algún tipo de representación que permita contemplar el espacio deproblemas y sea explorable y modificable hasta llegar a una solución que merezca lapena ser construida para comprobar que tal funciona. Como mucho, un númeroreducido de soluciones diferentes puede ser analizado con usuarios reales (dos, tres,pero no muchas más) para decidir si la solución hallada es lo suficientemente buena.

Ribera Turro Mireia (Ribera, 2005) explica los diversos hitos en la historia de lainteracción persona–ordenador, desde sus inicios a la etapa actual, en base a tresfactores: la creatividad humana, la evolución de la tecnología y el uso de losordenadores. En la etapa actual (a partir de 1989) el artículo analiza la influencia delentorno www y de la computación ubicua, nuevo paradigma computacional de granimpacto en la interacción persona–ordenador. Finalmente presenta algunas tendenciasque empiezan a configurar la interfaz post–WIMP.

Luzardo Alliey Ana (Luzardo, 2009) hace hincapié en la actualidad y menciona queel diseñador gráfico está ayudando a definir el entorno visual del siglo XXI, donde

temas específicos como este no quedan por fuera; debido a esto el profesional debeser capaz de realizar una página web con los argumentos necesarios para identificar yredirigir al usuario a una versión adaptada de los contenidos, tanto para un ordenadorde sobremesa como para un móvil, manejando el concepto de una web única. Lamisma web con la misma experiencia, los mismos elementos de navegación, o lasmismas funcionalidades en todos los dispositivos. Que los contenidos sean capacesde ser adaptados al contexto y a las interfaces de acceso y sean basada en losestándares web para su creación. Por esta razón, esta investigación va orientada alestudio del desarrollo de la Interfaz Gráfica para sitios web, dentro de losDispositivos Móviles, proponiendo pautas de estandarización. De esta manera, eldesarrollo de páginas mediante estándares web se convierte en una ventajacompetitiva sostenible, agregando valor, rentabilidad y posicionamiento, lograndoque un sitio tome fuerza dentro de este nuevo contexto mundial.

Ovidio Sánchez Walter (Ovidio, 2012) propone un compendio de estándares,métodos, técnicas y buenas prácticas de usabilidad para sitios y aplicaciones web enEl Salvador. La propuesta ha sido concebida para que sea de fácil implementación yde bajo costo según la realidad de El Salvador, específicamente para el áreametropolitana de San Salvador. Actualmente ya existen propuestas y proyectos deusabilidad, pero estas disponen de procesos muy extensos, con alto costo deimplementación por la cantidad de recursos humanos y materiales que requieren,además, estas han sido definidas según las necesitadas y realidades de un contexto opaís determinado, por lo que es necesario hacer los ajustes requeridos cuando sonimplementados en otras regiones, como la centroamericana, bajo otro contexto ydisponibilidad de recursos.

Mascheroni M., Greinier C. (Mascheroni, 2012) indica que la usabilidad es unatributo intangible del software, por lo tanto, es difícil de visualizar, medir yreconocer como un factor determinante de su calidad. Esto genera que un grannúmero de productos software tengan un nivel de usabilidad deficiente, cuando unamayor atención por este aspecto contribuiría a incrementar la calidad del productopercibida por el usuario, sin un aumento excesivo en el costo de desarrollo. Es porello que se pretende incorporar la denominada Ingeniería de Usabilidad dentro de laIngeniería de Software, integrando las técnicas de usabilidad a lo largo de todo elproceso de desarrollo. En este trabajo se describen los principales conceptos sobreusabilidad y los enfoques actuales que proponen la integración de la Ingeniería deUsabilidad a la Ingeniería del Software, así como también la metodología seguidapara recabar información acerca de la importancia que las pymes de softwareconfieren a este tema.

Mascherani M., Greiner C. (Mascherani, 2013) menciona que La usabilidad es unatributo intangible del software, por lo tanto, es difícil de visualizar, medir yreconocer como un factor determinante de su calidad. La Ingeniería de Usabilidad(IU) promueve la evaluación temprana de la usabilidad en el proceso de desarrollo desoftware y la participación del usuario en todas las fases del ciclo de vida. Paraconocer el grado de importancia que le conceden a la usabilidad las pequeñasempresas, se realizó un estudio exploratorio en pymes de software del nordesteargentino, enfocado en dos aspectos principales: la participación del usuario y lastécnicas de usabilidad que se utilizan. Los resultados indican que si bien las empresas

no desconocen la importancia de la usabilidad en la calidad del software, las prácticaspromovidas por la IU no se encuentran incorporadas en la mayoría de los procesos dedesarrollo. En este trabajo se presenta una propuesta tecnológica para evaluar lausabilidad durante el proceso de desarrollo, mediante cuestionarios que recaban yponderan la percepción de los usuarios y otros que comprueban el cumplimiento delos estándares y criterios heurísticos, con el objetivo de permitir a las empresasevaluar el cumplimiento de las recomendaciones vigentes en cuanto a criterios deusabilidad.

Sayago Sergio, Navarrete Toni (Sayago, 2005) en este artículo describe unareestructuración del ciclo de vida en Ingeniería de Usabilidad propuesto por Nielsen,que tiende a facilitar la inclusión de actividades en usabilidad en los modelostradicionales de desarrollo software, como son el evolutivo y el incremental; ytambién una metodología de diseño que agrupa ideas de Norman en una serie depasos que facilitan la reflexión y evaluación en el diseño de interfaces. Ambos se hanutilizado en varias aplicaciones, y además, cada una de ellas ha requeridoinvestigación específica. Se presentan aspectos clave y recomendaciones de diseñopara interfaces PDA; rasgos comunes en interfaces relacionadas con SIG, junto a unconjunto de recomendaciones fundamentadas en heurísticas para el diseño de uncallejero web. Finalmente se ofrece un modelo de documentación del diseño queintegra varias alternativas disponibles en la literatura.

2.2. Bases Teóricas de la Investigación

1. Planificación de un Proyecto de Ingeniería de SoftwareLa planificación involucra la especificación de objetivos y metas para unproyecto y las estrategias, políticas, planes y procedimientos para alcanzarlos.Todo proyecto de ingeniería de software debe partir con un buen plan. Laplanificación es necesaria por la existencia de incertezas sobre el ambiente delproyecto software y sobre fuentes externas. La planificación enfoca su atenciónen las metas del proyecto, riesgos potenciales y problemas que puedan interferircon el cumplimiento de esas metas. Los principales problemas en la planificaciónde un proyecto de ingeniería de software incluyen los siguientes (Pressmann,2005):• Requerimientos incorrectos e incompletos.• Muchas especificaciones de requerimientos son inestables y sujetas a

cambios mayores.• La planificación no se lleva a cabo por la creencia errónea de que es una

pérdida de tiempo y los planes cambiarán de todos modos.• La planificación de costos y plazos no es actualizada y se basa en

necesidades de mercadeo y no de los requerimientos del sistema.• Es difícil estimar el tamaño y complejidad del proyecto de software de modo

de realizar una estimación de costos y plazos realista.• Los costos y plazos no son reestimados cuando los requerimientos del

sistema o el ambiente de desarrollo cambia.• No se manejan factores de riesgo.• La mayoría de las organizaciones de desarrollo de software no recolectan

datos de proyectos pasados.• Las compañías no establecen políticas o procesos de desarrollo de software.

1.1 Actividades que se derivan de la planificación.• Fijar los objetivos y metas• Desarrollar estrategias• Desarrollar políticas• Anticipar futuras situaciones• Conducir un establecimiento de riesgos• Determinar posibles cursos de acción• Tomar decisiones de planificación• Fijar procedimientos y reglas• Desarrollar los planes del proyecto• Preparar presupuestos• Documentar los planes del proyecto.

2. Organización de un proyecto de Ingeniería de SoftwareInvolucra desarrollar una estructura organizacional efectiva y eficiente paraasignar y completar las tareas del proyecto y establecer las relaciones deautoridad y responsabilidad entre las tareas. Los principales problemas en laorganización de un proyecto de ingeniería de software incluyen los siguientes(Varas, 1998):• Es difícil determinar la mejor estructura organizacional para una organización

y/o ambiente particular (por ejemplo tipo proyecto, funcional o matriz) paragestionar el proyecto.

• Una estructura organizacional puede dejar responsabilidades para algunasactividades y tareas del proyecto poco claras o indefinidas.

• Mucho personal de desarrollo de software no acepta una organizaciónmatricial.

• Muchos líderes de equipo esperan desarrollarse tanto técnicamente como en lagestión de su equipo de trabajo.

2.1 Actividades que se derivan de la organización• Identificar y agrupar las funciones, actividades y tareas del proyecto.• Seleccionar estructuras organizacionales• Crear posiciones organizacionales• Definir responsabilidades y autoridades.• Establecer el perfil de cada puesto• Documentar las decisiones organizacionales

3. Consiguiendo Personal para un proyecto de Ingeniería de SoftwareConsiste en todas aquellas actividades que involucran llenar (y mantener llenos)los puestos que fueron establecidos en la estructura organizacional del proyecto.Esto incluye selección de candidatos, entrenamiento y otros. Los principalesproblemas en esta etapa son:• Los jefes de proyecto son frecuentemente seleccionados por su habilidad para

programar o realizar tareas de ingeniería en vez de su habilidad de gestión(pocos ingenieros son buenos gerentes)

• La productividad de los programadores, analistas e ingenieros de softwarevaría mucho de individuo en individuo.

• Hay grandes cambios en el equipo de un proyecto software, especialmente enaquellos organizados matricialmente.

• Las universidades no están produciendo un número suficiente de ingenierosque entiendan el proceso de la ingeniería de software o gestión de proyectos.

• Los planes de entrenamiento para desarrolladores individuales desoftware no se desarrollan o mantienen.

3.1 Actividades derivadas:• Llenar los puestos de la organización.• Asimilar al personal recientemente asignado• Educar o entrenar al personal• Proveer de desarrollo general• Evaluar y valorar al personal• Compensar

4. Dirección de un proyecto de ingeniería de softwareDirigir un proyecto de ingeniería de software consiste en aquellas actividades degestión que involucran aspectos interpersonales y de motivación por medio delas cuales el personal del proyecto entiende y contribuye a alcanzar los objetivosdel proyecto. Una vez que los subordinados son entrenados y orientados, el jefede proyecto tiene una responsabilidad continua por clarificar sus asignaciones,guiándolos hacia la mejora de la productividad, y motivándolos a trabajar conentusiasmo y confianza hacia las metas del proyecto. Los principales problemasen la dirección son:• Fallas para tener una comunicación efectiva entre las entidades del proyecto y

aquellas que no pertenecen al proyecto.• El dinero no es un motivador suficiente para los desarrolladores de software.• Las compañías y los jefes no poseen las técnicas y herramientas apropiadas

para motivar a los ingenieros de software.• Los clientes y gerentes no reconocen el impacto potencial en el software

causado por un aparentemente cambio trivial, por ejemplo, ellos creen que es“sólo un problema simple de programación”.

4.1 Actividades de dirección:• Proveer liderazgo• Supervisar personal• Delegar autoridad• Motivar personal• Construir equipos• Coordinar actividades• Facilitar comunicaciones• Resolver conflictos• Manejar cambios• Documentar las decisiones de dirección.

5. Control de un proyecto de ingeniería de softwareControlar es el conjunto de actividades de gestión utilizadas para asegurar que elproyecto va de acuerdo a lo planificado. El desempeño y los resultados se midencontra los planes, se notan las desviaciones, y se toman acciones correctivas. Elcontrol es un sistema de retroalimentación que provee información acerca de

cuán bien va el proyecto (Pressmann, 2005) (Sommerville, 2005). El controlresponde las preguntas1. ¿Está el proyecto en itinerario?2. ¿Está dentro de los costos?3. ¿Existen problemas potenciales que causen retrasos en alcanzar los

requerimientos dentro del presupuesto y plazo?

Los principales problemas en el control son:• Muchos métodos de control de proyectos de desarrollo de software confían en

los gastos del presupuesto para medir el “progreso” sin considerar el trabajoque lo acompaña.

• La visibilidad del progreso en un proyecto de software es difícil de medir.• La calidad no es requerida, monitoreada o controlada.• A menudo los estándares para el desarrollo de software no están escritos o, si

lo están, no se fuerzan.• El cuerpo de conocimiento llamado métricas de software (usadas para medir

productividad, calidad, y progreso de un producto software) no estácompletamente desarrollado.

5.1 Actividades de control:• Desarrollar estándares de desempeño• Establecer sistemas de monitoreo y reportes• Medir y analizar resultados• Iniciar acciones correctivas• Recompensar y disciplinar• Documentar los métodos de control.

6. Los problemas y errores comunes.Los desarrolladores, directivos y clientes normalmente tienen buenas razonespara tomar las decisiones que toman, y la apariencia seductora de los erroresclásicos es una de las razones de que esos errores se cometan tan a menudo. Perodebido a que se han cometido muchas veces, sus consecuencias se han hechofáciles de predecir. Y los errores rara vez producen los resultados que la genteespera (Pressmann, 2005) (Sommerville, 2005).

6.1 PersonasA continuación aparecen algunos de los errores clásicos relacionados con laspersonas (Pressmann, 2005) (Sommerville, 2005).1. Motivación débil. Estudio tras estudio ha mostrado que la motivación

probablemente tiene mayor efecto sobre la productividad y la calidadque ningún otro factor. Ejemplo: directivos que a lo largo de todo elproyecto toman medidas que minan la moral: como dar ánimos a diarioal principio para pedir horas extras en la mitad, y como irse devacaciones mientras el equipo está trabajando incluso los días de fiesta,para dar recompensas al final del proyecto que resultan ser de menos deun dólar por cada hora extra.

2. Personal mediocre. Después de la motivación, la capacidad individualde los miembros del equipo, así como sus relaciones como equipo,probablemente tienen la mayor influencia en la productividad.

Contratar apurando el fondo del barril supondrá una amenaza aldesarrollo. Ejemplo, hacer la selección del personal buscando quiénpuede contratarse más rápido, en vez de quién realizará la mayoría deltrabajo durante la vida del proyecto. Esta técnica consigue un iniciorápido del proyecto, pero no determina un final rápido.

3. Empleados problemáticos incontrolados. Un fallo al tratar con personalproblemático también amenaza la velocidad de desarrollo. Un fallo altomar una decisión cuando se trata con un empleado problemático esuna de las quejas más comunes que tienen los miembros del equiporespecto de sus responsabilidades. Ejemplo, el equipo sabe que uno deellos es una manzana podrida, pero el jefe del equipo no hace nada. Elresultado es predecible: rehacer el trabajo de la manzana podrida.

4. Hazañas. Algunos desarrolladores de software ponen un gran énfasis enla realización de hazañas en los proyectos. Pero lo que hacen tiene másde malo que de bueno. Ejemplo, los directivos de nivel medio danmayores aplausos a actitudes del tipo ser capaz de que a los progresosfirmes y consistentes y a los informes significativos de progreso. Elresultado es un modelo de planificación al límite en el que las amenazasde desajuste del plan no se detectan, no se conocen o ni se informan a lacadena de directivos hasta el último minuto. Un pequeño equipo dedesarrollo y sus jefes inmediatos toman como rehenes a una compañíaentera por no admitir que tiene problemas para cumplir su plan. Elénfasis en los comportamientos heroicos fomenta correr un riesgoextremo, e impide la cooperación entre los múltiples elementos quecontribuyen al proceso de desarrollo del software. Algunos directivosfomentan el comportamiento heroico cuando se concentran condemasiada firmeza en actitudes del tipo "ser capaz de". Elevando estasactitudes por encima de informes del estado exactos y a vecespesimistas, los directivos de estos proyectos coartan su capacidadde tomar medidas correctivas. Ni siquiera saben que tienen queemprender acciones correctoras hasta que el daño ya está hecho.

5. Añadir más personal a un proyecto retrasado. Este es quizás el másclásico de los errores clásicos. Cuando un proyecto se alarga, añadir másgente puede quitar más productividad a los miembros del equipoexistente de la que añaden los nuevos miembros.

6. Oficinas repletas y ruidosas. La mayoría de los desarrolladoresconsideran sus condiciones de trabajo como insatisfactorias. Alrededordel 60 por 100 indican que no tienen suficiente silencio ni privacidad.Los trabajadores que están en oficinas silenciosas y privadas tienden afuncionar significativamente mejor que aquellos que ocupan cubículosen salas ruidosas y repletas. Los entornos repletos y ruidosos alargan losplanes de desarrollo.

7. Fricciones entre los clientes y los desarrolladores. Las fricciones entrelos clientes y los desarrolladores pueden presentarse de distintas formas.A los clientes pueden parecerles que los desarrolladores no cooperancuando rehúsan comprometerse con el plan de desarrollo que desean losclientes o cuando fallan al entregar lo prometido. A los desarrolladorespuede parecerles que los clientes no son razonables porque insisten enplanes irreales o cambios en los requerimientos después de que éstos

hayan sido fijados. Pueden ser simplemente conflictos depersonalidad entre dos grupos. El principal efecto de esta fricción es lamala comunicación, y los efectos secundarios de la mala comunicaciónincluyen el pobre entendimiento de los requerimientos, pobre diseño dela interfaz de usuario y, en el peor caso, el rechazo del cliente a aceptarel producto acabado. En el caso medio, las fricciones entre clientes ydesarrolladores de software llegan a ser tan severas que ambas partesconsideran la cancelación del proyecto. Para remediar estasfricciones se consume tiempo, y distraen tanto a desarrolladores como aclientes del trabajo real en el proyecto.

8. Expectativas pocos realistas. Una de las causas más comunes defricciones entre los desarrolladores y sus clientes o los directivos son lasexpectativas poco realistas. Ejemplo, no tener razones técnicas parapensar que un software se podrá desarrollar en 6 meses, pero ése es elplazo en que lo quiere el comité ejecutivo de la compañía. Laincapacidad del jefe de proyecto para corregir esta expectativa irrealserá la principal fuente de problemas. En otros casos, los directivos o losdesarrolladores de un proyecto se buscan problemas al pedir fondosbasándose en estimaciones de planificación demasiado optimistas.Aunque por sí mismas las expectativas irreales no alargan el plan,contribuyen a la percepción de que el plan de desarrollo es demasiadolargo, y de que puede ser malo. Una inspección de Standish Groupmarcó las expectativas realistas como uno de los cinco factoresprincipales necesarios para asegurar el éxito de los proyectos internosde software de gestión.

9. Falta de un promotor efectivo del proyecto. Para soportar muchos de losaspectos del desarrollo rápido es necesario un promotor del proyecto dealto nivel, incluyendo una planificación realista, el control de cambios yla introducción de nuevos métodos de desarrollo. Sin un promotorejecutivo efectivo, el resto del personal de alto nivel de la empresapuede forzar a que se acepten fechas de entrega irreales o hacer cambiosque debiliten el proyecto. El consultor australiano Rob Thomstt afirmaque la falta de un promotor efectivo garantiza virtualmente el fracasodel proyecto.

10. Falta de participación de los implicados. Todos los principalesparticipantes del esfuerzo de desarrollo de software deben implicarse enel proyecto. Incluyendo a los promotores, ejecutivos, responsables delequipo, miembros del equipo, personal de ventas, usuarios finales,clientes y cualquiera que se juegue algo con el proyecto. La cooperaciónestrecha sólo se produce si se han implicado todos los participantes,permitiendo una coordinación precisa del esfuerzo para el desarrollorápido, que es imposible conseguir sin una buena participación.

11. Falta de participación del usuario. La inspección de Standish Groupdescubrió que la razón número uno de que los proyectos de Sistemas deInformación tuviesen éxito es la implicación del usuario. Los proyectosque no implican al usuario desde el principio corren el riesgo de que nose comprendan los requerimientos del proyecto, y son vulnerables a quese consuma tiempo en prestaciones que más tarde retrasarán el proyecto.

12. Política antes que desarrollo. Larry Constantine indicó que si hay cuatrotipos diferentes de orientaciones políticas. Los "políticos" estánespecializados en la "gestión", centrándose en las relaciones con susdirectivos. Los "investigadores" se centran en explorar y reunir lainformación. Los "aislacionistas" están solos, creando fronteras para elproyecto que mantienen cerradas a los que no son miembros del equipo.Los "generalistas" hacen un poco de todo: establecen relaciones con susdirectivos, realizan investigaciones y exploran actividades, y secoordinan con otros equipos como parte de su modo de trabajo.Constantine indicó que inicialmente los equipos políticos y generalistasestán bien vistos por los directivos de alto nivel. Pero después de un añoy medio, los equipos políticos llegan a la muerte súbita. Primar lapolítica en vez de los resultados es fatal para el desarrollo orientado a lavelocidad.

13. Ilusiones. Muchos problemas del desarrollo del software se deben a lailusión. Cuántas veces hemos escuchado cosas como éstas a distintaspersonas: "Ninguno de los miembros del proyecto cree realmente quepueda completarse el proyecto de acuerdo con el plan que tienen, peropiensan que quizás si trabajan duro, y nada va mal, y tienen un poco desuerte, serán capaces de concluir con éxito". "Nuestro equipo no hacemucho trabajo para la coordinación de las interfaces entre las distintaspartes del producto, pero tenemos una buena comunicación para otrascosas, y las interfaces son relativamente simples, así que probablementesólo necesitaremos un día o dos para eliminar los errores". "Sabemosque contamos con un desarrollador externo de poco talento para elsubsistema de la base de datos, y que es difícil ver cómo va a acabar eltrabajo con los niveles de personal que ha especificado en su propuesta.No tienen tanta experiencia como algunos de los demás desarrolladoresexternos, pero puede que compensen con energía lo que les falta enexperiencia. Probablemente acaben a tiempo". "No necesitamos reflejarla última lista de cambios en el prototipo para el cliente. Estoy seguro deque por ahora sabemos lo que quiere". "El equipo está diciendo querealizará un esfuerzo extraordinario para cumplir con la fecha deentrega, y que no han llegado a su primer hito por pocos días, pero creoque alcanzarán éste a tiempo". Las ilusiones no son sólo optimismo.Realmente consisten en cerrar los ojos y esperar que todo funcionecuando no se tienen las bases razonables para pensar que será así. Lasilusiones al comienzo del proyecto llevan a grandes explosiones al final.Impiden llevar a cabo una planificación coherente y pueden ser la raízde más problemas en el software que todas las otras causas combinadas.

7. ProcesoLos errores relacionados con el proceso malgastan el talento y el esfuerzo delpersonal. A continuación se muestran algunos de los peores errores relacionadoscon el proceso (Pressmann, 2005) (Sommerville, 2005):1. Planificación excesivamente optimista. Los retos a los que se enfrenta alguien

que desarrolla una aplicación en tres meses son muy diferentes de aquellos alos que se enfrenta alguien que desarrolla una aplicación que necesita unaño. Fijar un plan excesivamente optimista predispone a que el proyecto falle

por infravalorar el alcance del proyecto, minando la planificación efectiva, yreduciendo las actividades críticas para el desarrollo, como el análisis derequerimientos o el diseño. También supone una excesiva presión para losdesarrolladores, quienes a largo plazo se ven afectados en su moral y suproductividad.

2. Gestión de riesgos insuficiente. Algunos errores no son lo suficientementehabituales como para considerarlos clásicos. Son los llamados "riesgos".Como con los errores clásicos, si no ejercemos una gestión activa de losriesgos, con qué sólo vaya mal una cosa se pasará de tener un proyecto con undesarrollo rápido a uno con un desarrollo lento. El fallo de no gestionar unosolo de estos riesgos es un error clásico.

3. Fallos de los contratistas. Las compañías a veces contratan la realización departes de un proyecto cuando tienen demasiada prisa para hacer eltrabajo en casa. Pero los contratados frecuentemente entregan su trabajotarde, con una calidad inaceptable o que falla al no coincidir con lasespecificaciones. Riesgos como requerimientos inestables o interfaces maldefinidas pueden ser enormes cuando un contratado entre en escena. Si lasrelaciones con los contratados no se gestionan cuidadosamente, la utilizaciónde desarrolladores externos pueden retardar el proyecto en vez de acelerarlo.

4. Planificación insuficiente. Si no planificamos para conseguir un desarrollorápido, no podemos esperar obtenerlo.

5. Abandono de planificación bajo presión. Los equipos de desarrollo hacenplanes y rutinariamente los abandonan cuando se tropiezan con un problemaen la planificación. El problema no está en el abandono del plan, sino másbien en fallar al no crear un plan alternativo, y caer entonces en el modo detrabajo de codificar y corregir. Ejemplo, un equipo abandona su plan despuésde fallar en la primera entrega, y esto es lo habitual. A partir de este punto, eltrabajo no tiene coordinación ni elegancia.

6. Pérdida de tiempo en el inicio difuso. El "inicio difuso" es el tiempo quetranscurre antes de que comience el proyecto; este tiempo normalmente sepierde en el proceso de aprobar y hacer el presupuesto. No es poco común queun proyecto desperdicie meses o años en un inicio difuso, y entonces se está alas puertas de un plan agresivo. Es mucho más fácil y barato y menosarriesgado suprimir unas pocas semanas o meses del inicio difuso en vez decomprimir el plan de desarrollo en ese mismo tiempo.

7. Escatimar en las actividades iniciales. Los proyectos se aceleran intentandoacortar las actividades "no esenciales", y puesto que el análisis derequerimientos, la arquitectura y el diseño no producen código directamente,son los candidatos fáciles. Los resultados de este error, también conocidocomo "saltar a la codificación", son todos demasiado predecibles. Losproyectos que normalmente escatiman en sus actividades iniciales tendránque hacer ese trabajo en otro momento, con un costo de 10 a 100 vecessuperior a haberlo hecho bien inicialmente. Si no podemos encontrar cincohoras para hacer el trabajo correctamente la primera vez, ¿cómo vamos aencontrar 50 para hacerlo correctamente más tarde?

8. Diseño inadecuado. Un caso especial de escatimar en las actividades inicialeses el diseño inadecuado. Proyectos acelerados generan un diseñoindeterminado, no asignado suficiente tiempo para él y originado un entornode alta presión que hace difícil la posibilidad de considerar alternativas en el

diseño. El énfasis en el diseño está más orientado a la conveniencia que a lacalidad, por lo que necesitará varios ciclos de diseño de poder finalizarcompletamente el sistema.

9. Escatimar en el control de calidad. En los proyectos que se hacen con prisa sesuele cortar por lo sano, eliminando las revisiones del diseño y del código,eliminando la planificación de las pruebas y realizando sólo pruebassuperficiales. Acortar en un día las actividades de control de calidad alcomienzo del proyecto probablemente supondrá de 3 a 10 días de actividadesfinales.

10.Control insuficiente de la directiva. Poco control de la directiva para detectara tiempo los signos de posibles retrasos en el plan, y los pocos controlesdefinidos al comienzo se abandonan cuando el proyecto comienza a tenerproblemas. Antes de encarrilar un proyecto, en primer lugar debemos sercapaces de decir si va por buen camino.

11.Convergencia prematura o excesivamente frecuente. Bastante antes de que sehaya programado entregar un producto, hay un impulso para preparar elproducto para la entrega, mejorar el rendimiento del producto, imprimir ladocumentación final, incorporar entradas en el sistema final de ayuda, pulir elprograma de instalación, eliminar las funciones que no van a estar listas atiempo y demás. En proyectos hechos con prisa, hay una tendencia a forzarprematuramente la convergencia. Puesto que no es posible forzar laconvergencia del producto cuando se desea, algunos proyectos de desarrollorápido intentan forzar la convergencia media docena de veces o más antes deque finalmente se produzca. Los intentos adicionales de convergencia nobenefician al producto, Sólo son una pérdida de tiempo y prolongan el plan.

12.Omitir tareas necesarias en la estimación. Si la gente no guardacuidadosamente datos de proyectos anteriores, olvida las tareas menosvisibles, pero son tareas que se han de añadir. El esfuerzo omitido sueleaumentar el plan de desarrollo en un 20 o 30 por 100.

13.Planificar ponerse al día más adelante. Un tipo de reestimación es responderinapropiadamente el retraso del plan. Si hemos trabajado en un proyectodurante 6 meses, y hemos empleado tres meses en llegar al hitocorrespondiente a los dos meses ¿qué hacer?. En muchos proyectossimplemente se plantea recuperar el retraso más tarde, pero nunca se hace.Aprenderemos más del producto conforme lo estamos construyendo,incluyendo más sobre lo que nos llevará construirlo. Estos conocimientosnecesitan reflejarse en la reestimación del plan. Otro tipo de error es lareestimación que se debe a cambios en el producto. Si el producto queestamos construyendo cambia, la cantidad de tiempo necesaria paraconstruirlo cambiará también. El crecimiento de las nuevas prestaciones sinajustar el plan garantiza que no se alcanzará la fecha de entrega.

14.Programación a destajo. Algunas organizaciones creen que la codificaciónrápida, libre, tal como salga, es el camino hacia el desarrollo rápido. Piensanque si los desarrolladores están lo suficientemente motivados, puedensolventar cualquier obstáculo. Este enfoque muchas veces se presenta comoun enfoque "empresarial" al desarrollo de software, pero realmente es sólo laenvoltura del viejo paradigma a destajo combinado con una planificaciónambiciosa, y esta combinación raras veces funciona. Es un ejemplo de quedos negaciones no constituyen una verdad.

3. SOLUCIÓN PROPUESTA

3.1. JustificaciónLa Ingeniería de Software, busca producir una descripción detallada de un problema,con el fin de construir un Sistema de Software, que satisfaga las “necesidades yobjetivos” de la organización donde funcionará dicho sistema. En la comunidad deIngeniería de Software, estos objetivos constituyen el fundamento del sistema, y sonusualmente definidos como las metas a ser cumplidas por el sistema y su entorno,aunque algunos autores distinguen los objetivos del sistema de los objetivos de laorganización. A los desarrolladores puede resultarle más fácil comprender los objetivos a cumplirque la funcionalidad que se exhibiría en el sistema deseado. Los factores a menudoson difíciles de entender, pero ellos pueden ser justificados y explicados a través dela discusión de calidad. Debe notarse que la construcción de productos de software, apartir del análisis de procesos, es más estables pudiendo obtener costos más reales.

Existen muchos medios, pero uno de los más importantes es el proceso de desarrollode software; en él se encuentra definida una lógica de negocio casi precisa, siempre ycuando este artefacto se encuentre bien diseñado. Por otro lado los interfaces deusuario suelen ser el punto de atención de los usuarios finales ya que, gracias a ellospueden tener una “sensación” de gustos o disgusto o afecto por la utilización desistema construido por lo que elaborarlo de una manera adecuada y sólida permitiráobtener las primeras de medidas de calidad.

3.2. Descripción de la Solución

Obtenida técnica para llevar a cabo la medición empírica de las páginas webcomerciales en la etapa de diseño, se espera obtener medidas que permitancuantificar, en versiones tempranas, la calidad del producto por medio de susinterfaces gráficas.

Los inconvenientes que se pueden encontrar es que no se encuentren correctamentedefinidos los escenarios que permitan una definición clara de las medidas empíricas.Ante este inconveniente, es necesario elaborar una solución en base a medidasempíricas durante el proceso de diseño.

3.3. Alcances y Limitaciones

A. Alcances Internos

• Mejorar el criterio de usabilidad de las páginas web mediante medidasempíricas.

• Mejorar la satisfacción del usuario final en cuanto a la calidad de losinterfaces de usuario.

Externos• Mejorar los parámetros que inciden en la calidad de las páginas web

comerciales a desarrollar, con el fin de incidir en la resolución de la mejorade la usabilidad por parte de los usuarios.

• Mejorar la competitividad de la organización.

B. Limitaciones

El trabajo de investigación no contempla a aquellos métodos relativos decalificación de páginas web. Asimismo, no se contempla emplear métodosformales para de definición de las medidas empíricas.

4. METODOLOGÍAS A EMPLEARA. Método de la investigación

Investigación aplicada, empleando el método lógico deductivo.

B. Diseño de la investigaciónPara la investigación se utilizará las siguientes técnicas, instrumentos ymateriales de verificación, como se señala en el siguiente cuadro:

VARIABLES TECNICAS INTRUMENTOSDOCUMENTALES

Técnicas para definir medidas empíricas

Interfaces de usuario

ObservaciónFicha de observación documental

Observación Ficha de observación documental

Tabla N° 1: Variables y técnicas para la investigaciónFuente: Elaborado por el autor

C. Forma de Tratamiento de los DatosPara el proceso de los datos provenientes de la aplicación de los instrumentos, seutilizará:

Matriz de Sistematización de DatosPara consolidar los datos de la aplicación de la técnica, estos se sistematizaránde acuerdo a los rangos conceptuales previstos en la definición.

Matriz de TabulaciónCon el fin de contabilizar las respuestas a las observaciones hechas al caso deestudio que se aplicará.

Cuadros EstadísticosElaboración de cuadros estadísticos descriptivos que permitan visualizar lasrespuestas correspondientes en términos de indicadores.

AnálisisSe hará un análisis estadístico descriptivo aplicado a los resultados obtenidos.

5. PLAN DE TRABAJO

NOMBRE DE LA TAREA DURACIONFORMULACION DEL PROBLEMA 6 díasDETERMINACION DE OBJETIVOS 2 díasELABORACION DEL PLAN DE TESIS 5 díasPRESENTACION DEL PLAN DE TESIS 1 díaINVESTIGACION TEORICA: CAP. I 11 díasINVESTIGACION TEORICA: CAP. II 11 díasINVESTIGACION TEORICA: CAP. III 11 días

INVESTIGACION TEORICA: CAP. IV 11 díasPROPUESTA DE METRICAS 30 díasCOMPROBACION DE LA PROPUESTA 30 díasCONCLUSIONES Y RECOMENDACIONES 2 díasPRUEBAS DE EVALUACION 15 díasREDACCIÓN, REVISIÓN Y DEPURACIÓN 3 díasIMPRESIÓN Y ENTREGA DE EJEMPLARES 2 días

6. REFERENCIAS BIBLIOGRÁFICAS

(Farias, 2010) Farias Castro Alberto. Agregando Interfaz Humana Interactiva a Software deIngeniería. Tesis para optar el grado de Doctor en Informática. UNED. Madrid.

(Luzardo, 2009) Luzardo Alliey Ana. Diseño de la interfaz gráfica web en función de losdispositivos móviles caso de estudio: diarios digitales. Tesis para optar el grado de Magisteren Diseño. Universidad de Palermo. Argentina.

(Mascheroni, 2012) Mascheroni M., Greiner C. Calidad de software e Ingeniería deUsabilidad. Departamento de Informática. Facultad de Ciencias Exactas y Naturales yAgrimensura. Universidad Nacional del Nordeste. XIV Workshop de Investigadores enCiencias de la Computación. WICC 2012.

(Mascherani, 2013) Mascherani M., Greiner C. Ingeniería de Usabilidad. Una PropuestaTecnológica para Contribuir a la Evaluación de la Usabilidad del Software. RevistaLatinoamericana de Ingeniería de Software, 1(4): 125-134, ISSN 2314-2642. 2013.

(Ovidio, 2012) Ovidio Sánchez Walter. Compendio de estándares, métodos, técnicas ybuenas prácticas de ingeniería de la usabilidad orientado a sitios web en El Salvador. ING-NOVACIÓN. No. 3, Diciembre de 2011 – Mayo de 2012 • Reporte de Investigación.

(Pressmann, 2005) Roger Pressmann. Ingeniería de Software. Un enfoque Práctico. Mc.Graw Hill. Sexta Edición.

(Ribera, 2005) Ribera Turro Mireia. Evolución y tendencias en la interacción persona–ordenador. En: El profesional de la información, 2005, noviembre–diciembre, v. 15, n. 6, pp.414-422.

(Sayago, 2005). Sayago Sergio, Navarrete Toni. Técnicas de Ingeniería de Usabilidad ymetodología de diseño conceptual en algunas aplicaciones informáticas. Departament deTecnología, Grupo de Tecnologías Interactivas, Universitat Pompeu Fabra Passeig deCircumval·lació, 8, 08003, Barcelona (España). 2005.

(Sommerville, 2005) Ian Sommerville. Ingeniería de Software. Addison Wesley. SétimaEdición.

(Valero, 1996) Valero Mora Pedro. Descripción de interfaces hombre ordenador por mediode métodos formales: aplicación de métodos para la evaluación de un interfaz simulado.Tesis para optar el grado de Doctor en Informática. Universidad de Valencia. España.

7. POSIBLE TEMARIO DEL INFORME FINALPresentaciónResumenIntroducciónJustificaciónCap. 1. Planteamiento del problema

1.1 Título del proyecto1.2 Descripción del problema1.3 Delimitación y definición del problema1.4 Formulación del problema1.5 Objetivos de la investigación1.6 Viabilidad de la investigación1.7 Justificación e importancia de la investigación1.8 Limitaciones de la investigación1.9 Hipótesis de la investigación1.10 Variables e indicadores1.11 Área, línea, tipo y nivel de la investigación1.12 Método y diseño de la investigación1.13 Cobertura del estudio1.14 Técnicas e instrumentos de recolección de información

Cap. 2. Marco teórico2.1 Antecedentes investigativos2.2 Marco conceptual

2.2.1 Usabilidad2.2.2 Herramientas de usabilidad

Cap. 3. Esquema propuesto3.1 Estrategias para obtener las medidas empíricas3.2 Definición de métodos empleados

3.2.1 Método de inspección3.2.2 Métodos de indagación

Cap. 4. Caso de estudio4.1 Introducción4.2 Escenarios4.3 Requerimientos4.4 Herramientas

ConclusionesRecomendacionesBibliografíaAnexos