Unidad 1 Apuntes

UNIDAD 1

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE El aseguramiento de la calidad de SW es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza adecuada en que el producto logrará satisfacer los requisitos dados de calidad. El aseguramiento de la calidad se enfoca en identificar y evaluar los defectos que pueden afectar al SW. Si los errores se pueden identificar de forma temprana en el proceso del SW, las características de diseño se pueden especificar de modo que eliminarán o controlarán los peligros potenciales, al corregir los errores mucho antes en cada etapa, es decir durante el proceso, ahorrando tiempo, esfuerzo y recursos. Hay 3 aspectos importantes con relación al aseguramiento de la calidad del SW. -

La calidad se construye. El aseguramiento de la calidad no es una tarea que se realiza en una fase particular del ciclo de vida de desarrollo. Las actividades asociadas con el aseguramiento de la calidad del software deben ser realizadas por personas que no estén involucradas en el esfuerzo de desarrollo.

SQA comprende una gran variedad de tareas: -

Participación en la descripción de SW. Auditar el producto para verificar el cumplimiento del proceso definido. Asegurar que las divergencias en el trabajo de SW sean documentadas de acuerdo a los estándares definidos. Almacenar cualquier inconformidad y reportarla a la gerencia media. Las revisiones del proyecto se realizan durante cada paso del desarrollo del mismo. Gestiones de configuraciones de SW.

RELACIÓN DE LA ING. DE SW CON SQA La ingeniería del SW es el establecimiento y uso de principios sólidos de la Ing. para obtener económicamente un SW confiable y que funciones de modo eficiente. Es la aplicación de u enfoque sistemático, disciplinado y cuantificable al desarrollo del SW. DESARROLLO DE SW.

Pequeña escala No precisa, no requiere Ingeniería. Proceso simple Modelado Mínimo Puede hacerlo una persona. Bajo costo Desarrollo artesanal

Gran escala Necesidad de la Ingeniería. Proceso complejo Modelado y diseño Equipo de trabajo Costo elevado Gestión de proyecto

PERSPECTIVA HISTÓRICA DEL DESARROLLO DE SW Década 50 – 60 60 – 70 70 – 80 90 – Actual

SW como añadido. Desarrollo artesanal, lenguaje de bajo nivel. SW como producto. Lenguajes compiladores. SGBD, SO POO, programación visual, tecnología CASE, métodos ágiles, reutilización, interoperabilidad, web. SOA (Arq. orientada a servicios).

PROBLEMÁTICA ACTUAL DEL SW. -

Incapacidad para estimar tiempo, costo y esfuerzo. Falta de calidad. Avance del HW. Necesidades más complejas.

DEFINICIÓN Y PROPÓSITO DE SQA. SQA es un conjunto de actividades sistemáticas y planeadas para asegurar que los procesos y productos de SW cumplen con los requerimientos, estándares y procedimientos. PROCESOS Diseño Codificación Test Mantenimiento

PRODUCTOS SW Documentación Soporte

PROPÓSITO DE SQA Proporcionar visibilidad sobre procesos utilizados por el proyecto de SW y sobre los productos que genera. Objetivos 1. Planificar las actividades de aseguramiento de la calidad.

2. Revisar y auditar objetivamente los productos y las actividades para verificar que estén conformes con los procedimientos y estándares. 3. Proporcionar los resultados de estas revisiones o auditorías informando a la dirección. EL GRUPO ENCARGADO DE SQA. -

Trabaja con el equipo del proyecto desde el inicio. Debe ser objetivo e independiente. Ayuda al proyecto, más que controlar sus actividades.

La actividad de SQA es el proceso de verificación de que los estándares sean aplicados correctamente. En los proyectos pequeños esto se puede realizar por el equipo de desarrollo, pero en proyectos grandes, un grupo específico se debe dedicar a este rol. PROBLEMAS QUE RESUELVE SQA Obtener un SW de calidad. La obtención de un software de calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del SW que permitan uniformar la filosofía de trabajo. La adopción de una buena política o metodología contribuye en gran medida a lograr la calidad del SW pero no la asegura. Esta política debe estar sustentada en 3 principios básicos. 1) Tecnológico: Define las técnicas a utilizar en el proceso de desarrollo de SW. 2) Administrativo: Contempla las funciones de planificación y control del desarrollo de SW, así como la organización del ambiente o centro de ingeniería del SW. 3) Ergonómico: define la interfaz entre el usuario y el ambiente automatizado. Para controlar la calidad del SW, es necesario definir los parámetros, indicadores o criterios de medición. Las cualidades para medir la calidad del SW se definen en 2 categorías: -

Complejidad de programa o código. Complejidad de sistema o estructura.

Por lo tanto, SQA resuelve problemas como: -

Aumentar las posibilidades de éxito del proyecto. Funcionalidad. Cumplimiento. Usable.

Ayuda a definir parámetros de medición de la calidad del SW. Verifica que los estándares sean aplicados correctamente. Define un plan de monitoreo del proceso de desarrollo de SW (ciclo de vida). PLAN DE SQA (SQAP) El plan de aseguramiento de la calidad del SW (SQAP) define las actividades específicas a llevar a cabo en un proyecto. El SQAP contiene una lista de comprobación para las actividades que se deben llevar a cabo para asegurar la calidad del producto. En el SQAP se recogen una serie de medidas que permiten establecer el nivel de calidad de los desarrollos en cualquier momento en relación a los parámetros de calidad establecidos en el mismo, de modo que los gestores de proyecto puedan dar respuesta adecuada a las acciones a tomar de acuerdo a las medidas que se recogen en el plan. El SQAP CONTIENE: -

Propósito de plan. Documentación de referencia. Ciclo de vida. Gestión del proyecto. Documentación del proyecto. Estándares. Métricas. Mecanismos de revisión. Gestión de la configuración. Control de versiones. Entornos de desarrollo. Entornos de pruebas. Herramientas, técnicas y metodologías empleadas. Control de suministro de proveedores (si los hay). Políticas de almacenamiento, mantenimiento y conservación de documentación. Plan de pruebas.

CALIDAD DEL SW EN EL CICLO DE VIDA A lo largo de los años se han construido un conjunto de metodologías, técnicas, estándares y prácticas orientadas a la calidad, tanto del proceso de desarrollo de SW, como los resultados del mismo. A pesar de la indudable evolución y mejora de dichos procesos y de la calidad del desarrollo del SW, la realidad es que los resultados dejan mucho que desear.

Una de las causas finales que se señala frecuentemente cuando se analiza este problema es que la calidad real del SW resulta “invisible”. Es muy fácil de medir, de identificar los puntos “rojos” que requieren cambios en la forma de trabajo y de extraer recomendaciones prácticas para su introducción a lo largo del ciclo de vida de desarrollo y no al final de las pruebas de aceptación, cuando normalmente ya es demasiado tarde para hacer algo y el costo correctivo es elevado. Actualmente, los equipos de desarrollo no cuentan con un espectro completo y consistente de herramientas que permitan extraer información útil de código fuente y entregables asociados, de otros productos de la actividad del equipo o de medidas obtenidas de las propias actividades de desarrollo. El SQA añade transparencia al ciclo de desarrollo, capturando, integrando y procesando de forma automática las métricas extraídas de distintas herramientas y sistemas externos (analizadores, gestores de defectos, sistemas de control de versiones, herramientas de prueba, etc). Estas herramientas siguen un modelo de métricas en el que se integran medidas obtenidas automáticamente del proceso de desarrollo (actividades, requisitos, defectos y cambios) y de los elementos analizables de SW (código fuente, documentación del proyecto, scripts de construcción y scripts de pruebas). EL EQUIPO O GRUPO DE SQA El equipo de SQA trabaja con la gerencia de proyectos durante los inicios del desarrollo para establecer los planes, estándares y los procedimientos que agregarán valor al proyecto de SW y satisfacer los problemas del proyecto y de las políticas de la organización. Participa en establecer los planes, estándares y procedimientos. El equipo ayuda a asegurar que se cumplan con las necesidades del proyecto y verifica que sean usables para realizar revisiones e intervenciones durante todo el ciclo de vida. Las revisiones del grupo de SQA proyectan las actividades y revisan el producto de trabajo de SW, además de proveer a la gerencia la posibilidad de saber si el proyecto está de acuerdo a los planes estándares y procedimientos establecidos. ROLES Y RESPONSABILIDADES Humpre en su libro “Team Software Process” proporciona un marco de trabajo que se construye sobre la base del “Personal Software Process” con fases de desarrollo bien definidas, los productos de SW se generan en varios ciclos, se establecen medidas estándares para la calidad del producto y para el desempeño de los equipos y de los desarrolladores, se aplican evaluaciones por rol y del equipo.

TSP ayuda a la conformación de equipos de trabajo bien organizados a través de roles, cada rol está definido por un guión en el que se especifican su objetivo, sus responsabilidades en todo el ciclo de desarrollo y la forma en que se puede evaluar su trabajo. Los roles propuestos son: 1) Líder de proyecto: - Objetivo: Coordinar al equipo, asegurar que todos cumplan con su trabajo (reportes de datos). - Responsabilidades: Metas, generar informes, dirigir reuniones, motivar al equipo. 2) Administrador de desarrollo - Objetivo: controlar avance del proyecto (diseño, desarrollo). - Responsabilidad: dirigir la realización de las fases siguiendo los estándares propuestos. Integrar el trabajo de todos. 3) Administrador de la planificación - Objetivo: Establecer el plan de trabajo y verificar su cumplimiento. - Responsabilidades: Efectuar la planificación, asegurarse que se cumplan con el plan, recabar mediciones, resolver riesgos. 4) Administrador de apoyo - Objetivo: Ayudar al equipo a conseguir las herramientas necesarias para que pueda realizar el trabajo, Gestionar la configuración. - Responsabilidad: Conseguir lo necesario para el desarrollo del proyecto, generar un plan de configuración, realizar la gestión de la configuración. 5) Administrador de calidad y proceso: - Objetivo: Proponer un plan de calidad, proceso, resultado. - Responsabilidades: Apoyar al equipo en la definición, gestionar el plan de calidad (SQA), generar estándares para obtener un trabajo uniforme, moderar las revisiones de los productos. ACTIVIDADES DEL GRUPO DE SQA La garantía de calidad de SW comprende una gran variedad de tareas diferentes, los ingenieros de SW que realizan el trabajo técnico y un grupo de SQA que tiene la responsabilidad de la planificación de la garantía de la calidad, supervisión, mantenimiento de registros, análisis e informes. Los ingenieros de SW afrontan la calidad aplicando métodos técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de SW bien planificadas. Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del SW en la consecución de un producto final de alta calidad. El instituto de ingeniería del software recomienda el siguiente conjunto de actividades:

1) Establecimiento de un plan de SQA para el proyecto. El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas. 2) Participación en el desarrollo de la descripción del proceso de SW del proyecto. El equipo de ingeniería de SW selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa, los estándares (internos y externos) del SW y las demás partes del plan. 3) Revisión de las actividades de ingeniería del SW para verificar su ajuste al proceso de SW definido. El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se hayan realizado las correcciones. 4) Auditoría de los productos de SW designados para verificar su ajuste al proceso de SW con los definidos como parte del proceso de SW. El grupo de SQA revisa los productos seleccionados e informa periódicamente de los resultados al administrador del proyecto. 5) Asegurar que las desviaciones del trabajo y los productos de SW se documentan y se manejan de acuerdo al procedimiento establecido. 6) Registrar lo que no se ajuste a los requisitos e informar a los superiores. Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven. Además de estas actividades, el grupo SQA coordina el control, la gestión de cambios, ayuda a recopilar y a analizar las métricas del SW. METODOLOGÍA SQA Las pruebas de SW son tanto un arte como una ciencia en general, en aplicaciones complejas, como los sistemas operativos, es prácticamente imposible eliminar todos los errores antes de liberar la versión, esto se debe a los diferentes puntos de vista y a las limitaciones de tiempo. Diferentes aplicaciones de SW requieren distintos enfoques en lo que respecta a las pruebas. Los métodos más comunes para el aseguramiento de la calidad son los siguientes: 1) Auditorías PPQA (Process and Product Quality Assurance) Es la actividad de garantizar que el proceso y el product de trabajo se ajustan al plan acordado. 2) Pruebas de Validación: Es el acto de introducir datos, los cuales el tester sabe que son erróneos en la aplicación. 3) Comparación de datos: Técnica que se realiza comparando los resultados de una aplicación con parámetros específicos con los resultados de otra aplicación previamente creada, introduciendo los mismos parámetros de manera que se obtenga un resultado exacto.

4) Prueba de esfuerzo (Stress Testing) Se realiza cuando el SW es utilizado de la manera más “ruda” posible en un período de tiempo para ver si trabaja con altos niveles de carga. 5) Pruebas de Uso: A veces conseguir usuarios que no estén familiarizados con el SW para probarlo por un tiempo determinado, ofrece retroalimentación a los desarrolladores acerca de las dificultades que encontraron. Esta es la mejor maneta de realizar mejoras a la interfaz. 6) Revisiones por Pares (Peer Reviews). Son actividades efectivas para el control de la calidad. Pueden aplicarse al análisis, diseño y codificación. 7) Revisión Técnica formal (RTF): Es una actividad de garantía de calidad de SW. Es una revisión que incluye recorridos, inspecciones y revisiones cíclicas. REVISIONES POR PARES (PEER REVIEWS) Consiste en la revisión del código de un programador por otros programadores (sus pares). Se puede poner en práctica creando un panel que encarga de revisar periódicamente muestras de código. En la revisión por pares se analizan o revisan factores técnicos, de procedimiento y humanos. Las revisiones por pares son las siguientes: -

Walkthroughs (recorridos) Revisiones Inspecciones de código

Walkthroughs Objetivos: -

Detectar posibles defectos. Identificar oportunidades de mejora. Examinar alternativas.

El walkthrough es usado para revisar especificaciones de requerimientos o de diseño. Procedimientos: A partir del código regular, el walkthrough es realizado al menos una vez por cada bucle a través del modelo espiral y se realizará en forma circular (programador i-th revisará el código del programador 1-th+1). Todas las deficiencias serán anotadas y utilizadas para el mejoramiento del proceso.

Durante cada código revisado en el walkthrough se tomarán dos mediciones: relativas y objetivas. Las deficiencias relativas son: código eficiente (pocos recursos son consumidos) y código exacto (que tan cerca está el producto con las especificaciones). Las deficiencias objetivas son: errores de formato, nombre de variables no estandarizado, falta de documentación (comentarios en el código) y falta de normas de codificación. INSPECCIONES DE CÓDIGO -

No son excluyentes con el testing. Cada desarrollador puede encontrar distintos tipos de defectos. No hay tiempo ni dinero para inspeccionar todo. Se suele centrar la inspección en los módulos más críticos. Es recomendable realizarla después de una prueba básica.

Objetivos primarios: -

Detectar defectos. Elegir el camino de resolución. Verificar la resolución (Los defectos deben ser corregidos).

Objetivos secundarios: -

Asegurar consenso sobre el trabajo y la calidad. Potenciar el trabajo en equipo. Obtener datos para las métricas.

LA REUNIÓN -

El presentador o moderador conoce a fondo el producto. Los asistentes son especialistas del negocio, la tecnología usada o son conocedores de los sistemas donde hay impacto. Se pueden discutir brevemente los temas planteados (problemas, sugerencias de mejora, etc). Si funciona bien: Buenos resultados y buena relación calidad/esfuerzo. Se debe ser cuidadoso con el tiempo y el tema importante de la reunión.

ROLES DE LA REUNIÓN Moderador -

Responsable de la inspección Asegura que todos estén preparados. Aclara las reglas. Hace cumplir las reglas.

Revisores

-

Buscan y describen los defectos. Toman decisiones para solucionar los errores.

Autor del Código (Desarrollador) -

Explica el código que él realizó. Responde las dudas.

Lector -

Lee el programa línea por línea.

Registrador -

Anota los defectos encontrados.

BENEFICIOS DE LA REUNIÓN Directos -

Mayor calidad que lleva a aumentos de productividad. Mayor visibilidad del proceso. Trabajo en equipo y mejor comunicación. Mejora en la calidad de estándares y métodos.

REVISIONES Se utilizará un checklist para realizar las revisiones. REVISIÓN TÉCNICA FORMAL (RTF) Una revisión técnica formal es una actividad de garantía de calidad del SW llevada a cabo por los ingenieros de SW y el equipo de SQA. Los objetivos de la RTF son: 1) Descubrir errores en la función, la lógica o la implementación, de cualquier representación del SW. 2) Verificar que el SW bajo revisión alcance sus requisitos. 3) Garantizar que el SW ha sido realizado con los estándares predefinidos. 4) Conseguir un SW desarrollado de forma uniforme. 5) Hacer que los proyectos sean manejables. La RTF también sirve para promover la seguridad y continuidad, ya que varias personas se familiarizarán con partes del SW que de algún modo no habían visto. Cada RTF se lleva a cabo mediante una reunión y solo tendrá éxito si es bien planificada, controlada y atendida. REUNIÓN RTF

La reunión debe ajustarse a las siguientes restricciones. Deben convocarse para la revisión entre 3 y 5 personas. Se debe preparar por adelantado pero sin que requiera más de dos horas de trabajo por cada persona. La reunión debe ser menor de 2 horas. Con las anteriores limitaciones, debe resultar obvio que cada RTF se centra en una parte específica del SW total. Al limitar el centro de atención de la RTF la probabilidad de descubrir errores es mayor. Proceso El desarrollo informa al jefe de proyecto que el producto está terminado y que requiere revisión. El jefe de proyecto contacta con un jefe de revisión que evalúa la disponibilidad del producto, genera copias del material y las distribuye a otros revisores. Cada revisor tomará notas para conocer el trabajo. De forma simultánea, el jefe de revisión, analiza el producto y establece una fecha para la reunión. La reunión es llevada a cabo por el jefe de revisión, los revisores y el desarrollador. La reunión comienza con una breve explicación del desarrollo para después continuar con el recorrido de la inspección explicando el material, mientras los revisores exponen sus comentarios cuando se descubren problemas o errores válidos, serán registrados. Al final de la reunión los participantes deben decidir si. 1) Aceptar el producto sin posteriores modificaciones. 2) Rechazar el producto debido a los serios errores encontrados. Una vez corregidos debe hacerse otra reunión. 3) Aceptar el producto provisionalmente. Se han encontrado errores menores que deben ser corregidos sin necesidad de otra reunión. REGISTRO E INFORME DE LA REVISIÓN Durante la reunión se van registrando todas las dudas y errores que vayan surgiendo. Al final de la reunión se resumen todas las incidencias y se genera una lista de sucesos de revisión. Además se prepara un informe de la RTF que debe responder a 3 preguntas. 1) ¿Qué fue revisado? 2) ¿Quién lo revisó? 3) ¿Qué se descubrió y cuáles son las conclusiones? La lista de sucesos de revisión tiene dos propósitos: Identifica las áreas problemáticas dentro del producto.

Sirve como lista de comprobación de puntos de acción que guían al programador para realizar correcciones. DIRECTRICES PARA LA REVISIÓN Se deben establecer de antemano directrices para conducir la RTF. Las directrices más comunes son las siguientes. 1) Revisar al producto no al productor. 2) Fijar una agenda y mantener. La RTF debe seguir un plan de trabajo concreto. El jefe de revisión es el encargado de mantener el plan de la reunión. 3) Limitar el debate y las impugnaciones. Cuando se identifique alguna indecencia, puede o no haber unanimidad sobre su impacto. Sin embargo no se deber perder el tiempo debatiendo la cuestión si no que debe ser registrada y resolverse en otro momento. 4) Enunciar las áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. La resolución de problemas deber ser propuesta para después de la revisión. 5) Tomar notas. De preferencia, estas notas deber ser escritas en un pizarrón de forma que puedan ser comprobadas por el resto de los revisores. 6) Limitar el número de participantes e insistir en la preparación adecuada. 7) Desarrollar una lista de comprobación para cada producto que será revisado. Esta lista ayuda al jefe de revisión a estructurar la reunión. Se deben desarrollar listas de comprobación para los documentos de análisis, diseño, codificación y prueba. 8) Llevar a cabo un buen entrenamiento formal de todos los revisores. 9) Disponer recursos y una agenda para las RTF para que las revisiones sean efectivas, se deben planificar como una tarea de ingeniería del SW. 10) Repasar las revisiones anteriores. Las sesiones de información pueden ser beneficiosas para descubrir problemas en el propio proceso de revisión. El primer producto que se haya revisado puede establecer las propias directivas de revisión. TÉCNICAS ASOCIADAS A SQA A NIVEL DE PROYECTO SQA aborda principalmente 3 áreas o técnicas. -

Métricas de SW. Verificación y valoración. Gestión de la configuración.

Las técnicas de revisión de los productos de SW y las pruebas están fundamentalmente orientadas a la detección de defectos en el SW que a la evaluación de aspectos orientados a la calidad. Este aseguramiento de la calidad se realiza a través de modelos. Los más conocidos son los siguientes: -

Modelo de Boehm.

-

Modelo factores/criterios&métricas. Marco ISO 9126. Paradigma GQM (Goal – Question - Metric). Modelo Gilb. Modelo CMM (Capability Maturity Model). Modelo SPICE (Software Process Improvement and capability Determination).

MÉTRICAS Una métrica es una asignación de un valor y un atributo de una entidad de SW. Clasificación de las métricas de SW: Clasificación 1 -

Métricas de producto. Métricas de proceso.

Clasificación 2 -

-

-

-

-

Métricas basadas en atributos internos del producto. o Medidas de estructuración de un programa. o Métricas de complejidad. o Métricas de cobertura de pruebas. o Métricas de calidad y diseño. Métricas basadas en atributos externos del producto. o Métricas de portabilidad. o Métricas de defectos. o Métricas de usabilidad. o Métricas de Mantenibilidad. o Métricas de Fiabilidad. Métricas basadas en el código fuente. o No. de líneas de código. o No. de líneas de comentarios. o No. de instrucciones (funciones). o Densidad de documentación. Métricas basadas en estructura de diseño. o Relacionadas con el control intramodular. o Relacionadas con el acoplamiento entre clases. Métricas para sistemas orientados a objetos. o Acoplamiento o Herencia.

HERRAMIENTAS DE CALIDAD

-

-

Herramientas básicas. o Diagrama de flujo. o Diagrama causa – efecto. o Checklist. o Gráfica de control. o Histograma. o Diagrama de dispersión. Herramientas de gestión. Herramientas de creatividad. Herramientas estadísticas. Herramientas de diseño. Herramientas de medición. Niveles de madurez.