Calidad en el Desarrollo de Software

Calidad: Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor. Adecuación de un producto o servicio a las características especificadas en un contrato.

Norma: Regla que se debe seguir o a que se deben ajustar las conductas, tareas, actividades, etc. En calidad de software las normas son documentos que especifican requerimientos que pueden ser empleados en organizaciones para garantizar que los productos y/o servicios ofrecios por dichas organizaciones cumplan con su objetivo.

Estándar: Que sirve como tipo, modelo, norma, patrón o referencia. En calidad de software los estándares son acuerdos documentados que contienen especificaciones técnicas u otros criterios percisos para ser usados consistentemente como reglas, guías o definiciones de características para asegurar que los materiales, productos, procesos y servicios cumplan con su propósito.

Proceso: Conjunto de fases sucesivas que conducen a un final. Estas fases se llevan acabo con orden, dependencias, roles, responsabilidades, resultados, tiempos de ejecución y herramientas de apoyo. Hay procesos que pueden predefinirse o personalizarse.

Modelo: Conjunto de buenas prácticas para el ciclo de vida del software, enfocado en los procesos de gestión y desarrollo de proyectos.

Institutos que regulan la calidad:

• ISO: Organización Internacional de Normalización
• IEC: Comisión Electrotécnica Internacional
• IEEE: Instituto de Ingenieros Eléctricos y Electrónicos
• BSI: British Standards Institution
• NOM: Normas Oficiales Mexicanas

• Estética: Apariencia sensorial
• Conformidad: con estándares
• Durabilidad: vida prevista (en tiempo de uso)
• Desempeño: Características esenciales que pueden ser medidas (consumo, potencia, aceleración, etc.)
• Confiabilidad: Probabilidad de que el producto no falle o funcione bien durante un período de tiempo.
• Servicio: Rapidez, atención, facilidad de reparación.
• Calidad percibida: Durante el uso en contextos específicos.

• Operación del producto
  1. Corrección: ¿Hace el software lo que yo quiero?
  2. Confiabilidad: ¿Lo hace de forma exacta todo el tiempo?
  3. Usabilidad: ¿Puedo ejecutarlo?
  4. Integridad: ¿Es seguro?
  5. Eficiencia: ¿Se ejecutará sobre mi hardware lo mejor posible?
• Revisión del producto
  1. Facilidad de recibir mantenimiento: ¿Puedo arreglarlo?
  2. Flexibilidad: ¿Puedo modificarlo?
  3. Susceptibilidad de someterse a pruebas: ¿Puedo probarlo?
• Transición del producto
  1. Portabilidad: ¿Puedo utilizarlo en otra máquina?
  2. Reusabilidad: ¿Puedo reutilizar parte del software?
  3. Interoperabilidad: ¿Puedo comunicarlo con otro sistema?

Las métricas de Proyecto se consolidan para crear métricas de proceso que sean públicas para toda la organización del software. El uso de métricas para el Proyecto tiene 2 aspectos fundamentales:

1. Minimizar la planificación del desarrollo haciendo los ajustes necesarios que eviten retrasos y reducir problemas/riesgos potenciales.
2. Evaluar la calidad de los productos en el momento actual y cuando sea necesario, modificando el enfoque técnico que mejore la calidad.

1. Evaluar el estado del proyecto.
2. Seguir la pista de los riesgos potenciales.
3. Detectar las áreas de problemas antes de que se conviertan en “críticas”.
4. Ajustar el flujo y las tareas del trabajo.
5. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software.

Las métricas del Proceso se recopilan de todos los proyectos y durante un largo período de tiempo. Su intento es proporcionar indicadores que lleven a mejorar los procesos de software a largo plazo. Se tendrán métricas asociadas a cada proceso del software (p.e. métricas de implementación). Estos indicadores de proceso permiten que una organización de Ingeniería de Software pueda tener una visión más profunda de la eficacia de un proceso ya existente y permiten que los gestores evalúen lo que funciona y lo que no.

En realidad, las medidas que recopila un equipo de proyecto y las convierte en métricas para utilizarse durante un proyecto, también pueden trasmitirse a los que tienen la responsabilidad de mejorar el proceso de software. Por esta razón, se utilizan muchas de las mismas métricas tanto en el dominio del proceso como en el del proyecto.

La única forma racional de mejorar cualquier proceso es medir atributos del proceso, desarrollar un juego de métricas significativas según estos atributos y utilizar las métricas para proporcionar indicadores que conducirán a una estrategia de mejora.

Las métricas del proceso se caracterizan por:

1. El control y ejecución del proyecto.
2. Medición de tiempos del análisis, diseño, implementación, implantación y post-implantación.
3. Medición de las pruebas (errores, cubrimiento, resultado en número de defectos y número de éxito).
4. Medición de la transformación o evolución del producto.

Las métricas de Producto son privadas para un individuo y a menudo se combinan para desarrollar métricas del proyecto que sean públicas para un equipo de software. Están enfocadas a predecir y controlar:

1. El tamaño (líneas de código, bytes de código, operadores y operandos).
2. La estructura (control de flujo, relación entre componentes, cohesión y acoplamiento).
3. La complejidad (combinación de tamaño y estructura).
4. Los índices para controlar la documentación.
5. La calidad (independencia, completo, entendible, aumentado).
6. La estabilidad (los cambios aumentan el número de fallas, los cambios se pueden dar por definición de requerimientos o por cambios del entorno).

1. Simple y fácil de calcular.
2. Empírica e intuitivamente persuasiva: Debe satisfacer las nociones intuitivas del desarrollador sobre el atributo del producto en evaluación.
3. Consistente y objetiva: Presentar resultados sin ambigüedad.
4. Consistente en el empleo de unidades y tamaños: Deben emplearse medidas que no conduzcan a extrañas combinaciones de unidades.
5. Independiente del lenguaje de programación.
6. Mecanismo para retroalimentación de calidad: Debe proporcionar información para obtener un producto final de mayor calidad.

1. Costo de la calidad: es una medida del desempeño de las iniciativas de calidad en una organización. Se expresa en términos monetarios.
   Costo de calidad = (revisión + prueba + revisión de verificación + prueba de verificación + QA + gestión de configuración + medición + capacitación + revisión de revisión + prueba de revisión) / esfuerzo total x 100.
2. Costo de mala calidad: es el costo de implementar procesos y productos imperfectos.
   Costo de mala calidad = esfuerzo de retrabajo / esfuerzo total x 100.
3. Densidad de defectos: es el número de defectos detectados en el software durante el desarrollo dividido por el tamaño del software (generalmente en KLOC o FP)
   Densidad de defectos para un proyecto = Número total de defectos / tamaño del proyecto en KLOC o FP
4. Eficiencia de revisión: definida como la eficiencia en el aprovechamiento / detección de defectos de revisión en la etapa de verificación.
   Eficiencia de revisión = (número de defectos detectados en la revisión) / número total de defectos detectados) x 100.
5. Eficiencia de prueba: Eficiencia de prueba = 1 - ((defectos encontrados en la aceptación) / número total de defectos de prueba) x 100.
6. Eficiencia de eliminación de defectos: cuantifica la eficiencia con la que se detectaron defectos y se impidió que llegaran al cliente.
   Eficiencia de eliminación de defectos = (1 - (defectos totales detectados por el cliente / número total de defectos)) x 100.
7. Densidad del defecto residual = (número total de defectos encontrados por un cliente) / (Número total de defectos incluyendo defectos encontrados por el cliente) x 100.

1. Variación de programación: cualquier diferencia entre la finalización programada de una actividad y la finalización real se conoce como Variación de programación.
   Variación de programación = ((Días calendario reales - Días calendario planificados) + Variación de inicio) / Días calendario planificados x 100.
2. Variación de esfuerzo: la diferencia entre el esfuerzo planificado y el esfuerzo requerido para emprender realmente la tarea se llama variación de esfuerzo.
   Variación de esfuerzo = (esfuerzo real - esfuerzo planificado) / esfuerzo planificado x 100.
3. Variación de tamaño: diferencia entre el tamaño estimado del proyecto y el tamaño real del proyecto (normalmente en KLOC o FP).
   Variación de tamaño = (Tamaño real - Tamaño estimado) / Tamaño estimado x 100.
4. Índice de estabilidad de requisitos: proporciona visibilidad de la magnitud y el impacto de los cambios de requisitos.
   RSI = 1- ((Número de cambios + Número de borrados + Número de agregados) / Número total de requisitos iniciales) x100.
5. Productividad (Proyecto): es una medida de salida de un proceso relacionado para una unidad de entrada.
   Productividad del proyecto = Tamaño real del proyecto / Esfuerzo real gastado en el proyecto.
6. Productividad (para la preparación de casos de prueba) = Número real de casos de prueba / Esfuerzo real gastado en la preparación de casos de prueba.
7. Productividad (para la ejecución de casos de prueba) = Número real de casos de prueba / esfuerzo real gastado en las pruebas.
8. Productividad (detección de defectos) = Número real de defectos (revisión + prueba) / esfuerzo real gastado en (revisión + prueba).
9. Productividad (fijación de defectos) = número real de defectos reparados / esfuerzo real dedicado a la fijación de defectos.
10. Variación del cronograma para una fase: la desviación entre cronogramas planificados y reales para las fases dentro de un proyecto.
    Variación programada para una fase = (días calendario reales para una fase - días calendario planificados para una fase + variación inicial para una fase) / (días calendario planificados para una fase) x 100
11. Variación de esfuerzo para una fase: la desviación entre un esfuerzo planificado y real para varias fases dentro del proyecto.
    Variación de esfuerzo para una fase = (esfuerzo real para una fase - un esfuerzo planificado para una fase) / (esfuerzo planificado para una fase) x 100.

1. Tasa de descubrimiento de errores: Es para determinar la efectividad de los casos de prueba.
   Fórmula: Error Discovery Rate = (Total number of defects found /Total no. of test cases executed)*100
   P.ej:
   • No total de casos de prueba ejecutados = 240
   • Número total de defectos encontrados = 60
   • Tasa de descubrimiento de errores = (60/240) * 100 = 25%
2. Tasa de corrección de defectos: Ayuda a conocer la calidad de una construcción en términos de reparación de defectos.
   Fórmula: Defect Fix Rate = (Total no of Defects reported as fixed - Total no. of defects reopened) / (Total no of Defects reported as fixed + Total no. of new Bugs due to fix)*100
   P.ej:
   • No total de defectos notificados como fijos = 10
   • No total de defectos reabiertos = 2
   • No total de nuevos errores debido a la corrección = 1
   • Tasa de corrección de defectos = ((10 - 2) / (10 + 1)) * 100 = (8/11) 100 = 72.7 = 73%
3. Densidad del defecto: Se define como la relación de defectos a requisitos. La densidad del defecto determina la estabilidad de la aplicación.
   Fórmula: Defect Density = Total no. of defects identified / Actual Size (requirements) P.ej:
   • No total de defectos identificados = 80
   • Tamaño real = 10
   • Densidad del defecto = 80/10 = 8
4. Fugas de defectos: Se utiliza para revisar la eficiencia del proceso de prueba antes de UAT.
   Fórmula: Defect Leakage = ((Total no. of defects found in UAT)/(Total no. of defects found before UAT)) * 100
   P.ej:
   • Número de defectos encontrados en UAT = 20
   • Número de defectos encontrados antes de UAT = 120
   • Fugas de defectos = (20/120) * 100 = 16.6 = 17%
5. Eficiencia de eliminación de defectos: Nos permite comparar la eficiencia general de eliminación de defectos (defectos encontrados antes y después de la entrega)
   Fórmula: Defect Removal Efficiency = ((Total no. of defects found pre-delivery) /( (Total no. of defects found pre-delivery )+ (Total no. of defects found post-delivery)))* 100
   P.ej:
   • No total de defectos encontrados pre-entrega = 80
   • No total de defectos encontrados después de la entrega = 10
   • Eficiencia de eliminación de defectos = ((80) / ((80) + (10))) * 100 = (80/90) * 100 = 88.8 = 89%

INDICACIONES: Da clic aquí para conocer las definiciones, principios, objetivos, historia y elementos del Proceso Personal de Software (PSP)

INDICACIONES: En un documento word, responde las siguientes preguntas:

1. ¿Qué es PSP?, Descripción
2. ¿Qué instituto lo regula?
3. ¿Cuáles son sus objetivos?
4. ¿Cuáles son sus principios?
5. Describir los tres niveles
6. Describir sus elementos

Da clic aquí para conocer más sobre los niveles del PSP

En el siguiente enlace encontrarás un documento que contiene las plantillas de PSP.

INDICACIONES: Elabora en excel una bitácora donde registres cada una de las plantillas del enlace. La bitácora deberá incluir un número de plantilla, nombre de la plantilla, descripción de la plantilla y puntos importantes.

INDICACIONES: Responde en un documento word las siguientes preguntas relacionadas con la revisión técnica informal y formal en los procesos de desarrollo de software. Libro de ingeniería del software, un enfoque práctico.

1. ¿Cuál es el objetivo de las técnicas de revisión de procesos de software?
2. ¿Cuáles son las revisiones informales de los procesos de software?
3. ¿Cuáles son las revisiones técnicas formales de los procesos de software?
4. ¿Qué es RTF?
5. ¿Cuáles son las restricciones que un RTF debe cumplir en la reunión de revisión?
6. ¿Cuáles son las tres preguntas a las qué responde el resumen final de la reunión y la lista de pendientes de la revisión?
7. ¿Quién es el revisor?
8. ¿Cuáles son los lineamientos para la revisión técnica formal?

INDICACIONES: Elabora en excel una bitácora donde registres cada una de las plantillas del enlace. La bitácora deberá incluir un número de plantilla, nombre de la plantilla, descripción de la plantilla y puntos importantes.

INDICACIONES: Elabora una presentación en donde describas las técnicas existentes para la estimación de software. Favor de agregar una técnica por cada diapositiva, con una breve descripción e ilustraciones. Da clic en este enlace para conocer sobre las técnicas de estimación.

INDICACIONES: De los modelos que vienen en el siguiente documento, elabora una presentación para la siguiente clase en donde describas el modelo, sus principales características, su función, ilustraciones, roles, actividades, etc. Da clic aquí para acceder al enlace.

INDICACIONES: Da clic en el siguiente enlace para conocer las etapas para estimar un proyecto de software

INDICACIONES: En equipos de dos, elaboren una historieta sobre el caso de estudio de la "estimación como una herramienta" en donde se presente la idea principal del caso de estudio y donde se vaya redactado a manera de desarrollo: la terminología, el escenario, la idea principal, el origen del caso, el desarrollo del caso, la conclusión del caso, el conocimiento aprendido del caso.

INDICACIONES: Elabora una estimación de tiempo y costo mediante un diagrama gantt utilizando GanttPRO, en donde describas la siguiente información:

• Tareas
• Asignado (Personal)
• Fechas (Inicio/Termino)
• Duración (en días)
• Estimación (en horas)
• Costo
• Recursos

El aseguramiento de la calidad del software incluye un rango amplio de preocupaciones y actividades que se centran en la administración de la calidad del software. Éstas se resumen a continuación:

• Estándares. El IEEE, ISO y otras organizaciones que establecen estándares han producido una amplia variedad de ellos para ingeniería de software y documentos relacionados. Los estándares los adopta de manera voluntaria una organización de software o los impone el cliente u otros participantes. El trabajo del ACS es asegurar que los estándares que se hayan adoptado se sigan, y que todos los productos del trabajo se apeguen a ellos.
• Revisiones y auditorías. Las revisiones técnicas son una actividad del control de calidad que realizan ingenieros de software para otros ingenieros de software. Su objetivo es detectar errores. Las auditorías son un tipo de revisión efectuada por personal de ACS con objeto de garantizar que se sigan los lineamientos de calidad en el trabajo de la ingeniería de software. Por ejemplo, una auditoría del proceso de revisión se efectúa para asegurar que las revisiones se lleven a cabo de manera que tengan la máxima probabilidad de descubrir errores.
• Pruebas. Las pruebas del software son una función del control de calidad que tiene un objetivo principal: detectar errores. El trabajo del ACS es garantizar que las pruebas se planeen en forma apropiada y que se realicen con eficiencia, de modo que la probabilidad de que logren su objetivo principal sea máxima.
• Colección y análisis de los errores. La única manera de mejorar es medir cómo se está haciendo algo. El ACS reúne y analiza errores y datos acerca de los defectos para entender mejor cómo se cometen los errores y qué actividades de la ingeniería de software son más apropiadas para eliminarlos.
• Administración del cambio. El cambio es uno de los aspectos que más irrumpe en cualquier proyecto de software. Si no se administra en forma adecuada, lleva a la confusión y ésta casi siempre genera mala calidad. El ACS asegura que se hayan instituido prácticas adecuadas de administración del cambio

• Educación. Toda organización de software quiere mejorar sus prácticas de ingeniería de software. Un contribuyente clave de la mejora es la educación de los ingenieros de software, de sus gerentes y de otros participantes. La organización de ACS lleva el liderazgo en la mejora del proceso de software y es clave para proponer y patrocinar programas educativos.
• Administración de los proveedores. Son tres las categorías de software que se adquieren a proveedores externos: paquetes contenidos en una caja (por ejemplo, Office, de Microsoft); un shell personalizado, que da una estructura básica, tipo esqueleto, que se adapta de manera única a las necesidades del comprador; y software contratado, que se diseña y construye especialmente a partir de especificaciones provistas por la organización cliente. El trabajo de la organización de ACS es garantizar que se obtenga software de alta calidad a partir de las sugerencias de prácticas específicas de calidad que el proveedor debe seguir (cuando sea posible) y de la incorporación de cláusulas de calidad como parte de cualquier contrato con un proveedor externo.
• Administración de la seguridad. Con el aumento de los delitos cibernéticos y de las nuevas regulaciones gubernamentales respecto de la privacidad, toda organización de software debe instituir políticas para proteger los datos en todos los niveles, establecer cortafuegos de protección para las webapps y asegurar que el software no va a ser vulnerado internamente. El ACS garantiza que para lograr la seguridad del software, se utilicen el proceso y la tecnología apropiados.
• Seguridad. Debido a que el software casi siempre es un componente crucial de los sistemas humanos (como aplicaciones automotrices o aeronáuticas), la consecuencia de defectos ocultos puede ser catastrófica. El ACS es responsable de evaluar el efecto de las fallas del software y de dar los pasos que se requieren para disminuir el riesgo.
• Administración de riesgos. Aunque el análisis y la mitigación de riesgos es asunto de los ingenieros de software, la organización del ACS garantiza que las actividades de administración de riesgos se efectúen en forma apropiada y que se establezcan planes de contingencia relacionados con los riesgos.

INDICACIONES:

El aseguramiento de la calidad del software se compone de varias tareas asociadas con dos entidades diferentes: los ingenieros de software que hacen el trabajo técnico y un grupo de ACS que tiene la responsabilidad de planear, supervisar, registrar, analizar y hacer reportes acerca de la calidad. Los ingenieros de software abordan la calidad (y ejecutan actividades para controlarla), aplicando métodos y medidas técnicas sólidos, realizando revisiones técnicas y haciendo pruebas de software bien planeadas.

El objetivo del grupo de ACS es auxiliar al equipo del software para lograr un producto final de alta calidad. El Instituto de Ingeniería de Software recomienda un conjunto de acciones de ACS que se dirigen a la planeación, supervisión, registro, análisis y elaboración de reportes para el aseguramiento de la calidad. Estas acciones son realizadas (o facilitadas) por un grupo independiente de ACS que hace lo siguiente:

1. Prepara el plan de ACS para un proyecto. El plan se desarrolla como parte de la preparación del proyecto y es revisado por todos los participantes. Las acciones de aseguramiento de la calidad efectuadas por el equipo de ingeniería de software y por el grupo de ACS son dirigidas por el plan. Éste identifica las evaluaciones que se van a realizar, las auditorías y revisiones por efectuar, los estándares aplicables al proyecto, los procedimientos para reportar y dar seguimiento a los errores, los productos del trabajo que genera el grupo de ACS y la retroalimentación que se dará al equipo del software.
2. Participa en el desarrollo de la descripción del software del proyecto. El equipo de software selecciona un proceso para el trabajo que se va a realizar. El grupo de ACS revisa la descripción del proceso a fin de cumplir con la política organizacional, los estándares internos para el software, los estándares impuestos desde el exterior (como la norma ISO-9001) y otras partes del plan del proyecto de software.
3. Revisa las actividades de la ingeniería de software a fin de verificar el cumplimiento mediante el proceso definido para el software. El grupo de ACS identifica, documenta y da seguimiento a las desviaciones del proceso y verifica que se hayan hecho las correcciones pertinentes.
4. Audita los productos del trabajo de software designados para verificar que se cumpla con aquellos definidos como parte del proceso de software. El grupo de ACS revisa productos del trabajo seleccionados; identifica, documenta y da seguimiento a las desviaciones; verifica que se hayan hecho las correcciones necesarias y reporta periódicamente los resultados de su trabajo al gerente del proyecto.
5. Asegura que las desviaciones en el trabajo de software y sus productos se documenten y manejen de acuerdo con un procedimiento documentado. Las desviaciones pueden encontrarse en el plan del proyecto, la descripción del proceso, los estándares aplicables o los productos del trabajo de la ingeniería de software.
6. Registra toda falta de cumplimiento y la reporta a la alta dirección. Se da seguimiento a los incumplimientos hasta que son resueltos.

Las acciones de ACS descritas en la sección anterior se realizan con objeto de alcanzar un conjunto de metas pragmáticas:

1. Calidad de los requerimientos. La corrección, completitud y consistencia del modelo de requerimientos tendrá una gran influencia en la calidad de todos los productos del trabajo que sigan. El ACS debe garantizar que el equipo de software ha revisado en forma apropiada el modelo de requerimientos a fin de alcanzar un alto nivel de calidad.
2. Calidad del diseño. Todo elemento del modelo del diseño debe ser evaluado por el equipo del software para asegurar que tenga alta calidad y que el diseño en sí se apegue a los requerimientos. El ACS busca atributos del diseño que sean indicadores de la calidad.
3. Calidad del código. El código fuente y los productos del trabajo relacionados (por ejemplo, otra información descriptiva) deben apegarse a los estándares locales de codificación y tener características que faciliten darle mantenimiento. El ACS debe identificar aquellos atributos que permitan hacer un análisis razonable de la calidad del código.
4. Eficacia del control de calidad. Un equipo de software debe aplicar recursos limitados, en forma tal que tenga la máxima probabilidad de lograr un resultado de alta calidad. El ACS analiza la asignación de recursos para las revisiones y pruebas a fin de evaluar si se asignan en la forma más eficaz.

Descarga la siguiente presentación para conocer sobre las normas de ISO. Da clic aquí para descargar la presentación.

Da clic en el siguiente enlace para conocer sobre Moprosoft.

Da clic en el siguiente enlace para conocer sobre CMMI.

El examen se presenta el día miércoles 4 de diciembre.