3.19 hallazgos sobre el producto en estado...
TRANSCRIPT
Preparó: Ismael Castañeda Fuentes Pág. 66
persona que no asista a la presentación en público del producto en estado Alfa, tiene cero
como calificación.
3.19 Hallazgos sobre el producto en estado Alfa Las actividades siguientes a la presentación del producto en estado Alfa, deben estar
planificadas por cada una de las Empresas Tipo N, de acuerdo con los planes de gestión,
las líneas base y sobre todo con el Plan para la Dirección del Proyecto.
Los usuarios que van a probar el producto en estado Alfa deben tener en cuenta que el
producto en estado Alfa puede ser inseguro; puede presentar inestabilidades; puede
tener alguna funcionalidad o simplemente se puede “navegar” para tener una idea de
cómo es el producto según la maqueta elaborada; es posible que no presente todas las
características previstas en los requerimientos del producto; es posible que tenga errores.
Por lo anterior, es que las personas que van a probar el producto en estado Alfa, son
personas muy cercanas al proyecto, en general son únicamente personas que pertenecen
al equipo del proyecto.
Desde el punto de vista académico, cada estudiante tiene que reportar como mínimo diez
(10) hallazgos utilizando la herramienta de software definida para el reporte de hallazgos
en la Empresa tipo N a la que pertenece y sobre el producto en estado Alfa que su
Empresa presenta. Se esperan hallazgos reportando funcionalidades que no se deben
incluir, funcionalidades faltantes según los requerimientos, errores, inestabilidades, fallas
de seguridad, fallas de acceso, fallas de integridad, mejoras, sugerencias, cambios.
Todos los hallazgos reportados en cada Empresa tipo N por los probadores, tienen que ser
atendidos, siguiendo el proceso definido para Control de Cambios.
Los cambios aprobados tienen que verse reflejados cuando se tenga el producto en estado
Beta y en la versión liberada.
3.20 Software en estado Beta En una Fábrica de Software generalmente después del producto haber pasado por el o los
estados Alfa, típicamente pasa a una fase que se denomina la fase Beta.
El producto en estado Beta generalmente es la primera versión completa del producto; es
una versión del software en donde se presentan mejoras con respecto del estado Alfa;
usualmente ya tiene todas las características pedidas en los requerimientos; es funcional;
sin embargo no está totalmente libre de fallas; puede tener ciertos errores; es posible que
presente algunas inestabilidades pero es una versión útil que la pueden usar los posibles
usuarios bajo la advertencia de que se trata de una versión Beta; puede ser útil para
Gerencia de Proyectos de Software – Notas de clase Pág. 67
demostraciones a cierto grupo de clientes; pero tal vez la característica principal es que se
trata de una versión que está en prueba.
A las personas que prueban el producto en estado Beta se les conoce con el nombre
genérico de betatester y se espera que ellos reporten todos los hallazgos que le
encuentren al producto, para que los equipos de trabajo los reciban, los analicen y si es
del caso procedan con las medidas necesarias para hacer las modificaciones que se
consideren pertinentes.
En el caso del ejercicio académico, cada Empresa tipo N tiene que definir los entregables
que se deben tener al final de la fase Beta; tienen que definir qué se espera del producto
en estado Beta y tener preparada una planeación para las tareas siguientes a la
presentación del Producto en estado Beta. Cuando se haga la presentación del Producto
en estado Beta, tiene que estar en ambiente de producción, es decir, no se recibe en
ambiente de desarrollo; se tiene que poder acceder por Internet; el producto en estado
Beta tiene que estar disponible durante las veinticuatro horas del día (24h/d) por lo
menos ocho (8) días contados a partir del momento de su presentación para dar
cumplimiento al cuarto hito del curso; los betatester son todos los Estudiantes del curso,
el Profesor, los evaluadores y los calificadores.
La Empresa tipo E tiene que prepararse para ver si el Producto en estado Beta cumple con
los objetivos que se fijó cada una de las Empresas tipo N; si el producto en estado Beta
está de acuerdo con lo diseñado; si se han tenido en cuenta las características deseadas; si
cumplen con los requerimientos; si se han hecho las pruebas suficientes para
aseguramiento de la calidad; si han avanzado en la elaboración de los manuales que van a
acompañar el Producto; si se ha puesto en práctica la metodología seleccionada para el
desarrollo del Producto; si se han cumplido las políticas establecidas para el desarrollo del
proyecto; si se han cumplido las políticas definidas para las pruebas, el control de
cambios, el versionamiento del producto, instalación y despliegue del producto en
ambiente de producción; definidas las actividades que el equipo de cada Empresa N tiene
que realizar con respecto al Producto en estado Beta una vez presentado; si se han
cumplido las políticas de seguridad, en especial las que tienen que ver con las garantías de
amplio acceso para los evaluadores y calificadores, desde luego, todo lo anterior dentro
del marco establecido en el Plan para la Dirección del Proyecto.
3.21 Cuarta reunión para Control Ocho días antes de la presentación en público del Producto en estado Beta, la Empresa
tipo E se reúne con cada una de las Empresas tipo N con el fin de hacer seguimiento y
control de las actividades para cumplir con éxito el cuarto hito del curso, el cual consiste
Preparó: Ismael Castañeda Fuentes Pág. 68
en que cada Empresa Tipo N presenta su Producto en estado Beta; realiza una
presentación en público del trabajo realizado para llegar a este punto del Proyecto y
muestra el producto funcionando en estado Beta en ambiente de producción.
La cuarta reunión para control se hace en una sesión de clase, según el calendario del
curso, previa una determinación de hora y duración de la reunión. La Empresa tipo E hace
la agenda, preside la reunión, desarrolla la reunión y se encarga de las actas, excepto que
el acta con una o varias de las Empresas tipo N, durante la reunión, se designe de su
elaboración a otra persona.
La Empresa tipo E, tiene como insumos los informes semanales de las diferentes Empresas
tipo N. Con ellos, entre otras actividades, se recomienda que observen la planificación de
tareas, a nivel de cada persona, de equipo de trabajo y del proyecto; su cumplimiento; su
organización, y ojalá el equilibrio de tareas, esfuerzos y responsabilidades de los
participantes. También observar las desviaciones que se presenten de lo ejecutado con
respecto de lo planeado; se sugieran soluciones; se den recomendaciones; se miren los
riesgos y se haga un pronóstico.
Se debe insistir en que el producto en estado Beta se tiene que presentar en ambiente de
producción; accesible por Internet para todos estudiantes del curso, al Profesor, a los
evaluadores y calificadores; disponible por lo menos durante ocho (8) días, las veinticuatro
(24) horas del día, contados a partir del día de la presentación en público. Esto quiere
decir, que por ningún motivo se va a aceptar el producto en ambiente de desarrollo y
tampoco se acepta que esté disponible solo por espacios de tiempo. Para los evaluadores,
deben garantizar acceso amplio y suficiente para que puedan evaluar y calificar. También
se debe insistir en la importancia de registrar todos los datos para que se puedan
fácilmente presentar los indicadores de cada persona, del equipo y del proyecto.
De especial importancia, es que los temas tratados y los acuerdos queden registrados y
consolidados en el acta de la reunión.
Se siguiere que la Empresa tipo E, tenga preparado un formato de acta de la reunión, de
tal forma que su llenado sea rápido, ágil y práctico. Que antes de finalizar la reunión
quede protocolizada el Acta de la reunión y lista para su publicación, aprovechando las
facilidades tecnológicas que hoy existen, como el escaneo de documentos y
comunicaciones a través de Internet utilizando dispositivos móviles.
Terminadas las reuniones de Control con cada una de las Empresas tipo N, la Empresa
Tipo E, presenta un informe al Profesor de lo sucedido. El Profesor con base en ese
informe coloca una calificación. La persona que no asista, tiene cero como calificación.
Gerencia de Proyectos de Software – Notas de clase Pág. 69
3.22 Actividades antes de la presentación del producto en estado
Beta El día anterior a la Presentación del producto en estado Alfa, cada Empresa Tipo N, antes
del mediodía tiene que entregar al Profesor, en físico (CD, DVD, USB) el “Cuarto
Congelado” de lo trabajado por ellos. El Profesor registra la entrega del “Cuarto
Congelado”, lo hace llegar a la Empresa Tipo E para que ellos lo utilicen como una de las
entradas para evaluar las Empresas Tipo N. Con esto se busca que las tareas se elaboren
con antelación, la presentación del producto en estado Beta esté muy bien preparada y no
improvisada; adicionalmente facilita el trabajo de los evaluadores, que van a tener
información antes de la Presentación y cuentan con mayor tiempo para revisar
cuidadosamente el “Cuarto Congelado”.
El “Cuarto Congelado” tiene que contener todo el trabajo adelantado hasta este momento
por cada una de las Empresas tipo N. Desde el punto de vista académico, es el sitio donde
debe estar absolutamente todo lo trabajado por las personas en el desarrollo del Proyecto
por cada una de las Empresas tipo N, incluido el código fuente de los programas. La razón
principal para exigir lo anterior, es para poder evaluar y calificar el trabajo adelantado. Lo
que no se vea clara y objetivamente, no se califica. Otra razón para exigir el “Cuarto
Congelado”, es para compararlo con lo presentado del Producto es estado Alfa, hacer
seguimiento, poder controlar, poder medir los avances reales del Proyecto y para ver los
aciertos y equivocaciones en la gerencia, dirección y gestión del Proyecto.
En el “Cuarto Congelado” se tienen que encontrar las respuestas a muchos interrogantes
que posiblemente formulen los evaluadores.
Preguntas como las siguientes: ¿Cómo se planificó? ¿Se ejecutó lo que se planificó? ¿Se ha
hecho un registro cuidadoso de las tareas realizadas? ¿Cuáles son las desviaciones? ¿Qué
ajustes se han hecho? ¿Cómo es el comportamiento del desarrollo del producto con
respecto del alcance? ¿Con respecto del tiempo? ¿Con respecto de los costos? ¿Con
respecto de la calidad? ¿Están absolutamente seguros que eso es lo que desea el cliente?
¿Cuál es la ruta crítica? ¿Tiene suficiente holgura el proyecto en tiempo y costos? ¿Los
recursos humanos han sido suficientes? ¿Cómo se han gestionado los riesgos? ¿Qué
nuevos riesgos han aparecido? ¿Qué tanto impacto pueden tener los nuevos riesgos?
¿Cómo se ha gestionado el tema de las previsiones para atender las eventualidades?
¿Cómo han gestionado, planificado, ejecutado, controlado y cerrado las adquisiciones?
¿Cómo han gestionado a los interesados? ¿Cómo se ha gestionado lo relacionado con
conflictos? ¿Se han seguido las metodologías seleccionadas para el desarrollo del
Producto? ¿Las metodologías seleccionadas han funcionado o han tenido inconvenientes?
¿Se han seguido las normas para la construcción del software? ¿Cómo han gestionado al
Preparó: Ismael Castañeda Fuentes Pág. 70
personal técnico que desarrolla el producto? ¿Cómo se ha gestionado el aseguramiento
de la calidad? ¿Cómo se han gestionado las comunicaciones? ¿Los canales de
comunicación han funcionado o han tenido problemas? ¿Cómo se ha gestionado el
seguimiento y control al desarrollo del Producto y al Proyecto? ¿Cómo han validado las
cosas hechas con respecto del Producto y del Proyecto? ¿Lo implementado corresponde a
lo diseñado? ¿Ha sido acertada la selección de lenguajes y/o interpretadores utilizados
para hacer la programación? ¿Han cumplido con las políticas determinadas con respecto a
la calidad del Producto? ¿Han elaborado las pruebas que tenían previstas para el sistema?
¿Han utilizado los repositorios y cómo han sido sus resultados? ¿Han utilizado algún
sistema de trabajo colaborativo, qué resultados han tenido? ¿Están utilizando algún
software para la gestión de versiones del Producto? ¿Lo pusieron en práctica para sacar el
estado Beta del Producto? ¿El Proyecto va a terminar exitosamente?
3.23 Presentación en público del Producto en estado Beta El día programado para la presentación en público del Producto en estado Beta, según el
calendario del curso, cada Empresa Tipo N muestra al público el trabajo que ha
adelantado y muestra el funcionamiento del Producto en estado Beta. El auditorio son el
Profesor, la Empresa tipo E y las demás Empresas Tipo N. La hora y duración máxima de
cada presentación se establecen con anterioridad dentro de una sesión de clase. La
Empresa tipo E hace la agenda, preside la reunión y adelanta la evaluación y calificación.
El contenido y dinámica de la presentación en público del Producto en estado Beta, el(los)
presentador(res), la consecución de las ayudas audiovisuales, las herramientas que
utilicen y demás cosas que necesiten y quieran utilizar, son responsabilidad y de libre
albedrío de cada Empresa tipo N. Es importante tener un plan básico, por si todo resulta
como se planifica, y uno o varios planes alternativos, en caso de alguna contingencia.
Se sugiere que la presentación se haga con ayuda de una herramienta informática y un
retroproyector. Pero también se puede utilizar el tablero, el papelógrafo, marcadores,
diapositivas y carteleras. Todo lo anterior acompañando a la presentación en línea del
producto en estado Beta.
La Presentación en público del Producto en estado Beta; la comprobación de la existencia
del sitio Web actualizado; de la existencia y acceso del producto en estado Beta; y de la
evaluación del contenido de todo el “Cuarto Congelado”, la Empresa tipo E presenta al
Profesor un informe. El Profesor con base en ese informe coloca una calificación. La
calificación puede ser grupal o individual, esto último cuando se vean grandes diferencias
de trabajo por parte de los miembros del Equipo de cada una de las Empresas Tipo N. La
Gerencia de Proyectos de Software – Notas de clase Pág. 71
persona que no asista a la presentación en público del producto en estado Beta, tiene
cero como calificación.
3.24 Hallazgos sobre el producto en estado Beta Las actividades siguientes a la presentación del producto en estado Beta, deben estar
planificadas por cada una de las Empresas Tipo N, de acuerdo con los planes de gestión,
las líneas base y sobre todo con el Plan para la Dirección del Proyecto.
Los betatester van a ser los Estudiantes del curso, el Profesor, los evaluadores y los
calificadores, los cuales van a probar el producto en estado Beta.
Desde el punto de vista académico, los betatester tienen que reportar como mínimo cinco
(5) hallazgos por cada Producto probado en estado Beta, es decir, si en el curso hay dos (2)
Empresas tipo N, se deben tener dos (2) Productos en estado Beta; entonces un
estudiante tiene que reportar como mínimo cinco (5) hallazgos a cada Empresa tipo N, o
sea un total de mínimo diez (10) hallazgos. Los hallazgos se tienen que presentar
utilizando la herramienta de software para el reporte de hallazgos que cada Empresa tipo
N esté utilizando. Por lo tanto, cada Empresa tipo N, tiene que tener en cuenta esta
situación y dar acceso a la herramienta para reporte de hallazgos a todos los betatester
(personas que posiblemente no hacen parte de su equipo, sino usuarios seleccionados
que van a reportar hallazgos). Se esperan hallazgos reportando funcionalidades que no se
deben incluir, funcionalidades faltantes según los requerimientos, errores, inestabilidades,
fallas de seguridad, fallas de control de acceso, fallas de integridad, mejoras, sugerencias,
cambios.
Todos los hallazgos reportados por los betatester a cada Empresa tipo N, tienen que ser
atendidos, siguiendo el proceso definido para Control de Cambios.
Los cambios aprobados tienen que verse reflejados cuando se tenga el producto en la
versión liberada.
3.25 Producto de software liberado En una Fábrica de Software generalmente después del producto haber pasado por el o los
estados Beta, típicamente pasa a una fase que termina con la presentación del producto
de software liberado, que en el caso del ejercicio académico, corresponde al producto del
Proyecto que soluciona el problema del cliente.
El Producto liberado tiene que presentar todas las características pedidas en los
requerimientos; tiene que ser funcional; tiene que estar libre de fallas; no puede tener
errores; tiene que ser estable y listo para que lo pueden usar los posibles usuarios.