Analisis y Diseño de Sistemas by Analisis y Diseño de Sistemas II

Republica Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Ingeniería de Sistemas Universidad Bicentenaria de Aragua

Integrantes:  Jorge Durand  Elías Coelho  Argenis Arteaga  Juan F. Da Silva

C.I: 23.795.671 C.I: 23.587.493 C.I: 19.175.833 C.I: 23.423.698

¿Qué es la evaluación del prototipo? El desarrollar sistemas interactivos implica utilizar ciclos de vida iterativos que permitan el desarrollar sistemas centrados en el usuario, es decir, que sean usables. Es evidente, por tanto, que la usabilidad es un objetivo fundamental a conseguir en una aplicación interactiva. El concepto de usabilidad es fácil de asimilar aunque conseguir que un producto sea usable ya es más difícil. En general, cuando se diseña un producto se está más preocupado en la funcionalidad que en la usabilidad. La aplicación de los métodos de evaluación de la usabilidad permite garantizar la obtención de la misma en una aplicación interactiva. La evaluación de la usabilidad implica analizar el entorno y los usuarios que van a utilizar el producto, probar un prototipo, diseño o producto con una selección de usuarios, analizar el diseño con expertos, etc., en definitiva, conseguir su integración en el ciclo permitiendo la realización de un diseño centrado en el usuario. La evaluación comprende un conjunto de metodologías y técnicas que analizan la usabilidad de un sistema interactivo en diferentes etapas del ciclo de vida. El diseño y desarrollo de sistemas interactivos centrados en el usuario evaluando la usabilidad nos permitirá desarrollar productos que produzcan más satisfacción al usuario, reducir los costes de mantenimiento porque al usuario le será más fácil utilizarlo, reducirá el coste de rediseño debido que a se han realizado evaluaciones ya desde el inicio del diseño y por tanto el diseño estará mucho más probado lo que implicará un menor coste y un mayor prestigio para los desarrolladores, una mayor audiencia al estudiar aspectos culturales y en general una mejor introducción del producto en el mercado. La evaluación de la usabilidad nos permitirá garantizar la usabilidad de la interfaz. Métodos de Evaluación del Prototipo Existe una amplia variedad de métodos de evaluación que se clasifican en los tres métodos principales siguientes: Inspección: es un nombre genérico para un conjunto de métodos basados en evaluadores que inspeccionan o examinan aspectos relacionados con la usabilidad de la interfaz. Los inspectores de la usabilidad pueden ser especialistas en usabilidad, consultores de desarrollo de software con experiencia en guías de estilo de interfaces o usuarios finales que tengan conocimientos de las tareas o del dominio u otros tipos de profesionales. Los diferentes métodos por inspección tienen objetivos ligeramente diferentes, pero en

todos ellos se tienen en cuenta las opiniones, juicios, informes de los inspectores sobre elementos específicos de la interfaz como factor fundamental de la evaluación de la usabilidad. Entre los métodos más comunes se encuentran: La Evaluación Heurística, Recorrido de la usabilidad plural, Recorridos cognitivos e inspecciones de estándares. Evaluación heurística La evaluación heurística fue desarrollada por NIELSEN y MOLICH. La evaluación heurística consiste en analizar la conformidad de la interfaz con unos principios reconocidos de usabilidad (la “heurística”) mediante la inspección de varios evaluadores expertos. Se utilizan expertos para validar la interfaz porque es difícil que el desarrollador ò un evaluador pueda encontrar todos los problemas de usabilidad en una interfaz, a partir de unos criterios definidos. Es posible mejorar perceptiblemente la eficacia del método implicando a varios evaluadores. Es verdad que algunos problemas de usabilidad son muy fáciles de encontrar, pero hay también problemas difíciles de detectar. Además, no es fácil identificar al mejor evaluador y confiar solamente en los resultados de esa persona y por otra parte no siempre es verdad que el mismo evaluador sea el mejor para diferentes evaluaciones. En definitiva, en cualquier evaluación heurística es necesario implicar a varios evaluadores. Se recomienda normalmente utilizar de tres a cinco evaluadores ya que se consideran suficientes y la inclusión de un mayor número de los mismos no garantiza una mejora en el resultado. La evaluación heurística se lleva a cabo realizando por parte de cada evaluador una revisión de la interfaz. Cuando se han terminado todas las evaluaciones se permite a los evaluadores comunicar los resultados y sintetizarlos. Este procedimiento es importante para asegurar evaluaciones independientes e imparciales de cada evaluador. Los resultados de la evaluación se pueden registrar como informes escritos de cada evaluador o haciendo que los evaluadores comuniquen verbalmente sus comentarios a un observador mientras inspeccionan la interfaz.

Los informes escritos tienen la ventaja de presentar un expediente formal de la evaluación, pero requieren un esfuerzo adicional para los evaluadores y la necesidad de leerlo y diseñar un documento que integre el trabajo de todos los evaluadores por parte del encargado de la evaluación. Recurrir a un observador agrega un coste en los gastos indirectos de cada sesión de la evaluación, pero reduce la carga de trabajo de los evaluadores. Además esto supone que los resultados de la evaluación están disponibles enseguida después de haber realizado la evaluación, puesto que el observador necesita solamente entender y ordenar un conjunto de notas personales, no el conjunto de los informes escritos por otros. Además, el observador puede asistir a los evaluadores en el funcionamiento de la interfaz en caso de que se encuentren problemas tales como un prototipo inestable, y puede ayudar a los evaluadores si tienen poco conocimiento del entorno en que están trabajando y necesitan que se les explique determinados aspectos de la interfaz. 10 reglas heurísticas de usabilidad Conjunto revisado de reglas heurísticas de usabilidad a partir del análisis de 249 problemas de usabilidad. 1) Visibilidad del estado del sistema. El sistema debe siempre mantener a los usuarios informados del estado del sistema, con una realimentación apropiada y en un tiempo razonable. 2) Utilizar el lenguaje de los usuarios. El sistema debe hablar el lenguaje de los usuarios, con las palabras, las frases y los conceptos familiares, en lugar de que los términos estén orientados al sistema. Utilizar convenciones del mundo real, haciendo que la información aparezca en un orden natural y lógico. 3) Control y libertad para el usuario. Los usuarios eligen a veces funciones del sistema por error y necesitan a menudo una salida de emergencia claramente marcada, esto es, salir del estado indeseado sin tener que pasar por un diálogo extendido. Es importante disponer de deshacer y rehacer 4) Consistencia y estándares. Los usuarios no deben tener que preguntarse si las diversas palabras, situaciones, o acciones significan la misma cosa. En general siga las normas y convenciones de la plataforma sobre la que se está implementando el sistema. 5) Prevención de errores. Es importante prevenir la aparición de errores que mejor que generar buenos mensajes de error. 6) Minimizar la carga de la memoria del usuario. El usuario no debería tener que recordar la información de una parte de diálogo a la otra Es mejor mantener objetos, acciones, y las opciones visibles que memorizar.

7) Flexibilidad y eficiencia de uso. Las instrucciones para el uso del sistema deben ser visibles o fácilmente accesibles siempre que se necesiten. Los aceleradores no vistos por el usuario principiante, mejoran la interacción para el usuario experto de tal manera que el sistema puede servir para usuarios inexpertos y experimentados. Es importante que el sistema permita personalizar acciones frecuentes. 8) Los diálogos estéticos y diseño minimalista. No deben contener la información que sea inaplicable o se necesite raramente. Cada unidad adicional de la información en un diálogo compite con las unidades relevantes de la información y disminuye su visibilidad relativa. 9) Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores. Que los mensajes de error se deben expresar en un lenguaje claro (no haya códigos extraños), se debe indicar exactamente el problema, y deben ser constructivos. 10) Ayuda y documentación. Aunque es mejor si el sistema se pueda usar sin documentación, puede ser necesario disponer de ayuda y documentación. Ésta ha de ser fácil de buscar, centrada en las tareas del usuario, tener información de las etapas a realizar y que no sea muy extensa. Típicamente una sesión de evaluación heurística ha de durar de 1 a 2 horas, en caso de que se realice el test de una interfaz muy compleja se puede dividir en varias sesiones que aborden diferentes aspectos de la interfaz. El resultado de una evaluación heurística es una lista de problemas de usabilidad que han sido transgredidos en el diseño en opinión del evaluador. Recorrido de la usabilidad plural Este método es debido a BIAS y fue desarrollado en los laboratorios IBM. Comparte algunas características con los recorridos tradicionales pero tiene algunas características propias que lo definen. Estas características son las siguientes: 1) Participantes: Este método se realiza con tres tipos de participantes, usuarios representativos, desarrolladores y expertos en usabilidad, que conforman todos los actores implicados en el producto. 2) Las pruebas se realizan con prototipos de papel u otros materiales utilizados en escenarios. Cada participante dispone de una copia del escenario de la tarea con datos que se puedan manipular 3) Todos los participantes han de asumir el papel de los usuarios, por tanto aparte de los usuarios representativos que ya lo son, los desarrolladores y los expertos en usabilidad tambien lo han de asumir. 4) Los participantes han de escribir en cada panel del prototipo la acción que tomarán para seguir la tarea que están realizando, escribiendo las respuestas lo mas detalladas posibles. 5) Una vez que todos los participantes han escrito las acciones que tomarían cuando interactuaban con cada panel, comienza el debate. En primer lugar deben hablar los usuarios representativos y una vez estos han expuesto completamente sus opiniones, hablan los desarrolladores y después los expertos en usabilidad.

Recorrido cognitivo El recorrido cognitivo es un método de inspección de la usabilidad que se centra en evaluar en un diseño su facilidad de aprendizaje, básicamente por exploración y está motivado por la observación que muchos usuarios prefieren aprender software por exploración. El recorrido cognitivo está basado en los recorridos estructurales tradicionales que se usan en la comunidad de la ingeniería de software. En el recorrido cognitivo los revisores evalúan una propuesta de interfaz en el contexto de una o más tareas de esta. En un recorrido partimos inicialmente con un diseño detallado de la interfaz (por ejemplo en forma de prototipo de papel o en un prototipo de software), un escenario, tareas a realizar, un estudio de la población de usuarios y el contexto de uso. Para cada tarea dispondremos mediante los documentos del análisis de tareas de una secuencia de acciones que el usuario tiene que realizar satisfactoriamente para completar la tarea designada, para cada acción el analista explicará la interacción que el usuario puede realizar típicamente con la interfaz, que va a intentar realizar y que acciones están disponibles. Si el diseño de la interfaz es bueno, las intenciones del usuario provocarán que se seleccione la acción apropiada, la interfaz debe presentar una retroalimentación indicando que se están realizando progresos para completar la tarea.  Ambito y limitaciones del método El recorrido cognitivo se centra en un atributo de la usabilidad, la facilidad de aprendizaje, por otra parte este aprendizaje por exploración permite la adquisición de habilidades. El uso del recorrido cognitivo como método de evaluar una interfaz potencia su diseño en la dirección de la facilidad de aprendizaje. Todos los métodos tienen sus puntos fuertes y débiles y creemos que a través del uso de varios métodos nos permitirá tener una buena cobertura de la interfaz. Esta técnica es idónea en la etapa del diseño, pero puede también ser aplicada durante el código, la prueba, y las etapas de distribución. Pasos a realizar Definición de los datos iniciales del recorrido Antes de empezar el análisis del recorrido, se debe estar de acuerdo en estos cuatro aspectos: 1) ¿Quiénes serán los usuarios del sistema? En la descripción de los usuarios se debe incluir la experiencia específica acumulada o el conocimiento técnico que tiene y que puede influenciar a los usuarios cuando intentan ocuparse de la nueva interfaz. Se debe considerar el conocimiento de los usuarios de la tarea y de la interfaz. Un ejemplo de descripción de usuarios es, por ejemplo, “Usuarios de Macintosh que han trabajado con MacPaint”.

2) ¿Qué tarea(s) será analizada? En general, el análisis se debe limitar a una colección razonable pero representativa de tareas de prueba. La selección de las tareas se debe basar en los resultados de los estudios de marketing, análisis de las necesidades, test conceptual y análisis de requisitos. Las tareas de prueba deben ser tan concretas y realistas como sean posibles. La descripción de las tareas debe incluir el contexto necesario, tal como el contenido de las bases de datos que los usuarios se espera que usen y debe reflejar las condiciones típicas bajo las que se aplicará el sistema. 3) ¿Cuál es la secuencia correcta de acciones para cada tarea? Para cada tarea, debe haber una descripción de cómo se espera que el usuario vea la tarea antes de aprender la interfaz. Debe también haber una descripción de la secuencia de las acciones que permiten realizar la tarea con la definición actual de la interfaz. Las acciones de ejemplo pueden ser “presione la tecla RETURN”, “ponga el cursor sobre el menú ‘fichero’”. Puede también puede ser una secuencia de varias acciones simples que un usuario típico puede ejecutar como “Selecciona guardar del fichero de Menú”. El nivel de granularidad de las acciones depende de la experiencia de los usuarios. 4) ¿Cómo se define la interfaz? Debemos disponer de una interfaz que nos permita presentar al usuario todos los elementos interactivos de que dispondrá en la realización de cada acción así como la reacción de la interfaz a cada una de estas acciones. Si disponemos de un sistema implementado ya disponemos de esta información. En el caso de la interfaz se ha puesto en ejecución, toda la información está disponible de la puesta en práctica. Anterior al proceso de desarrollo, la evaluación se puede realizar con una descripción en papel de la interfaz. Para una descripción en papel, el nivel de detalle al definir la interfaz dependerá de la maestría que los futuros usuarios tienen con los sistemas existentes. Recorriendo las acciones La fase de análisis consiste en examinar cada acción que está en el camino de la solución y el procurar contar una historia creíble en cuanto a porqué los usuarios elegirán esa acción. Las historias creíbles se basan en supuestos sobre el conocimiento

y objetivos de base del usuario, y en una comprensión del proceso de resolución del problema que permite a un usuario conjeturar la acción correcta. Mientras que procede al recorrido, los evaluadores hacen las cuatro preguntas siguientes: ¿Los usuarios intentarán alcanzar el objetivo correctamente? Por ejemplo, si la tarea es imprimir un documento, y la primera cosa que tienen que hacer es seleccionar una impresora. ¿Se darán cuenta de que tienen que seleccionar la impresora? ¿El usuario se dará cuenta de que está disponible la acción correcta? Esto se relaciona con la visibilidad y la comprensibilidad de las acciones en la interfaz. ¿El usuario asociará la acción correcta al efecto que se alcanzará? Los usuarios utilizan a menudo la estrategia seguimiento de etiqueta, que los conduce a seleccionar una acción si el texto de la etiqueta para esa acción corresponde con la descripción de la tarea. ¿El usuario verá que se está progresando hacia la solución de la tarea, si se realiza la acción correcta?. Esto es para controlar la realimentación del sistema después de que el usuario ha realizado la acción. El o los evaluadores intentarán construir una historia con éxito para cada paso de progresión en los casos de las tareas. Las condiciones generales para saber si hemos tenido éxito se explican después en “características comunes del éxito”. Cuando fracasamos, se debe realizar una historia del incidente, proporcionando el criterio (uno o más de las cuatro preguntas arriba) y la razón por la que el usuario puede fallar. Recogida de información Mientras se realiza la evaluación, es importante recoger información mientras se vaya produciendo para analizarla después. Un primer método es grabar en vídeo toda la sesión que nos va a permitir revisar posteriormente conversaciones, acciones, etc.. En cuanto a material escrito disponemos de una información inicial que hemos de completar con datos referentes a los éxitos y fracasos de los usuarios en la realización de las acciones necesarias para completar las tareas. Ejemplo Tarea a realizar:  Mover una aplicación a una carpeta nueva o

dispositivo. Quien la realiza:  Usuario de Windows 95. Interfaz:  Sobremesa de Windows 95. Situación de partida:  La carpeta que contiene la aplicación deseada está abierta.  La carpeta o dispositivo de destino es visible. Secuencia de acciones:  Mover el ratón al icono de la aplicación. Éxito: Los usuarios de una IGU saber mover el ratón a un objeto para operar con él.  Pulsar el botón derecho del ratón en el icono de la aplicación. Resultado: El icono de la aplicación se realza. Fallo: El usuario puede no saber que el botón derecho puede ser el que deba utilizarse. ¿Éxito?: El realzado nos muestra que algo ha pasado pero ¿es lo correcto?  Mover ratón al icono de destino. Resultado: El icono de la aplicación sigue al ratón. El icono de destino se realza cuando el ratón llega. Éxito: Arrastrar y soltar es intuitivo (y común de la IGU) para mover. La realimentación es apropiada.  Liberar el botón del ratón. Resultado: Aparece el menú: Mover, Copiar, Crear atajo, Cancelar. Éxito: Al usuario se le plantea la próxima acción.  Mover el ratón a “Mover”. Resultado: Realzado de la selección. Éxito: Interacción de menú IGU estándar.

 Clic del botón del ratón. Resultado: El icono de la aplicación desaparece de debajo del ratón. El icono de la aplicación desaparece de la carpeta original. El icono de la aplicación aparece en la carpeta de destino. Éxito: Selección de menú IGU estándar. La realimentación muestra que el objetivo deseado se ha realizado. Inspección de estándares Este método se realiza por medio de un experto en un estándar que puede ser de facto o de iure de la interfaz. El experto realiza una inspección minuciosa a la interfaz para comprobar que cumple en todo momento y globalmente todos los puntos definidos en el estándar. Indagación: La información acerca de los gustos del usuario, desagrados, necesidades y la identificación de requisitos son informaciones indispensables en una etapa temprana del proceso de desarrollo. Por tanto, inicialmente, hay que descubrir y aprender, hay que generar ideas de diseño, y va a resultar de especial interés que las metodologías a aplicar en una primera fase proporcionen información acerca de la usabilidad de un producto que aún no se ha empezado a fabricar. También es importante obtener información del producto en uso una vez acabado. En este tipo de métodos se realiza hablando con los usuarios, observándolos, usando el sistema en trabajo real (no para un test de usabilidad), o obteniendo respuestas a preguntas verbalmente o por escrito. Métodos de indagación: Observación de campo, Análisis etnográfico, Grupo de discusión dirigido, entrevistas, cuestionarios Observación de campo/ Análisis etnográfico Para realizar una observación de campo el trabajo que se realiza es visitar el lugar o lugares de trabajo donde se estén realizando las actividades objeto de nuestro estudio y donde encontraremos usuarios representativos. El objetivo principal consistirá en observarlos para entender cómo realizan sus tareas y qué clase de modelo mental tienen sobre ellas. También les podremos hacer preguntas para completar esta información. Este método se puede utilizar en las etapas de prueba y del despliegue del desarrollo del producto. Procedimiento Preparación para las visitas del campo Elige una variedad de usuarios representativos del producto, de diversos lugares de trabajo y prepara visitas con estos usuarios.

Elabora la lista de las preguntas que necesitas que te contesten y de los datos que quieres recoger Utilice el sitio de observación y el tiempo con eficacia. Intenta recoger tantos datos como sea posible en los puntos de observación. Se puede hacer el análisis de datos después de volver al despacho Parte de la observación de campo se hace a través de preguntas, es decir entrevistar a los usuarios de su trabajo y la manera como utilizan el producto o realizan sus tareas. Otra parte es observación, observando a las personas utilizar su producto de la manera en que lo hacen normalmente en el día a día. Una manera de asegurar los datos adecuados es identificar tantos artefactos y afloramientos como sea posible. Este método también se denomina observación etnográfica y viene de la antropología. Artefactos son objetos físicos en uso en el sitio (blocs de notas, formularios, informes, espacios, paredes). Los afloramientos son rasgos físicamente identificables que marcan o caracterizan el sitio (tamaño de los cubículos, tamaño de las pizarras y qué es lo que está escrito en ellos, tipos de uniformes). Deben tenerse en cuenta las siguientes etapas: 5) Identificar los artefactos y afloramientos durante la observación /entrevista 6) Coleccionar y marcar in situ 7) Tomar fotos, grabar ficheros en disco, preguntar por la ubicación o esquemas de objetos físicos Representando los datos Cuando usemos los datos para tomar decisiones u opiniones de alternativas de diseño, probar las siguientes representaciones: Muestra el artefacto físicamente y su afloramiento Muestra una foto del artefacto y su afloramiento Muestra un diagrama del artefacto Muestra un dibujo del objeto con las partes etiquetadas Muestra un dibujo del objeto antes y después de su uso Muestra repetidas instancias del artefacto Relaciones de grupo Cuándo podemos usar esta técnica El mejor momento de utilizar esta técnica es en las etapas iniciales del desarrollo de un producto, cuando necesitamos conocer el entorno de trabajo, los objetos, las personas, la organización, los métodos, las tareas que se realizan, etc. Para poder recoger requisitos iniciales y opciones abiertas para incorporar en el diseño preliminar. Por otra parte este método también se puede utilizar en el momento de despliegue, el cual se puede considerar como una etapa inicial de un nuevo diseño. Grupo de discusión dirigido (focus group)

El focus group o grupo de discusión dirigido es una técnica de recolección de datos donde se reúne de 6 a 9 usuarios para discutir aspectos relacionados con el sistema. Un ingeniero de factores humanos hace las veces de moderador, que tiene que preparar la lista de aspectos a discutir y recoger la información que necesita de la discusión. Esto puede permitir capturar reacciones espontáneas del usuario y ideas que evolucionan en el proceso dinámico del grupo. Procedimiento Los procedimientos generales para dirigir un focus group son: Localizar usuarios representativos (típicamente 6 a 9 por focus group) que quieran participar Seleccionar un moderador. Preparar una lista de temas a ser discutidos y objetivos a asumir por los temas propuestos. Controlar la discusión sin inhibir el flujo libre de ideas y comentarios. Asegurar que todos los participantes contribuyen a la discusión. Procurar que no haya un participante que domine la discusión. Conservar la discusión que discurra libremente y no estructurada, pero procura que siga un esquema planeado. Escribir un resumen de las opiniones que han prevalecido y comentarios críticos de la sesión incluyendo cuotas representativas. Aspectos a considerar al dirigir el focus group: Tener más de un grupo principal, puesto que el resultado de una sola sesión puede no ser representativo y una sola discusión pudo haberse centrado en un subconjunto de las ediciones o de los aspectos de menor importancia del sistema. El asesor necesita ser experto en la dinamización y la comunicación del grupo para hacer un grupo principal acertado. No es tan simple como preparando preguntas, porque el asesor necesita facilitar y dirigir la discusión en tiempo real. Los datos recogidos tienden a tener una validez baja y son muy difíciles de analizar debido a su naturaleza no estructurada y de flujo libre. Etapas para ser aplicado: Test y despliegue.

Entrevistas Entrevistar a los usuarios respecto de su experiencia en un sistema interactivo resulta una manera directa y estructurada de recoger información. Además las cuestiones se pueden variar con tal de adaptarlas al contexto. Normalmente, en una entrevista se sigue una aproximación de arriba abajo. Las entrevistas pueden ser efectivas para una evaluación de alto nivel, particularmente para extraer información sobre las preferencias del usuario, impresiones y actitudes. Puede ayudar a encontrar problemas no previstos en el diseño. Para que la entrevista sea lo más efectiva posible, ha de ser preparada con antelación, con todo un conjunto de preguntas básicas. El revisor puede adaptar la entrevista al entrevistado y obtener el máximo beneficio. Cuestionario El cuestionario es menos flexible que la entrevista, pero puede llegar a un grupo más numeroso y se puede analizar con mas rigor. Se puede utilizar varias veces en el proceso de diseño. Hay una serie de tipos de preguntas que se pueden incluir en el cuestionario: 8) General: Preguntas que ayudan a establecer el perfil de usuario y su puesto dentro de la población en estudio. Incluye cuestiones como edad, sexo, ocupación. lugar de residencia y otras. 9) Abierta: Preguntas útiles para recoger información general subjetiva. Pueden dar sugerencias interesantes y encontrar errores no previstos. 10) Escalar: Permite preguntar al usuario sobre un punto específico en una escala numérica. Por ejemplo: El diseño de los iconos es comprensible

Poc 1 2 3 4 5 Mucho o 11) Opción múltiple: En este caso se ofrecen una serie de opciones y se pide responder a una o varias. ¿Que tipo de software has utilizado? Tratamiento de texto Hoja de cálculo Bases de datos Contabilidad 12) Son particularmente útiles para recoger información de la experiencia previa del usuario. Un caso especial es cuando se le dan opciones para contestar si o no. 13) Ordenadas: Se presentan una serie de opciones que hay que ordenar. 14) Ordena la utilidad de como ejecutar una acción: 15) 1 la más útil, 2 la siguiente, etc. 0 si no se utiliza Por iconos Selección de menú Doble clic Ejemplos de cuestionarios En este apartado presentamos el diseño de un cuestionario después de realizar una tarea y después de acabar el test. Cuestionario de post–tarea 1. ¿Ha sido fácil completar la tarea? (Marca la respuesta adecuada) Muy fácil

Fácil

Normal

Difícil

Muy difícil

Comentarios: 2. ¿Has utilizado el manual para completar la tarea? Sí____ No ____ 3. Si has utilizado el manual, ¿la información ha sido fácil de encontrar? Muy fácil Comentarios:

Fácil

Normal

Difícil

Muy difícil

4. ¿La información que encontraste en el manual ha sido fácil de utilizar? Muy fácil

Fácil

Normal

Difícil

Muy difícil

Comentarios: Cuestionario post–test Este cuestionario está diseñado para ver tu opinión respecto del producto. 1. Utilizar el programa ha sido: Muy fácil

Fácil

Normal

Difícil

Muy difícil

Comentarios: 2. Encontrar las características que querías en los menús ha sido: Muy fácil

Fácil

Normal

Difícil

Muy difícil

Comentarios: 3. Comprender los mensajes de los prompts ha sido: Muy fácil

Fácil

Normal

Difícil

Muy difícil

Normal

Difícil

Muy difícil

Normal

Difícil

Muy difícil

Comentarios: 4. La recuperación de errores es: Muy fácil

Fácil

Comentarios: 5. El uso del manual ha sido: Muy fácil

Fácil

Comentario: 6. ¿Te explica el manual todo el ámbito del programa? Si____ No ____ Comentarios: 7. ¿Recomiendas que se compre este producto? 8. Comentario general: Grabación del uso (logging) El logging implica disponer en el ordenador de una ampliación del sistema que recoja automáticamente estadísticas sobre el uso detallado del sistema. Es útil porque muestra cómo los usuarios realizan su trabajo real y porque es fácil recoger automáticamente datos de una gran cantidad de usuarios que trabajan bajo diversas circunstancias. Típicamente, un registro de la interfaz contendrá estadística sobre la frecuencia con la cual cada usuario ha utilizado cada característica en el programa y la frecuencia con

que los diversos eventos de interés (tales como mensajes de error) han ocurrido. La estadística que muestra la frecuencia del uso de comandos y de otras características de sistema se puede utilizar para optimizar características con frecuencias usadas y para identificar las características que se utilizan o no se utilizan raramente. La estadística que muestra la frecuencia de las diversas situaciones de error y el uso de la ayuda en línea se puede utilizar para mejorar la utilidad de los desbloqueos futuros del sistema reajustando las características que causan la mayo parte de los errores y la mayoría del acceso para la ayuda en línea. Esta técnica se puede utilizar en las etapas de prueba o de despliegue. Procedimiento: El registro se realiza generalmente modificando los drivers del sistema, por ejemplo del ratón o del teclado u otras partes del sistema que permitan el registro de las acciones del usuario o modificando la aplicación que estamos probando. Este último método es el preferido ya que hace más fácil registrar acontecimientos de interés. Si los únicos datos disponibles son entrada de información y salida sin procesar, es mucho más difícil analizar los acontecimientos de gran interés para el uso del sistema, tal como situaciones del uso de alguna característica o de error. Si el sistema equipado se ejecuta en una unidad central o en sitios de trabajo con un espacio compartido del fichero, es fácil recoger datos de registro simplemente copiando los ficheros de diario de cada usuario en los intervalos regulares. Si no, puede ser necesario recoger datos de registro a través de correo electrónico automáticamente o pidiendo que los usuarios ejecuten periódicamente un programa que envíe el fichero por correo. Test En los métodos de usabilidad por test, usuarios representativos trabajan en tareas utilizando el sistema ( o el prototipo ) y los evaluadores utilizan los resultados para ver cómo la interfaz de usuario soporta a los usuarios con sus tareas. Tipos de métodos: 1) Medida de prestaciones 2) Test remoto 3) Pensando en voz alta 4) Interacción constructiva 5) Test retrospectivo 6) Método del conductor Medida de prestaciones Un test de medida de prestaciones comparte estas características: El primer objetivo es mejorar la usabilidad del producto. Los participantes representan usuarios reales. Los participantes hacen tareas reales. Se observa y se registra lo que los participantes hacen y dicen. Se analizan los datos, se diagnostican problemas reales y se recomiendan cambios para fijar los problemas.

1) El primer objetivo es mejorar la usabilidad de un producto. El primer objetivo es mejorar la usabilidad de un producto que se está probando y también mejorar el proceso en que se basa el diseño y desarrollo del producto. Esta característica lo distingue de un test de funcionalidad que tiene como objetivo garantizar que el producto funcione de acuerdo con las especificaciones. 2) Los participantes representan usuarios reales. Las personas que hacen el test del producto tienen que ser del grupo de personas que ahora o después utilizará el producto. Un test que utilice programadores cuando el producto está pensado para secretarias no es un test de usabilidad. Si los participantes son mas experimentados que los usuarios actuales, se pueden omitir problemas que provocan que después no entre bien en el mercado. Si los participantes son menos experimentados que los usuarios actuales, podría ocurrir que se hicieran cambios que no representen mejoras para los usuarios reales. 3) Los participantes tienen que hacer tareas reales. Las tareas a tener en cuenta en el test han de ser tareas que los usuarios hacen en el trabajo o en casa. Esto quiere decir que se han de conocer los perfiles de los usuarios y las tareas por las que el producto es relevante. Es evidente que no se podrán probar todas las tareas en un test de usabilidad; tan sólo unas pocas de las que el usuario utilizará con el producto. Por tanto, es importante que las tareas que se prueben sean relevantes para los usuarios y que puedan ocultar problemas de usabilidad. 4) Se observa y se registra lo que los participantes hacen y dicen. Observar y grabar las actividades de los participantes en el test distingue un test de usabilidad de un debate de grupo, encuestas y beta test. En un test de usabilidad tendremos un grupo de personas que trabajarán con el producto. De estas personas grabaremos sus actividades y sus opiniones. Normalmente estas actividades estarán relacionadas con la grabación de tareas y la respuesta a cuestionarios. Un test de usabilidad incluye los dos aspectos: El momento en que los usuarios están realizando tareas con el producto y el tiempo que invierten llenando cuestionarios del producto. 5) Se analizan los datos, se diagnostican problemas reales y se recomiendan cambios para fijar los problemas. Recoger los datos es necesario, pero no es suficiente en un test de usabilidad. Después del test se tienen que analizar los datos y se consideran los datos cualitativos y cuantitativos de los participantes con las observaciones propias y los comentarios del usuario. Se utilizan todos estos datos para diagnosticar y documentar los problemas de usabilidad del producto y las soluciones recomendadas para estos problemas.

Selección de tareas Tareas que demuestren problemas de usabilidad Tareas sugeridas por la propia experiencia

Tareas derivadas de otros criterios Tareas que los usuarios harán con el producto 1) Tareas que demuestren problemas de usabilidad. El criterio más importante para seleccionar tareas es utilizar tareas que prueben los problemas potenciales de usabilidad del producto. Como con cualquier otro procedimiento de test, cuantos más problemas encontremos mejor. 2) Tareas sugeridas por la propia experiencia. Los desarrolladores siempre tienen algunas ideas respecto de dónde encontrar problemas. Saben qué partes del producto fueron más difíciles de diseñar y cuáles son los problemas que se han de probar. 3) Tareas derivadas de otros criterios. Se pueden utilizar otros criterios, como por ejemplo las tareas que son difíciles de recuperar después de un error. 4) Tareas que los usuarios harán con el producto. Se seleccionan tareas habituales en el día a día de los usuarios en orden de optimizar la usabilidad n los aspectos más cotidianos. ¿Cómo medir la usabilidad? Consideraremos cómo planificar las observaciones y medidas para un test de usabilidad. En primer lugar trataremos de comprender qué es lo que se puede medir. En un test de usabilidad podemos recoger: 1) Medidas de rendimiento. Esto quiere decir contar las acciones y los comportamientos que se puedan ver 2) Medidas subjetivas. Esto quiere decir percepciones de las personas, opiniones y juicios Medidas de rendimiento. Las medidas de rendimiento son cuantitativas. Se pueden contar cuántas personas, cuántos errores hacemos, cuántas veces repiten el mismo error. La mayor parte de las medidas de rendimiento requieren observaciones cuidadosas. Ejemplo de medidas de rendimiento en test de usabilidad típicos: tiempo para completar una tarea tiempo consumido en menús de navegación tiempo consumido en ayuda en línea tiempo en buscar información en un manual tiempo invertido en recuperarse de errores número de opciones de menú erróneos número de opciones incorrectas en cajas de dialogo número de selección de iconos incorrectos número de teclas de función mal seleccionadas número de llamadas a la ayuda número de pantallas de ayuda en línea número de veces que se consulta el manual observaciones de frustración

observaciones de confusión observaciones de satisfacción Medidas subjetivas. Las medidas subjetivas pueden ser cuantitativas o cualitativas. Ejemplos de medidas subjetivas en test de usabilidad típicos: Relaciones de:

 facilidad de uso del producto  facilidad de aprender el producto  facilidad de hacer una determinada tarea  facilidad de instalar el producto  facilidad de encontrar información en el manual  facilidad de comprender la información  utilidad de los ejemplos de ayuda

Preferencias o razones de  de una versión previa la preferencia:  sobre un producto de la competencia  de la manera como estamos haciendo las tareas ahora Predicciones comportamiento: Comentarios espontáneos:

de  ¿Comprará el producto?  Estoy totalmente perdido  Ha sido fácil  No comprendo el mensaje

Resultados del test. Un test de usabilidad genera una cantidad importante de datos: Una lista de problemas que han ido creciendo durante la realización del test Datos cuantitativos de tiempo, errores y otras medidas de rendimiento Datos cuantitativos de valoraciones subjetivas y otras cuestiones de cuestionarios post– tarea y post–test Comentarios de los participantes de las grabaciones y de los cuestionarios Las notas escritas del equipo de test o sus comentarios que pueden ser grabados Datos generales de los participantes, de sus perfiles o de cuestionarios de pre–test Las grabaciones de vídeo, presentando diferentes vistas del test El objetivo de un test de usabilidad es encontrar problemas reales con el producto y con el proceso que se ha de utilizar para desarrollar el producto.

Pensando en voz alta (thinking aloud) Descripción En este método de evaluación se les pide a los usuarios que expresen en voz alta sus pensamientos, sentimientos y opiniones mientras que interaccionan con el sistema. Es muy útil en la captura de un amplio rango de actividades cognitivas. Procedimiento Se les proporciona a los usuarios el producto que tienen que probar (o un prototipo de la interfaz) y un conjunto de tareas a realizar y se les dice que realicen las tareas y que expliquen que es lo que piensan al respecto mientras están trabajando con la interfaz. Pensando en voz alta permite a los probadores (testers) comprender cómo el usuario se aproxima a la interfaz y qué consideraciones tiene en la mente cuando la usa. El usuario puede expresar que la secuencia de etapas que le dicta el producto para realizar el objetivo de su tarea es diferente de la que esperaba. Aunque el principal beneficio del protocolo pensando en voz alta es una mejor comprensión del modelo mental del usuario y la interacción con el producto, hay asimismo otros beneficios, por ejemplo, conocer la terminología que el usuario utiliza para expresar una idea o función que debería ir incorporada en el diseño del producto o al menos en su documentación. Interacción constructiva Este método es una derivación del pensando en voz alta e implica el tener en vez de uno, dos usuarios que hagan el test del sistema conjuntamente [OMA94], este método también se denomina aprendizaje por co-descubrimiento. La principal ventaja de este método es que la situación del test es mucho más natural que el pensar en voz alta con usuarios individuales ya que las personas normalmente verbalizan cuando tratan de resolver un problema conjuntamente y además hacen muchos más comentarios. Este método tiene la desventaja que los usuarios pueden tener diferentes estrategias de aprendizaje. Un aspecto a tener en cuenta es que la interacción constructiva requiere el doble de usuarios que el método de pensar en voz alta. Test retrospectivo Si se ha realizado una grabación en vídeo de la sesión de test es posible recoger más información haciendo que el usuario revise la grabación. Los comentarios del usuario mientras está revisando el vídeo son más extensos que mientras ha estado trabajando en la tarea de test y es por tanto posible para el experimentador parar el vídeo y preguntar al usuario con más detalle sin tener miedo de interferir con el test que esencialmente ha sido completado.

El aspecto negativo más obvio es que se tarda como mínimo dos veces más en realizar el test para cada usuario. Método del conductor (coaching method) El método del conductor es algo diferente de estos métodos de test de la usabilidad en la que hay una interacción explícita entre el sujeto del test y el experimentador (o conductor). En la mayor parte de los otros métodos, el experimentador trata de interferir lo menos posible con el que está realizando el test, en este caso es al contrario, se conduce al usuario en la dirección correcta mientras se usa el sistema. Durante el test por conducción al usuario se le permite preguntar cualquier aspecto relacionado con el sistema a un conductor experto que responderá lo mejor que pueda. Una variación del método implica que el conductor es un usuario experto. Este método se centra en el usuario inexperto y su propósito es descubrir las necesidades de información de los usuarios de tal manera que se proporcione un mejor entrenamiento y documentación al mismo tiempo que un posible rediseño de la interfaz para evitar la necesidad de preguntas.

Métodos de evaluación en el ciclo de vida En este apartado se presenta una tabla donde se enumeran los diferentes métodos de evaluación junto con las fases del proceso en que se aplican. Métodos

Etapas del ciclo de vida Requisitos Diseño Codificación

Despliegue

Recorridos plurales Chequeo de escenario

T e s t

sistema

Evaluación heurística

Pensando en voz alta

Recorridos cognitivos

Focus groups

Cuestionarios

Medida de prestaciones Entrevistas

Observación de campo

Estándares

Grabación del uso

Documentación del Sistema La documentación de sistemas es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y para quién lo hacen. La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operando como hacerlo funcionar. Existen varios tipos de documentación. La de programas, que explica la lógica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos; la del usuarios en forma general la naturaleza y capacidades del sistema y cómo usarlo. Muchas organizaciones tienen lo que se conoce como un "programa de documentación", el cual consiste en una política formal cuya documentación se muestra como algo que debe prepararse en forma rutinaria para cada programa de cómputo, archivo y nuevos sistemas. Otra definición sería la de registro físico, generalmente por escrito que contiene los siguientes elementos: Políticas y normas referentes al desarrollo del sistema, su implantación, operación y mantenimiento. El diseño del sistema de información administrativo. Procedimientos para instalar el sistema de información administrativo. Procedimientos para operar el sistema de información administrativo. Procedimientos para mantener el sistema de información administrativo. Importancia De La Documentación De Sistemas La importancia de la documentación bien podría ser comparada con la importancia de la existencia de una Póliza de Seguro; mientras todo va bien no existe la precaución de confirmar si nuestra Póliza de Seguros está o no vigente. La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica l menor tiempo y se le presta menos atención. Siempre se debe documentar un sistema como si estuviera a punto de irse a Siberia el siguiente mes, para nunca volver. Si la documentación del sistema es incompleta el diseñador continuamente estará involucrado y no podrá moverse a otra asignación. La documentación es un conjunto de elementos registrados sobre cualquier soporte que permita instruir o informar acerca de algo, en función de las necesidades específicas de aquellos que la utilizan.

Su Importancia Constituye el respaldo formal de la información. Es el elemento integrador que permite la apreciación unitaria y conjunta del sistema. Facilita el conocimiento, interpretación, comprensión y divulgación del sistema. Constituye un elemento imprescindible para el control interno en general y del sistema en particular; facilita el parámetro de referencia contra el cual se analizará y/o enjuiciará su comportamiento real. Elimina los riesgos de dependencia con respecto a determinados individuos que conocen el sistema. Es un elemento fundamental para la adecuada capacitación de los usuarios del sistema y facilita la comunicación con los mismos. Modelos de formularios utilizados para documentar los sistemas de información:         

Hoja de diseño de archivos o registros Índice de archivos Hoja de diagramación Hoja de diseño de salidas impresas y/o formularios Hoja de diseño de formatos de pantalla Hoja de programación Índice de programas Tabla de decisiones y/o alternativas Hoja de especificaciones del programa

La documentación básica necesaria de un sistema de información deberá contar con: Carpeta de papeles de trabajo (análisis):      

Síntesis del documento de generación Presupuesto o plan de fijación de tareas Documentación del relevamiento detallado Formularios o comprobantes analizados Papeles de trabajo del análisis Estudio de factibilidad y diagnóstico

Carpeta de sistemas (diseño global):   

Fijación de los objetivos del sistema Descripción global del sistema Modelo lógico del sistema (DFD, diccionario de datos, especificación de la lógica)



 

Diseño de entradas y salidas Normas y procedimientos para los usuarios (en operaciones de rutina, de respaldo, de emergencia, de recupero, de uso de backup). Recursos materiales y humanos necesarios Estudio técnico-económico acerca de la posibilidad de procesar el sistema mediante el uso de un computador

Carpeta de programas (diseño detallado):       

Descripción detallista del programa Diagrama de lógica Descripción de entradas Descripción de salidas Descripción de archivos Tablas, cuadros de control de consistencia y parámetros utilizados Controles del programa sobre archivos y datos

Carpeta de operaciones:    

Normas de control de entradas, salidas y de procesamientos Normas de operación, de recupero, de back-up, de seguridad de archivos Cronograma de procesos Descripción de usuarios

En esta tarea se recoge toda la información necesaria para la especificación de la documentación a entregar al usuario, que incluirá los manuales de usuario y, cuando proceda, los manuales de explotación. Para ello, es necesario definir, entre otros, los siguientes aspectos: - Tipo de documentos y estándares a seguir en la elaboración de los mismos. - Formato en el que se desarrollarán. - Estructura. - Soporte en el que se van a generar. - Distribución y mantenimiento de la documentación y copias a editar. - Control de versiones. Productos De entrada

· Catálogo de Requisitos (DSI 1.2) · Diseño de la Arquitectura del Sistema (DSI 7.2) · Entorno Tecnológico del Sistema (DSI 7.2) De salida · Catálogo de Requisitos Prácticas · Catalogación · Sesiones de Trabajo Participantes · Equipo del Proyecto · Usuarios Expertos · Responsable de Operación EL MANUAL DE USUARIO El manual de usuario es un documento técnico de un determinado sistema que intenta dar asistencia que sus usuarios. Los manuales de usuario generalmente son incluidos a dispositivos electrónicos, hardware de computadora y aplicaciones. El manual de usuario puede venir tanto en forma de libro como en forma de documento digital, e incluso poder ser consultado por internet. En general, un manual de usuario debería poder ser entendido por cualquier usuario principiante, como así también serle útil a usuarios avanzados. El manual de usuario tiene como objetivo instruir al usuario en el uso del sistema y la solución de los problemas que puedan suceder en la operación. Un manual de usuario completo suele tener: Introducción

Objetivos del sistema Guía de uso Sección de solución de problemas. E-mail o teléfonos de soporte técnico. Introducción: Debe contener una pequeña descripción del Sistema. Como funciona, para que es, quien lo puede utilizar, etc. Objetivos del Sistema: Trata de enumerar cuales son los propósitos generales del Sistema, para que fue creado, que es lo que se intenta solucionar con él. Guía de Uso: Mediante capturas de pantallas, se le hace conocer al usuario el funcionamiento total del Sistema, para que es que sirve cada elemento del Sistema, y todo lo que involucre su manejo. Sección de Solución de Problemas: Es una pequeña sección en la que incluimos de la manera más explícita qué problemas o dudas con las más comunes que el usuario se puede encontrar y como es que se solucionan. E-mail o teléfonos de soporte técnico: Aquí solamente ponemos los datos de contacto de la persona encargada de proveer el soporte técnico al sistema, ya sea por correo electrónico o por teléfono. MANUAL TÉCNICO El manual técnico va dirigido a la dirección de IT, al administrador del sistema y a otros desarrolladores de software para que puedan darle mantenimiento en caso que se requiera. También puede ser utilizado por el departamento de auditoría de sistemas. Debe contener: Objetivo y alcances del sistema Manual de Normas, políticas y procedimientos de la organización en las que se basa el sistema para su implementación. Descripción de bases de datos y diagramas de relación

Diseño de reportes y pantallas. Objetivo y alcances del sistema: Que es lo que intentamos solucionar con la aplicación del Sistema, y que es lo que en realidad solucionamos, ya que existen ocasiones en las que no se logra por completo solucionar todo lo que habíamos requerido. Manual de Normas, políticas y procedimientos de la organización en las que se basa el sistema para su implementación. Consiste en un listado del reglamento de la organización en la que se va a implementar el sistema. Descripción de bases de datos y diagramas de relación Se muestran las tablas de las bases de datos, con la descripción de cada uno de sus campos, además del diagrama de relación entre las tablas Manual técnico Diseño de Reportes y Pantallas Esta parte consiste únicamente en detallar de la mejor manera posible, como es que están diseñados los reportes y pantallas, que partes las constituyen, etc MANUAL DE PROCEDIMIENTOS Un manual de procedimientos es el documento que contiene la descripción de actividades que deben seguirse en la realización de las funciones de una unidad administrativa, o de dos ò mas de ellas. El manual incluye además los puestos o unidades administrativas que intervienen precisando su responsabilidad y participación. Suelen contener información y ejemplos de formularios, autorizaciones o documentos necesarios, máquinas o equipo de oficina a utilizar y cualquier otro dato que pueda auxiliar al correcto desarrollo de las actividades dentro de la empresa. En él se encuentra registrada y transmitida sin distorsión la información básica referente al funcionamiento de todas las unidades administrativas, facilita las labores de auditoría, la evaluación y control interno y su vigilancia, la conciencia en los empleados y en sus jefes de que el trabajo se está realizando o no adecuadamente. UTILIDAD Permite conocer el funcionamiento interno por lo que respecta a descripción de tareas, ubicación, requerimientos y a los puestos responsables de su ejecución. Auxilian en la inducción del puesto y al adiestramiento y capacitación del personal ya que describen en forma detallada las actividades de cada puesto. Sirve para el análisis o revisión de los procedimientos de un sistema.

Interviene en la consulta de todo el personal. Que se desee emprender tareas de simplificación de trabajo como análisis de tiempos, delegación de autoridad, etc. Para establecer un sistema de información o bien modificar el ya existente. Para uniformar y controlar el cumplimiento de las rutinas de trabajo y evitar su alteración arbitraria. Determina en forma más sencilla las responsabilidades por fallas o errores. Facilita las labores de auditoría, evaluación del control interno y su evaluación. Aumenta la eficiencia de los empleados, indicándoles lo que deben hacer y como deben hacerlo. Ayuda a la coordinación de actividades y evitar duplicidades. Construye una base para el análisis posterior del trabajo y el mejoramiento de los sistemas, procedimientos y métodos. CONFORMACIÓN DEL MANUAL A) IDENTIFICACIÓN Este documento debe incorporar la siguiente información: Logotipo de la organización. Nombre oficial de la organización. Denominación y extensión. De corresponder a una unidad en particular debe anotarse el nombre de la misma. Lugar y fecha de elaboración. Número de revisión (en su caso). Unidades responsables de su elaboración, revisión y/o autorización. Clave de la forma. En primer término, las siglas de la organización, en segundo lugar las siglas de la unidad administrativa donde se utiliza la forma y, por último, el número de la forma. Entre las siglas y el número debe colocarse un guión o diagonal. B) ÍNDICE O CONTENIDO

Relación de los capítulos y páginas correspondientes que forman parte del documento. C) PRÒLOGO Y/O INTRODUCCIÓN Exposición sobre el documento, su contenido, objeto, áreas de aplicación e importancia de su revisión y actualización. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual. D) OBJETIVOS DE LOS PROCEDIMIENTOS Explicación del propósito que se pretende cumplir con los procedimientos. Los objetivos son uniformar y controlar el cumplimiento de las rutinas de trabajo y evitar su alteración arbitraria; simplificar la responsabilidad por fallas o errores; facilitar las labores de auditoría; facilitar las labores de auditoría, la evaluación del control interno y su vigilancia; que tanto los empleados como sus jefes conozcan si el trabajo se está realizando adecuadamente; reducir los costos al aumentar la eficiencia general, además de otras ventajas adicionales. E) AREAS DE APLICACIÓN Y/O ALCANCE DE LOS PROCEDIMIENTOS Esfera de acción que cubren los procedimientos. Dentro de la administración pública federal los procedimientos han sido clasificados, atendiendo al ámbito de aplicación y a sus alcances, en: procedimientos macroadministrativos y procedimientos mesoadministrativos o sectoriales. F) RESPONSABLES Unidades administrativas y/o puestos que intervienen en los procedimientos en cualquiera de sus fases G) POLÍTICAS O NORMAS DE OPERACIÓN En esta sección se incluyen los criterios o lineamientos generales de acción que se determinan en forma explícita para facilitar la cobertura de responsabilidad de las distintas instancias que participaban en los procedimientos. Además deberán contemplarse todas las normas de operación que precisan las situaciones alterativas que pudiesen presentarse en la operación de los procedimientos. A continuación se mencionan algunos lineamientos que deben considerarse en su planteamiento: Se definirán perfectamente las políticas y/o normas que

circunscriben el marco general de actuación del personal, a efecto de que esté no incurra en fallas. Los lineamientos se elaboran clara y concisamente, a fin de que sean comprendidos incluso por personas no familiarizadas con los aspectos administrativos o con el procedimiento mismo. Deberán ser lo suficientemente explícitas para evitar la continua consulta a los niveles jerárquicos superiores. H) CONCEPTO (S) Palabras o términos de carácter técnico que se emplean en el procedimiento, las cuales, por su significado o grado de especialización requieren de mayor información o ampliación de su significado, para hacer más accesible al usuario la consulta del manual. I) PROCEDIMIENTO (descripción de las operaciones). Presentación por escrito, en forma narrativa y secuencial, de cada una de las operaciones que se realizan en un procedimiento, explicando en qué consisten, cuándo, cómo, dónde, con qué, y cuánto tiempo se hacen, señalando los responsables de llevarlas a cabo. Cuando la descripción del procedimiento es general, y por lo mismo comprende varias áreas, debe anotarse la unidad administrativa que tiene a su cargo cada operación. Si se trata de una descripción detallada dentro de una unidad administrativa, tiene que indicarse el puesto responsable de cada operación. Es conveniente codificar las operaciones para simplificar su comprensión e identificación, aun en los casos de varias opciones en una misma operación. J) FORMULARIO DE IMPRESOS. Formas impresas que se utilizan en un procedimiento, las cuales se intercalan dentro del mismo o se adjuntan como apéndices. En la descripción de las operaciones que impliquen su uso, debe hacerse referencia específica de éstas, empleando para ello números indicadores que permitan asociarlas en forma concreta. También se pueden adicionar instructivos para su llenado. K) DIAGRAMAS DE FLUJO. Representación gráfica de la sucesión en que se realizan las operaciones de un procedimiento y/o el recorrido de formas o materiales, en donde se muestran las unidades administrativas (procedimiento general), o los puestos que intervienen (procedimiento detallado), en cada operación descrita. Además, suelen hacer mención del equipo o recursos utilizados en cada caso. Los diagramas representados en forma sencilla y accesible en el manual, brinda una descripción clara de las operaciones, lo que facilita su comprensión. Para este efecto, es aconsejable el empleo de símbolos y/o gráficos simplificados. L) GLOSARIO DE TÉRMINOS. Lista de conceptos de carácter técnico relacionados con el contenido y técnicas de elaboración de los manuales de procedimientos, que sirven

de apoyo para su uso o consulta. Procedimiento general para la elaboración de manuales administrativos FASE DE IMPLEMENTACIÓN Comprende la adquisición e integración de los recursos físicos y conceptuales, en esta fase se ejecutan todas las instalaciones y adiestramiento necesario para poder colocar el sistema en modo funcional En esta fase se siguen los siguientes pasos: Planificación de la implementación, Anuncio de la implementación del nuevo sistema, Adquisición del hardware, Adquisición del software, Preparación de la base de datos, Preparación de las instalaciones físicas, Capacitación a los usuarios y participantes, Preparación del proceso de corte y cambio del uso y Corte y cambio al nuevo sistema FASE DE USO Y MANTENIMIENTO Esta es la etapa final del ciclo de desarrollo de sistemas. En esta fase se pone en ejecución todo el trabajo realizado por parte de analistas y usuarios, Comprende: supervisión, evaluación y modificación de un sistema en el momento que deje de ser efectivo para las nuevas tareas que ocurran en un futuro. En esta fase se siguen los siguientes pasos: Uso del sistema, para cumplir con los objetivos propuestos, Auditoria del sistema, Mantenimiento del sistema y Formulación de propuestas de reingeniería.

OBJETIVOS DEL SISTEMA DE ADIESTRAMIENTO: Incrementar la productividad. Promover la eficiencia del trabajador, sea obrero, empleado o funcionario. Proporcionar al trabajador una preparación que le permita desempeñar puesto de mayor responsabilidad. Promover un ambiente de mayor seguridad en el empleo. Ayudar a desarrollar condiciones de trabajo más satisfactorias, mediante los intercambios personales surgidos con ocasión del adiestramiento. Promover el mejoramiento de los sistemas y procedimientos. Contribuir a reducir los movimientos de personal, tales como renuncias, destituciones y otros. Reducir el costo del aprendizaje. Promover el mejoramiento de las relaciones públicas de la institución, y de los sistemas de comunicación internos. Contribuir a reducir las quejas del empleado y a proporcionar una moral de trabajo más elevada. Facilitar la supervisión de personal. Promover los ascensos sobre la base del mérito personal. Contribuir a la reducción de los accidentes de trabajo. Reducir el costo de operación. DETECCIÓN DE NECESIDADES DE ADIESTRAMIENTO Es un proceso mediante el cual se establecen los requerimientos de adiestramiento para el personal que labora en la organización para programar las diferentes acciones de adiestramiento. OBJETIVOS: elaborar la planificación, programación y ejecución de los programas de adiestramiento, que permiten adecuar al trabajador para el ejercicio de determinada función o para la ejecución de tareas específicas establecidos por la organización en cada puesto de trabajo.

PLANIFICACIÓN DEL ADIESTRAMIENTO Es la integración del conjunto de actividades, medios y recursos en una estructura de acción, de acuerdo a los objetivos propuestos, para mejorar el desempeño de los trabajadores de la organización a través de la realización de actividades de adiestramiento. PLAN ANUAL: es el documento que recoge el total de las acciones de adiestramiento cuya ejecución esta prevista en un plazo determinado, considerando los recursos. RECURSOS: son los elementos fundamentales para la elaboración de un plan (humano, financiero, materiales y de tiempo). El programa de entrenamiento exige una planeación que incluya los siguientes aspectos: Enfoque de una necesidad especifica cada vez. Definición clara del objetivo de entrenamiento. División del trabajo por desarrollar, en módulos, paquetes o ciclos. Determinación del contenido del entrenamiento. Elección de los métodos de entrenamiento y de la tecnología disponible. Definición de los recursos necesarios para la implementación del entrenamiento, como el tipo de entrenador o instructor, recursos audiovisuales, maquinas, equipos o herramientas necesarias, materiales, manuales, etc. Definición de la población objetivo, es decir, el personal que va a ser entrenado, considerando lo siguiente: Número de personas. Disponibilidad de tiempo. Grado de habilidad, conocimientos y tipos de actitudes. Características personales de comportamiento. Lugar donde se afectará el entrenamiento, considerando también el horario más oportuno o la ocasión más propicia. Época o periodicidad del entrenamiento, considerando también el horario más oportuno o la ocasión más propicia.

Calculo de la relación costo-beneficio del programa. Control y evaluación de los resultados, considerando la verificación de puntos críticos que requieren ajustes o modificaciones en el programa para mejorar su eficacia. EJECUCIÓN Y DESARROLLO DEL ADIESTRAMIENTO (PRESUPUESTOS) La ejecución del entrenamiento presupone el binomio instructor/aprendiz. Los aprendices son personas situadas en cualquier nivel jerárquico de la empresa, que necesitan aprender o mejorar los conocimientos que tienen sobre alguna actividad o trabajo. Los instructores son personas situadas en cualquier jerárquico de la empresa, expertos o especializados en determinada actividad o trabajo, que transmiten sus conocimientos a los aprendices. Los auxiliares, jefes o gerentes pueden ser aprendices; así mismos pueden ser instructores, cargo que también puede desempeñar el encargado o gerente de entrenamiento. Además, el entrenamiento presupone una relación instrucción/aprendizaje. Instrucción es la enseñanza originada de cierta tarea o actividad; aprendizaje es la incorporación del o enseñado a comportamiento del individuo. Por tanto, aprender es modificar el comportamiento gracias a lo enseñado. La ejecución del entrenamiento depende de lo siguientes elementos: Adecuación del programa de entrenamiento al as necesidades de la organización. Calidad del material de entrenamiento presentado. Cooperación de los jefes y dirigentes de la empresa. Calidad y preparación de los instructores. Calidad de los aprendices. EVALUACIÓN Y SEGUIMIENTO DEL ADIESTRAMIENTO (CONTROL) La etapa final del proceso de entrenamiento es la evaluación de los resultados obtenidos. Es necesario evaluar la eficiencia del programa de entrenamiento. Esta evaluación debe considerar dos aspectos: Determinar si el entrenamiento produjo las modificaciones deseadas en el Comportamiento de los empleados. Verificar si los resultados del entrenamiento presentan relación con la consecución de las metas de la empresa.

Además de estos dos aspectos, es necesario determinar si las técnicas de entrenamiento empleadas son efectivas. La evaluación de los resultados del entrenamiento puede hacerse en tres niveles: En el nivel organizacional. En este nivel, le entrenamiento debe proporcionar resultados como: Aumento en la eficacia organizacional. Mejoramiento en la imagen de la empresa. Mejoramiento en el clima organizacional. Mejores relaciones entre la empresa y sus empleados. Facilidad en los cambios y en la innovación. En el nivel de los Recursos Humanos. Reducción de la a rotación de personal. Disminución del ausentismo. Aumento de la a eficiencia individual de los empleados. Aumento de las habilidades de las personas. Elevación del conocimiento de las personas. En el nivel de las tareas y obligaciones. Aumento de la productividad. Mejoramiento de la calidad de los productos y servicios. Reducción del ciclo de la producción. Mejoramiento de la atención al cliente. Reducción de índices de accidente. Desde un punto de vista más amplio, el entrenamiento parece una respecta lógica a un marco de condiciones ambientales mutables y a nuevos requisitos para la supervivencia y el crecimiento organizacional.

Tipos de adiestramiento Es la orientación general, que se le da al empleado para adecuarlo al puesto, al grupo y a la institución. Este tipo de formación tiene por meta crear una actitud favorable del empleado y facilitar su proceso de integración. Adiestramiento a través de la experiencia: consiste en reunir un grupo de personas en base a tareas o áreas similares para intercambiar experiencias, métodos, recursos y otros. En tales espacios se debe establecer un flujo informativo precisando objetivos, expectativas, dinámicas, metodología, aspectos organizativos y el código para el análisis. Este tipo de formación podría ser muy útil, ya que de la experiencia de los individuos o grupos se enriquece el trabajo y se comparten vivencias muy significativas. Adiestramiento "en" y "para" la organización: consiste en desarrollar al máximo el potencial humano de la institución por vía de la implementación de un sistema de educación permanente que abarque las siguientes etapas: Preparación y actualización para el mejor desempeño del cargo. Preparación para otros cargos que pudiera ocupar el empleado. Preparación para el desarrollo general integral. La capacitación en las instituciones deben basarse en las siguientes condiciones: Las necesidades de las personas. El crecimiento individual La participación como aprendizaje activo. La capacidad para dar respuestas a necesidades de la realidad y la posibilidad de aplicarlas a la vida cotidiana. Los conocimientos y experiencias de los participantes, revalorizando y reforzando el aprendizaje existente e incorporando nuevos conocimientos. El aprendizaje en equipo que permite mayor posibilidad de interacción e intercambio. Centros de adiestramiento y especializados: habiendo procesado de antemano las necesidades actuales y futuras del personal, se puede ofrecer la oportunidad de formación y entrenamiento en un centro de capacitación, para que el empleado asuma con mayor responsabilidad y eficacia el trabajo que desempeña.

¿Por qué es importante la el análisis de costos y usabilidad? El uso de un modelo de proceso centrado en el usuario supone unos beneficios respecto al modelo que no considera la usabilidad. Mayhew y Mantei nos describen estos beneficios desde un punto de vista interno y de ventas. En los siguientes apartados presentamos una descripción de estos beneficios organizados en tres áreas: Ventas, uso interno y desarrollo Desarrollo Reducción de los costes de producción: Todo y que en un principio parece lo contrario, los costes y tiempos de desarrollo totales pueden ser reducidos evitando el sobre–diseño y reduciendo el número de cambios posteriores requeridos en el producto. Reducción de los costes de mantenimiento y apoyo: Los sistemas que son fáciles de usar requieren menos entrenamiento, menos soporte para el usuario y menos mantenimiento. Uso interno Reducción de los costes de uso: Los sistemas que mejor se ajustan a las necesidades del usuario mejoran la productividad y la calidad de las acciones y las decisiones. Los sistemas más fáciles de utilizar reducen el esfuerzo y permiten a los usuarios manejar una variedad más amplia de tareas. Los sistemas difíciles de usar disminuyen la salud, bienestar y motivación y pueden incrementar el absentismo. Tales sistemas suponen pérdidas en los tiempos de uso y no son explotados en su totalidad en la medida en que el usuario pierde interés en el uso de las características avanzadas del sistema, que en algunos casos podrían no utilizarse nunca. Ventas Incremento de las ventas. Un producto más usable permite un mejor marketing debido a la mejor imagen del producto, es mas compresible, con lo que aumenta las ventas Mejora en la calidad del producto: El diseño centrado en el usuario da lugar a o deriva en aplicaciones de mayor calidad de uso, más competitivos en un mercado que demanda productos de fácil uso. Menor soporte al cliente. Los sistemas usables son mas fáciles de aprender y de utilizar, por tanto implican un menor coste de implantación. En muchos casos estos beneficios han podido calcularse en términos económicos. Por ejemplo, Brad Myers (Carnegie Mellon University) refiere: Un estudio demostró que el ahorro conseguido como consecuencia del desarrollo de una buena interfaz de usuario fue de 41.700 dólares en una aplicación sencilla utilizada por 23.000 empleados, y de 6.800.000 dólares para una aplicación compleja utilizada por 240.000 empleados. S. Dray (Dray & Associates.) refiere lo siguiente: Un estudio de la compañía NCR mostró un incremento en la producción del 25% y una reducción adicional del número de errores también del 25%, como resultado del nuevo diseño de las interfaces de usuario.

Para poder completar este trabajo habríamos de establecer una relación de costes adicionales que supone el uso de la ingeniería de la usabilidad en el modelo de proceso y valorar los beneficios que suponen para cada uno de los apartados que hemos considerado. Pruebas del Sistema Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o requerimientos. Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito, mensurables para el producto.

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. Son pruebas de integración del sistema de información completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento en el entorno de producción.

Tipos de pruebas Se distinguen los siguientes tipos de pruebas: Pruebas de Usabilidad Se centran en: Factores humanos, Estética, Consistencia con la interfaz de usuario, Ayudas en línea y “context sensitive”, Wizards y agentes, Documentación para el usuario Materiales de entrenamiento. Pruebas Funcionales: Se enfoca a validar funcionalidades específicas provistas por servicios requeridos, métodos, o casos de uso. Estas pruebas se implementan y ejecutan a nivel de unidades, unidades integradas, aplicaciones y sistemas. Pruebas de Seguridad: Pruebas enfocadas en asegurar que la data o el sistema puede seraccesado solamente por aquellos actores autorizados. Pruebas de Volumen: Pruebas enfocadas en la verificación de la habilidad de manejar grandes cantidades de data, bien sea como entrada, salida o residente en una base de datos. Pruebas de Confiabilidad: Pruebas de Integridad: Se enfocan en probar la robustez (resistencia a fallas) y el uso adecuado del lenguaje, sintaxis y uso de recursos. Este tipo de prueba puede aplicarse tanto a unidades como a integración de unidades. Pruebas de Estructura: Estas pruebas se enfocan en hallar problemas de adherencia del elemento objetivo a su diseño y formación. Típicamente, estas pruebas se realizan sobre aplicaciones Web, asegurando que todos los enlaces están conectados, los controles adecuados se muestran, y no hay contenido inaccesible. Pruebas de Stress: Este tipo de prueba se enfoca a evaluar el comportamiento del sistema baso condiciones anormales. Stress del sistema se refiere a extrema carga, memoria insuficiente, no disponibilidad de servicios y hardware o recursos compartidos limitados. Este tipo de prueba permite comprender mejor cómo y qué áreas del sistema colapsarán, de este modo es posible planificar contingencias y actualizar el mantenimiento y planear y asignar recursos de antemano.

Pruebas de Benchmark: Compara el desempeño del elemento objetivo de la prueba con un sistema conocido y una carga de trabajo definida. Pruebas de Contención: Validar que el elemento que se adecuadamente cuando muchos actores solicitan el mismo recurso.

prueba

maneja

Pruebas de Carga: Validar y evaluar aceptabilidad de un elemento de un sistema sobre diferentes cargas de trabajo mientras el sistema permanece constante. Generalmente se incluye simulación de cargas de trabajo promedio y pico que puedan ocurrir dentro de la tolerancia operacional normal. Pruebas de Perfil de Desempeño: Monitorea el perfil en el tiempo incluyendo flujo de ejecución, acceso a data, llamadas a funciones para identificar cuellos de botella y procesos Pruebas de Configuración: Se enfocan en evaluar aquellos elementos configurados para diferentes hardware y/o configuraciones de software. Pueden implementarse como pruebas de rendimiento del sistema. Pruebas de Instalación: Se enfoca en evaluar que el elemento a probar se instala como se indica, en diferentes hardware y /o configuraciones de sistemas de software y bajo diferentes condiciones (tales como espacio insuficiente en disco, interrupción de electricidad). Este tipo de prueba se aplica y ejecuta sobre aplicaciones y sistemas. PRUEBAS ALFA Y BETA Cuando se construye software a medida para un cliente, se lleva a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. La mayoría de los desarrolladores de productos de software llevan a cabo un proceso denominado pruebas alfa y beta para descubrir errores que parezca que sólo el usuario final puede descubrir. Prueba alfa: se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las

pruebas alfa se llevan a cabo en un entorno controlado.

Prueba beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. La implantación es el proceso de verificar e instalar el nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes.

El manual de usuario El manual de usuario es un documento técnico de un determinado sistema que intenta dar asistencia que sus usuarios. Los manuales de usuario generalmente son incluidos a dispositivos electrónicos, hardware de computadora y aplicaciones. El manual de usuario puede venir tanto en forma de libro como en forma de documento digital, e incluso poder ser consultado por internet. En general, un manual de usuario debería poder ser entendido por cualquier usuario principiante, como así también serle útil a usuarios avanzados.

El manual de usuario tiene como objetivo instruir al usuario en el uso del sistema y la solución de los problemas que puedan suceder en la operación. Un manual de usuario completo suele tener: IntroducciónObjetivos del sistemaGuía de usoSección de solución de problemas.E-mail o teléfonos de soporte técnico. Introducción: Debe contener una pequeña descripción del Sistema.Como funciona, para que es, quien lo puede utilizar, etc.

Objetivos del Sistema: b Trata de enumerar cuales son los propósitos generales del Sistema, para que fue creado, que es lo que se intenta solucionar con él. Guía de Uso: Mediante capturas de pantallas, se le hace conocer al usuario el funcionamiento total del Sistema, para que es que sirve cada elemento del Sistema, y todo lo que involucre su manejo. Sección de Solución de Problemas: Es una pequeña sección en la que incluimos de la manera más explícita qué problemas o dudas con las más comunes que el usuario se puede encontrar y como es que se solucionan. E-mail o teléfonos de soporte técnico: Aquí solamente ponemos los datos de contacto de la persona encargada de proveer el soporte técnico al sistema, ya sea por correo electrónico o por teléfono. Manual técnico El manual técnico va dirigido a la dirección de IT, al administrador del sistema y a otros desarrolladores de software para que puedan darle mantenimiento en caso que se requiera.También puede ser utilizado por el departamento de auditoría de sistemas. Manual de procedimientos Un manual de procedimientos es el documento que contiene la descripción de actividades que deben seguirse en la realización de las funciones de una unidad administrativa, o de dos ò mas de ellas. El manual incluye además los puestos o unidades administrativas que intervienen precisando su responsabilidad y participación.

Suelen contener información y ejemplos de formularios, autorizaciones o documentos necesarios, máquinas o equipo de oficina a utilizar y cualquier otro dato que pueda auxiliar al correcto desarrollo de las actividades dentro de la empresa. En él se encuentra registrada y transmitida sin distorsión la información básica referente al funcionamiento de todas las unidades administrativas, facilita las labores de auditoría, la evaluación y control interno y su vigilancia, la conciencia en los empleados y en sus jefes de que el trabajo se está realizando o no adecuadamente.

Utilidad Permite conocer el funcionamiento interno por lo que respecta a descripción de tareas, ubicación, requerimientos y a los puestos responsables de su ejecución. Auxilian en la inducción del puesto y al adiestramiento y capacitación del personal ya que describen en forma detallada las actividades de cada puesto. Sirve para el análisis o procedimientos de un sistema.

revisión

los

Ayuda a la coordinación de actividades y evitar duplicidades. Construye una base para el análisis posterior del trabajo y el mejoramiento de los sistemas, procedimientos y métodos. Conformación del manual A) IDENTIFICACIÓN

B) ÍNDICE O CONTENIDO C) PRÒLOGO INTRODUCCION

Y/O

D) OBJETIVOS DE PROCEDIMIENTOS

LOS

E) AREAS DE APLICACIÓN Y/O ALCANCE DE LOS PROCEDIMIENTOS F) RESPONSABLES G) POLÍTICAS O NORMAS DE OPERACIÓN H) CONCEPTO (S) I) PROCEDIMIENTO (descripción de las operaciones). J) FORMULARIO DE IMPRESOS. K) DIAGRAMAS DE FLUJO. L) GLOSARIO DE TÉRMINOS. Análisis de Costos y beneficios del sistema. El análisis de costo-beneficio es un término que se refiere tanto a - Una disciplina formal (técnica) a utilizarse para evaluar, o ayudar a evaluar, en el caso de un proyecto o propuesta, que en sí es un proceso conocido como evaluación de proyectos; - Un planteamiento informal para tomar decisiones de algún tipo, por naturaleza inherente a toda acción humana.

Bajo ambas definiciones, el proceso involucra, ya sea explícita o implícitamente, un peso total de los gastos previstos en contra del total de los beneficios previstos de una o más acciones con el fin de seleccionar la mejor opción o la más rentable. Muy relacionado, pero ligeramente diferentes, están las técnicas formales que incluyen análisis costo-eficacia y análisis de la eficacia del beneficio. El costo-beneficio es una lógica o razonamiento basado en el principio de obtener los mayores y mejores resultados al menor esfuerzo invertido, tanto por eficiencia técnica como por motivación humana. Se supone que todos los hechos y actos pueden evaluarse bajo esta lógica, aquellos dónde los beneficios superan el costo son exitosos, caso contrario fracasan. El análisis de costo-beneficio es una técnica importante dentro del ámbito de la teoría de la decisión. Pretende determinar la conveniencia de proyecto mediante la enumeración y valoración posterior en términos monetarios de todos los costos y beneficios derivados directa e indirectamente de dicho proyecto. Este método se aplica a obras sociales, proyectos colectivos o individuales, empresas privadas, planes de negocios, etc., prestando atención a la importancia y cuantificación de sus consecuencias sociales y/o económicas.

El análisis de costo-beneficio se utiliza en la biología evolutiva para evaluar los costos y beneficios de los rasgos. Por ejemplo, un ecologista de comportamiento puede utilizar el enfoque de costo-beneficio para explicar la evolución del juego en el comportamiento de los animales jóvenes. Los costos incluyen el perjuicio y el aumento de la vulnerabilidad de la depredación, mientras que los beneficios pueden incluir la mejora de una determinada habilidad importante en futuros éxitos. Desviaciones de las predicciones basadas en el análisis de

costo-beneficio pueden poner de relieve los factores no considerados por el investigador.

¿Como debes proyectar tu negocio? Las empresas pequeñas y medianas deben saber cómo guiar su crecimiento, dice José L. González Narro; hay herramientas que te ayudan a saber si una inversión te conviene a futuro o perderás dinero. ¿A qué empresario no le ha sucedido que posterior a la ilusión de hacer una nueva inversión, experimente la decepción por el hecho de que esa inversión no alcanzó los objetivos imaginados inicialmente? Generalmente, los empresarios tienen la ilusión de progresar,…de crecer sus ventas, su productividad, sus rendimientos, y suelen realizar inversiones de capital para mejorar sus capacidades y lograr esos objetivos. La mayoría de la literatura de finanzas y de evaluación de proyectos se enfoca en lectores que ya tienen ciertas bases en el tema y normalmente intentan considerar todas las variables, lo que añade complejidad. Esto agrega valor para los ejecutivos en finanzas que trabajan en grandes compañías, pero hace que esta literatura sea inaccesible para el micro y pequeño empresario común que necesita realizar evaluaciones privadas y con información y medios limitados. Las necesidades de los pequeños empresarios son distintas. El análisis para la evaluación de un proyecto de inversión debe simplificarse, haciendo uso primero del sentido común, y luego de ciertas herramientas que ayuden a realizar una evaluación metodológica racional, con la finalidad de reducir la incertidumbre.

Antes de pensar en hacer una inversión de capital, es muy importante tener muy claro cuál es la necesidad de nuestra empresa y qué se necesita para atenderla. Una vez ideada la inversión que creemos necesitar, debemos tener claro dónde y cómo encaja esa nueva máquina, ese nuevo camión, esa nueva línea de producto, en nuestro negocio actual, y cómo va a ayudar para generar sinergias. Cabe mencionar la definición de proyecto propuesta por el Dr. Ernesto Fontaine “un proyecto es la fuente de costos y beneficios que ocurren en distintos periodos de tiempo”. Debemos encontrarle el sentido a la inversión que queremos hacer, …un sentido que sea congruente con el negocio para después, iniciar el proceso de identificación, cuantificación y valoración de los costos y beneficios. Una vez acreditada la viabilidad de la idea de inversión mediante una evaluación previa con base en el sentido común, se deben realizar estudios de mercado, técnicos, ambientales, legales y económicos para corroborar la factibilidad del proyecto. Salvado lo anterior se puede iniciar el análisis de gestión del financiamiento, a través del cual se define el costo de la inversión y se intenta pronosticar los flujos de efectivo que causará el proyecto: positivos como incremento en ventas y reducción de costos actuales, y negativos como la inversión por si misma, los nuevos costos de mantenimiento y la nueva fuerza laboral. Es de especial utilidad dibujar una línea de tiempo que considere el horizonte de valuación (el tiempo entre que se realiza la inversión y se concluyen los costos y beneficios derivados de ésta), en la que se identifiquen los ingresos y los egresos implicados de manera gráfica, colocando a los egresos con flechas hacia afuera de la línea y a los ingresos con flechas hacia adentro (ver Figura 1 siguiente). Entendidos los flujos de efectivo, podemos iniciar con el uso de ciertas herramientas relativamente sencillas para evaluar cuantitativamente los beneficios de un proyecto, y compararlos con los de proyectos alternativos. Por su simplicidad y accesibilidad, se proponen 6 herramientas:

1. Valor Presente Neto (“VPN”) y Tasa Interna de Retorno (“TIR”) Son la base para la evaluación financiera de un proyecto. Se consideran como una misma técnica porque en realidad es el mismo método, pero expresado en distintos términos. Ambas consideran el valor del dinero en el tiempo (no vale lo mismo un peso hoy que el mismo peso dentro de un año). El VPN indica el valor hoy, de flujos de efectivo (positivos y negativos) a percibirse en el futuro. Para calcularse se necesita saber (1) el monto y tiempo de los flujos de efectivo (de acuerdo a la línea de tiempo dibujada) y (2) la tasa de descuento, que es la tasa que representa el costo de oportunidad. En México, la tasa social de descuento autorizada por la Secretaría de Hacienda y Crédito Público para proyectos de inversión pública es del 12%, aunque la tasa a la que una PyME debe descontar es la tasa promedio a la que se fondea (ponderado), con un tope mínimo en la tasa a la que tendría acceso al invertir en otros instrumentos libres de riesgo (pagaré bancario). Cabe mencionar que debe de tomarse en cuenta el valor Terminal de la inversión. Es decir, el precio al que podría venderse esa máquina o ese camión, al término del horizonte de valuación. Para calcular el VPN debe restarse el monto de la inversión inicial de la suma de todos los flujos futuros descontados, esto es (ver Figura 2):

En caso de utilizar el Excel, la función es =VAN (Valor Actual Neto), pero debe cuidarse de no incluir la inversión inicial dentro de la función y en cambio, restarla aparte, ya que la función descuenta el primer valor en el periodo 1, y no en el 0, que es el tiempo real en que se eroga la inversión. El criterio de decisión es que se acepta el proyecto cuando el VPN es positivo, y se rechaza cuando es cero o negativo. Por su parte, la TIR es la tasa de descuento que al sustituirla en la fórmula del VPN, éste se hace cero. El criterio de aceptación indica que la TIR debe de ser mayor a la tasa mínima aceptable de rendimiento, que es al menos el costo del fondeo (o la tasa libre de riesgo). La función en Excel es =TIR, aunque también se puede utilizar la herramienta “buscar objetivo”, una vez formuladas las variables.

Es imprescindible considerar estos dos conceptos de manera paralela, dado que un VPN mayor no necesariamente significa una TIR mayor. Eso depende de los tiempos en que se perciban los flujos. Puede darse el caso de que el criterio de aceptación del VPN sea positivo y el de la TIR sea negativo, por lo que además de hacer un análisis cualitativo de los motivos, es necesario considerar otras alternativas de evaluación. 2. Análisis de sensibilidad No existen métodos perfectos de evaluación de proyectos de inversión, por lo que el riesgo de tomar una mala decisión se disminuye considerablemente cuando se utilizan más de una herramienta. Utilizando el análisis de sensibilidad podemos disminuir la incertidumbre y anticipar los efectos si una o más variables cambian en el tiempo. Este análisis se realiza al nivel del pronóstico de las proyecciones de los flujos, las cuales se determinan con base en ciertas variables de ventas y costos, entre otros. Mediante el análisis de sensibilidad, podemos experimentar moviendo dichas variables en un más menos por ciento, y luego observar el efecto sobre el VPN y la TIR. Se deben de identificar y profundizar en las variables clave para el éxito del proyecto, pero hay que tener cuidado con las que pudieran haberse olvidado: puede haber un retraso en la obtención de permisos que derive en un retraso en los flujos, por ejemplo. El retraso de los flujos del ejemplo anterior, implicaría una disminución en el VPN derivado del valor del dinero en el tiempo. La proyección sobre la que se basa la sensibilidad es la que se percibe como la más realista, pero es necesario tener conciencia de los riesgos implicados en que las variables cambien, y los efectos que resultarán de dichos cambios. Es necesario experimentar además, utilizando estimaciones consideradas como optimistas y otras pesimistas de las variables relevantes, y observar el resultado en el VPN. La seguridad del proyecto, entonces, va a ser una cuestión de percepción con base en dos cuestiones: (1) la probabilidad de que ocurran los niveles adversos en las variables y (2), el efecto que tendría la ocurrencia de dichos niveles en el VPN. El proyecto puede ser aceptable incluso bajo estimaciones pesimistas. Este análisis tiene ciertas limitaciones, como la existencia de ambigüedad en las definiciones de optimista y pesimista, y la posibilidad de que las variables estén interrelacionadas, lo que imposibilita tomar valores optimistas y pesimistas para todas las variables de los flujos de efectivo. Aún así, el análisis de sensibilidad proporciona un sentido sobre cuáles son las variables que se deberán observar y controlar, y qué tan devastador o laxo es el efecto del cambio en esas variables sobre el VPN y TIR. 3. Análisis de escenarios Cuando las variables están interrelacionadas, puede ser útil observar el comportamiento del proyecto en distintos escenarios. Mediante este análisis se pueden realizar diferentes combinaciones de variables. Si la competencia abre una tienda al

lado de la nuestra, por ejemplo, podrían combinarse una merma en las ventas y con una disminución en el margen. A diferencia del análisis de sensibilidad, en éste no se manejan diferentes niveles porcentuales de cambio de una misma variable única. Aquí pueden proyectarse las variables (todas) considerando cambios específicos en el entorno: si se aprueba o no una ley, si se obtiene o no una concesión gubernamental, si se consigue o no una licencia, etc. Lo único que hay que hacer son diferentes proyecciones, cada una con las diferentes consideraciones y con los efectos que derivan en las distintas variables. Luego se calculan los VPN y TIR de cada escenario y se comparan. 4. Análisis del punto de equilibrio Cuando se realiza el análisis de sensibilidad, resulta útil saber hasta qué punto es grave el que se mueva una variable. Es decir, cuánto se puede mover una variable dada antes de que el VPN del proyecto de inversión sea negativo. Calcular el punto de equilibrio de un proyecto es muy sencillo con la ayuda del Excel. Una vez capturados los flujos del proyecto y formulado el VPN, se pueden indexar las ventas (por ejemplo) a una celda con un porcentaje, que en inicio puede ser el 100%. Luego se puede utilizar la función “Buscar objetivo” del menú “herramientas, e ingresarse la celda del VPN en “Definir la celda”, con el valor 0, “para cambiar la celda” en la que se encuentre el porcentaje. El resultado será el nivel porcentual al que deben bajar (o subir) las ventas para que el VPN se convierta en cero. 5. Plazo de recuperación o “Payback” Resulta valioso para la decisión de invertir, conocer el plazo que tardará una inversión en recuperarse. Esto es especialmente útil para eficientar el uso del efectivo de un inversionista. Evitar la consideración de perpetuidad es una forma de controlar mejor los proyectos de inversión, poniendo fechas límite para conseguir los rendimientos esperados. El tiempo de “payback” requerido dependerá del proyecto específico de inversión, de las necesidades de efectivo de cada inversionista y de su agresividad particular. Una vez realizado el cálculo del VPN sólo debe desdoblarse en el valor presente (“VP”) para cada periodo. Así, se inicia sumando el monto de la inversión inicial (con signo negativo) al VP de cada periodo desde el primero hacia el último. Cuando la suma deje de ser negativa, es en ese periodo cuando se espera que se recupere la inversión. 6. Árboles de decisión Esta herramienta es particularmente útil para planear la toma de una secuencia de decisiones que implican múltiples inversiones en el tiempo, inversiones que se van erogando dependiendo del éxito de las anteriores. Por ejemplo, cuando hay que invertir en investigación y desarrollo de un producto, luego que ya se tiene el producto, hay que

volver a invertir para construir un prototipo y hacer pruebas y después, si hay éxito, se vuelve a invertir para sacarlo a producción y a la venta posterior. Un árbol de decisión permitirá realizar una evaluación racional y metodológica de la secuencia de las decisiones, considerando los distintos escenarios. Primero deben identificarse las múltiples decisiones que habrán de tomarse en la vida del proyecto. Luego se dibujan en un esquema de árbol considerando el éxito y el fracaso de cada decisión. Después se define la probabilidad (en porcentaje) percibida del éxito y del fracaso (ambas deben sumar el 100%) de cada decisión. Finalmente se calcula el VPN considerando las inversiones e ingresos que habrán de hacerse en cada rama del árbol y al multiplicarse por el porcentaje de probabilidad, se obtiene un valor esperado para cada punta del árbol.

El criterio para tomar la decisión es elegir el camino que lleva a la punta del árbol con el valor esperado más alto. Cabe destacar que conforme va pasando el tiempo y el éxito o fracaso de las decisiones se va realizando, los valores esperados van cambiando de acuerdo a las nuevas circunstancias, por lo que el árbol resulta dinámico y las decisiones posteriores deben adecuarse a las condiciones cambiantes de la vida del proyecto. Como se puede apreciar, es posible combinar todas las herramientas explicadas anteriormente y de hecho, es recomendable utilizarlas todas. Hay ocasiones en que ni siquiera es posible realizar una sin haber considerado otra. Esta metodología podría parecer simplista. Los libros de texto consideran más variables: inflación, riesgo, fórmulas estadísticas para determinar probabilidades, etc. Pero es precisamente esta simplicidad la que hace accesible el método a un mayor número de pequeños empresarios, empresarios que no tienen el conocimiento, la información, ni los recursos para hacer análisis más complejos, y es precisamente esta accesibilidad la que permitirá que estos pequeños empresarios puedan hacer evaluaciones racionales de sus proyectos de inversión. Los beneficios Tangibles e Intangibles

Los beneficios intangibles incluyen mejorar el proceso de toma de decisiones, incrementar la exactitud, ser más competitivo en el servicio al cliente, mantener una buena imagen del negocio e incrementar la satisfacción del trabajo para los empleados eliminando las tareas tediosas. Como puede juzgar de la lista dada, los beneficios intangibles son sumamente importantes y pueden tener consecuencias transcendentales para el negocio conforme relaciona a las personas fuera y dentro de la organización. Aunque los beneficios intangibles de un sistema de información son factores importantes que se deben considerar al decidir proceder con un sistema, un sistema construido únicamente por sus beneficios intangibles no tendrá éxito. Debe discutir los beneficios tangibles e intangibles en su propuesta, debido a que presentar ambos permitirá a tomadores de decisiones del negocio tomar una decisión bien documentada acerca del sistema propuesto. Costos tangibles Los conceptos de costos tangibles e intangibles presentan una semejanza conceptual al de los beneficios tangibles e intangibles ya discutidos. Los costos tangibles son aquellos que el analista de sistemas y el personal de contabilidad del negocio pueden proyectar con precisión. Incluidos en los costos tangibles están el costo de equipo tal como las computadoras y terminales, el costo de recursos, el costo del tiempo de analistas de sistemas, el costo del tiempo de programadores y sueldos de otros empleados. Por lo regular estos costos están bien establecidos o se pueden descubrir muy fácilmente y son los costos que requerirán un desembolso en efectivo del negocio. Costos intangibles Los costos intangibles son difíciles de estimar y podrían ser desconocidos. Éstos incluyen perder una ventaja competitiva, perder la reputación por no ser el primero con una innovación o un líder en un campo, deterioro de la imagen de la compañía debido al incremento en la insatisfacción del cliente y toma de decisiones ineficaz debido a la información inoportuna o inaccesible. Como puede imaginar, es casi imposible proyectar con precisión una cantidad en dólares para los costos intangibles. Para ayudar a tomadores de decisiones que quieren evaluar el sistema propuesto y todas sus implicaciones, debe incluir los costos intangibles aunque no sean cuantificables. Resumen de los beneficios tangibles e intangibles que el nuevo sistema proveerá. Beneficios Tangibles: -

La información se procesara más rápido Acceso en cualquier momento a la información Información confiable

Los comestibles se reducirán al mínimo Se podrán generar reportes inmediatamente Eliminación de los errores numéricos Aumento de ingresos Beneficios Intangibles Mejoraremos la producción del personal Mejoraremos la satisfacción en el empleo Mayor privacidad de la información Aumentara la satisfacción del cliente La calidad del servicio aumentara

Beneficios tangibles e intangibles de un ERP La maximización de los beneficios de los sistemas de información interfuncionales denominados sistemas ERP, es fundamental para alcanzar los objetivos y metas estratégicas de una compañía. En esta nota contiene los resultados del estudio realizado por EvaluandoERP sobre los beneficios tangibles e intangibles percibidos por 155 empresas usuarias de software ERP. ¿Cuáles son los beneficios más percibidos y cuál es su grado de tangibilidad? ¿Son cuantificable? Los ERP son sistemas que emplean la tecnología de información para integrar los procesos empresariales y soportar las operaciones en el marco de la estrategia de la empresa. Si el software ERP es la espina dorsal de la empresa, la implantación deficiente, el bajo nivel de explotación, la falta de compromiso y mejora constante del sistema, comprometerá cualquier iniciativa de integración en la cadena de valor, reducirá el potencial del sistema e impedirá el cumplimiento de objetivos y metas estratégicas relacionadas con el sistema. En forma general, los beneficios de los sistemas ERP pueden ser descriptos en 5 dimensiones de negocios. 1. Beneficios de gestión: se producen por una mejora en la información. Proveen de mejores recursos al management para la toma de decisión y el planeamiento. Las organizaciones pueden utilizar sistemas ERP ya sea para soportar estructuras organizacionales que no era posible previamente, o para crear una cultura más disciplinada dentro de la empresa. Con el apoyo de los sistemas ERP es posible desarrollar empresas que crucen tanto fronteras geográficas como de unidades de negocio, logrando que cada uno de los integrantes de la organización utilice procesos e información similar. 2. Beneficios operacionales: son que provienen de la automatización de las operaciones repetitivas, aumentando la velocidad de los procesos. Sustituyen el trabajo e incrementan el volumen de operaciones. Los sistemas ERP además de automatizar muchas de las transacciones de negocio esenciales pueden también mejorar los procesos de reporte como los de toma de decisiones.

3. Beneficios en infraestructura de IT: se refiere a los producidos gracias a la capacidad de re usar y compartir recursos de tecnología informática. Los sistemas ERP prometen proveer un solo ambiente y una sola plataforma tecnológica unificada para todo el sistema de información. En un Enterprise Resource Planning los datos de todos los procesos claves del negocio se integran en un solo repositorio. 4. Beneficios organizacionales: son los que surgen de una mejora en el desarrollo de los recursos humanos. Los sistemas ERP pueden ayudar a crear una organización con operaciones más eficientes y con procesos de negocio orientados al cliente. Al integrar procesos discretos como ventas, producción, finanzas y logística, la empresa como un todo puede responder eficazmente a los requerimientos de los clientes sobre productos o información, realizar pronósticos sobre nuevos productos, o producir y entregar en función a la demanda. 5. Beneficios estratégicos: son todos aquellos que tienen que ver con la capacidad que brinda el sistema para obtener ventajas competitivas. Beneficios operacionales, tácticos y estratégicos Un beneficio intangible es aquel es difícil de medir. Un beneficio tangible es el que afecta directamente al resultado de la empresa. Hay autores que presentan una clasificación de los beneficios de los sistemas de información según su orientación: beneficios operacionales, beneficios tácticos y beneficios estratégicos. Estos autores observaron que, a medida que los beneficios de un proyecto de implantación de un sistema de información se movían desde una orientación operacional hacia una orientación estratégica, estos beneficios se hacían menos cuantificables y más intangibles. Beneficios percibidos por los usuarios Desde Enero a Mayo de 2013, EvaluandoERP realizó una consulta en un grupo de empresas con el objeto de conocer, entre otras cuestiones, el grado de tangibilidad de una serie beneficios y cuán cuantificable podrían ser los mismos. De un conjunto de 17 beneficios se les formuló a los participantes la siguiente pregunta: Asumiendo que el uso de software ERP produce beneficios en el negocio, a su criterio ¿Cuál es el grado de tangibilidad de los siguientes beneficios y qué grado de cuantificación tienen?

Las opciones para responder se presentaron como una escala de calificaci贸n con 4 respuestas posibles: Totalmente tangible, bastante tangible, algo tangible, baja tangibilidad. Los resultados de las respuestas se presentan en orden de acuerdo a tres posibilidades de respuesta

Tabla Nro. 1 - Fuente Evaluando ERP en base a datos propios En el cuadro anterior puede verse que, si bien se consignaron los 5 beneficios m谩s tangibles que fueron votados de acuerdo a cada tipo de respuesta, no hay plena coincidencia en las 3 columnas, con excepci贸n de las mejoras en la productividad. Una primera conclusi贸n es que, de acuerdo a los participantes de la encuesta, con el uso del ERP hay al menos hay 8 beneficios tangibles. En cambio los 5 beneficios menos tangibles que los participantes votaron fueron:

Tabla Nro. 2 - Fuente Evaluando ERP en base a datos propios

Tres de los 5 beneficios más intangibles aparecen, en diferente orden, en las tres clases de respuestas lo que evidencia coincidencia. Es decir que para los participantes de la encuesta hay al menos 7 beneficios que, en diferentes grados, son intangibles. Esta pregunta se complementó con otra que refería al grado de cuantificación de los mismos beneficios, utilizando la misma escala que en el caso anterior (totalmente cuantificable, bastante cuantificable, algo cuantificable, bajo grado de cuantificación).

Tabla Nro. 3 - Fuente Evaluando ERP en base a datos propios

Tabla Nro. 4 - Fuente Evaluando ERP en base a datos propios Costo de ventas

El costo de venta es el costo en que se incurre para comercializar un bien, o para prestar un servicio. Es el valor en que se ha incurrido para producir o comprar un bien que se vende. Cuando se hace una venta, por ejemplo de $100.000, todo no es utilidad para el vendedor, puesto que para poder vender ese valor, debió haberse comprado un bien, para lo cual indudablemente hubo necesidad de incurrir en un costo, costo que se conoce como costo de venta. Quizás el vendedor compro una camisa en $60.000 y luego la vendió en $100.000, por lo que su costo de venta viene a ser los $60.000, pues debió incurrir en un costo de $60.000 para poder hacer una venta de $100.000. Determinar el costo de venta, en principio es algo muy sencillo, pues todo lo que se debe hacer es restar al valor de la venta, el valor que se invirtió en el producto vendido. Pero cuando se venden grandes cantidades y se manejan multitud de productos, el proceso de determinación del costo de venta es mucho más complejo. Los inventarios son controlados mediante dos sistemas (Sistema de inventarios permanente y Sistema de

inventarios

periódico).

Cada

sistema tiene su propio mecanismo o procedimiento para determinar el costo de venta. En el caso del sistema permanente se utilizan los diferentes métodos de valuación de Inventarios (Método Peps, Método Ueps, Método del promedio ponderado, Método retail, etc). En el sistema periódico se utiliza el Juego de inventarios. Costos iniciales El costo inicial se considera como aquel que es necesario para iniciar una actividad. La principal ventaja de reconocer esta clase es que llama la atención sobre un conjunto de costos que están asociados con la iniciación de una nueva actividad y a los cuales

podría no haberse dado una consideración apropiada de manera diferente. Esta clasificación está limitada generalmente, a aquellos costos que se presentan únicamente una vez en una actividad. Existen grados de acción en un gran número de campos por debajo de los cuales su efecto es insignificante. Así por ejemplo, un pequeño movimiento de un piñón en un engranaje simplemente se notará pero sin alcanzar a mover el otro piñón. Como analogía debe reconocerse que hay muchas actividades que de otra manera podrían ser rentables pero que no deben llevarse s. cabo por la simple razón de que su costo inicial representa un nivel de insumes que está por encima del que se podría obtener. Muchas propuestas de ingeniería que aparecerían lógicas de manera diferente no se inician porque su costo inicial está fuera del alcance de la organización. Otras propuestas de ingeniería fracasan una vez iniciadas, porque el margen requerido no se alcanzó debido a limitaciones financieras. Considérese, por ejemplo, la propuesta de una operación minera que supone la extracción de un volumen de mineral que se ha estimado en 1.200.000 toneladas. La Propuesta A supone la construcción de un túnel que parte de una línea férrea existente y termina en el depósito de minerales, dentro de la montaña. El mineral será sacado de la mina por un transportador de gravedad colocado dentro del túnel. El costo inicial del túnel

del

transportador instalado

sido

estimado

$1.380.000.

transportador

tendrá

un costo de operación de $0,40 por tonelada y

valor

salvamento $180.000.

de de

La Propuesta B implica remover una cierta cantidad de capa vegeta con lo cual el mineral quedará al aire y listo para cargarlo en volquetas. Se ha estimado que el costo inicial de remover la capa vegetal y de mejorar ligeramente la carretera asciende a $220.000. Se tomarán en arriendo volquetas con sus conductores para trasportar el mineral desde la mina hasta la línea férrea, con un costo de $1,30 por tonelada de material trasportado. Se considera que todos los demás costos son iguales en las dos propuestas. La diferencia en costo sin tener en cuenta los intereses sobre la inversión se calcula como sigue: Propuesta

$1.380.000

—

80.000

$0,40(1.200.000)

$1.680.000

Propuesta B $220.000 + $1,30(1.200.000) = $1.780.000 Un análisis más cuidadoso indica que la operación de la mina generará ingresos suficientes para producir utilidades independientemente de la propuesta que se seleccione, pero que algunas limitaciones de orden financiero no permitirán la terminación exitosa de la Propuesta A debido a su alto costo inicial. En un caso como éste, la operación de la mina podría iniciarse aceptando la Propuesta B aunque su costo será $100.000 más alto que el de A. A pesar de que A aparece como la mejor propuesta seleccionada, conduciría a un fracaso debido a la incapacidad para arbitrar el dinero necesario para cubrir su costo inicial. Costos de desarrollo Los costos de desarrollo de un proyecto deben ser reconocidos como gastos del periodo en el que se incurren, a menos que se cumplan las condiciones, para su reconocimiento como activos, que se identifican en el párrafo . Los costos de desarrollo inicialmente reconocidos como gastos de un ejercicio, no deben reconocerse como activos

ningún

periodo

posterior.

Los costos de desarrollo de un proyecto deben ser reconocidos como activos cuando cumplen todas y cada una de las siguientes condiciones: (a) el producto o proceso está claramente definido, y el costo atribuible al mismo puede ser identificado por separado y medido con fiabilidad;

(b) puede ser demostrada la viabilidad técnica del producto o proceso; (c) la empresa tiene intención de producir y comercializar, o utilizar, el producto o proceso; (d) puede ser demostrada la existencia de un mercado para el producto o proceso, o bien su utilidad en la producción, en caso de que vaya a ser usado internamente y no comercializado, y (e) existen los medios adecuados, o bien está garantizada su disponibilidad, para completar el proyecto, así como para vender o utilizar el producto o proceso resultante. Los costos de desarrollo de un proyecto, que hayan sido reconocidos como activos, no deben de exceder del importe que sea probable recuperar por medio de

los

beneficios

económicos

futuros, una vez deducidos, en su caso,

los

costos

complementarios,

de así

desarrollo como

los

costos de producción relacionados y los costos directos, administrativos y comerciales, en los que se incurrirá al

colocar

producto

mercado. 18. Aunque los costos de desarrollo de un proyecto cumplan con la definición de activo, tales partidas pueden

satisfacer

las

condiciones para su reconocimiento como activos, debido a la insuficiente certeza sobre el flujo de beneficios económicos futuros, que pueden llegar a la empresa como consecuencia de los citados costos. En tales circunstancias, los costos de desarrollo se reconocerán como gastos del periodo

en que se han incurrido, y no vuelven a reconocerse como activos en ningún periodo posterior. Manuales de Usuario es un documento de comunicación técnica destinado a dar asistencia a las personas que utilizan un sistema en particular Por lo general, este documento esta redactado por un escritor técnico, como por ejemplo los programadores del sistema o los directores de proyectos implicados en su desarrollo, o el personal técnico, especialmente en las empresas más pequeñas. Los Manuales de usuario para la mayor parte de las aplicaciones de software contienen comúnmente todos los contenidos detallados en el apartado anterior. El Starta User Manual es un buen ejemplo de este tipo de documento. Sin embargo, algunos documentos tienen una estructura más fluida con muchos enlaces internos. El Google Earth User Guide es un ejemplo de este tipo de manuales. Manuales de operación Es

manual

procedimientos,

que

contiene

instrucciones

orientación que permiten al personal encargado

operaciones

desempeñar sus obligaciones.

Manual de procedimientos Es el documento que contiene la descripción de actividades que deben seguirse en la realización de las

funciones

una

unidad

administrativa,

dos

mas

ellas.

El manual incluye además los puestos o unidades administrativas que intervienen precisando

responsabilidad

participación.

Suelen contener información y ejemplos de formularios, autorizaciones o documentos necesarios, màquinas o equipo de oficina a utilizar y cualquier otro dato que pueda auxiliar

correcto

desarrollo

las

actividades

dentro

empresa.

En el se encuentra registrada y transmitida sin distorsión la información básica referente al funcionamiento de todas las unidades administrativas, facilita las labores de auditoria, la evaluación y control interno y su vigilancia, la conciencia en los empleados y en sus jefes de que el trabajo se està realizando o no adecuadamente. Manual de sistemas Documentación relacionada con el análisis diseño e implementación de un sistema de información. Son una guía para su correcto funcionamiento.