Cambio de blog

ESTE BLOG LO HEMOS TRASLADADO A http://ideassobresoftware.blogspot.com.ar/
FAVOR DE SEGUIRNOS ALLÍ.

SALUDOS,
RAUL MARTINEZ

Seminario sobre Calidad de Producto de Software

Hola a todos.

Quería decirles que hemos publicado la versión 3.0 de nuestro Seminario sobre Expectativa de los Interesados y Calidad de Productos de Software.

La actividad no está orientada a explicar el estándar ISO 25000, sólo lo toma como una forma posible de modelar la Calidad de un producto de software.

El foco está puesto en entender de qué manera puede elaborarse un modelo propio y de qué forma se pueden definir, medir y evaluar los atributos de calidad de un producto.

Se generan entonces interesantes debates acerca de la relación de la calidad con la satisfacción del cliente, el precio, el tiempo de entrega y otros elementos que no son inherentes al producto sino que son externos a él.

Les dejo la presentación para que la vean.

RMyA - seminario expectativas de los interesados y calidad del producto de software - v 3.0 – Gobierno de la Calidad: El lado del Producto from Raul Martinez

Saludos,
Raúl

¿Es posible estandarizar las pruebas de software?

Hola a todos.

Como habíamos adelantado, ayer se presentó este tema en la 3° Jornada de Calidad de Software de ORT, generando mucha participación y debate por parte de los asistentes.

Y hemos publicado en slideshare la presentación, que pueden ver o bajar en http://www.slideshare.net/pilarbarrio/rmya-presentacin-jornada-ort-estandar-iso-iec-29119-2011-v10.

Invitamos a todos los que quieran seguir debatiendo sobre el tema o los contenidos de la presentación, a que lo hagan vía comentarios en el blog, para beneficio de los demás colegas interesados.

Muchas gracias.

Pilar

Próximamente: "¿Es posible estandarizar las pruebas de software?"

Tal como lo dice el título, próximamente publicaremos una presentación sobre la estandarización del proceso de pruebas de software, su aplicabilidad y utilidad.

Intentamos comentar y debatir sobre estas grandes preguntas:

- Dada la diversidad de software que actualmente se construye, ¿es posible definir un conjunto de buenas prácticas de pruebas de software que se adecúe a cualquier organización, proyecto y producto?

- ¿Quién aplicaría ese conjunto de buenas prácticas?

- ¿Para qué se aplicaría?

- Dado que ya existen estándares y modelos, ¿para qué uno nuevo?

Esperamos el tema resulte de interés a muchos otros profesionales y colegas.

Publicaremos por este medio también un temario más detallado próximamente, y el lugar donde podrán participar en forma presencial en Ciudad de Buenos Aires.

La presentación completa será puesta a disposición luego de su primera aparición pública, en unos 15 días o pocos más.

Mientras tanto, cualquier otro comentario o sugerencia será bienvenido.

Saludos

Pilar

¿Hace falta un terremoto? …

 

(Publicado originalmente septiembre 2010)

Releyendo recientemente conceptos de BCM (Business Continuity Management) y de ITSCM
(IT Service Continuity Management), no pude dejar de relacionar el tema con algunos aspectos de las pruebas de software, y la evaluación y mitigación de riesgos, y la gestión de servicios en general, que también hemos destacado en otros artículos de este blog mis colegas y yo anteriormente.

Esos aspectos están relacionados también con las características / sub-características / métricas de calidad de producto descriptas en la norma ISO 9126 y que pueden evaluarse según el proceso descripto por la norma ISO 14598, con las más actuales ISO/IEC 25000 SQuaRE
de calidad de productos de software, y con las normas ISO 20000 que especifican los requisitos de implementación de la gestión de servicios de TI. (Ver Referencias)

En definitiva, están relacionados con los requisitos o requerimientos no funcionales (RNFs) de las aplicaciones que construimos y probamos.

Lamentablemente, en muchas ocasiones, estos aspectos son ignorados o postergados en los proyectos de construcción de software, hasta que ocurren desastres, accidentes, ataques u otros incidentes más o menos críticos, que no siempre necesitan ser de la gravedad de un terremoto, pero que afectan a la disponibilidad de los servicios de TI, o incluso a la posibilidad o forma de restaurar esos servicios luego de algún tipo de evento que ha afectado a su continuidad.

¿Por qué digo que lamentablemente estos aspectos son ignorados o postergados?

Porque suele ocurrir que:

• Los RNFs no están especificados, detallados y/o cuantificados.
  
• Se considera que no es momento de probarlos, porque se puede hacer más adelante, o no son riesgosos, o no hay tiempo antes de salir a producción.
  
• Se considera que no es momento de considerarlos en el análisis o diseño de la solución, porque se puede agregar más adelante.
  
• No se ha considerado qué puede ocurrir en ambientes productivos, con mayor interacción de componentes de HW / SW que en los ambientes de prueba.
  
• No se ha previsto qué pasa con el crecimiento de tamaño de entidades de datos, y/o no se han previsto mecanismos de depuración de las mismas.
  
• No se han previsto mecanismos de recuperación ante caídas, o lo más grave aún, no se ha analizado o diseñado para gestionar transacciones en las aplicaciones que lo requieren. También se considera que esto es algo que puede agregarse más tarde.
  
• No se ha planificado quién, cuándo, cómo se actúa ante algún incidente o desastre, o cómo se restaurará la operación normal del sistema, o en qué condiciones de pérdida de información, o se desconoce incluso si toda la información necesaria está respaldada.
  
• No se ha analizado si en función a las características y tipo de solución de software, existen disposiciones legales o regulatorias que apliquen a la misma.
  
• Se considera que todo se resuelve agregando más o mejores servidores / disco / memoria / hardware de comunicaciones.
  
• … y seguramente cada uno tiene un conjunto más de ítems que agregar a esta lista, a partir de su experiencia en diversos proyectos y organizaciones…
  

 

 Mis opiniones

 

Desde nuestro rol en las áreas de Calidad o como líderes de práctica, líderes de equipos, o como testers, es nuestra responsabilidad llamar la atención sobre estos temas al líder de proyecto, cuando consideramos que pueden haber sido descuidados, o no los encontramos representados en los planes de proyecto y/o prueba. Al menos preguntar.
Hacen a la calidad de los productos y servicios que estamos colaborando a entregar.

Está claro que los requerimientos no los ponemos nosotros, ni podemos constituirnos en los "guardianes de la calidad" impidiendo que se entreguen a producción productos que creemos no están totalmente probados o todavía presentan defectos… por algo hablamos de pruebas basadas en riesgos, de entregar productos con un nivel suficiente de calidad, de priorizar defectos y no corregirlos, de involucrar a referentes usuarios en esa priorización, etc. .

Pero también considero que está totalmente en línea con nuestra misión como testers, capacitarnos y "evangelizar" sobre estos conceptos… antes de que nos golpee algún terremoto.

 

Referencias

 

1. ISO/IEC TR 9126-3:2003(E) - Software engineering — Product quality — Part 3: Internal metrics.
   
2. ITIL® v3
   
3. http://www.iso.org/iso/catalogue_detail.htm?csnumber=35683
   
4. Implementing ISO/IEC 20000 Certification - The Roadmap (ITSM Library) - Van Haren Publishing
   
5. http://excelza.blogspot.com/2009/12/sobre-pruebas-de-software-y-servicios.html
   
6. http://excelza.blogspot.com/2010/03/arriesgamos-o-no-arriesgamos.html
   
7. http://excelza.blogspot.com/2009/10/ti-servicios-de-valor-para-el-negocio.html
   
8. http://excelza.blogspot.com/2009/10/sobre-nuestra-mision-como-testers.html
   
9. http://excelza.blogspot.com/2009/11/pensando-que-probar.html
   
10. http://excelza.blogspot.com/2009/12/isoiec-20000-en-pocas-palabras.html

Integración entre SharePoint 2010 y Project 2010

[artículo publicado originalmente en CompartiMOSS Nro. 6]

Como muchos de ustedes sabrán, Microsoft ofrece una solución de servidor para la administración corporativa de proyectos. Esta solución, conocida bajo el nombre de EPM (Enterprise Project Management) se implementa con la herramienta Project Server que se ejecuta sobre SharePoint. Se trata de una excelente solución que apunta a un mercado en particular… Pero hoy no hablaremos de EPM…

Los que nos dedicamos a EPM, siempre nos hemos preguntado cómo manejar algún tipo de integración entre Project Professional y SharePoint, sin tener que utilizar Project Server. ¿Por qué? Porque la práctica de administración de proyectos en las organizaciones está muy relacionada con el nivel de madurez que la organización posee en este tipo de procesos. A veces, una solución EPM es muy compleja y necesitamos algo intermedio entre el Project tradicional y Project Server.

Hasta hace poco tiempo esa posibilidad no existía, ya que las listas de tareas de proyecto de SharePoint eran bastante limitadas. Pero afortunadamente, en la versión 2010 de SharePoint, aparece una nueva funcionalidad: la sincronización entre SharePoint 2010 y Project Professional 2010 :-)

La siguiente lámina (que pueden descargar desde http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=cd9f97c4-bb88-4b8e-b69a-62921b63fb18) muestra claramente donde se posiciona la solución de sincronización respecto al resto de las soluciones de Microsoft para la administración de proyectos:

 

La idea de la sincronización bi-direccional

La idea de la sincronización bi-direccional es muy interesante. Habilita la posibilidad de sincronizar un proyecto creado con Project Professional (no con Project Standard) con una lista de tareas de proyectos de SharePoint. Esto nos permite combinar (con algunas limitaciones) lo mejor de los dos mundos:

• La potencialidad de Project Professional a la hora de planificar un proyecto.
• La potencialidad de SharePoint como herramienta de colaboración, facilitando el acceso a las tareas, su publicación, alertas, RSS y todo lo que estarán imaginando…

¿Cómo funciona? Es simple. Se puede comenzar creando un proyecto en Project Professional y luego sincronizarlo con una lista de tareas en SharePoint, contando además con la posibilidad de mapear campos de Project Professional con columnas de la lista en SharePoint. Lo demás es terreno conocido, una vez que tenemos la lista en SharePoint, contamos con todas las ventajas propias de la herramienta como poder subscribirse, crear una vista de Gantt, crear una vista para filtrar mis tareas, crear una página con varias webparts, etc.

Además, podemos modificar las tareas en SharePoint y hacer que luego queden sincronizadas con Project Professional. Por eso es “bi-direccional”. Esto facilita la actualización de un plan en el que participan varias personas, evitando la centralización o el envío de archivos.

Pero esto no termina aquí. Es importante saber que también podríamos haber comenzado al revés, creando el proyecto en SharePoint y luego sincronizándolo con Project Professional. En fin, un abanico muy amplio de posibilidades en comparación a la versión 2007, asumiendo que por alguna razón no podemos utilizar Project Server, que por supuesto es mucho más potente.

Un dato más, funciona con SharePoint Foundation 2010, no requiere SharePoint Server 2010 (a diferencia de Project Server).

 

Mi primera sincronización

Vamos a tratar de mostrar en este artículo un ejemplo sencillo de esta característica. El primer paso será crear un proyecto en Project Professional 2010 como lo hacemos habitualmente.

Continuar leyendo en: http://surpoint.blogspot.com/2011/02/integracion-entre-sharepoint-2010-y.html.

¿Cómo sería una herramienta de gestión de proyectos 2.0?

Hace algunos días escribí sobre la necesidad y el interés de estudiar e investigar el tema Gestión de Proyectos 2.0 cuya definición simple y resumida podría ser: “gestión de proyectos + web 2.0”. Aquel artículo inicial pueden consultarlo en: ¿Por qué este blog?. Desde esa fecha hasta ahora, he recibido muchos comentarios de gente que hace años trabaja en el tema, enlaces a artículo, etc.

Sin embargo, aún me cuesta encontrar alguna definición para este término. Existe una en Wikipedia que pueden consultar desde este artículo: Gestión de Proyectos 2.0 según Wikipedia.

A pesar de contar con cierta incertidumbre, me está resultando interesante imaginar cómo sería una herramienta de gestión de proyectos 2.0 en el año 2011 y sobre eso me propongo escribir algunas líneas hoy, no para dar una definición, sino para proponer algunas ideas y someterlas a debate.

 

a – los lineamientos

¿Cuáles serían los drivers, los principales lineamientos que debería seguir una herramienta de este tipo? Hago una primera división:

a1 (gestión de proyectos)

Por ser una herramienta de gestión de proyectos, en principio debería estar alineada a las prácticas de administración de proyectos. Esto es básico… pero a cuáles? ¿PMBOK, AGILE, …, …?

Creo humildemente que no deberíamos entrar en esta discusión. La herramienta debería estar alineada a las buenas prácticas o guías que mejor apliquen a su organización.

a2 (web 2.0)

Aquí es dónde me parece que que hay que marcar la diferencia. Al tratarse de una herramienta 2.0, deberíamos tratar de seguir ciertos lineamientos. Para empezar simplemente citaré los que creo pueden ser elementos que sirvan de inspiración:

• Inteligencia colectiva (http://es.wikipedia.org/wiki/Inteligencia_colectiva)
• Web 2.0 (http://es.wikipedia.org/wiki/Web_2.0)
• Social media (http://en.wikipedia.org/wiki/Social_media)
• Empresa 2.0 (http://es.wikipedia.org/wiki/Empresa_2.0)
• Red social (http://es.wikipedia.org/wiki/Red_social)

 

b – la tecnología

Desde el punto de vista tecnológico hay mucho para decir, pero empezando de a poco, una herramienta de este tipo debería…

Si te resultó interesante esta primera parte, seguí leyendo en este enlace: http://gestiondeproyectosdoscero.wordpress.com/2011/02/04/cmo-sera-una-herramienta-de-gestin-de-proyectos-2-0/.

Gracias!

Social media y mejora de procesos (debate)

Hace algún tiempo comenzó una discusión en un grupo de LinkedIn sobre Mejora de Procesos en el que proponíamos el siguiente debate:

Social media y mejora de procesos de TI

Me pregunto como podremos aprovechar la "social media" para hacer más efectiva la mejora de procesos de TI en las organizaciones...
Supongo que a los 500 miembros de este grupo nos interesan los 2 temas, así que espero se genere un buen debate de un tema tan apasionante.

Hoy 6 meses después se sigue debatiendo sobre el tema, Los invito a opinar en este enlace (requiere registración previa).

Que lo disfruten!

Fuente: http://gestiondeproyectosdoscero.wordpress.com/2011/01/10/social-media-y-mejora-de-procesos-debate/