aseguramiento de la calidad.pdf
TRANSCRIPT
Calidad de Software
Integrantes
Asenjo Medina, Christian Wilmer
Rojas Herrera, Alex Jhampier
Vásquez Villalobos, Henry
Profesor
Ing. Mg. Víctor Tuesta
Conjunto de actividades sistemáticas que proveen capacidad al proceso de software para producir un producto adecuado para el uso.
El grupo de AC coordina con el control , la gestión del cambio y ayuda a recopilar y analizar métricas de software.
Prácticas colaborativas Se utilizan para mejorar la calidad del desarrollo de software.
Las prácticas colaborativas funcionan mejor si la construcción del sistema también es colaborativa, sin dueños de módulos, sino que todos pueden modificar diseño y código.
(SEI) recomienda un conjunto de actividades de Aseguramiento de la Calidad :
Planificación
Supervisión
Conservación de registros
Análisis
Elaboración de informes de aseguramiento de la calidad.
Se desarrolla durante la planificación del proyecto, este identifica Las evaluaciones que se realizan Las auditorías Revisiones para llevar a cabo Los estándares aplicables al proyecto Los procedimientos para el informe y
seguimiento de errores Los documentos que debe producir el grupo de AC
El grupo de AC revisa la descripción del proceso para que concuerde con :
Las políticas organizacionales
Los estándares internos de software
Los estándares
Por ejemplo, ISO 9001
,ISO 9126, ISO 25 000 ,etc
El grupo de AC :
o Identificar
o Documentar
o Sigue las desviaciones del proceso
o Verifica que se hayan hecho las correcciones
El grupo de AC Revisa los productos de trabajo seleccionados Identificar Documenta y sigue las desviaciones Verifica que se hayan hecho las
correcciones Periódicamente informa de los
resultados de su trabajo al gestor del proyecto.
Las desviaciones se pueden encontrar en :
El plan del proyecto
En la descripción del proceso
En los estándares aplicables
En los productos de trabajo técnicos.
A los elementos que no se ajustan se les da seguimiento hasta resolverlos.
Las revisiones de código son de las técnicas de mejoramiento de la calidad que mejor resultado brindan. Como además son de menos uso que otras técnicas.
Revisiones por pares en general
Son muy productivas, se realiza revisiones formales de diseño o de requerimientos y permite descubrir problemas nuevos.
Revisiones por pares informales
El programador expone su código en reuniones informales, donde encuentra errores y además da ideas avanzadas a programadores novatos que asisten a estas reuniones
Pruebas de Escritorio
Consiste en simular un recorrido por el código con algunos datos y ver si el programa se comporta como se espera, pero sin correr el programa, sino con lápiz y papel.
Hay tres formas básicas de revisiones de código:
• Trata de una revisión por un par que, aunque con menos formalismo, se realiza a la vez que se genera el código.
• Brinda mejor calidad de producto en menor tiempo. Y aunque los costos pueden ser un poco mayores, la relación costo-beneficio es claramente muy buena.
• El costo no siempre está justificado por los beneficios que se podrían obtener. Tal vez una buena manera de encararla sea utilizarla solamente en módulos más críticos, más complejos o de mayor riesgo.
La programación de a pares de programadores fue introducida formalmente por XP(Programación extrema), Trata de que un programador escribe, mientras el otro piensa enmayor escala, buscando simplicidad, errores y formas alternativas de solución delproblema.
• Se puede trabajar con wikis más herramientas automatizadas de controlde versiones.
• Un repositorio centralizado debe tener, al menos, funcionalidades parapoder actualizar código fuente de más de un origen y dar marcha atrásen caso de necesitarlo, hacia cualquier versión anterior.
En todas las técnicas colaborativas es fundamental contar con un repositorio único decódigo y documentación.
• Busca mejorar el diseño del código ya escrito, su estructura interna sin cambiar el comportamiento observable o externo.
• Dicho de otro modo, ningún objeto cliente debería darse cuenta de que algo cambió.
• Lo que estamos haciendo es modificar la estructura interna de un trozo de código, sin modificar su funcionalidad externa.
Integración continua.
Una de las prácticas más fuertes de XP es la de integración continua.
Consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes
La idea es que, una vez al día, corridos ya todos los tests unitarios, se integre, se compile y se corran las pruebas de integración, todo en forma automatizada.
En proyectos chicos y medianos la pueden hacen los desarrolladores. En cambio, en proyectos grandes y muy grandes, suele haber equipos especializados en integraciones y pruebas de humo, entre los cuales se pueden incluir desarrolladores.
Son pruebas de caja negra, y para ser corridas en el marco de la integración continua, automáticas.
Deben ser escritas por personas que desconocen el funcionamiento interno del sistema, asistidas por gente especializada en pruebas.
Usuarios van a considerar que nuestra aplicación tiene un mejor desempeño cuando les permita realizar más rápidamente sus tareas, y eso puede tener que ver con el diseño de pantallas, usabilidad, velocidad de la interfaz de usuario y facilidad de desplazamiento en formularios, entre muchas otras cosas.
Los cambios deben ser pequeños y hay que probarlos enseguida para asegurarse de que no se han introducido errores en un sistema que funcionaba bien. Es deseable que las pruebas estén automatizadas y sean lo más exhaustivas posibles.
es una técnica para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo. A esta actividad se le conoce informalmente como limpiar el código. La refactorización se realiza a menudo como parte del proceso de desarrollo del software: