• Save
16 Cast Software Solo Pruebas 2009
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

16 Cast Software Solo Pruebas 2009

on

  • 322 views

Presentación de Cast Software en Solo Pruebas 2009

Presentación de Cast Software en Solo Pruebas 2009

Statistics

Views

Total Views
322
Views on SlideShare
322
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

16 Cast Software Solo Pruebas 2009 Presentation Transcript

  • 1. La importancia de la calidad del código fuente Febrero 2009
  • 2. Agenda
    • Los problemas que implica la baja calidad de código
    • Qué medir, qué probar.
    • Las Soluciones
    • Los retos en la evolución de las herramientas.
  • 3. Algunos problemas de la baja calidad de código
    • Riesgo
      • La literatura esta llana de ejemplos:
      • http://www.csl.sri.com/neumann/illustrative.html
    • Pero todos tenemos favoritos
    “ La rutina del sistema esperaba no tener impacto… pero las pruebas previas probaron ser insuficientes”, dijo RIM en una declaracion. Software inestable Una dura interrupción: 14 horas sin servicio de emails de Blackberry Control limitado de errores, falta de garantias, falta de fiabilidad, de transparencia y pruebas incompletas ‘ CANCEL’,no funciona Un vendedor vende 610k acciones a 1 yen, en vez de 1 acción por 610k yenes.
    • Pérdidas de 347 millones de dolares
    • Dimisión de los máximos responsables de Mizuho y TSE.
    Mizuho Trading
  • 4. Algunos problemas de la baja calidad de código
    • Diario de sesiones de una Comunidad Autónoma. 18 de Febrero de 2009.
    • Sobre un sistema informático educativo.
      • Perdida de datos.
      • Rendimiento que impide la operación.
    • “ Mire usted, de momento, la valoración que hacen tanto los institutos de primaria como los de secundaria y de bachillerato es que el funcionamiento es desastroso; esto no va bien en absoluto. Si tenemos que hacer una valoración respecto a los sistemas anteriores, los profesionales, los docentes, y también el personal administrativo, valoran mucho mejor los “tamagochis” que este sistema. “
  • 5. Problemas de la baja calidad. El coste. Linea temporal de proyectos Test de sistema Volumen de trabajo Cantidad de código producido Lanzamiento (con análisis de código) Lanzamiento (sin análisis de código) Tiempo y dinero perdido Más defectos en la vida de la aplicación Nuevo desarrollo Perfíl de defectos sin Control Perfíl de defectos con Control
  • 6. Algunos problemas de la baja calidad de código
    • El anquilosamiento / envejecimiento
      • Un código de mala calidad es mas caro y difícil de mantener.
      • Este efecto crece con el tiempo, hasta que hace inviable el mantenimiento de la aplicación.
    Algunos problemas de la baja calidad de código
  • 7. Agenda
    • Los problemas que implica la baja calidad de código
    • Qué medir, qué probar.
    • Las Soluciones
    • Los retos en la evolución de las herramientas.
  • 8. Qué medir y que probar
    • Probamos que la aplicación hace lo que esperamos de ella:
      • Pruebas funcionales
    • Probamos que la aplicación permitirá hacer el trabajo al ritmo necesario.
      • Pruebas de stress y carga
    • Tenemos metodologías que indican si el proceso de fabricación ha sido controlado:
      • CMMI, SPICE, Agile…
    • Pero aun falta medir el producto: el código fuente de la aplicación.
  • 9. Más acerca del riesgo proactivo y la gestión de la calidad
    • El análisis de código provee de un mapeado de todos los defectos de la aplicación
    • Los defectos de alta gravedad pueden ser justificados como el objetivo de un plan de corrección, para mejorar el comportamiento de la aplicación
    • Algunos defectos de alta gravedad justifican el objetivo de remediar la mantenibilidad
    • El resto pueden ser corregidos cuando el mantenimiento funcional provoca que los desarrolladores toquen el código
    Aplicación crítica de la empresa Aplicación existente
  • 10. Cómo se mide la calidad del código.
    • Existen múltiples intentos normativos. Los más destacados son:
      • la familia de normas ISO 9000 (en especial la ISO 9001 y la ISO9003-2)
      • el modelo de niveles de madurez CMM (Capability Maturity Model)
      • el estándar para el aseguramiento de planes de calidad del IEEE 730:1984
      • el plan general de garantía de calidad del Consejo Superior de Informática MAP
    • Pero la forma más comúnmente aceptada de medir la calidad de código es la norma 9126-3.
  • 11. Según la ISO 9126 la gestión de la calidad interna y externa es crítica para controlar el riesgo.
    • Calidad Interna
      • Predice la calidad final
      • Identifica los problemas, ofrece una acción correctiva antes de que el software sea ejecutable
      • Tests posibles a lo largo de todo el ciclo de vida.
    ** ISO/IEC TR 9126-3 First edition 2003-07-01
    • Calidad Externa
      • Mide el comportamiento del sistema
      • Sólo posible durante la fase de test y producción del ciclo de vida
      • Se lleva a cabo ejecutando el software en un entorno del sistema
    Calidad Interna Calidad Externa Influencia Depende de Producto Software Métricas Internas Métricas Externas
  • 12. Cómo se mide la calidad del código.
    • Cómo mide la norma ISO 9126-3
      • De lo general a lo particular en tres niveles
        • Factores
        • Criterios
        • Métricas
      • Los factores: Las características técnicas generales de un buen software.
        • 1. Funcionalidad
        • 2. Fiabilidad
        • 3. Usabilidad
        • 4. Eficiencia
        • 5. Mantenibilidad
        • 6. Portabilidad
  • 13. Cómo se mide la calidad del código.
      • Bueno… y como sabemos que un software es… por ejemplo:
        • Mantenible
        • Por la medición de sus criterios
        • Analizabilidad Cambiabilidad Estabilidad Facilidad de prueba Conformidad
        • Y cada una de estas esta a su vez compuesta por las métricas correspondientes.
  • 14. Un ejemplo de modelo de calidad Transferibilidad Cambiabilidad Robustez Rendimiento Tamaño Normas de nomenclatura Documentación Arquitectura Complejidad Package naming Class naming Interface naming Method naming Attribute naming Constant naming Package comment Class comment Method comment Package size Class size (methods) Class size (attributes) Interface size Method size Class complexity (Inh. depth) Class complexity (Inh. width) Method complexity (Param.) Method complexity (control flow) Mantenibilidad Seguridad Prácticas de programación File conformity Dead code Controled data access Structuredness Modularity Encapsulation conformity Empty code Inheritance Factores Criterios Subconjunto de métricas Application Quality Application Quality Calidad de aplicación
  • 15. De donde salen las métricas
    • Las métricas estan compuestas por comprobaciones unitarias en el código.
    • Provienen de las normas generales de desarrollo, documentación y arquitectura publicadas por los fabricantes, las instituciones (SEI, ACM, etc…) y las definidas por el propio equipo de desarrollo.
    DECADAS DE INGENIERIA EN CALIDAD DE SOFTWARE
  • 16. Las soluciones de calidad técnica de código.
    • Las herramientas deben hacer algo más que medir:
      • deben ayudar a diagnosticar,
        • Reforzar la seguridad? el rendimiento?
      • deben ayudar a tomar decisiones.
        • Conservo la aplicación? la sustituyo? modifico mi equipo?
      • deben ayudar a actuar
        • Qué hacer primero? Comparar aplicaciones… definir prioridades…
      • Deben ayudar al gobierno y la ejecución del desarrollo.
  • 17. Los contextos aplicativos son complejos Database
    • Data Management Layer
    • EJB – Hibernate - Ibatis
    Databases Files Web Services CICS Connector Enterprise Applications Legacy Applications Middleware Presentation Tier Business Logic Tier Data Tier
    • Web / Client Server Applications
    • ASP/JSP/VB/.NET
    • Application Logic
    • Java, C++, …
    • Frameworks Struts MVC, Spring
    COBOL CICS Monitor (Cobol) Tuxedo Monitor (C) Batch Shell Scripts
  • 18. Un ejemplo de uso en una organización. Operador 1- Entrega del código fuente 2- Test de aceptación 2a- Aceptación Funcional 2b- Aceptación de Carga/Stress 2c- Aceptación Técnica 2d – Envío de lista de defectos para Su corrección 4- Decisión Go / No Go 5a- Informe de salida a producción 3- Informe de QA 5b- Objetivos de calidad de código Lista defectos en Reglas Niveles de cumplimiento Objetivos de calidad de código. Niveles de cumplimiento Cumplimiento de objetivos de negocio Organización de QA Jefes de equipo de desarrollo Responsable de aplicación Director de Desarrollo Medición del código
  • 19. Diferentes usos y consumo de los resultados. Medición del código Datos informes y resumenes
    • Visibilidad
    • Datos objetivos
    • Toma de decisiones
    • Objetivos Organizativos
    • Seguimiento de la aplicación de la arquitectura
    • Gestión proactiva de la calidad de software
    • Metricas – calidad, cantidad, técnicas
    • KPIs objetivos para la gestión
    Información Y documentación
    • Localización de defectos
    • Mejor compresnión del impacto
    • Oportunidad de aplicar las mejores prácticas en desarrollo
    Equipos de desarrollo internos y externos Gerencia, Dirección de desarrollo Jefes de proyecto, arquitectos y personal de Calidad
  • 20. Visión general del ROI ROI Beneficios de la gestión de entregas Beneficios de la externalización = 1 2 + - Costes 3 Procesos de desarrollo gestionados directamente No se gestiona directamente a los desarrolladores
  • 21. Gestión de entregas – categoría de beneficios y cálculo 1 Impacto en la empresa del periodo de inactividad de la producción = (defectos totales en producción/año/desarrollador) x (# de desarrolladores) x (eficiencia CAST en eliminación de defectos) x (Wt. Avg. costes de defectos en producción) Menos defectos en sistemas activos Impacto empresarial = (# de licencias discovery portal) x (Costes de cada desarrollar) x (% ttiempo gastado en fortalecimientos menores) x (productividad mejorada porque DP) = (# de desarrolladores) x (Costes de cada desarrolladores) x (Ganancias de productividad por la expectación) = (mejora del mantenimiento anual) x (costes de mantenimiento anual) = (# de desarrolladores) x (Coste de cada desarrollador) x (Reutilización de la productividad mejorada) = (# de recursos QA (FTEs)) x (Costes de cada recurso QA) x (eficiencia CAST en eliminación de defectos) = (Defectos/año/Desarrollador) x (# de desarrolladores) x (ahorro por eliminación de defectos en desarrollo) x (eficiencia CAST en eliminación de defectos) Fórmula Transferencia de conocimiento más rápida para nuevas transferencias, aumentos menores y movimientos de HR internos, Productividad fortalecida cuando se aplican métricas objetivas Mejor código de calidad resulta en un mantenimiento más eficiente Codificación eficiente a través de una mejor reutilización y conformidad de los frameworks Menos defectos alcanzan la QA Ahorros por detección temprannosa de defectos en desarrollo Breve explicación Nevagación más rápida por sistemas heredados complejos Discovery Portal Anticipación de las mediciones Mantenimiento más eficiente Reutilización y adherencia a los frameworks Fortalecimiento del rendimiento de los equipos Procesos de QA más eficientes Detección temprana de defectos Eliminación de defectos Subcategoría Categoría de beneficios
  • 22. Gestión de entregas- categorías de beneficios y cálculos 2 = (Mejora del mantenimiento annual) x (costes anuales de mantenimiento) = (# de recurso QA para controlar externos (FTEs)) x (Coste de cada recurso QA) x (eficiencia de la eliminación de defectos de CAST) = (Defectos totales en producción/año/desarrollador) x (# de desarrolladores externos) x (eficiencia de eliminación de defectos de CAST) x (Wt. Avg. coste de defectos en prod.) = (Defectos totales en producción/año/desarrollador) x (# de desarrolladores externos) x (eficiencia de eliminación de defectos de CAST) x (ahorros de la eliminación de defectos antes de la prod.) = (media gastada en peticiones de cambio) x (Ganancias esperadas de la negociación) Fórmula Mejor calidad de código resulta en un mantenimiento más eficiente Menos defectos acceden a QA Impacto en la empresa de un menor periodo de inactividad de la produccion Ahorros por encontrar los defectos antes de ir a producción Mejor estimación de los costes de las peticiones de cambio Breve explicación Mantenimiento más eficiente Procesos de QA más eficientes Mejoras de la productividad Menos defectos en sistemas activos Eliminación de los defectos antes de la entrega del proveedor Menos defectos en producción Ganancias de lo negociación Control RFC Subcategoría Categoría Beneficios
  • 23. Valor mesurable
    • Calidad de gestión de aplicaciones mejorada
      • Descubre defectos antes 10x ahorro por defecto
      • QA más eficiente hasta 20% de equipos QA
      • Reduce los problemas de que sufren los clientes el valor depende del negocio
    • Gestión de la productividad de los equipos mejorada
      • Mejor reutilización del framework y los componentes hasta 10% del presupuesto AD
      • Reduce costes de mantenimiento hasta un 5% del presupuesto AD por año
    • Visibilidad de la gestión aumentada
      • Transparencia con la Externalización 5-50% de ahorro sobre las peticiones de cambio
      • Medición objetiva y KPIs hasta 10% del presupuesto de aplicaciones
  • 24. Preguntas?
  • 25. Gracias por su atención. Antonio Díaz Sales Manager, Iberia [email_address] CAST, Leader in Automated Application Intelligence Achieve Insight. Deliver Excellence. www.castsoftware.com | Gain visibility into application quality to proactively manage risk and improve team performance.