Ingenier a de software
This presentation is the property of its rightful owner.
Sponsored Links
1 / 45

Ingeniería de Software PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

Ingeniería de Software. Control y aseguramiento de la calidad. ¿Qué es Quality Assurance ?. Es el proceso general de administración, aseguramiento y control de la calidad. Incluye todos los aspectos que hacen a la calidad del software final y sus atributos: SRS Diseño Desarrollo

Download Presentation

Ingeniería de Software

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ingenier a de software

Ingeniería de Software

Control y aseguramiento de la calidad


Qu es quality assurance

¿Qué es QualityAssurance?

  • Es el proceso general de administración, aseguramiento y control de la calidad.

  • Incluye todos los aspectos que hacen a la calidad del software final y sus atributos:

    • SRS

    • Diseño

    • Desarrollo

    • Control de cambios

    • Planeamiento

    • Control de calidad


Qu es control de calidad

¿Qué es control de calidad?

  • Un conjunto de actividades que se encargan de controlar que se consiga alcanzar los objetivos previstos

  • Éstas actividades se pueden dividir en dos grupos:

    • Validación

    • Verificación

  • El planeamiento y alcance de éstas actividades es responsabilidad de QA


Qu es v v

¿Qué es V&V?

  • Verificación:

    • “Estamos creando el producto correctamente?”

    • El producto debe conformar a su especificación de manera correcta

  • Validación:

    • “Estamos creando el producto correcto?”

    • El producto debe conformar a las necesidades del cliente

  • En la práctica es difícil ver el límite entre los dos grupos.


Cu l es el objetivo de v v

¿Cuál es el objetivo de V&V?

  • Según IEEE-1012:

    • Facilitar la detección de errores en etapas tempranas

    • Mejorar la visibilidad de la calidad, los riesgos y el cumplimiento del proceso

    • Asegurar que se cumplan todas las actividades planificadas de manera eficiente, respetando calendario y recursos


Qu es validaci n

¿Qué es Validación?

  • Según IEEE-1012:

    • Es el proceso de chequear que el software:

      • Responde a los requerimientos de sistema especificados y resuelve el problema especificado correctamente

  • Es decir, el producto sea tal cual fue especificado

  • Herramientas:

    • Testing unitario manual/automatizado

    • Testing integral


Qu es verificaci n

¿Qué es Verificación?

  • Según IEEE-1012:

    • Es el proceso de chequear que todos los artefactos:

      • Cumplen con los atributos de calidad esperados en todo el ciclo de vida.

      • Satisfacen los estándares de calidad y buenas prácticas durante todo el ciclo de vida

      • Establecen una base para asegurar que el resultado de cada actividad sea el input esperado para la actividad que lo requiera

  • Es decir, el proceso sea el esperado

  • Herramientas:

    • Checklists

    • Inspección de código


Caracter sticas de v v

Características de V&V

  • Especifica acciones durante todo el ciclo de vida

  • Los procesos de Validación y Verificación funcionan mejor si están hechos en paralelo al desarrollo del producto, y no después.

  • Las actividades de V&V son complementarias.


Validaci n

Validación

  • El objetivo es encontrar fallas en el producto:

    • Hacerlo lo mas eficientemente posible

    • Encontrar la mayor cantidad de fallas

    • No detectar fallas que en realidad no lo son

    • Encontrar las mas importantes


Definiciones

Definiciones

  • Incidente:

    • Todo evento no esperado durante la ejecución de una prueba de software.

    • Clasificación

      • Equivocación: Una acción humana que produce un resultado incorrecto

      • Defecto: Error o mala práctica en el código

      • Falla: Resultado no esperado. Es la manifestación de uno o más defectos.

    • No toda incidencia es una falla

    • No todo defecto produce una falla en el momento del testing

    • Una equivocación lleva a uno o más defectos, que están presentes en el código

    • Un defecto lleva a cero, una o mas fallas

    • La falla es la manifestación del defecto

    • Una falla tiene que ver con uno o más defectos


Definiciones1

Definiciones

  • Test case vs Test condition

    • Los casos de prueba son lotes de datos necesarios para que se dé una determinada condición de prueba

    • Las condiciones de prueba son descripciones de situaciones ante las que el sistema debe responder que quieren probarse

  • Economía de la Prueba:

    • Se puede invertir mucho esfuerzo en probar

    • Probar es el proceso de establecer confianza en que un programa hacelo que se supone que tiene que hacer

      • Ya que nunca voy a poder demostrar que un programa es correcto...

      • Continuar probando es una decisión económica


Tipos de prueba

Tipos de prueba

  • Los tipos de prueba varían de acuerdo a la actividad del ciclo de vida.


Tipos de prueba1

Tipos de prueba

  • De acuerdo al conocimiento interno que se tenga, las prubas unitarias, de integración y funcionales se pueden clasificar en:

    • Prueba de caja negra

    • Prueba de caja blanca

  • Las pruebas de regresión, sistema y aceptación deben ser siempre de caja negra.


Prueba de caja negra

Prueba de caja negra

  • Se valida que el resultado de una acción sea el esperado de acuerdo a la especificación.

  • Requiere, por lo tanto, una especificación verificable

  • En la teoría, una prueba de caja negra completa es imposible de realizar: se deberían probar todas las combinaciones de todos los valores posibles.

  • En la práctica, se definen conjuntos de datos de entrada posibles.


Prueba de caja negra1

Prueba de caja negra

  • Conjuntos:

    • Clases o particiones de equivalencia

      • Conjunto de valores equivalentes

    • Condiciones de borde

    • Valores de tipos no esperados o incorrectos

    • Integridad del modelo de datos

      • Dominio

      • Entidad

      • Relación

  • Probando los valores específicos de cada conjunto encontrado se cubre toda la prueba

  • La cantidad de conjuntos y combinaciones utilizadas definen la calidad de la prueba


Prueba de caja blanca

Prueba de caja blanca

  • Al igual que la prueba de caja negra evalúa el resultado.

  • A diferencia de este, aprovecha el conocimiento interno del código para dirigir la prueba.

  • El desarrollador al conocer la estructura interna puede dirigirse directamente a las partes del código más riesgosas.


Prueba de caja blanca1

Prueba de caja blanca

  • Test coverage:

    • Mide la calidad del test de acuerdo al porcentaje del código probado.

    • Grados de cobertura:

      • Sentencia

      • Decisión

      • Condición

    • A mayor complejidad ciclomática, mayor dificultad en maximizar el test coverage.


Tipos de test unit test

Tipos de test – Unit Test

  • Prueba componentes en forma independiente o en conjuntos reducidos.

  • A mayor cohesión, mayor capacidad de probar componentes independientemente.

  • Generalmente es realizado por el desarrollador, y se ejecuta de manera automatizada.

  • Se debería hacer para cada componente de código individual.

  • Se busca encontrar errores lo antes posible

  • Al ser un test de caja blanca, se busca maximizar el coverage.


Tipos de test prueba de regresi n

Tipos de test – Prueba de regresión

  • Pruebas orientas a probar que la funcionalidad no modificada en una iteración o luego de un cambio siga funcionando.

  • Se realiza de manera manual, a partir de un plan de testing que especifique los casos de prueba que se deben ejecutar en casos de regresión.

  • Se complementa con los test unitarios, en la medida que, estos, se ejecuten automáticamente cada vez que se realice un cambio.


Tipos de test pruebas funcionales

Tipos de test – Pruebas funcionales

  • Se prueba cada requerimiento por separado, probando los resultados esperados contra los actuales.

  • Es un test de caja negra.

  • Cada caso de prueba es un conjunto corto de acciones.


Tipos de test pruebas de sistema

Tipos de test – Pruebas de sistema

  • Se prueba el sistema buscando que las relaciones entre los distintos requerimientos se cumplan y se tienen en cuenta los requerimientos no funcionales.

  • Tipos de prueba:

    • Pruebas exploratorias

    • Pruebas de camino básico

    • Pruebas de stress

    • Pruebas de rendimiento

    • Pruebas de usabilidad


Tipos de test pruebas de usuario

Tipos de test – Pruebas de usuario

  • Prueba especificada por el sponsor, basada en la especificación de requerimientos, y ejecutada por él, con el objetivo de definir si el software cumple, o no, la especificación y en qué grado.


Verificaci n

Verificación

  • El objetivo es asegurar que se sigue el proceso

  • Esto incluye asegurar que los resultados de una actividad sean los esperados

  • Herramientas:

    • Inspecciones de código manuales

    • Inspecciones de código automatizadas

    • Checklists


Inspecciones de software manuales

Inspecciones de software manuales

  • Actividad realizada por los desarrolladores con el objetivo de descubrir defectos y anomalías.

  • Las inspecciones no requieren software andando y pueden ser realizadas tanto contra el código, como contra el diseño.

  • Es una técnica que permite encontrar defectos en etapas tempranas que serían difíciles de encontrar en pruebas en ejecución.


Inspecciones de software manuales1

Inspecciones de software manuales

  • Se espera la presencia de desarrolladores expertos.

  • Son complementarias al testing, no lo reemplazan.

  • Una sola inspección puede encontrar muchos defectos


Pre condiciones

Pre-condiciones

  • Se debe tener la especificación de requerimientos

  • Un checklist de errores comunes puede ayudar

  • Se debe tener la aceptación y conformidad del management, dado que estas tareas implican costos directos, pero reducen costos a futuro.

  • Las inspecciones de código no son herramientas para evaluar al personal


Procedimiento

Procedimiento

  • Se debe especificar quiénes participan en la inspección y con qué responsabilidad.

  • Los participantes deben saber qué código se va a verificar y se debe estudiar con antemano

  • Se realiza la inspección del código o documentos seleccionados, y se anotan los defectos encontrados

  • Se arreglan los defectos encontrados

  • Se evalúa si se debe volver a hacer la inspección


Roles

Roles

  • Autor:

    • El responsable del código o documento a evaluar

    • Se debe entender que lo que se evalúa es el código o documento, NO al autor

  • Inspector:

    • Una o más personas que se encargan de encontrar errores

  • Lector:

    • Encargado de dirigir la lectura

  • Moderador:

    • Maneja el proceso y se encarga que no haya conflictos.

    • Reporta al responsable de la inspección.

  • Responsable de inspección:

    • Se encarga de planear y administrar las inspecciones y definir los roles de cada integrante


Inspecciones de c digo automatizadas

Inspecciones de código automatizadas

  • Se utilizan herramientas de software que procesan el código

  • Encuentran errores comunes, a partir de patrones definidos.

  • No reemplazan a las inspecciones manuales, pero ayudan a encontrar errores comunes más fácilmente, por ejemplo:

    • Manejo de excepciones

    • Chequeo de tipos de datos

    • Chequeo de inicialización de variables


Checklist

Checklist

  • Herramienta de verificación manual, utilizada para saber si un artefacto cumple, o no, con ciertas condiciones.

  • Las condiciones incluyen condiciones de formalidad y contenido, condiciones impuestas por estándares de calidad, condiciones impuestas por la organización.

  • Se utiliza tanto para código como para documentación.


Ejemplo checklist de c digo

Ejemplo - Checklist de código

  • Se utiliza como ayuda para las inspecciones de código

  • Enumera defectos comunes, dependientes del lenguaje, que es probable encontrar

  • Cuanto más levemente tipado es un lenguaje, más chequeos se necesitan

  • Ejemplos:

    • Inicialización

    • Nombres de variables

    • Manejo de excepciones


M tricas y su relaci n con v v

Métricas y su relación con V&V

  • Inspecciones y Reusabilidad se pueden apoyar en:

    • Métodos ponderados por clase

    • Profundidad del árbol de herencia

    • Falta de cohesión de métodos

    • Acoplamiento entre objetos

  • Pruebas unitarias y verificabilidad / mantenibilidad se pueden apoyar en:

    • Test coverage

    • Complejidad ciclomática

    • Comentarios/Documentación

    • Cohesión / Acoplamiento


Planeamiento de pruebas

Planeamiento de pruebas


Planeamiento de pruebas1

Planeamiento de pruebas


Planeamiento de pruebas2

Planeamiento de pruebas

  • El proceso de prueba: Una descripción de las fases principales del proceso de prueba

  • Seguimiento de requerimientos: Se debe saber que requerimientos individuales se están probando

  • Elementos probados

  • Calendarización, incluyendo asignación de recursos

  • Procedimiento de registro de las pruebas: No alcanza con ejecutarlas, hay que registrar el resultado

  • Requerimientos de HW y SW: No todas las pruebas requieren del mismo HW o SW para ser ejecutadas


Estructura de un test case

Estructura de un test case

  • Referencia: identificador, creador, versión, nombre, …, requerimientos que prueba, dependencias (con otros subsistemas por ej)

  • Ambiente: Configuración de HW y SW a utilizar

  • Inicialización: Prepara el escenario

  • Acciones: Acciones para ejecutar y completar la prueba

  • Finalización: “Resetea” el ambiente a un estado inicial no relacionado con el test case

  • Datos de entrada: Se especifican las diferentes particiones de los datos de entrada

  • Resultados

    • Resultado: Ok/Fallido

    • Salida esperada

    • Salida obtenida

    • Severidad: Impacto de la falla

    • Adjuntos: Screenshots, archivos log, …


Intervalo que largo que fue no

Intervalo (que largo que fue, no?)


Herramientas case

Herramientas CASE

  • CASE: ComputerAided Software Engineering Ingeniería de Software Asistida por Computadora

  • Desde “simples” modeladores para realizar análisis, hasta herramientas capaces de generar código fuente.


Case db

CASE: DB


Case an lisis

CASE: Análisis


Case desarrollo

CASE: Desarrollo


Ingenier a de software

CASE

  • Building continuo

  • Inspección automatizada (Sonar, findbugs, etc…)

  • Test coverage

  • Test automatizados

  • Formateo automático, control de inclusión de documentación


Preguntas

Preguntas


Sugerencias

Sugerencias


Aplausos

Aplausos


  • Login