viernes, 15 de noviembre de 2013

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

jueves, 14 de noviembre de 2013

Acercarnos al negocio (Cuando el negocio es el desarrollo)




En la primera entrada mencionamos aquellas compañías cuyo negocio es desarrollar software para terceros.

Los modelos de trabajo: 
Tradicionales de desarrollo de software, y administración de proyectos si se trabaja sobre requerimientos conocidos.

La aplicación de un modelo exploratorio llevaría a que el desarrollador permanezca asociado al producto una vez que éste está en la calle, de modo de ir incorporando las funcionalidades que se van descubriendo como necesarias. Cosa que no siempre sucede.

La calidad: en este contexto significa cumplir con los requerimientos en tiempo y forma ante el cliente, y cumplir con los objetivos de negocio ante la propia compañía de desarrollo.

Además, en este caso, no formalizar los requerimientos implica un riesgo importante ya que el desarrollador tratará de aplicar un modelo de tipo “fábrica”, es decir trabajar contra requerimientos. Si éstos no están explicitados o hay que descubrirlos, el modelo mencionado no aplica, y se gasta tiempo y dinero inútilmente, atentando contra las expectativas de calidad que se tenían del proveedor.


Contexto: complicado y ordenado.


Saludos,
Raúl
TW: @RaulMartinez582

martes, 12 de noviembre de 2013

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

Oct 2013

Calidad de producto y expectativas

Jun 2013
Administración de proyectos

Nov 2013
Calidad y negocios, el resumen

Jun 2013

Indicadores Negocio/Producto

Sep 2013

Complejidad de distintos escenarios
Aug 2013
Testing y servicios
Jul 2013
Testing
May 2013
Calidad de producto
Sep 2013
Calidad de producto y negocio
May 2013
Calidad de producto y negocio

Saludos,
Raúl
TW: @RaulMartinez582