mio

1. 7 Evaluación de los Sistemas<br />Los progresos realizados en un sistema deben ser medidos o evaluados para conocer las deficiencias y problemas que éste presenta. Aunque una evaluación cualitativa puede resultar útil en las etapas iniciales del desarrollo del sistema, medidas cuantitativas bajo unas mismas condiciones resultan de vital importancia para ver el progreso real del sistema y compararlo consigo mismo o con otros. Los números no aportan información si se desconoce de dónde proceden, es decir, qué representan. La evaluación de cualquier tecnología debe ir acompañada de un conjunto de medidas estándar propuestas para tal fin. La disponibilidad de bases de datos y de protocolos o procedimientos para la evaluación de estos sistemas ha sido un componente muy importante, casi fundamental, en el progreso alcanzado en este campo y ha permitido compartir nuevas ideas, e incluso compararlas con otras ya consolidadas. Los progresos en la evaluación de sistemas de comprensión del lenguaje hablado están comenzando. Así vamos a mencionar a continuación diferentes acuerdos alcanzados [PRI90] en la evaluación de sistemas:<br />Conjuntos de Datos de Entrenamiento y de Prueba Independientes. La importancia de disponer de conjuntos de datos independientes para el entrenamiento/desarrollo y para la evaluación de sistemas de reconocimiento de habla viene siendo aceptada desde hace bastante tiempo por la comunidad científica. Sigue siendo igual de importante para el desarrollo y evaluación de los sistemas de comprensión de habla, aunque para estos últimos nos interesará tener datos de prueba dónde aparezcan el mayor número de fenómenos del habla posibles (son importantes las construcciones gramaticales, los efectos propios del habla espontánea, etc.), para colocar al sistema en el mayor número de situaciones (léxicas, sintácticas y semánticas) posible. Sin embargo, es conveniente resaltar que el proceso de evaluación no deja de ser parte del proceso de entrenamiento, pues en muchos casos los resultados de la misma sirven para depurar o mejorar el comportamiento final del sistema. Por tanto, es importante que exista un conjunto de datos independiente y realista, tan grande como sea posible, con el que se evalúe definitivamente un sistema y con cuyos resultados no se intente seguir desarrollando (mejorando) el sistema.<br />Evaluación del Sistema como Caja Negra. La evaluación de los componentes de un sistema es una tarea importante durante el desarrollo del mismo, aunque no es especialmente útil para comparar sistemas entre sí, al menos que los sistemas a comparar sean muy similares, lo que no suele ser el caso. La motivación para evaluar los componentes de un sistema es puramente interna, por tanto, no es absolutamente necesario llegar a acuerdos en la comunidad internacional sobre la metodología de evaluación de los mismos. Las medidas de evaluación de los componentes internos de un sistema pueden utilizarse para evaluar las tecnologías empleadas en cada componente como una función de sus parámetros de diseño; por ejemplo, el funcionamiento de un módulo de reconocimiento acústico puede ser evaluado como una función de la perplejidad alofónica y sintáctica, el funcionamiento de un analizador sintáctico (parser) como una función de la calidad (errores) de la secuencia de palabras (frase) de entrada. Además, estas medidas son útiles para evaluar el progreso conseguido, y cómo los cambios en varios componentes afectan al resto de los mismos.<br />Evaluación Cuantitativa vs. Cualitativa. Una evaluación cualitativa de un sistema (p. ej. lo que parece gustar a los usuarios del sistema) puede ser animador, pero mucho más convincente para aquellos que no pueden observar el sistema son las medidas cuantitativas llevadas a cabo de forma automática. Las medidas deberían ser estandarizadas en la medida de lo posible, y ser reproducibles, para considerarlas significativas. El proceso automatizado evita errores humanos debido a fatiga, falta de atención, malas intenciones, etc. y además, permite capturar muchos más datos que en un caso manual, y sacar conclusiones sobre el funcionamiento de ciertos procesos o hechos que ocurren, con una mayor fiabilidad.<br />Captura de Datos para Evaluación. Para capturar los datos que necesitamos para evaluar los sistemas de lenguaje hablado, se han desarrollado técnicas y sistemas especiales conocidos como PNAMBIC(“Pay No Attention to the Man Behind the Curtain”) o Mago de Oz (Wizard of Oz), que implica la existencia de un experto cooperando con un sistema más o menos automático y completo, pero del que no es consciente el usuario, quién piensa que interacciona sólo con un sistema completamente automático. Realmente, el “mago” introduce las peticiones del usuario transcribiendo la frase hablada a texto y enviándosela a la pantalla del usuario, así como interaccionando con un sistema de información (p.e. de gestión de bases de datos), para conseguir las respuesta a la pregunta o petición del usuario y poder mandársela. No se permite que el “mago” realice tareas complejas, sólo puede enviar los datos obtenidos de la base de datos, o frases que indiquen ciertos problemas, indicaciones al usuario, como “su pregunta requiere un proceso que sobrepasa las posibilidades del sistema”. En general, la actuación del “mago” viene condicionada por el hecho de que comprenda o no la pregunta del usuario y sobre su conocimiento sobre las posibilidades de la base de datos. Los datos deben ser analizados a posteriori para determinar si la actuación del “mago” fue o no correcta.<br />Convenios sobre las Transcripciones. La transcripción de las sesiones, es decir, las frases que se muestran al usuario, representan el habla natural de ese locutor. Para llevar a cabo evaluaciones automáticas, debemos llegar a un cierto acuerdo sobre los convenios a utilizar para representar lo que el usuario ha dicho, y se deben implementar procedimientos que aseguren que estos convenios son realmente utilizados.<br />Respuestas Canónicas y Obtención de Medidas. Las respuestas canónicas son, en general, las respuestas enviadas al usuario bajo el control del “mago”. Estas respuestas deberán ser modificadas si el “mago” comete un error, o si la respuesta depende del contexto en que fue generada debido a la posible cooperación (diálogo) entre el “mago” y el usuario. La obtención de medidas se lleva a cabo con programas estándar y convenios para las entradas y salidas.<br />En las auditorias se pueden definir muchas etapas diferentes, más o menos detalladas según el criterio de cada auditor, a continuación comento algunas que me parecen que no pueden dejar de estar al momento de llevar adelante un trabajo de auditoría.<br />Etapas principales de la Auditoria<br />Exploración<br />La exploración es la etapa en la cual se realiza el estudio o examen previo al inicio de la Auditoria con el propósito de conocer en detalle las características de la entidad a auditar para tener los elementos necesarios que permitan un adecuado planeamiento del trabajo a realizar y dirigirlo hacia las cuestiones que resulten de mayor interés de acuerdo con los objetivos previstos.<br />Los resultados de la exploración permiten, además, hacer la selección y las adecuaciones a la metodología y programas a utilizar; así como determinar la importancia de las materias que se habrán de examinar.<br />También posibilita valorar el grado de fiabilidad del control interno (contable y administrativo) así como que en la etapa de planeamiento se elabore un plan de trabajo más eficiente y racional para cada auditor, lo que asegura que la Auditoría habrá de realizarse con la debida calidad, economía, eficiencia y eficacia; propiciando, en buena medida, el éxito de su ejecución. <br />En la entidad se deben efectuar entrevistas con los principales dirigentes con el propósito de explicarles el objetivo de la Auditoría, y conocer o actualizar en detalle los datos en cuanto a estructura, cantidad de dependencia, desenvolvimiento de la actividad que desarrolla, flujo de la producción o de los servicios que presta y, otros antecedentes imprescindibles para un adecuado planeamiento del trabajo a ejecutar.<br />Planeamiento<br />El trabajo fundamental en esta etapa es el definir la estrategia que se debe seguir en la Auditoría a acometer.<br />Lo anterior conlleva planear los temas que se deben ejecutar, de manera que aseguren la realización de una Auditoría de alta calidad y que se logre con la economía, eficiencia, eficacia y prontitud debidas.<br />Partiendo de los objetivos y alcance previstos para la Auditoría y considerando toda la información obtenida y conocimientos adquiridos sobre la entidad en la etapa de exploración, el jefe de grupo procede a planear las tareas a desarrollar y comprobaciones necesarias para alcanzar los objetivos de la Auditoría.<br />Igualmente, debe determinar la importancia relativa de los temas que se van a auditar y reevaluar la necesidad de personal de acuerdo con los elementos de que dispone.<br />Después de que se ha determinado el tiempo a emplear en la ejecución de cada comprobación o verificación, se procede a elaborar el plan global o general de la Auditoría, el que se debe recoger en un documento que contenga como mínimo:<br />Definición de los temas y las tareas a ejecutar.<br />Nombre del o los especialistas que intervendrán en cada una de ellas.<br />Fecha prevista de inicio y terminación de cada tarea. Se considera desde la exploración hasta la conclusión del trabajo.<br />Igualmente se confecciona el plan de trabajo individual de cada especialista, considerando como mínimo:<br />Nombre del especialista.<br />Definición de los temas y cada una de las tareas a ejecutar.<br />Fecha de inicio y terminación de cada tarea.<br />Cualquier ampliación del término previsto debe estar autorizada por el supervisor u otro nivel superior; dejando constancia en el expediente de Auditoría.<br />Según criterio del jefe de grupo, tanto el plan general de la Auditoría, como el individual de cada especialista, pueden incluirse en un solo documento en atención al número de tareas a ejecutar, cantidad de especialistas subordinados, etc.<br />Supervisión<br />El propósito esencial de la supervisión es asegurar el cumplimiento de los objetivos de la Auditoría y la calidad razonable del trabajo. Una supervisión y un control adecuados de la Auditoría son necesarios en todos los casos y en todas las etapas del trabajo, desde la exploración hasta la emisión del informe y su análisis con los factores de la entidad auditada.<br />Asimismo, debe garantizar el cumplimiento de las Normas de Auditoría y que el informe final refleje correctamente los resultados de las comprobaciones, verificaciones e investigaciones realizadas.<br />Una supervisión adecuada debe asegurar que:<br />Todos los miembros del grupo de Auditoría han comprendido, de forma clara y satisfactoria, el plan de Auditoría, y que no tienen impedimentos personales que limiten su participación en el trabajo.<br />Se sigue el plan de Auditoría elaborado al efecto y se aplican los procedimientos previstos, considerando las modificaciones autorizadas.<br />Los papeles de trabajo contengan evidencias que sustenten correctamente los señalamientos en el informe final.<br />En el informe final de la Auditoría se expongan las conclusiones, detalles y recomendaciones que se consideren pertinentes de acuerdo con los resultados de las revisiones efectuadas.<br />La supervisión tiene normalmente dos niveles de ejecución: el que corresponde al que se realiza sistemáticamente por el jefe de grupo y el que acomete el funcionario del Ministerio designado como supervisor<br />Ejecución<br />El propósito fundamental de esta etapa es recopilar las pruebas que sustenten las opiniones del auditor en cuanto al trabajo realizado, es la fase, por decir de alguna manera, del trabajo de campo, esta depende grandemente del grado de profundidad con que se hayan realizado las dos etapas anteriores, en esta se elaboran los Papeles de Trabajo y las hojas de nota, instrumentos que respaldan excepcionalmente la opinión del auditor actuante.<br />Informe<br />En esta etapa el Auditor se dedica a formalizar en un documento los resultados a los cuales llegaron los auditores en la Auditoría ejecutada y demás verificaciones vinculadas con el trabajo realizado.<br />Comunicar los resultados al máximo nivel de dirección de la entidad auditada y otras instancias administrativas, así como a las autoridades que correspondan, cuando esto proceda.<br />El informe parte de los resúmenes de los temas y de las Actas de Notificación de los Resultados de Auditoría (parciales) que se vayan elaborando y analizando con los auditados, respectivamente, en el transcurso de la Auditoría.<br />La elaboración del informe final de Auditoría es una de las fases más importante y compleja de la Auditoría, por lo que requiere de extremo cuidado en su confección.<br />El informe de Auditoría debe tener un formato uniforme y estar dividido por secciones para facilitar al lector una rápida ubicación del contenido de cada una de ellas.<br />El informe de Auditoría debe cumplir con los principios siguientes:<br />Que se emita por el jefe de grupo de los auditores actuantes.<br />Por escrito.<br />Oportuno.<br />Que sea completo, exacto, objetivo y convincente, así como claro, conciso y fácil de entender.<br />Que todo lo que se consigna esté reflejado en los papeles de trabajo y que responden a hallazgos relevantes con evidencias suficientes y competentes.<br />Que refleje una actitud independiente.<br />Que muestre la calificación según la evaluación de los resultados de la Auditoría.<br />Distribución rápida y adecuada.<br />Seguimiento<br />En esta etapa se siguen, como dice la palabra, los resultados de una Auditoría, generalmente una Auditoria evaluada de Deficiente o mal, así que pasado un tiempo aproximado de seis meses o un año se vuelve a realizar otra Auditoría de tipo recurrente para comprobar el verdadero cumplimiento de las deficiencias detectadas en la Auditoria.<br />Desarrollo de sistemas - Presentation Transcript<br />TATIANA KATHERINE MONTOYA ZABALETA<br />EVALUACIÓN DE LOS SISTEMAS<br />La elaboración de sistemas debe ser evaluada con mucho detalle, para lo cual se debe revisar si existen realmente sistemas entrelazados como un todo o bien si existen programas aislados. Otro de los factores a evaluar es si existe un plan estratégico para la elaboración de los sistemas o si se están elaborados sin el adecuado señalamiento de prioridades y de objetivos.<br />El proceso de planeación de sistemas deberá asegurarse de que todos los recursos requeridos estén claramente identificados en el plan de desarrollo de aplicaciones y datos. Estos recursos (hardware, software y comunicaciones) deberán ser compatibles con la arquitectura y la tecnología, conque se cuenta actualmente.<br />EVALUACIÓN DE LOS SISTEMAS<br />Los sistemas deben evaluarse de acuerdo con el ciclo de vida que normalmente siguen:<br />* requerimientos del usuario. * estudio de factibilidad.<br />* diseño general. * Análisis.<br />* diseño lógico. * desarrollo físico.<br />* Pruebas. * Implementación.<br />* Evaluación. * Modificaciones.<br />* Instalación. * mejoras.<br />Y se vuelve nuevamente al ciclo inicial, el cual a su vez debe comenzar con el de factibilidad.<br />EVALUACIÓN DEL ANÁLISIS<br />En esta etapa se evaluarán las políticas, procedimientos y normas que se tienen para llevar a cabo el análisis.<br />Se deberá evaluar la planeación de las aplicaciones que pueden provenir de tres fuentes principales:<br />* La planeación estratégica.<br />* Los requerimientos de los usuarios.<br />* El inventario de sistemas en proceso al recopilar la información de los cambios que han sido solicitados, sin importar si se efectuaron o se registraron.<br />EVALUACIÓN DEL DISEÑO LÓGICO DEL SISTEMA<br />En esta etapa se deberán analizar las especificaciones del sistema.<br />¿Qué deberá hacer?, ¿Cómo lo deberá hacer?, ¿Secuencia y ocurrencia de los datos, el proceso y salida de reportes?<br />Una vez que se halla analizado estas partes, se deberá estudiar la participación que tuvo el usuario en la identificación del nuevo sistema, la participación de auditoría interna en el diseño de los controles y la determinación de los procedimientos de operación y decisión.<br />EVALUACIÓN DEL DISEÑO LÓGICO DEL SISTEMA<br />Entradas, Salidas, Procesos.<br />Especificaciones de datos.<br />Especificaciones de proceso.<br />Métodos de acceso.<br />Operaciones.<br />Manipulación de datos<br />Identificación de archivos, tamaño de los campos y registros.<br />Proceso en línea o lote y su justificación.<br />Frecuencia y volúmenes de operación.<br />Sistemas de seguridad.<br />Sistemas de control.<br />Responsables.<br />Número de usuarios.<br />Al tener el análisis del diseño lógico del sistema debemos compararlo con lo que realmente se está obteniendo en la cual debemos evaluar lo planeado, cómo fue planeado y lo que realmente se está obteniendo. Los puntos a evaluar son:<br />Proceso lógico necesario para producir informes.<br />EVALUACIÓN DEL DESARROLLO DEL SISTEMA<br />En esta etapa del sistema se deberán auditar los programas, su diseño, el leguaje utilizado, interconexión entre los programas y características del hardware empleado (total o parcial) para el desarrollo del sistema.<br />Al evaluar un sistema de información se tendrá presente que todo sistema debe proporcionar información para planear, organizar, controlar de manera eficaz y oportuna, para reducir la duplicidad de datos y de reportes y obtener una mayor seguridad en la forma más económica posible.<br />EVALUACIÓN DEL DESARROLLO DEL SISTEMA<br />De ese modo contará con los mejores elementos para una adecuada toma de decisiones. Al tener un proceso distribuido, es preciso considerar la seguridad del movimiento de la información entre nodos. El proceso de planeación de sistemas debe definir la red óptima de comunicaciones, los tipos de mensajes requeridos, el trafico esperado en las líneas de comunicación y otros factores que afectan el diseño.<br />Es importante considerar las variables que afectan a un sistema: ubicación en los niveles de la organización, el tamaño y los recursos que utiliza.<br />EVALUACIÓN DEL DESARROLLO DEL SISTEMA<br />.<br />Las características que deben evaluarse en los sistemas son:<br />Dinámicos (susceptibles de modificarse).<br />Estructurados (las interacciones de sus componentes o subsistemas deben actuar como un todo)<br />Integrados (un solo objetivo). En él habrá sistemas que puedan ser interrelacionados y no programas aislados.<br />Accesibles (que estén disponibles).<br />Necesarios (que se pruebe su utilización).<br />Comprensibles (que contengan todos los atributos).<br />Oportunos (que esté la información en el momento que se requiere).<br />Funcionales (que proporcionen la información adecuada a cada nivel).<br />Estándar (que la información tenga la misma interpretación en los distintos niveles).<br />Modulares (facilidad para ser expandidos o reducidos).<br />Jerárquicos (por niveles funcionales).<br />Seguros (que sólo las personas autorizadas tengan acceso).<br />Únicos (que no duplique información).<br />EVALUACIÓN DEL DESARROLLO DEL SISTEMA<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DE SISTEMAS<br />RIESGO<br />Acceso no autorizado<br />EJEMPLO<br />Cuando los desarrolladores de software acceden sin autorización al sistema<br />CONTROL<br /> Establecer mecanismos necesarios a fin de asegurar que los programadores y analistas no tengan acceso a la operación del computador y los operadores a su vez no conozcan la documentación de programas y sistemas.<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DEL SISTEMA<br />RIESGO<br />Planificación insuficiente<br />EJEMPLO<br />Cuando los desarrolladores de software su pera en tiempo establecido para la terminación del software.<br />CONTROL<br />Debe analirse minuciosamente la planeación del desarrollo del programa para un desarrollo rapido<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DEL SISTEMA<br />RIESGO<br />Cambio de requerimientos<br />EJEMPLO<br />Este caso se presenta cuando no se definieron claramente los requerimientos del software y al desarrollador, analista le toca rediseñaran y volver a programar<br />CONTROL<br />Realizar cuidadosamente el estudio antes de comenzar el desarrollo, aplicando los diferentes métodos obtencion de requerimientos<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DEL SISTEMA<br />RIESGO<br />Tiempo de desarrollo<br />EJEMPLO<br />Cuando los desarrolladores de software su pera en tiempo establecido para la terminación del software.<br />CONTROL<br />Debe analirse minuciosamente la planeación del desarrollo del programa<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DEL SISTEMA<br />RIESGO<br />Perdida de manuales<br />EJEMPLO<br />En una empresa que se necesite la actualización de un sistema<br />CONTROL<br />Proteger los manuales en lugares seguros en donde los operadores, analistas , desarrolladores tengan acceso; y no se dañen.<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DEL SISTEMA<br />RIESGO<br />Diseño inadecuado<br />EJEMPLO<br />En el proceso de desarrollo los diseñadores no escatiman el tiempo necesario para la creación del diseño por la rapidez de completar la planeación.<br />CONTROL<br />Determinar en la planeación el tempo justo para el desarrollo de diseño y darle su importancia.<br />¿POSIBLES RIESGOS HA TENER EN CUENTA EN LA DESARROLLO DEL SISTEMA<br />RIESGO<br />Personal mediocre<br />EJEMPLO<br />cuando en el equipo de desarrollo se encuentra una persona que desconoce los métodos de desarrollo de software.<br />CONTROL<br />En el momento de la contratación debe estudiarse con detalle la hoja de vida del personal a participar en el desarrollo y desarrollar test de conocimiento<br />GRACIAS<br />