Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
.

Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.

 

Artículos
 

¿Cuál es la contribución a la empresa y en qué le sirve a un administrador de proyecto?
Fase de evaluación de un proyecto de software–Mucho más que evaluación

Por Michael Szwarc [ Acerca del autor]

En este artículo se describirán algunos de los beneficios de la fase de evaluación de un proyecto de desarrollo de software, y cómo asegurar que la empresa y el administrador de proyecto puedan crecer.

Definición de la Fase de Evaluación

Es muy difícil definir "fase de evaluación". Para ilustrar la idea de este artículo, la fase de evaluación se referirá a la fase en la cual las evaluaciones exhaustivas comienzan a ser realizadas en los productos de desarrollo (generalmente por evaluadores designados). Para objetivos de discusión, la evaluación exhaustiva comienza desde las etapas de integración y hasta la prueba de sistema. Muchos refieren a esta etapa como la “Etapa QA” (Quality Assurance o Aseguramiento de la Calidad), a causa de la complejidad del concepto “QA” y la descripción enorme, este artículo se adherirá al concepto “fase de evaluación”.

Objetivos de la Fase de Evaluación

Antes de que estudiemos el aporte de la fase de evaluación al proyecto, es importante entender los objetivos declarados en esta fase. Las respuestas aceptadas de estas interrogantes son las siguientes:

  • Permitir que las partes interesadas en el producto reciban una medición de su calidad y cumplimiento de sus requerimientos.
  • Demostrar que el software hace lo que se supone debe hacer (Definición problemática y parcial).
  • Encontrar las brechas o entre lo que se supone que debe hacer o no el software y lo que realmente hace o no (definición completa más ligera).

Esto es efectivamente el propósito principal de la fase de evaluación – una fase importante y crítica para el éxito del proyecto.

Sin embargo, ¿esto es el objetivo exclusivo?. ¿Es el trabajo de los evaluadores catalogados de este modo?. En la mayoría de los casos la respuesta es positiva sin mucha vacilación, ya que la tarea de ellos está enfocada a marcar una “V” la calidad del producto como es percibido por muchos, lo que resulta en la carencia de la atención administrativa.

La mayor parte de los focos en el proyecto, al igual que el entusiasmo administrativo, está en la etapa de desarrollo (en su sentido tradicional: el mundo de los desarrolladores de software).

En vista de esto, los administradores tienden a poner menos énfasis en la planeación de la fase de evaluación en las etapas de planificación del proyecto y se presta mucha mayor atención a esta etapa (y tienen razón, así es). Pero en realidad este estímulo demuestra que no es trivial. De lo contrario no sería necesario.

Muchos de los project managers recuerdan la fase de evaluación sólo en el último minuto. Pocos se involucran e integran a ésta en las etapas de planificación y únicamente los “meticulosos” hacen alusión a la planeación de la evaluación como una parte integral de la planeación del proyecto por sí misma.

Funciones adicionales de la "Fase de Evaluación"

La experiencia en campo muestra que la actitud simplista en la fase de evaluación reduce su aporte al proyecto. La fase de evaluación oculta mucho valor para el administrador del proyecto y la empresa en general:

a. Primero y muy importante, y en concordancia con el objetivo declarado, la fase de evaluación otorga una visión de calidad del producto del proyecto. Ésta es la clásica y obvia contribución de los managers implicados. Ya después de la rotación de la primera evaluación, los sentimientos viscerales de aquellos involucrados comienzan a desaparecer y a transformarse basados en evaluaciones más científicas. Hay un reporte de estado que comienza a hacerse más claro por primera vez, permitiendo al project manager un suspiro de alivio (incluso un poco) para primera vez o bien comenzar a preocuparse (pero esta vez fuera del conocimiento…).

b. Al principio de la etapa de redacción del plan de evaluación (antes del comienzo de la evaluación): muchos problemas aparecen en los documentos de diseño: ambigüedad, manejo de casos extremos, imprecisión y otros. Esto resulta en una gran precaución, puntualidad y meticulosidad que caracteriza el personal de pruebas. Su entrenamiento y personalidades son las que los empujan a realizar preguntas (a diferencia de la gente de desarrollo quienes tienen una tendencia mayor de interpretar de manera subjetiva). Por lo general el costo de encontrar estos problemas en una etapa posterior es mucho mayor.

Ejemplo: En un proyecto el cual fue planeado para tomar tres meses (dos semanas de diseño, un mes para el desarrollo, dos semanas para la evaluación y una semana de instalación), la redacción del plan de evaluación fue demorada una semana antes del inicio de la evaluación. Durante la escritura de éste (por el estudio de muchos casos extremos) el evaluador se avalancha con un número de preguntas relacionadas a las temas que no quedaron claros en el diseño. Estas preguntas motivan un cambio básico en el diseño y consecuentemente en el desarrollo. El resultado fue de dos semanas de retraso total en el proyecto. Además del evaluador, nadie prestó atención a estos incidentes tempranos.

c. La transferencia del estado de desarrollo a la fase de evaluación se caracteriza normalmente vinculando las diferentes terminaciones de los productos del proyecto. En muchos casos unos pocos desarrolladores trabajan en un número de partes diferentes del software. A veces una etapa en sí misma es dedicada a la evaluación de la integración. A veces la fase de evaluación constituye la primera oportunidad para ver todos los componentes diferentes trabajando juntos. Este es el momento en el cual las “excavadoras de túneles” de ambos lados se encuentran. A veces únicamente en esta etapa convergen los últimos detalles finalizados de las interfaces y la configuración específica.

Ejemplo: En un proyecto para un cliente determinado, una configuración de un sistema específico fue requerida, por lo cual se definieron algunos parámetros diferentes. Durante el desarrollo el software, éste fue revisado con una variedad de parámetros sin ninguna conexión con las especificaciones del cliente. Durante las pruebas, los evaluadores también insistieron en revisar las demandas específicas del cliente y las evaluaciones revelaron contradicciones funcionales precisamente en estos casos.

d. Continuando con el párrafo anterior al ejemplo, la fase de evaluación comienza desde la instalación (no necesariamente el primero pero sí el más importante) del software y/o del producto. Esta es la primera vez que el producto en sí pasa las manos (y no sólo documentos). Hay dos transferencias que son las siguientes:

1) Tecnológica: La transferencia de un ambiente (desarrollo) a otro ambiente (pruebas). Es posible referirse a esta operación como el primer ensayo para la instalación operacional y para examinar la calidad del proceso de instalación en sí mismo.

Ejemplo: En un proyecto, la instalación del producto en la transferencia de la fase de desarrollo a la evaluación duró aproximadamente dos días. El plan de instalación operacional tuvo un plazo de tiempo de sólo 6 horas. Como consecuencia de la instalación ampliada, la empresa estuvo forzada a asignar otra semana para reducir el tiempo de instalación. El proyecto demoró otra semana pero una sorpresa desafortunada fue evitada durante la noche de la instalación operacional.

2) Transferencia de conocimiento: El producto es más que su tecnología. El producto combina procesos, interfaz de usuario, terminología y más. En un mundo utópico los evaluadores no necesitan el producto para familiarizarse con éste (ellos ya están implicados en la fase de diseño). En la práctica esto no sucede. La fase de pruebas tiene que comenzar con la capacitación apropiada del personal de pruebas. Esta formación es el fundamento inicial para el material de entrenamiento del producto. Por lo tanto, la transferencia de conocimiento constituye la primera indicación del proceso de entrenamiento y la asimilación requerida.

Ejemplo: Un proyecto que consistió en muchas interfaces de usuario, el programa de adiestramiento estaba enormemente basado en datos y conclusiones que fueron reportadas por los evaluadores (basados en su experiencia personal).

e. La fase de pruebas no es una fase consecutiva y homogénea. Por naturaleza es una etapa cíclica conducida en rotaciones (sin relación con la metodología de la completa administración de proyectos). Los jugadores importantes participan en estas rotaciones: gerentes de producto, equipo de desarrollo y el project manager. La tensión organizacional creada entre el evaluador y el evaluado, la necesidad de tomar muchas pequeñas decisiones (a veces también son grandes) en ocasiones generan la formación de algunas comunicaciones inter-organizacionales: ¿Cuál es el defecto?, ¿Cuál es el cambio?, ¿Qué es crítico?, ¿Cuándo reparar?, ¿Sí hay que reparar?. Esta comunicación mejora el funcionamiento del equipo en otros proyectos y así contribuye a la mejora de los procesos en la empresa. Por una buena razón, las herramientas para administrar los defectos/cambios fueron las primeras en ser asimiladas en el proceso de administración del proyecto. Para mejorar las habilidades de organización y comunicación.

Ejemplo: Había una carencia de comunicación entre dos empresas que fueron socias en un proyecto de desarrollo, que incluyó un número de desarrollos y ciclos de prueba. Las etapas de diseño y desarrollo se vieron afectadas a raíz de las diferencias de entendimiento y metodología del trabajo que casi condujo a una paralización completa del proyecto en la fase de evaluación conjunta. A la luz de esto, muchos esfuerzos administrativos fueron invertidos para definir el proceso de trabajo y la comunicación, la cual está basada en métodos de trabajo acordados y tecnología de soporte. Estos procesos que fueron definidos en la fase de pruebas ayudaron al resto de los ciclos en el proyecto.

f. El proceso de pruebas incluye un formato estructurado de medición: estadísticas de defectos, porcentaje de cobertura, medidas funcionales del producto y la mayoría de sus medidas no funcionales. Al "panel de control" del administrador del proyecto se le añade inmediatamente muchos indicadores que reducen la incertidumbre y mejoran su capacidad de planificar la continuación del proyecto.

Ejemplo: En un proyecto irregular en la empresa, fueron realizadas las evaluaciones cuidadosamente, para el tiempo de pruebas (debido a las innovaciones en el proyecto: de nueva interfase y empleo de un nuevo producto de anaquel). Al principio de la fase de pruebas, el gerente de pruebas comenzó a advertir sobre una estadística de base diaria a los resultados de las pruebas: defectos y porcentajes de cobertura. El análisis de los resultados mostró el paso de las pruebas y suministró un instrumento objetivo para planificar la continuación del proyecto.

Utilización del Potencial Oculto de la Fase de Pruebas

De lo ya mencionado puede verse que el proceso de pruebas constituye un esquema importante para los gerentes. Para el administrador del proyecto esto es un instrumento central que le permite controlar el proyecto entero (y no sólo la calidad del producto). Para el resto de los gerentes es un instrumento bueno para el control de la empresa, y aún más, una oportunidad de aprender, mejorar y asimilar procesos.

La fase de pruebas indica la madurez de la empresa, la calidad de procesos de diseño, procesos de desarrollo y más. Un buen proceso de diseño no indicará un proceso inferior de prueba, pero sí lo contrario. Desde este punto de vista los que se confunden entre los conceptos " pruebas de producto " y "aseguramiento de la calidad" (QA) tienen razón (por bondad y no a favor de). En el amplio sentido del significado, el concepto de aseguramiento de la calidad se refiere a todos los procesos de la empresa y no sólo a la calidad del producto. Y el argumento es que la manera de examinar la calidad del producto indica la calidad de los procesos de empresa.

La conclusión obvia es dedicar mucha más atención a la fase de pruebas y proveer el ambiente necesario para asegurar su ejecución de una forma correcta y apropiada –para ser precisos con la sincronización correcta: aclaratoria de los contenidos que están siendo evaluados, congelando el código, interés por el ambiente de pruebas apropiado y conveniente y la aprobación de todos los socios en el proyecto sobre el plan de pruebas.

Además, el project manager debería involucrar activamente a los evaluadores en todas las fases, e incluso administrar el hito del inicio de pruebas. De ser posible, es recomendable comenzar a probar ciclos tan temprano como sea (aunque haya muchas desventajas en un inicio temprano, es necesario saber cómo administrarlos). La cooperación entre el jefe del proyecto y el gerente de pruebas es crítica.

Al nivel de empresa, la importancia debe ser aplicada al personal encargado de las pruebas (y en especial sus directivos) con el fin de maximizar el potencial de la contribución global a la compañía más allá de la calidad del producto en sí.

Por último, hay casos en los cuales es correcto usar metodologías del mundo de pruebas en otros procesos de la empresa como puede ser el uso de las mediciones. Un ejemplo extremo incluye la etapa de desarrollo en la fase de pruebas para forzar una estructura “ágil” en el proyecto si es requerida (sobre todo si la empresa no es experta en esto).

Ejemplo: En un proyecto de cuatro meses y debido a las condiciones de certeza (presión del tiempo y características del cliente) fue conocido de antemano que habrían cambios en los requerimientos durante el desarrollo. La empresa decidió iniciar los ciclos de pruebas en una etapa más temprana. Todos los mecanismos de revisión de defectos en alta frecuencia y versiones administración de desarrollo acordadamente sirvieron como puntos de modificación en el diseño. En estas frecuencias encontradas (una vez cada dos días, en un formato corto) todas las partes interesadas estuvieron presentes: los diseñadores, desarrolladores, evaluadores y el administrador del proyecto. El proyecto recibió un tipo de administración ágil natural y familiar sin ninguna necesidad de capacitación específica. Esta decisión aseguró el éxito del proyecto.

Resumen

La fase de pruebas de un proyecto tiene un objetivo principal, importante y bien conocido pero más allá de esto, constituye una amplia gama de oportunidades para mejorar los procesos en la empresa y ocultar dentro del alto valor para el project manager. Las conciencias de este potencial en la etapa inicial y sus usos pueden servir como un elemento estratégico que asegure el éxito de los proyectos y como una fuerza conductora para estudios de grandes periodos y desarrollo.


Esta página ha sido calificada como:
Califica esta página:   

Temas relacionados:
Certificación PMP® en Administración de Proyectos
Curso breve intensivo de certificación en administración de proyectos para principiantes (CAPM®)

+





Gestión y actualización de los riesgos del proyecto
(Julio Matus)
+
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.