{"id":179,"date":"2012-10-28T11:23:07","date_gmt":"2012-10-28T10:23:07","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=179"},"modified":"2013-01-05T11:23:41","modified_gmt":"2013-01-05T10:23:41","slug":"software-quality-2012","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/software-quality-2012\/","title":{"rendered":"Software Quality 2012"},"content":{"rendered":"

\"\"<\/a>He recibido alg\u00fan material de Capers Jones, autor bien conocido y conferenciante internacional (no es necesario presentarle, pero por si acaso: http:\/\/www.namcook.com\/aboutus.html<\/a>). Capers Jones es vicepresidente y director de tecnolog\u00eda (CTO) de Namcook Analytics LLC.<\/p>\n

Es una buena s\u00edntesis del estado actual de la calidad del software, por lo que acabo de hacer un resumen de los puntos principales, que nos da la oportunidad de hacer algunas preguntas a Capers.<\/p>\n

<\/p>\n

Introducci\u00f3n<\/strong><\/h3>\n

En 2012, m\u00e1s de la mitad de los proyectos de software por encima de 10 000 Puntos de Funci\u00f3n o Function Points (alrededor de 1 000 000 l\u00edneas de c\u00f3digo) se cancelan o se retrasen por m\u00e1s de un a\u00f1o. La siguiente tabla muestra los resultados de 13 000 proyectos clasificados en seis tama\u00f1os diferentes, y los porcentajes de los que est\u00e1n a tiempo, temprano, tarde o cancelado.<\/p>\n

Table 1: Software Project Outcomes By Size of Project <\/span><\/strong><\/em><\/p>\n\n\n\n\n\n\n\n\n\n\n\n
<\/td>\nEarly<\/strong><\/td>\nOn-Time<\/strong><\/td>\nDelayed<\/strong><\/td>\nCanceled<\/strong><\/td>\n<\/tr>\n
1 FP<\/td>\n14.68%<\/td>\n83.16%<\/td>\n1.92%<\/td>\n0.25%<\/td>\n<\/tr>\n
10 FP<\/td>\n11.08%<\/td>\n81.25%<\/td>\n5.67%<\/td>\n2.00%<\/td>\n<\/tr>\n
100 FP<\/td>\n6.06%<\/td>\n74.77%<\/td>\n11.83%<\/td>\n7.33%<\/td>\n<\/tr>\n
1 000 FP<\/td>\n1.24%<\/td>\n60.76%<\/td>\n17.67%<\/td>\n20.33%<\/td>\n<\/tr>\n
10 000 FP<\/td>\n0.14%<\/td>\n28.03%<\/td>\n23.83%<\/td>\n48.00%<\/td>\n<\/tr>\n
100 000 FP<\/td>\n0.00%<\/td>\n13.67%<\/td>\n21.33%<\/td>\n65.00%<\/td>\n<\/tr>\n
Average<\/em><\/td>\n5.53%<\/em><\/td>\n56.94%<\/em><\/td>\n13.71%<\/em><\/td>\n23.82%<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Q: \u00bfC\u00f3mo ha conseguido todos estos datos sobre todos estos proyectos? \u00bfSon todos de EE.UU.?<\/em><\/p>\n

He trabajado en IBM y ITT y ten\u00eda acceso a todos sus datos internos. Tambi\u00e9n ten\u00eda un equipo de una docena de consultores que traen los datos de 25 a 75 proyectos por mes a partir de cientos de empresas. He trabajado en 24 pa\u00edses, pero alrededor del 90% de los datos de la tabla es de los EE.UU.
\n<\/em><\/p>\n

Los mejores pa\u00edses para la calidad son Jap\u00f3n y la India. Productividad es algo m\u00e1s complejo debido a enormes variaciones en las horas de trabajo. En los EE.UU. tenemos una semana nominal de 40 horas, de 44 horas en Jap\u00f3n, s\u00f3lo 36 horas en Canad\u00e1. Tambi\u00e9n hay diferencias importantes en las vacaciones y los d\u00edas festivos. Esto es demasiado complicado para una respuesta r\u00e1pida.<\/em><\/p>\n

Q: Usted dice que 10 000 FP es de aproximadamente 1 000 000 l\u00edneas de c\u00f3digo. \u00bfEs esta una medida que alguien puede utilizar para comparar sus proyectos con estos datos, cuando no tiene estimaci\u00f3n de FP? \u00bfO hay alguna otra medida como, por ejemplo, el tama\u00f1o del equipo de desarrollo, el n\u00famero de a\u00f1os\/hombre?<\/em><\/p>\n

La proporci\u00f3n de tratamientos de c\u00f3digo respecto a un punto de funci\u00f3n se llama \u201cbackfiring\u201d<\/em> y fue desarrollado por primera vez en los a\u00f1os 70 por IBM. La proporci\u00f3n var\u00eda seg\u00fan el lenguaje o la combinaci\u00f3n de tecnolog\u00edas. COBOL es aproximadamente 105,7 sentencias por punto de funci\u00f3n; C es de unos 128 declaraciones por punto de funci\u00f3n, Java es cerca de 53 sentencias por punto de funci\u00f3n. Varias compa\u00f1\u00edas venden listas de esos ratios para 1000 lenguajes de programaci\u00f3n.<\/em><\/p>\n

Volumen de defectos<\/strong><\/h3>\n

Al examinar los proyectos con problemas de software, la principal raz\u00f3n de demora o de cancelaci\u00f3n se debe a un volumen excesivo de defectos graves. La tabla 2 muestra los vol\u00famenes promedio de defectos encontrados en los proyectos de software, y el porcentaje de defectos removidos antes de la entrega a los clientes, por diferentes or\u00edgenes.<\/p>\n

Table 2: Defect Removal Efficiency By Origin of Defects Circa 2012<\/strong><\/em><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Defect Origins<\/strong><\/td>\nDefect potentials<\/strong><\/td>\nRemoval Efficiency<\/strong><\/td>\nDelivered Defects<\/strong><\/td>\n<\/tr>\n
Requirements<\/td>\n1.00<\/td>\n77%<\/td>\n0.23<\/td>\n<\/tr>\n
Design<\/td>\n1.25<\/td>\n85%<\/td>\n0.19<\/td>\n<\/tr>\n
Coding<\/td>\n1.75<\/td>\n95%<\/td>\n0.09<\/td>\n<\/tr>\n
Document<\/td>\n0.60<\/td>\n80%<\/td>\n0.12<\/td>\n<\/tr>\n
Bad Fixes<\/td>\n0.40<\/td>\n70%<\/td>\n0.12<\/td>\n<\/tr>\n
Total<\/em><\/td>\n5.00<\/em><\/td>\n85%<\/em><\/td>\n0.75<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

(Datos en defectos por Function Point)<\/p>\n

Q: Podemos ver en la tabla anterior que los potenciales defectos de c\u00f3digo son por encima de los otros. \u00bfRespecto a eso, ha visto usted una evoluci\u00f3n entre las diferentes tecnolog\u00edas utilizadas en los proyectos? Mucha gente piensa que las nuevas tecnolog\u00edas, porque m\u00e1s complejas, son m\u00e1s propensas a introducir defectos?<\/em><\/p>\n

Defectos de c\u00f3digo est\u00e1n principalmente <\/em>relacionados con el nivel de tecnolog\u00edas utilizadas. Cada fuente de defectos se ve afectada por la complejidad, y aplicaciones multi-capas como cliente-servidor tienen m\u00e1s defectos de dise\u00f1o y de requisitos<\/em>.
\n<\/em><\/p>\n

Q: Podemos ver tambi\u00e9n que defectos de requisitos y de dise\u00f1o son m\u00e1s numerosos que los defectos de c\u00f3digo. La misma pregunta: \u00bfha visto all\u00ed cualquier evoluci\u00f3n? Con el \u00e9nfasis puesto en la externalizaci\u00f3n y el outsourcing, se podr\u00eda pensar que esos defectos suceden m\u00e1s y m\u00e1s frecuentes. <\/em><\/p>\n

Existen herramientas eficaces, como Flesch y FOG, de an\u00e1lisis de texto o de UML que pueden reducir los defectos de requisitos. Tambi\u00e9n de modelizaci\u00f3n de requisitos y de ‘pattern matching’. Usuarios Agile integrados pueden ayudar tambi\u00e9n, pero con l\u00edmites. Un solo usuario no puede entender todas las funcionalidades de una aplicaci\u00f3n de 10 000 puntos de funci\u00f3n o de 10 000 usuarios.<\/em><\/p>\n

La industria del software deber\u00eda utilizar m\u00e9todos de requisitos y de dise\u00f1o en 3D – no s\u00f3lo diagramas de texto y est\u00e1ticos. Si utilizas m\u00e9todos adecuados, tienes alta calidad y plazos cortos al mismo tiempo.<\/em><\/p>\n

De hacer un trabajo pericial en juicios sobre los proyectos que fracasan, la mayor parte falla debido a un pobre control de cambios y de calidad. Demasiados bugs antes de la fase de QA extienden los ciclos de prueba de una manera casi infinita.<\/em><\/p>\n

Dos estrategias se necesitan para un control de calidad con exito:<\/p>\n

    \n
  1. La reducci\u00f3n de los vol\u00famenes de defectos y defectos potenciales.<\/li>\n
  2. El aumento de la eficiencia de eliminaci\u00f3n de defectos (Defect Removal Efficiency o DRE). Podemos notar que DRE no es muy bueno para los defectos que no son de c\u00f3digo.<\/li>\n<\/ol>\n

    Reducci\u00f3n de volumenes de defectos
    \n<\/strong><\/h3>\n

    Algunos de los m\u00e9todos que reducen defectos incluyen:<\/p>\n

      \n
    • Modelizaci\u00f3n de requisitos.<\/li>\n
    • Herramientas de an\u00e1lisis est\u00e1tico de requisitos que pueden encontrar errores y ambig\u00fcedades.<\/li>\n
    • Requisitos formalizados y inspecciones de dise\u00f1o.<\/li>\n
    • Usuarios incorporados, como se encuentra en desarrollo Agile.<\/li>\n
    • Desarrollo basado en prueba, cuando dise\u00f1o est\u00e1 precedido por la definici\u00f3n de las pruebas.<\/li>\n
    • Prototipos para minimizar los cambios de requisitos.<\/li>\n
    • Revisi\u00f3n formal de todas las solicitudes de cambio (Change Requests).<\/li>\n
    • Herramientas automatizadas de control de cambios con capacidades de referencias cruzadas.<\/li>\n<\/ul>\n

      Cuando inspecciones formales se a\u00f1aden al ciclo de desarrollo, los potenciales defectos gradualmente se reducen de 5 por punto de funci\u00f3n por debajo de 3 por punto de funci\u00f3n, mientras que los niveles de eficiencia de eliminaci\u00f3n de defectos (DRE) llegan al 95% y hasta pueden alcanzar 99%.<\/p>\n

      An\u00e1lisis de c\u00f3digo es una forma relativamente nueva de eliminar defectos, que tambi\u00e9n tiene beneficios en t\u00e9rminos de prevenci\u00f3n de defectos.<\/p>\n

      Un aspecto interesante del control de los requisitos es la reducci\u00f3n de los cambios no planificados o \u201crequirements creep\u201d. Proyectos donde los requisitos son cuidadosamente recogidos y analizados consiguen s\u00f3lo una fracci\u00f3n de 1% por mes en los cambios planificados. Joint Application Design (JAD), prototipos, y inspecciones de requisitos son efectivos en la reducci\u00f3n de \u201crequirements creep\u201d.<\/p>\n

      Aumentar los niveles de eficiencia de eliminaci\u00f3n de defectos (DRE)<\/strong><\/h3>\n

      Muchas formas de pruebas realizadas por los desarrolladores tienen menos de 35% de eficiencia en la b\u00fasqueda de errores o defectos, aunque unos superan 50%. QA con pruebas formalizadas y con personal certificado es por lo general con frecuencia por encima de 50%.<\/p>\n

      Dise\u00f1o formal e inspecciones de c\u00f3digo superan 65% de eficiencia en la b\u00fasqueda de errores o defectos y a veces 85%. Las inspecciones tambi\u00e9n aumentan la eficiencia al proporcionar pruebas m\u00e1s completas para el personal de la prueba.<\/p>\n

      El an\u00e1lisis de c\u00f3digo es tambi\u00e9n alto en eficiencia contra muchos tipos de defectos. Por lo tanto, todos los proyectos en empresas l\u00edderes utilizan combinaciones sin\u00e9rgicas de inspecciones formales, an\u00e1lisis de c\u00f3digo y QA.<\/p>\n

      Esta combinaci\u00f3n es la \u00fanica forma conocida de conseguir niveles de eliminaci\u00f3n de defectos superiores a 98%, permite plazos de desarrollo m\u00e1s cortos y reduce las probabilidades de errores en los proyectos.<\/p>\n

      Q: En los m\u00e9todos anteriores, algunos son automatizados y podr\u00eda ser m\u00e1s barato, otros \u2013 como el dise\u00f1o formalizado e inspecciones de c\u00f3digo \u2013 no pueden automatizarse, y por lo tanto son probablemente m\u00e1s caro. \u00bfAlguna vez ha tratado de definir una relaci\u00f3n entre el costo y la eficiencia de estos m\u00e9todos?<\/em><\/p>\n

      Usted se equivoca. Antes de que IBM introdujo inspecciones para el desarrollo de una base de datos, la fase de QA necesitaba 3 meses de pruebas. Despu\u00e9s inspecciones, la fase de pruebas se redujo a 1 mes. Las inspecciones ncesitaron cerca de 6 semanas. Hubo una reducci\u00f3n en los costos y los plazos y un aumento en la eficiencia de eliminaci\u00f3n de defectos, que estaba por debajo de 85% hasta m\u00e1s del 95%, al mismo tiempo.<\/em><\/p>\n

      Su pregunta refleja un problema com\u00fan \u2013 <\/em>la mayor\u00eda de las empresas no miden lo suficiente como para entender la econom\u00eda de la calidad. Tengo datos sobre los costes comparativos de cada combinaci\u00f3n de inspecciones, an\u00e1lisis de c\u00f3digo y pruebas. Los mejores resultados se obtienen con una combinaci\u00f3n sin\u00e9rgica de la prevenci\u00f3n de defectos, eliminaci\u00f3n de defectos preliminarios y pruebas realizadas por personal certificados.<\/em><\/p>\n

      Q: \u00bfLa eficacia de estos m\u00e9todos var\u00eda dependiendo del tama\u00f1o de un proyecto? Uno puede pensar instintivamente que cuanto mayor sea el proyecto, mayor ser\u00e1 el riesgo de encontrar defectos de dise\u00f1o y de requisitos, mientras que los defectos de c\u00f3digo deben permanecer (m\u00e1s o menos) estable?<\/em><\/p>\n

      Cuando las aplicaciones crecen en tama\u00f1o, los defectos potenciales <\/em>se hacen m\u00e1s importantes y la eficiencia de eliminaci\u00f3n de los defectos disminuye. Es por eso que inspecciones y an\u00e1lisis de c\u00f3digo son m\u00e1s valiosos cuando las aplicaciones se hacen m\u00e1s grandes.<\/em><\/p>\n

      Q: Yo dir\u00eda que para los proyectos grandes, se recomienda industrializar todos estos m\u00e9todos. Sin embargo, para proyectos m\u00e1s peque\u00f1os o de tama\u00f1o medio, o para un equipo que todavia no utiliza estos m\u00e9todos, le recomendar\u00eda algunos que <\/em>considerar\u00eda m\u00e1s f\u00e1cil o m\u00e1s valioso para poner en pr\u00e1ctica por primera vez? Para decirlo de otro modo, \u00bfhay un mejor camino hacia la madurez?<\/em><\/p>\n

      Esto es una pregunta <\/em>demasiada complicada para una respuesta corta. El an\u00e1lisis de c\u00f3digo es barato, eficaz y f\u00e1cil de usar para todos los proyectos de todos tama\u00f1os. Por debajo de 1 000 puntos de funci\u00f3n, Agile est\u00e1 bien, por encima de los 10 000 puntos de funci\u00f3n, TSP es lo mejor. <\/em><\/p>\n

      Lo que las empresas necesitan no son respuestas generales, pero predicciones espec\u00edficas y un conjunto de m\u00e9todos \u00f3ptimos para proyectos espec\u00edficos. Mi trabajo principal es la construcci\u00f3n de herramientas que permitan predecir los resultados espec\u00edficos para proyectos concretos.<\/em><\/p>\n

      Q: Una \u00faltima pregunta, para concluir, y probablemente una acerca de la cual <\/em>la mayor\u00eda de las personas sienten curiosidad: \u00bfqu\u00e9 es un d\u00eda t\u00edpico para usted? Haciendo consultor\u00eda para un cliente? Trabajo sobre un papel o un nuevo libro? Ir a pescar o jugar al golf?<\/em><\/p>\n

      Hace a\u00f1os, cuando yo estaba trabajando en mi primer libro, yo ten\u00eda que estar en el trabajo a las 8:30 as\u00ed que empec\u00e9 a levantarme temprano para escribir a las 5 de la ma\u00f1ana. Despu\u00e9s de 15 libros, no puedo dormir tarde. Yo suelo escribir libros o art\u00edculos entre las 4 y las 10 AM., cambiar a tareas de software o de negocios desde las 10 AM hasta las 4 PM, y luego relajarme o jugar al golf despu\u00e9s. Tambi\u00e9n hago desporte en un gimnasio tres d\u00edas a la semana.<\/em><\/p>\n

      Gran parte de mis consultor\u00edas y discursos tambi\u00e9n son remotos. El 08 de noviembre estar\u00e9 en una conferencia en Estocolmo, Suecia. El tema es \u201cAchieving Software Excellence\u201d<\/em>. El 13 de noviembre, estoy haciendo un seminario sobre \u201cSoftware Risk and Value Analysis\u201d.<\/em> El 4 de diciembre, un webcast de IBM sobre \u201cMeasuring Software Quality and Customer Satisfaction\u201d<\/em>.<\/em><\/p>\n

      Hago viajes a conferencias m\u00e1s importantes, como para el Symposium japon\u00e9s on Software Testing, the Malaysian Testing Conferenc<\/em>, y conferencias para el International Function Point Users Group.<\/em><\/em><\/p>\n

      Capers, muchas gracias por el material que me ha enviado y por el tiempo para responder a mis preguntas.<\/p>\n","protected":false},"excerpt":{"rendered":"

      He recibido alg\u00fan material de Capers Jones, autor bien conocido y conferenciante internacional (no es necesario presentarle, pero por si acaso: http:\/\/www.namcook.com\/aboutus.html). Capers Jones es vicepresidente y director de tecnolog\u00eda (CTO) de Namcook Analytics LLC. Es una buena s\u00edntesis del estado actual de la calidad del software, por lo que acabo de hacer un resumen […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-179","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/179"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=179"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/179\/revisions"}],"predecessor-version":[{"id":180,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/179\/revisions\/180"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=179"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}