La gestión de la calidad (QM o Quality Management) es un concepto global, dentro del cual se incluyen: el Aseguramiento de la calidad (QA o Quality Assurance), el Control de la Calidad (Quality control) y las pruebas (Testing).

El objetivo de este post es tener en un mismo texto los modelos de mejora continua y los estándares de aseguramiento de la calidad (QA) más conocidos. Metodologías que no solo están presentes en las empresas de ingeniería de software especializadas en la producción de programas y sistemas informáticos, sino que aplican a cualquier negocio o empresa, ya que en mayor o menor medida necesitan de un software para su funcionamiento y desarrollo.

MODELOS DE MEJORA CONTINUA 

Kaizen

La palabra Kaizen proviene de dos términos japoneses: kai, que significa “mejora”, y zen, que significa “bueno” o “bienestar, pero que se traduce más libremente en occidente como «mejora continua». El proceso Kaizen se popularizó en la década de 1950 después de la Segunda Guerra Mundial por los fabricantes japoneses.

Lo que lo diferencia de otros métodos de mejora de procesos es que pretende implicar a toda la organización, desde la alta dirección hasta los trabajadores de la

cadena de montaje, en su aplicación. Tener una Cultura Kaizen en su organización significa que cada individuo, independientemente de su rango, está facultado para buscar oportunidades de mejora cada día, por pequeñas que sean.

Para aplicar la metodología Kaizen se seguirán los siguientes pasos:

1. Planificar: para este primer paso debes ser consciente de la situación actual de tu negocio, analizar los problemas y definir un plan de acción. Fíjate en cuáles son tus cuellos de botella, las incidencias más habituales, los puntos que te gustaría mejorar.
2. Hacer: el siguiente paso consiste en que desarrolles el plan de acción y lo pongas en marcha. Este plan de acción debe contemplar medidas para cada uno de los aspectos que has identificado durante la planificación.
3. Comprobar: en este tercer paso lo más importante es que analices si tu plan de acción está teniendo resultados y comparar estos con los de antes de establecer la metodología Kaizen. Si has alcanzado los resultados que te propusiste al principio significa que vas por buen camino. En caso contrario deberás volver a empezar.
4. Actuar: si has logrado cumplir los objetivos que te marcaste al principio, entonces es la hora de estandarizar la metodología, pero sin olvidar que es un proceso en el que la mejora debe ser continua.

LEAN

A finales del siglo XIX surgió el primer pensamiento Lean en Japón de parte de Sakichi Toyoda el fundador de Toyota. Pero no fue hasta principios de los 90 cuando dicha filosofía de trabajo llegó a occidente, gracias a una publicación de James Womack, Daniel Jones y Roos titulada “La máquina que cambió el mundo”. En la cual se explicaban las características de un nuevo sistema de producción que combinaba eficiencia, flexibilidad y calidad, donde aparece por primera vez el concepto Lean Manufacturing.

Para ello se apoya en la supresión dentro del proceso productivo de todo aquello que no aporta valor, permitiendo trabajar de una forma más eficiente y con un menor consumo de recursos. La Metodología Lean ha ido evolucionando a nuevas aplicaciones específicas como el Lean Health, el Lean Construction y el Lean Office. El punto en común entre todos, es la actuación conjunta de directivos, mandos intermedios y operarios, instaurando unos principios de calidad para optimizar el trabajo, mejorar los resultados y aplicar para siempre la Mejora Continua en todas las áreas empresariales.

Los cinco principios base de esta filosofía son:

1. Especificar el valor del producto según lo perciba el cliente.
2. Identificar la cadena de valor.
3. Dejar que la producción y el valor fluyan.
4. Permitir que el cliente obtenga lo que desea.
5. Perseguir la perfección.

El Lean Management fomenta el trabajo en equipo, todos los que trabajan son parte importante del proceso y su trabajo es fundamental para el resto de los empleados y finalmente para la empresa.

En el pensamiento Lean, cualquier capacidad en las operaciones que sea mayor que la cantidad necesaria para satisfacer la demanda de clientes, será considerado un desperdicio que no producirá valor, por lo que todas las iniciativas de mejora se centrarán en eliminar estos desperdicios y en equilibrar la capacidad con la demanda.

Six Sigma

La metodología Six Sigma fue un concepto creado por el ingeniero Bill Smith en Motorola en 1988, como una estrategia comercial y de mejora de la calidad. Pero posteriormente fue mejorada y popularizada por General Electric.

Es una metodología de mejora que proporciona un camino a seguir para mejorar continuamente la calidad del producto o servicio, buscando ahorro de costes, permitir aumentar la satisfacción del cliente, conseguir el 99,9999% de eficacia (capacidad de lograr el efecto que se desea o se espera) y eliminar la variabilidad y el desperdicio.

Para ello se centra en reducir (hasta casi cero) los defectos y variaciones en los procesos, los costes de calidad, los tiempos de ciclo y aumentar la productividad y la satisfacción de los clientes a través de dicha reducción de variaciones en los productos y los procesos proporcionando a las organizaciones una ventaja competitiva sostenible en el tiempo.

La metodología Six Sigma basa la mejora continua en dos grandes indicadores: la velocidad con que se realiza un proceso (tiempo de ciclo) y el número de errores que llegan al cliente (interno/externo). Se compone de un diseño robusto además de establecer tolerancias para definir un estándar y saber que productos tienen o no la suficiente calidad para salir al mercado.

La metodología Six Sigma suele utilizarse para mejorar procesos o productos que ya existen en la empresa y se basa en el método DMAIC: definir, medir, analizar, mejorar y controlar.

Cuando Six Sigma se aplica a procesos o productos que todavía no existen se basa en el método DMADV: definir, medir, analizar, diseñar y verificar.

 

METODOLOGÍAS TRADICIONALES

WATERFALL (Cascada)

En Ingeniería de software, la metodología en cascada se denominó así por la posición de las fases del desarrollo que parecen caer en cascada “por gravedad” hacia las siguientes fases, de forma escalonada.

Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

Este modelo comenzó a diseñarse en 1966 y se terminó alrededor de 1970. El principal problema de esta aproximación es cuando surgen cambios o modificaciones, ya que hay que volver hacia atrás en el ciclo de vida. Además, los resultados no se pueden ver hasta muy avanzado el proyecto por lo que cualquier cambio debido a un error puede suponer un gran retraso además de un alto coste de desarrollo.

Modelo – V

El modelo – V apareció por primera vez en Hughes Aircraft, alrededor de 1982, como parte del esfuerzo previo a la propuesta para el programa FAA Advanced Automation System (AAS) para sustituir el hardware y el software del sistema de control del tráfico aéreo, proporcionando nuevas capacidades automatizadas para hacer frente al aumento de dicho tráfico aéreo.

El modelo – V es un modelo SDLC (Software Development Life-Cycle) en el que la ejecución de procesos ocurre de manera secuencial en forma de V. También se conoce como modelo de verificación y validación.

Es una extensión del modelo en cascada y se basa en la asociación de una fase de prueba para cada etapa de desarrollo correspondiente.

Este es un modelo muy disciplinado y cada fase comienza solo después de completar la fase anterior.

Prototyping

Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación. El prototipo de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de la manera más rápida posible.

Spiral

Toma las ventajas del modelo de desarrollo en cascada y el de prototipo añadiéndole el concepto de análisis de riesgo.

Se definen cuatro actividades:

1. Planificación: en la que se recolectan los requisitos iniciales o nuevos requisitos a añadir en esta iteración.
2. Análisis de riesgo: basándonos en los requisitos decidimos si somos capaces o no de desarrollar el software y se toma la decisión de continuar o no continuar.
3. Ingeniería: en el que se desarrolla un prototipo basado en los requisitos obtenidos en la fase de planificación.
4. Evaluación del cliente: el cliente comenta el prototipo. Si está conforme con él se acaba el proceso, si no, se añaden los nuevos requisitos en la siguiente iteración.

Incremental

Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad.

Estas etapas, consisten en: requerimientos, diseño, codificación, pruebas y entrega. Permite entregar al cliente un producto más rápido en comparación del modelo en cascada.

• Reduce los riegos ya que provee visibilidad sobre el progreso de las nuevas versiones.
• Provee retroalimentación a través de la funcionalidad mostrada.
• Permite atacar los mayores riesgos desde el inicio.
• Se pueden hacer implementaciones parciales si se cuenta con la suficiente funcionalidad.
• Las pruebas y la integración son constantes.
• El progreso se puede medir en periodo cortos de tiempo.
• Resulta más sencillo acomodar cambios al acortar el tamaño de los incrementos.
• Se puede planear en base a la funcionalidad que se quiere entregar primero.
• Por su versatilidad requiere de una planificación cuidadosa tanto a nivel administrativo como técnico.

Para apoyar el desarrollo de proyectos por medio de este modelo se han creado Frameworks (entornos de trabajo), los dos más famosos son el Rational Unified Process (RUP) y el Dynamic Systems Development Method (DSDM), que explicamos más adelante cuando tratamos las metodologías ágiles.

El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.

RAD

La metodología de desarrollo conocida como diseño rápido de aplicaciones RAD (Rapid Application Development), presentada oficialmente por James Martin en 1991, consiste en desarrollar aplicaciones rápidamente por medio de iteraciones frecuentes, construcción de prototipos y aprobaciones con comentarios continuos de los clientes. Gracias a su rapidez y agilidad, la popularidad de RAD va en aumento.

Los beneficios clave son:

• Reducción del tiempo de desarrollo y aceleración de la entrega.
• Mejora de la flexibilidad y la adaptabilidad.
• Mejor gestión de riesgos.
• Menos programación manual y tiempos de prueba más cortos.
• Comentarios de los usuarios constantes, relevantes y en tiempo real.

 

METODOLOGÍAS ÁGILES

En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágil aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos.

XP (Programación Extrema)

La principal particularidad de esta metodología son las historias de usuario, las cuales corresponden a una técnica de especificación de requisitos; se trata de formatos en los cuales el cliente describe las características y funcionalidades que el sistema debe poseer.

Restringe a los integrantes del equipo de trabajo a sólo trabajar en las necesidades inmediatas, en lugar de considerar las necesidades futuras. El objetivo es crear un sistema simple que pueda ser implementado fácilmente para después irlo mejorando de acuerdo con las necesidades que vayan surgiendo.

Se busca resolver la mayor cantidad de problemas pequeños antes de que se conviertan en problemas más grandes y afecten a la fecha de entrega.

En esta metodología se realiza el proceso denominado Planning game, que define la fecha de cumplimiento y el alcance de una entrega funcional, el cliente define las historias de usuario y el desarrollador con base en ellas establece las características de la entrega, costos de implementación y número de interacciones para terminarla.

Se realizan entregas pequeñas que son el uso de ciclos cortos de desarrollo, llamado iteraciones, que muestra al cliente una funcionalidad del software terminado y se obtiene una retroalimentación de él.

En esta metodología, hay una parte muy importante: las pruebas de aceptación, una vez que se ha desarrollado una funcionalidad, entra a pruebas por parte del cliente, dando su aprobación.

Scrum

Su objetivo principal es que un equipo de trabajo reaccione con rapidez, sencillez y de manera apropiada en lugar de perder tiempo en la creación/actualización de planes de trabajo obsoletos.

Describe un conjunto de prácticas para la gestión de proyectos:

• Unidades de trabajo (sprint), normalmente de 30 días.
• Reuniones cortas diarias (daily), de 15 minutos, por el equipo de Scrum.
• Demos con las funciones que pueden ser entregadas dentro del plazo establecido.

Y se definen roles para generar una estructura de correcto funcionamiento:

• El Scrum Master: persona que lidera el equipo y asegura que se cumplan las reglas y procesos de la metodología.
• Product Owner: representante de los clientes que usan el software.
• El equipo de desarrollo: grupo de profesionales encargados de convertir la lista de requerimientos o también llamado Product Backlog en funcionalidades del software.
  

  

DoR y DoD

Los métodos Agile Scrum utilizan DoR (Definition of Ready) y DoD (Definition of Done) para garantizar la calidad al reforzar la transparencia y establecer las expectativas correctas.

En las metodologías ágiles Quality gates es el mecanismo que asegura la calidad a lo largo de las diferentes etapas del proyecto.

DoR es el criterio de entrada a las historias de usuario para el sprint.

DoD es el criterio de salida a las historias de usuario para el sprint.

Crystal Clear

Crystal fue creada por el antropólogo Alistair Cockburn, el cuál tomo como base el análisis de distintos proyectos de desarrollo de software y su propia experiencia, lo cual fusionando ambos aspectos dio lugar este nuevo método de trabajo; no es solo una metodología de desarrollo de software ágil, ya que se la considera una familia de metodologías, debido a que se subdivide en varios tipos en función a la cantidad de persona involucradas en el proyecto.

La familia Crystal dispone de un código de color para marcar la complejidad de una metodología, ya que cuanto más oscuro es el color, más pesado es el método y cuanto más crítico es un sistema, más rigor se requiere. El código cromático se aplica a una forma tabular que se usa para situar el rango de complejidad al cual se aplica una metodología. El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad.

Kanban

Esta metodología tiene como base de su origen la aplicación de los procesos de producción JIT (Just in Time) ideados por la empresa automotriz Toyota, en la cual utilizaban tarjetas visuales para identificar necesidades de material en la cadena de producción.

Kanban se basa en la idea de que el trabajo en curso debería limitarse, y sólo deberíamos empezar con algo nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra función posterior de la cadena. La metodología Kanban utiliza un mecanismo de control visual para hacer seguimiento del trabajo conforme este viaja a través del flujo de valor.

Normalmente, se emplea un panel o pizarra con notas adhesivas o un panel electrónico de tarjetas para gestionar el flujo de trabajo y las asignaciones. Las mejores prácticas apuntan al uso de ambos métodos. El Kanban (o tarjeta visual) implica que se genera una señal visual para indicar que hay nuevos bloques de trabajo que pueden ser comenzados porque el trabajo en curso actual no alcanza el máximo acordado.

Mobile-D (ágil y extrema para móviles)

El objetivo de esta metodología es conseguir ciclos de desarrollo muy rápidos en equipos muy pequeños. Se basa en metodologías para el desarrollo de aplicaciones móviles conocidas pero aplicadas de forma estricta como: extreme programming, Crystal Methodologies y Rational Unified Process.

Tiene distintas fases y cada una tiene un día de planificación y otro de entrega.

1. Fase exploración: se centra la atención en la planificación y en los conceptos básicos del proyecto. Aquí es donde se define el alcance del proyecto y su establecimiento con las funcionalidades donde se quiere llegar.
2. Fase de iniciación: configuramos el proyecto identificando y preparando todos los recursos necesarios como hemos comentado anteriormente en esta fase la dedicaremos un día a la planificación y el resto al trabajo y publicación.
3. Fase de producto: se repiten iterativamente las subfases. Se usa el desarrollo dirigido por pruebas (TDD), antes de iniciar el desarrollo de una funcionalidad debe existir una prueba que verifique su funcionamiento. En esta fase podemos decir que se lleva a cabo toda la implementación.
4. Fase de estabilización: se realizan las acciones de integración para enganchar los posibles módulos separados en una única aplicación.
5. Fase de pruebas: una vez parado totalmente el desarrollo se pasa una fase de testeo hasta llegar a una versión estable según lo establecido en las primeras fases por el cliente. Si es necesario se reparan los errores, pero no se desarrolla nada nuevo.

Marco de proyecto adaptativo (AFP)

El marco de proyecto adaptativo (AFP), también conocido como gestión adaptativa de proyectos (APM), surgió a partir de la idea de que, en cualquier etapa de un proyecto, pueden surgir factores desconocidos que lo afecten. Esta técnica se aplica principalmente para proyectos de TI en los que no funciona otro tipo de técnicas tradicionales para la gestión de proyectos.

Este marco se basa en la idea de que los recursos de un proyecto pueden cambiar en cualquier momento. Por ejemplo, el presupuesto puede cambiar, el cronograma también o incluso los miembros que trabajan en el equipo encargado del proyecto pueden pasar a trabajar en otros equipos. El marco de proyecto adaptativo se centra en los recursos que hay para el proyecto, en contraposición a los recursos que se necesitan para el proyecto.

Feature Driven Development (FDD)

Metodología de desarrollo basado en funciones (FDD) está alineada con la metodología de desarrollo ágil. Se trata de un proceso orientado al diseño, desarrollado y refinado por Jeff De Luca, Peter Coad y otros colaboradores.

Es una metodología de desarrollo de software centrada en el cliente conocido por iteraciones cortas y lanzamientos frecuentes.

Al igual que Scrum, FDD requiere que el cliente, también conocido como propietario del negocio del proyecto, asista a la reunión de diseño inicial y las retrospectivas de iteración.

Al lanzar nuevas funciones de forma incremental, los desarrolladores pueden priorizar las solicitudes de los clientes, responder a las solicitudes de manera oportuna y mantener a los clientes satisfechos. El proyecto se divide en características. Estas características son pequeñas piezas de un proyecto completo. que los desarrolladores son capaces de crear, dividen las solicitudes complejas en una serie de conjuntos de características más pequeños y luego crean un plan sobre cómo completar cada objetivo con el tiempo.

Método de desarrollo de sistemas dinámicos (DSDM)

El método de desarrollo de sistemas dinámicos es un método ágil que se centra en el ciclo de vida completo de un proyecto. Este es el motivo por el cual este método tiene una estructura y bases más rígidas, a diferencia de lo que sucede con los demás métodos ágiles.

Las 4 fases principales del método de desarrollo de sistemas dinámicos son las siguientes:

1. Estudio de viabilidad y de la empresa.
2. Iteración del modelo funcional o prototipos.
3. Diseño e iteración de la estructura.
4. Implementación.

Adaptive Software Development (ASD)

Desarrollo adaptativo de software (ASD) es una metodología creada por Jim Highsmith y Sam Bayer a comienzos de 1990. Encarna el principio de que el estado normal se basa en la continua adaptación del proceso de desarrollo al trabajo real.

Tiene tres componentes o etapas:

1. Especular: se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones, necesarias para la correcta atención de los trabajadores que se mueven dentro de plazos de forma que puedan priorizar sus tareas. Se decide el número de iteraciones para consumir el proyecto, prestando atención a las características que pueden ser utilizadas por el cliente al final de la iteración. Son necesarios también marcar objetivos prioritarios dentro de las mismas iteraciones. Estos pasos se pueden volver a examinar varias veces antes de que el equipo y los clientes están satisfechos con el resultado.
2. Colaborar: Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cíclica. Un trabajo importante es la coordinación que asegure que lo aprendido por un equipo se transmite al resto y no tenga que volver a ser aprendido por los otros equipos
3. Aprender: La última etapa termina con una serie de ciclos de colaboración, su trabajo consiste en capturar lo que se ha aprendido, tanto positivo como negativo. Es un elemento crítico para la eficacia de los equipos.

Proceso Unificado de Desarrollo Software (UP)

La metodología de Proceso Unificado (UP) se está debatiendo aún si considerarla metodología ágil, puesto que se caracteriza por estar dirigida por casos de uso, centrado en la arquitectura y además es iterativa e incremental.

Conclusión

Hay muchas metodologías de aseguramiento de la calidad y modelos para la gestión de los proyectos de desarrollo de software, pero la teoría difiere de la realidad.

Uno de los primeros retos a los que se enfrentan las empresas en la actualidad es poner en práctica los modelos ágiles que demanda el mercado para llegar a tiempo, con la máxima calidad para el usuario final y sin incrementar los costes. En este post sobre la implementación de la Calidad en la Transformación Digital tienes la clave, para más información contacta directamente con nosotros aquí.