Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Presentación Calidad de Sistemas

Presentación de la Segunda Unidad en la Materia de Calidad de Sistemas de Información
by

Oseas Jimenez

on 1 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Presentación Calidad de Sistemas

Unidad II: Ángel Martines Linares Carlos Lopéz Carrasco Viviana Nivón Sántos 2.3.- Listas de Comprobación 2.2.1.- El Cuaderno de Registros de Defectos 2.2.3.- Formas de Encontrar y Corregir Defectos Oseas Jiménez Sánchez Calidad de Sistemas de Información Calidad enfocada al desarrollo
de
sistemas de información Calidad enfocada al desarrollo de sistemas de información Calidad Calidad es el conjunto de propiedades y características de un producto o servicio que le confieren capacidad de satisfacer necesidades, gustos y preferencias, y de cumplir con expectativas en el consumidor. Tales propiedades o características podrían estar referidas a los insumos utilizados, el diseño, la presentación, la estética, la conservación, la durabilidad, el servicio al cliente, el servicio de postventa, etc. Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el hardware necesario para que el sistema de información pueda operar El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema. Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información. ¿Qué es un Sistema de Información? Calidad en los sistemas de información 2.1. CALIDAD EN LOS SISTEMAS DE INFORMACIÓN. 2.1.- Calidad en los Sistemas de Información Sistema de Información de la Calidad (SIC) Es un método organizado para recolectar, almacenar y reportar la información sobre la calidad para ayudar a los tomadores de decisiones en todos los niveles. 2.2. DEFECTOS Y ERRORES DE CALIDAD EN LOS SISTEMAS DE INFORMACIÓN. 2.2. DEFECTOS Y ERRORES DE CALIDAD EN LOS SISTEMAS DE INFORMACIÓN. 2.2.2.- Contabilización de Defectos y Errores ¿Qué son los defectos? El termino defecto se refiere a algo que está equivocado en un programa, tal como un error sintáctico, una falta tipográfica, un error de puntuación, o una sentencia incorrecta del programa. Los defectos pueden estar en los programas, en los diseños o incluso en los requisitos, las especificaciones o en otra documentación. Los defectos pueden ser sentencias extra o redundantes, sentencias incorrectas o secciones del programa omitidas. Un defecto, es cualquier cosa que reduce la capacidad de los programas para cumplir completa y efectivamente las necesidades de los usuarios. Un defecto es una cosa objetiva. Es algo que puedes identificar, describir y contabilizar. Es importante separar la cuestión de encontrar o identificar los defectos de la determinación de sus causas. La simple contabilización y registro de los defectos en los productos software no es la especificación de las causas ni la asignación de culpas. Los defectos cometidos, sin embargo, tienen sus causas. Puedes haber cometido un error al escribir el nombre de un parámetro, omitido un signo de puntuación o llamado incorrectamente un procedimiento. Todos estos errores causan defectos.
Todos los defectos, por consiguiente, provienen de errores humanos y muchos de los que los ingenieros del software cometen, causan defectos en los programas. ¿Qué son los errores? Los errores son cosas incorrectas que cometen las personas y, sin tener en cuenta cuándo y quién los comete, los defectos son elementos defectuosos de los programas. Así, las personas cometen errores o equivocaciones mientras que los programas tienen defectos. Cuando los ingenieros cometen errores que conducen a defectos, nosotros nos referimos a esto como la introducción de defectos.

Esto significa que para reducir el número de defectos que introduces en tus productos, debes cambiar la forma de hacer las cosas. Para eliminar los defectos en tus productos, sin embargo, sencillamente tienes que encontrarlos. La eliminación de defectos es, por lo tanto, un proceso más sencillo que la prevención de defectos. La prevención de defectos es un aspecto importante y prioritario que requiere un estudio comprensivo de todo el proceso de desarrollo del software. Los defectos deberían ser importantes para cada ingeniero del software no sólo porque afectan a los usuarios, sino también porque más de la mitad del esfuerzo de las organizaciones de software está dedicado a encontrar y corregir los defectos. Puesto que el tiempo de pruebas es difícil de predecir, los defectos son, a menudo, la causa principal de los problemas de costes y programaciones. Tipos de Defectos. Como comprender los defectos El primer paso para gestionar los defectos es entenderlos. Para hacer eso, debes reunir los datos de defectos. Entonces, podrás entender estos errores y comprender cómo evitarlos. Puedes también comprender cómo encontrarlos mejor, corregirlos o prevenir el defecto que todavía introduces. Para reunir datos de defectos de tus programas, haz lo siguiente:
Registra cada defecto que encuentres en un programa.Registra la información suficiente sobre cada defecto para que puedas entenderlo posteriormente.Analiza estos datos para ver qué tipos de defectos causan los mayores problemas. Los defectos que introduces y encuentras en tus propios programas, son solamente parte de la historia. Algún día, necesitarás aprender sobre los defectos que otras personas encuentran en tus programas. Puesto que estos defectos se escaparán a todos los esfuerzos de detección y prevención de defectos, serán más importantes para entender y tratar las debilidades de tus procesos personales. Estos defectos se denominan escapes, porque han escapado a todos tus esfuerzos de eliminación de defectos. Conforme mejore tu proceso personal, los defectos que se escapan serán la última fuente principal de datos para tu mejora personal. 2.2.1.- El Cuaderno de Registros de Defectos 2.2.2.- Contabilización de Defectos y Errores El cuaderno de registro de defectos está diseñado para ayudarte a reunir datos de defectos. El cuaderno se muestra en la siguiente figura: y sus instrucciones se indican de esta manera Utiliza este cuaderno para reunir datos de defectos para cada programa que codifiques. Describe cada defecto con bastante detalle para que puedas entenderlo más adelante. Después de haber terminado cada programa, analiza los datos para ver dónde has introducido y eliminado los defectos y qué tipos de defectos causan los principales problemas. Antes de utilizar este cuaderno, lee el resto de ese capítulo y las instrucciones en la tabla anterior. Aunque la definición de un defecto puede parecer obvia, no lo es. Durante la compilación, por ejemplo, cuenta solamente los cambios que haces. Es decir, si el compilador presenta 10 mensajes de error por una omisión del punto y coma, la omisión del punto y coma es un único defecto. Así, anota un defecto en el Cuaderno de Registro de Defectos para cada corrección del programa, sin tener en cuenta la naturaleza de la corrección y el número de mensajes de error del compilador. De forma similar, cuando encuentres un defecto de diseño mientras estés codificando, se considerará un defecto de diseño. Mientras diseñas, sin embargo, con frecuencia puedes cambiar tu idea de cómo hacer algo.
Si estás corrigiendo un error en los requisitos o en las especificaciones, eso sería un defecto de requisitos o de especificación. Si, por el contrario, has pensado una forma mejor de hacer el diseño, no sería un defecto. A menudo, advertirás y corregirás errores conforme los vas cometiendo. Dichos ajustes son las cosas más naturales de un pensamiento creativo y no son defectos. La clave está en registrar aquellos defectos que has dejado en el producto cuando hayas acabado el diseño inicial o terminado la codificación.

Por ejemplo, si escribes una línea de código e inmediatamente ves un error en el nombre del parámetro y lo corriges, este error no es un defecto.

Si, por el contrario, acabas de codificar el programa y posteriormente observas el error, entonces sí sería un defecto y lo contabilizarías. Así, si normalmente compruebas la corrección de cada línea después de introducirla, los defectos que encuentres de esta forma no es necesario contabilizarlos. Comienza a contabilizar los defectos cuando termines una fase de un producto o parte del mismo. Después de la fase de diseño, por ejemplo, contarías todos los defectos de diseño. Supongamos, sin embargo, que estás codificando dos procedimientos de un programa. Después de codificar el primero, decides codificar el segundo, antes de comenzar la compilación del primero. A mitad de codificar el segundo procedimiento, te das cuenta de que has dado un nombre equivocado a un parámetro en el primer procedimiento. Esto es un defecto, porque aunque estés en la fase de codificación, en ese momento habías terminado la codificación del primer procedimiento. Observa que en este libro no se te exige contabilizar los defectos encontrados durante las fases de diseño y codificación. Inicialmente, es importante concentrarte sobre aquellos defectos encontrados durante la compilación y pruebas. Una vez que estés acostumbrado a reunir datos de defectos, sabrás mejor por qué son necesarios dichos datos.

Entonces puedes querer aprender más sobre los errores que cometes y corriges durante las fases de codificación y diseño. Puesto que probablemente cometerás muchos errores mientras diseñas y codificas, estas son las fases donde debes tratar de entender las causas de los defectos y ver cómo prevenirlos. Por el momento, sin embargo, comienza con aquellos defectos que encuentres en la compilación y en las pruebas. 2.2.4.- El Costo de Encontrar y Corregir Defectos 2.2.3.- Formas de Encontrar y Corregir Defectos 2.2.4.- El Costo de Encontrar y Corregir Defectos Hay varias formas de encontrar los defectos en un programa. En esencia, todos estos métodos implican los siguientes pasos:

1. Identificar los síntomas del defecto.
2. Deducir de estos síntomas la localización del defecto.
3. Entender lo que es erróneo en el programa.
4. Decidir cómo corregir el defecto.
5. Hacer la corrección.
6. Verificar que el arreglo ha resuelto el problema. Una segunda forma de encontrar defectos, es por medio de las pruebas.
La calidad de las pruebas está gobernada por el grado en que estos escenarios cubren todas las funciones importantes del programa. Se han inventado varias herramientas y ayudas para ayudar a los ingenieros en estos pasos. La primera herramienta que los ingenieros normalmente utilizan es un compilador. el trabajo del compilador es generar código. Así, un compilador explorará todo el código fuente para ver si puede generar código. Si puede, lo hará, tanto si el código es correcto como si no.
Los compiladores pueden identificar muchos defectos sintácticos, pero no pueden decir lo que uno pretende.
Los compiladores, sin embargo, solamente proporcionan síntomas de defectos y debes entender dónde y cuál es el problema. Aunque las pruebas pueden utilizarse para comprobar casi cualquier función del programa, tienen varias desventajas Primero, como con los compiladores, las pruebas solo suponen el primer paso de corrección de defectos.
Otro problema, es que cada prueba verifica solamente un conjunto de condiciones del programa.
La tercera forma de encontrar los defectos, es la más común de todas.
Consiste en entregar programas defectuosos y esperar que los usuarios identifiquen e informen de los defectos. Esta es la estrategia más costosa. Por Último, indicar que la forma más efectiva de encontrar y corregir defectos es revisar personalmente el código fuente del programa. Aunque esto puede parecer una forma difícil de limpiar un programa defectuoso, se trata de la forma más rápida y eficiente.
La causa de que la revisión de código sea tan eficiente, es porque cuando haces revisiones, ves los problemas no los síntomas. Es decir, mientras revisas el código, piensas sobre lo que el programa debe hacer.
Las revisiones también tienen desventajas. Las dos desventajas principales son que las revisiones de código consumen tiempo y es difícil hacerlas correctamente. El coste medio de encontrar y corregir un defecto crece unas 10 veces en cada paso del proceso de desarrollo.

Aunque el tiempo de corregir los defectos varía enormemente, estos valores medios muestran, a pesar de todo, los tipos de defectos

El tiempo de encontrar los defectos en las pruebas de integración, de componentes o del sistema, también variará con el tamaño y la complejidad del sistema. Una vez que los productos son entregados a los clientes, el coste de encontrar y corregir los defectos puede ser mucho mayor, dependiendo de la clase de productos y de los tipos y número de clientes.

Además del coste, una razón de igual importancia para encontrar los defectos al-principio, es que la compilación, depuración y las pruebas tienen una efectividad reducida.

Así, si se quiere producir un producto de alta calidad, tendrás que producir un programa sin defectos al principio o esperar dedicarle mucho tiempo en las pruebas. Cecilia Gutierrez Ramirez 2.6.- Controlar la Calidad del Sistema de Información 2.7.- Costo de Calidad de los Sistemas de Información 2.6.- Controlar la Calidad del Sistema de Información 2.7.- Costo de Calidad de los Sistemas de Información El logro del control de la calidad es un fin en sí mismo. Se espera que se contribuya al perfeccionamiento global de la calidad; el ingeniero que evita los errores de diseño, el obrero de producción que localiza los defectos, el representante de ventas presenta el producto adecuadamente a los clientes potenciales.
Otro concepto de calidad que está cobrando un amplio uso es seis sigma es una medida especifica de calidad, que representa 3.4 defectos de partes por millón. La mayoría de las compañías no puede lograr este nivel de calidad pero utilizan seis sigma como una meta para implementar un conjunto de metodologías y técnicas para mejorar la calidad y reducir los costos. Los sistemas de información pueden ayudar a las empresas a lograr sus metas de calidad ayudándoles a simplificar productos o procesos, a cumplir estándares de benchmarking (pruebas corporativas), hacer mejoras con base en las demandas del cliente, reducir el tiempo de ciclo y aumentar la calidad y precisión de diseño y producción.
En los sistemas de información, el control de calidad hace referencia a los mecanismos y procedimientos introducidos en la rutina del sistema, con el fin de prevenir la aparición de defectos y errores, así como para garantizar ciertos niveles de calidad en los procesos que han sido establecidos de antemano, de acuerdo con los recursos disponibles. El Coste de la Calidad (CDC) proporciona una forma de tratar estas cuestiones. El CDC tiene tres elementos principales: costes de los fallos, costes de valoración y costes de prevención.
Los costes de los fallos incluyen todos los costes de corregir los defectos del producto. Mientras estás corrigiendo un defecto, estás incurriendo en unos costes de los fallos Los costes de valoración incluyen todo el trabajo de valoración del producto para ver si tiene defectos, excluyendo el tiempo dedicado a la corrección de defectos. Incluye la revisión de código, el tiempo de compilación y las pruebas para un programa libre de errores.

Los costes de prevención son los costes incurridos cuando modificas el proceso para evitar introducir defectos. Incluye, por ejemplo, los análisis hechos para comprender los defectos. 2.7.1.- Calculo del Costo de la Calidad El PSP mide el CDC de una forma muy sencilla. Aunque el tiempo dedicado a la compilación incluye algún tiempo de compilación libre de defectos, el PSP (Proceso Software Personal) contabiliza todo el tiempo de compilación como costes de fallos.

El PSP contabiliza todo el tiempo de pruebas como costes de fallos. Finalmente, todo el tiempo de revisión es contabilizado como coste de valoración. Este tiempo incluye algún coste de reparación, pero el PSP contabiliza todo el tiempo de revisión como coste de valoración. El coste de la calidad se calcula como un porcentaje del tiempo de desarrollo total. Para el PSP, los costes de valoración y fallos se calculan de las siguiente forma:
La valoración CDC es la suma de todo el tiempo de revisión como un porcentaje del tiempo total de desarrollo.
Los fallos CDC es la suma de todo el tiempo de compilación y pruebas como un porcentaje del tiempo total de desarrollo.
Por ejemplo, supongamos que se tienen los datos del proceso que se muestran en la Tabla siguiente. Resumen del Plan del Proyecto. Se Podría calcular la valoración CDC de la siguiente forma: 2.7.1.- Calculo del Costo de Calidad Gracias por su Atención... @YasHGeek 2.4 gestión del tiempo para el desarrollo de sistemas de información 2.5 Obtener Calidad en los Sistemas de Información 2.3.- Listas de Comprobación 2.4 Gestión del tiempo para el Desarrollo de Sistemas de Información 2.5 Obtener Calidad en los Sistemas de
Información Una lista de comprobación contiene una serie de pasos que tú quieres seguir de forma rigurosa. Cuando utilizas una lista de comprobación desarrollada a partir de tus propios defectos, harás revisiones más eficientes.

La lista de comprobación no solamente ayuda a encontrar más defectos, también ayuda a encontrarlos más rápidamente. Para construir una lista de comprobación para la revisión de código, adáptala al lenguaje que utilices, diséñala a partir de tus propios defectos y ajústala a tus habilidades y experiencia cambiante. Algunas orientaciones para utilizar la lista de comprobación son: haz las revisiones paso a paso, completa cada programa o procedimiento antes de iniciar el siguiente, examina cada apartado de la lista de comprobación cuando lo completes. Cuando encuentres defectos, anota el número encontrado en cada apartado de la lista de comprobación. Cuando lo hagas, completa las columnas Hasta la Fecha y % Hasta la Fecha. Después de acabar cada programa, revisa los datos y la lista de comprobación para ver cómo la puedes mejorar. Las listas de comprobación también pueden ser una fuente de ideas. Cuando sigues una lista de comprobación personal, sabes cómo revisar tu código. Si utilizas la lista correctamente, también sabes cuantos defectos encuentras en cada paso de dicha lista. Comparar tu lista de comprobación con las de otros ingenieros, te puede sugerir aproximaciones útiles para la revisión.
La lista de comprobación encapsula la experiencia personal. Utilizándola con regularidad y mejorándola, mejorarás en la detección de los defectos de tus programas. La lista de comprobación también te ayudará a encontrar estos defectos en menos tiempo. CÓMO EVALUAR TU DISTRIBUCIÓN DEL TIEMPO Ahora que puedes saber cómo utilizas tu tiempo, pregúntate a ti mismo si estás utilizando el tiempo de la forma que quieres. Decide qué actividades son más importantes y considera si estás dedicándole el tiempo suficiente. ¿A algunas tareas, le dedicas más tiempo que a otras que son más importantes? ¿Estás dejando suficiente tiempo para leer el libro de texto? ¿Haces el trabajo? Y, ¿cuáles son tus compromisos personales? ¿Comienzas los ejercicios a tiempo para acabarlos, o los terminas en el último momento?
Esta es una decisión muy personal que debes equilibrar entre el trabajo académico, las tareas, el descanso y la vida social. Algunos de estos componentes son cuestiones personales que implican complejas elecciones, particularmente si tienes un trabajo y responsabilidades familiares. Como Encontrar Mas Tiempo Después de haber revisado la estimación de tiempo, puedes necesitar aumentar la cantidad total de tiempo. ¿Cómo puedes hacer esto? Tienes varias opciones. Primero, si tu agenda no está muy ocupada, serás capaz de encontrar un poco de tiempo extra, pero desdichadamente, pocas personas están bendecidas con el tiempo libre. Es más probable que estés super comprometido. En este caso, haz un amplio estudio de todos tus compromisos. Después revisa el tiempo que utilizas tanto en las clases, como en las principales áreas de trabajo, así como en las actividades de ocio.
Para gestionar bien tu tiempo analiza tus propios datos históricos de tiempos. Establece una estimación para utilizar el tiempo y registra tu tiempo real frente al estimado. Para hacer una estimación de tiempo decide cómo quieres utilizar el tiempo. Haz una programación que refleje tu elección y que muestre los tiempos cada día; puedes necesitar diferentes estimaciones para distintas semanas. Las reglas básicas para estimar el tiempo pueden ser útiles: identifica tus compromisos fijos y variables. Divide tu tiempo variable en tareas que son exigidas y aquellas que son discrecionales. Analiza como divides ahora tú tiempo en estas categorías. Recuerda que tu tiempo total es fijo: si necesitas más tiempo para algunas actividades, debes dedicar menos tiempo a otras.
Finalmente, revisa el rendimiento frente al tiempo estimado: continúa reuniendo datos de tiempos. Revisa el tiempo estimado frente a tu experiencia real. Revisa la estimación basándote en tus necesidades y experiencias. Haz los cambios de forma gradual. Cuando cambies tu estimación de tiempo, guarda las versiones anteriores. Conforme los programas son más grandes, es más costoso encontrar y corregir los defectos. El proceso de eliminación de defectos es también me- nos efectivo. La estrategia para producir grandes programas de gran calidad es, en primer lugar, eliminar todos los defectos de los módulos que forman estos grandes programas. La eliminación de defectos es un proceso de filtrado: ve cada fase de eliminación de defectos como un filtro. Cuantos más defectos se pongan en el filtro más se encontrarán. También, cuantos más defectos se pongan en el filtro, más se pasarán por alto. El rendimiento de muchas fases de prueba es menor del 50%. Así, para obtener un producto de alta calidad al final de una prueba, debes poner un producto de alta calidad al comienzo de la prueba. Un trabajo concienzudo en cada paso de tu proceso será rentable y ahorrará tiempo. Si haces un programa mal, se encontrarán muchos defectos en la compilación y en cada subsiguiente fase de pruebas. El rendimiento mide la calidad de la eliminación de defectos. El rendimiento del proceso se refiere a la tasa de defectos en el producto que son eliminados antes de la primera compilación. El rendimiento puede medir también la tasa de defectos en un producto que son eliminados en la fase de eliminación de defectos. Tu objetivo sería lograr el 100% de rendimiento del proceso.

Recuerda: no serás capaz de hacer grandes programas de mucha calidad hasta que no puedas hacer de forma constante pequeños programas de gran calidad. Esto supone una dedicación constante a la calidad, disciplina personal y mucha práctica. Para lograr la máxima calidad en un programa, haz pequeños prototipos para probar cada suposición antes de incorporarla al producto. Aprende a reconocer la diferencia entre lo que crees que sabes y lo que realmente sabes. Cada vez que hagas una suposición, es probable que introduzcas un defecto. El proceso de medida del rendimiento introducido en el Capítulo 16, tiene que ver con la tasa de eliminación de defectos antes de la primera compilación. La medida del rendimiento, sin embargo, puede ser aplicada a cualquier paso de la eliminación de defectos. Así, el rendimiento de cada fase puede calcularse de la siguiente forma: Rendimiento de la Fase = 100*(número defectos eliminados durante la fase)/(número de defectos en el producto al inicio de la fase). Desafortunadamente, los datos sobre los rendimientos de compilación y pruebas no son tranquilizadores. Como se muestra en la Tabla 18.1, las revisiones de código e inspecciones tienen mejores rendimientos, mientras la compilación, pruebas de unidad y otras formas de pruebas son menos efectivas [Humphrey 891. Estas cifras están basadas en datos limitados y puede que no se apliquen a tu situación particular, pero estos son todos los datos que tenemos. La mejor respuesta para ti, naturalmente, sería reunir los datos de rendimiento de tus propios métodos de eliminación de defectos y sacar tus propias conclusiones. Es interesante observar que el método de mayor rendimiento de la Tabla 18.1 es para los ingenieros que hacen una revisión de código. El siguiente mayor rendimiento es para las inspecciones, donde varios ingenieros revisan entre sí el diseño y el código. Los métodos que tienen los mayores rendimientos son manuales y no implican ninguna herramienta automatizada. La razón de que sean mejores que otros métodos es que la mente humana es el instrumento de detección de defectos más poderoso que cualquier herramienta software actual. La conclusión lógica de estos datos es que, para hacer programas de alta calidad, debes tener el menor número de defectos posible al comenzar las pruebas. Comenzar las pruebas con el menor número de defectos, significa salir de la fase de compilación con el menor número de defectos. Finalmente, para salir de la fase de compilación con el menor número de defectos, debes eliminar los defectos antes de comenzar a compilar. Naturalmente, para hacer productos de máxima calidad, deberías medir, analizar y mejorar cada fase de eliminación de defectos.
Full transcript