viernes, 30 de noviembre de 2012

Saving Money with Software Quality Assurance (SQA)

This is the first part of an article written by Hernan Gil


In this article we will see what is Software Quality Assurance (SQA), what are the economic benefits of its implementation and how it takes part on the early stages of the development process.
The main objective of implementations of the SQA discipline is to increase the quality of deliverables throughout the development process. Many quality requirements, especially those having to do with the performance, usability, load, availability, etc.. - Can be treated as hazards. That is, the fact that one of them is not met implies a risk.
Then, ensuring quality of software during its process, reduce risks and increase the predictability of software development. This brings with it a wide range of benefits of visibility. Among those that stand out, we can name:

  • Reduced development time, mainly generated rework time in the testing phase.
  • Optimizing the use of resources, reducing the cost of the infrastructure required to support the application.
  • Maintenance cost reduction, as they generate more stable and secure applications.
  • Increased change permeability and ease to measure its impact.
  • Compliance requirements, both functional as quality.
  • Tracking the defined standards.
  • Provides information about the quality of the project to the stake holders who have less technical knowledge.
  • Developments become more predictable, which makes estimates easier.
SQA activities in the development process
SQA is a discipline which is composed of a number of activities accompanying development process. The objective of this work is to enhance, manage, and monitor the quality of the built deliverables.
UP phases and disciplines




To identify these activities and the right time to perform them , it is necessary to review the life cycle of a project. For this we rely on the analysis of phases / disciplines / effort in UP, it is a process widely used in the market, however, the same analysis can be applied to other development processes. Analyzing the Phases diagram, we realize that the effort of each discipline varies by project phase.
From this it follows that the time to control the quality of each discipline is when more effort is devoted.
In healthy SQA initiatives, the impact of this should be reflected in all the artifacts that are generated in the development process. It should not be limited to testing or functional verification, which is a fairly widespread sense of SQA function, but diametrically misguided.
In a broader perspective SQA synergistic role in a development project, we find, among others, the following activities:
  • Requirements verification:  Aims to demonstrate that the definition of the requirements actually define the system that the user needs or the customer wants.
  • Validation and verification of requirements: They aim to show that the specification of the requirements actually define the application that user needs or the customer wants and that the system meets these needs.
  • Evaluate the architecture: It 's a very important activity to assess the feasibility of meeting non-functional requirements and early detection of the major risks associated with the project.
  • Design Control: It focuses on validate the logical design of the components, their distribution and interaction, to identify components which may be reusable, and the scope of the defined quality requirements of each.
  • Source Control: It is divided into two activities:
    • Static Control Code: The validation of the code against a set of rules, best practices and predefined standards.
    • Dynamic control code: Control focuses on the use of resources and the application does the coverage of code making unit tests.
  • Functional Testing: This is done near the end of the development stage, and is responsible for monitoring compliance with the functional requirements of the system and to detect errors more visible to the user.
  • Stress Test: Focuses on assessing the performance of the application for the simulation of peak activity times.
Previous Tasks


It is necessary to note that, for some of these activities, you first have to perform other, such as:
- Definition of standards and best practices development.
- Choice of tools to document and develop.
- Other
Performing these tasks is justified by the mere fact that, in order to validate the quality of any process, it is necessary to have, previously, the definition, requirement or standard against which to validate.

In the second article we explore the following topics: Analysis of costs, where do we start?, Quality metrics and Conclusions



Fernando Hunth





Economizar con Software Quality Assurance: Parte II

Parte II, por Hernan Gil

Análisis de costos
Implementar alguna o todas las actividades descriptas en la entrega anterior, implica tiempo, esfuerzo y, sin dudas, dinero. Por esa razón, es necesario analizar el ROI de esta implementación, para lo cual nos basaremos en un estudio que analiza las etapas de un proyecto tradicional, y los defectos introducidos, los encontrados y el costo de su reparación. Como se puede apreciar, la introducción del 85% de los defectos de la aplicación se produce al inicio de la etapa de construcción, pero estos defectos se van encontrando paulatinamente, en etapas posteriores.
Mientras más se demore en encontrar un error, más costoso será repararlo. Por eso se propone establecer actividades que acompañen al proceso de desarrollo (en vez de puntos de control), para maximizar la detección de defectos en cada etapa, y minimizar la cantidad y el impacto de los defectos que se encuentran en las etapas finales. Es importante tratar de calcular el costo de un defecto encontrado durante el testing versus encontrarlo luego de la puesta en producción, ya que el costo asociado a este último no es sólo el que se produce al generar una nueva versión, sino que también se le suma el del test de regresión, la nueva puesta en producción y el tiempo que esté bajo el sistema.

¿Por dónde empezamos?
Implementar todas las actividades de SQA al mismo tiempo es costoso e impráctico. Es mejor empezar por las actividades en las que se vean resultados de forma más rápida y efectiva.
Además, una implementación paulatina y retroalimentada ayudará a que el proceso sea más armonioso y fácilmente aceptado. Si se está en las etapas iniciales del proyecto, conviene empezar por la verificación de requerimientos y la validación de arquitectura, mientras que si ya se está avanzado, es mejor revisar el diseño o, directamente, el código.


Fases y disciplinas de UP: relación con las actividades de SQA.

Métricas de calidad
La única manera de mostrar cuáles son los beneficios que aportan las actividades de SQA es a través de métricas que reflejen la evolución del proceso de desarrollo. Si no podemos medir las mejoras, no podremos evaluar la efectividad del proceso de SQA y tampoco será posible mejorarlo. Ejemplos de este tipo de métricas podrían ser:

  • Número de incidencias reportadas en producción.
  • Número de incidencias reportadas en testing.
  • Cantidad de ciclos de testing/retrabajo necesarios.
  • Tiempo necesario para realizar un cambio (categorizado por impacto).

Conclusiones
SQA es un conjunto de actividades que tienen como objetivo bajar el costo de desarrollo para alcanzar los parámetros de calidad establecidos.
Es factible alcanzar calidades y costos determinados, pero es necesario saber que no es posible insertar calidad deseada al final del proceso de desarrollo, sino que se debe crear a lo largo de todo el proceso. Cuanto antes se comience con las actividades de SQA, mayores serán los beneficios obtenidos.

viernes, 23 de noviembre de 2012

Economizar con Software Quality Assurance: Parte I


Economizar con Software Quality Assurance: Parte I, por Hernan Gil

En el presente artículo veremos qué es Software Quality Assurance (SQA), cuáles son los beneficios económicos de su implementación y cómo interviene en las etapas del proceso de desarrollo.

La implementación de una disciplina de SQA tiene como principal objetivo aumentar la calidad de los entregables durante todo el proceso de desarrollo. Muchos requerimientos de calidad –sobre todo, aquellos que tienen que ver con la performance, la usabilidad, la carga, la disponibilidad, etc. – pueden ser tratados como riesgos. Es decir que el hecho de que uno de ellos no se cumpla implica un peligro.
Entonces, al asegurar la calidad del software durante su proceso, se disminuyen los riesgos asociados y se aumenta la predictibilidad del desarrollo de software. Esto trae aparejada una serie de beneficios de variada visibilidad. Entre los que más se destacan, podemos nombrar:

  • Reducción de los tiempos de desarrollo, principalmente, el tiempo de retrabajo generado en la fase de testing.
  • Optimización del uso de los recursos, que disminuye el costo de la infraestructura necesaria para soportar la aplicación.
  • Disminución del costo de mantenimiento, ya que se generan aplicaciones más seguras y estables.
  • Aumento de la permeabilidad al cambio y facilidad para medir su impacto.
  • Cumplimiento de los requerimientos, tanto los funcionales como los de calidad.
  • Seguimiento de los estándares definidos.
  • Provee información sobre la calidad del proyecto a los stake holders que tienen menor conocimiento técnico.
  • Los desarrollos se vuelven más predecibles, lo cual facilita las estimaciones.

Actividades de SQA en el proceso de desarrollo

SQA es una disciplina que está compuesta por una serie de actividades que acompañan al proceso de desarrollo. El objetivo de estas tareas es aumentar, administrar y monitorizar la calidad de los entregables producidos.

Fases y disciplinas de UP

Para identificar estas actividades y el momento oportuno para realizarlas, es necesario revisar el ciclo de vida de un proyecto. Para esto nos basamos en el análisis de fases/disciplinas/esfuerzo realizado en UP, porque es un proceso muy difundido en el mercado; sin embargo, el mismo análisis puede aplicarse a otros procesos de desarrollo. Analizando el diagrama de Fases, notamos que el esfuerzo de cada disciplina varía según la fase del proyecto.
De aquí se deriva que el momento para controlar la calidad de cada disciplina es cuando mayor esfuerzo se le dedica.
En iniciativas de SQA saludables, el impacto de ésta debería verse reflejado en todos los artefactos que se generan en el proceso de desarrollo. No debería limitarse sólo al testing o verificación funcional, lo cual es una acepción bastante difundida de la función de SQA, pero diametralmente desacertada.

En una perspectiva más amplia del rol sinérgico de SQA en un proyecto de desarrollo, podemos encontrar, entre otras, las siguientes actividades:

  • Verificación de requerimientos: Tiene como objetivo demostrar que la definición de los requerimientos definen realmente el sistema que el usuario necesita o el cliente desea.
  • Validación y verificación de requerimientos: Tienen como objetivo demostrar que la especificación de los requerimientos definen realmente el sistema que el usuario necesita o el cliente desea y que el sistema satisface dichas necesidades.
  • Evaluar la arquitectura: Es una actividad muy importante para evaluar la factibilidad de cumplir con los requerimientos no funcionales y detectar de forma temprana los principales riesgos asociados al proyecto.
  • Control de diseño: Se enfoca en validar el diseño lógico de los componentes, su distribución e interacción; en identificar componentes que puedan ser reutilizables, y en el alcance de los requerimientos de calidad definidos por parte de cada uno de ellos.
  • Control de código: Se subdivide en dos actividades:
    • Control estático del código: Es la validación del código contra un conjunto de reglas, best practices y estándares predefinidos.
    • Control dinámico del código: El control se focaliza en el uso de los recursos que hace la aplicación y la cobertura del código que hacen los tests unitarios.
  • Testing Funcional: Se realiza cerca del final de la etapa de desarrollo, y se encarga de controlar el cumplimiento de los requerimientos funcionales de sistema y de detectar los errores de mayor visibilidad para el usuario.
  • Test de stress: Se enfoca en evaluar el desempeño de la aplicación durante la simulación de momentos pico de actividad.

Tareas previas
Es necesario tener en cuenta que, para realizar algunas de estas actividades, primero hay que realizar otras, como las siguientes:
- Definición de estándares y best practices de desarrollo.
- Elección de herramientas para documentar y desarrollar.
- Otras
La realización de estas tareas se justifica por el solo hecho de que, para poder validar la calidad de cualquier proceso, es necesario contar, previamente, con la definición, requerimiento o estándar contra el cual validar.
En la segunda entrega veremos los siguientes temas: Análisis de costos, ¿Por dónde empezamos?, Métricas de calidad y Conclusiones