excelza

¿Es posible estandarizar las pruebas de software?

noreply@blogger.com (Pilar Barrio la Iglesia) — Tue, 15 Nov 2011 12:05:25 PST

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?"

noreply@blogger.com (Pilar Barrio la Iglesia) — Tue, 15 Nov 2011 11:41:56 PST

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?...

noreply@blogger.com (Pilar Barrio la Iglesia) — Thu, 27 Oct 2011 07:36:23 PDT

¿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

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

Integración entre SharePoint 2010 y Project 2010

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Mon, 21 Feb 2011 04:31:49 PST

[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?

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Fri, 04 Feb 2011 11:09:46 PST

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)

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Mon, 10 Jan 2011 13:03:42 PST

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/

Gestión de Proyectos 2.0 según Wikipedia

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Sun, 02 Jan 2011 20:10:30 PST

Existe en Wikipedia una definición de Project Management 2.0 que es interesante de leer. A continuación les dejo un breve resumen, pero les recomiendo que consulten el artículo original.

Para Wikipedia, la gestión de proyectos 2.0 es la evolución natural de la gestión de proyectos apalancándose en las tecnologías web 2.0, tales como wikis, blogs y software colaborativo en general. Está definición acepta también el termino social project management como válido.

Wikipedia hace una comparación entre la gestión de proyectos tradicional y la 2.0. Mientras que la tradicional ubica al jefe de proyecto en el centro del trabajo, recopilando la información del equipo, procesándola e informando luego a la dirección; las nuevas tendencias definen al proyecto como liderado por el equipo, donde cada miembro posee acceso total a la información.

La nueva generación de tecnologías posibilitan la inteligencia colectiva, termino sobre el que pueden profundizar en este enlace.

Las principales diferencias entre la gestión de proyectos 2.0 y la tradicional pueden observarse en este cuadro.

Continuar leyendo en: http://gestiondeproyectosdoscero.wordpress.com/2011/01/03/gestin-de-proyectos-2-0-segn-wikipedia/.

Investigando Gestión de Proyectos 2.0

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Thu, 30 Dec 2010 10:47:45 PST

Desde hace un tiempo, con algunos colegas, estamos muy interesados en explorar algo que se llama Gestión de Proyectos 2.0, que en forma resumida es la suma de las prácticas y herramientas de la web 2.0 y las redes sociales a la gestión de proyectos.

Algo sobre el tema se puede leer en Wikipedia en este enlace: http://en.wikipedia.org/wiki/Project_management_2.0.

Estamos tratando de entender este fenómeno y compilar ideas. Así que creamos un blog que pueden encontrar aquí: http://gestiondeproyectosdoscero.wordpress.com/. Y una cuenta en twitter también: http://twitter.com/gesprodoscero/.

Se que entre los lectores hay muchos interesados en el tema Gestión de Proyectos, así que estoy buscando opiniones, colaboración, participación en debates, etc.

Si hay por ahí algún interesado, le dejo el link con una breve introducción http://gestiondeproyectosdoscero.wordpress.com/2010/12/28/porque/ y desde ya le agradezco sus comentarios.

Hasta la próxima (y se agradece difusión)!

Si trabajas con personas, este video te va a resultar interesante…

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Tue, 30 Nov 2010 19:09:38 PST

Desde el blog de mi amigo Sergio Martínez en http://zonam3.wordpress.com/ me enteré de la existencia de este video, que habla sobre colaboración, comunicación, y todos estos temas “blandos” que siempre me resultan interesantes. Pueden ver el enlace original en http://zonam3.wordpress.com/2010/11/30/en-la-era-de-la-colaboracion-la-clave-es-la-colaboracion/.

Que lo disfruten!

Microsoft Project and SharePoint Server 2010 -- Better Together

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Tue, 20 Jul 2010 09:58:27 PDT

Microsoft liberó un nuevo paper orientado a usuarios finales y stakeholders, que nos muestra las nuevas funcionalidades de Project Server 2010 y cómo el producto ha ido evolucionando. Pueden descargarlo desde este enlace: http://www.microsoft.com/downloads/details.aspx?FamilyID=4f327363-181b-43ea-99f8-58927b452135&displaylang=en.

Que lo disfruten!

Fuente: Microsoft Project and SharePoint Server 2010 -- Better Together.

Mindstorming

noreply@blogger.com (Sergio Martínez) — Tue, 13 Jul 2010 06:40:37 PDT

¿Cómo se hace un mindstorming? ¿Para qué sirve?

Si dispone de ellas, las herramientas de mind mapping son excelentes para realizar este tipo de ejercicios, en caso contrario, no se preocupe, todo lo que se necesita para realizar un mindstorming es papel y lápiz.

El primer paso consiste en identificar el problema, desafío u objetivo. Aquí es muy importante tener en cuenta que cuánto más específico sea, mejor serán los resultados que se obtendrán. La mayoría de las veces el 80% de la solución está en definir claramente el problema. Cuando no se conoce bien el objetivo que se quiere conseguir, es muy difícil poder alcanzarlo.

Una vez identificado el problema, desafío u objetivo, conviértalo en una pregunta orientada a obtener la solución del mismo (la mayoría de las veces esto puede lograrse iniciando la oración con la palabra ¿cómo...?) y escríbalo en el inicio de la página.

El siguiente paso es comenzar a generar ideas o respuestas a su pregunta. Pero aquí está el truco: no debe detenerse hasta haber escrito 20 ideas. Sólo deje que las ideas fluyan, deje de lado los juicios que censuran las ideas, debe silenciar esa voz interior que critica sus ideas, debe dejar que fluya su creatividad, no importa cuan alocadas parezcan sus ideas, no debe darle importancia a eso en este momento.

Tenga en cuenta que las primeras cinco o diez le llevarán algunos minutos, las siguientes diez o quince probablemente le tome el doble de tiempo, y es muy probable que las últimas cinco le lleven mucho tiempo (más que todas las anteriores combinadas), sin embargo es aquí dónde, por lo general, se consiguen las respuestas más inspiradas y creativas, que llevarán a los mejores resultados.

Una vez que tenga sus 20 ideas escritas en la hoja de papel, vuelva a leerlas y elija la que sienta que es la correcta. Debe confiar en su instinto aquí, él es una guía extraordinaria, sólo relájese y confíe en su instinto. Luego de seleccionada la idea, comience nuevamente un mindstorming para generar 20 ideas sobre cómo llevarla a cabo.

A continuación, tome la lista 20 ideas y ordénelas de acuerdo al impacto que cada una de ellas tendrá en el logro del objetivo; seleccione la primera de la lista ordenada y comience a actuar inmediatamente en ella. Cuanto antes actúe sobre las respuestas que he descubierto, más probabilidades hay de que alcance el objetivo inicial.

Espero lo puedan poner en práctica y resulte de utilidad. ¡Hasta la próxima!

Lo que verdaderamente nos motiva

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Wed, 23 Jun 2010 07:02:21 PDT

Excelente video sobre las verdaderas causas de la motivación. Que lo disfruten!

Fuente: http://twitter.com/vcarazo.

Un enfoque iterativo e incremental para implementar la Gestión de la Configuración

noreply@blogger.com (Sergio Martínez) — Fri, 04 Jun 2010 14:11:34 PDT

Paso a paso…

Implementar un sistema de gestión de la configuración es un desafío importante, que puede encararse adoptando diferentes patrones y enfoques.

La capacidad de la gestión de la configuración, debe estar de acuerdo con los objetivos de negocio que se persiguen, pero también con las posibilidades de la organización de llevar adelante la iniciativa de poner en marcha y sostener en el tiempo un sistema de gestión de la configuración que brinde información útil, confiable y consistente.

Es por lo anteriormente mencionado, que se recomienda fuertemente que los arquitectos a cargo del diseño de la CMDB (Base de Datos de Gestión de la Configuración) consideren una evolución iterativa e incremental del modelo conceptual a implementar, que se enfoque en la rápida generación de valor y posibilidad de evolución de manera gradual y ordenada, permitiendo que la organización absorba el impacto del cambio de manera suave.

Desde el punto de vista de los datos, a continuación se describe un camino incremental, que busca alcanzar los objetivos planteados más arriba.

Etapa 1

Lo primero es vincular aplicaciones con servidores. Por lo general, la prioridad más importante cuándo se decide implementar un sistema de gestión de la configuración pasa por saber qué aplicaciones dependen de qué servidores y su relación inversa, lo cual, en términos generales, no representa complejidad desde el punto de vista de estructura de datos.

Es importante notar que en esta estructura de datos no hay distinción entre aplicación y software, o entre servidor y equipo. La dependencia de la aplicación con el servidor puede deberse a una base de datos, pero eso no se manifiesta en este modelo como una entidad separada, de modo que en este nivel, algunos detalles de información todavía serán manejados de manera algo pobre.

Todavía no se enfrenta el desafío de diferenciar productos tecnológicos de servicios de TI, tampoco se diferenciarán servidores físicos de servidores virtuales. Sin embargo, como un primer paso en este proceso incremental representa una base sólida que por si misma traerá sus desafíos a la hora de implementarse.

Etapa 2

En esta etapa se agrega el concepto de Almacenamiento de Datos al modelo, los cuales se manifestarán de manera explícita en el modelo, pero, con un enfoque simplificador, relacionándolos sólo con los servidores y las aplicaciones.

Un almacenamiento de datos requiere la intervención de un componente de base de datos desplegado en el servidor, pero por el momento no se prestará atención a esto.

Etapa 3

En esta etapa se distingue entre Servidor (una instancia lógica de un sistema operativo) y un Equipo (hardware físico) como dos ítems diferentes.

Alcanzar la madurez completa en éste área puede requerir mayor elaboración, dado que podríamos tener la necesidad de distinguir entre sistema operativo anfitrión y huésped, y equipos que contienen equipos (lo cual podría llevar a la necesidad de implementar relaciones recursivas en las entidades Servidor y Equipo) con la complejidad de manejo que esto puede implicar, sobre todo si la actualización de datos se realizara de manera distribuida.

Etapa 4

La etapa 4 distingue entre Aplicación y Sistema.

Este es un trabajo muy grande, que probablemente requiera de herramientas de descubrimiento automático para poder ser realizado de manera precisa.

Otra cuestión a considerar es que será necesario disponer de herramientas más potentes para la consulta y navegación de la base de datos (CMDB), dado que, por ejemplo, para conocer de qué servidores depende una aplicación, es necesario navegar a través del software desplegado (si bien es posible mantener la relación entre aplicación y servidor, el riesgo potencial de generar inconsistencias en la base de datos hace que esto no sea una práctica recomendable).

Etapas posteriores

Componente y Punto de Despliegue pueden ser los siguientes pasos a considerar, y a partir de aquí, una vez que los fundamentos de la CMDB han sido consolidados, se abren muchas opciones para continuar el camino del desarrollo de un sistema de gestión de la configuración completo.

Dependiendo de las posibilidades de la organización y las prioridades del negocio, se le puede dar más foco a todo lo que es Redes y Comunicaciones, Almacenamiento, etc.

Es importante no dejar de tener en cuenta que esta discusión sólo araña la superficie de la definición del desarrollo y consolidación de un sistema de Gestión de la Configuración y la implementación de una CMDB. Sin embargo, se recomienda fuertemente que se emplee este enfoque para encarar este tipo de proyectos, dado que intentar una implementación de alcance completo de una sola vez es un camino altamente riesgoso y con grandes posibilidades de fracaso. Utilizar este tipo de enfoques iterativos e incrementales con todas las restricciones que tienen los productos de los distintos proveedores será por sí mismo todo un desafío, pero las probabilidades de lograr el éxito serán mucho más altas.

¡Hasta la próxima!

Sergio

Referencias: Architecture and Patterns for Service Management Resource PLanning and Governance.

Documentación de usuario final de Project y Project Server 2010

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Thu, 27 May 2010 09:00:29 PDT

Ya está disponible on line la ayuda de Project y Project Server 2010 (en inglés):

Que la disfruten!

Predicciones Gartner 2010 sobre Administración de Carteras de Proyectos

noreply@blogger.com (Raúl Martínez) — Tue, 25 May 2010 15:25:20 PDT

Leyendo otro blog sobre Cartera de Proyectos, encontré una promoción de capacitaciones de Gartner Europe, que más allá de la publicidad es interesante de resumir para ver su visión sobre el tema. Aquí va una traducción libre.

Predicciones

Hacia el 2012, la utilización de herramientas de Administración de Proyectos en las aplicaciones críticas del negocio o de "la nube" crecerá más del 100%, erosionando la utilización de productos complejos de escritorio y planillas de cálculo.

Hacia el 2014, la duración promedio de un proyecto de TI se reducirá en un 25% mientras que el volumen promedio de trabajo formalmente completado en un período de 12 meses crecerá en un 25%.

Durante los próximos 18 meses, las Oficinas de Proyecto que no sean responsables directas por los proyectos, programas o carteras de proyectos serán radicalmente reestructuradas o desmanteladas.

Principales Hallazgos

Las Oficinas de Proyecto, proyectos, programas o carteras de proyectos, están en el foco como conductores hacia la efectividad y eficiencia organizativa. Históricamente, las diversas funciones de la Administración de Cartera siguieron las prácticas tradicionales orientadas alrededor del modelo de comando y control, con resultados diversos.

Recomendaciones

El aporte de valor, continuará siendo una cuestión clave que las Oficinas de Proyectos deben responder, junto con la prestación de amplio soporte a las Organizaciones para encajar en la necesidades de recuperación económica.
El pasaje al éxito de las oficinas de Proyecto es cada vez más a través de mayores niveles de madurez, mayor capacidad de sus individuos y un ajuste cada vez más cercano de sus actividades con las necesidades de la gobernanza de la Organización.

Vuelvo a repetir, se puede estar de acuerdo o no con sus predicciones, pero más allá de la publicidad de Gartner y de sus cursos, es interesante ver la proyección e importancia que dan al tema.

Para pensar…

Nota: para todos aquellos interesados en debatir sobre este tema, los espero en el Grupo Mejora de Procesos de TI en LinkedIn.

Saludos,

Raúl

Microsoft Project Server Blogs and Resources

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Fri, 14 May 2010 20:33:50 PDT

The following is a compilation of blogs and resources of Microsoft Project Server. Please feel free to help adding new resources. Will update the list with your comments with the aim of achieving a common repository of resources for EPM. Thank you all for your cooperation!

La siguiente es una compilación de blogs y recursos de Microsoft Project Server. Por favor, siéntanse libres de colaborar agregando nuevos recursos. Actualizaré la lista con sus comentarios con el objetivo de lograr un repositorio común de los recursos de EPM. Gracias a todos por su colaboración!

Continuar leyendo en: http://surpoint.blogspot.com/2010/05/microsoft-project-server-blogs-and.html.

Llegan los videos de Microsoft Project 2010 Ignite!!

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Thu, 13 May 2010 20:33:44 PDT

Bien, finalmente tenemos los videos de Microsoft Project 2010 Ignite. Este es un material de gran valor para todos los seguidores del tema EPM.

La lista de videos está compuesta por...

Continuar leyendo en: http://surpoint.blogspot.com/2010/05/llegan-los-videos-de-microsoft-project.html.

Microsoft Project Server 2010 RTM Demo Virtual Machine!

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Sat, 08 May 2010 21:23:41 PDT

Ya tenemos disponible la máquina virtual para demostraciones de Project Server 2010 RTM:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=751fa0d1-356c-4002-9c60-d539896c66ce

Fuente: http://surpoint.blogspot.com/2010/05/microsoft-project-server-2010-rtm-demo.html.

Webcast de Project Server 2010

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Fri, 07 May 2010 21:01:21 PDT

Para los interesados en la nueva versión de Project Server (2010), les dejo esta información proveniente del Faro de Project Server. Transcribo:

Nos llegan noticias de más webcasts en castellano, una ya celebrada (os adjuntamos el enlace a la grabación) y otra para el próximo Martes, 11 de Mayo de 2010.

Esperamos os resulten de interés:

https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=es-ES&EventID=1032448011&CountryCode=ES

https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032448014&EventCategory=4&culture=es-ES&CountryCode=ES

Que los disfruten!

Fuente: http://blogs.technet.com/elfarodeprojectserver/archive/2010/05/07/webcasts-project-2010-y-project-server-2010.aspx.

¿De qué se está hablando en el grupo de Mejora de Procesos de TI hoy 4 de mayo de 2010?

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Tue, 04 May 2010 11:07:08 PDT

Te esperamos en:

http://www.linkedin.com/groups?gid=2603073

WebCasts, Virtual Labs y Podcasts sobre Project Server

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Sat, 24 Apr 2010 09:20:10 PDT

Recursos interesantes para los que trabajamos con EPM:

http://www.microsoft.com/events/series/epm.aspx?tab=overview

Fuente: http://surpoint.blogspot.com/2010/04/webcasts-virtual-labs-y-podcasts-sobre.html

¿Problemas de comunicación?

noreply@blogger.com (Juan Pablo Pussacq Laborde) — Wed, 21 Apr 2010 19:10:31 PDT

Cuándo implementamos prácticas de administración de proyectos en las organizaciones, muchas veces nos encontramos con que los problemas típicos a resolver no son técnicos. Uno de los problemas no técnicos que (al menos yo) me he encontrado, es el problema de comunicación.

¿Les ha pasado lo mismo?

Si es así, no dejen de ver estos videos (que apenas duran unos minutos). Son muy útiles como inspiración para actividades o talleres. Se los recomiendo.

Estoy seguro que el primero lo mirarán más de una vez.

Hasta la próxima!

Otros videos de excelza en http://excelza.blogspot.com/search/label/videos.

Sobre la belleza

noreply@blogger.com (Pilar Barrio la Iglesia) — Wed, 21 Apr 2010 14:08:48 PDT

Algo que los testers hemos aprendido, a veces duramente, es que "LA BELLEZA ESTÁ EN LOS OJOS DEL OBSERVADOR", y de igual manera, la calidad de un sistema o producto de software puede medirse con una vara que tiene diferente medida según el interesado al que consultemos.

Para nosotros, entonces, el dicho pasa a ser "LA CALIDAD ESTÁ EN LOS OJOS DEL OBSERVADOR".

Relacionado con la belleza, también hemos aprendido que no siempre nuestra profesión o nuestras actividades son consideradas bellas, ya sea por otros miembros de los equipos de proyecto en que trabajamos, o incluso por estudiantes y futuros profesionales, que miran el testing como una actividad de segunda categoría.

Sin embargo, para nosotros el testing ES BELLO, ES interesante, ES desafiante.

Buscando bibliografía, di recientemente con este libro, que si bien no es un libro técnico, es muy interesante por la diferente y sin embargo común temática, y por las definiciones de muchos especialistas de qué es BEATIFUL TESTING para ellos. O qué encuentra bello cada uno, en relación a nuestra tarea de todos los días.

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice) by Tim Riley and Adam Goucher (Paperback - Oct. 22, 2009)

Según aclaran los editores, el libro no es una colección de how-to's, ni una colección de case-studies, y las regalías por su venta son donadas a una campaña de Naciones Unidas para la lucha contra la malaria en África.

Recopila ensayos de diversos profesionales, agrupados a lo largo de tres temáticas; cada ensayo es un capítulo. Las temáticas son:

Los Testers, sus características y su interacción con otras áreas (capítulos 1 a 4);
El Proceso, qué hace el tester y por qué (capítulos 5 a 17);
Las Herramientas que ayudan a los testers a hacer su trabajo más eficazmente (capítulos 18 a 23).

Considero interesantes a nivel general, los capítulos siguientes, y las definiciones de BELLEZA de sus autores:

Capítulo	Autor(es)	Título	La Belleza del Testing está en…
1	Linda Wilkinson	"Was it good for you?"	…La alegría de la exploración y el placer de la caza; Mantener esto siempre vivo en los testers, fomentarlo y premiarlo adecuadamente.
2	Rex Black	"Beautiful Testing Satisfies Stakeholders"	…Conocer a los interesados; Conocer sus objetivos y expectativas; Establecer métricas para medir objetivos y expectativas de los interesados (belleza externa); Establecer métricas para medir objetivos y expectativas de las pruebas (belleza interna).
6	Emily Chen y Brian Nitz	Bug Management and Test Case Effectiveness"	…Administrar los bugs, y medir la efectividad de los casos de prueba, de la forma más simple posible.
11	Murali Nandigama	"Change-Centric Testing"	…La eficiencia, no en el esfuerzo: entender qué se debería probar, y saber que eso es lo que se está probando.
12	Karen N. Johnson	"Software In Use"	…Que en este mundo imperfecto, la gente hace sus mejores esfuerzos para generar productos que importan, y cada uno de esos productos necesita gente que los sepa probar. (Este artículo se refiere en particular a software embebido en dispositivos médicos).
13	Chris McMahon	"Software Development is a Creative Process"	…La naturaleza artística de este trabajo: La construcción de software es un proceso estético, es la labor de interpretación de un artista, y el testing es la evaluación de esa interpretación. Por eso es bello.
18	Andreas Zeller y David Schuler	"Seeding Bugs to Find Bugs: Beautiful Mutation Testing"	…Poder experimentar con las nuevas herramientas disponibles para hacer test de mutaciones, y con ellas analizar la calidad de las pruebas automáticas utilizadas (poder hacer QA del QA).

Y en particular, creo que el Capítulo 1, de Linda Wilkinson, "Was it good for you?", debería ser leído por todos los líderes involucrados en proyectos, sean o no líderes de testing, y por los responsables de áreas funcionales de QA/QC.

Otros capítulos pueden resultar igualmente interesantes, en función al tema / proceso / herramienta que particularmente tratan y nuestro contexto inmediato.

¿Qué más encuentran bello en nuestro trabajo como testers?

Los invito a discutirlo en el grupo Mejora de Procesos de TI en LinkedIn.

¡Hasta la próxima!

Pilar

Un modelo de madurez para la Gestión de la Configuración

noreply@blogger.com (Sergio Martínez) — Wed, 21 Apr 2010 03:45:33 PDT

El siguiente modelo de madurez intenta reflejar tanto las necesidades del control y gestión de las dependencias entre componentes, como las del gobierno de TI.

Puede que no sea el mejor modelo ni el del gusto particular de cada uno, pero sin dudas, es una buena referencia de como trazar el camino hacia la implementación de la gestión de la configuración, de acuerdo a las necesidades y posibilidades de cada organización.

Además, tengamos siempre presente que no todas las organizaciones necesitan buscar desesperadamente los máximos niveles de madurez en todos sus procesos, y que, en todo caso esto generalmente responde a una necesidad de disminuir el nivel de exposición a determinados riesgos (menor madurez –> mayor riesgo; mayor madurez –> menor riesgo).

Espero sea de utilidad…

Nivel	Hardware	Software
1	Se mantiene un inventario de hardware a mano mediante inventarios periódicos.	Se mantiene un inventario de licencias de software a mano mediante inventarios periódicos.
2	Se mantiene un inventario de hardware mediante los procesos de compras y gestión de cambios, apoyado por herramientas básicas de descubrimiento automático.	Se mantiene un inventario de licencias de software mediante los procesos de Compras y Gestión de Cambios.
3	Las características del hardware y sus dependencias (topología de la red, por ejemplo) se descubren automáticamente mediante herramientas. Se realiza barrido automático de la configuración instalada para reforzar el control de los cambios.	Se mantiene la cartera de aplicaciones corporativas, incluyendo propietarios y responsabilidades, y se la controla por la gestión de cambios. Se mantienen las dependencias aplicaciones-servidor y se utilizan como base para la evaluación de impacto de cambios. Se realiza barrido automático de la configuración instalada para la detección de cambios. Los cambios detectados se concilian con el proceso de gestión de cambios y se toman acciones correctivas para los cambios no autorizados o no planificados.
4	Se mantienen las dependencias entre hardware y software mediante barrido automático de la configuración instalada basado en identificación unívoca de los componentes.	Se mantienen las dependencias entre servicio de TI y software mediante identificación unívoca de los componentes. Se mantienen los catálogos de bases de datos como ítems de configuración. Se mantienen las dependencias entre aplicaciones. Se mantienen las dependencias entre aplicaciones y software (de base). Se utiliza un sistema de evaluación de riesgos de los cambios basado (al menos parcialmente) en exploración automática de dependencias (haciendo uso del sistema de gestión de la configuración). Se refuerza la precisión de la información de la base de datos de configuración (CMDB) mediante la implementación de procesos de seguridad: “si no está en la CMDB no puede ser accedido”.
5	Se realiza barrido automático de control de cambios integrado con la gestión de configuración, orientada (a su vez) a la gestión de activos.	Se mapean completamente las dependencias de los componentes del middleware. Se hace posible la gestión a nivel de componentes cuando la relación costo / beneficio lo justifica. La gestión de la arquitectura corporativa y la administración de cartera de servicios usan la gestión de la configuración para crear modelos de análisis tipo what-if. Los procesos de gestión de servicios refuerzan el uso y la precisión de la información en la base de datos de configuración (CMDB): “si no está en la CMDB, no se puede incluir en ningún acuerdo de nivel de servicios (SLA), ni en los modelos de capacidad o disponibilidad (por ejemplo)”. El diccionario de datos se integra a la base de datos de configuración (CMDB) para dar cumplimiento a requisitos regulatorios.

¡Hasta la próxima!

Sergio

Nota: para todos aquellos interesados en debatir sobre este tema, los esperamos en el grupo Mejora de Procesos de TI en LinkedIn.

Referencias:

Sobre la Gestión de la Configuración
Architecture and Patterns for IT Service Management, Resource Planning and Governance.

Sobre la Gestión de la Configuración

noreply@blogger.com (Sergio Martínez) — Mon, 19 Apr 2010 05:25:39 PDT

Gestionar la configuración de producción

Muchas compañías simplemente no conocen, ya sea con el nivel de detalle o con la precisión necesarios, los activos informáticos que poseen, dónde se encuentran ubicados, quién es el responsable o propietario interno y cuánto cuesta mantenerlos operativos.

La gestión de la configuración consiste en la registración, seguimiento y reporte de los componentes de interés de los servicios de TI y sus interrelaciones.

En general la gestión de la configuración incluye procesos de auditoría e informe del estado de los componentes, actividades que representan un área crítica para el sostenimiento del valor de cualquier sistema de gestión de la configuración.

La gestión de la configuración representa una de las áreas más problemáticas en la cadena de valor de TI, pero sin ella se torna altamente dificultoso tomar decisiones precisas e informadas.

Muchas veces cuesta justificar su inclusión como parte principal de la cadena de valor de TI, dado que en general los clientes de TI no son capaces de apreciar el valor que representa, sin embargo, la información que brinda es tan crítica en muchos aspectos relacionados con la creación y operación de servicios de valor, que relegarla a los procesos secundarios es altamente desaconsejable.

Dos sabores de Gestión de la Configuración

La gestión de la configuración, desde el punto de vista de la Gestión de Servicios de TI, puede ser considerada de dos formas distintas.

La primera es la más técnica (si se quiere), que está relacionada con la detección de cambios, por ejemplo:

¿por qué está caído el servidor XYZ?
¿qué cambió en la configuración del firewall?
¿quién realizó qué cambios y cuándo?

La integridad y la seguridad de la configuración de los ambientes productivos son la prioridad desde este punto de vista. Conocer que algo ha cambiado puede ser esencial para evitar incidentes o identificar brechas de seguridad que puedan estar siendo explotadas.

El segundo aspecto de la gestión de la configuración es el de cartera, activos y dependencias. Este es el que nos permite responder preguntas del siguiente tipo:

¿qué aplicaciones están corriendo en tal o cual servidor?
¿qué procesos de negocio soporta tal o cual servicio?
¿qué bases de datos interactúan con tal o cuál aplicación?

Estas preguntas son muy importantes para actividades tales como la gestión de riesgos, incidentes y problemas, así como también para el análisis y planificación de largo plazo de la cartera de servicios.

Administración de las dependencias como fundamento del Gobierno de TI

Las dependencias son un fundamento esencial para el gobierno de TI: los procesos de negocio dependen de servicios de TI, la capacidad funcional de los servicios depende de aplicaciones, las aplicaciones dependen de bases de datos, las bases de datos dependen de servidores, los servidores dependen de dispositivos de comunicación, y así siguiendo. Las organizaciones de TI trabajan con esta información a diario, pero en general la tratan de manera (casi) vergonzosa.

La información de las dependencias no es barata. Típicamente se genera a partir del trabajo de un equipo de recursos caros, que registran qué está instalado dónde, con qué se comunica, y que necesita para correr. En general esta información se captura en herramientas de escritorio (planillas de cálculo, documentos, etc.), raramente se sincroniza con los procesos de gestión y en general no se pone a disposición para todos los posibles interesados.

Si consideramos áreas tales como administración de cartera de servicios, arquitectura corporativa, desarrollo de aplicaciones, gestión de la información, inteligencia de negocio y data warehousing, soporte de servicio, planificación de la capacidad, conformidad regulatoria, continuidad de los servicios de TI, administración de la seguridad, gestión financiera de TI, etc; como algunas de las áreas productoras o consumidoras de este tipo de información, en general se las puede encontrar capturando, organizando y utilizando en gran medida el mismo tipo de información esencial, sin tomar en cuenta el trabajo que cada uno de los otros está realizando sobre el tema.

Las dependencias representan parte del a información más valiosa para una organización de TI, sin embargo en general es tratada casi como basura, o peor aún, como propiedad privada de algunas pocas personas (muchas veces proveedores), que ven su conocimiento sobre algunas dependencias como un seguro de trabajo.

Ya sea de forma automática o manual, si no se dispone de un repositorio centralizado y el proceso adecuado para mantenerlo actualizado, la información de dependencias que haya podido capturar se harán humo en cortísimo plazo. De modo que la próxima vez que encuentre un proyecto de captura de información de dependencias, que involucre algunos personas levantando datos en planillas descartables pregúntese: “¿existe una mejor manera de hacer esto?”…

Saludos,

Sergio

Nota: para todos aquellos interesados en debatir sobre este tema, los esperamos en el grupo Mejora de Procesos de TI en LinkedIn.

Referencia: Architecture and Patterns for IT Service Management, Resource Planning and Governance.