Entradas etiquetadas como Proceso Definido

Plantillas: Cierre de Iteración

Si el Plan de Iteración es la planificación de un periodo corto de tiempo dentro del proyecto, entonces el Cierre de Iteración es el informe del cumplimiento de dicho plan.

El documento de cierre de iteración es una presentación de las actividades realizadas, los recursos dedicados, los hitos, los riesgos concretados, así como cualquier otro evento o información de la que queramos dejar constancia.

He de comentar que el Cierre de Iteración que presento aquí tiene una característica adicional: el control de evaluación de los artefactos. La idea es que en el Plan de Aseguramiento de Calidad se indiquen los criterios que deben ser evaluados en cada artefacto, para que luego entre el Plan de Iteración y el Cierre de Iteración se siga la pista de la evolución de estas calificaciones.

Es una característica un poco engorrosa, pero si se cuenta con recursos para mantener un equipo de control de calidad entonces se va a poder llevar a cabo este control, con miras a mejorar la ejecución del proyecto en su conjunto.

En cualquier caso, acá esta la plantilla del artefacto Cierre de Iteración:

Cierre de Iteración (en PDF)

Cierre de Iteración (en iScribd)

Anuncios

, , , , , , , , , , ,

3 comentarios

¿Qué son las llamadas Mejores Prácticas?

Las mejores prácticas son características reconocibles de los procesos de las organizaciones de éxito. Suelen ser conductas observables, llenas de sentido común; que al estar presentes en las mejores empresas de cada sector, se piensa que son parte del éxito de dichas empresas. Por supuesto, se piensa también que de asumirse, toda empresa se puede beneficiar, por lo que la predica en pos de las mejores prácticas es parte importante de la planificación a largo plazo de las organizaciones que desean mejorar y crecer.

A nivel personal, podemos establecer un símil con los consejos más comunes sobre como llevar una vida sana y exitosa. Consejos tales como “pensar antes de actual” o bien el elemental “dormir lo suficiente cada noche” son el equivalente de las mejores prácticas, aplicadas a como conducir la propia vida.

En el caso de las empresas, se confía en los institutos de investigación de cada sector, quienes identifican sistemáticamente las prácticas en uso, con el objetivo de publicar catálogos de mejores prácticas, que sean apropiadas para el sector industrial que se este considerando. Dichos catálogos suelen ser de acceso libre y son conocidos bajo diferentes denominaciones, como si se estuviera hablando de cosas diferentes en cada sector. Pero no hay confusión que valga: para todo sector valen distintas mejores prácticas, pero llámense como se quieran llamar, todas son mejores prácticas y poco más.

Cuando se esta diseñando un proceso empresarial, es útil considerar las mejores prácticas conocidas del sector o actividad en la que el proceso vive. Dado que existen gran cantidad de sectores, el analista de procesos puede beneficiarse de conocer que se considera como una buena idea, dando entonces una base sistemática para identificar objetivos de diseño para los procesos, más allá de cubrir las necesidades inmediatas demandadas por los clientes.

He de hacer notar también, que muchas de las mejores prácticas pueden ser apoyadas por sistemas de información apropiados; o dicho de otra forma, que hoy en día existen gran cantidad de sistemas de información, muchos de ellos construidos para dar cumplimiento a una o más de las mejores prácticas de sector destino del sistema.

Así que el asunto de las prácticas conviene tenerlo en mente.

, , , , , , , ,

Deja un comentario

Plantillas: Plan de Iteración

El Plan de Iteración recoge la planificación detallada de un periodo corto de tiempo dentro del proyecto – una iteración. Entre otras cosas, debe identificar las actividades, los riesgos involucrados, los artefactos a actualizar o crear, las necesidades de adquisición de bienes o servicios y los hitos esperados durante la iteración.

Adicionalmente, esta plantilla contiene los rudimentos para la evaluación regular y controlada de la calidad de los productos y del proceso: las pautas de evaluación indicadas en el plan de iteración sirven para este fin. Se complementa esto con los detalles de la evaluación contenidos en el artefacto de Cierre de Iteración.

El documento es una variación de la plantilla de reportes, por lo cual no contiene número de versión y se identifica solo por la fecha de emisión.

Finalmente, he aquí la plantilla:

Plan de Iteración(en PDF)

Plan de Iteración(en Scribd)

, , , , , , , , , , ,

2 comentarios

Prácticas: Gestión de Proveedores

Dado que en un esfuerzo de desarrollo no todo puede ser resuelto con los recursos propios, es probable que nos encontremos en la posición de tener que adquirir insumos, servicios y productos a terceros; por lo cual, es necesario extender a estos proveedores todo lo que podamos en cuanto a control de calidad y buenas prácticas pues de lo contrario estaríamos comprometiendo nuestra propia capacidad de asegurar el nivel de calidad requerido por nuestros clientes.

Esta práctica la llamamos Gestión de Proveedores e involucra:

  • Determinar los servicios y productos a adquirir.
  • Determinar el nivel de servicio requerido (cantidad, tiempo, precio, calidad).
  • Seleccionar los proveedores según su capacidad de cumplir con el nivel de servicio.
  • Establecer contratos de suministro y nivel de servicio con los proveedores.
  • Ejecutar la adquisición del servicio o producto.
  • Evaluar (cuando sea requerido) los productos requeridos contra el nivel de servicio solicitado.
  • Aceptar las entregas de los productos adquiridos.
  • Distribuir lo adquirido al lugar en que se necesita.

Como cabe esperar, esta práctica se relaciona con Seguimiento y Control de Proyectos y con Gestión de Requisitos. La primera por cuanto los suministros deben de llegar oportunamente (básicamente pero hay otras razones) en tanto que la segunda por cuanto lo que se ha adquirido se va a integrar en el producto final y de ahí, que sus características deban guardar relación con los requisitos impuestos al proyecto.

En esta práctica se ve que para asegurar un desarrollo eficiente los procesos de la empresa se deben estructurar correctamente mucho más allá que simplemente poner orden en el departamente técnico. En este caso, se debe implantar algún sistema de gestión de requisiciones que permita centralizar las compras en un departamento que pueda hacer el seguimiento a los proveedores, desde su selección pasando por su contratación hasta la ejecución del servicio.

, , , , , , , ,

Deja un comentario

Prácticas: Medición y Análisis

El propósito de la práctica conocida como Medición y Análisis, es desarrollar la capacidad de la organización para reunir información objetiva (medición) con el fin de dar soporte a la dirección y gerencia.

De acuerdo con CMMi, esta capacidad de medición involucra lo siguiente:

  • Especificar los objetivos de medición y análisis tales que sean necesarios para dar soporte a las metas y necesidades de la organización.
  • Especificar las magnitudes, las técnicas de análisis y los medios para la recolección, y manipulación de las mediciones.
  • Implementar los procedimientos necesarios para la recolección, registro y reporte de la data relacionada con las mediciones.
  • Proveer resultados objetivos de las mediciones, tales que puedan servir de base para la toma de decisiones.

En otras palabras: proveer la infraestructura necesaria para la recolección de información estadistica cualitativa y de ser posible cuantitativa sobre los aspectos del proceso que se descubran relevantes para la toma de decisiones, así como la detección y corrección de desviaciones.

Dado su propósito amplio, la práctica de Medición y Análisis debe integrarse en forma distribuida a lo largo del proceso de desarrollo. En el caso ideal, cada actividad y tarea realizada en la organización ha de generar algún tipo de información útil que sirva para determinar su rendimiento, situación objetiva y la calidad de los resultados.

Si bien es cierto que un programa de metrica a gran escala es una propuesta ambisiosa, no es necesario tener un gran esfuerzo de recolección de metricas en el desarrollo para establecer la práctica de la que aquí hablamos. Basta con determinar en puntos clave del proceso definido que se sigue, estadisticas que sean significativas y que de ser posible, sean resultados naturales de las tareas ejecutadas.

Es decir, que contrario a lo que podría parecer, un programa bien establecido de medición no es una operación burocratica a gran escala, sino por el contrario es la reutilización inteligente de la información sobre el proceso que ya de forma natural, se este generando en la organización.

Varios ejemplos de medidas utiles me vienen a la mente:

  • Horas de esfuerzo por tarea o actividad.
  • Número de componentes diseñados o implantados.
  • Número de páginas de documentación solicitadas y redactadas.
  • Cantidad de veces que una actividad se repite.

Estas son estadisticas que ya en forma natural deberan existir en la organización, solo es cuestión de definir cuales son útiles para la gestión del proceso y establecer entonces formas de recolectar y utilizar esta data.

Finalmente, dado que con esta práctica estamos detectando desviaciones y proveyendo información útil para la gerencia, es obvio que estamos en presencia de una práctica relacionada con la Planificación de Proyectos así como con el Seguimiento y Control de Proyectos.

, , , , , ,

Deja un comentario

Plantillas: Plan de Desarrollo de Software

Técnicamente, el Plan de Desarrollo de Software es un compendio de los distintos planes que son necesarios para ejecutar un proceso de desarrollo. Es decir, que en proyectos de tamaño pequeño o mediado, este documento tendrá muchas secciones con información sobre la gestión del proceso, en tanto que en un proyecto grande, lo que tendrá será muchas referencias a todos los planes independientes que se hayan desarrollado.

Ahora bien, que dado que el documento en si mismo esta bien documentado y lleno de comentarios, considero que basta con colocar la plantilla para que se entienda su propósito. Con todo, es posible mencionar aquí que este documento es el centro de la práctica Planificación de Proyectos y junto con los planes de iteración, de la práctica Seguimiento y Control de Proyectos.

Finalmente, como ya había dicho, la plantilla del documento:

Plan de Desarrollo de Software(en PDF)

Plan de Desarrollo de Software(en iScribd)

, , , , , , ,

6 comentarios

El Ciclo de Vida: Objetivos de Fase

Cada Fase del Ciclo de Vida debe terminar cuando se alcanzan un conjunto bien identificado de objetivos, definidos en términos de productos concretos o eventos acordados con los stakeholders. Según lo que se haya indicado en la planificación del proyecto durante la Fase de Concepción.

Esto es, llamamos Objetivos del Ciclo de Vida a las metas concretas que marcan el éxito de una fase, según lo que se haya planificado inicialmente.

Según la fase del proyecto en la que nos encontremos, los objetivos van a ser diferentes. Algunos ejemplos son:

  • Objetivos del Ciclo de Vida de la Fase de Concepción: Documento Visión, Modelo de Casos de Uso, Documento de Requisitos Suplementarios.
  • Objetivos del Ciclo de Vida de la Fase de Elaboración: Documento de Arquitectura del Sistema, Prototipo de Interfaz de Usuario, Prototipo Técnico de la Arquitectura del Software.
  • Objetivos del Ciclo de Vida de la Fase de Construcción: Versión Beta del Software en ejecución en ambiente de pruebas, Documentación de Usuario, Soporte de Entrenamiento de Usuarios, etc.

Un objetivo del ciclo debe ser concreto, verificable, planificado de antemano, bien conocido y aceptado por todos los stakeholders del proyecto. Veremos cada criterio uno a uno:

Concreto: Cada objetivo del ciclo de vida debe estar bien enunciado. No se aceptar definiciones vagas o que no se comprendan plenamente por todos los stakeholders involucrados. Se tienen por concreto a los artefactos del proceso cuando estos son aprobados por el cliente y este entiende el significado y rol técnico del producto que esta aprobando.

Verificable: Tanto el cliente como el equipo de Control de Calidad del Software van a estar interesados en comprobar que el objetivo se ha alcanzado. Esto es, la ocurrencia del evento debe poder ser observada por terceros de forma así de garantizar que el éxito en alcanzar el objetivo del ciclo de vida no es resultado de una evaluación subjetiva más sujeta al capricho o la premura que a la realidad.

Planificado: El objetivo de ciclo de vida es una meta; por lo que no puede ser alcanzado solo por casualidad. El objetivo ha de haber sido señalado como meta desde un principio y no puede en ningún caso, ser presentado como aquello que se ha salvado de un proceso malogrado de desarrollo. La planificación también es importante para permitir con el suficiente tiempo, la elaboración de estrategias de evaluación que permitan la verificación del objetivo.

Bien Conocido: El objetivo del ciclo de vida debe ser un artefacto o evento reconocido en el sector de desarrollo, de forma tal que exista un acuerdo profesional sobre lo que este significa y de los eventuales criterios de aceptación y demás características del objetivo. Por ejemplo, el Documento de Visión es bien conocido ya que esta difundido en la profesión el contenido esperado de este documento así como en el propósito que persigue.

Aceptado: Todos, tanto los clientes como los desarrolladores, deben haber aceptado el objetivo del ciclo de vida y sentir compromiso por conseguirlo. El objetivo de ciclo de vida debe ser aceptado como un elemento que señala un avance significativo del proyecto que aporte valor real al desarrollo y que debe ser apoyado y buscado con energías. Esto debe ser algo sincero, ya que un objetivo del ciclo de vida no puede ser percibido como un alcabala o requisito burocrático: muy por el contrario, debe ser un artefacto o evento de valor para todos los involucrados.

, , ,

1 comentario