ALM BootCamp–Video de las presentaciones

por Daniel Laco  23. mayo 2011

 

El pasado 28 de Abril participamos como oradores con Victor Passador en el ALM BootCamp en Microsoft Argentina.

También participaron Juan Pablo Díaz, Maxi Accotto y Eric Delahaye.

Aquí les dejo los videos de las presentaciones y que las disfruten !

 

Apertura - Juan Pablo Díaz:

 

 

Control de Versiones - Daniel Laco:

 

 

Versionado de Base de Datos - Maxi Accotto:

 

 

Arquitectura - Eric Delahaye:

 

 

Testing- Victor Passador:

 

 

Reportes Agiles en Team Foundation Server – Stories Overview Report

por Viviana Chelini  10. noviembre 2010

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Status on All Iterations Report

 

Hoy comentaremos sobre:

Stories Overview Report (Agile)

El siguiente reporte muestra gráficamente información general sobre los casos de uso definido para una iteración o área determinada.

Información que proporciona el reporte

El reporte presenta una visión del trabajo realizado para el conjunto de casos de uso filtrados hasta la fecha actual.

Este reporte muestra la siguiente información sobre cada caso de uso:

Progreso del trabajo

  • % de horas completadas: un valor numérico y representación visual que muestra el porcentaje de trabajo completado.
  • Horas restantes: un valor numérico de todas las horas restantes para todas las tareas vinculadas al caso de uso o sus casos secundarios.

Estado de la prueba

  • Pruebas: un valor numérico que representa el número de casos de prueba vinculados al caso de uso o sus casos secundarios.
  • Resultados de pruebas: un valor numérico y representación visual que muestra el porcentaje de casos de prueba, agrupados según el estado de su ejecución de pruebas más reciente, donde las opciones son Superadas (verde), Con error (rojo) o Sin ejecutar (negro).
  • Errores: un valor numérico y representación visual que muestra el número de errores vinculados al caso de prueba o caso de uso, donde las opciones son Activa (azul) y Resuelto (oro).

El reporte de Información general enumera y resalta los casos según los siguientes criterios:

  • Los casos aparecen por orden de importancia, que está basado en su clasificación asignada.
  • Los casos aparecen en tipo en negrita cuando están en el estado activo o resuelto.
  • Los casos aparecen en tipo normal cuando están en el estado cerrado.
  • Los casos aparecen en tipo gris cuando su iteración o área asignada está fuera del conjunto filtrado, pero tienen tareas o casos secundarios que están dentro del conjunto filtrado de iteraciones o áreas de producto.

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

  • Definir los casos de uso y tareas, crear un vínculo Secundario desde cada tarea a un caso de uso y crear un vínculo Secundario desde cualquier subtarea a su tarea primaria.
  • Definir y actualizar los campos Completado y Restante para cada tarea o subtarea durante la iteración o versión.
  • Definir los casos de prueba y crear el vínculo Prueba realiza por desde cada caso de prueba a un caso de uso.
  • Para cada error, crear el vínculo Prueba realiza por al caso de prueba que identificó el defecto de código o un vínculo Relacionado al caso de uso con el que está relacionado el error.
  • Establecer el Estado de cada error en Resuelto cuando se corrija.
  • Especificar las rutas de acceso Área e Iteración para cada caso, tarea, caso de prueba y error.

 

Análisis del reporte

El reporte de Información general muestra el progreso de trabajo global en tres áreas que son importantes para completar y cerrar un caso de uso:

  • Tareas implementadas para completar el caso de uso.
  • Casos de prueba ejecutados para asegurar la calidad de los casos implementados.
  • Errores identificados que indican los problemas con la calidad de los casos de uso.
Progreso del trabajo
  • ¿Corresponde a sus expectativas la cantidad de trabajo que resta para cada caso de uso?
  • ¿Se implementan primero los casos de uso clasificados según su relevancia?
  • ¿Cuántas pruebas se definen para cada caso de uso?¿Cuántas pruebas se superan?
  • ¿Qué casos de uso se implementan que no tienen ningún caso de prueba definido para ellos?
Progreso de la calidad
  • ¿Cuántos casos de prueba se han ejecutado para cada caso de uso y cuántos han superado las pruebas?
  • ¿Cuántos errores activos tiene cada caso de uso?
  • ¿Se encuentran errores para los casos de uso que se prueban?
  • ¿Se resuelven los errores o siguen activos?
Evaluación de riesgo
  • ¿Qué casos de uso están en riesgo?
  • ¿Qué casos de uso no son suficientemente estables para la versión?
  • ¿Qué casos de uso puede distribuir hoy el equipo?

 

Versión positiva del reporte

Un reporte positivo muestra más progreso en los casos de uso que aparecen cerca de la parte superior del reporte. En la imagen que se muestra a continuación se visualiza que el equipo ha realizado más trabajo para los casos que aparecen en el reporte.

 

 

Versión negativa del reporte

Un reporte negativo muestra una o más de los siguientes indicadores:

  • El equipo está realizando más progreso en los casos de uso que tienen un rango inferior que en los que tienen un rango superior.
  • Hay más pruebas con errores que superadas.
  • Se producen errores en las pruebas para un caso de uso, pero no se crea ningún elemento de trabajo de error.

 

Hasta la próxima.

 

Tags: , ,

ASP.NET | Javascript | ORM | TFS

Reportes Agiles en Team Foundation Server – Remaining Work Report

por Viviana Chelini  29. octubre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

 

Seguimos en este post con:

Remaining Work Report

El reporte de trabajo restante permite realizar un seguimiento del progreso del equipo e identificar cualquier problema en el flujo de trabajo.

Información que proporciona el reporte

El reporte puede visualizarse según las horas trabajadas o el número de elementos de trabajo para cada tarea, caso de uso o error.

La primera vista (horas trabajadas) muestra el número total de horas de trabajo para el período de tiempo especificado y el progreso del equipo para completar ese trabajo. La segunda vista (elementos de trabajo) muestra el número de elementos de trabajo para el período de tiempo especificado y el número de elementos de trabajo en cada estado.

Horas de trabajo

Aquí se muestra un ejemplo del reporte en la vista Horas de Trabajo. Este ejemplo es positivo en cuanto que se ha completado una tasa constante de trabajo.

 

  • Horas restantes: valor acumulado de todas las horas restantes para todas las tareas.
  • Horas completadas: valor acumulado de todas las horas completadas para todas las tareas.

Número de elementos de trabajo

La ilustración siguiente muestra el mismo reporte pero en la vista Elementos de Trabajo, con los elementos de trabajo agrupados por estado. Un análisis del graficó permite determinar que el equipo realizó un progreso adecuado pero la estimación de elementos de trabajo aumentó desde el inicio de la iteración a casi tres veces más hacia el final de la iteración.

 

  • Activo: valor acumulado de todos los casos de uso, tareas y errores que se encuentran en estado Activo (azul).
  • Resuelto: valor acumulado de todos los casos de uso o errores que se encuentran en estado Resuelto (oro).
  • Cerrado: valor acumulado de todos los casos de uso, tareas y errores que se encuentran en estado Cerrado (verde).

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

 

  • Definir los casos de uso, tareas y errores y especificar las rutas de acceso de Área e Iteración para cada elemento de trabajo.
  • Especificar y actualizar los campos Horas Completadas y Horas Restantes para cada tarea o subtarea a medida que el equipo realiza progresos en cada elemento de trabajo.
  • Actualizar el Estado de cada tarea, caso de uso y error cuando progrese de activo a cerrado.


Análisis del reporte

El reporte muestra información que permite visualizar si el equipo progresa correctamente y si finalizará las tareas dentro del tiempo asignado, como así también permite responder a las siguientes preguntas:

 

  • ¿Con qué rapidez avanza el equipo hacia el trabajo restante?
  • ¿Se agrega trabajo durante la iteración?
  • ¿Cuánto progreso puede realizar el equipo en el tiempo disponible?
  • ¿Hay demasiado trabajo en curso?
  • ¿El flujo de trabajo se impide o está bloqueado?
  • ¿Cuándo finalizará el equipo la iteración actual?


Versión positiva del reporte

Un reporte positivo muestra un progreso constante para resolver y cerrar las tareas. La forma rectangular del diagrama indica que el trabajo estimado coincide con el trabajo final y no fue necesario agregar nuevas tareas.

Versión negativa del reporte

Un reporte negativo muestra poco progreso y las líneas planas del gráfico identifican que las tareas permanecen en el mismo estado durante un tiempo prolongado. También se puede determinar que le número elementos de trabajo aumenta después del punto medio de la iteración, lo que indica que se han introducido nuevas tareas las cuales no habían sido planificadas.

 

Los posibles indicadores que se pueden visualizar en un reporte negativo son:

  • El número de horas completadas o el número de elementos de trabajo resueltos o cerrados sigue siendo plano, se podría deben a un bloqueo en el progreso del equipo.
  • El número de horas restantes o elementos de trabajo activos aumenta.

    Esta situación indica que el equipo no estimó con precisión el trabajo en el inicio de la iteración o que el equipo agregó las características después de que se inició la iteración.

Reportes Agiles en Team Foundation Server – Build Quality Indicators Report

por Viviana Chelini  28. septiembre 2010

 

Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :

Bug Status Report

Bug Trend Report

Reactivation Report

Seguimos en este post con:

 

Build Quality Indicators Report

El siguiente reporte muestra la cobertura de pruebas, la renovación de código y el número de errores para una compilación especificada.

 

Información que proporciona el reporte

En el reporte se puede visualizar sobre el eje X las compilaciones que incluye el reporte, sobre la base de los filtros establecidos para la plataforma, la configuración y la definición de la compilación.

Cada barra vertical representa un conjunto de datos derivados de una o más compilaciones. En la variante de tamaño de código del reporte, la longitud de cada barra vertical representa el tamaño de la base de código protegida. Las pruebas manuales se pueden ejecutar en cualquier momento después de la compilación y están asociadas a esa compilación. Las pruebas que no se han ejecutado todavía se cuentan como "no concluyentes".

En la siguiente tabla se describe la información que aparece en el reporte:

Indicador

Descripción

Errores activos (número)

Gráfico de líneas que representa el número de errores que estaban activos al momento de la compilación.

Renovación de código (líneas)

Gráfico de líneas que describe el número de líneas de código que el equipo agregó, quitó y modificó antes de la compilación. La renovación de código se calcula determinando el número de líneas de código que se han agregado, eliminado o modificado en la compilación dividido por el número total de líneas de la compilación.

Cobertura de código (porcentaje)

Gráfico de líneas que representa el porcentaje de código que cubren las pruebas.

Pruebas no concluyentes

Gráfico de barras apiladas de color gris que indica el número de pruebas que no tuvieron un resultado correcto o se pusieron en pausa. Si la compilación no tuvo un resultado correcto, las pruebas no se cuentan o se cuentan como no concluyentes.

Ejemplo de informe Indicadores de calidad de la compilación

Pruebas no superadas

Gráfico de barras apiladas de color rojo que indica el número de pruebas no superadas para la compilación.

Pruebas superadas

Gráfico de barras apiladas de color verde que indica el número de pruebas superadas para la compilación.

Para que el reporte sea fiable los miembros del equipo deben realizar las siguientes actividades para administrar pruebas y compilaciones:

  • Configurar un sistema de compilación. Para utilizar Team Foundation Build, debe configurar un sistema de compilación.
  • Crear definiciones de compilación. Puede crear varias definiciones de compilación, de modo que cada una de ellas pueda ejecutarse para generar código para una plataforma diferente.
  • Definir las pruebas que se ejecutarán automáticamente como parte de la compilación.
  • Configurar las pruebas para recopilar datos de cobertura de código. Para que los datos de cobertura de código aparezcan en el reporte, los miembros del equipo deben instrumentar las pruebas para recopilar esos datos.
  • Ejecutar compilaciones con regularidad. Puede ejecutar compilaciones a intervalos establecidos o después de cada protección. Puede crear compilaciones periódicas cuando utilice el desencadenador de programación.

 

Análisis del reporte

El reporte permite responder las siguientes preguntas:

  • ¿Cuál es la calidad del software?
  • ¿Está el equipo probando suficiente código?
  • ¿Se están superando las pruebas?
  • ¿Es probable que el equipo termine en función del código y las métricas de pruebas?
  • ¿Con qué frecuencia se superan las pruebas y con qué frecuencia se prueba el código?

 

Versión positiva del reporte

Un reporte positivo muestra los siguientes indicadores:

  • La mayoría de las pruebas se superan (áreas grandes de color verde) y pocas pruebas no se superan (cantidades pequeñas de color rojo).
  • El porcentaje de color rojo es inferior al 20-30 por ciento.

Versión positiva del indicador de calidades de compilación

 

Versiones negativas del reporte

Una versión negativa mostrará uno o más de los siguientes indicadores:

  • Menos cobertura de código y más renovación de código. Podría indicar que el nuevo código se protege sin las correspondientes pruebas unitarias que lo cubran.

    Renovación de código del informe Indicadores de calidad de la compilación

  • Baja tasa de pruebas en ejecución. Estos datos podrían indicar que el equipo no está realizando suficientes pruebas. Este bloqueo podría indicar falta de recursos o que los evaluadores estén haciendo otras tareas, como escribir la automatización de pruebas en lugar de probar la funcionalidad actual.

    Baja tasa de pruebas en el informe Indicadores de calidad de la compilación

  • Alta renovación de código, baja tasa de cobertura de código. Una alta renovación de código sugiere que los errores se introducirán como efectos secundarios de los cambios. De lo contrario, una alta renovación de código podría indicar una cobertura reducida y la necesidad de reescribir pruebas.

    Alta renovación de código en el informe Indicadores de calidad de la compilación

  • Tasa alta de pruebas no superadas. La siguiente ilustración muestra que muchas pruebas se realizan con una cobertura de código razonable, pero que no se están superando las pruebas. Estos datos podrían indicar prácticas de desarrollo poco rigurosas o, en iteraciones tempranas, que las pruebas son demasiado duras para esta etapa del producto.

    Prueba no superada en el informe Indicadores de calidad de la compilación

  • Alta tasa de pruebas que se superan y alta tasa de errores activos. La siguiente ilustración muestra una alta tasa de pruebas superadas pero, no obstante, un alta tasa de errores de entrada. Esta situación se puede producir por varias razones. Es posible que las pruebas no sean suficientemente rigurosas para esta etapa del producto.

    Baja tasa de pruebas en el informe Indicadores de calidad de la compilación

  • Tasa creciente de superación de pruebas sin aumento en la cobertura de código. Habitualmente, cuantas más pruebas se realizan, se debe cubrir más código. Por otro lado, si la ejecución de pruebas y las tasas de superación de pruebas aumentan sin un aumento correspondiente en la cobertura de código, es posible que las pruebas incrementales sean redundantes.
  • El número de errores activos aumenta, pero las pruebas no superadas no aumentan. Es probable que las pruebas no estén probando la misma funcionalidad que indican los errores.
  • El número de errores activos está disminuyendo, pero las pruebas superadas no aumentan. Puede que exista un aumento en la tasa de reactivación.

 

 

Tags: , ,

ALM | Gestión de Proyectos | TFS

Reportes Agiles en Team Foundation Server – Bug Trend Report

por Viviana Chelini  16. septiembre 2010

En el post anterior publiqué una introducción al tema de reportes Ágiles y un resumen de uno de los reportes.

Seguimos la serie con:

Bug Trend Report

El siguiente reporte ayuda a obtener y seguir la tasa de detección y resolución de errores del equipo. Este reporte muestra un promedio acumulado o móvil de los errores notificados, resueltos y cerrados a lo largo del tiempo, obteniendo una visión de la medida en que el equipo está encontrando, resolviendo y cerrando los errores.

Información que proporciona el reporte

El reporte calcula un promedio acumulado del número de errores que el equipo ha abierto, resuelto y cerrado. El promedio acumulado se basa en los siete días antes de la fecha para la que se calcula. Es decir, el reporte calcula el promedio del número de errores en cada estado para cada uno de los siete días antes de la fecha y, a continuación, divide el resultado entre siete.

BugStatusReport1

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

  • Definir los errores y especificar sus rutas de acceso de Área e Iteración.
  • Actualizar el Estado de cada error cuando se ha corregido, probado y cerrado.
  • Especificar la Prioridad y Gravedad de cada error durante la evaluación de errores.


Análisis del reporte

Las tasas de errores se interpretan mejor comparándolas con todas las actividades de proyecto de equipo actuales y las otras métricas que proporcionan los reportes de Estado del error y Reactivaciones. Por ejemplo, el equipo podría encontrar errores con especial rapidez en código mal escrito, en código recientemente integrado, con pruebas mejoradas o durante un evento excepcional como una búsqueda intensiva de errores. Por otra parte, los errores son más difíciles de encontrar en un producto de alta calidad y con pruebas ineficaces. Cuando el producto se estabiliza hacia el fin de un ciclo del producto, el equipo debería encontrar errores con menos frecuencia.

El reporte podría informar determinadas situaciones que se deberían evaluar porque surgen:

· El equipo encuentra el mismo número de errores aproximadamente en períodos de tiempo sucesivos.

o ¿Son adecuados los casos de prueba para probar los casos de uso que se están desarrollando?

o ¿Las pruebas se han vuelto obsoletas o están probando la funcionalidad equivocada?

o ¿El equipo de pruebas está probando cada caso de uso rigurosamente?

· El equipo resuelve muchos errores en cada período

o ¿Se cierran rápidamente los errores resueltos? La tasa de errores cerrados debe ser similar a la de errores resueltos.

o ¿Permanecen las reactivaciones de errores dentro de los límites esperados?

· El equipo resuelve los errores rápidamente pero no los cierra.

o ¿Están sobreasignados los recursos de pruebas?

o ¿Debería el equipo volver a revisar las prioridades de pruebas?

Versión positiva del reporte

Un reporte positivo muestra que el equipo encuentra más errores en el inicio de un ciclo de desarrollo y menos errores hacia el fin de una iteración. Cuando el equipo resuelve los errores más rápidamente que los encuentra, el número de errores activos empezará a disminuir. Cuando el equipo empieza a encontrar menos errores, el producto se estará estabilizando.

Versión negativa del reporte

Un reporte negativo podría mostrar que el equipo encuentra errores más rápidamente a medida que se acerca la fecha de envío y los resuelve más lentamente. En esta situación, el trabajo pendiente del equipo está aumentando, ya que los errores no se corrigen y sería conveniente investigar las causas.

 

 

BugStatusReport2

Nuevos conceptos en TFS 2010

por Victor Passador  8. julio 2010

Como es de esperarse a estas alturas, existe infinidad de blogs que enumeran las características que vienen con la nueva versión de Team Foundation Server.

Para no caer en la misma situación, la idea de este post es que nos enfoquemos solamente en algunas pocas de esas nuevas características a las que el nombre de “feature” le queda un poco chico, ya que implican un cambio más de fondo y que va un  poco más allá de una simple “nueva funcionalidad”.

Project Collections

Las colecciones de proyectos brindan una capa adicional de indirección que permite el agrupamiento de proyectos según el criterio que a nosotros más nos convenga. Esta agrupación podría ser por tipo de arquitectura, por equipo o área de la empresa, o por ejemplo, separando proyectos de desarrollo de aquellos otros de consultoría.

Lo interesante de este agrupamiento es que no es solamente a nivel lógico, sino que también lo es a nivel físico. Esto permite lograr un mejor nivel de aislamiento entre proyectos, y ese aislamiento impacta en el aspecto de seguridad, ya que cada colección equivale a una nueva instancia de TFS en términos de sus versiones 2005/2008.

Project collection compartmentalization

 

El lector atento dirá a esta altura “… pero ojo… acá la cosa se complica …”.

Y si, como en cualquier otro caso, nos encontraremos con ventajas y desventajas en la implementación de colecciones de proyectos. Vamos a enumerar las más importantes:

Ventajas:
  • Aunque parezca obvio, no deja de ser una ventaja el hecho de poder seguir trabajando como en las versiones anteriores de TFS si no tenemos ganas de complicarnos la vida con estas colecciones, con la única salvedad de que nuestros proyectos estarán ahora dentro de una “Default Collection”.
  • Como cada colección maneja su propia base de datos, tenemos muchas más opciones a la hora de escalar y manejar balanceo de carga.
  • En grandes organizaciones (y no tanto), este nivel de aislamiento permite una administración de seguridad mucho más granular.
  • Tenemos la posibilidad de hacer respaldo/restauración de grupos de proyectos de manera independiente.
 
Desventajas:
  • Lo que para algunos pueda ser una ventaja, es lo contrario para otros, ya que se podrá argumentar que ante una gran cantidad de colecciones se complicará seguramente la tarea del administrador al momento de configurar permisos de acceso a cada uno de los proyectos.
  • A raíz de que cada colección usa su propia base de datos, nos encontraremos con una tarea más ardua al momento de administrar copias de resguardo de toda esa información adicional.

 

En el blog de Steve Lange podrán encontrar un diagrama de flujo muy interesante que les ayudará a decidir si necesitan o no manejar Project Collections.

 

Nuevos templates de Proyectos

Al momento de crear un nuevo proyecto en TFS en la versión 2010, nos encontraremos con un par de nuevos templates, entre ellos la versión 5.0 de MSF for Agile (aquí podrán encontrar una comparativa con la versión anterior).

No quisiera centrarme en describir el proceso que intenta implementar, sino en la funcionalidad que aportan sus nuevos tipos de Work Item, Workflows y por sobre todo, las nuevas relaciones que se pueden establecer entre ellos.

Cabe recordar que TFS 2010 permite establecer jerarquías de work items y además crear relaciones mucho más ricas que una simple dependencia de ida y vuelta entre uno y otro. Valiéndose de esto último, el nuevo template permitirá documentar por ejemplo “Historias de Usuario” y “Casos de Test” vinculados por una relación de tipo “Testea a …” o “Testeado por …” entre otras.

Este es, indudablemente, un modelo mucho más rico que el anterior, ya que permite ser explotado por queries mucho más intuitivas, muchas de las cuales ya vienen incluidas en el propio template.

Podríamos consultar, por ejemplo, Historias de Usuario que no cuentan con casos de test asociados para tener rápidamente un acceso a partes de nuestra aplicación que no tienen las pruebas mínimas necesarias.

 

Dashboards

Gracias a su integración con las últimas versiones de Sharepoint, los portales de proyectos creados con TFS 2010 mejoran su capacidad de reporting incluyendo Dashboards.

La idea de un Dashboard (o tablero de control) es contar con una consola que incluya diferentes indicadores que muestren rápidamente la situación actual del proyecto en un único lugar pero a un nivel más “macro” y que, además, permita a las áreas gerenciales determinar que tan en línea está un determinado proyecto con las políticas de su negocio.

Los Sharepoint Dashboard son la materialización de lo que se conoce como Balance Scorecards, es decir, sistemas de gestión y planificación estratégica que intentan alinear las actividades diarias del desarrollo con la visión de la empresa.

Obviamente estos Dashboards son altamente personalizables, pero de manera inmediata podremos contar con la siguiente información:

  • Reporte de Task Burndown
  • Lista de cantidades de Work Items en sus diferentes posibles estados (Activos, Cerrados, Resolved, etc.)
  • Lista de fechas importantes
  • Lista de los últimos Builds
  • Lista de los últimos checkins realizados y sus comentarios
  • Vista rápida del Product backlog donde se ve el estados de sus items

 

Cada uno de estos indicadores no es más que un wepbart embebido en el portal Sharepoint, por lo que contando con MOSS podremos personalizarlos y/o extenderlos de una manera muy flexible.

Hasta la próxima.

Tags: , , ,

Gestión de Proyectos | Sharepoint | TFS

Manage IT 2010 - Gestión de Proyectos y Arquitectura de Software

por Daniel Laco  26. abril 2010

Se viene el evento nuevamente !!!

 

Este año estaremos repitiendo el evento sobre Gestión de Proyectos y Arquitectura de Software.

VEMN SA conjuntamente con el MUG, Lagash SA y el apoyo de la Universidad Argentina de la Empresa (UADE) realizaremos el evento el día 8 de Junio a las 9.00 hs. en la sala Magna de la UADE.

Temario

8:30 - 9:30 Acreditación
9:30 – 10:00 Presentación del Evento y KeyNote
10:00 – 11:15 Value Express. Optimizando los resultados de sus inversiones realizadas.
(Susana Silberberg)
11:15 - 11:45 Break
11:45 – 13:00 Desarrollo de aplicaciones de misión crítica.
(Diego Gonzalez y Rodolfo Finochietti)
13:00 – 14:15 Almuerzo Libre
14:15 – 15:30 Estimación de Proyectos de Software. La cara oculta de las diferencias.
(Daniel Laco y Patricia Scalzone)
15:30 – 16:00 Break
16:00 – 17:15 ¿Sueñan los Gerentes de IT con programadores eléctricos?
(Luis Ávalo)
17:15 – 17:30 Cierre y Sorteos
Es un evento de interés para profesionales de TI, Gerentes de Sistemas, Líderes de Proyectos, Arquitectos, Analistas y todo aquel interesado en el mundo TI.


El evento es gratuito. Vacantes limitadas, con inscripción previa.

Para mas información en www.manageit.com.ar.


Posición Estratégica de las Empresas

por Patricia Scalzone  18. marzo 2008
Toda empresa que compite en un sector industrial posee una estrategia competitiva, ya sea explícita o implícita. Esta estrategia pudo haber sido desarrollada explícitamente mediante un proceso de planeación o pudo haberse originado en forma implícita a través de la actividad agregada de los diferentes departamentos funcionales de la empresa.Dejado a sus propios medios, cada departamento funcional inevitablemente seguirá los enfoques dictados por su orientación profesional y las motivaciones que están a su cargo. Sin embargo, la suma de estos enfoques departamentales rara vez llega a ser la mejor estrategia (PORTER, 1982).
 
La formulación de la planeación estratégica generada por los mandos administrativos de los diferentes departamentos de las empresas busca ejecutar políticas encaminadas a la coordinación de las actividades para lograr objetivos comunes. Para el caso de planeaciones estratégicas implícitas, estos objetivos comunes no se encuentran desarrollados formalmente, por lo que difícilmente lograrán repercutir en el rumbo de la empresa en un largo plazo, más que todo buscan mantener la operatividad cotidiana.
 
Esta es la situación de la mayoría de las empresas nacionales que se rigen por administraciones o bien empíricas, ortodoxas o de corte familiar. En la actualidad, su planificación no contempla algunos factores necesarios para enfrentar la época de globalización que se desarrolla actualmente, pero los reconoce como fundamentales, tales como son: la competencia con empresas multinacionales mucho más grandes y completas que ella; el empeño demostrado por fabricar productos de calidad; servicio al cliente después de realizar las ventas; en otras palabras, la forma de hacer negocios y los éxitos conseguidos al operar en forma improvisada ya no tienen ningún significado.
 
Sin mencionar los efectos que puedan tener sobre la empresa posibles eventos exógenos tales como: una elevada y sostenida tasa de inflación; cambios tecnológicos que conviertan en obsoletos la planta y el equipo existente, recesión, aumento en las tasas de salarios, cambios en la legislación que afecten a la empresa, entre otros.
 
Evidentemente, la mayoría de las empresas en el país no están preparadas para soportar tales inclemencias en su entorno económico. En adición a estos factores, es probable llegar a sufrir algunos de los síntomas inherentes a la globalización como son: competir en precios, competir en costos, competir en servicios, manejar líneas de productos más complejas o intensificar la actividad comercial.
 
El hecho de reaccionar ante estos indicadores es inminente, de no hacerlo, las empresas nacionales estarán condenadas a la quiebra, es necesario adoptar medidas efectivas y cuanto antes mejor.

 

 

Tags:

Gestión de Proyectos

La Calidad y las PyMes de la Industria del Software

por Patricia Scalzone  12. marzo 2008
En la economía mundial se observan claras tendencias hacia la internacionalización de los negocios y los mercados de capitales, la liberación del comercio, el intercambio entre grandes bloques regionales y cierto desplazamiento del centro del comercio mundial desde el Océano Atlántico hacia el Pacífico (Bozzo, 2001).
 
El papel de las Pequeñas y Medianas Empresas (PyMEs) en la estructura industrial deja paulatinamente de ser cualitativa y cuantitativamente marginal, para conformar una parte integrada y no simplemente alternativa de organizaciones productivas. El mercado Argentino no está exento a estas consideraciones.
 
En particular la industria del software, y especialmente luego de los cambios económicos sufridos a partir del año 2001, se ha convertido en una actividad económica de suma importancia para la economía del país, como para el resto de los países latinoamericanos.
 
Por otra parte, las pequeñas y medianas empresas desarrolladoras de software sufren un cambio de paradigma importante, producto de la maduración de este mercado emergente, y es que ya no basta con aplicar bien la tecnología, o aplicar la tecnología de última generación para obtener un buen producto software. Uno de los desafíos para no sucumbir, es buscar e implementar nuevas estrategias sobre la base del trabajo con mayor eficiencia (Bozzo, 2001).
 
En este mercado esto se traduce con procesos de calidad. La única forma que tiene una Pyme de desarrollo de Software de mejorar su eficiencia y ser más productiva, alcanzando los niveles de calidad exigidos por el comercio exterior, es introducir un modelo de calidad, que se ajuste a las necesidades de la organización.
No obstante, las PyMEs de este sector productivo poseen una serie de ventajas y algunas desventajas, debido a sus características estructurales.
 
Entre las ventajas de las PyMEs más significativas, se puede señalar:
 
  1. Posibilidad de flexibilidad y reaccionar con rapidez frente a los cambios.
  2. Mayor poder de innovación.
  3. Menores costos de infraestructura.
  4. Concentración en la toma de decisiones.
  5. Puntos de ventas cercanos al consumidor.
  6. Atención más personalizada.
 
Entre las desventajas de las PyMEs más destacadas, se puede señalar:
 
  1. Pocas facilidades de financiación.
  2. Problemas para planear su crecimiento.
  3. Falta de gerenciamiento profesional.
  4. Dificultades para exportar.
  5. Fuerte individualismo que le impide efectuar distintos tipos de asociaciones.
  6. Fuertes lazos afectivos con su pasado.
  7. Sistemas de información, administración y contabilidad deficientes.
 
Dentro de este contexto, es necesario aplicar un modelo de procesos que asegure obtener los niveles de calidad requeridos por el mercado para ser eficiente, pero que por otro lado no resulte excesivamente burocrático, que se convierta en gigantesco e inflexible, o que termine resultando muy costoso y desmotivador para el equipo de desarrollo.
 
En la actualidad existen varios modelos de proceso apropiados para aplicar en el desarrollo de software. Entre los más utilizados y reconocidos por el mercado, se encuentra el conjunto de Normas ISO, para certificación de Calidad tales como ISO/IEC 15504-2, ISO 90003, ISO 9001:2000, y el Modelo CMMI (Capability Maturity Model Integration)  (Software Engineering Institute, 2002), que mide la madurez de las organizaciones y ha sido creado especialmente para el desarrollo de software.
 
Estos modelos han sido pensados para la mejora de la calidad en organizaciones grandes, por lo tanto, la implementación en pequeñas y medianas empresas resulta dificultosa, compleja y de un costo económico significativo. Es por ello que han surgido diversas experiencias de crear modelos de proceso adecuados a las PyMEs, como son los casos de Brasil, con el Modelo "MR mps" de Brasil  (Weber, y otros, 2004), México con el Modelo MoProSoft, Modelo de Procesos y Evaluación para Desarrollo y Mantenimiento de Software  (Oktaba, y otros, Agosto 2005), y el modelo SPICE: Software Process Improvement and Capability dEtermination, ISO 15504  (ISO/IEC, 2003).
 
El modelo MoProSoft, ha sido elaborado por la Universidad Autónoma de México y aprobado en el marco del Programa para el Desarrollo de la Industria de Software (ProSoft) de la Secretaría de Economía, como Norma de Certificación de Calidad de software para la industria mexicana de software (NMX-I-059/01-NYCE-2005 TECNOLOGÍA DE LA INFORMACIÓN - SOFTWARE - MODELOS DE PROCESOS Y EVALUACIÓN PARA DESARROLLO Y MANTENIMIENTO DE SOFTWARE), creado especialmente para el desarrollo de software por Pequeñas y Medianas Empresas.
 
MoProSoft, que en estas latitudes se conoce como CompetiSoft, se propone como un modelo sencillo de entender y de aplicar en las empresas pequeñas, que les permita mejorar su forma de trabajar y obtener niveles de competitividad internacionales en relativamente corto tiempo y a bajo costo.
 
En su estructura define diferentes niveles de capacidad, de forma similar a lo que hace CMMI, con un orden específico para la implementación de las prácticas de los procesos partiendo de prácticas básicas, e incorporando prácticas más complejas que se corresponden con los niveles más avanzados.
 
Por otra parte, una dificultad con la que se encuentran a menudo las empresas de desarrollo de software es la selección y utilización de herramientas apropiadas para el gerenciamiento de proyectos que a su vez permita la visibilidad de todo el desarrollo, incluyendo la definición de tareas y responsabilidades por rol en el equipo de trabajo, hasta la generación de código correspondiente al producto requerido.
 
Generalmente, las empresas cuentan e incorporan a la organización, una diversidad de herramientas que se encuentran disponibles en el mercado, para cumplir con las diferentes actividades. Este conjunto de herramientas, habitualmente permanecen desvinculadas entre sí, generando dificultades para gestionarlas, mantenerlas y controlar el versionamiento de los productos que se desarrollan, no teniendo la información disponible exacta acerca de los elementos del desarrollo, se encuentren o no documentados. Como resultado, se cuenta con distintas fuentes o repositorios no integrados, que hace costosa y menos confiable la obtención de información para el control gerencial de los proyectos.
 
En Marzo del 2006 Microsoft Corporation lanzó al mercado Visual Studio Team System (VSTS), un conjunto integral de herramientas diseñadas para permitir la comunicación desde dos perspectivas: por una parte, entre los miembros de un equipo de desarrollo, y por otra parte, entre los miembros del equipo de desarrollo y los interesados o clientes, en tiempo real (Levinson & Nelson, 2006), facilitando una administración legítima del proyecto integrada con el desarrollo, sin tener que recurrir a herramientas extras.
 
El Visual Studio Team System viene provisto de dos metodologías de desarrollo, basadas en el metamodelo denominado Microsoft Solution Framework (MSF), que es un marco de trabajo descriptivo con modelos y disciplinas a seguir. Las metodologías propuestas por el fabricante no son más que guías de procesos de desarrollo prescriptivas, una pensada más liviana que es MSF para Desarrollo de aplicaciones Ágiles, y otra más formal y rigurosa que es MSF para Proceso de Mejora Continua con CMMI.
 
No obstante los modelos provistos por la herramienta, la misma cuenta con la capacidad de personalizar la totalidad del Modelo de Proceso a las características propias del modelo de cualquier organización. De esta manera, permite conformar una plantilla de proceso genérica que cuenta con todos los elementos necesarios, cada vez que la misma es seleccionada al iniciar un proyecto.
 
Como resultado, podría haber tantas plantillas de procesos diferentes como proyectos tuviera una organización, ya sea de Modelos Agiles como de Modelos tradicionales.
 
Cada uno de estas metodologías, dentro de este conjunto de herramientas, cuenta con una Guía de Procesos, que sirve de consulta permanente para todos los miembros del equipo de proyecto, y puede personalizarse acorde al proceso seleccionado.
 

 

 

Tags: , ,

ALM | Gestión de Proyectos | Metodologías y Procesos

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML