stringtranslate.com

Clasificación de defectos ortogonales

La clasificación ortogonal de defectos ( ODC ) [1] convierte la información semántica en el flujo de defectos del software en una medición del proceso. [2] Las ideas fueron desarrolladas a fines de la década de 1980 y principios de la década de 1990 por Ram Chillarege [3] en IBM Research . Esto ha llevado al desarrollo de nuevos métodos analíticos utilizados para el desarrollo de software y el análisis del proceso de prueba. ODC es independiente del modelo de proceso, del lenguaje y del dominio. Varias corporaciones han informado sobre aplicaciones de ODC en una variedad de plataformas y procesos de desarrollo, que van desde procesos de desarrollo en cascada , espiral, controlados y ágiles [4] [5] . Una de las aplicaciones populares de ODC es el análisis de causa raíz del software .

Se sabe que el ODC reduce el tiempo que lleva realizar un análisis de causa raíz en más de un factor de 10. Las ventajas provienen principalmente de un enfoque diferente para el análisis de causa raíz, donde los datos del ODC se generan rápidamente (en minutos, en lugar de horas por defecto) y se utilizan análisis para el análisis de causa y efecto. Esto desplaza la carga del análisis de un método puramente humano a uno que requiere más datos. [6]

El ODC, tal como se propone en sus artículos originales, tiene conjuntos de atributos y valores específicos que crean mediciones sobre el proceso de desarrollo. Dos de las cinco categorías más conocidas son el tipo de defecto y el desencadenante del defecto . El tipo de defecto captura los cambios realizados en el código como resultado del defecto. Hay siete valores para el tipo de defecto y se han establecido empíricamente para proporcionar una medición del producto a través del proceso mediante su distribución. El concepto es que los cambios en la distribución del tipo de defecto son una función del modelo del proceso de desarrollo y, por lo tanto, proporcionan una medición intrínseca del progreso del producto a través del proceso.

El disparador de defectos, de manera similar, proporciona una medición del proceso de prueba. El concepto de disparador es una contribución clave que se realizó a través de ODC y ahora se usa bastante ampliamente en publicaciones técnicas y de investigación. [7] El disparador de software se define como la fuerza que hizo que aflorara la falla para crearla. El conjunto completo de disparadores está disponible en la Documentación de ODC.

El tipo de defecto y el desencadenante proporcionan en conjunto una gran cantidad de información causal sobre los defectos. La información adicional del defecto que se captura en las implementaciones estándar de ODC incluye "impacto", "origen" y "antigüedad". Los cursos de capacitación de ODC informan que, una vez capacitado, una persona puede categorizar un defecto mediante ODC en menos de 3 minutos al realizar la tarea de forma retrospectiva. [8] El tiempo que se tarda es mucho menor cuando se realiza en vuelo o en proceso. La categorización no se puede comparar directamente con el análisis de causa raíz, ya que los datos de ODC se refieren a "qué es", no a "por qué". Sin embargo, el análisis de causa raíz se realiza muy comúnmente utilizando ODC. El análisis que estudia los datos de ODC realiza el primer paso del análisis de causa raíz, que se confirma al discutir los resultados con el equipo de desarrollo. Este enfoque tiene cinco diferencias principales entre el método clásico y el método ODC. [9]

El análisis de causa raíz es sólo una de las aplicaciones del ODC. El diseño original del ODC fue crear un sistema de medición para la ingeniería de software utilizando el flujo de defectos como fuente de mediciones intrínsecas. De este modo, los atributos, ya sea de forma individual o en conjunción con uno de los otros, proporcionan mediciones específicas sobre ciertos aspectos del proceso de ingeniería. Estas mediciones se pueden utilizar para uno o más métodos analíticos, ya que se diseñaron teniendo en cuenta los principios generales de medición. Hasta el momento, varios artículos de investigación los han aplicado para diversos fines. Más recientemente, ha habido artículos de investigación que utilizan el ODC para evaluar los métodos utilizados para la evaluación de la seguridad y han ampliado el alcance del ODC. [10]

Referencias

  1. ^ Clasificación de defectos ortogonales: un concepto para mediciones en proceso, IEEE Transactions on Software Engineering, noviembre de 1992 (vol. 18, núm. 11). http://www.chillarege.com/articles/odc-concept.html
  2. ^ ¿ Qué es ODC? https://www.youtube.com/watch?v=mno4pQMqtBM
  3. ^ Premio al logro técnico 2002 de la IEEE Computer Society https://www.computer.org/profiles/ram-chillarege
  4. ^ Clasificación de defectos ortogonales (ODC) en el desarrollo ágil. M. Jagia, S. Meena, Actas complementarias de IEEE ISSRE 2009, noviembre de 2009.
  5. ^ Clasificación de defectos ortogonales: una introducción a las pruebas y el control de calidad ágiles, Conferencia sobre desarrollo ágil, noviembre de 2012
  6. ^ "ODC: un análisis de causa raíz diez veces mejor", R. Chillarege 2006
  7. ^ Defectos de software y su impacto en la disponibilidad del sistema: un estudio de fallas de campo en sistemas operativos. M. Sullivan y R. Chillarege, IEEE 21st Fault-Tolerant Computing Systems, 1991.
  8. ^ Diamantes a partir de defectos, conferencia magistral de LADC, http://www.unicauca.edu.co/ladc2016/?q=node/22
  9. ^ "5 diferencias entre el análisis de causa raíz clásico y el análisis de causa raíz ODC. https://www.youtube.com/watch?v=fTJr2Pgnxco
  10. ^ PJ Morrison, R. Pandita, X. Xiao, R. Chillarege y L. Williams, “¿Las vulnerabilidades se descubren y resuelven como otros defectos?”, Empir Software Eng, vol. 23, núm. 3, págs. 1383–1421, junio de 2018, doi: 10.1007/s10664-017-9541-1.

Enlaces externos