Calidad y modelo de negocios

El 4 de marzo, James Bach escribe que "La calidad está muerta" en la creación de software. Pero el desarrollo de su nota apunta más bien a un modelo de negocios, antes que a una posición general sobre el desarrollo de software siguiendo patrones de calidad.
Ciertamente apunta a un problema su indicación de que la cesión del desarrollo y actividade de control a terceros a través del outsourcing disminuye la calidadad del producto. Al menos, es frecuente la crítica de desconexión entre solicitante y encargado de los trabajos, así como la desconfianza en la real capacidad de empresas (abundantes referencias a India), y la devaluación de algunas certificaciones de calidad.
También es cierto que la media probablemente maneja criterios mucho más laxos que los recomendables tanto en la construción como en el control, y no alcanzarían varias páginas para dar ejemplos.
Lo importante de su observación es que, si las empresas que desarrollan software, y aquí habla de aquellas cuyo negocio es esto mismo, si estas empresas son empujadas por el mantenimiento de un retorno elevado de utilidades, entran en un ciclo de renovación de productos que termina degradando la calidad de aquello que entregan. Bach habla reiteradamente de quien probablemente sea el mayor impulsor de este modelo, Microsoft, señalando en las sucesivas entregas de versiones de Windows un grado de inmadurez que ha terminado minando la confianza en sus productos.
Estamos ante una crisis que parece que marcha a ser mayor que la de 1930. ¿Se generalizarán las malas prácticas en pro del abaratamiento del producto final, o se mantendrá un modelo más conservador? Estas son épocas de crudo darwinismo. Quizá el más fuerte no sea el mejor.

Material sobre Testeo, y más

Finalmente, con un poco de tiempo disponible, hice dos o tres cambios a los enlaces, agregando varios que tenía interés en compartir, aunque quedan otros futuros candidatos, que agregaré basado en la frecuencia de su utilidad. Tres incluídos son sobre Testeo: Testing reflections, Cem Kaner y James Bach. Kaner, especialmente, extiende su interés como analista de testing desde un punto de vista más amplio (a propósito, en algún momento habrá que tomar sus comentarios sobre el SWEBOK 1 y 2). Dos candidatos en el área de testing que seguramente incluiré son Pavankumar Pothuraju y Pradeep Soundararajan, que muestran a India en su estado actual, y su potencia futura.

Cem Kaner: un poco de teoría sobre Testing

Encontré a Cem Kaner a través de otro comentario de James Bach, otro especialista en testing. Su blog aporta una serie de notas consistentes sobre Testeo de Software. Lo agendé en del.icio.us, y en unos días trataré de registrarlo separando los conceptos que desarrolla. Por ahora, sólo para no perder su nombre.

Bijay Jayaswal y Peter Patton sobre métricas de calidad

Developer publica un artículo sobre métricas de software que tiene la virtud de estar soportado por una visión de la calidad que supera el usual enfoque "especialista". Son destacables tres aspectos: la recuperación de la importancia de los teóricos de Calidad Total (TQM) en los orígenes de la disciplina; la atención dedicada a los problemas de arquitectura (a propósito, los autores entregan también una definición de arquitectura); y la discusión de las métricas específicas al paradigma del análisis y la programación orientada a objetos. Sus puntos principales desarrollados:

• 
  

• Historically software quality metrics have measured exactly the opposite of quality—that is, the number of defects or bugs per thousand lines of code.
• Software is a multidimensional concept that can be viewed from many professional and user viewpoints.
• Two leading firms in customer-focused software quality are IBM and Hewlett-Packard.
• IBM has a proprietary measure set, whereas HP uses five Juran quality parameters.
• The Naval Air Systems Command coined the term Total Quality Management (TQM) in 1985 to describe its own quality improvement program. It soon spread worldwide.
• The four essential characteristics of a TQM program in any field are customer focus, process improvement, quality culture, and measurement and analysis.
• TQM made an enormous contribution to the quality of enterprise software in the early 1990s, just in time for the Y2K transition.
• Until recently, most software quality metrics were of an in-process nature; metrics to support DFTS must be applied upstream in the development process.
• Small programs (less than 100 LOC) exhibit 1.5 defects per KLOC. Large programs (more than 1,000 LOC) exhibit 1.5 defects per KLOC. Medium-sized programs often have only 0.5 defects per KLOC.
• Sophisticated software tools for measuring software quality, such as PAMPA, are beginning to appear.
• OOP goals in software reusability tend to enhance software quality as well.

"la calidad no es mi problema"

Alan Koch escribe en CM Crossroads acerca de los roles en la construcción de software de calidad, apuntando a un problema común: la separación de funciones diluye la responsabilidad en la obtención de un producto de calidad, y en la raíz del problema está el hecho de que ésta no se obtiene a posteriori, sino que se construye con el producto. Por lo tanto, su obtención es responsabilidad del proceso de construcción en sí (y sus actores):

Testers Don’t Assure Quality
(...) one of the premises for the “Quality is not my job” syndrome is the idea that the testers are responsible for assuring the quality of the product we are building. It turns out that this is not the case. Although the testers’ job revolves around quality, it is more about measuring quality that it is about assuring it.
Yes, testers find problems, which get fixed resulting in fewer problems. But do we ever expect the testers to find all of the defects in the product? We shouldn’t, because the complexity of our systems makes that an unreasonable expectation. The main value of testing is to demonstrate the degree to which the product can be trusted to satisfy the customers’ needs.
There is an important truism that says, “You can’t test quality into the product; it must be built in.” [El subrayado es mío] If quality must be built in, then who should be accountable for the quality of the product? Those who build it are the only people we can look to for a high-quality product. The developers are the source of the quality (or lack there of) that the testers measure.

¿Cómo se debe manejar la calidad? Como una visión global, una cultura de calidad:

A Culture of Quality
While it is advisable to integrate product quality into our developers’ accountabilities, this will work best within the context of a culture of quality. We need an organization that values the quality of what is done just as surely as it values productivity and speed.

In a quality-oriented organization, every individual is conscious of the quality of the end product and their own contributions to it.

• The developers strive for high-quality designs and code, not just for the sake of technical elegance, but mainly so it will satisfy the customer. Rather than slinging code, they carefully engineer a system.
• The Business Analyst strives not just to document the requirements, but mainly to provide the foundation the developers will need to build the right thing. Rather than merely writing a specification, the BA is the liaison between the customer and the developer, assuring that they understand each other.
• The project Manager strives not just to build a good plan and manage activities, but mainly to establish the environment in which the team can build the product the customer needs and deliver it when the customer needs it. Rather than giving orders and demanding results, the pM is enabling each team member to do his or her job well.
• The tester strives not just to find defects and point fingers, but mainly to determine the degree to which the product as it was built will actually meet the customer’s needs. Rather than telling the developers how bad their code is, the tester is helping the developers to do a better job on this project than they did on prior ones.

In an organization like this, no one will say, “Quality is not my job.” Rather, everyone is conscious of the ways in which quality is a part of their jobs.

Las afirmaciones de Koch remontan a los conceptos de Calidad Total, y han recorrido un ya largo camino en la industria. A pesar de las opiniones de muchos desarrolladores, contrarios a las ideas de emplear sistemas "fabriles", encontrarían muchas ideas estimulantes en el estudio de la evolución de los métodos de fabricación de los últimos treinta o cuarenta años (Lean Manufacturing, Just in Time)

IBM: Clasificación ortogonal de defectos

Gracias a Pablo Sánchez, que en algún momento refirió el blog de Prasanna Kumar, dí con la clasificación de IBM, actualizada por última vez en febrero de 2002 (link en el título de esta nota).
Así se introduce el problema en el Center for Software Engineering, de IBM:

Traditionally, defects represent the undesirable aspects of a software's quality. Root Cause Analysis (RCA)and Statistical Growth Modeling (e.g. S-curves) have played useful roles in the analysis of software defects. Effective RCA, while yielding exhaustive details on each defect, takes substantial investment of resources for completion and points to too many actions as a result. Growth modeling, on the other hand, provides an easy way to monitor trends, but is not capable of suggesting corrective actions due to the inadequate capture of the semantics behind the defects.

ODC is a scheme to capture the semantics of each software defect quickly. It is the definition and capture of defect attributes that make mathematical analysis and modeling possible. Analysis of ODC data provides a valuable diagnostics method for evaluating the various phases of the software life cycle (design, development, test and service) and the maturity of the product. This is much like the diagnostics done in medicine using the blood sample from a patient to understand the existing health conditions and arrive at corrective actions. ODC makes it possible to push the understanding and use of defects well beyond quality.

ODC puede representar una buena guía de referencia en el seguimiento de defectos. Probablemente pase a formar parte de mis guías rápidas de trabajo.

Global Tester: SQA, Metodos de manejo de la Calidad

Jeff Nyman sostiene Global Tester, un sitio dedicado al manejo de calidad en la construcción de software, con énfasis en el testeo. Qué dice sobre el concepto:

GlobalTester is a repository of open content information regarding subjects related to Quality Assurance, Quality Control, and Quality Testing. To state what GlobalTester is, it is helpful to consider its goals. One goal of GlobalTester is to provide a wide variety of information about various aspects of a quality initiative that can be used in a variety of organizations that act to bring a product to market, whether that product is hardware, software, Web sites, or anything else within the domain of the Information Technology (IT) industry. On a practical side, a goal of GlobalTester is to be two things simultaneously: (1) a diverse toolbox and repository of methodologies, methods, and practices for a robust quality initiative, and (2) a testing solution framework that emphasizes a broad view of testing to include non-exectuable and executable elements of a development lifecycle and that seeks to promote ways of thinking as well as ways of doing. Another goal of GlobalTester is to be as independent as possible of different management structures, specific tools and software, and staffing realities so as to present a large selection of topics that one can pick and choose from based on relevance and interest.

Qué dice sobre sí mismo Jeff:

Any time a site like this pops up it is logical and prudent to ask what makes the author of the site (and its contents) claim to be an expert in the field that they are talking about. In my case the answer is: absolutely nothing. In general, there is nowhere that I will claim to be an "expert", whatever that truly might be in the context of Quality Assurance. In fact, like everyone else in the industry, I am in a constant state of learning. Thus, even when I learn something there is always the corollary that tells me I have a lot more to learn. The only claim I will categorically make is that I am an individual that is committed to Quality Assurance in my professional life (and even my personal one to a large extent) and that I am committed to disseminating as much information as I can about Quality Assurance to the widest possible audience. I also make the claim that anything I present on this site has had the potential to save me a lot of time and effort at various organizations with which I have been employed. Perhaps more importantly, anything I present on this site has led to improvements in the overall quality efforts and initiatives of which I have been a part.

Adhiero a su punto de vista...( también puedo decir, "especialista en nada, e interesado en todo")

Análisis de productividad

Middleware Research ha desarrollado varios análisis de productividad y comparaciones de rendimiento de herramientas basadas en principios MDA. Estas debieran constituír una fuente de estudio para aquellos que desean mejorar la productividad y calidad en el desarrollo de sus aplicaciones. Una lectura de estos estudios debiera servir para comprender la ventaja ganada por enfoques orientados al diseño de un modelo, y las IDEs de corte "tradicional". Puede verse la batería de análisis en su página de Investigaciones.