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?... sigue la saga

A riesgo de ser pesado, sigamos con el tema anterior, que ha causado cierta reacción en Twitter, aquí y sobre todo en mí.

Imaginemos 2 stakeholders típicos (entre muchos) para un producto como el coche con su software.
La Autoridad de aplicación, por ejemplo la Autoridad de la ciudad y el Interesado. Por ejemplo yo, comprador del coche.

La Autoridad de aplicación le impone al constructor del coche/software, de aquí en más llamémoslo sistema (coche + software) sus requerimientos, que son restricciones de seguridad. Por ejemplo, ante una situación de riesgo, el sistema debe elegir el mal menor. Un caso, estrellar el coche contra el muro en lugar de atropellar a la anciana o la embarazada.

Obviamente, el otro interesado, Yo el comprador, pongo como requerimiento que el coche sea seguro y que no me mate, para decirlo rápidamente.

Ahora bien, el constructor del sistema como se manejaría con dos requerimientos tan enfrentados?

Por ejemplo que diría la promoción de su producto: “Compre este coche que es el más seguro y en la letra pequeña diría: tomaría la mejor elección para Ud. y el entorno que lo rodea.” Firme aquí. 

Leído entre líneas dirá, Ud. acepta que el coche lo estrellará contra el muro si eso es o que más conviene al entorno.

Qué le pediría seguramente su Product Manager. ”Haz esto, lo que pide la Autoridad, pero no mucho. Haz esto sin que se note. O saltéalo y si se da será un error de software”. Caso en el cual Ud. Desarrollador irá preso, pero el habrá logrado la promoción.

Bueno comparado con esto, nuestra tarjeta de crédito alcahueta mencionada en la entrada anterior será cosa de niños. :=)

Saludos,
Raúl

Nota 1: quién se atreve a opinar como uno de los 2 stakeholders????
Nota 2: el futuro nos aplasta, vean esta nota del diario El País de España:http://tecnologia.elpais.com/tecnologia/2016/07/01/actualidad/1467337732_779288.html

 

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

 

 Diseño de la Propuesta de valor

Es interesante ver como modelos y herramientas que tienen su origen en el “negocio” se adaptan a nuestra forma de descubrir, diseñar y probar la viabilidad de productos de software. 

Entre el cliente, inversor, usuario (interesado en general) y quien diseña y crea la solución, comienza a surgir un lenguaje común a través de modelos visuales que son comprendidos y compartidos por ambos. 

La intervención cada vez más importante de aspectos que ya no son sólo funcionales, sino emocionales –social y personal– que la solución debe contemplar es también un desafío para quien explora y diseña nuevos productos y servicios.

Nada de esto es nuevo, simplemente que ahora la tecnología y la inundación de propuestas que recibe el interesado nos lleva a la “nueva normalidad”: mejor, más barato, más rápido, más pequeño, más conveniente, más personalizable, hace que sea mucho más necesario tener estos temas en cuenta. 

Vamos despidiéndonos del famoso "usuario cautivo" de décadas atrás para construir soluciones para las personas que pueden elegirnos a nosotros o a otros. 

Ganará el mejor, quien comprendió más íntegramente los trabajos para los cuales el cliente "contrata" nuestro producto. 

Ya en la entrada de este blog Value Proposition Design - Comentarios sobre el nuevo libro de Alex Osterwalder comenté acerca del contenido del modelo propuesto por el autor.

Ahora, en la presentación más abajo mostrada amplío la descripción del modelo con algunos de los pasos que este recorre y las herramientas que utiliza.

Value proposition design (brief presentation of A. Osterwalder new model) from Raúl Martínez

Las láminas 15 y 17 del pdf corresponde a este video: https://www.youtube.com/watch?v=NMacTuHPWFI

Espero sea de utilidad y genere en Uds. inquietud y curiosidad para seguir explorando.

Saludos,

Raúl

@RaulMartinez582

¿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

Desarrollar software hoy

Desarrollar software hoy. Sólo controlamos lo encerrado en el círculo.
Partes tomadas de bi-modal IT del Gartner Group.


Raúl Martínez‏@RaulMartinez582

Acercarnos al Negocio (Conclusión) -No hay lugar para los débiles- Re-edición

Acercarnos al Negocio (Conclusión)

-No hay lugar para los débiles-

Este artículo es la conclusión sobre el tema del tipo de negocio, la relación entre el área de tecnología (IT), los Clientes / Usuarios y la calidad percibida por ellos, desarrollada a través de las notas anteriores (1), (2) y (3).

La tabla mostrada, definitivamente incompleta y simplificada, creemos que permite entender el contexto de los productos de software desde varios puntos de vista. Los temas que muestra actúan simultáneamente sobre el usuario / consumidor, el negocio y el equipo de IT. 

Atarse a un modelo de trabajo, a una situación determinada  que onsideremos estable (impacto del sw en nuestra industria, usuario eternamente cautivo por ejemplo) o a una única definición de calidad es peligroso, para el negocio y para nosotros.

Otras conclusiones: 

1.           Si bien puede parecernos que es lento y que no es posible que el negocio mute de un tipo a otro, va a mutar es la forma en que la tecnología permite hoy resolver los negocios y ofrecer nuevas oportunidades de negocio. Con el tiempo, los límites entre los tipos vayan haciéndose más tenues, en servicios prestados vía la tecnología se refiere.

2.           El cambio entre columnas es costoso, en ambos sentidos. En un negocio donde se debe explorar el comportamiento del consumidor no podemos ni debemos esperar requerimientos escritos, al menos al inicio. Del mismo modo, en un negocio donde el objetivo del producto es conocido, explorar no tiene demasiado lugar y no recibir los requerimientos razonablemente definidos en este caso sólo agrega tiempo y defectos.

3.           En lo referido a contextos. El contexto complejo y desordenado no es un lugar para permanecer. A medida que las expectativas del cliente se detecten y se cumplan, debemos esforzarnos para pasar al complicado pero ordenado. Y prepararnos para una nueva tanda de expectativas a explorar y así siguiendo.  

Tema a considerar	Lo más importante es el sw de backoffice	Importa el sw de backoffice pero hay sw que interactúa con el cliente	Hay interacción continua del sw con el cliente y además sw backoffice
La finalidad de la empresa	No relacionada con el software	Productos de sw importantes para su negocio, pero no son su negocio	Su negocio es la prestación de un servicio a través del producto de software
Los requerimientos	Conocidos	Conocidos; mayor cuidado en los atributos de calidad de cara al cliente	Conocidos los funcionales básicos; a explorar el resto según demandas del usuario y competencia
Los usuarios	Conocidos y cautivos	Conocidos internos y externos. Costo de cambio es alto para el cliente. Baja movilidad de clientes.	Variados y gran cantidad, desconocidos hasta la identificación. Comunidades, decisiones conjuntas, no controlables. Bajo costo de cambio para el cliente/consumidor.
Los modelos de trabajo	Tradicionales para el desarrollo de sw y administración de proyectos	Ídem anterior más, parcialmente exploratorios de cara al cliente	En lo funcional básico, en parte tradicionales. En lo competitivo,   modelos totalmente exploratorios.
La calidad	Cumplir los requerimientos	Cumplir los requerimientos y prestar atención a la calidad en uso	Cumplir los requerimientos básicos se da por hecho. La calidad se mide en el cumplimiento de expectativas de los consumidores.
Formas de acercarse IT al negocio	Apoyo tecnológico y soporte	Ídem anterior, más  algunos indicadores accionables de la performance negocio/producto de sw	Indicadores accionables que permitan analizar en los tiempos del negocio la performance negocio/producto de sw y corregir desvíos.
Contexto	Complicado pero  ordenado	Complicado pero ordenado	Complejo y desordenado

Como se dijo más arriba, la mutación y mezcla entre las columnas de la tabla está en curso, más lenta en algunos casos, más rápida en otros pero siempre presente.

Difícilmente podamos imaginar en pocos años más una industria que no haya incorporado software como una herramienta más para competir. Aún en aquellas industrias que parecen más alejadas de este tipo de tecnología. De allí la importancia para el sector de IT de preverlo y administrarlo hoy, o será tarde.

Aquí aplica una vez más la frase, “lo único permanente es el cambio”. 

Raúl Martínez

TW: @RaulMartinez582


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/11/acercarnos-al-negocio-exploradores.html

⁽⁴⁾ http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

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

La Persona detrás de El Usuario

Al tratar de entender un problema a resolver o la solución a proponer, hablamos habitualmente de El Usuario. Eso es correcto según toda la literatura y es quien en última instancia utilizará nuestro producto/servicio.  

Bastante tiempo atrás nos preocupaba que este usuario recibiera un producto funcionalmente correcto, luego en la medida que la tecnología lo permitió sumamos cada vez más la idea de usabilidad y finalmente hoy debemos sumar algo más abstracto de definir que es la persona que está detrás de ese usuario.

Así como la propuesta Ágil nos muestra, entre varias otras cosas, la Persona que está detrás del Recurso en el Equipo de Trabajo y lo útil que es considerarla, deberíamos examinar cómo nuestro modelo de análisis de los problemas contemplan a la persona detrás del usuario y no sólo la funcionalidad que utilizará en la operación del producto.

Hay varios factores además del funcional, como el social o el emocional, que pueden finalmente transformarse en requerimientos tal como cualquier otro requerimiento funcional que conocemos.

En mi opinión este tipo de análisis es un movimiento imparable debido a la presión y difusión de las tecnologías que hoy ya están totalmente incorporadas al plano social y personal.

Sobre el tema, hay literatura interesante que si bien pertenece a lo que llamaríamos habitualmente libros de negocios, creo que son necesarios para el analista de negocios, el product manager , el arquitecto / desarrollador senior y por supuesto el emprendedor.

Los libros son estos:

--Business Model Generation, Osterwalder, Pigneur, 2009

--Value Proposition Design, Osterwalder, Pigneur , Bernarda, 2014

--The four steps to epiphany. Steve Blank, 2013

--The Startup Owner’s Manual. Blank , Dorf, 2012

Ninguno trae ideas revolucionarias, excepto el formato gráfico de los dos primeros utilizado para plantear temas áridos de negocios. Hay ideas de Christensen, Kim, Ries, etc. Bien condensadas y presentadas.

Conviene empezar por el primero Business Model.

Hay que tomarse un tiempo para leerlos, desprenderse del preconcepto de “eso es un  tema del negocio, no mío” y recordar siempre la frase de Steve Blank  -- get “outside of the building” -- que las cosas ocurren fuera de nuestro lugar de trabajo. Con la lectura no basta.

Hasta la próxima.

Raúl Martínez

rmartinez@rmya.com.ar

www.rmya.com.ar / Ideas sobre el software / Twitter: @RaulMartinez582

¿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

El producto de software Calidad y contexto

Está publicada la nueva versión de nuestro seminario sobre Calidad de Producto (Mayo 2014).

Allí podrán ver un caso real, una nueva línea de negocios de Mercado Libre, y la posible aplicación de distintas herramientas o prácticas, todas conocidas (Kano, mapas de empatía) pero no necesariamente utilizadas en nuestros desarrollos.   

En el tipo de desarrollo que se presenta, además de los requerimientos “debe estar” utilizando la terminología del modelo Kano, aparece la necesidad de buscar aquello que “diferencien” al negocio del  resto de la competencia.

También se ve la identificación de diversos interesados, dado que todos ellos evaluarán la calidad del producto desde su punto de vista.

La presentación plantea a lo largo de su desarrollo la necesidad de ver a la calidad no como un conjunto de herramientas y prácticas aisladas y sumadas, sino como una composición donde los aspectos: Producto y sus características, Interesado y sus expectativas, Organización y su visión de la calidad y la Cultura de la organización que tratamos, colaboran a potenciar la satisfacción del cliente y el valor para su negocio.

Al final de la presentación hay una serie de preguntas que creemos es interesante tratar de responderse y que entendemos son las dudas que habitualmente se tienen al encarar el tema calidad.

Esta presentación fue actualizada en setiembre 2014, ver http://www.slideshare.net/rmartinez582/el-producto-de-software-negocio-calidad-y-contexto 

Saludos,

Raúl

Twitter: @RaulMartinez582