EVALUACIN DE ANLISIS

Ing Fredy Gonzales Calle 9na Semana

IMPORTANCIA EL PROCESO QUE LLAMAMOS ANALISIS DE SISTEMAS ES UNA ACTIVIDAD DE SOLUCION DE PROBLEMAS QUE REQUIERE UNA COMUNICACIN INTENSIVA ENTRE EL QUE DESARROLLA EL SISTEMA Y LOS USUARIOS.

ES IMPORTANTE REALIZAR UNA LISTA DE COMPROBACION PARA EL ANALISIS DEL SISTEMA O UNA EVALUACION DEL MISMO A FIN DE DETERMINAR POSIBLES ERRORES.

COMPRENDE UNA SERIE DE ASPECTOS QUE VA DESDE LA PLANIFICACION DEL ANALISIS PASANDO POR LA IDENTIFICACION DE LOS USUARIOS HASTA LA PUESTA A PUNTO DEL MISMO

La Evaluacin del Sistema: Se lleva a cabo para identificar puntos dbiles y fuertes del Sistema implantado. La evaluacin ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones: Evaluacin operacional: Es el Momento en que s evala la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la Informacin,. Impacto Organizacional: Identifica y mide los beneficios operacionales para las reas , en el desempeo e impacto competitivo, Impacto, rapidez y en el flujo de Informacin interna y externa. Desempeo del Desarrollo. Es la evaluacin del Proceso de desarrollo adecuado tomando en ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con y estndares y otros criterios de Administracin de Proyectos. Adems se incluyen la valoracin de los mtodos y herramientas utilizados durante el desarrollo del Sistema.

LISTA DE COMPROBACION PARA ANALISIS DE SISTEMAS

PLANIFICACION DEL ANALISIS ESTAN CLARAMENTE DEFINIDAS LAS RAZONES PARA EL PROYECTO DE ANALISIS ESTAN DEFINIDOS LOS LIMITES DEL PROYECTO ESTA PROGRAMADA LA REALIZACION DEL PROYECTO QUIEN REALIZARA EL ANALISIS ESTAN IDENTIFICADOS LOS USUARIOS ESTAN FIJADOS LOS OBJETIVOS PARA EL SISTEMA .- QUIEN FORMULO PRIORIDAD PARA EL PROYECTO

TRABAJOS PREVIOS QUE HA REALIZADO EN ESTA AREA

CONSIDERACIONES LEGALES, DE SEGURIDAD O AUDITORIA ESPECIAL PLAN DE TRABAJO

CONTACTO CON LOS USUARIOS

ESTAN IDENTIFICADOS LOS USUARIOS Y DEFINIDOS SUS ROLES EN LA ORGANIZACIN. COMPRENDEN EL FUNCIONAMIENTO DEL SISTEMA. DOCUMENTADAS LAS QUEJAS LEGITIMAS DE LOS USUARIOS. DOCUMENTADAS LAS CONSECUENCIAS DE LAS QUEJAS. DEFINIR EL TIEMPO Y ESFUERZO DE LOS USUARIOS .

CONOCEN LOS USUARIOS AL PERSONAL QUE APOYA, OPONE Y QUIENES SON INDIFERENTES.
ESPERAN LOS USUARIOS BENEFICIOS DEL SISTEMA. ESTA DEFINIDO EL SOPORTE DE ALTO NIVEL.-QUIENES SON PERSONAS QUE TOMAN DECISIONES CLAVES EN LOS USUARIOS GENTE QUE VA A USAR EL SISTEMA EN DIFERENTES NIVELES

RECOMENDACIONES
CONTAR CON EL ORGANIGRAMA DE TODAS LAS AREAS Y RELACIONES ENTRE ELLAS. DISPONER DE UNA DESCRIPCION Y EXPERIENCIA DE LOS USUARIOS.

DOCUMENTACION DE LOS PROBLEMAS Y SUS CONSECUENCIAS .

FORMULAR UN PLAN DE TRABAJO PARA LA PARTICIPACION DE LOS USUARIOS. FORMULAR UNA BREVE HISTORIA DE LOS PROCEDIMIENTOS DEL SISTEMA DOCUMENTAR LAS ESPECTATIVAS QUE DESEAN LOS USUARIOS. DOCUMENTAR E IDENTIFICAR OTROS SISTEMAS QUE TENGA QUE VER ALGO CON EL SISTEMA PROPUESTO.

EVALUACION A LOS OBJETIVOS DEL SISTEMA

ESTAN DEFINIDOS FORMALMENTE LOS OBJETIVOS. TENDRA IMPACTO SOBRE LAS OPERACIONES DE LA EMPRESA. REEMPLAZARA EL SISTEMA A UNO YA EXISTENTE.- CUANTO TIEMPO TIENE EL ACTUAL.- CUANTOS HAN PRECEDIDO. SE ESPERA QUE EL NUEVO SISTEMA PRODUZCA UNA REUBICACION O DESAPARICION DE ALGUNAS FUNCIONES (RESISTENCIA) SE NECESITA EL SISTEMA PARA CUBRIR OBJETIVOS INMEDIATOS SE PUEDE APROXIMAR AL DISEO DEL NUEVO SISTEMA COSTOS QUE SE TIENEN QUE JUSTIFICAR RECURSOS QUE SE DEBE DE ASIGNAR AL PROYECTO TIEMPO QUE DEBEN DEDICAR LOS USUARIOS PARA LA CAPACITACION Y APRENDIZAJE.

RECOMENDACIONES

LOGRAR DESCRIPCION COMPRENSIBLE DE LOS OBJETIVOS DEL SISTEMA

FORMULAR UN INFORME DEL ALCANCE GENERAL Y EL NIVEL DE ESFUERZOEN COSTOS Y RECURSOS. FORMULAR UN INFORME RELATIVO A LOS PROCEDIMIENTOS Y SISTEMAS QUE SE DEBEN DE CAMBIAR, ELIMINAR Y/O MODIFICAR. FORMULAR UN INFORME INDICANDO LAS ETAPAS DEL PROYECTO Y DEL EQUIPO DE TRABAJO QUE SE HARA CARGO DEL MISMO. UN COMENTARIO SOBRE LOS CARGOS Y RESPONSABILIDADES DE LOS DEPARTAMENTOS DE USUARIOS QUE PARTICIPAN

EVALUACION AL SISTEMA ACTUAL

CUALES SON LOS PROBLEMAS CON EL SISTEMA ACTUAL SEGN LOS USUARIOS Y EL EQUIPO TECNICO.- SON IGUALES ? COMO REALIZAN OTRAS ORGANIZACIONES FUNCIONES SIMILARES

QUE OTROS METODOS Y PROCEDIMIENTOS SE HAN PROBADOY/O USADO EN LA APLICACIN

CRONOLOGIA DETALLADA DE LA VIDA DEL SISTEMA. HISTORIA DE LA ORGANIZACIN DURANTE LA VIDA DEL SISTEMA

QUE COSTOS DE DESARROLLO, MANTENIMIENTOY OPERACIN HAY ASOCIADO AL SISTEMA

IDENTIFICAR NOMBRE, RANGO, POSICION EN LA ORGANIZACIN QUE ASESORARON Y/O CONSTRUYERON EL SISTEMA ACTUAL.

IDENTIFICAR UNO O MAS FALLOS PRINCIPALES DEL SISTEMA ACTUAL.

RECOMENDACIONES
CONTAR CON UNA EXTENSA NARRACION DEL SISTEMA, SU OPERACIN , USUARIOS E HISTORIA PROBLEMAS COSTOS DEL SITEMA ACTUAL INFORME DE LA POSICION DEL NUEVO SISTEMA EN RELACION A OTROS DE OTRAS ORGANIZACIONES. COLECCIN COMPLETA DE DOCUMENTOS , PROCEDIMIENTOS Y OTROS DETALLES RELATIVOS A SU OPERACION

AUDITORIA A LOS ELEMENTOS Y ESTRUCTURA DE DATOS

SE ENCUENTRAN DOCUMENTADOS SON LOGICOS Y CONSISTENTES Y SE USAN LAS ESTRUCTURAS ACTUALES

ESTAN LIMPIAS LAS BASES DE DATOS

TIENEN LOS USUARIOS UNA LISTA DE ELEMENTOS DE DATOS NUEVOS QUE LES GUSTARIA VER EN EL NUEVO SISTEMA REDUNDANCIA EN LA BASE DE DATOS

FLEXIBILIDAD EN LA BASE DE DATOS PARA CUBRIR LAS NECESIDADES DEL NUEVO SISTEMA
SERA DIFICIL CONVERTIR LA BASE DE DATOS A OTRA NUEVA SE HACE MANTENIMIENTO A LA BASE DE DATOS

CONVERTIR ARCHIVOS GRANDES

PARTE DE LA BASE DE DATOS QUE SE USA NORMALMENTE FALLOS EN LA BASE DE DATOS

RECOMENDACIONES
FORMULAR LAS DEFINICIONES DE CONTENIDO DE LOS DATOS FORMULAR UNA EVALUACION DEL CONTENIDO ACTUAL DE LAS BASES DE DATOS, CON ENFASIS EN LOS ERRORES , REDUNDANCIA Y USOS FUTUROS UNA LISTA DE CAMBIOS PREVISTOS, ADICIONES, SUSTRACCIONES Y OTRAS MODIFICACIONES NECESARIAS AL NUEVO SISTEMA. LISTA DE FALLOS Y ERRORES DE LA BASE DE DATOS

INVESTIGACION CON OTROS SISTEMAS

OTRAS ORGANIZACIONES QUE PUEDAN SER INVESTIGADAS POR SU SIMILITUD CON EL APLICATIVO A DESARROLLAR PAQUETES DISPONIBLES EN EL MERCADO QUE PUEDAN AJUSTARSE A LA ORGANIZACIN BIBLIOGRAFIA DISPONIBLE QUE FACILITE EL DESARROLLO TIEMPO A EMPLEAR EN ESTUDIAR OTROS SISTEMAS SON NECESARIOS OTROS ENTREVISTADORES PARA ESTAS ORGANIZACIONES INFORME SOBRE LOS CONTACTOS CON OTROS USUARIOS

PROPOSICIONES ALTERNATIVAS
CUANTAS ALTERNATIVAS SE DEBEN DE CONSIDERAR TIEMPO Y ESFUERZO A EMPLEAR EN EVALUAR OTRAS ALTERNATIVAS CUAN DETALLADAS Y COMPLETAS ESTAN CADA ALTERNATIVA QUIEN EVALUARA LAS ALTERNATIVAS.- REVISARAN LOS USUSARIOS LAS ALTERNATIVAS TODAS LAS ALTERNATIVAS SON LOGICAS SE TOMAN EN CUENTA LA OPINION DE EXPERTOS

RECOMENDACIONES SOBRE LA EVALUACION DE PROPOSICIONES

DEFINICIONES DE DISEO ALTERNATIVO FACTORES POSITIVOS Y NEGATIVOS DE CADA ALTERNATIVA INFORME DE EVALUACION DE CADA GRUPO QUE ESTUDIA LAS ALTERNATIVAS. PRESENTACION FORMAL DE LAS ALTERNATIVAS PREDICCION PRELIMINAR DE COSTOS DE CADA ALTERNATIVA IMPACTO TECNOLOGICO DE CADA ALTERNATIVA

SELECCIN DE DISEO ALTERNATIVO

SE HAN REVISADO TODAS LAS ALTERNATIVAS SE HAN CLASIFICADO LAS ALTERNATIVAS PARA SATISFACER LOS REQUERIMIENTOS DEL SISTEMA. EXISTE UN GRUPO TECNICO PARA SELECCIONAR LA ALTERNATIVA MAS APROPIADA EXISTE UNA ALTERNATIVA QUE SOBRESALGA DE LAS OTRAS. QUE ALTERNATIVAS PROPORCIONAN LOS USUARIOS QUE ALTERNATIVA USA LOS CONCEPTOS MAS AVANZADOS QUE ALTERNATIVA SE PRESENTA COMO LA MAS DURADERA.

EVALUACION DE DISEO
Ing Fredy Gonzales Calle Semana 12-13

Contenido

Origen Qu es el diseo centrado en el usuario (DCU)? Por qu DCU? Los principios ms importante en DCU Cmo prepararnos para desarrollar en DCU? Actividades claves en DCU

Origen
En 1986, Norman y Draper(1986) presentaron un enfoque en cual se presentaba al usuario como ente principal ISO TC159/SC4 (Ergonomics of human-system interaction)propuso crear a un grupo cuyo lder fue Tom Stewart. El objetivo de este grupo era crear una gua para los administradores de proyectos Esta gua se llam ISO 13407:1999 Human-centred design processes for interactive systems.

Qu es el diseo centrado en el usuario (DCU)?

Evaluar la calidad de un producto es una prctica muy antigua Se observ que la calidad del producto era directamente proporcional a la calidad del proceso que haba producido dicho producto. En consecuencia, se evala tambin el proceso

Antiguamente, se sola evaluar el sistema de informacin cuando ste estaba a punto de ser entregado al usuario final. Se evaluaba la precisin de ejecucin del mismo

La evaluacin de calidad de uso, que era realizada al final del proceso de desarrollo, era poco eficaz ya que:

En muchos casos el error a corregir era detectado muy tarde y su solucin implicaba cambios estructurales de elevado costo y a veces imposibles de realizar
Las pruebas se enfocaban en la ejecucin del sistema y no en el uso que se le daba al sistema Las pruebas se realizaban entre los mismo diseadores, analistas y programadores Los usuarios casi nunca estaban contento con el producto final, es decir con el sistema Siempre haba la esperanza que una nueva versin apareciera

Se concluyeron las siguientes premisas El diseo y la evaluacin deben realizarse con usuarios para los cuales se est creado el producto

La evaluacin debe ser hecha en todos los estados del proceso de diseo, tan temprano como sea posible. Desde la creacin de prototipos hasta la versin final
El estndar ISO 13 407 provee de un marco terico para el desarrollo de actividades centradas en el usuario que puede ser adaptado a diversos ambientes de desarrollo (modelo Waterfallo desarrollo iterativo)

El ISO 13 407 se concentra en el proceso de desarrollo de sistemas interactivos

Se desarrollan prototipos y stos son probados en usuarios reales con el fin de obtener feedback
Los prototipos son cambiados o sustituidos en funcin del feedback obtenido Observe que el implicar al usuario en el diseo no es lo mismo que disear pensando en el usuario

Hay razones importantes que sugieren al desarrollador de software usar DCU. produce un software que:
Es ms fcil de usar y entender lo que implica una reduccin de los costos de entrenamiento Mejora la calidad de vida de los usuarios ya que reduce el estrs y adems incrementa la satisfaccin Incrementa la productividad y eficacia operacional de los usuarios individuales y la la organizacin

El proceso promueve comunicacin entre desarrolladores y usuarios. Esto permite que se identifiquen problemas en un estado en el cual es an barato y posible hacer cambios

Los principios ms importante en DCU

1.Debe haber un balance apropiado de las funciones a realizar entre el usuario y el sistema Es crtico determinar qu aspectos de una tarea o trabajo deben ser manejados por personas y cules deben ser manejados por el sistema Esto debe ser realizado tomando en cuenta las capacidades humanas y sus limitaciones, y un profundo entendimiento de la tarea El feedback de los usuarios finales es importante para determinar el balance de las funciones. Esto ayudar a que los resultados sean aceptados por lo que sern afectados

2.Inclusin de los usuarios activamente La extensin de cunto se han de involucrar los usuarios depende en la naturaleza de las actividades de diseo Lo ms efectivo es usar personas que tengan un verdadero conocimiento y necesidad de trabajar o usar la aplicacin Esto ayudar a la aceptacin del producto final ya que los usuarios finales se pueden sentir comprometidos. Los usuario sentirn que el sistema fue diseado tomando en cuenta su opinin y no que ha sido impuesto

3.Iteracin de soluciones potenciales Un diseo iterativo implica el seguimiento del feedback de los usuarios. Es necesario incorporar incrementalmente soluciones de diseo encontrada Las soluciones pueden ser presentada desde el uso de esbozos, maquetas, o prototipos de gran fidelidad ejecutados en computadoras El usuario debe tratar de solucionar tareas reales (factibles) usando el diseo que presenta soluciones potenciales y su feedback debe ser usado para desarrollar (o modificar) un nuevo diseo ms adelante

4.Grupos de diseo multidisciplinarios

DCU es un proceso cooperativo en el cual hay que involucrar varias partes. Cada una de las partes posee conocimientos y experiencias que ofrecer. Diferentes perspectivas El grupo debe estar conformado por representes de todos los sectores que sern afectados por el sistema Deben participar: gerentes, especialistas de usabilidad , personal administrativo y entrenamiento, ingenieros de software, representantes para asegurar la calidad, y, claro, los usuarios finales del sistema

Cmo prepararnos para desarrollar en DCU? DCU puede ser incluido en estrategias ya existentes de desarrollo de software Las actividades de DCU deben ser planificadas y supervisadas como otras actividades
Los planes deben identificar sus alcances y sus relaciones con cualquier otra actividad de desarrollo Los recursos en cuanto a tiempo, habilidades necesarias y equipos, y el nmero de participantes deben estar claramente identificados Importante que el plan de DCU tome en cuenta el tiempo que se tomar incorporar el feedback de los usuarios

Actividades claves en DCU Identificar la necesidad de DCU Entender y especificar el contexto de uso Especificar los requisitos del usuario Producir soluciones de diseo Contrastar los diseos con los requisitos El sistema satisface los requerimientos de usuario y organizacionales especificados

1.Entender y especificar el contexto de uso

Caractersticas relevantes de los usuarios Conocimientos, habilidades, experiencia, educacin, entrenamiento, atributos fsicos, hbitos, capacidades motor-sensoriales. Identificar si hay grupos distintivos (ejemplo Expertos vs. Novatos) Conocer la tarea que se realiza Objetivos, frecuencia, y duracin de la misma El ambiente en que el usuario usar el sistema Aspectos organizacionales (estructura del grupo, etc.), tcnicos (hardware, red, etc.), y fsicos (temperatura, humedad, aspectos de salud y seguridad, etc.)

2.Especificar los requisitos del usuario Identificar el personal y usuarios relevantes en el diseo Proveer una propuesta clara de los objetivos

Establecer puntos de referencias con los cuales se pueda comparar el diseo a probar
Evidencias que los requerimientos han sido aceptados por sus representantes Estar en conocimientos de requerimientos legales, por ejemplo seguridad laboral

3.Producir soluciones de diseo Crear maquetas simples al inicio

La solucin inicial pude ser basada en experiencias previas, estndares ya reconocidos, o guas de estilo Lo ms importante es simular la solucin que presenta el diseo y sea real. La creacin de prototipos propicia la comunicacin entre desarrolladores y usuarios Uso de un prototipo sencillo permite probar ms alternativas antes de empezar a codificar Los cambios a realizar son oportunos y de posible realizacin tcnica y econmica

4.Contrastar los diseos con los requisitos Crear un plan de evaluacin

Reportar los resultados de la evaluacin y las recomendaciones de cambio

Iterar esta actividad hasta que el objetivo del diseo (y usabilidad) sean logrados
Llevar un seguimiento de los cambios, del mantenimiento, y de la continuidad del producto