Aseguramiento de la Calidad Aplicada Proyecto ITS 312 Diagrama de temas

Bienvenida

Este curso es el segundo curso de la serie Metodologa de Aseguramiento de Calidad. El curso Metodologa para el Aseguramiento de la Calidad es requisito para poder tomar este curso. En el curso Metodologa para el Aseguramiento de Calidad. definimos que es calidad, que son modelos conceptuales, que es usabilidad, que es lo difcil de los proyectos Web, como se controla la calidad a nivel de proyecto, que aspectos de calidad de la mantenibilidad del software debemos tener en cuenta y qu medidas se pueden usar para medir dichos conceptos. En este curso, aplicaremos diferentes aspectos de la administracin de la calidad, evaluacin de la calidad del proceso de desarrollo de software, y del proyecto en s. El objetivo del curso es trabajar en proyectos prcticos para aplicar la teora d el curso Metodologa para el Aseguramiento de la Calidad. El aseguramiento de calidad de software involucra revisiones y auditorias de los productos de software y sus actividades para verificar que cumplen con los procedimientos y los estndares aplicables y que proporcionan al proyecto y a los gerentes los resultados de dichas revisiones y auditorias.
o

Objetivos

proveer a los gerentes con suficiente visibilidad dentro del proceso que se est usando en el desarrollo de productos de un proyecto de software.

Objetivos Especificos

Aplicar los conceptos de calidad estudiados en el curso Metodologa para el Aseguramiento de la Calidad a un software especfico o producto.

Aplicar diferentes aspectos de la administracin de la calidad, evaluacin de la calidad del proceso de desarrollo de software.

trabajar en proyectos prcticos para aplicar la teora que el curso Metodologa para el Aseguramiento de la Calidad.

Contenidos

Sesin 1 Proyecto de Investigacin El objetivo de esta sesin es trabajar en un proyecto de investigacin que analizar un marco de trabajo especfico. Al final de la sesin el estudiante debe tener una idea clara de:
o o o o

Que son los marcos de trabajo Que categoras de marcos de trabajo existen Que marcos de trabajos orientados a la calidad de software Detalles especficos sobre un marco de trabajo del Modelo de Capacidad y Madurez.

Video La Ingeniera de Software es una disciplina que estudia los procesos, mtodos y herramientas vinculadas en la produccin de software de calidad. <center><iframe width="640" height="480" src="https://www.youtube.com/embed/YFin8nNnARA" frameborder="0" allowfullscreen></iframe> Sesin 2 Proyecto de Mejoramiento de Calidad de Software El objetivo de esta sesin es trabajar en un proyecto prctico de mejoramiento de calidad de software donde pueda comprender la aplicacin de los conceptos. Al final de la sesin el estudiante debe tener una idea clara de:
o o o o

Como planificar mejoramientos de calidad de software Como seleccionar la medida de calidad apropiada para medir el nivel de mejora Como definir los datos requeridos Como planificar la recoleccin de datos

Video

La calidad del software es una preocupacin a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios. <center> <iframe width="640" height="480" src="https://www.youtube.com/embed/17kgzOO8t8" frameborder="0" allowfullscreen></iframe> Sesin 3 Proyecto de Definicin de Requerimientos Esta sesin definir los requerimientos funcionales, de interfaz de usuario y de calidad de un producto especfico. Al final de esta sesin el estudiante tendr una idea clara de:
o o o

Como se entrevista a cliente para definir requerimientos de un sistema Como se documenta los requerimientos de sistema Como se planifica la calidad requerida de un sistema desde un principio

Video Jordi Borja, Director de desarrollo de negocio y estrategia de solucin, Visure solutions visuresolutions.com/index_sp.php, explica cmo conocer el xito desde la construccin del primero software. Para ello, enfoca sobre la identificacin de las necesidades del cliente. <center><iframe width="640" height="480" src="https://www.youtube.com/embed/OMpn9vTFbDk" frameborder="0" allowfullscreen></iframe> Video Introduccin al estandar IEEE 830 para Ingeniera del Software <iframe width="640" height="480" src="https://www.youtube.com/embed/WKXdXJ6XXd0" frameborder="0" allowfullscreen></iframe> Sesin 4 Proyecto de Plan de Aseguramiento de Calidad (SQA) El objetivo de esta sesin es investigar que es un plan de evaluacin de calidad (SQA). Al final de la sesin el estudiante deber tener una idea clara de:
o o

Que es un plan de evaluacin de calidad de software Cules son los componentes de un plan de evaluacin de calidad de software

Video <center> <iframe width="640" height="480" src="https://www.youtube.com/embed/GpD_ga7VSnI" frameborder="0" allowfullscreen></iframe> Sesin 5 Medidas de la Satisfaccin del Cliente La satisfaccin del cliente es la validacin mxima de calidad. El objetivo de esta sesin es estudiar el uso y anlisis de los datos de una encuesta de satisfaccin del cliente. Al final de la sesin el estudiante debe tener una idea clara de:
o o o

Diferentes mtodos de recolectar datos de una encuesta Aspectos a considerar al definir el muestreo Anlisis de los datos de la encuesta

Video Cmo medir la satisfaccin del cliente? <center> <iframe width="640" height="360" src="https://www.youtube.com/embed/xtmVDewJytA" frameborder="0" allowfullscreen></iframe> Sesin 6 Proyecto de Cuestionario de Satisfaccin del Cliente La satisfaccin del cliente es la validez mxima de calidad. En la sesin anterior usted inici el proyecto de satisfaccin del cliente. El objetivo de esta sesin es completar el proyecto y publicarlo para recibir comentarios de sus compaeros. Los comentarios de su instructor y sus compaeros deberan de ayudarle ver su proyecto de diferentes perspectivas. Al final de la sesin el estudiante debe tener una idea clara de:
o o o o

Tipo de preguntas que funcionan mejor en las encuestas de satisfaccin del cliente Problemas en la recoleccin de datos de las encuestas de satisfaccin del cliente Procedimientos para manejar datos faltantes Problemas con el anlisis de datos de encuestas

Sesin 7 Proyecto de Plan de Aseguramiento de Calidad (SQA) de un sitio Web

El objetivo de esta sesin es trabajar en un proyecto prctico de planificacin de aseguramiento de calidad (SQA), donde pueda relacionar conceptos cubiertos en la ltima sesin de ITS211, con los aspectos especficos de los sistemas Web cubiertos en la sesin anterior Al final de la sesin el estudiante debe tener una idea clara de:
o o o o

Como aplicar los conceptos de un plan de aseguramiento de calidad (SQA) a un proyecto Web Que aspectos se deben de evaluar en un sistema Web para asegurar confiabilidad Como definir los requerimientos del sistema Como evaluar la experiencia del usuario

Video <center><iframe width="640" height="480" src="https://www.youtube.com/embed/e89aiT_t6BE" frameborder="0" allowfullscreen></iframe> Sesin 8 Proyecto de Mtricas de Calidad de Proceso Esta sesin aplicar las medidas de proceso claves para administrar efectivamente el proceso de software de un producto especfico. Al final de esta sesin el estudiante tendr una idea clara de:
o o o

Que son la medidas de proceso Como se seleccionan las medidas de proceso Como se interpretan las medidas de proceso

Video Video que demuestra algunos de los factores de calidad y las metricas de calidad, tambin conocido como McCall. <center> <iframe width="640" height="480" src="https://www.youtube.com/embed/C1CKO9bFbDg" frameborder="0" allowfullscreen></iframe>

Facilitador

Evaluacin

Sesin 1 Proyecto de Investigacin Tarea 1: Proyecto Individual El objetivo de esta actividad investigar sobre el Modelo de Capacidad y Madurez (CMM). Usted deber preparar un reporte de 5-10 pginas sobre que es el modelo CMM, cual es su objetivo, como ha evolucionado, cuales niveles incluye y como se caracterizan cada uno de ellos, como se avanza de un nivel a otro, aspectos controversiales, beneficios que proporciona y bajo qu circunstancias ofrece los mejores resultados. Tarea 2: Modelo de Capacidad y Madurez Publique un resumen de 250 palabras de lo que usted ha entendido del Modelo de Capacidad y Madurez, su objetivo, que indica cada nivel, y que problemas y ventajas presenta. Haga comentarios a los proyectos de por lo menos dos de sus compaeros de clase. Sesin 2 Proyecto de Mejoramiento de Calidad de Software Tarea 1: Disear un proyecto de mejoramiento de la calidad El objetivo de esta actividad es disear un proyecto de mejoramiento de la calidad de software. El proyecto incluye varias secciones:
o o o

Seleccione un proyecto con el cual usted tenga familiaridad o acerca del cual pueda conseguir informacin Identifique cuatro metas de mejoramiento de calidad que le gustara alcanzar en el proyecto Identifique las preguntas y medidas que le permitirn monitorear el progreso hacia el cumplimiento de las metas.

Para cada uno de las metas, necesita desarrollar una lista de 3 a 5 preguntas a examinar. Para cada pregunta, necesitar seleccionar la medida apropiada para medir cambios en las reas de inters. Necesitar definir los datos necesarios para calcular la medida y decidir el punto del proceso donde se recolectarn dichos datos. Tambin, necesitar disear los formularios que se usarn por los miembros del equipo para recolectar los datos.

El proyecto debe de incluir:

o o o o o o o

Una descripcin detallada del proyecto de software Descripcin de sus metas Preguntas para cada meta Medidas que se usarn para definicin Descripcin de los datos necesarios Formularios de recoleccin de datos Horario de recoleccin de datos

Tarea 2: Resumen de su proyecto a desarrollar Publique un resumen de 250 palabras del proyecto en el que trabajar esta semana. Haga comentarios a los proyectos de por lo menos dos de sus compaeros de clase.

Sesin 3 Proyecto de Definicin de Requerimientos Tarea 1: Proyecto Individual El objetivo de este proyecto es definir los requerimientos de un sistema nuevo. Usted debe de identificar una nueva aplicacin y quien sera el usuario final de la misma. Su misin es entrevistarlo para recolectar los requisitos funcionales, de interfaz de usuario y de calidad que el sistema debe de cumplir. Una vez haya entrevistado al usuario final, deber documentar todos los requerimientos del sistema de una forma clara, definiendo que mtrica cree que puede ser usada para evaluar que el requerimiento se haya cumplido. Sintase en libertad de asumir ciertos detalles del sistema, pero asegrese de documentar lo que ha asumido. Use diagramas o grficos cuando sean apropiados. El reporte de diseo de especificaciones deber incluir:
o o o o o o o

Descripcin conceptual de la aplicacin Descripcin de los clientes potenciales Descripcin de la infraestructura (hardware, sistema operativo, software) bajo el cual debe de funcionar Descripcin de los requerimientos funcionales de la aplicacin Descripcin de los requerimientos de interfaz de usuario Descripcin de los requerimientos de calidad necesarios Medidas a usar para comprobar que se cumplan todos los requerimientos

Gua de niveles aceptables de medidas

Sesin 4 Proyecto de Plan de Aseguramiento de Calidad (SQA) Tarea 1: Proyecto Individual El objetivo de este proyecto es investigar que es un plan de evaluacin de la calidad de software, que debe de incluir. Esta investigacin le servir de modelo para un proyecto del prximo curso. El reporte debe de incluir:
o o o o o

Descripcin de que es un plan de evaluacin de evaluacin de la calidad de software (SQA) Objetivos del plan SQA ndice de las secciones del plan Explicacin del contenido de cada seccin Referencias

Enve el reporte final del proyecto a su instructor. Tarea 2: Plan de calidad de software Publique un resumen de su reporte sobre el contenido de un plan de calidad de software. El resumen debe de ser presentado en la forma de una presentacin de PowerPoint. Haga comentarios a las publicaciones de por lo menos dos de sus compaeros. Como siempre, sus comentarios deben de incluir dos afirmaciones y dos preguntas

Sesin 5 Medidas de la Satisfaccin del Cliente Tarea 1: Diseo de Cuestionario de Satisfaccin del Cliente Leer artculo: Diseno_Encuestas.pdf. Annimo, Evaluacin del Servicio a Travs de Encuestas, Recuperado Mayo 17, 2006, del sitio Web: http://www.monitoreociudadano.gob.mx/doctos/diseno_encuestas.pdf

El objetivo de este proyecto es disear un cuestionario de satisfaccin del cliente. Usted tiene esta semana y la prxima para ejecutar el proyecto. El resultado del proyecto ser publicado en un foro de discusin de la prxima semana para que sus compaeros lo revisen y le den comentarios. El proyecto requiere de las siguientes actividades:
o o o o o o o o

Seleccione un software o hardware con el cual usted tiene familiaridad Disee la encuesta de satisfaccin del cliente Identifique la poblacin de usuarios y defina el tamao del muestreo Su cuestionario debe de incluir 5 preguntas demogrficas y por lo menos 15 preguntas de calidad relacionadas con la usabilidad del producto. Ejecute un plan piloto del cuestionario con 20 a 25 personas que pertenecen a la poblacin del muestreo Justifique el mtodo de recoleccin de datos que provee la mayor respuesta posible de muestreo de usuarios Prepare un resumen estadstico del piloto de la encuesta Proponga anlisis avanzado de los datos, pero no lo lleve a cabo.

Tarea 2: Objetivo de su encuesta y de su diseo Introduccin El objetivo de esta sesin es entender los componentes que forman una encuesta de satisfaccin del cliente y poner ese conocimiento en prctica. Este proyecto se ejecutar en dos semanas. Esta sesin incluye el diseo de la encuesta, la identificacin de la poblacin objetivo y un muestreo. Ejecucin y anlisis de la encuesta son las actividades que se llevarn a cabo la prxima semana. Actividad En base a lo estudiado y realizado publique resumen de 250 palabras del objetivo de su encuesta y de su diseo. Haga comentarios a por lo menos dos de las definiciones de sus compaeros. Sus comentarios deben de incluir dos afirmaciones y dos preguntas.

Sesin 6 Proyecto de Cuestionario de Satisfaccin del Cliente

Tarea 1: Resultado de la Encuesta de Satisfaccin del Cliente Para esta actividad, deber entregar un reporte de la encuesta de satisfaccin del cliente diseada y ejecutada en la sesin anterior. El reporte debe de incluir:
o o o o o o o o

Descripcin corta del producto y de la poblacin de usuarios Descripcin corta de los objetivos del proyecto Cuestionario de satisfaccin del cliente Descripcin del muestreo de la poblacin Descripcin de la ejecucin del programa piloto Resumen de estadsticas Discusin de resultados Lecciones aprendidas y recomendaciones de futuros cambios

Enve el reporte final del proyecto a su instructor. Tarea 2: Encuesta de Satisfaccin del Cliente Introduccin La mayor parte del trabajo de esta sesin es la ejecucin de la encuesta de satisfaccin del cliente diseada en la sesin anterior. El proyecto requiere un reporte que ser calificado por su instructor y un resumen de dos pginas del proyecto del que recibir retroalimentacin de sus compaeros. Actividad Publique un resumen de dos pginas del resultado de su proyecto para recibir retroalimentacin de sus compaeros. Por favor publique su resumen por lo menos dos das antes del final de la semana. Comente sobre los proyectos de dos de sus compaeros. Como siempre, sus comentarios deben de incluir por lo menos dos afirmaciones y dos preguntas. Sesin 7 Proyecto de Plan de Aseguramiento de Calidad (SQA) de un sitio Web Tarea 1: Proyecto Individual El objetivo de esta actividad es disear un plan de aseguramiento de la calidad de software (SQA) de un sistema Web. El proyecto incluye varias secciones:

o o o o

Seleccione un proyecto Web con el cual usted tenga familiaridad o acerca del cual pueda conseguir informacin Identifique los requerimientos originales del sistema Identifique quienes son los usuarios del sistema y cual es el objetivo que esperan lograr al visitar el sitio Identifique cuales eran los objetivos de calidad para la entrega

El objetivo de este proyecto es definir un plan de aseguramiento de calidad resumido. Si no tiene toda la informacin necesaria, especifique lo que ha asumido. El proyecto debe de incluir:
o o o o o o o o o o

Una descripcin detallada del proyecto de software Descripcin de los requerimientos Descripcin de los usuarios potenciales y sus objetivos Objetivos de calidad para la entrega (esenciales, esperadas, deseadas) Plan de desarrollo Plan de pruebas Plan de administracin Plan de accin (Asignacin de tareas a personas) Formularios de recoleccin de datos Horario de recoleccin de datos

Tarea 2: Resumen del plan de aseguramiento de su aplicacin Web Publique un resumen del plan de aseguramiento de su aplicacin Web a travs de una presentacin. Haga comentarios a los proyectos de por lo menos dos de sus compaeros de clase.

Sesin 8 Proyecto de Mtricas de Calidad de Proceso Tarea 1: Proyecto Individual El objetivo de este proyecto es disear un plan de evaluacin que determine si el producto est listo para ser liberado. El programa de software a usar es uno con el cual usted est familiarizado y debe de tener por lo menos 500 lneas de cdigo.

Una vez identifique el programa que usar, deber desarrollar el plan de evaluacin. Asuma que esta es la primera versin a ser liberada del producto y que el objetivo del plan es determinar si la fecha planificada de liberacin se puede cumplir. El reporte deber incluir:
o o o o o

Descripcin detallada del producto Descripcin de la funcionalidad del programa Plan de pruebas Medidas a usar Gua de niveles aceptables de medidas

Biblioteca

Libro de Texto requerido

Calidad en el desarrollo y mantenimiento del software. PIATTINI, M. G. y GARCA F. O. Editorial RA-MA Fecha Publicacin: Enero 2003. ISBN:8478975446. Artculos CalidadSoftware.pdf mExtracto del libro digital Calidad Tradicional y de Software por Alejandro Bendini G. Recuperado Mayo 16, 2006, del sitio Web: http://www.willydev.net/descargas/Articulos/General/CalidadSoftware.pdf

Material de Referencias
Proceso Del Software http://www.slideshare.net/leo_ruth/proceso-del-software Arquitectura de software-Modelo, marcos de trabajo y patrones de diseo: http://administrandoproyectos.blogspot.com/2011/01/arquitectura-de-software-modelomarcos.html Arquitectura de software: http://administrandoproyectos.blogspot.com/search/label/Arquitectura%20de%20Software Aseguramiento De La Calidad Del Software: http://administrandoproyectos.blogspot.com/search/label/Aseguramiento%20de%20la%20 calidad%20del%20software Aseguramiento de la calidad dentro de un proyecto de Software: http://administrandoproyectos.blogspot.com/search/label/Aseguramiento%20de%20la%20 calidad%20dentro%20de%20un%20proyecto%20de%20Software

Metodologas para la gestin y desarrollo de Software: http://es.scribd.com/doc/8255409/Metodologias-para-la-geston-y-desarrollo-de-Software Software Productivity Center http://www.spc.ca/resources/index.htm R.S. Pressman and Associates http://www.rspa.com/ The Data & Analysis Center for Software http://www.dacs.dtic.mil/ NIST Quality Program http://www.quality.nist.gov/ ISO Online http://www.iso.org/iso/en/ISOOnline.frontpage Deming Electronic Network http://deming.eng.clemson.edu/pub/den/ Tantara Software Engineering Resources http://www.tantara.ab.ca/info.htm

Desarrollo del Contenido

Sesin 1 Proyecto de Investigacin Que son los marcos de trabajo

Marcos de trabajo Un marco de trabajo es una estructura de soporte, en la cual se base otro proyecto de software. Los marcos de trabajo son diseados para facilitar el desarrollo de software; por lo tanto, la clave de un buen marco de trabajo es que sea escalable y fcil de usar. Definen una arquitectura adaptada a las particularidades de un determinado dominio de aplicacin, definiendo de forma abstracta una serie de componentes y sus interfaces y estableciendo las reglas y mecanismos de interaccin entre ellos. El Marco de trabajo del proceso Actividades de Proteccin Base para un proceso de software completo. Es como un libro de recetas de cocina. Siento que una receta es slo un tema con el que un cocinero inteligente puede jugar cada vez de una manera distinta Madame Benoit La adaptacin es esencial. Marco de trabajo del Proceso comn Aplicables a lo largo del proceso del software. Su objetivo la gestin, el rastreo y el control del proyecto. Garantizar la calidad del software. Actividades del marco de trabajo Aplicables a todos los proyectos. Conjunto de Tareas Actividades que hacen que el marco de trabajo se adapte a las caractersticas particulares de cada proyecto de software. Define el trabajo real a cumplirse. Tareas Hitos, entregas Puntos SQA Suele incluirse la implementacin de algunos de los componentes e incluso varias implementaciones alternativas.

 El usuario Selecciona, instancia, extiende y reutiliza los componentes del marco. Completa la arquitectura con nuevos componentes especficos dentro de las relaciones estructurales del marco. Bsicamente se presentan como un diseo reutilizable de todo o parte de un sistema, representado por un conjunto de componentes abstractos y la forma en que los componentes interactan. Una alternativa es verlos como un esqueleto de una aplicacin que debe ser adaptado por el programador segn sus necesidades concretas. Un marco de trabajo define el patrn arquitectnico que relaciona los componentes de un sistema Presentan dos niveles: Especificacin de la arquitectura marco. Implementacin del marco de trabajo (normalmente un lenguaje orientado a objetos). Al desarrollo de aplicaciones a partir de un marco de trabajo se le denomina extensin del marco: Puntos de entrada (hot spots): Componentes o procedimientos cuya implementacin final depende de la aplicacin concreta. Definidos por el diseador del marco para que sean la forma natural de la extensin del mismo. Que categoras de marcos de trabajo existen

Dependiendo de la extensin tenemos: Marcos de trabajo de caja blanca Que se extienden mediante herencia, concretamente mediante la implementacin de las clases y mtodos abstractos definidos como puntos de entrada. Se tiene acceso al cdigo del marco y se permite reutilizar la funcionalidad de sus clases mediante herencia y redefinicin de mtodos. Marcos de trabajo de caja de cristal

Admiten la inspeccin de su estructura e implementacin, pero no su modificacin ni extensin, excepto en los puntos de entrada. Dependiendo de su aplicabilidad tenemos: Marcos de trabajos horizontales Vlidos para todos los dominios de aplicacin concretados en un aspecto del sistema. Infraestructuras de comunicacin, interfaces de usuario, entornos visuales, etc. Marcos de trabajo distribuidos (Middelware Application Frameworks) o Plataforma de Componentes Distribuidos para integrar componentes distribuidas. Aslan las dificultades conceptuales y tcnicas del desarrollo de aplicaciones distribuidas basadas en componentes. marcos de trabajos orientados a la calidad de software

Pasos para lograr un control total de calidad

Kaizen (mejora continua). Su objetivo es desarrollar un proceso que sea visible, repetible y medible. Atarimae hinshitsu. Examina lo intangible que afecta al proceso y trabaja para optimizar su impacto. Kansei (Los cinco sentidos). Examina la forma en que el usuario aplica el producto y conduce a la mejora del producto y del proceso que lo cre. Miryokuteki hinshitsu (Las cosas van bien). Examinando la utilizacin del producto en el mercado, identifica oportunidades en reas relacionadas.

Modelo CMM (Capability Maturity Model) Desarrollado por el Instituto de Ingeniera de Software (SEI) de la Universidad de Carnegie-Mellon en Pittsburgh. Proporciona una medida de la efectividad global de las prcticas de ingeniera de software en una compaa y establece 5 niveles de madurez del proceso, cada nivel (excepto el 1), tiene definidas reas claves de proceso (KPA) y cada nivel incluye las reas del nivel anterior. 1. Inicial.
o

El proceso depende del problema.

o o

Se definen pocos procesos. El xito depende del esfuerzo individual.

2. Repetible. Se establecen procesos de administracin del proyecto para hacer seguimientos del costo, planificacin y funcionalidad. Se pueden repetir xitos anteriores aplicando la disciplina necesaria. Areas claves:
o o o o o o

Administracin de configuracin. Aseguramiento de calidad (SQA). Administracin de subcontratacin (outsourcing). Seguimiento y supervisin del proyecto. Planeacin del proyecto. Administracin de requisitos.

3. Definido. El proceso de software se documenta, standariza y se integra para toda la empresa. Todos los proyectos utilizan una versin documentada y aprobada del proceso de desarrollo. Areas claves.
o o o o o o o

Revisiones peridicas. Coordinacin entre grupos. Ingeniera de productos de software. Administracin de integracin del software. Programa de formacin. Definicin del proceso de la organizacin. Enfoque del proceso de la organizacin.

4. Administrado. Se recopilan medidas detalladas del proceso y de la calidad del software y con ellas se comprenden y controlan cuantitativamente tanto los productos como el proceso del software.

reas claves.
o o

Administracin de calidad del software. Administracin cuantitativa del proceso.

5. Optimizado. Mediante un resultado cuantitativo del proceso y de las ideas y tecnologa nuevas, es posible una mejora del proceso. reas claves.
o o o

Administracin de cambios del proceso. Administracin de cambios de tecnologa. Prevencin de defectos.

Detalles especficos sobre un marco de trabajo del Modelo de Capacidad y Madurez.

CMM El Modelo de Madurez de Capacidades (CMM) es un modelo de referencia para la aplicacin de conceptos de gestin de procesos y de mejora de calidad en el desarrollo y mantenimiento de software, que deben ser implementadas por toda organizacin interesada en desarrollar y mejorar la calidad de sus productos y su productividad. Este modelo est basado en conceptos de calidad total y de mejoramiento continuo y ha sido desarrollado en el SEI (Software Engineering Institute) relacionado con Carnegie Mellon University, en Pittsburgh. El CMM se desarroll como reaccin a la crisis del software a principios de los ochenta y financiado por el Departamento de Defensa de los Estados Unidos. Se entiende por proceso el saber cmo utilizar el conocimiento del personal y latecnologa de forma eficiente para lograr productos que alta calidad quesatisfagan las necesidades de los clientes, producidos dentro de costos y plazos aceptables. Un proceso puede considerarse maduro si cumple con los siguientes criterios: Est definido: El proceso es claro, sistemtico y suficientementedetallado. Adems existe acuerdo entre el personal, la gerencia y los proyectos respecto al proceso que se va a utilizar. Esta documentado: Esta escrito en un procedimiento publicado, aprobado y fcilmente accesible. El personal ha sido entrenado en el proceso: Los ingenieros de software y la gerencia han recibido cursos y entrenamiento en cada proceso que aplica a su trabajo

Es practicado: El proceso definido debe ser usado en las tareashabituales llevadas a cabo por los proyectos. El entrenamiento y la adaptacin del proceso a la realidad de la empresa debieran garantizar su aplicacin en la vida real. Es mantenido: El proceso es revisado regularmente, para asegurarseque est adaptado para satisfacer las necesidades reales de losproyectos Est controlado: Los cambios y puestas al da del proceso sonrevisados, aprobados y comunicados oportunamente a todos losusuarios. Se verifica: La gerencia mantiene mecanismos para asegurarse de que todos los proyectos siguen el proceso vigente. Se valida: Se asegura que el proceso mantiene concordancia con los requerimientos y estndares aplicables. Se mide: La utilizacin, los beneficios y el rendimiento resultante del proceso se miden regularmente. Puede mejorarse: Existen mecanismos y apoyo de la gerencia para revisar e introducir cambios en el proceso, de manera que se pueda mejorar su eficacia e incorporar nuevas metodologas.

El CMM se basa principalmente es dos conceptos importantes, el concepto de proceso maduro, definido anteriormente y el concepto de nivel de madurez que es definido como la capacidad de los procesos de ingeniera de software y de administracin de proyectos usados en una organizacin de desarrollo de software y entendindose por maduro el definido anteriormente como proceso. Niveles de Madurez de CMM El CMM identifica los niveles de madurez de los procesos siguientes: As es como el modelo CMM mide el progreso conforme avanza, en niveles de madurez. Cada nivel tiene un cierto nmero de reas de proceso importantes que deben lograrse. Su logro se detecta mediante la satisfaccin (o no) de varios metas claras y cuantificables. Con excepcin del Nivel 1, cada uno de estos Niveles de Madurez est compuesto por un cierto nmero de reas Claves de Proceso, conocidas a travs de la documentacin del CMM por su sigla inglesa: KPA. Cada KPA identifica una agrupacin de actividades y prcticas relacionadas, las cuales cuando son realizadas en forma colectiva permiten lograr alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestin, Organizacional e Ingeniera. Las prcticas que deben ser realizadas por cada rea Clave de Proceso estn organizadas en 5 Caractersticas Comunes, las cuales constituyen propiedades que indican si la implementacin y la institucionalizacin de un proceso clave es efectivo, repetible y duradero.

Estas 5 caractersticas son: Compromiso de la realizacin. La capacidad de realizacin. Las actividades realizadas Las mediciones y el anlisis La verificacin de la implementacin. El modelo CMM se formula de una manera genrica. Es independiente de cualquier mtodo (o metodologa) y de cualquier ambiente de tecnologa (software o hardware). Los mtodos especficos usados por una compaa o agencia no impone restricciones especficas en la utilizacin del SW-CMM, debido a que sus prcticas se formulan de forma general para que pueda fcilmente adaptarse de manera de satisfacer las necesidades de ambientes particulares. Este modelo debe interpretarse de acuerdo al tamao de las compaas o agencias, pero es aplicable en el contexto global. Cualquier entidad que desarrolla o mantiene software, independientemente de su tamao se beneficiar mejorando su proceso de software aplicando el CMM. Uno de los mtodos de evaluacin basados en el modelo CMM para el mejoramiento interno de procesos, generalmente conocido como CBA-IPI ("CMM -Based Appraisal for Internal Process Improvement"): su principal objetivo es permitir a la empresa la determinacin de sus puntos fuertes y necesidades de mejoramiento, tambin permite revisar las prcticas de los proveedores externos, a objeto de que puedan derivar un plan de mejoramiento adecuado a su organizacin 1. Nivel 1: Nivel Inicial Nivel de Inmadurez Es el estado inicial de las empresas que desarrollan software. En este nivel se encuentran todas las empresas que no han logrado implementar las prcticas bsicas de gestin de proyectos e ingeniera de software definidas a partir del nivel 2 o superiores. Una empresa est en el nivel catico cuando sus gerentes y personal afirmen que los proyectos no se pueden planear, que los requerimientos no se pueden tener bajo control, que no est siempre en condiciones de controlar las versiones de producto, donde la calidad sea percibida como una burocracia innecesaria, cuando se acepte que los procesos son una cosa personal, cuando no se pueda verificar ni validar el producto, y sobre todo, cuando sus gerentes y personal vivan bajo condiciones de stress y frustracin permanentes.

La gerencia ocupa una parte significativa de su tiempo en paliar problemas y enfrentar clientes insatisfechos. Ante una situacin de crisis permanente, se les hace difcil destinar recursos para definir o documentar procesos, lo que lleva a un crculo sin salida. Cuando el proyecto se termina, la inversin hecha en desarrollar el proceso es raramente reutilizada en nuevos proyectos. Los desarrolladores de software generalmente tienen que trabajar largas horas y paliar problemas en forma cotidiana, lo cual les disminuye su creatividad y productividad netas. 2. Nivel 2: Nivel Repetible El proyecto planificado El nivel 2 o Repetible hace posible la implementacin de prcticas mnimas de administracin de proyecto, de control de requerimientos, versiones de producto y de proyectos realizados por subcontratistas. El grupo o equipo humano que realiz el proyecto puede aprovechar su experiencia e inversin en procesos para aplicarla en un nuevo proyecto. Este nivel no garantiza que todos los proyectos dentro de la empresa estn necesariamente al mismo nivel de madurez. Algunos pueden estar todava en el nivel inicial. Luciano Guerrero, en cuya pgina hemos basado gran parte del trabajo ha visto algunos casos en la prctica y en todos ellos estos proyectos fueron ineficientes con respecto a los de mayor madurez, malgastando el xito de estos ltimos. Eventualmente algunos invirtieron los esfuerzos necesarios para ponerse a tono, otros simplemente fueron cerrados con un elevado costo de frustracin y descalabro de carreras profesionales. Beneficios de implantar el Nivel 2 El mayor beneficio obtenido de la implementacin del nivel 2 por la empresa en la cual se encuentra actualmente, es la planificacin realista de los proyectos. Antes los cronogramas de proyecto expresaban ms los deseos de la gerencia que la realidad. Este principio (el mismo en la cual se basa la magia) conduca una situacin de buscar culpables y generar excusas, produciendo al mismo tiempo frustracin y desconfianza entre clientes y empleados actualmente en la empresa, los cronogramas son cada da ms confiables, y mejora a medida que se acumula ms informacin en las bases de datos de los proyectos pasados. El uso generalizado de mtodos de estimacin permite al personal del proyecto de justificar plazos y recursos. An el "olfato profesional" y la experiencia personal juegan un papel importante en la generacin de planes de proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas como en el pasado. Los pasos siguientes Este nivel todava permite la proliferacin y definicin insuficiente de los procesos de ingeniera de software. Los proyectos comparten principalmente sus experiencias en materia de administracin de proyectos, pero sus mtodos tcnicos pueden diferir. An

existe incomunicacin entre proyectos, grupos y entre personal y gerencia. Este nivel identifica prcticas de sentido comn que son aplicables en todo tipo de organizaciones de desarrollo de software, independientemente de su rubro, tamao o ambiente de desarrollo. La ausencia de cualquiera de sus prcticas simplemente pone en peligro elxito de la empresa. KPAs del Nivel 2 Gestin de Requisitos Planificacin del proyecto de software Seguimiento y Supervisin del proyecto Gestin de subcontratos de software Garanta de calidad de software Gestin de configuracin del software 3. Nivel 3: El proceso definido El proceso generalizado en todos los proyectos. La empresa ha definido un conjunto de procesos, metodologas y La empresa ha definido un conjunto de procesos, metodologas y herramientas comunes a todos los proyectos iniciados por la herramientas comunes a todos los proyectos iniciados por la corporacin. El proceso comn est suficientemente documentado en una biblioteca accesible a todos los desarrolladores. Todo el personal ha recibido el entrenamiento necesario para entender el proceso estndar. Existen pautas y criterios definidos para adaptar dicho proceso a las necesidades y caractersticas propias de cada proyecto. El nivel de definicin es detallado y completo. La dependencia (o el riesgo de depender) en individuos irreemplazables es baja. Beneficios de implantar el Nivel 3 del CMM La base de datos que rene estadsticas de los proyectos pasados en curso, permite planificar y comparar el rendimiento. Existen mecanismos de comunicacin entre proyectos y departamentos, lo que garantiza una visin comn del producto y una rpida accin para enfrentar los problemas. Segn el autor, ha conocido unas pocas empresas a este nivel y la cosa que ms le llamo la atencin, fue la satisfaccin del personal. En empresas de nivel 1 habitualmente se escuchan quejas y acusaciones. A nivel 3 los empleados tienen una alta valoracin de los procesos y entienden claramente la manera en que afecta su desempeo habitual. Los gerentes pueden realizar su verdadera

funcin, administrar. El hecho de realizar revisiones tempranas en forma regular mejora visiblemente la calidad de los productos y minimiza las reiteraciones innecesarias. Curiosamente muchas organizaciones de nivel 1 realizan revisiones de pares, pero lo hacen de manera inconsistente y al primer signo de pnico las suspenden. Los pasos siguientes El nivel 3 ya es un estado avanzado y es percibido por algunos gerentes como un lujo. Si no todas, al menos unas cuantas de sus reas claves de procesos deben ser implementadas. KPAs del Nivel 3 Enfoque en el proceso de la organizacin Definicin del proceso de la organizacin Programa de entrenamiento Gestin integrada del software Ingeniera de software del producto Coordinacin entre grupos Revisin de pares 4. Nivel 4: El proceso gestionado La calidad planificada y confiable En este nivel la corporacin mide la calidad del producto y del proceso de software. Ambos, producto y proceso, son seguidos en forma cuantitativa y se controlan mediante mtricas detalladas. La capacidadde rendimiento del proceso es previsible. Las mediciones permitendetectar cuando las variaciones del rendimiento se salen de los rangos aceptables, de manera que se puedan tomar medidas correctivas para asegurar la calidad. Beneficios de implantar el Nivel 4 del CMM La empresa es capaz de proponerse metas cuantitativas para la calidad de los productos y de los procesos de software. Es posible medir la productividad y calidad de los procesos de software a travs de todo el proyecto. Los proyectos pueden controlar la variacin del rendimiento de sus productos y procesos para mantenerla dentro de fronteras cuantitativas aceptables. Es posible discriminar las

variaciones significativas en el rendimiento del proceso de la variacin (ruido) al azar, particularmente dentro de lneas de productos establecidas. Es necesario aclarar que el hecho de contar con un sistema de mtricas de software no significa que se est en el nivel 4. Es una virtual seal de alarma que les dice lo graves que son sus problemas, pero la inmadurez de sus procesos no les permite hacer nada efectivo, excepto tal vez abortar el producto para evitar un dao mayor que puede resultar de distribuirlo a los clientes. Los pasos siguientes Son muy raras las empresas que han decidido implementar este nivel.Son muy raras las em presas que han decidido implementar este nivel. No son muchos los especialistas de procesos que realmente tengan experiencia prctica, o incluso que entiendan bien las reas claves de experiencia prctica, o incluso que entiendan bien las reas claves de proceso del nivel 4. Son solamente 2 prcticas, pero imposibles de proceso del nivel 4. Son solamente 2 prcticas, pero imposibles de alcanzar si no se ha implementado firmemente los 2 niveles de alcanzar si no se ha implementado firmemente los 2 niveles de madurez anteriores. Madureces anteriores. KPAs del Nivel 4 Gestin cuantitativa del proceso Gestin de la calidad del software 5. Nivel 5: El mejoramiento permanente La calidad planificada y confiable En el Nivel Optimizado, la caracterstica principal es el continuo del proceso, en base a la realimentacin cuantitativa y alensayo y tecnologas innovadoras. Beneficios de implantar el Nivel 5 del CMM La organizacin entera se aboca al mejoramiento continuo del proceso. La corporacin cuenta con los medios para identificar las debilidades y reforzar el proceso, con objeto de prevenir la ocurrencia de defectos. Los datos relativos a la eficacia del proceso de software se usan paraanalizar el coste y el beneficio de usar nuevas tecnologas y deimplementar cambios al proceso de software. Mejoramiento de ideas

Los proyectos de software analizan los defectos para determinar sus causas. Los proceso de software se evalan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos. Los pasos siguientes No existen ms de 10 empresas en el mundo que estn a este nivel (no hay ninguna en pases hispano-hablantes). Y las pocas que lo han logrado no divulgan sus secretos para mantener su ventaja competitiva. Este nivel es un estado ideal, que probablemente nunca ser alcanzadopor la mayora de las empresas productoras de software. Luciano Guerrero opina que es una hermosa utopa, pero inalcanzable en el mundo normal.

KPAs del Nivel 5 Prevencin de defectos Gestin del cambio de tecnologa Gestin del cambio del proceso La familia CMM Hay toda una familia de modelos de madurez (CMMs), aplicables a otros dominios relacionados con el software. SW-CMM: El modelo CMM lo aplicamos especficamente al mbito del software. SE- CMM: que significa Systems Engineering, el cual cubre el mbito de la Ingeniera de Sistemas. P-CMMP-CMM: que significa Personal CMM, el cual cubre la administracin de que significa Personal CMM, el cual cubre la administracin de personal. SA-CMM: que significa Software Acquisition, el cual cubre las prcticas de la adquisicin de productos de software. IPD-CMM: que significa Integrated Product Development, el cual cubre el desarrollo de la integracin del producto. A continuacin pasamos a detallar los cinco niveles de madurez de que consta CMM

Sesin 2 Proyecto de Mejoramiento de Calidad de Software Como planificar mejoramientos de calidad de software

Definicin segn San Pressman

La calidad del software se define como concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los standares de desarrollo explcitamente documentados, y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. Implicaciones:

La concordancia con los requisitos es la base para medir la calidad. Los standares definidos desarrollan criterios y guian el proceso de ingeniera de software. Hay un conjunto de requerimientos implcitos que deben cumplirse.

Como seleccionar la medida de calidad apropiada para medir el nivel de mejora

Sistemas de inspeccin La inspeccin en lo referente a la calidad consiste en examinar y medir las caractersticas de calidad de un producto, as como sus componentes y materiales de que est elaborado, o de un servicio o proceso determinado, todo ello utilizando instrumentos de medicin, patrones de comparacin o equipos de pruebas y ensayos, para ver si cumple o no los requisitos especificados. Por tanto, los sistemas de inspeccin sirven para confirmar que el sistema de calidad funciona segn lo previsto. Normalmente se hace por muestreo y solo se usa el control 100% para caractersticas importantes de seguridad, funcionalidad o normas. Otra definicin de inspeccin segn la normativa ISO 8402/94 sera, las actividades tales como la medicin, examen, el ensayo o la constatacin con un patrn de una o ms caractersticas de una entidad y la comparacin de los resultados son los requisitos especificados para establecer si se ha logrado conformidad en cada caracterstica. Tipos de inspeccin En una primera clasificacin, los tipos de inspeccin podran diferenciarse entre la inspeccin 100% y la inspeccin por muestreo. Inspeccin 100% El proceso de inspeccin 100% es aquel proceso que consiste en verificar todas las unidades de un lote.

Una inspeccin al 100% permite aceptar solo piezas de la calidad especificada, pero cuando la inspeccin al 100% es realizada manualmente, se presentan 2 tipos de problemas, uno sera, el gasto involucrado y el otro, la precisin de la inspeccin, considerados como errores tipo I y tipo II. Inspeccin por muestreo Por el contrario, los sistemas de inspeccin por muestreo, tambin conocidos como muestreo de aceptacin o muestreo de lotes, es un procedimiento en el que se verifica una o ms muestras del lote para determinar su calidad. El muestreo es usado para reducir la necesidad de inspeccionar cada artculo o producto, y reducir as el tiempo y gastos de inspeccin. La inspeccin por muestreo tiene cierto nmero de ventajas sobre la inspeccin 100%. La fatiga de los inspectores originada por operaciones repetitivas puede ser un obstculo serio para una buena inspeccin 100%, es ms econmica y requiere de menor tiempo para su realizacin. Es por ello que se llevaron a cabo investigaciones en el campo de las teoras de las probabilidades y la estadstica, llegndose a la conclusin de que para tomar decisiones sobre la calidad de la produccin en proceso y terminada, no hay necesidad de efectuar una inspeccin 100% sobre todos los artculos, sino que basta con inspeccionar slo una parte del lote, o sea, una muestra, mediante una inspeccin por muestreo. Algunos de los factores por considerar en la inspeccin por muestreo sern el nivel de confianza en los proveedores, el costo en que se incurre al aceptar productos defectuosos, y el riesgo del muestreo, que siempre existir por la naturaleza estadstica del proceso. En general, existen dos tipos de errores con probabilidad de ocurrir, el primero es llamado error tipo I, y ocurre cuando rechazamos un lote que cumple con las especificaciones de calidad y el segundo es llamado error tipo II, y ocurre cuando aceptamos un lote que no cumple con las especificaciones de calidad.

Dentro de la inspeccin por muestreo de la calidad, se distinguen principalmente dos tipos de inspeccin para controlar los procesos productivos. Estos procesos son los llamados Inspeccin por Atributos e Inspeccin por Variables. Inspeccin por atributos La inspeccin por atributos se puede considerar aquel tipo de inspeccin de muestras aleatorias de n unidades en el que cada artculo o producto es clasificado de acuerdo con ciertos atributos como aceptable o defectuosa, es decir, consiste en averiguar si el material en consideracin cumple o no cumple con lo especificado, sin interesar la medida de la caracterstica.

Para la inspeccin por atributos el tamao de las muestras y el intervalo entre las mismas debe ser tal que se inspeccione aproximadamente un 5 % de la produccin. En procesos muy masivos que no presentan dificultades frecuentes o el porcentaje de produccin defectuosa no es grave, este porcentaje se puede reducir a menos de un 5 % donde se recomienda que debe existir como mnimo 25 defectuosos en cada muestra para lograr establecer un comportamiento adecuado del proceso. Inspeccin por variables La inspeccin por variables se trata de un tipo de inspeccin que consiste en medir y registrar una unidad de medida en la que una caracterstica especfica de calidad es medida con una escala continua para posteriormente ser anotada, como podra ser kilogramos, centmetros, metros por segundo, etc Los mtodos estadsticos aplicables a la inspeccin por variables se basan sobre el supuesto de una distribucin normal y no sobre una distribucin de proporciones como sucede con la inspeccin por atributos. Para los mtodos aplicables, y con las mediciones obtenidas, se calcular un estadstico, que generalmente estar en funcin de la media y la desviacin estndar muestral, y dependiendo del valor de este estadstico al compararlo con un valor permisible, se aceptar o rechazar todo el lote. Las ventajas que tiene este mtodo con respecto al mtodo de inspeccin por atributos seran que se puede obtener la curva caracterstica de operacin con un tamao muestral menor que lo requerido por un plan de muestreo por atributos, adems, cuando se utilizan pruebas destructivas, el muestreo por variables es particularmente til para reducir los costos de inspeccin. Por otra parte, los datos de mediciones proporcionan normalmente ms informacin sobre el lote que los datos de atributos. Por el contrario, se debe de conocer la distribucin de la caracterstica de calidad, se debe de usar un plan para cada caracterstica de calidad que hay que inspeccionar y es posible que el uso de un plan de muestreo por variable lleve al rechazo de un lote aunque la muestra que se inspecciona realmente no tenga ningn artculo defectuoso. En el caso de la inspeccin del proceso por variables los tamaos muestra ms empleados son entre 1 y 25 unidades. Las muestras de 2 o 3 unidades son poco empleadas por su baja sensibilidad, emplendose slo cuando el costo de las mediciones es muy alto. Por tanto cuanto queramos una mayor sensibilidad en el grfico, los tamaos de muestras debern ser mayores. Ejemplos de inspeccin por muestreo
INSPECCION POR VARIABLES INSPECCION POR ATRIBUTOS

Medicin de la longitud de una determinada Medir una pieza cilndrica mediante calibres pasa/no pasa pieza. para determinar si se encuentra dentro de las tolerancias. Medicin de la temperatura de un horno de Determinar la tasa de fraccin de defectos de una muestra de un horno de coccin. partes de produccin. Medicin de la resistencia elctrica de un Contar el nmero de defectos por automvil conforme este determinado componente electrnico. deja la planta de ensamble final Medicin del tiempo que puede aguantar un Contar el nmero de faltas de los empleados por turno en una material al fuego. empresa.

Procedimiento de inspeccin Las operaciones a ejecutar en el proceso de inspeccin seran: 1. Interpretacin de la especificacin requerida. 2. Muestreo de los lotes. 3. Medicin de la caracterstica de calidad. 4. Comparacin de lo interpretado con lo medido. 5. Enjuiciamiento de la conformidad. 6. Registro de los datos obtenidos. Para el registro de los datos, se implantarn un conjunto de modelos especficos en correspondencia con el fin que tenga la inspeccin, es decir, si el fin es preventivo se establecern grficos de control y si el fin es de aceptacin se establecer el modelo en correspondencia al plan de muestreo a utilizar. Tipos de errores cometidos Los tipos de errores que podemos cometer durante una inspeccin de calidad de un proceso son: - error tipo I: es el error que hacemos cuando rechazamos un producto siendo este correcto, cumpliendo con todos los parmetros que hemos definido como de buena calidad. - error tipo II: se trata del error que cometemos cuando damos como bueno una muestra que en realidad no se encuentra dentro de los parmetros que hemos definido como vlidos, dicha muestra an teniendo defectos no deseados es admitida.

As pues estos errores nos llevan a equivocar la clasificacin de los productos derivados del proceso y conllevan consecuencias no deseables en el control de calidad de una empresa. Como definir los datos requeridos Como planificar la recoleccin de datos

En ingeniera del software y el desarrollo de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Los requerimientos son declaraciones que identifican atributos, capacidades, caractersticas y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qu elementos y funciones son necesarias para un proyecto. En el modelo clsico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseo del sistema/software. Etapas de la fase de requerimientos * Obtencin de requerimientos: bsqueda y obtencin de los requerimientos desde los grupos de inters. * Anlisis: comprobacin de la consistencia y completitud de los requerimientos. * Verificacin: constatacin de que los requerimientos especificados son correctos. Clasificacin de los requerimientos * Requerimientos funcionales: qu debe hacer el sistema o software. * Requerimientos no funcionales: cmo debe funcionar el sistema o software (no su implementacin), por ej. calidad, rendimiento, facilidad de uso, etc. * Requerimientos externos: a qu se debe atener el sistema o software con respecto a su entorno: compatibilidad con otros sistemas, adecuacin a determinadas leyes, etc. Caractersticas que deberan cumplir los requerimientos * Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo. * Cohesin: el requerimiento debe dirigirse a solo una nica cosa. * Completo: el requerimiento debe estar completamente declarado en un nico lugar, sin informacin faltante. * Consistente: el requerimiento no debe contradecir ningn otro requerimiento y debe ser completamente consistente con toda la documentacin.

* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software. * Factible/viable: el requerimiento debe poder ser implementado. * No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder poder ser interpretado de una nica manera. * Obligatorio: el requerimiento debe representar una caracterstica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada. * Observable externamente: el requerimiento debe especificar una caracterstica observable externa o experimentable por el usuario del producto. * Verificable/demostrable: La implementacin del requerimiento debe poder ser resuelta en alguno de estos cuatro mtodos: inspeccin, anlisis, demostracin o prueba. Sesin 3 Proyecto de Definicin de Requerimientos Como se entrevista a cliente para definir requerimientos de un sistema

Tcnicas principales La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio. Entrevistas Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del

negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin. Forma de contrato En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos stos pueden tener centenares de pginas. Objetivos medibles Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construccin, para evaluar en cualquier momento qu tan avanzado se encuentra el proyecto. Prototipos Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Casos de uso Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseo final. Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al comenzar otra vez. Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin embargo, no proporcionan explcitamente cules son los requisitos.

Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseo grfico, se realizan en una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin. Descripcin de las tcnicas ms utilizadas en la ingeniera de requerimientos. En esta seccin se van a describir en detalle algunas de las tcnicas ms usadas en la IR. Cada tcnica puede aplicarse en una o ms actividades de esta ingeniera; en la prctica, la tcnica ms apropiada para cada actividad depender del proyecto que est desarrollndose. Entrevistas y cuestionarios Dentro de una organizacin, la entrevista es la tcnica ms significativa y productiva de que dispone el analista para recolectar datos. En otras palabras, la entrevista es un intercambio de informacin que se efecta cara a cara. Es un canal de comunicacin entre el analista y la organizacin; sirve para obtener informacin acerca de las necesidades y la manera de satisfacerlas, as como consejo y comprensin por parte del usuario para toda idea o mtodo nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpata con el personal usuario, lo cual es fundamental en transcurso del estudio. A. Preparacin de la Entrevista .Determinar la posicin en la organizacin del futuro entrevistado, responsabilidades, actividades, y otros (Investigacin). Preparar las preguntas que van a plantearse, y los documentos necesarios (Organizacin). Fijar un lmite de tiempo y preparar la agenda para la entrevista. (Psicologa). Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Psicologa). Hacer la cita con la debida anticipacin (Planeacin). B. Conduccin de la Entrevista Explicar con toda amplitud el propsito y alcance del estudio (Honestidad). Explicar la funcin propietaria como analista y la funcin que se espera conferir al entrevistado. (Imparcialidad).Hacer preguntas especficas para obtener respuestas cuantitativas (Hechos). Evitar laspreguntas que exijan opiniones interesadas, subjetividad y actitudes si

milares (Habilidad).Evitar el cuchicheo y las frases carentes de sentido (Claridad). Ser corts, abstenindose deemitir juicios de valores. (Objetividad). Conservar el control de la entrevista, evitandodi vagaciones y los comentarios al margen de la cuestin (Habilidad). Escuchar atentamente lo que se dice, guardndose de anticiparse a las respuestas (Comunicacin). C. Secuela de la Entrevista. Escribir los resultados (Documentacin). Entregar una copia al entrevistado, solicitando su conformacin, correcciones o adiciones. (Profesionalismo). Archivar los resultados de la entrevista para referencia y anlisis posteriores (Documentacin). D. Recolectar datos mediante la Entrevista. La entrevista es una forma de conversacin, no de interrogacin, al analizar las caractersticas de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no estn disponibles en ningn otra forma. En las investigaciones de sistema, las formas cualitativas y cuantitativas de la informacin son importantes. La informacin cualitativa est relacionada con opinin, poltica y descripciones narrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan con nmeros frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente de informacin cualitativa, los otros mtodos tiende a ser ms tiles en la recoleccin de datos cuantitativos. Son valiosas las opiniones, comentarios, ideas o sugerencia en relacin a cmo se podra hacer el trabajo; la entrevista a veces es la mejor forma para conocer las actividades de las empresas. La entrevista puede descubrir rpidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las aplicaciones de desarrollo; ms an, a menudo es ms fcil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen un cuestionario. E. Determinacin del tipo de Entrevista. La estructura de la entrevista vara. Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de preguntas sin estructura, con una sesin de preguntas y respuestas libres. El formato de respuestas para las preguntas pueden ser abierto o cerrado; las preguntas abiertas permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Pueden contestar por completo con sus propias palabras. Los analistas tambin deben dividir el tiempo entre desarrollar preguntas para entrevistas y analizar respuestas. Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema.

Este tipo de preguntas son siempre apropiadas, adems que ayudan a entender la perspectiva del afectado y no estn influenciadas por el conocimiento de la solucin. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, y otros. El siguiente ejemplo muestra algunos tipos de preguntas abiertas Del Usuario

Quin es el cliente?Quin es el usuario?Son sus necesidades diferentes?Cules son sus habilidades, capacidades, ambiente? Del Proceso

Cul es la razn por la que se quiere resolver este problema?Cul es el valor de una solucin exitosa?Cmo usted resuelve el problema actualmente?Qu retrasos ocurren o pueden ocurrir? Del Producto

Qu problemas podra causar este producto en el negocio?En qu ambiente se usar el producto? Cules son sus expectativas para los conceptos fcil de usar, confiable,rendimiento? Qu obstculos afectan la eficiencia del sistema El xito de esta tcnica combinada, depende de la habilidad del entrevistador y de suprepa racin para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cmo tratar con problemas potenciales. Asimismo, necesitan considerar no slo la informacin que adquieren a travs del cuestionario y la entrevista, sino tambin, su significancia. F. Ejemplos de las preguntas abiertas y cerradas en la entrevista estructurada Forma de pregunta

Ejemplo: obtener la informacin sobre las caractersticas de diseo crticas para los empleados. "Algunos empleados han sugerido que la mejor forma para hacer eficiente el procesamiento de pedidos es instalar un sistema de computadora que maneje todos los clculos..." Bajo estas circunstancias apoyara usted el desarrollo de un sistema de este tipo? Forma de pregunta cerrada

Ejemplo: obtener la informacin sobre lascaractersticas de diseo crticas para losemplea dos." La experiencia le ha proporcionado una amplia visin en cuanto a la forma en la que la empresa maneja los pedidos..." Me gustara que usted contestara algunas preguntas especficas en relacin en lo anterior: -Qu etapas trabajan bien? Cules no? -En donde se presenta la mayor parte del problema?- Cundo ocurre un atraso, cmo se maneja? Cuestionario Los cuestionarios proporcionan una alternativa muy til para la entrevista; si embargo, existen ciertas caractersticas que pueden ser apropiada en algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben disearse cuidadosamente para una mxima efectividad. Recabacin de datos mediante cuestionarios Para los analistas los cuestionarios pueden ser la nica forma posible de relacionarse con un gran nmero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamento, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos en relacin al sistema. En mayor parte de los casos, el analista no ver a los que responde; no obstante, tambin esto es una ventaja porque aplican muchas entrevista ayuda a asegurar que el interpelado cuenta con mayor anonimato y puedan darse respuestas mas honesta ( y menos respuestas prehechas o estereotipadas). Tambin las preguntas estandarizadas pueden proporcionar datos ms confiable. Seleccin de formas para cuestionarios El desarrollo y distribucin de los cuestionarios; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. Tambin es importante el formato y contenido de las preguntas en la recopilacin de hechos significativos. Existen dos formas de cuestionarios para recabar datos: cuestionarios abiertos y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlas. Con frecuencia se utilizan ambas formas en los estudios de sistemas. Cuestionario Abierto

Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; tambin son tiles al explorar el problema bsico, por ejemplo, un analista que utiliza cuestionarios para estudiar los mtodos de verificacin de crdito, es un medio. El formato abierto proporciona una amplia oportunidad para quienes respondan escriba las razones de sus ideas. Algunas personas sin embargo, encuentran ms fcil escoger una de un conjunto de respuestas preparadas que pensar por s mismas. Cuestionario Cerrado El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mtodo para obtener informacin sobre los hechos. Tambin fuerza a los individuos para que tomen una posicin y forma su opinin sobre los aspectos importantes.

Como se documenta los requerimientos de sistema

En un Sistema de Gestin de Calidad los procesos se deben documentar, para que estos ayuden todos los das a visualizar lo que se hace y no perder de vista las necesidades que demandan en cada uno. Para cada proceso se debe determinar: Las entradas Los procesos Las salidas La secuencia y Los recursos

La norma ISO 9001:2000 Establece que se deben identificar, documentar, implantar y mantener los procesos necesarios para asegurar la conformidad de los productos y servicios con base en los requerimientos y necesidades de los clientes. Requisitos de la documentacin Desarrollar la documentacin del Sistema de gestin de calidad, que incluya: Declaraciones documentadas de una poltica de calidad y de objetivos de calidad.

Generalidades:

Un manual de calidad que establezca los requisitos del sistema. Procedimientos que definan la manera de implantar el sistema. Procedimientos de las actividades de la operacin. Desarrollar el manual de calidad de forma que quede establecido: El alcance del sistema de gestin de la calidad, incluyendo los detalles y la justificacin de cualquier exclusin. Los procedimientos documentados establecidos o referencia a ellos. La secuencia o interaccin de los procesos.

Control de la documentacin Establecer un mtodo para controlar los documentos del sistema de gestin de la calidad que defina los medios para: Determinar los niveles de firmas para la elaboracin, revisin y aprobacin de los documentos de calidad, segn aplique. Aprobar los documentos antes de su emisin. Revisar y actualizar los documentos cuando sea necesario. Elaborar listas maestras de documentos que identifiquen el estado de revisin. Tener accesibilidad a los documentos en los puntos de uso y que estos conserven su legibilidad y actualizacin. Evitar el uso no intencionado de documentos obsoletos. Controlar la distribucin de los documentos controlados.

Como se planifica la calidad requerida de un sistema desde un principio

La administracin de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos. La planeacin comienza al mismo tiempo que la obtencin inicial de requerimientos. La administracin activa debe iniciar tan pronto est lista la primera versin del documento de requerimientos. Caractersticas de los requerimientos Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no

pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
o

Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.

La ingeniera de requerimientos es un proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema. Comprende cuatro actividades de alto nivel: 1. Estudio de factibilidad 2. Obtencin y anlisis de requerimientos 3. Validacin de requerimientos 4. Administracin de requerimiento principales causas para el fracaso de un proyecto de software es la mala (o ausencia de) administracin de requerimientos. Los principales problemas de un mal manejo de requerimientos son:

Incapacidad para manejar los cambios en los requerimientos durante el desarrollo. Falta de especificacin detallada de los requerimientos. Mala organizacin y control de requerimientos. Requerimientos mal entendidos.

La administracin de requerimientos comprende las actividades relacionadas con la definicin, clasificacin, asignacin, seguimiento y control de los requerimientos durante todo el ciclo de vida de desarrollo de software. Es una metodologa indispensable para el aseguramiento de la calidad de los productos, as como para el control y seguimiento de los proyectos.

Impacto de los errores en la etapa de los requerimientos.

El software resultante puede no satisfacer a los usuarios. Las interpretaciones mltiples de los requerimientos pueden causar desacuerdos entre clientes y desarrolladores. Es imposible que a travs del testeo el software satisfaga sus requerimientos. Puede gastarse tiempo y dinero construyendo el sistema errneo.

Sesin 4 Proyecto de Plan de Aseguramiento de Calidad (SQA) Que es un plan de evaluacin de calidad de software

Aseguramiento de la calidad (SQA) El objetivo del aseguramiento de la calidad es proporcionar a la administracin los datos necesarios para tener la certeza de que el producto se est haciendo con calidad. Las actividades que realiza un grupo de SQA son:

Establecimiento de un plan SQA para el proyecto. El plan debe establecer:

o o o o o

Evaluaciones, auditoras y revisiones a realizar. Standares que se pueden aplican al proyecto. Procedimientos para informacin y seguimiento de errores. Documentos producidos por el grupo SQA. Retroalimentacin proporcionada al equipo de desarrollo.

Participacin en el desarrollo de la descripcin del proyecto de software.

Revisin de las actividades de ingeniera para verificar su cumplimiento con el proceso. Auditora del producto para verificar su concordancia con los requisitos. Asegurar que las desviaciones estn bien documentadas

Revisiones de software

Revisiones por un colega. Mejoran la calidad. Detecta errores de diseo o codificacin. Se hacen despus del anlisis, despus del diseo, durante la compilacin y durante las pruebas.

Revisiones tcnicas formales (RTF) Objetivos

Descubrir errores de funcionamiento, lgica o de implementacin. Verificar que el software cumpla con los requisitos. Garantizar que se cumplen los standares establecidos. Conseguir un desarrollo uniforme. Lograr que los proyectos sean manejables.

Caractersticas

Revisar el producto no al productor. Fijar una agenda y mantenerla. Limitar el debate y las impugnaciones. Enunciar los problemas no resolverlos en ese momento. Tomar notas escritas. Limitar el nmero de participantes (de 3 a 5). Revisar el material antes. Limitar la duracin de la junta (menos de 2 horas).

Desarrollar una lista de comprobacin por cada producto. Planear de antemano las RTF. Repasar las revisiones anteriores.

Enfoques formales de SQA

Verificacin formal de programas. Aseguramiento de calidad estadstica. Proceso de sala limpia (clean room), combina las 2 anteriores.

Medidas de fiabilidad y disponibilidad TMDF. Tiempo medio de fallas. TMDR. Tiempo medio de reparacin. TMEF. Tiempo medio entre fallas Medida de fiabilidad TMEF = TMDF + TMDR Medida de disponibilidad A = TMDF / (TMDF + TMDR) * 100 = TMDF / TMEF * 100

Cules son los componentes de un plan de evaluacin de calidad de software

Propsito [Esta seccin debe contener el propsito y alcance del Plan de Calidad. Se debe especificar el uso que se le dar al software que se est desarrollando y se deben listar los elementos del software que sern cubiertos por el Plan. Adems se debe especificar la porcin del ciclo de vida del software que ser cubierta por el Plan. (Ej.: Este Plan solo cubre la parte del ciclo de vida correspondiente al desarrollo del software pero no cubre la parte del ciclo de vida correspondiente al mantenimiento.)] Referencias ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance Plans.

Gestin [Se debe especificar la organizacin, actividades y responsables.] Organizacin [Distinguir las lneas de trabajo dentro de la organizacin que tienen influencia y controlan la calidad del software. Descripcin de cmo est organizado el equipo de trabajo y de las dependencias o independencias de las lneas de trabajo antes mencionadas.] Actividades Ciclo de vida del software cubierto por el Plan [Esta seccin debe contener las etapas ms importantes del ciclo de vida del software que cubre el Plan. (Ej.: Etapa de Requerimientos y anlisis) Adems debe contener una lista con todos los productos de proyecto que tendrn revisiones de calidad.] Actividades de calidad a realizarse Las tareas a ser llevadas a cabo debern reflejar las evaluaciones a realizar, los estndares a seguir, los productos a revisar, los procedimientos a seguir en la elaboracin de los distintos productos y los procedimientos para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su correccin. Las actividades que se realizarn son: Revisar cada producto Revisar el ajuste al proceso Realizar Revisin Tcnica Formal (RTF) Asegurar que las desviaciones son documentadas.

Revisar cada producto En esta actividad se revisan los productos que se definieron como claves para verificar en el Plan de calidad. Se debe verificar que no queden correcciones sin resolver en los informes de revisin previos, si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisin. Se

revisan los productos contra los estndares, utilizando la checklist definida para el producto. Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que se hayan realizado las correcciones. Como salida se obtiene el Informe de revisin de SQA, este informe debe ser distribuido a los responsables del producto y se debe asegurar de que son concientes de desviaciones o discrepancias encontradas. Revisar el ajuste al proceso En esta actividad se revisan los productos que se definieron como claves para verificar el cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en el producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos durante todo el ciclo de vida del software. Se debe recoger la informacin necesaria de cada producto, buscando hacia atrs los productos previos que deberan haberse generado, para poder establecer los criterios de revisin y evaluar si el producto cumple con las especificaciones. Esta informacin se obtiene de los siguientes documentos: Plan del Proyecto, Plan de la iteracin, Plan de Verificacin. Antes de comenzar, se debe verificar en los informes de revisin previos que todas las desviaciones fueron corregidas, si no es as, las faltantes se incluyen para ser evaluadas. Como salida se obtiene el Informe de revisin de SQA correspondiente a la evaluacin de ajuste al Proceso, este informe debe ser distribuido a los responsables de las actividades y se debe asegurar de que son consientes de desviaciones o discrepancias encontradas. Realizar Revisin Tcnica Formal (RTF) El objetivo de la RTF es descubrir errores en la funcin, la lgica la implementacin de cualquier producto del software, verificar que satisface sus especificaciones, que se ajusta a los estndares establecidos, sealando las posibles desviaciones detectadas. Es un proceso de revisin riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Por esta caracterstica se adopta esta prctica para productos que son de especial importancia. En la reunin participan el responsable de SQA e integrantes del equipo de desarrollo.

Se debe convocar a la reunin formalmente a los involucrados, informar del material que ellos deben preparar por adelantado, llevar una lista de preguntas y dudas que surgen del estudio del producto a ser revisado. La duracin de la reunin no debe ser mayor a dos horas. Como salida se obtiene el Informe de RTF. Asegurar que las desviaciones son documentadas Las desviaciones encontradas en las actividades y en los productos deben ser documentadas y ser manejadas de acuerdo a un procedimiento establecido. Se debe chequear que los responsables de cada plan los modifiquen cada vez que sea necesario, basados en las desviaciones encontradas. Relaciones entre las actividades de SQA y la planificacin [En esta seccin se incluye una lista con las actividades de calidad a realizarse durante el proyecto, especificando en que semana del proyecto se realizan.]

Actividad

Semana cuando se realiza [Semana] [Semana 6]

Actividad 1 [RTF de Estimaciones y Mediciones] Responsables

[Identificar los distintos responsables de cada actividad identificada.] Documentacin Propsito Identificacin de la documentacin relativa a desarrollo, Verificacin & Validacin, uso y mantenimiento del software. Establecer como los documentos van a ser revisados para chequear consistencia: se confirman criterio e identificacin de las revisiones. Documentacin mnima requerida

La documentacin mnima es la requerida para asegurar que la implementacin lograr satisfacer los requerimientos. Especificacin de requerimientos del software El documento de especificacin de requerimientos deber describir, de forma clara y precisa, cada uno de los requerimientos esenciales del software adems de las interfaces externas. El cliente deber obtener como resultado del proyecto una especificacin adecuada a sus necesidades en el rea de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se haya acordado detallar con el cliente. La especificacin debe: Ser completa :

a. Externa, respecto al alcance acordado. b. Internamente, no deben existir elementos sin especificar. Ser consistente, no pueden haber elementos contradictorios. Ser no ambigua, todo trmino referido al rea de aplicacin debe estar definido en un glosario. Ser verificable, debe ser posible verificar siguiendo un mtodo definido, si el producto final cumple o no con cada requerimiento. Estar acompaada de un detalle de los procedimientos adecuados para verificar si el producto cumple o no con los requerimientos. Incluir requerimientos de calidad del producto a construir.

Los requerimientos de calidad del producto a construir son considerados dentro de atributos especficos del software que tienen incidencia sobre la calidad en el uso y se detallan a continuacin: Funcionalidad a. adecuacin a las necesidades b. precisin de los resultados c. interoperabilidad

d. seguridad de los datos Confiabilidad a. madurez b. tolerancia a faltas c. recuperabilidad (Ver si aplica) Usabilidad a. comprensible b. aprendible c. operable d. atractivo Eficiencia a. comportamiento respecto al tiempo (Ver si aplica) b. utilizacin de recursos Mantenibilidad a. analizable b. modificable c. estable, no se producen efectos inesperados luego de modificaciones d. verificable Portabilidad a. adaptable (Ver si aplica) b. instalable c. co-existencia d. reemplazante (Ver si aplica) Cada uno de estos atributos debe cumplir con las normas y regulaciones aplicables a cada uno.

Descripcin del diseo del software El documento de diseo especifica como el software ser construido para satisfacer los requerimientos. Deber describir los componentes y subcomponentes del diseo del software, incluyendo interfaces internas. Este documento deber ser elaborado primero como Preliminar y luego ser gradualmente extendido hasta llegar a obtener el Detallado.

El cliente deber obtener como resultado del proyecto el diseo de un producto de software que cubra aquellos aspectos que se haya acordado con el cliente incorporar al diseo, en funcin de la importancia que estos presenten y de sus conexiones lgicas. El diseo debe: Corresponder a los requerimientos a incorporar:

a. Todo elemento del diseo debe contribuir a algn requerimiento b. La implementacin de todo requerimiento a incorporar debe estar contemplada en por lo menos un elemento del diseo. Ser consistente con la calidad del producto

Plan de Verificacin & Validacin El Plan de V & V deber identificar y describir los mtodos a ser utilizados en: La verificacin de que:

a. los requerimientos descritos en el documento de requerimientos han sido aprobados por una autoridad apropiada. En este caso sera que cumplan con el acuerdo logrado entre el cliente y el equipo. b. los requerimientos descritos en el documento de requerimientos son implementados en el diseo expresado en el documento de diseo. c. el diseo expresado en el documento de diseo esta implementado en cdigo. Validar que el cdigo, cuando es ejecutado, se adecua a los requerimientos expresados en el documento de requerimientos.

Reportes de Verificacin & Validacin

Estos documentos deben especificar los resultados de la ejecucin de los procesos descritos en el Plan de V & V. Documentacin de usuario La documentacin de usuario debe especificar y describir los datos y entradas de control requeridos, as como la secuencia de entradas, opciones, limitaciones de programa y otros elementos necesarios para la ejecucin exitosa del software. Todos los errores deben ser identificados y las acciones correctivas descritas. Como resultado del proyecto el cliente obtendr una documentacin para el usuario de acuerdo a los requerimientos especficos del proyecto. Plan de Gestin de configuracin El Plan de gestin de configuracin debe contener mtodos para identificar componentes de software, control e implementacin de cambios, y registro y reporte del estado de los cambios implementados. Otros documentos [Esta seccin puede contener otros documentos que se identifiquen de incidencia en la calidad del producto a desarrollar, por ejemplo:

Plan de desarrollo Plan de proyecto Manual de estndares y procedimientos Etc...]

Estndares, prcticas, convenciones y mtricas [Esta seccin deber cumplir con las siguientes funciones: Identificar los estndares, prcticas, convenciones y mtricas que sern aplicadas para la evaluacin de Calidad. Indicar como ser monitoreado y asegurado el cumplimiento con estos elementos.]

Estndar de documentacin Como estndares de documentacin se definirn dos documentos:

Estndar de documentacin tcnica y Estndar de documentacin de usuario.

La documentacin tcnica del producto debe: Ser adecuada para que un grupo independiente del de desarrollo pueda encarar el mantenimiento del producto. Incluir fuentes, Modelos de Casos de Uso, Objetos

Para la escritura de documentos se han definido plantillas para ser utilizadas en la elaboracin de entregables. En estas plantillas se definen: encabezado y pie de pgina. fuente y tamao de fuente para estilo normal fuente y tamao de fuente para los ttulos a utilizar datos mnimos que se deben incluir: fecha, versin y responsables.

[Esta seccin debe incluir todos los estndares de documentacin que se utilicen durante el desarrollo del proyecto.] Estndar de verificacin y prcticas Se utilizan las prcticas definidas en el Plan de Verificacin y Validacin. Como estndar se utiliza el documento de: Std 1012-1986 IEEE Standard for Software Verification and Validation Plans. [Esta seccin debe incluir todos los estndares de verificacin y prcticas que se utilicen durante el desarrollo del proyecto.] Otros Estndares [En esta seccin se debern definir otros estndares a utilizar.] Revisiones y auditoras Objetivo Definicin de las revisiones y auditoras tcnicas y de gestin que se realizarn.

Especificacin de cmo sern llevadas a cabo dichas revisiones y auditoras. Requerimientos mnimos [Se especifican las revisiones y auditoras que deben realizarse como mnimo, as como la agenda para la realizacin de las mismas.] Revisin de requerimientos Esta revisin se realiza para asegurar que se cumpli con los requerimientos especificados por el Cliente. Revisin de diseo preliminar Esta revisin se realiza para asegurar la consistencia y suficiencia tcnica del diseo preliminar del software. Revisin de diseo crtico Esta revisin se realiza para asegurar la consistencia del diseo detallado con la especificacin de requerimientos. Revisin del Plan de Verificacin & Validacin Esta revisin se realiza para asegurar la consistencia y completitud de los mtodos especificados en el Plan de V & V. Auditora funcional Esta auditora se realiza previa a la liberacin del software, para verificar que todos los requerimientos especificados en el documento de requerimientos fueron cumplidos. Auditora fsica Esta revisin se realiza para verificar que el software y la documentacin son consistentes y estn aptos para la liberacin. Auditoras internas al proceso Estas auditoras son para verificar la consistencia: del cdigo versus el documento de diseo, especificaciones de interfase, implementaciones de diseo versus requerimientos funcionales, requerimientos funcionales versus descripciones de testeo. Revisiones de gestin

Estas revisiones se realizan peridicamente para asegurar la ejecucin de todas las actividades identificadas en este Plan. Deben realizarse por una persona ajena al grupo de trabajo (en caso de que sea posible). Revisin del Plan de gestin de configuracin Esta revisin se realiza para asegurar la consistencia y completitud de los mtodos especificados en el Plan de gestin de configuracin. Revisin Post Mortem Esta revisin se realiza al concluir el proyecto para especificar las actividades de desarrollo implementadas durante el proyecto y para proveer recomendaciones. Agenda [En esta seccin se deber especificar la agenda para las revisiones y auditoras detalladas anteriormente.] Otras revisiones Revisin de documentacin de usuario Se revisa la completitud, claridad, correctitud y aplicacin de uso. Verificacin [Se debe identificar todas las verificaciones que no fueron identificadas en el Plan de V & V para el software y debe especificar los mtodos a ser usados.] Reporte de problemas y acciones correctivas [Esta seccin debe incluir: Descripcin de las prcticas y procedimientos que se seguirn para el reporte, seguimiento, y resolucin de los problemas surgidos en el desarrollo de software; especificar los responsables comprometidos con la implementacin de estas acciones correctivas.] Herramientas, tcnicas y metodologas [Se deben identificar herramientas de software, tcnicas, y metodologas de soporte para las actividades de aseguramiento de calidad.] Gestin de riesgos [Se deben especificar los mtodos y procedimientos utilizados para especificar, monitorear, y controlar las reas de riesgo durante el proyecto.

Los riesgos identificados, la estrategia de mitigacin, monitoreo y plan de contingencia a ser llevados a cabo, sern descritos en el Documento de Gestin de Riesgos, con lo cual se podr hacer referencia a l.]

Sesin 5 Medidas de la Satisfaccin del Cliente Diferentes mtodos de recolectar datos de una encuesta

Las encuestas proveen una fuente importante de conocimiento cientfico bsico. Economistas, siclogos, profesionales de la salud y socilogos llevan a cabo encuestas para estudiar materias tales como los patrones de ingreso y gastos en los hogares, las races del prejuicio tnico o racial, las implicaciones de los problemas de salud en la vida de las personas, comparando el comportamiento electoral y los efectos sobre la vida familiar de mujeres que trabajan fuera del hogar. Las encuestas pueden ser clasificadas en muchas maneras. Una dimensin es por tamao y tipo de muestra. Las encuestas pueden ser usadas para estudiar poblaciones humanas o no humanas (por ejemplo, objetos animados o inanimados, animales, terrenos, viviendas). Mientras que muchos de los principios son los mismos para todas las encuestas, el foco aqu ser en mtodos para hacer encuestas a individuos. Muchas encuestas estudian todas las personas que residen en un rea definida, pero otras pueden enfocar en grupos particulares de la poblacin -nios, mdicos, lderes de la comunidad, los desempleados, o usuarios de un producto o servicio particular. Las encuestas tambin pueden ser conducidas con muestras locales, estatales o nacionales. Las encuestas pueden ser clasificadas por su mtodo de recoleccin de datos. Las encuestas por correo, telefnicas y entrevistas en persona son las ms comunes. Extraer datos de rcords mdicos y otros se hace tambin con frecuencia. En los mtodos ms nuevos de recoger datos, la informacin se entra directamente a la computadora ya sea por un entrevistador adiestrado o an por la misma persona entrevistada. Un ejemplo bien conocido es la medicin de audiencias de televisin usando aparatos conectados a una muestra de televisores que graban automticamente los canales que se observan. Las encuestas son una fuente importante de conocimiento cientfico bsico. Las encuestas por correo, a travs de entrevistas telefnicas o en persona son las ms comunes. Las encuestas por correo pueden ser de costo relativamente bajo. Como con cualquier otra encuesta, existen problemas en usar este mtodo si no se presta suficiente atencin a obtener niveles altos de cooperacin. Estas encuestas pueden ser ms efectivas cuando se

dirigen a grupos particulares, tal como suscriptores a una revista especializada o a miembros de una organizacin profesional. Las entrevistas telefnicas son una forma eficiente de recoger ciertos tipos de datos y se estn usando con cada vez mayor frecuencia. Se prestan particularmente bien a situaciones donde es necesario obtener resultados oportunos y cuando el largo de la encuesta es limitado. Las entrevistas en persona en el hogar u oficina de un participante son mucho ms caras que las encuestas telefnicas o por correo. Estas pueden ser necesarias especialmente cuando se debe recoger informacin compleja. Algunas encuestas combinan varios mtodos. Por ejemplo, una encuestadora puede usar el telfono para identificar participantes elegibles (tal como localizar individuos mayores elegibles para Medicare) y luego hacer cita para una entrevista en persona. Podemos clasificar las encuestas tambin por su contenido. Algunas encuestas enfocan en las opiniones y actitudes (tal como las encuestas pre-eleccionarias), mientras que otras se preocupan por caractersticas o comportamiento reales (tal como la salud de las personas, vivienda, gastos del consumidor o hbitos de transportacin). Muchas encuestas combinan preguntas de ambos tipos. Los participantes pueden ser preguntados si han odo ledo sobre algn asunto qu saben sobre l su opinin con cuanta firmeza sienten y por qu su experiencia sobre el asunto y ciertos datos personales que ayudar al analista a clasificar sus respuestas (tal como edad, gnero, estado civil, ocupacin y lugar de residencia). Las preguntas pueden ser abiertas (Por qu siente as?), o cerradas (Aprueba usted o desaprueba?). Los entrevistadores pueden solicitar al participante que evale un candidato poltico o un producto usando alguna escala, o pueden solicitarle que ordene varias alternativas. Aspectos a considerar al definir el muestreo

Importancia de determinar el tamao de una muestra El determinar el tamao de una muestra representa una parte esencial del mtodo cientfico para poder llevar a cabo una investigacin. Al muestreo lo podemos definir como el conjunto de observaciones necesarias para estudiar la distribucin de determinadas caractersticas en la totalidad de una poblacin, a partir de la observacin de una parte o subconjunto de una poblacin, denominada muestra. El muestreo debe procurar ser representativo, ya que proporciona ventajas de ndole econmicas y prcticas, nos brinda la alternativa de optar por otra alternativa, ya que en

lugar de investigar el total de la poblacin, se investiga tan slo una parte de ella, proporcionando con esto la informacin en forma ms oportuna, eficiente y exacta, eliminando con ello recurrir a encuestar a toda la poblacin Por ejemplo, una prctica comn que frecuentemente vemos en los peridicos y ms a ltimas fechas, me refiero a las encuestas de opinin efectuadas para las elecciones del 2006, donde se tiene una poblacin estimada de 109 millones de habitantes, se requera realizar un sondeo para saber por quin votaran los que cuentan con edad para ello. Imagnense el nmero de encuestadores y recursos necesarios para realizarla uno por uno, ante todo sera un gasto innecesario y superfluo. Tambin las evaluaciones pueden ser destructivas, imagnense que dentro de una planta que elabora productos alimenticios se requiere evaluar lacalidad de todos sus productos para lo cual se hara necesario destaparlos, piensen que destapar todos sus productos para verificarlos, seria un completo desperdicio y gasto innecesario. Principales definiciones As, con esto se hace necesario el que nosotros definamos los siguientes trminos: Una poblacin ser cualquier conjunto de individuos, objetos, medidas, etc. Es decir, un grupo de elementos comunes, se refiere en concreto a un grupo finito. Muestra de la poblacin, ser un subconjunto de elementos de esa poblacin. Donde los Elementos son las unidades individuales que componen la poblacin. Existen dos tipos de muestreo, el probabilstico y el no probabilstico mismo que en los presentes apuntes no ser tratado, pero diremos que para realizar este ltimo las razones estarn en funcin del costo y criterios del investigador. Definir el Tamao de una Muestra Al definir el tamao de la muestra, nosotros deberemos procurar que sta informacin sea representativa, vlida y confiable y al mismo tiempo nos represente un mnimo costo. Por lo tanto, el tamao de la muestra estar delimitado por los objetivos del estudio y las caractersticas de la poblacin, adems de los recursos y el tiempo de que se dispone. Etapas para determinar el Tamao De La Muestra 1. Determinar el nivel de confianza con que se desea trabajar. (Z ), donde z = 1.96 para un 95% de confianza o z= 1.65 para el 90% de confianza
TABLA DE APOYO AL CALCULO DEL TAMAO DE UNA MUESTRA

POR NIVELES DE CONFIANZA Certeza Z 95% 1.96 3.84 e 0.05 0.0025 94% 1.88 3.53 0.06 0.0036 93% 1.81 3.28 0.07 0.0049 92% 1.75 3.06 0.08 0.0064 91% 1.69 2.86 0.09 0.0081 90% 1.65 2.72 0.10 0.01 80% 1.28 1.64 0.20 0.04 62.27% 50% 1 1.00 0.37 0.6745 0.45 0.50

0.1369 0.25

Para ver como se distribuye algunas de las caractersticas de la muestra con respecto a la variable que se esta midiendo, podemos recurrir a la famosa campana de Gauss o Student que refleja la curva normal de distribucin cuya caracterstica principal es la de ser unimodal donde la media, mediana y la moda siempre coinciden.

Media, Moda y Mediana

Esta distribucin normal, nos permite representar en la estadstica muchos fenmenos fsicos, biolgicos, psicolgicos o sociolgicos:

Ahora bien, se hace necesario el definir los trminos Media, Moda y Mediana Media: Es el conjunto de n observaciones sumadas y divididas entre n. Moda: Se define como el valor que ms ocurre en un conjunto de observaciones. Mediana es el centro de un conjunto de observaciones ordenadas en forma creciente Esta curva esta detallada en todos lo libros de estadstica y recurriremos a ella cuando deseemos obtener otros valores de certeza como por ejemplo el 99% de estimacin y que da por resultado z=3.00 o z=1.65 para el 90%. 2. Estimar las caractersticas del fenmeno investigado. Donde deberemos considerar la probabilidad de que ocurra el evento (p) y la de que no se realice (q); siempre tomando en consideracin que la suma de ambos valores p + q ser invariablemente siempre igual a 1, cuando no contemos con suficiente informacin, le asignaremos p = .50 q = .50 . 3. Determinar el grado de error mximo aceptable en los resultados de la investigacin. ste puede ser hasta del 10%; ya que variaciones superiores al 10% reducen la validez de la informacin.

4. Se aplica la frmula del tamao de la muestra de acuerdo con el tipo de poblacin. Poblacin infinita Poblacin Finita

Cuando no se sabe el nmero exacto de Cuando se conoce cuntos elementos tiene la unidades del que est compuesta la poblacin poblacin. En donde: Z = nivel de confianza. p = Probabilidad a favor. q = Probabilidad en contra. N = Universo e = error de estimacin. n = tamao de la muestra

Diseo del muestreo. La seleccin de la muestra y las unidades de muestreo, es decir, el diseo del muestreo, depende del patrn espacial que presentan dichas unidades una vez ubicadas en la zona de estudio. El patrn espacial puede ser preferencial, aleatorio, estratificado, sistemtico. En el muestreo preferencial la muestra se sita en unidades consideradas tpicas o representativas de la poblacin sobre la base de criterios subjetivos del investigador. En los dems casos cuando son zonas extensas, lo primero que se sugiere es estratificar la zona, es decir, subdividirla en unidades espaciales o estratos homogneos de acuerdo a alguna variable de estratificacin como la vegetacin, comunidades, barrios, parroquias o alguna otra variable geogrfica o topogrfica. Dentro de cada estrato las unidades de muestreo se ubican segn un patrn aleatorio o sistemtico, aplicando algunas de las tcnicas de muestreo estadstico sealadas anteriormente. De esta manera se pretende disminuir la variabilidad (desviacin estndar) de los datos, con respecto a toda la zona sin estratificar. En los ltimos tiempos se recurre a imgenes, fotografas areas, etc. Al momento de realizar la estratificacin. Tamao de la muestra. A mayor nmero de unidades muestrales, ms precisa ser la estimacin de la

variable o variables consideradas. Sin embargo dado el gran costo del muestreo (econmico, de esfuerzo, tiempo) es necesario llegar a un compromiso tal que el esfuerzo invertido sea equivalente a la cantidad y a la calidad de la informacin. Criterios para seleccionar el tamao de la muestra: - Relacin entre el rea muestreada y la superficie total. - De acuerdo a procedimientos estadsticos se exige un determinado nivel de precisin (error de muestreo), el cual puede ser calculado por informacin previa sobre la zona en estudio, puede ser fijado segn algn criterio del investigador o puede ser impuesto por la institucin para la cual se est realizando el estudio. Luego dependiendo de la tcnica de muestreo seleccionada, se procede a usar algunas frmulas que permiten calcular exactamente su tamao. - Otra manera de calcular este tamao es realizando un premuestreo donde se tengan unidades pequeas. Se calcula la media para una variable de inters, luego se va incrementando el tamao de estas unidades junto con el clculo de su media, se realiza un grfico del tamao de las unidades con respecto a las medias obtenidas y se puede considerar como un tamao ptimo aquel valor donde la media se estabiliza, deja de tener mucha fluctuacin; claro este procedimiento es un poco subjetivo al momento de seleccionar este valor. - Si se conoce la intensidad de muestreo el tamao de la muestra (n) puede ser calculado a partir de la siguiente formula: n= (i * N) / 100 i = intensidad de muestreo - Conociendo la fraccin de muestreo: n= f * N Para el clculo del tamao de la muestra n, se considerar la siguiente frmula (Scheaffer Mendenhal, (1987)

Donde: cv% = Coeficiente de Variacin (estimado de estudios previos o calculado a partir de un premuestreo), exclusivo para el tamao de parcela utilizado.

cv% = (s / )*100 Y = media muestral de la variable y s = desviacin estndar muestral de la variable y E% = Error de muestreo prefijado (usualmente 10%) t = t de Student a p nivel de probabilidad (usualmente 95%) y con (n-1) grados de libertad (se comienza con grados de libertad y se va reiterando el clculo con los valores de n obtenidos por la aplicacin de la frmula, hasta que n no cambie significativamente en dos clculos sucesivos) N= Nmero total de elementos en la poblacin - Disponibilidad de recursos y asignacin de responsabilidades. En esta etapa se engloba todo lo concerniente a la preparacin del personal que va a recoger la informacin y del material que se va a usar para ello. - Ejecucin. Esta etapa comprende la ejecucin del trabajo de campo. - Anlisis de la informacin. Una vez recogida y purificada la informacin se procede a elaborar la base de datos para su procesamiento y anlisis. En esta etapa es muy importante pensar en los resultados que se podran obtener y cul ser el formato de presentacin de los mismos. - Uso y aplicacin de los resultados. Anlisis de los datos de la encuesta

Encuesta: Es un mtodo de recoleccin mediante el cual la informacin se obtiene relevando slo un subconjunto o muestra de elementos del universo en estudio, que permite obtener informacin sobre el mismo. Para que la informacin obtenida con la encuesta sea generalizable a la poblacin, la muestra utilizada debe ser representativa de la poblacin de la que proviene. Para lograrlo, se utilizan mtodos de seleccin de unidades especialmente diseados con este fin. Su uso ha ido en rpido aumento, en la medida en que las instituciones productoras de informacin disponen depersonal capacitado para efectuar su organizacin, diseo y anlisis, debido a su menor costo y a que en determinadas circunstancias la informacin resulta ms exacta debido a que los errores ajenos al muestreo (errores en la recoleccin y en el procesamiento) pueden ser reducidos a travs de una mejor capacitacin de los empadronadores y la utilizacin de mtodos de captacin de informacin ms objetivos. Anlisis e interpretacin de datos.

Para llevar a cabo esto es necesario: Replantear la hiptesis de trabajo, y discriminar de ella, las variables: independiente, dependiente e interviniente. Seleccionar las categoras (preguntas) relevantes para anlisis (realizarlo con base a la hiptesis); para lo cual es necesario, establecer los grupos de variables que corresponden a la variable independiente, a la dependiente y a la interviniente. Establecer las relaciones (causales, efecto, condicionantes, etc.) entre las categoras, subcategoras y variables sealadas como relevantes: cuestionar (realizar preguntas) a las categoras, subcategoras y variables; responder esas preguntas con los datos (cuantitativos y cualitativos) que se han ordenado previamente. Ir redactando el cuerpo del informe a medida que van surgiendo los datos de las categoras, subcategoras y variables. Establecer las condiciones (tesis) de cada pregunta. Establecer y jerarquizar las situaciones problemticas. Recuerde que cada matriz tiene datos que corresponden a una pregunta (variable) o al cruce de ellas; y es necesario que al analizar e interpretar los datos se tomen en cuenta estas sugerencias. Inferencia estadstica. Cuando se realiza un estudio de investigacin, en base a evidencia obtenida de una muestra de la poblacin, se recurre a la inferencia estadstica, entendida sta, como una parte de la metodologa estadstica, que utiliza, precisamente, esa evidencia, para extender, mediante un razonamiento inductivo, los resultados obtenidos a la poblacin o universo de origen. De los procedimientos propios de la inferencia estadstica, sin duda, es la prueba de hiptesis la ms importante. La prueba de hiptesis trata con situaciones en donde el investigador una vez recopilada la evidencia (datos muestrales) debe especificar si son congruentes o no con la hiptesis planteada, esto es, saber si es falsa o verdadera. Para ello, dispone de la teora estadstica, que provee de una variedad de modalidades de pruebas, dependiendo de la naturaleza de las variables de inters. Se sugiere que se revise material bibliogrfico con referencia al clculo estadstico, para ampliar la visin sobre esta temtica. La presentacin del informe de investigacin.

La comunicacin de los resultados de una investigacin debe hacerse con claridad y de acuerdo con las caractersticas del usuario o receptor. Para ello es necesario formular las siguientes preguntas: Cul es el contexto en que habrn de presentarse los resultados? Quines son los usuarios de los resultados? Cules son las caractersticas de estos resultados? Cules son las caractersticas de estos usuarios? Si los resultados se presentan con fines comerciales al pblico en general, o a personas con menores conocimientos en investigacin, entonces se est en un contexto no acadmico. Sesin 6 Proyecto de Cuestionario de Satisfaccin del Cliente Encuesta Una encuesta es un estudio observacional en el cual el investigador busca recaudar datos de informacin por medio de un cuestionario prediseado, y no modifica el entorno ni controla el proceso que est en observacin (como s lo hace en un experimento). Los datos se obtienen a partir de realizar un conjunto de preguntas normalizadas dirigidas a una muestra representativa o al conjunto total de la poblacin estadstica en estudio, formada a menudo por personas, empresas o entes institucionales, con el fin de conocer estados de opinin, caractersticas o hechos especficos. El investigador debe seleccionar las preguntas ms convenientes, de acuerdo con la naturaleza de la investigacin. Tipos Cuando es posible listar o enumerar a cada uno de los elementos de la poblacin se dice que la encuesta es un censo. Es decir, un censo es una encuesta que se realiza a toda la poblacin. El inconveniente de este tipo de encuesta es que suele ser complicada, reunir mucho tiempo, y ser econmicamente costosa. Tiene, claro, la ventaja de que si no se cometieron errores en su realizacin, asegura que se posee informacin de cualquier individuo de la poblacin. El censo pocas veces otorga, en forma clara y precisa, la verdadera informacin que se requiere. De ah que sea necesario muchas veces realizar una encuesta muestral (tambin llamada, encuestas por muestreo) a la poblacin en estudio, para obtener informacin suplementaria en relacin a la otorgada por el censo. En estas encuestas se elige una parte de la poblacin que se estima representativa de la poblacin total. Debe tener un diseo muestral (o sea, un proceso de seleccin de la muestra), necesariamente debe tener

un marco muestral (lista de elementos pertenecientes a la poblacin de la cual se obtendr la muestra) y ese marco, cuando se trata de personas, suele obtenerse del censo de poblacin. Si no se cuenta con un censo, dependiendo de la informacin buscada, puede ser reemplazado por un padrn electoral, un directorio telefnico, etc. Una forma reducida de una encuesta por muestreo es un "sondeo de opinin", esta forma de encuesta es similar a un muestreo, pero se caracteriza porque la muestra de la poblacin elegida no es suficiente para que los resultados puedan aportar un informe confiable. Se utiliza solo para recolectar algunos datos sobre lo que piensa un nmero de individuos de un determinado grupo sobre un determinado tema. Actualmente, existen sistemas de gestin de encuestas en Internet, que estn acercando su utilizacin a investigadores que hasta el momento no tenan acceso a los medios necesarios para ejecutarla. Tambin hay 2 tipos que son: 1. Encuesta cerrada: son encuestas en las cuales, el encuestador establece una serie de alternativas. 2. Encuesta abierta: son encuestas en las cuales, el encuestado puede responder de manera libre . Ejemplo de uso 1. Medir las relaciones entre variables demogrficas, econmicas y sociales. 2. Evaluar las estadsticas demogrficas como errores, omisiones e inexactitudes. 3. Conocer profundamente patrones de las variables demogrficas y sus factores asociados como fecundidad y migraciones determinantes. 4. Evaluar peridicamente los resultados de un programa en ejecucin. 5. Saber la opinin del pblico acerca de un determinado tema. 6. Escoger el tema a tratar. Encuesta por muestreo Ventajas 1. Bajo costo 2. Informacin ms exacta (mejor calidad) que la del censo debido a que el menor nmero de encuestadores permite capacitarlos mejor y ms selectivamente.

3. Es posible introducir mtodos cientficos objetivos de medicin para corregir errores. 4. Mayor rapidez en la obtencin de resultados. 5. Tcnica ms utilizada y que permite obtener informacin de casi cualquier tipo de poblacin. 6. Gran capacidad para estandarizar datos, lo que permite su tratamiento informtico y el anlisis estadstico. Desventajas El planeamiento y ejecucin de la investigacin suele ser ms complejo que si se realizara por censo. 1. Requiere para su diseo de profesionales con buenos conocimientos de teora y habilidad en su aplicacin. Hay un mayor riesgo de sesgo muestral. 2. Es necesario dar un margen de confiabilidad de los datos, una medida del error estadstico posible al no haber encuestado a la poblacin completa. Por lo tanto deben aplicarse anlisis estadsticos que permitan medir dicho error con, por ejemplo, intervalos de confianza, medidas de desviacin estndar, coeficiente de variacin, etc. Esto requiere de profesionales capacitados al efecto, y complica el anlisis de las conclusiones.

Tipo de preguntas que funcionan mejor en las encuestas de satisfaccin del cliente

1. Qu tan importante es el conocimiento de la industria a la hora de elegir entre diversas empresas como la nuestra?

Qu tan importante es el conocimiento de la industria a la hora de elegir entre diversas empres Muy importante Un poco importante Ligeramente importante Nada importante

2. Qu tan importante es la antigedad comercial a la hora de elegir entre diversas empresas como la nuestra?

Qu tan importante es la antigedad comercial a la hora de elegir entre diversas empresas com Muy importante Un poco importante Ligeramente importante Nada importante

3. Qu tan importante es la capacidad de realizar consultas a la hora de elegir entre diversas empresas como la nuestra?

Qu tan importante es la capacidad de realizar consultas a la hora de elegir entre diversas emp Muy importante Un poco importante Ligeramente importante Nada importante

4. Qu tan importantes son las herramientas y la tecnologa ofrecidas a la hora de elegir entre diversas empresas como la nuestra?

Qu tan importantes son las herramientas y la tecnologa ofrecidas a la hora de elegir entre div Muy importante Un poco importante Ligeramente importante Nada importante

5. Qu tan importantes son las referencias personales a la hora de elegir entre diversas empresas como la nuestra?

Qu tan importantes son las referencias personales a la hora de elegir entre diversas empresa Muy importante Un poco importante Ligeramente importante Nada importante

6. Qu tan importante es el costo a la hora de elegir entre diversas empresas como la nuestra?

Qu tan importante es el costo a la hora de elegir entre diversas empresas como la nuestra? E Muy importante Un poco importante Ligeramente importante Nada importante

7. Califique la calidad general de nuestros productos y servicios.

Califique la calidad general de nuestros productos y servicios. Excelente Muy buena Buena Regular Pobre

8. Califique nuestro nivel de comprensin de sus necesidades empresariales.

Califique nuestro nivel de comprensin de sus necesidades empresariales. Excelente Muy bueno Bueno Regular Pobre

9. Qu tan claras fueron nuestras comunicaciones con usted?

Qu tan claras fueron nuestras comunicaciones con usted? Extremadamente claras Muy claras Un poco claras Ligeramente claras Nada claras

10. Qu tan informado sobre nuestro progreso lo mantuvimos?

Qu tan informado sobre nuestro progreso lo mantuvimos? Extremadamente informado Muy informado Un poco informado Ligeramente informado

Nada informado

11. Con qu nivel de eficacia cumplimos con los plazos?

Con qu nivel de eficacia cumplimos con los plazos? Extremadamente eficaces Muy eficaces Un poco eficaces Ligeramente eficaces Nada eficaces

12. Califique el valor de nuestros productos y servicios en comparacin con el costo.

Califique el valor de nuestros productos y servicios en comparacin con el costo. Excelente valo Muy buen valor Buen valor Valor regular Valor pobre

13. Qu tan rpido respondimos ante los problemas?

Qu tan rpido respondimos ante los problemas? Extremadamente rpido Muy rpido Un poco rpido Ligeramente rpido Nada rpido

14. Qu nivel de conocimientos tena el representante de su empresa?

Qu nivel de conocimientos tena el representante de su empresa? Extremadamente informad Muy informado Un poco informado Ligeramente informado Nada informado

15. Nuestro desempeo es mejor que antes, peor que antes, similar, o usted no realiz actividades comerciales con nosotros previamente?

Nuestro desempeo es mejor que antes, peor que antes, similar, o usted no realiz actividades Peor Similar No he realizado actividades comerciales con ustedes anteriormente

16. Al realizar una llamada habitual, cunto debe esperar en lnea?

Al realizar una llamada habitual, cunto debe esperar en lnea? Minutos:

17. Con qu nivel de puntualidad recibe las facturas?

Con qu nivel de puntualidad recibe las facturas? Extremadamente puntual Muy puntual Un poco puntual Ligeramente puntual Nada puntual

18. Cules son las probabilidades de que realice actividades comerciales con nosotros nuevamente en el futuro?

Cules son las probabilidades de que realice actividades comerciales con nosotros nuevament Muy probable Un poco probable Ligeramente probable Nada probable

19. Cules son las probabilidades de que nos recomiende a otras personas?

Cules son las probabilidades de que nos recomiende a otras personas? Extremadamente pro Muy probable

Un poco probable Ligeramente probable Nada probable

20. Por cunto tiempo ha sido cliente?

Por cunto tiempo ha sido cliente? Aos: Meses:

21. Cuntos empleados tiene su empresa?

Cuntos empleados tiene su empresa? Empleados:

22. Cmo se enter de la existencia de nuestra empresa?

Cmo se enter de la existencia de nuestra empresa? Nuestro sitio web Motor de bsqueda Referencias Uno de nuestros empleados Noticias en los medios Otro
Listo

Problemas en la recoleccin de datos de las encuestas de satisfaccin del cliente Encuesta de satisfaccin del cliente Use esta plantilla para encuestas breves sobre la satisfaccin del cliente para medir de manera precisa el nivel de satisfaccin del cliente con su compaa, su producto y su servicio. Use la lgica de exclusin para permitir a sus clientes responder preguntas relacionadas con los productos o los servicios que han usado y descubrir en qu reas debe mejorar.

Satisfaccin del cliente con una encuesta de servicio al cliente Evale el xito de su servicio de atencin al cliente y de los agentes de soporte con una rpida encuesta de servicio al cliente. Enve esta encuesta a sus clientes inmediatamente despus de cada interaccin para averiguar si fue fcil localizar a los representantes del servicio al cliente y si estos fueron tiles y serviciales. Adems, puede evaluar el tiempo de espera del servicio al cliente, la resolucin de problemas y el conocimiento del producto/servicio para asegurarse de que los representantes de la compaa siempre dejen una buena impresin en los clientes. Encuesta de una empresa a otra Cada uno de sus clientes tiene necesidades nicas diferentes, en particular cuando se trata de empresas. Cuando sus clientes tambin son empresas, enve una breve encuesta de satisfaccin del cliente. Identifique el nivel de satisfaccin de sus clientes segn su puntualidad, profesionalismo y servicio. De este modo, podr asegurarse de que lo sigan eligiendo. Las siguientes son algunas consideraciones a tener presentes al desarrollar una estrategia para medir la satisfaccin del usuario a travs de Encuestas de Satisfaccin. Definir el objetivo de la encuesta. Identificar que informacin es la que se pretende recabar. Casos concretos seran: el servicio brindado por el personal, la rapidez del servicio, tiempos de espera, aspecto de las instalaciones, reclamaciones, etc. Este es el primer paso y el ms importante, aunque muchos suelen brincrselo, y los problemas llegan cuando se analizan los resultados obtenidos. Definir la escala de medicin. Determinar la escala a utilizar para la encuesta, se puede seleccionar una o varias escalas dentro de la misma encuesta. La seleccin de la escala a utilizar determinar en gran medida las preguntas, la distribucin de la encuesta y el cmo se recogen los datos. Dentro de las principales escalas se pueden mencionar las siguientes: Escala de tres puntos (1 = Malo, 2 = Regular, 3 = Bueno) Escala de cinco puntos (1 = Malo, 2 = No tan malo, 3 = Neutral, 4 =Bueno, 5 = Muy Bueno ) Escala de diez puntos (1 = Nada importante 10 = Muy importante)

Definir el nmero y tipo de preguntas. Anteriormente se ha dicho que no existe un nmero ideal de preguntas para una encuesta, sin embargo debe de lograrse que la encuesta recabe la informacin que se necesita para cumplir un objetivo. Las preguntas pueden ser abiertas o cerradas, de preferencia pueden utilizarse preguntas abiertas al principio. Sin

embargo no hay que abusar de este tipo de preguntas, recordando que para poder medir la satisfaccin del cliente necesitamos datos duros y esos se pueden obtener a travs de las mediciones (escalas). Realizar pruebas piloto. Llevar a cabo pruebas piloto antes de liberar la versin final, haciendo pruebas con colaboradores, familiares, amigos, etc. El fin de llevar a cabo estas pruebas es identificar todas aquellas preguntas que pudiesen no resultar claras y entendibles, as como la distribucin de las mismas en la encuesta.

Logre una ventaja competitiva utilizando encuestas de satisfaccin

A menudo, el valor de la satisfaccin es subestimado. Una parte esencial de la evaluacin de la satisfaccin incluye evaluar la insatisfaccin. Los usuarios y los empleados insatisfechos, a menudo tienen la informacin que no hace falta para lograr un producto o servicio exitoso. Entender cuando y por qu se manifiesta la insatisfaccin, le ayuda a implementar cambios para ganar y retener usuarios. Las encuestas sobre satisfaccin recogen informacin valiosa Hoy en da, las encuestas sobre satisfaccin y los cuestionarios se utilizan cada vez con mayor frecuencia. Piense cuntas veces le solicitan que complete un cuestionario cuando compra un producto o disfruta de un servicio. Cualquiera sea el medio por el que se realicen: mailing, telemarketing o internet; usted encuentra cuestionarios sobre satisfaccin en restaurantes, consultorios mdicos, seminarios e incluso en los cines. Las encuestas sobre satisfaccin responden preguntas difciles Una encuesta de satisfaccin bien diseada puede darle la respuesta a su pregunta ms crtica: Estn satisfechos mis usuarios? Las organizaciones utilizan encuestas sobre satisfaccin para alcanzar estos objetivos:

Entender las expectativas y los requerimientos de sus clientes, empleados, pacientes y miembros.

Determinar en qu medida satisface su organizacin esas expectativas y requerimientos. Desarrollar estndares de servicio o producto basndose en sus hallazgos. Observar las tendencias de forma tal de poder tomar acciones inmediatamente. Establecer prioridades, objetivos y estndares para evaluar si est alcanzando esos objetivos. Evaluar el impacto que produce un cambio en una poltica, producto o servicio.

Las encuestas sobre satisfaccin lo ayudan a tomar las decisiones correctas Las organizaciones exitosas hacen del anlisis de satisfaccin una parte integral de sus negocios. Utilizan la estadstica para traducir las respuestas en informacin valiosa a fin de obtener el mximo de sus datos. Esta lista de los beneficios que brindan las encuestas sobre satisfaccin demuestra cmo las organizaciones han logrado xito utilizando las encuestas sobre satisfaccin y analizndolas por medio de las estadsticas. Las encuestas ayudan a los analistas a identificar qu sucursales, plazas o localidades de una organizacin pueden o necesitan mejorar, para ofrecer a sus usuarios una mejor experiencia de uso. Los resultados del anlisis estadstico le ayudan a la gerencia a decidir que recursos, como entrenamiento y tecnologa (entre otros), necesitan sus sucursales. Encuestas en sitios de internet Debido al gran auge que han ganado los sitios de internet en todo el mundo, la audiencia en ellos se ha convertido en un punto clave para su existencia y adems, en su principal fuente de ingresos ya que la publicidad ha aprovechado la oportunidad para introducirse en estos. Pero esto no sucede en todos los casos, existen sitios a los que solo les interesa el nmero de visitantes que tienen cada cierto tiempo, con el fin de realizar comparativos de relevancia de informacin o bien, conocer el tipo de usuarios que frecuentan dicha pagina. Dichos documentos estadsticos tambin sirven para conocer las preferencias de los usuarios y de alguna manera, contribuir a la personalizacin del portal, esto a travs de las visitas que hace sobre cada una de las ligas o banners de publicidad, lo cual significa que existe cierto inters. Los sistemas de medicin se dividen principalmente en tres tipos:

Basado en el usuario: obtiene informacin del usuario a travs formularios, encuestas, programas instalados en sus ordenadores que registran todo acerca de la forma en que navegan. Basado en la publicidad: analiza el trfico mediante los banners y los archivos log (archivos de registro) de los servidores de anuncios. Orientado al sitio web: el sitio recupera la informacin mediante sus archivos log del servidor y sus aplicaciones HTML y/o Java.

Procedimientos para manejar datos faltantes Problemas con el anlisis de datos de encuestas Consejos para disear una buena encuesta 10 formas de mejorar la respuesta de un cuestionario

1. Convierte al cuestionario en el hroe del mailing en caso de ser una encuesta on-line, que no sea simplemente una parte. El acceso a la encuesta es recomendable que no solo sea un link sino que haya un botn o un icono para acceder. Evita el texto redundante, complejo y largo: mejor emails cortos y concisos, explicando muy claro la garanta de privacidad de la encuesta. 2. Menos preguntas, mejor. Entre 7 y 9 es lo ideal. Por alguna extraa razn los nmeros impares parecen funcionar mejor. Esta afirmacin es correcta para encuestas en newsletters, pero depende de la relacin que se tenga con el usuario y del incentivo, se podrn hacer encuestas ms largas. En caso de encuestas de satisfaccin o de clima laboral, la duracin de la encuesta podr ser ms larga dada la relacin del receptor con el remitente. 3. Incluye una carta de gracias por anticipado. Diles que sus respuestas son importantes. Diles lo que obtienen a cambio. Es tan importante la forma en que se comunica el agradecimiento como el incentivo. En encuestas en newsletters, o de satisfaccin por el uso de una web, etc es importante ofrecer una recompensa por el tiempo invertido en la encuesta. Es mucho ms efectivo el incentivo directo que el sorteo. 4. Haz que la carta venga de alguien importante o con un cargo importante en la empresa. Es muy relevante en encuestas de satisfaccin de clientes que venga de la persona con quien se ha estado trabajando, responsable de cuentas, comercial, etc. y en las de clima laboral, es importante que sea una direccin ms neutra y a ser posible de una empresa externa que realice el trabajo de investigacin.

5. Ofrceles algo. Puede ser una participacin en un sorteo, un regalo o la promesa de enviarles los resultados en cuanto los tengas tabulados 6. En el mismo cuestionario, da las gracias. En la pgina de redireccin que ver el encuestado al acabar, incluye adems de las gracias, una confirmacin de que sus datos han sido guardados y una direccin de contacto por si tuviesen alguna duda. 7. Incluye la oferta en el mismo cuestionario. Utiliza una fotografa de la misma, si es posible.Esta recomendacin est pensada para ofertas de productos, pero se puede cambiar por incluye elementos multimedia en el cuestionario, cuanto ms dinmico e interactivo sea este, mejor. 8. Haz que el cuestionario sea simple. Respuestas del tipo S/No funcionan mejor. Preguntar a la gente cul va a ser su cifra de ventas para el 2005 puede ser complicado, y una buena razn para tirarlo a la papelera. Evita adems las matrices en la medida de lo posible, no son intuitivas y son preguntas que crean mucha confusin. 9. Asegrate de que incluyes un espacio para sugerencias o comentarios. No importa como hayas hecho el cuestionario, siempre se olvida uno de algo. Dales la oportunidad de expresar lo que quieran. Adems, las preguntas abiertas son mucho mejor contestadas y con mayor contenido por Internet que por cualquier otro canal. El usuario ve en ellas una oportunidad de dar su opinin libremente y sin limitaciones. 10. Si es necesario, tranquilzalos respecto a la confidencialidad de las respuestas obtenidas y de que no se utilizarn para intentar venderles algo (a no ser que ste sea el objetivo). En un estudio de mercado el objetivo de la encuesta no puede ser vender algo, pero si es necesario en cualquier caso garantizar la confidencialidad de las respuestas, eliminando el vnculo entre los datos personales del participante y sus respuestas.

Sesin 7 Proyecto de Plan de Aseguramiento de Calidad (SQA) de un sitio Web Como aplicar los conceptos de un plan de aseguramiento de calidad (SQA) a un proyecto Web Que aspectos se deben de evaluar en un sistema Web para asegurar confiabilidad Como definir los requerimientos del sistema Como evaluar la experiencia del usuario

ESTOS CONTENIDOS ESTAN EN LA CARPETA DOS PRESENTACIONES QUE DICEN SESION 7. LOS ADJUNTAN ALL El tema de evaluar habla de probar, en la ingeniera de software existen las pruebas tcnicas, las cuales permite realizar evaluaciones y afinamientos del producto de software, tambin es conocido como SQA o aseguramiento de la calidad del software, realmente cada desarrollo de software se inicia o se crea segn una necesidad, y esta necesidad contiene un sin fin de requerimientos o funciones mnimas que deba cumplir el software, los conceptos tcnicos de los cuales hablasuso de tecnologas, validez y semntica del cdigo, adecuacin de la esttica, usabilidad, accesibilidad y compatibilidad. son conceptos que permiten evaluar lo No funcional, es decir lo que no est directamente enfocado al proceso que este realiza. En fin. El tema es que para evaluar un sitio web, se deben contar con la siguientes premisas: 1. Capacidad de Usuarios Concurrentes 2. Tiempos de Respuesta bajo esa concurrencia de usuarios 3. escalabilidad, es decir la capacidad de adaptabilidad que tenga el sitio web o aplicativo web a las exigencias del medio. Este debe ser el primer paso al evaluar un sitio web, luego de eso es analizar bajo los elementos existentes si el sitio satisface las condiciones o requerimiento tanto funcionales como no funcionales para el cual fue creado.

Sesin 8 Proyecto de Mtricas de Calidad de Proceso Que son la medidas de proceso Como se seleccionan las medidas de proceso Como se interpretan las medidas de proceso

Proceso de medicin Con el fin de lograr una mejor comprensin de la medicin algunos conceptos como: beneficios de la medicin. Qu que es medir, por qu medir, donde realizar mediciones, cuando y que debemos medir, quien debe hacer la medicin, las mediciones y la gerencia, las mediciones y el mejoramiento. Que es medir? Medir es determinar una Cantidad comparndola con otra.

La anterior resistencia tiene races en la gerencia, en primer lugar por no haber dotado al personal de habilidades para medir, establecer y calcular indicadores validos y representativos del proceso o trabajo en el cual interviene o realizan, y en segundo lugar por el mal uso que se ha tenido de la medicin en el pasado: el de buscar cupables. Sin la superacin de estas dosdebilidades la participacin real y efectiva no dejara de ser un buen deseo. Una correcta comprensin y desarrollo de la medicin es fundamental para superar la gerencia por situaciones o crisis, ese estilo de gerencia que entroniza el "Por hacer lo urgente, dejamos de hacer lo importante". Bajo este estilo gerencial los compromisos con el cliente se convierten en un cuando pueda. El mantenimiento es solo para las emergencias, se compra solo lo urgente, la calidad es medida por los reclamos, es un estilo que no permite avanzar y evolucionar las empresas y menos alcanzar su misin y mucho menos su visin. La medicin no puede entenderse solo como un proceso de recoger datos, sino que debe insertarse adecuadamente en el sistema de toma de decisiones. Se pueden tener muchos datos sobre las causas de un efecto, pero si no se tiende a clasificarlos, estudiar su frecuencia, aislar los principales, y establecer sus relaciones con la finalidad ya sea de poner bajo control el proceso o de mejorar su desempeo, de poco servirn dichos datos y la medicin. Se tendr algo as como una fotografa de la situacin en forma esttica, mas no del porque de la misma y su tendencia, que es la visin dinmica del asunto. Por que medir? La medicin en el concepto tradicional ha servido ms para buscar responsables, que una oportunidad para mejorar los procesos dentro de laempresa. Por lo tanto las empresas deb en cambiar su paradigma de que la medicin, la evaluacin y control son agentes de la fiscalizacin y penalizacin por encima de las posibilidades de correccin y mejoramiento. En esta perspectiva la medicin debe buscar que el anlisis de las mediciones tienda a identificar responsabilidades de mejora y no a establecer culpables. Por responsable debe entenderse aquel que puede y debe tomar las decisionespertinentes p ara mejorar en el momento oportuno. Establecer un clima de esta naturaleza en la empresa es tarea fundamental de la gerencia porque le permitir tener una organizacin con actitud crtica y de superacin de las barreras que se le interpongan en el camino, lo que conlleva finalmente a generar un clima de confianza, base fundamental del desarrollo organizacional.

Debe insistirse en que la medicin como un aspecto de los procesos de toma de decisiones interesa a los diferentes niveles de las entidades y apreciadas, a dimensin organizacional de las mediciones, es importante desarrollar las mismas de la manera mas participativa posible. Esto ayudara a lograr el clima de confianza y aceptacin en que deben desenvolverse las mediciones, as como a mejorar los niveles de involucramiento de todo el grupo de trabajo en las etapas anteriores de anlisis y mejoramiento de las reas de oportunidad detectadas. Para que medir? Con frecuencia se observa que muchas personas se quejan de lo arduo del trabajo durante todo el da y al final de este se dedican a algunas actividades deportivas que consumen muchas ms energas que las ocho horas de trabajo, y aun as se sientenencantadas de practicarlas. Parece que experimentaran un sentimiento de logro cuando el sistema de medidas le ofrece una retroalimentacin directa. La emocin que se experimenta al jugar bolos no consiste solamente en el lanzamiento de la bola, se trata de saber el nmero de palitroques que se han derribado. Estudios recientes han confirmado que las personas en las empresas quieren que se les evale. Necesitan que se les mida. Los trabajadores mediocres parecen ser los nicos que no desean ser evaluados. En efecto, si la empresa y la gerencia no establecen los sistemas apropiados de medicin, los buenos ejecutores idearan la forma de autoevaluarse para poder de esta manera mejorar donde estn dbiles. Sin embargo esto carece de significado para la empresa, por lo tamo esta debe trabajar con los empleados para establecer medidas que tengan significacin tanto para ellos, como para la organizacin. En el deporte existen reglas bien definidas y lo que se trata es de superar su desempeo, algo similar existe en los procesos de la empresa, y por ello se debedesarrollar una serie de procesos que permitan a los empleados superar sudesempeo dando lo mejor de s. Las medidas permiten al individuo desarrollar un sentimiento de logro ysuperacin. Las m edidas acompaadas de un buen sistema de recompensasestimulan al individuo y al equipo a realizar un es-fuerzo adicional que se necesita para que la organizacin se aparte de lo comn. Objetivos de la medicin La medicin permite: Planificar con mayor certeza y confiabilidad.

 Discernir con mayor precisin las oportunidades de mejora deun proceso dado. Analizar y explicar como han sucedido los hechos. Corregir las condiciones fuera de control. Comprender si nuestro producto es competitivo en el mercado. Establecer prioridades en la organizacin. La medicin es necesaria e indispensable para conocer a fondo los procesos, ya sean administrativos o tcnicos, de produccin o de apoyo que se dan en la organizacin y para gerenciar su mejoramiento acorde con la exigente competencia actual. El conocimiento profundo de un proceso parte de admitir y conocer suvariabilidad y sus causas, las mismas son imposibles de conocer sin su medicin. Conocer esto es precisamente la clave para gerenciar el proceso y conquistar los objetivos de excelencia que se plantean. Conocer un proceso no es estudiarlo una vez, se trata de una actitud permanente de observacin y estudio para aprender las tendencias de este, sus condiciones, potencialidades, limitaciones y sus causas. Muchas veces se interpreta que la medicin es solo til para conocer las tendencias promedios, olvidando que estas son tiles dependiendo de cmo sean presentadas o procesadas y que cuando se dirigen procesos dentro de las empresas no nos basta saber las tendencias promedios, sino que debemos ir mas all, conociendo con precisin la variabilidad en toda su gama y lainterconexin de facto-res y causas en cada nueva situacin. Situaciones yrelaciones que tambin se expresan a travs del lenguaje de la medicin. Sin medicin no se puede adelantar con rigurosidad y sistemticamente las actividades del proceso de mejoramiento a saber: Evaluar, Planificar, Disear Prevenir Innovar Corregir Mantener. Que es medible?

Medir es fcil en produccin, en mi departamento no es aplicablelo que nosotros vendemos es intangible y no se puede medir, "estasson expresiones que cotidianamente se escuchan e n la mayora de las'empresas. La mayor confusin es relacionar lo intangible con cosas perfectamente medibles, pero para lo cual no se ha desarrollado o no se conoce instrumento o indicador adecuado. La palabra tangible significa que puede tocarse, que es sensible, que se percibe en forma precisa, lo cual no implica que para todo lo tangible: tengamos instrumentos desarrollados para medirlo o contarlo. EL malestar de un cliente es algo que se siente y se percibe conprecisin, mas, a veces, no se cuantifica para compararlo con referenciaspreestablecidas, tarea esta que se debe abor dar dependiendode la importancia del asunto a gerenciar. El que algo no se haya medido hasta el presente, no implica que no se pueda odeba medir. Muchas variables que en el pasado no eran medibles hoy sonabsoluta mente posibles. La temperatura, la longitud, e! peso, el ruido, la luminosidad, la humedad, etc., son algunas de ellas. Otras un poco sin desarrollar aun: como la medida de un retraso,de un error, de la satisfa ccin, de la comodidad, donde el instrumentode medicin no existe y que son de gran impo rtancia para eldesarrollo y mejoramiento de los procesos de empresa. Por lo anterior en estas se utilizan algunas mediciones indirectas, las cuales hoy son muy confiables. Cuando se habla de medicin no necesariamente se refiere a escalas universal es reconocidas para expresar los resultados, como alternativa se, pueden utilizar indicadores con escalas propias, desarrolladas para cada uno que permitancomparaciones, las cuales son tiles para grados de avance. EL nivel de satisfaccin de los clientes puede medirse indirectamente. Por ejemplo, la opinin respecto al acto de comprar: 1. Volvera usted a comprar en este empresa? 2. Antes de comprar buscara otras alternativas? 3. Le recomendara comprar a un familiar? Los anteriores niveles pueden darle una orientacin que le permite construir una escala cuantitativa para facilitar la expresin de la satisfaccin de compra de este consumidor. Donde medir? El principal problema de la mayor parte de los procesos de la empresa es que el proceso solo se mide al final. En la generalidad de los casos, lo anterior proporciona poca retroalimentacin relativa sobre las actividades individuales dentro del proceso, o

cuando lo proporciona es demasiado tarde. Es necesario establecer puntos de medida aproximados a cada actividad, de manera quelas personas que la realizan reciban una retroalimentacin directa, inmediata y pertinente para establecer las correcciones en tiempo real. Imaginmonos por ejemplo, cuan difcil seria controlar la factura de llamadas telefnicas de larga distancia si todas las que se hacen dentro de la empresa llegan a un mismo nmero de cuenta. Las mediciones deben realizarse tan pronto como se haya finaliza- -do unaactividad del proceso.' No dirija su empresa como hace la persona que noregistra la cantidad de cheques que gira, sino que espera hasta e! momento que llega el extracto bancario para saber cul es su saldo. Posponer las mediciones contribuye a que se cometan errores adicionales. Que procesos medir ? La gerencia tiene la responsabilidad de proporcionar sistemas de medidas correctas y retroalimentacin apropiada para ayudarles a todos a que hagan mejor su trabajo. Mediante la evaluacin de los resultados, la gerencia seala que cosas son importantes para la empresa. Muchas personas piensan que si determinada labor no se evala no tiene sentido ejecutarla. Aunque en teora cada tarea debe evaluarse y los resultados deben comunicarse al individuo que realiza la tarea, esto no siempre es prctico. Por ello lo mejor es realizar un examen de los diferentes procesos o actividades, segn el caso, e identificar aquellos que tienen mayor importancia dentro del proceso general y de esta manera sealar cules deben ser medidos. Otra forma de saber que medir, es la revisin del nivel de satisfaccin del cliente interno, centrndose en aquellas actividades que no satisfacen las expectativas del cliente. Una tercera forma de saber que medir, es conocer las actividades que requieren unos recursos significativos y a aquellas que proporcionan retroalimentacin solo sobre el desempeo del trabajo realizado por un individuo. Quien debe hacer las mediciones ? La persona que puede hacer mejor las mediciones, es aquella querealiza su propio proceso y debe hacerlo por que es a el a quien masle interesa como una oportunidad de encontrar en donde mejorar sudesempeo, utilizando de esta manera la informacin como unaretroal imentacin inmediata. Para una real evaluacin de los resultados se requiere mucho tiempo. Todas las evaluaciones demandan tiempo para revisar: la informacin arrojada, por ello es necesario que tenga el tiempo suficiente dentro del proceso que le permita analizar la informacin y realizar los correctivos que considere necesario. Atributos de la medicion

Son atributos de una buena medicin los siguientes: Pertinencia y precisin Oportunidad, Economa, Confiabilidad, Que observados a la luz de un producto, puesto que la medicin es un producto; son los mismos atributos exigidos a ellos. Pertinencia: se refiere a que las mediciones que se hagan, deben ser tomadas en cuenta y tener importancia en las decisiones que se toman con base en las mismas. Elgrado de pertinencia debe revisa-se peridicamente, ya que algo que sea muyimportante en un momento determinado, puede dejar de serlo en el transcurrir del tiempo. Precisin: se refiere al grado en que la medida obtenida refleja fielmente la magnitud del hecho que se quiere analizar o corroborar. Para lograr un buen grado de medicin deben llevarse a cabo algunos pasos como: Definir las caractersticas a medir, Escalas de medicin, Seleccin de muestras, Calculo de las estimaciones, Errores permisibles, Instrumental de medicin, Personal bien adiestrado tomadores de datos, y Equipos de informtica adecuados. Oportunidad: se refiere al logro de la medicin que permita tomar las decisiones ms adecuadas de correccin, restableciendo as la estabilidad del proceso deseada, bien sea para prevenir o para disear elementos que impidan que las caractersticas deseadas salgan fuera de los limites de control de tolerancia. Confiabilidad: se refiere al hecho de que la medicin en la empresa no es un acto que se haga una sola vez, por el contrario, es un acto repetitivo y de naturaleza generalmente peridica. Si se quiere estar seguros de lo que se mide sea la base adecuada para las decisiones que se toman, se debe revisar peridicamente todo el sistema. Economa: se refiere a los gastos de la medicin de tal manera que le permita ungran beneficio a unos costos dados

Mtricas de Software: Cuando pueda medir lo que est diciendo y expresarlo con nmeros, ya conoce algo sobre ello; cuando no pueda medir, cuando no pueda expresar lo que dice con nmeros, su conocimiento es precario y deficiente; puede

ser el comienzo del conocimiento, pero en tus pensamientos apenas ests avanzando hacia el escenario de la ciencia. Lord Kelvin Definiciones

Medida. Proporciona una indicacin cuantitativa de extensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de un proceso o producto. Pueden ser directas, p.e. nmero de lneas de cdigo, nmero de errores encontrados, etc., o pueden ser indirectas, p.e. funcionalidad, calidad, complejidad, etc. Medicin. Acto de determinar una medida. Mtrica. Es una medida cuantitativa del grado en que un sistema o proceso posee un atributo dado. Por lo general relaciona una o ms medidas, p.e. nmero de errores encontrados por cada mil lneas de cdigo. Indicador. Es una mtrica o combinacin de mtricas que proporcionan una visin del proceso, del proyecto o del software en s, y poder hacer ajustes para que las cosas mejoren.

Mtricas orientadas al tamao. Medidas

Lneas de cdigo (LOC). Esfuerzo en hombre-mes. Costo en pesos o dlares. Nmero de pginas de documentacin. Nmero de errores. Fallas detectadas antes de entregar el software al cliente. Nmero de defectos. Fallas detectadas despus de entregar el software al cliente. Nmero de personas en el proyecto.

Mtricas

Errores por KLOC (mil lneas de cdigo). Defectos por KLOC. Costo por KLOC.

Pginas de documentacin por KLOC. Errores por hombre-mes. LOC por hombre-mes. Costo por pgina de documentacin.

Ventajas

Son fciles de calcular. Muchos modelos de estimacin de software usan LOC o KLOC como datos de entrada. Existen un amplio conjunto de datos y literatura basados en LOC.

Desventajas

Son dependientes del lenguaje de programacin. Perjudica a los programas cortos pero bien diseados. Su uso en estimacin es dficil porque hay que estimar las LOC a producirse mucho antes de que se complete el anlisis y el diseo.

Mtricas orientadas a la funcin. La medida de punto de funcin se propuso en 1979 y trata de medir la funcionalidad o utilidad del software. Clculo del punto de funcin 1. Hay que completar la siguiente tabla de valores del dominio de la informacin:
Factor de ponderacin Parmetro Cuenta Simple Medio Complejo Nmero de entradas de usuario Nmero de salidas de usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces externas 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 Subtotal

Factor de ponderacin Parmetro Cuenta Simple Medio Complejo Total Subtotal

2. donde:
o

Entradas de usuario. Son entradas que proporcionan diferentes datos a la aplicacin. No confundirlos con las peticiones de usuario. Salidas de usuario. Son reportes, pantallas o mensajes de error que proporcionan informacin. Los elementos de un reporte, no se cuentan de forma separada. Peticiones de usuario. Es una entrada interactiva que produce la generacin de alguna respuesta del software en forma de salida interactiva. Archivos. Son los archivos que pueden ser parte de una base de datos o independientes. Interfaces externas. Son los archivos que se usan para transmitir informacin a otro sistema.

Indicaciones:
o o

Contar cada medida por separado. Asociar, de alguna manera, un valor de complejidad a cada medida. La siguiente tabla muestra una heurstica para decidir la complejidad de todo el sistema.
Tipos de archivos elementales 1-5 0-1 2-3 4+ bajo bajo medio 6-19 bajo medio alto datos

Tipos de referenciados

20+ medio alto alto

Para cada medida, multiplicar su cuenta por el factor de complejidad elegido y escribirlo en la columna de la extrema derecha.

Sumar la columna de la extrema derecha y obtener un total T que indica el valor del dominio de la informacin.

3. Responder a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial. 1. 2. 3. 4. 5. 6. Requiere el sistema copias de seguridad y de recuperacin fiables? Requiere comunicacin de datos? Existen funciones de procesamiento distribuido? Es crtico el rendimiento? Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? Requiere entrada de datos interactiva?

7. Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? 8. 9. 10. 11. 12. Se actualizan los archivos maestros de forma interactiva? Son complejas las entradas, las salidas, los archivos o las peticiones? Es complejo el procesamiento interno? Se ha diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la instalacin?

13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14. Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario? Sumar los puntos asignados a cada respuesta y obtener un total F que indica un valor de ajuste de complejidad. El punto de funcin FP se calcula con la siguiente ecuacin: PF = T * (0.65 + 0.01 * F). Mtricas
o

Errores por PF.

o o o o

Defectos por PF. Costo por PF. Pgina de documentacin por PF. PF por hombre-mes.

Mtricas ampliadas de punto de funcin. Los puntos de funcin fueron diseados originalmente para sistemas de informacin y por eso le da ms importancia a los datos y menos a los aspectos de control y funcionales. Para subsanar esto, se han propuesto los puntos de caracterstica y los puntos de funcin 3D. Puntos de caracterstica. Se calcula igual que el punto de funcin y solo agrega la cuenta de algoritmos. En este contexto se define un algoritmo como un problema de clculo limitado que se incluye dentro de un programa de computadora especfico. Invertir una matriz, decodificar un string o manejar una interrupcin son ejemplos de algoritmos. Puntos de funcin 3D. Los puntos de funcin 3D se calculan llenando la siguiente tabla:
Pesos de complejidad Elemento de medicin Bajo Estructuras internas de datos Datos externos Nmero de entradas de usuario Nmero de salidas de usuario Nmero de peticiones de usuario Transformaciones Transiciones Punto de funcin 3D * 7 + * 5 + * 3 + * 4 + * 3 + * 7 + + Medio * 10 + * 7 * 4 * 5 * 4 + + + + Alto * 15 = * 10 = * 6 * 7 * 6 = = = Subtotal

* 10 + +

* 15 = =

donde:

o o

Estructuras internas de datos. Son arreglos, listas ligadas, pilas, colas, etc. Datos externos. Equivale a la suma de los archivos y las interfaces externas tal y como estn definidos para el punto de funcin. Entradas de usuario. Definidas igual que para el punto de funcin. Salidas de usuario. Definidas igual que para el punto de funcin. Peticiones de usuario. Definidas igual que para el punto de funcin. Transformaciones. Son las operaciones internas requeridas para transformar datos de entrada en datos de salida. Multiplicar dos matrices cuenta como una transformacin. Leer datos de un archivo y guardarlos en memoria no. Transiciones. Ocurre cuando el software pasa de un estado a otro como resultado de algn suceso. En un sistema de altas, bajas y cambios, al tomar la opcin de altas, pasa del estado "men principal" al estado "procesa altas" y puede ser que en ese momento pida datos para dar la alta.

o o o o

Indicaciones:
o

Para cada medida, contar por separado, de acuerdo a algn criterio de asignacin de complejidad, las veces que aparezca con complejidad baja, media y alta. Para cada medida, multiplicar cada cuenta por el factor de complejidad correspondiente, sumar las tres cantidades y escribir el total en la columna de la extrema derecha. Sumar la columna de la extrema derecha y obtener el punto de funcin 3D.

Funcionalidad de los lenguajes de programacin La tabla siguiente proporcional estimaciones informales del nmero de lneas de cdigo que se necesitan para construir un punto de funcin en varios lenguajes de programacin:
Lenguaje Ensamblador C Cobol LOC/PF 320 128 105

Lenguaje Fortran Pascal Ada OOL 4GL Generadores de cdigo Hojas de clculo Lenguajes de conos

LOC/PF 105 90 70 30 20 15 6 4

Observando la tabla podemos decir que, en promedio, un programa en ensamblador tendr 320/128 = 2.5 veces ms lneas de cdigo que un programa en C que haga lo mismo, y casi 11 veces ms que un lenguaje orientado a objetos (OOL) con la misma funcionalidad. Medidas de calidad de Gilb.
o

Correcin. Es el grado en el que el software lleva a cabo su funcin requerida. Se mide en defectos por KLOC. Facilidad de mantenimiento. Es la facilidad con que se puede corregir un programa si se encuentra un error, adaptar si su medio ambiente cambia o mejorar si el cliente desea un cambio de requisitos. Se mide en Tiempo Medio de Cambios (TMC), que es el tiempo que se lleva desde analizar la peticin hasta distribuir el cambio a los usuarios. Integridad. Mide la habilidad de un sistema de resistir ataques. Se calcula aplicando la frmula: 1 - amenaza * (1 - seguridad)

Para cada tipo de ataque, y donde amenaza se define como la probabilidad de que ocurra ese ataque y seguridad como la probabilidad que ese ataque sea rechazado.
o

Facilidad de uso. Mide que tan amigable es el sistema con el usuario en funcin de cuatro caractersticas:

Habilidad intelectual y/o fsica para aprender a usarlo. Tiempo requerido para ser moderadamente eficiente al usarlo. Aumento neto de productividad, comparado con el sistema que reemplaza. Valoracin subjetiva de la disposicin de los usuarios hacia el sistema.

Eficacia de la Eliminacin de defectos (EED) EED = E / (E + D) donde: E es el nmero de errores (fallas detectadas antes de entregar el sistema al usuario por primera vez) D es el nmero de defectos (fallas detectadas despus de entregar el sistema al usuario por primera vez)