La norma ISO/IEC 25000 "Requisitos y evaluación de la calidad del sistema y del software (SQuaRE). Modelos de calidad del sistema y del software” sigue su camino

En este blog hemos publicado desde hace tiempo varios artículos sobre el tema Calidad de software e ISO/IEC 25000.

Quizás convenga hacer una actualización del estado presente del estándar.

Siguiendo el link http://www.iram.org.ar/index.php?IDM=44&IDN=745&mpal=no&alias=

encontraran la situación de los documentos que componen la norma y cuáles están ya traducidos a nuestro idioma.

Como muchos de Uds. conocen, el modelo de calidad planteado por este estándar, tiene su origen en trabajos previos sobre el tema y en estándares anteriores, siendo la ISO/IEC 9126 la serie más conocida a la que luego reemplazo la ISO/IEC 25000.

En nuestro país, si bien en los ámbitos académicos el modelo era conocido y enseñado, en el ámbito de negocios, la ley de software, al incluirlo como certificación valida juntamente con otros modelos de calidad de proceso (ISO 9000, CMM, y otros) lo popularizó. Para esta finalidad particular del estándar, a nuestro entender el tema no se expandió demasiado posiblemente por las exigencias de información previa que se requiere y otras consideraciones que escapan al tema de este artículo.

Sin embargo, y como lo reflejan varios artículos publicados en este blog, la propuesta del modelo es sumamente útil y práctica.

Quizás el “envoltorio” que le da el formato de un estándar ISO, asusta por su tamaño y formalidad, lo que hace pensar que se trata de una burocracia que solo agregará tiempo sin dejar algo práctico. No es así, la idea es sencilla y totalmente implementable.

Ahora bien, que ocurre hoy con el modelo.

Para aquellos que no lo visitan desde hace un tiempo, se ha agregado el tema de calidad de servicio con sus indicadores, se ha reemplazo prácticamente la documentación de ISO/IEC 9126, a la brevedad se publicará la nueva versión de Requerimientos de Calidad de sistemas/software (ISO/IEC 25030), un nuevo enfoque del modelo de calidad en uso y varios temas más que se fueron mejorando.

Los cambios tecnológicos y enfoques de trabajo tienen cabida en la norma en su estado actual y lo tendrán más aún en versiones futuras.

Como vemos, todo está en evolución, no nos quedemos atrás, luego no será sencillo (o posible) subirnos.

Saludos,
Raúl

@RaulMartinez582

 

Si me estrella contra el muro, es de calidad?...

Hace unos minutos puse este mensaje en @RaulMartinez582 de twitter.

Muchos lo deben conocer, pero igual es interesante http://moralmachine.mit.edu/ . Qué sería aquí calidad de producto?

Como saben varios de este grupo, estoy bastante (muy) comprometido con el tema calidad de software y por eso traigo este comentario que como digo más adelante hoy todavía parece lejano.

Lo que muestra esa encuesta/consulta del MIT del link previo, nos hace pensar entre miles de cosas más, a que llamaríamos “calidad de un producto”, en este caso el producto coche con todo su software dentro por ejemplo.

Como situación, quizás límite, dejaría de ser de calidad el coche y su software, si me estrella contra el muro de contención para no atropellar a la embarazada o a los niños? Seguramente esa no fue mi necesidad a satisfacer, una de las definiciones de calidad, al comprarlo.

Parece un problema no muy cercano y filosófico, alejado del día a día. Pero ya está aquí, en el “mainstream” como le dicen y mañana nosotros mismos nos encontraremos desarrollando el software para la tarjeta de crédito que nos preguntará ¿Está seguro que quieres comprar esa tontera con el nivel de gastos que tienes” . Tampoco fue mi intención que el plástico me interpelara pero allí está haciéndolo. Se nota que es de calidad. :=)

Saludos,
Raúl

 

¿Son compatibles los productos de software actuales con la norma ISO 25000?

Dada la velocidad con que se producen hoy los cambios en la tecnología, y consecuentemente en el software que las maneja, los tiempos de proyectos cada vez más cortos, la complejidad de determinar en forma precisa sus requerimientos y resultados, surge una pregunta: 

¿Puede ayudar un estándar de calidad de producto como ISO 25000 a una mejor comprensión del problema y a resolverlo teniendo en cuenta el contexto antes mencionado?

¿Son compatibles los productos de software actuales con la norma ISO 25000? from Raúl Martínez

Saludos,
Raúl
@RaulMartinez582

Actualizaciones y comentarios breves

Gente, algunas actualizaciones sobre temas relacionados con el interés de los miembros del grupo Mejoras de procesos de TI  en Linkedin y comentarios breves van por twitter en @RaulMartinez582

saludos,
Raúl

¿Los sistemas y productos de software actuales y el estándar ISO 25000 son compatibles?

Normalmente las normas y estándares parecen alejadas de los productos tan cambiantes que vemos hoy y las asociamos más con sistemas estables y en alguno casos críticos. ¿Es así? ¿Sólo sirven  para eso?. Trataremos de mostrar que no.

Cuando vemos un producto como una red social, un sitio de comercio electrónico, un juego, u otros de alta interacción con el consumidor / cliente / usuario, nos cuesta asociarlo con un estándar que habitualmente lo tenemos por algo burocrático, rígido, y pesado. Por ejemplo la familia de normas ISO 25000 de calidad de sistemas y productos de software, sucesora de la ISO 9126.

Sin embargo antes de descartar estas normas, deberíamos explorar si no contienen guías que nos permiten validar si estamos haciendo lo correcto, si contemplamos todo lo requerido, y fundamentalmente, si podemos hacer algo que luego podamos trasladar a otro producto de software o familia de productos  de software.

De todo esto trata esta presentación la presentación que adjuntamos.

Siguiendo brevemente un ejemplo, en este caso de comercio electrónico veremos como, las distintas consideraciones que tuvieron los diseñadores del software, son contempladas por la norma ISO 25000. 

Asimismo, veremos las novedades que hay a la fecha, octubre 2014, en esta importante norma.

La presentación se encuentra aquí:

Sistemas actuales e ISO 25000

Esperamos debatan y compartan estas conclusiones.

Saludos,

Raúl

@RaulMartinez582

“Secretos”  detrás del éxito

 Esta presentación explora algunos de los “secretos”  que hay detrás del éxito de ciertos  productos de software y/o servicios para comprender si con acciones similares, podremos tener éxito con nuestros productos y servicios.

Cuando nos proponemos crear un producto de calidad, de alto impacto y exitoso para nuestro negocio, siendo nosotros:

Un emprendedor o

Alguien que desarrolla en forma interna o para terceros

en algunos casos nos preocupa el proceso que seguimos, los defectos que encontramos, o bien el aspecto de usabilidad del  producto, estética y cantidad de funciones que provee.

Sin embargo nada de esto parece alcanzar,

¿Por qué?

¿Faltó ingeniería?

¿Faltó organización?

¿Fue útil al negocio?

A menos que veamos todo como una unidad difícilmente alcanzaremos el éxito.

De todo esto trata esta presentación.

Las propuestas son prácticas, y surgen después de haber visto, discutido y expuesto todos estos temas en los últimos años con los responsables de este caso y otros casos, no siempre exitosos, en otras empresas.

Esperamos debatan y compartan estas conclusiones.

La presentación se puede encontrar aquí:

Seminario de Calidad de producto



Saludos,
Raúl
@RaulMartinez582

¡Hoy volvemos al Super!

Continuemos con nuestra aventura en el supermercado  iniciada en un post anterior (Una visita al supermercado).

Como sus propietarios notaron una caída en las ventas se propusieron averiguar de cuánto era y a qué se debía dicha caída.

Más allá del indicador del monto de la caída, que era un indicador tardío, les interesaba saber si había alguna otra observación que les permitiera adelantarse a los problemas.  

Descartaron primero las obvias, precio, variedad, ubicación del local, etc., ya que en todas ellas estaban en iguales condiciones que la competencia.

Quedaba por entender entonces algo que estaba ocurriendo dentro del local, entre el cliente y la oferta de nuestro supermercado.  Pensaron varias alternativas, entre ellas:

•       Contar cuánta gente entraba y cuánta salía sin comprar nada.
•      Ver los tickets y entender en qué góndolas la gente compraba menos,  a igual precio e igual mercadería que la competencia, habría otros factores que no les convencían.
•      Detectar cuántos clientes vuelven a comprar luego de la primera compra (licencia poética).
•      Entender el tipo de cliente que normalmente atraemos y entender sus expectativas (qué le encanta y qué le disgusta).
•       .……

Podríamos seguir enumerando indicadores que le pongan valor al comportamiento del cliente y tratar de deducir de allí la experiencia  de compra que tiene.

--

Dejemos aquí al supermercadista preocupado y nuevamente hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Comencemos por la definición de requerimientos o exploración de las necesidades.

Si el comportamiento del usuario es más conocido y manejable nos permitirá la definición de requerimientos algo más precisa, si es menos conocido y manejable nos obligará a explorar.

Para ordenar el trabajo puede ser útil aquí el modelo Kano ⁽¹⁾, que nos dice habrá funcionalidad que el producto deberá tener, ya que si ellas nuestro usuario/consumidor ni siquiera lo considerará, habrá otras características que entre más tenga de ellas, más apreciará el producto y finalmente habrá otras que al descubrirlas le encantarán y eso hará que lo considere de calidad superior, y tal vez esté dispuesto a pagar más por él. Es una ayuda, al menos nos acercará a descubrir necesidades y algunas expectativas.

Pero qué ocurre cuando el producto está en operación durante algún tiempo. ¿Cómo podremos descubrirlas? Es una situación parecida a la de nuestro personaje del supermercado que quería verificar la experiencia del consumidor en su local. Buscaba medidas e indicadores que lo orientaran a qué cambiar y mejorar y a qué mantener. Nosotros también.

Dependiendo del tipo de producto/servicio que estemos tratando, algunos indicadores pueden ser parecidos, por ejemplo cantidad de visitantes convertidos en ventas.

Algunas alternativas de qué medir cuando el producto/servicio está operando las plantea la idea de calidad en uso propuesta por la ISO 25010, hoy con poco detalle todavía, pero ayuda. 

Nos hace preguntar por ejemplo:

• ¿Confía el usuario en el sistema?
• ¿Hace más cosas en menos tiempo?
• ¿Está satisfecho con el sistema?
•  ¿Se logró/mejoró el objetivo económico con la adopción del sistema?
• ¿Logró lo anterior, confiabilidad, efectividad, satisfacción, en los diferentes contextos de utilización?

En estas entradas: La calidad en uso e Indicadores accionables hay algo más sobre esta idea.

Posiblemente nuestro caso necesite algunos indicadores distintos, o más detallados, o de mayor precisión. Pero esta es una buena aproximación.

Dejamos entonces a nuestro supermercadista de la historia viendo cómo mejorar la experiencia de usuario de sus visitantes y, como él, entendamos que las expectativas al entrar al local, superadas o no, son lo que va a definir finalmente el futuro del negocio.

Viene de Equipos Multidisciplinarios
y de Una visita al supermercado

Saludos,

Raúl

TW: @RaulMartinez582

Referencias:

Kano, Noriaki; Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji (April 1984). «Attractive quality and must-be quality»

Una visita al supermercado

Imaginen un sábado por la mañana y Uds. entrando al supermercado cercano a su casa.

Allí hay góndolas que exhiben los productos, encuentran las marcas habituales, los precios no parecen fuera de lugar.

Todo parece normal, pero hay algo que los incomoda, los pasillos estrechos, la limpieza en alguno de los exhibidores  no es la mejor, cierto desorden en la mercadería, etc.

Efectúan la compra, hacen fila en la caja, abonan y se retiran.

Al salir les queda una sensación que podría expresarse así: “Compré lo que necesitaba pero no volvería, o sólo lo haría en caso de necesidad; prefiero caminar más y pagar algo más caro pero sentirme mejor comprando”. Con esto termina este relato cotidiano.

Hagamos una analogía entre lo dicho y nuestra tarea de crear productos y servicios de software.

Los requerimientos o requisitos están cumplidos, las góndolas, la mercadería y los precios. Esa necesidad del consumidor la cubren. Sin embargo,  a pesar de ello:

Las expectativas, es decir aquello que el consumidor esperaba al entrar al supermercado (que puede o no ser realista) basado en experiencias previas, no fueron satisfechas. Encontró pasillos angostos, falta de limpieza, desorden, etc.

Su experiencia como consumidor, la suma de lo físico (góndolas, productos, precios) y lo emocional, no fue buena. Por lo tanto, a menos que tenga necesidad o le convenga por motivos por ejemplo económicos, probablemente no vuelva.

¿Adónde va todo esto?

Se trabajó y trabaja mucho en el área de requerimientos, su  definición, precisión, modelización, que sin duda son importantes. Pero el usuario/cliente/consumidor cada vez tiene más experiencia, utiliza más productos, y sus expectativas aumentan. Su experiencia de usuario incluirá lo que el producto hace, y cómo se esperaba que lo hiciera (lo funcional y parte de lo no funcional) y las expectativas cumplidas o no por el producto en su entorno real de ejecución.

¿Tenemos en cuenta esto también en nuestros desarrollos? ¿Qué ayudaría a considerar más estos temas?

Una propuesta  rápida y seguramente incompleta es:

Trabajar en equipos multidisciplinarios. Cada vez más importante para el éxito de los productos de software y servicios apoyados en ellos. Debemos entender no sólo cómo definir requisitos sino también cómo evaluar  comportamientos de los usuarios / consumidores ante el producto.

Evaluar la experiencia de usuario que trasciende por mucho a la usabilidad aunque la contiene. Suele medirse en algunos casos la usabilidad, pero no es todo lo que importa.

Obtener realimentación proveniente del producto en operación (calidad en uso).  Es fundamental ya que únicamente analizando esta información podremos llegar a entender cómo se siente el usuario interactuando con el producto o servicio.

Definir indicadores relacionados al negocio que muestren el comportamiento del producto / servicio desde su construcción hasta su comportamiento en Producción, además de los puntuales relacionados con la calidad de su construcción. 

Algunos podrán considerar que los puntos enunciados no son de su responsabilidad. Tal vez sea así. Pero… ¿Nuestra responsabilidad es lograr la calidad constructiva y conforme a requerimientos? ¿Sólo eso? ¿O es más amplia y comprende  que además el producto sea exitoso para el negocio?.  Para pensar al menos.


Continua en Equipos multidisciplinarios 
Y en ¡Hoy volvemos al Super!

Saludos,

Raúl

TW: @RaulMartinez582

La Calidad en Uso debe verse con cuidado (ISO/IEC 25010)

La ISO 9126 y la ISO 25000 describen el concepto de calidad en uso.

Tal vez por simple cercanía de nombres, algunas veces se asocia calidad en uso a usabilidad, que si bien es importante y puede definirse a través de otras características como efectividad, eficiencia y satisfacción del usuario, no es el único criterio que propone, ni necesariamente el más importante.

La idea de calidad en uso es la más cercana al resultado final del proyecto, desde el punto de vista del negocio.

Para evaluarla deberemos averiguar, a través del usuario utilizando el sistema en su ambiente real de trabajo, cosas como las siguientes:

• ¿Confía el usuario en el sistema?
• ¿Hace más cosas en menos tiempo?
• ¿Está satisfecho el usuario con el sistema?
•  ¿Se logró/mejoró el objetivo económico con la adopción del sistema?
• ¿Logró lo anterior, confiabilidad, efectividad, satisfacción, en los diferentes contextos de utilización?
• ........

Para ello necesitamos valores objetivo, y así poder comparar. Aquí las expectativas juegan un papel fundamental. 

Como vemos excede y en gran medida el aspecto usabilidad y se acerca más al resultado de negocio de la adopción del sistema/software por el usuario.

De acuerdo a lo que desarrollamos en post anterior sobre  "Acercarnos al negocio", tendremos mayor o menor responsabilidad en este aspecto tan fundamental de la calidad.

Saludos,

Raúl

TW: @RaulMartinez582

Interés de los lectores

Distribución del interés de los lectores de nuestro blog ideassobresoftware.blogspot.com.ar, en los distintos temas a lo largo de los meses. Estos son los 10 primeros puestos en cantidad de lecturas.

Entrada	Fecha de Publicación	Tema
Calidad no es testing, ni procesos, ni certificaciones	Oct 2013	Calidad de producto y expectativas
¿Encajar una pieza cuadrada en un hueco redondo? E...	Jun 2013	Administración de proyectos
Acercarnos al Negocio (Conclusión)	Nov 2013	Calidad y negocios, el resumen
Indicadores accionables	Jun 2013	Indicadores Negocio/Producto
¿Todavía quiere seguir jugando?	Sep 2013	Complejidad de distintos escenarios
Sobre Pruebas de software y Servicios de TI	Aug 2013	Testing y servicios
Sobre nuestra misión como testers	Jul 2013	Testing
ISO 25000 y otras - Calidad en Uso	May 2013	Calidad de producto
Release or not release, that is the question!	Sep 2013	Calidad de producto y negocio
La Calidad (no?) se negocia	May 2013	Calidad de producto y negocio

Saludos,

Raúl

TW: @RaulMartinez582

Acercarnos al negocio (exploradores)

Finalmente llegamos al tercer grupo en el tema de acercarnos al negocio y su relación con la calidad del producto. 

Aquí el consumidor opera el producto, disponiendo de una cantidad de opciones, por ejemplo consultar, registrarse, comprar, pagar, publicar, etc.
Sus expectativas juegan un papel central.

La finalidad de la empresa: el servicio que se presta a través del producto es el negocio mismo de la empresa.

Los requerimientos: conocidos los requisitos básicos, éstos pueden estar especificados con cierta precisión por adelantado. Varios, sobre todo aquellos que harán diferencial al producto, se encontrarán explorando las demandas del consumidor, la forma en que utiliza el producto, sus expectativas y el comportamiento de los productos competidores. Esta exploración nos guiará en la funcionalidad a implementar y su prioridad.

Los usuarios: Muchos, desconocidos o no conocidos hasta que se identifican, recorriendo pasos totalmente aleatorios o especificados en el producto en algunos casos. Estos consumidores pueden agruparse y tomar decisiones conjuntas o bien operar individualmente. Volátiles, con la posibilidad de hacer la misma operación con otro producto competidor, sin mayores costos en el cambio.

Los modelos de trabajo: Tradicionales de desarrollo de software, y administración de proyectos para las partes conocidas.

Necesidad de modelos exploratorios para las partes más volátiles.

Los atributos de calidad deben tenerse en cuenta y su valor objetivo se definirá en parte por la pérdida/ganancia de negocios para la empresa al cumplir o no las expectativas del consumidor.

La calidad: en este contexto significa cumplir con los requerimientos básicos del producto y del proyecto con la tasa de defectos más baja posible, admitiendo errores y equivocaciones en aquellas funcionalidades detectadas por medios exploratorios donde la puesta en producción o el "time-to-market" es prioritario. El indicador accionable, ya mencionado en el post anterior, que une el resultado de una funcionalidad para el negocio, con la pieza de software que la implementa, es una guía para saber qué corregir y con qué prioridad.

Acercarnos al negocio: vale todo lo mencionado en las entradas anteriores sobre conocimiento de productos, tecnología, etc. si bien posiblemente parte de ese conocimiento esté más difundido en estas compañías dado el tipo de negocio en gran medida dependiente de la tecnología.

Contexto: predominantemente complejo y desordenado.

Para una explicación más amplia de estos contextos ver 
http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

Post relacionados

http://ideassobresoftware.blogspot.com.ar/2013/10/acercarnos-al-negocio-back-office.html

http://ideassobresoftware.blogspot.com.ar/2013/11/acercandonos-al-negocio-con-el-cliente.html

http://ideassobresoftware.blogspot.com.ar/2013/06/indicadores-accionables.html

Saludos,

Raúl

TW: @RaulMartinez582