Ejemplos práctios de calidad en el software tecdencies

7,659 views

Published on

Presentación de Jordi Martí y Lleonard del Río, Tecdencies, en EUG, dentro del ciclo

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,659
On SlideShare
0
From Embeds
0
Number of Embeds
2,387
Actions
Shares
0
Downloads
90
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Ejemplos práctios de calidad en el software tecdencies

  1. 1. Ciclo conferencias “Gestión de Proyectos” (Abril-Junio 2012)Ejemplos prácticos de calidad en el software 2 de Mayo de 2012 jordi.marti@tecdencies.com lleonard.delrio@tecdencies.com
  2. 2. En què consistirà la presentació? Tecdencies, Enginyeria de Software La qualitat en el software:  No és fer proves en un moment donat del projecte, s’ha d’aplicar en tot l’àmbit del Projecte …  … però en aquesta sessió ens centrarem en la qualitat del codi a desenvolupar: Des del dia 1 que es comença a programar, fins que entreguem el producte. 2
  3. 3. En 10 segundos…IntegraciónProporcionar soluciones Tecdenciesbasadas en componentesy sistemas existentes e Servicios de ingeniería yintegrarlos con los sistemas desarrollo de solucionesactuales de los clientes. software basados en personas, Integración procesos y tecnología.Proven InnovationInnovar de forma segura Cómomediante tecnologías Expertos trabajando de forma directaprobadas. con Departamentos de SI, o ayudando a las Consultoras TI a alcanzar la excelencia en la prestación de sus servicios.
  4. 4. Analysis / Design / Construction / Test / Deploy / Maintain ¿Estás seguro? •¿Estamos capturando bien los requisitos? •¿Estamos traduciéndolos bien en software? •¿A qué nos compromete esta arquitectura? ¿No deberíamos estar usando SOA? •¿Son estos patrones de diseño los correctos? •¿Utilizamos las herramientas correctas? •¿Las utilizamos correctamente? •¿Qué proceso de pruebas utilizamos? •¿Lo revisamos periódicamente? •¿Inspeccionamos el código que generamos? •¿Utilizamos estándares de codificación? •…
  5. 5. Ingeniería del software Definición según el IEEE: 1. La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software Cualquier enfoque de ingeniería debe estar sustentado en un compromiso con la calidad Herramientas Métodos Proceso Enfoque de calidad
  6. 6. SWEBOK El SoftWare Engineering Body Of Knowledge es un proyecto de colaboración entre la IEEE Computer Society y la Université du Québec à Montreal, con el fin de definir el cuerpo de conocimientos de la ingeniería de software Sus objetivos:  Caracterizar los conocimientos de ingeniería del software  Aportar un acceso por temas al conocimiento de ingeniería del software.  Promover una visión consistente de la ingeniería del software en todo el mundo.  Clarificar el lugar y el entorno de la ingeniería del software con respecto a otros disciplinas (computer science, gestión de proyectos, computer engineering, matemáticas).  Aportar una base para el desarrollo de un currículo material para poder certificar y conceder licencia a profesionales.
  7. 7. Áreas de conocimiento (1/2)
  8. 8. Áreas de conocimiento (2/2)
  9. 9. KA: Prueba del software
  10. 10. KA: Calidad del software
  11. 11. Definición de calidadConcordancia con 1. los requisitos funcionales y de desempeño explícitamente establecidos, 2. estándares de desarrollo explícitamente documentados, y 3. características implícitas que se esperan de cualquier software desarrollado profesionalmente
  12. 12. CASO PRÁCTICO 1:CARACTERÍSTICAS IMPLÍCITAS 1
  13. 13. Coste de la calidad Costes que genera la búsqueda de calidad o que demanda el desarrollo de las actividades relacionadas con la calidad Tipologías  Costes de prevención: planificación de la calidad, revisiones técnicas formales, equipo de pruebas y entrenamiento  Costes de evaluación: inspección en el proceso, calibración y mantenimiento de equipo y pruebas  Costes de fallas: son los que no existen si no aparecen defectos antes de enviar un producto a los clientes  Costes de fallas internas: detectados en el producto antes del envío  Costes de fallas externas: detectados después del envío
  14. 14. Mecanismos para encontrar defectos  Posibilidades  Herramientas Compilador, revisores de código, etc.  Pruebas Pruebas unitarias, de integración, etc.  Usuarios Esperar a que los usuarios los encuentren  Revisiones Revisar el código fuente  Etc.Son inspecciones manuales:Revisión, la realiza uno mismoInspección, la realiza una tercera REVISIÓN DE CÓDIGO [70-80 %]persona INSPECCIÓN DE CÓDIGO [50-70 %] COMPILACIÓN [50 %] PRUEBAS UNITARIAS [40-50 %] PRUEBAS INTEGRACIÓN [45 %] PRUEBAS DE REQUISITOS [45 %] PRUEBAS DE ALGORITMO [8 %]
  15. 15. La importancia de las pruebas COSTES DE DESARROLLO Aún y así, la sensación es que [30-50 %] (habitualmente) el software no está Pruebas de Software suficientemente probado antes de ser distribuido  Probar software es extremadamente difícil  Las formas en las que puede comportarse un programa no se pueden cuantificar  La prueba se hace típicamente sin una metodología clara y sin la necesaria automatización o el soporte de herramientas
  16. 16. Principios de las pruebas Principio #1  Todas las pruebas deben ser rastreables hasta los requisitos del cliente Principio #2  Las pruebas se deben planificar mucho antes de que comience el proceso de prueba Principio #3  El principio de Pareto es aplicable para las pruebas de software Principio #4  Las pruebas deben comenzar “en lo pequeño” y progresar hacia “lo grande” Principio #5  Las pruebas exhaustivas no son posibles
  17. 17. Etapas de las pruebas Pruebas de UNIDAD  “Pronto“ + propio desarrollador  Verificar los elementos “testeables” más pequeños del software  El comportamiento se deduce de los casos de uso Pruebas de INTEGRACIÓN  Asegurar que los componentes actúan de la forma adecuada al combinarse para la ejecución de un caso de uso  Verificar paquetes (packages) Pruebas de SISTEMA  Cuando el software funciona como un todo (o cuando subconjuntos de comportamiento están implementados)  Todo el sistema Pruebas de ACEPTACIÓN  Acción final de las pruebas antes de desplegar el software  Verificar que el software está a punto y puede ser usado por los usuarios finales
  18. 18. CASO PRÁCTICO 2: PRUEBAS CONVISUAL STUDIO 18
  19. 19. ¡Gracias!

×