1

2 La Gestión de Calidad del Software como un activo trascendental (una perspectiva para generar valor) la 'brecha tecnológica' existen importantes oportunidades mejorar la calidad de su tecnologíasu nivel de productividad “Se estima que la 'brecha tecnológica' es actualmente muy amplia, lo que sugiere que aún existen importantes oportunidades para las empresas para mejorar la calidad de su tecnología y con ello su nivel de productividad". Alan Greenspan

3 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

4 Nuestra meta es producir software de calidad, pero… Calidad del Software: Conceptos El concepto de calidad del software es complejo Depende de las percepciones de los usuarios La búsqueda de la calidad a ultranza se es poco realista

5 Calidad del Software: Definiciones "Conjunto de esfuerzos efectivos de los diferentes grupos de una organización para la integración del desarrollo, del mantenimiento y de la superación de la calidad de un producto, con el fin de hacer posible la fabricación y servicio a satisfacción completa del consumidor y al nivel más económico" [Feigenbaun, Deming y Juran]

6 Calidad del Software: Definiciones "La mejor calidad que una empresa puede producir con su tecnología de producción y capacidades de proceso actuales, y que satisfará las necesidades de los clientes, en función de factores tales como el coste y el uso previsto" [Dr. Kaoru Ishikawa]

7 Calidad del Software: Definiciones " La gestión de calidad en la empresa es el proceso de identificar, aceptar, satisfacer y superar constantemente las expectativas y necesidades de todos los colectivos humanos relacionados con ella, clientes, empleados, directivos, propietarios, proveedores y la comunidad con respecto a los productos y servicios que esta proporciona" [consultora Arthur Andersen]

8 Calidad del Software: Modelo de McCall La ISO 9126 (International Organization for Standardization/International Electrotechnical Commission) es una serie de documentos ISO para evaluar la calidad de los productos finales de software, se basa en este modelo

9 Calidad del Software: Modelo de McCall Área L y SI U. Burgos http://pisuerga.inf.ubu.es

10 Calidad del Software: McCall FACTORDEFINICIÓN CorrecciónGrado en el que un programa satisface las especificaciones y cumple los objetivos del usuario. FiabilidadGrado en el que un programa se espera que realice su función con una precisión requerida. EficienciaCantidad de recursos y código requeridos por un programa para realizar una función. IntegridadGrado en el que se controla el acceso al programa o los datos por usuarios no autorizados. UsabilidadEsfuerzo necesario para aprender, operar, preparar entradas e interpretar la salida de un programa. MantenibilidadEsfuerzo requerido para localizar y corregir un error en un programa en funcionamiento. Facilidad de pruebaEsfuerzo requerido para probar un programa (para garantizar que realiza la función deseada). FlexibilidadEsfuerzo requerido para modificar un programa en funcionamiento. PortabilidadEsfuerzo requerido para trasferir un programa de una configuración hardware o entorno software a otro. ReusabilidadGrado en el que un programa se puede utilizar en otras aplicaciones InteroperatividadEsfuerzo requerido para acoplar un sistema con otro.

11 Calidad del Software: Factores Calidad del Producto Factor Humano ProcesoTecnología Presupuesto, Plazos, Habilidades

12 Calidad del Software: Evidencia La evidencia es la información que utilizamos para determinar si el resultado de la prueba realizada es correcto o no, en este ultimo caso también debe servir como orientación para la remediación de la falla o defecto que se ha detectado. “ All in all, coders introduce bugs at the rate of 4.2 defects per hour of programming. If you crack the whip and force people to move more quickly, things get even worse” W. Humphrey (note), http://www.cs.usask.ca/grads/jpp960/490/BombSquad.html

13 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

14 La tendencia de la calidad : El Costo de la Calidad - Los costos de prevención : - La planificación de la calidad - Evaluación de formación técnica - Equipos de ensayo - La formación - Los costos de evaluación : - Inspección intra-proceso y entre procesos - Calibración de equipo y mantenimiento - Pruebas - Los costos del fracaso: Costo de falla interna : - Revisión, reparación y análisis de modo de falla Costo de fallas externas: - Resolución de quejas - De devolución del producto y su sustitución - Línea de ayuda y apoyo - Garantía de trabajo Versus

15 La tendencia de la calidad : Proceso Evolutivo Modelo Incremental [LEHMAN-84] Crear sistema añadiendo componentes funcionales (incrementos) En cada paso se actualiza el sistema con nuevas funcionalidades y requisitos

16 La tendencia de la calidad : Verificación y Validación continua A diferencia del enfoque tradicional, durante la prueba del producto se descubren los problemas con el tiempo necesario para resolverlos sin que por ello se exceda el tiempo planificado y se produzca una mora en la entrega Requerimiento Análisis y Diseño ConstrucciónPruebaDistribución

17 La tendencia de la calidad : Proceso Unificado Esfuerzo Necesario por Actividad TransiciónElaboraciónConstrucciónConcepción Iteración Preliminar.... Iteración 1 Iteración 2.... Iteración n Iteración n+1 Análisis & Diseño Construcción Pruebas Distribución Requerimientos Disciplinas A & D C P D R C P D R C P D R C P D R

18 La tendencia de la calidad : Establecer un Entorno para la medición de la calidad software

19 La tendencia de la calidad : Evolución Futura Todo proyecto de pruebas debe dejarnos experiencias capitalizables para la evolución futura de nuestro enfoque de calidad, pues cada proyecto nos coloca ante la situación única de adquirir nuevas experiencias. Mejora de la calidad Control de calidad Garantía de calidad Calidad total Tiempo Detectar defectos Prevenir defectos Mejora continua

20 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

21 Garantía de calidad del software: Beneficios El beneficio principal de un programa de garantía de calidad de software es el de asegurar que en el proyecto los procesos establecidos se han ejecutado cabalmente. Esta evaluación es hecha por un grupo independiente, especializado en métodos de calidad, con un criterio objetivo y con visión de contexto. Se usa la metodología de desarrollo apropiada Las actividades de desarrollo han sido debidamente planeadas Se han definido estándares y procedimientos para al proyecto El personal ha sido debidamente entrenado en los procesos de calidad aplicables Se llevan a cabo regularmente revisiones y auditorías independientes El desarrollo es documentado adecuadamente para facilitar la mantención y la reutilización La documentación se produce oportunamente y no después que el desarrollo ha sido completado Los cambios introducidos han sido debidamente controlados Las pruebas efectuadas son eficaces para detectar defectos, especialmente en aquellas áreas de mayor riesgo Las actividades se llevan a cabo de acuerdo a los plazos y en los términos planeados Las desviaciones a los estándares se identifican rápidamente El proyecto está en condiciones para ser sometido a auditorías externas, si corresponde La calidad es verificada con respecto a criterios preestablecidos La gerencia es oportunamente informada de problemas y riesgos relativos a la calidad Los problemas de calidad se analizan y las causas se comunican al proyecto para tomar medidas preventivas que eviten su repetición Se asegura que :

22 Garantía de calidad del software: Factores El sistema de calidad La aplicación adecuada del proceso La actividades que aseguran la calidad del producto Toda organización que desarrolle software comercial o de uso propio, debe pretender que los productos desarrollados alcancen cotas de calidad dignas de satisfacer las necesidades de los usuarios y ser competitivos en su entorno de gestión J. R. Hilera, J.A. Gutierrez, J.J. Martínez Departamento de Ciencias de la Computación Universidad de Alcalá de Henares

23 Garantía de calidad del software: Pasos Planeación de actividades de prueba de software El plan de pruebas de software depende en gran medida de la planeación de actividades de desarrollo, sobretodo en cuanto a las entregas de componentes para probar. Si el cronograma de desarrollo está desfasado, seguramente se verá afectado el cumplimiento de las actividades de prueba del software. Ejecución de pruebas de software Independiente de la forma como se realicen las pruebas (manuales y/o automáticas) y de los tipos de pruebas que se acordaron en el alcance del proyecto, la ejecución de pruebas por parte del proveedor se basa en los ciclos o iteraciones de prueba, en los cuales se ejecutan los conjuntos de pruebas (casos o requerimientos de prueba) diseñados y en busca de una estabilidad incremental del producto de software.

24 Garantía de calidad del software Control y seguimiento de actividades de prueba de software Retroalimentación del proceso de pruebas

25 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

26

27 Enfoques formales para el aseguramiento de la calidad del software La garantía de la calidad de software requiere un enfoque formal Involucrarse tempranamente. Acordar relaciones de trabajo entre todos los participantes. Efectiva utilización de terceras partes. Soporte continuo de los niveles jerárquicos Capacidad de gerenciamiento de los recursos y sus habilidades técnicas. Mediciones /Incentivos proporcionados. Seguimiento positivo de logros y éxitos. Factores Críticos de Éxito

28 Enfoques formales para el aseguramiento de la calidad del software: Componentes Métodos y herramientas de análisis, diseño, codificación y prueba. Revisiones técnicas formales que se aplican durante cada paso del Proceso. Pruebas secuenciadas en múltiples escenarios y con métodos específicos de diseño de casos de prueba. Control de la documentación y de los cambios realizados. Procedimientos que aseguren un ajuste a los estándares de desarrollo Mecanismos de medida y de información. Métricas para medir la calidad.

29 Enfoques formales para el aseguramiento de la calidad del software: TMM

30 Enfoques formales para el aseguramiento de la calidad del software: TMMi TMMI (Test Maturity Model) (http://www.tmmifoundation.org/), específico para pruebas (complemento a CMM, CMMI)http://www.tmmifoundation.org/

31 Enfoques formales para el aseguramiento de la calidad del software: Métodos de Mejora del Proceso de Pruebas TPI  - Test Process Improvement, esquema general The Software Quality and Correctness (SQuaC) group from ITI, Valencia, Spain, has made a translation of the TPI®-material in Spanish.

32

33 Enfoques formales para el aseguramiento de la calidad del software: Tmap  TMap fue creado por la empresa Sogeti, es el enfoque para definir un proceso de prueba estructurado, basado en 4 componentes: Ciclo de vida, que y cuando probar Actividades Organizacionales, quien efectúa las pruebas: la organización del equipo de test, donde cada uno debe tener tareas y responsabilidades la incorporación del equipo de test en la organización del proyecto Infraestructura y herramientas, donde y con que herramientas probar Técnicas aplicables al proceso de prueba, como probar TMap Next® Business Driven Test Management, una excelente guía para convertir objetivos de negocio en planes de pruebas concretos, pragmáticos y controlables. ISBN: 9789072194930 C T I A

34 Enfoques formales para el aseguramiento de la calidad del software: Tmap  Fases Planificación y Control: Especificación de "Quien", "Que", "Cuando", "Como" y "Donde" probar. Preparación: Determinar si las especificaciones del software escritas o no, tienen la calidad necesaria para la especificación y ejecución de las pruebas. Especificación: Incluye la especificación de los casos de prueba y configurar la infraestructura. Ejecución: Se ejecutan las pruebas especificadas de forma de obtener conocimiento de la calidad del producto a probar. Finalización: Consiste de conservar los materiales del test para su futura reutilización, realización del informe final y evaluación del proceso de prueba para mejorar el control de futuros procesos de prueba.

35 Enfoques formales para el aseguramiento de la calidad del software: MoProSoft  Procesos Dra. Hanna Oktaba, presidenta de la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS) http://www.iie.org.mx/boletin032003/ind.pdf Desarrollo y mantenimiento de software Realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. Desarrollo y mantenimiento de software Realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. MoProSoft es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que da contenido es la NMX- 059/01-NYCE-2005 que fue declarada Norma Mexicana Procesos MoProSoft

36 La Secretaría de Economía tiene derechos reservados ® de MoProSoft. Fases de un Ciclo MoProSoft  Requerimientos Necesidades del cliente y Plan de desarrollo Análisis y Diseño Construcción Cierre Requerimientos Análisis yDiseño Componentes Primer / Siguiente Entregable Inicio Integración y Pruebas Configuración de Software Categoría de Operación (OPE)

37 La Secretaría de Economía tiene derechos reservados ® de MoProSoft. Actividades de una Fase MoProSoft Producción / Corrección Entrada de la Fase Verificación Validación/Aceptación Salida de la Fase Incorporación Bajo Control de Configuración Registro de Mediciones Defectos

38 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

39 Planificación y gestión de las pruebas : Automatización La automatización de pruebas es una de las inversiones que ha producido los mejores y más satisfactorios resultados Inversión a medio-largo plazo Única actividad que nos proporciona una estimación real de la calidad de nuestra aplicación “Sí, el producto está preparado para salir” “No, no está preparado y esta es la razón por la que no puede salir” Es imprescindible en el desarrollo iterativo : probar en cada iteración, cada vez que se realiza un cambio seria un esfuerzo irrealizable sin este enfoque

40 Planificación y gestión de las pruebas : “En el desarrollo de software, existen limitaciones a tener en cuenta tales como la Planificación y gestión de Proyectos, que si no se lleva a cabo de forma correcta lleva al inminente fracaso del proyecto. Otra de las características esenciales esta relacionada al Líder del Proyecto, debiendo este tener la capacidad para llevar a cabo la gestión adecuada para alcanzar los objetivos propuestos”. EVANS, Michael W., ABELA, Alex M., BELTZ, Thomas Trabajo presentado en la Conferencia de Tecnologías de Software, 30 de abril de 2002 en Salt Lake City UT.

41 Planificación y gestión de las pruebas : La planificación de pruebas significa poner en acción nuestra estrategia de prueba y validarla durante un periodo específico como por ejemplo una iteración o un pequeño proyecto realimentado la planificación con los resultados obtenidos. Un plan básico de pruebas incluye la integración de informes y métricas que den una visión objetiva de la marcha del proyecto.

42 Planificación y gestión de las pruebas : Pre-requisitos Información sobre el contexto Información sobre el problema (o proyecto) Ideas sobre las pruebas Ideas sobre la cobertura de las pruebas Ideas sobre los riesgos del proyecto Ideas sobre los detalles de la ejecución Documentos o artefactos que apuntan a compartir las ideas que se tienen, y que resultan útiles para cuestionar los supuestos y las nociones Documentos o artefactos que puedan ser necesarios para avanzar en el proceso (según el contexto)

43 Planificación y gestión de las pruebas : Ítems a considerar Preparaciones Asignación de personal Cobertura de la prueba Todos los requerimientos de prueba (técnicos u otros) Entornos de prueba Criterios de ingreso Criterios de salida Delegación de responsabilidades Adquisición de instalaciones Planificación de tareas Programación Documentación sobre la coordinación y colaboración con otros equipos Riesgos y problemas que puedan impactar sobre las pruebas Entregables específicos del proyecto de prueba

44 Planificación y gestión de las pruebas : Ejecución

45 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

46 Tercerización de las Pruebas (Outsourcing vs. Insourcing) Habilidades técnicas y de gestión Terceros Interno BajoAlto Bajo DesajusteCoincidencia DesastreDesajuste Comprador maduro instruye al proveedor inmaduro Resultado impredecible Proveedor y comprador maduros Probabilidad alta de éxito No disciplina No procesos No producto Comprador inmaduro Proveedor maduro Comprador “sugiere” caminos “cortos”

47 Tercerización de las Pruebas (Outsourcing vs. Insourcing) Ejecución interna de las pruebas de software dentro del centro de desarrollo pero por un equipo independiente del de desarrollo (Insourcing) o fuera de él por un tercero especializado en las mismas (Outsourcing).

48 Tercerización de las Pruebas: “Testing Factory” Una Testing Factory, provee una alternativa a aquellas organizaciones que no desean tener un área de testing interna. La tercerización de infraestructura, recursos humanos y herramientas de testing, permiten a los clientes maximizar los beneficios, al contar con un área de Testing, sin incurrir en los costos de mantenimiento, complejidad de planificación, ejecución y disponibilidad de recursos humanos..

49 Tercerización de las Pruebas: “Testing Factory” Ventajas Especialidad del proveedor fundamentada en su propia investigación, aplicación y experiencia en otros proyectos. El análisis que el proveedor especializado puede ofrecer a la organización será confiable, basado en hechos reales y sobre todo independiente. La independencia hace que el proveedor pueda realizar evaluaciones (que demuestran fortalezas y debilidades) mas objetivas. La obligación del proveedor de pruebas de software es mantenerse actualizado en temas de su especialidad, lo cual redundará en beneficios para la organización. Los costos adicionales del proceso de pruebas (entrenamiento y alistamiento de recursos, desarrollo de herramientas de apoyo), serán asignados sólo al proveedor, y permitirán a la organización dedicar más recursos a su verdadero enfoque de negocio.

50 Tercerización de las Pruebas: Origen de Fallas Las fallas en el desarrollo de proyectos de software habitualmente no son unidimensionales. Las fallas no son causadas únicamente con un desliz técnico en una rutina cualquiera. No son causada solamente por problemas de comunicación interpersonal. En la realidad suelen ser una combinación de los factores citados en la lista precedente los que se acumulan en el tiempo, y en ocasiones resultan en una falla mayor.

51 Tercerización de las Pruebas: Su impacto Hay pocos sistemas hoy que no usan computadores para suministrar control o apoyar el diseño En los ciclos críticos a la seguridad se pueden usar computadores en maneras distintas: Proveer información a un controlador humano a petición. Interpretar los datos y mostrarlos al controlador, que hace las decisiones de control. Emitir los comandos directamente con un monitor humano. Eliminar el humano completamente. Es obvio que hay riesgos cuando los computadores tienen control directo sobre procesos peligrosos. Otros peligros no tan obvios son Se usan datos generados por software para hacer decisiones críticas a la seguridad (por ejemplo, en el control del tráfico aéreo). Se usan software en el análisis de diseño (por ejemplo, en CAD/CAM). Se guardan datos críticos a la seguridad (por ejemplo, datos de banco de sangre) en un base de datos.

52 Gestión ServiciosAnálisis y DiseñoRequerimientosConstrucciónPruebas Administración de la Configuración y Cambios Aseguramiento de la Calidad de Procesos y Productos Centro de Soporte Herramnetal Procesos En sitio En sitio y/o Fábrica de Software Tercerización de las Pruebas: Actividades

53 Agenda Conceptos de calidad. La tendencia de la calidad. Garantía (aseguramiento) de calidad del software. Enfoques formales para el aseguramiento de la calidad del software. Planificación y gestión de las pruebas como factor clave para el éxito. Tercerización de las Pruebas (Outsourcing versus Insourcing). Conclusiones.

54 Conclusiones: Aspectos Clave Entrega de Aplicaciones Más Predecible Mayor (y más cuantificable) Calidad en el Producto Entregado Reducción de los Riesgos de Negocio y Perdidas Financieras y logro de una mayor Credibilidad por parte de los Clientes

55 Conclusiones La Prueba de Software es una actividad que consume recursos intensivamente. Un enfoque que aplique una perspectiva de valor puede ayudarnos a lograr un retorno sobre la inversión satisfactorio en su realización y para alinear las pruebas con las percepciones de valor de los patrocinadores del proyecto. Hemos de dar valor a logros tales como disminución de la incertidumbre al planificar y mitigar tempranamente riesgos mayores en el proyecto de desarrollo. Debemos basarnos en decisiones comprometidas con el resultado y apoyadas en el análisis costo-beneficio. Esto implica que quien gerencia las pruebas deba estar informado no solamente del costo de las mismas sino también de los beneficios aportados al proyecto debidos a su realización correcta y oportuna. Para realizar un análisis adecuado se deben conocer tanto los costos como los beneficios ya sean estos tangibles o intangibles (y deseablemente para varios enfoques alternativos de proyecto, para así decidir por la mejor opción)

56 BACKUP SLIDES

57 Arquitectura de Ambiente Desarrollo y Mantenimiento Aseguramiento y Control de Calidad de Productos Administración de Proyectos Contratación de la Adquisición Administración Técnica de Adquisiciones Administración y Desarrollo de Requerimientos Desarrollo de Soluciones Integración del Producto Aseguramiento de Calidad Organizacional de Procesos Administración de Configuración y Cambios Medición y Análisis Análisis y Toma de Decisiones Mejora Continua de Procesos Capacitación Organizacional Administración de Proveedores y Contratos Organizacionales Principales Soporte Adquisiciones Desarrollo Por Proyecto Rational Unifed Process Rational RequisitePro Rational RequisitePro Web Rational Functional Tester Rational Robot Performance Tester Rational ClearQuest Rational Software Arquitect Rational RequisitePro Rational RequisitePro Web Rational Unified Process Rational Software Modeler Rational RequisitePro Rational RequisitePro Web Rational ClearCase Rational ClearQuest Rational Method Composer Rational ClearQuest Web Rational ClearCase Rational ClearQuest

58 Un buen conjunto de datos de prueba es el que posee una gran probabilidad de detectar un error no descubierto, no aquel que muestra que el programa se comporta correctamente. Uno de los problemas más difíciles con que se tropieza en una prueba es saber cuándo detenerse. Es imposible que usted pruebe su propio programa. La descripción de la información de salida o de los resultados esperados, es un elemento imprescindible de todo conjunto de datos de prueba. Evite las pruebas no repetibles o reproducibles. Desarrolle datos de prueba que contengan información de entrada relativa a condiciones válidas o inválidas. Examine y revise cuidadosamente los resultados de cada prueba. Con el incremento del número de errores encontrados en un programa, aumenta igualmente la probabilidad de la existencia de errores no descubiertos. Asigne la tarea de prueba a los programadores con mayor creatividad. Asegúrese que se hallan contemplado en el diseño y estructura del programa, las facilidades para una prueba adecuada. El diseño del sistema debería contemplar y asegurar que cada módulo sea integrado con el sistema una sola vez. No altere nunca el programa para que la prueba resulte más fácil. La prueba, como cualquier otra actividad, debe comenzar con el establecimiento de los objetivos pertinentes.

59 Documentación relacionada con la ejecución de las pruebas según el estándar IEEE 829 Ejecución de Ciclos de Prueba Reportes de Errores Reporte del Ciclo I Reporte del Ciclo N Reporte de Errores Historia de la Ejecución de Pruebas Especificaciones de Prueba

60 Ontology of software testing Basic Concepts Tester Context Method Environment Artefact Activity SW testing Concepts Compound Concepts Capability Task Relations Basic relations Compound relations Capable_of More_ powerful Subsumes

61 Algunos Estándares IEEE 730 Software Quality Assurance Plans IEEE 730.1 Guide for Software Assurance Planning IEEE 982.1 Standard Dictionary of Measures to Produce Reliable Software IEEE 1061 Standard for a Software Quality Metrics Methodology ISO/IEC 9126-1 Software Engineering - Product Quality - Part 1: Quality Model ISO/IEC 12119 Information Technology-Software Packages-Quality Requirements and Testing ISO/IEC 14598-1 Information Technology-Evaluation of Software Products-General Guide ISO/IEC 25030 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements

62 Estándares Argentinos (IRAM) IRAM-ISO/IEC 14598-1 Tecnología de la información - Ingeniería de software. Evaluación del producto de software. Parte 1: Descripción general. IRAM-ISO-IEC 14598-2 Tecnología de la información - Ingeniería de software. Evaluación del producto de software. Parte 2: Planificación y gestión. IRAM-ISO-IEC 14598-3 Tecnología de la información - Ingeniería de software. Evaluación del producto de software. Parte 3: Proceso para desarrolladores (en estado de Proyecto, última etapa del proceso de elaboración). IRAM-ISO-IEC 14598-4 Tecnología de la información - Ingeniería de software. Evaluación del producto de software. Parte 4: Proceso para compradores (próxima a salir a discusión pública). IRAM-ISO-IEC 14598-5 Tecnología de la información - Ingeniería de software. Evaluación del producto de software. Parte 5: Proceso para evaluadores (en estudio). IRAM-ISO/IEC 90003 Ingeniería de software. Directrices para la aplicación de norma IRAM-ISO 9001:2000 al software. IRAM-ISO-IEC 20000-1 Tecnología de la información - Gestión de los servicios. Parte 1: Especificación (en estudio).

63 Ahooros generados por la calidad Unit Test Production Code El COSTO de REPARAR un DEFECTO Planning Analysis System Design $140 Unit Test $1000 Code $14000 La inversion, los recursos y el esfuerzo se incrementan exponencialmente cuanto mas se avanza en el proyecto Fuentes: Cutter Consortium/Forrester/Sogeti Integration Test $2500 System Test $4500 Certification Test $7000

64 EvalProSoft El nivel de madurez de capacidades de una organización corresponde máximo nivel de capacidad alcanzado por todos los procesos evaluados El modelo está basado en el ISO/IEC 15504-2 Miguel Orozco - Ultasist

65 COMPETISOFT Visión General Actualmente el modelo se está robusteciendo en el proyecto COMPETISOFT a nivel Iberoamérica Miguel Orozco - Ultasist

66 ISO/IEC 29119, una nueva norma para pruebas software Javier Tuya, miembro del workgroup de ISO JTC1/SC7/WG26 - Software Testing que elabora el nuevo estándar ISO/IEC 29119

67 El Problema: es usual que... Demasiado que probar... Las pruebas pueden exceder en un 50% a los costos de desarrollo Ejemplo: 20 variables, 10 valores cada una 10 20 combinaciones ¿Cuales probamos?

68 La Actualidad

69 Procesos de negocio interdependientes Incremento del número de lenguajes Sistemas distribuídos Integración de Paquetes Plataformas heterogéneas El aumento de tamaño y complejidad del software requiere un enfoque más riguroso del desarrollo de aplicaciones Complejidad

70 Source: THE STANDISH GROUP 2003 90% Delivered Late 66% Were not Considered Successful Source: THE STANDISH GROUP 2003 54% Delivered over Budget Cancelled prior to Completion 30% Estamos Fallando!!! Las estadísticas son alarmantes 50 60 70 80 90 100 % 0 10 20 30 40