3.24 hallazgos sobre el producto en estado...

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

Upload: hadung

Post on 24-Sep-2018

228 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 3.24 Hallazgos sobre el producto en estado Betadis.unal.edu.co/~icasta/GGP/_Ver_2016_2pub/Clases/2016_01NotasDe... · de software liberado, que en el caso del ejercicio académico,

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.

Page 2: 3.24 Hallazgos sobre el producto en estado Betadis.unal.edu.co/~icasta/GGP/_Ver_2016_2pub/Clases/2016_01NotasDe... · de software liberado, que en el caso del ejercicio académico,

Preparó: Ismael Castañeda Fuentes Pág. 72

Para el ejercicio académico, cada Empresa tipo N tiene que presentar todos los

entregables previstos en el Proyecto; no pueden faltar las lecciones aprendidas y el post

mortem; tiene que estar en ambiente de producción, es decir, por ningún motivo se

recibe en ambiente de desarrollo; se tiene que poder acceder por Internet; el producto

liberado tiene que estar disponible durante las veinticuatro horas del día (24h/d) por lo

menos tres (3) días contados a partir del momento de su presentación para dar

cumplimiento al quinto hito del curso.

La Empresa tipo E tiene que prepararse para ver si el Producto liberado cumple con los

objetivos que se fijó cada una de las Empresas tipo N; si el producto está de acuerdo con

lo diseñado; si presenta todas las características deseadas; si cumplen con los

requerimientos; si se ha pasado satisfactoriamente todas las pruebas que aseguren su

calidad; si los manuales que acompañan el Producto están completos; 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; 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, y desde luego, todo lo anterior dentro del

marco establecido en el Plan para la Dirección del Proyecto.

3.26 Quinto Control El quinto control tiene como objetivo revisar todo lo adelantado en el Proyecto y también

revisar que el Producto esté listo y terminado. Tan pronto como la Empresa de tipo N

considere que su Producto está terminado y listo para la entrega y se han cumplido con

todos los requisitos pedidos en el curso con respecto de la gerencia y gestión del proyecto,

acuerdan una reunión, del líder de aseguramiento de la calidad de la Empresa N

acompañado con las personas que él considere pertinentes, con la Empresa tipo E, quien

es la encargada de elaborar la revisión. Si terminada la reunión, la Empresa tipo E

considera que todo no está listo y terminado, se tiene que acordar otra reunión para

efectuar otra revisión. Se hacen tantas reuniones como sean necesarias, hasta cuando la

Empresa tipo E considere que todo está listo y da su visto bueno para que el Profesor haga

su revisión.

Ahora el líder de aseguramiento de la Calidad de la Empresa N acompañado de las

personas que él considere pertinentes, se reúne con el Profesor para que efectúe su

revisión. Si el Profesor al hacer la revisión está satisfecho, se programa la fecha y hora

para la sustentación final del grupo, la cual va a tener una duración de dos (2) hora y está

compuesta por tres partes. La primera parte es la “Venta del Producto”, es decir es una

Page 3: 3.24 Hallazgos sobre el producto en estado Betadis.unal.edu.co/~icasta/GGP/_Ver_2016_2pub/Clases/2016_01NotasDe... · de software liberado, que en el caso del ejercicio académico,

Gerencia de Proyectos de Software – Notas de clase Pág. 73

presentación de tipo comercial. La segunda parte es una presentación de tipo académica

donde muestran cómo en el Proyecto se puso en práctica la metodología del Pmbok[ 39.

La tercera parte es la presentación de cada Estudiante, en donde cada Estudiante muestre

cómo fue su participación en el Proyecto y en la elaboración del Producto; muestre cuáles

fueron sus aportes; indique cuáles fueron sus mayores dificultades y cómo las superó; y

muestre todas las otras cosas importantes que considere necesarias. A partir de este

momento, el Producto Final tiene que estar disponible en línea por lo menos durante tres

(3) días, las veinticuatro (24) horas del día.

Si el Profesor no está satisfecho con lo mostrado, se harán tantas reuniones como sean

necesarias hasta cuando el Profesor dé su visto bueno y se programe la Presentación final.

En la reunión donde se acuerde la Presentación Final, la Empresa tipo N entrega en físico

todos los soportes (el “Congelado Final” en medio magnético; documentación en papel

que consideren pertinente; el Producto disponible en línea; y cualquier otro material de

soporte).

De cada reunión efectuada, tanto de las reuniones con la Empresa tipo E como con las

reuniones con el Profesor, el líder de calidad de la Empresa tipo N, hace el acta.

Los insumos para estas reuniones, entre otros son: los informes semanales de la Empresas

tipo N; el “Congelado Final”; el Producto de Software funcionando en ambiente de

producción.

El “Congelado Final”, debe contener todo lo trabajado en el curso, incluyendo lo solicitado

en el curso desde el punto de vista académico; todos los documentos que el Pmbok[ 39

pide para la gerencia y gestión de proyectos, especialmente el Contrato, la Propuesta, el

Acta de Constitución del Proyecto, el Plan para la Dirección del Proyecto, los Planes

subsidiarios; las Líneas base; la EDT; el Diccionario de la EDT; los diferentes informes

hechos durante la elaboración del Proyecto; todas las Actas (incluyendo el borrador del

Acta de Cierre); las lecciones aprendidas; el Producto del Proyecto, incluido todo el

código; los manuales que acompañan el Producto (presentación gerencial, manual de

instalación, manuales de usuario, manual del sistema; manual para mantenimiento); un

post mortem (ver post mortem en Introduction to the Team Software Process de W.S.

Humphrey); las presentaciones (incluida la presentación final), entre otros.

La Empresa tipo E debe tener una lista de chequeo, para mirar lo que están entregando;

mirar la consistencia de la información de los informes semanales, las líneas base, la

ejecución del presupuesto y los indicadores; tienen que recibir el producto en ambiente

productivo previa la prueba del escenario dado al comienzo de semestre; mirar los

documentos como los manuales que acompañan el producto para ver su pertinencia y

Page 4: 3.24 Hallazgos sobre el producto en estado Betadis.unal.edu.co/~icasta/GGP/_Ver_2016_2pub/Clases/2016_01NotasDe... · de software liberado, que en el caso del ejercicio académico,

Preparó: Ismael Castañeda Fuentes Pág. 74

concordancia con lo entregado del producto; mirar que ya esté lista la presentación final y

que todo esté listo para cerrar el Proyecto.

Durante las reuniones, la Empresa tipo N tiene que estar en capacidad de contestar con

base en la documentación, preguntas como las siguientes: ¿Cómo se planificó? ¿Se

ejecutó lo que se planificó? ¿Se hizo un registro cuidadoso de las tareas realizadas?

¿Cuáles fueron las desviaciones? ¿Qué ajustes se hicieron? ¿Cómo fue el desarrollo del

producto con respecto del alcance? ¿Con respecto del tiempo? ¿Con respecto de los

costos? ¿Con respecto de la calidad? ¿Cuánto costó el Proyecto? ¿Cuánto costó la

elaboración del producto? ¿Cuánto costó cada uno de los miembros del equipo? ¿Cuánto

costaron las adquisiciones? ¿Cuánto fueron las utilidades? ¿Cuánto se gastó en

imprevistos? ¿Están absolutamente seguros que el Producto que elaboraron era lo que

deseaba el cliente? ¿La holgura en tiempo y costos fue acertada? ¿Los recursos humanos

fueron sido suficientes? ¿Cómo se gestionaron los riesgos? ¿Cómo se gestionaron,

planificaron, ejecutaron, controlaron y cerraron las adquisiciones? ¿Cómo se gestionaron

a los interesados? ¿Cómo se gestionaron los conflictos? ¿Las metodologías seleccionadas

para el desarrollo del Producto fueron acertadas? ¿Qué normas siguieron para la

construcción del software? ¿Cómo se gestionó al personal técnico que desarrolló el

producto? ¿Cómo se llevó a cabo el aseguramiento de la calidad? ¿Cómo se gestionaron

las comunicaciones? ¿Los canales de comunicación funcionaron de acuerdo a lo

planificado? ¿Cómo se gestionó el seguimiento y control del desarrollo del Producto y del

Proyecto? ¿Cómo se validaron las cosas hechas con respecto del Producto y del Proyecto?

¿Lo implementado corresponde a lo diseñado? ¿Fue acertada la selección de lenguajes

y/o interpretadores utilizados para hacer la programación? ¿Se cumplieron las políticas

determinadas con respecto a la calidad del Producto? ¿Se elaboraron las pruebas que

tenían previstas para el sistema? ¿Utilizado los repositorios y cómo fueron sus resultados?

¿Utilizaron algún sistema de trabajo colaborativo, qué resultados obtuvieron? ¿Cómo

gestionaron las versiones del Producto? ¿Cómo les funcionó el proceso de control de

cambios? Y otras que resulten pertinentes y que inquieten a los evaluadores y

calificadores.

3.27 Presentación Final El día programado para la Presentación Final, la Empresa Tipo N presenta la agenda, la

cual debe estar de acuerdo con lo pedido por el Profesor para la Presentación Final y tiene

que contemplar las tres partes: la “presentación comercial”, la “presentación académica”

y la “presentación de cada Estudiante”. La “presentación comercial” tiene que incluir una

demostración del Producto en línea. El auditorio son el Profesor y eventualmente un

invitado por el Profesor. La duración es de dos (2) horas.

Page 5: 3.24 Hallazgos sobre el producto en estado Betadis.unal.edu.co/~icasta/GGP/_Ver_2016_2pub/Clases/2016_01NotasDe... · de software liberado, que en el caso del ejercicio académico,

Gerencia de Proyectos de Software – Notas de clase Pág. 75

El contenido y dinámica de la Presentación Final, los presentadores, 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 Final.

La Presentación Final; la comprobación de la existencia del sitio Web actualizado; de la

existencia y acceso del Producto Final; y de la evaluación del contenido de todo el “Quinto

Congelado”, el Profesor 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 la Empresa Tipo N. La persona que no asista a la Presentación

Final, tiene cero como calificación.

Terminada la Presentación Final se tiene que protocolizar el cierre formal de proyecto y el

Profesor registra la calificación en el Sistema de Información Académica de la Universidad.