Modelos y estándares de procesos de desarrollo de software Universidad de los Andes ECOS – 2010 – Sección I.

Presentación del tema: "Modelos y estándares de procesos de desarrollo de software Universidad de los Andes ECOS – 2010 – Sección I."— Transcripción de la presentación:

1 Modelos y estándares de procesos de desarrollo de software Universidad de los Andes ECOS – 2010 – Sección I

2  Tiempo por fase  Metas del grupo  Metas de los roles  PIP

3  La mayor dedicación de este ciclo fue a la iniciación del ciclo y a la planeación.  Se tuvo una desviación de 1.8 horas pero faltaron 9 actividades por ejecutar.

4  Tiempo por fase  Metas del grupo  Metas de los roles  PIP

5  Las metas de cumplimiento no se cumplieron ya que no se logró avanzar mucho en la construcción del componente.

6  Tiempo por fase  Metas del grupo  Metas de los roles  PIP

7  Líder

8  Líder de desarrollo

9  Líder de planeación

10  Líder de procesos y calidad

11  Líder de soporte

12  Tiempo por fase  Metas del grupo  Metas de los roles  PIP

13  Evaluación del ciclo  Tuvimos inconvenientes al implementar el algoritmo el equipo decidió enfocarse en el proceso y posponer la liberación del primer release del software.  La mayor parte del tiempo se dedico a tareas del proceso.  El equipo logró familiarizarse con las diferentes etapas del proceso.

14  Lecciones aprendidas  La planeación debe realizarse en concenso, procurando que la carga de cada integrante esté balanceada dentro del tiempo disponible según su calendario personal.  En la estimación de cada tarea se debe considerar que el equipo no es experto en TSP, de manera que se requiere lectura e investigación.  La dependencia entre tareas se debe definir y planear de manera que ningún integrante del equipo de trabajo tenga que esperar a que otro finalice.

15  Lecciones aprendidas  En la planeación se deben incluir tareas asociadas con la lectura de los diferentes documentos generados por el equipo, con el fin de que todos estén informados y exista retroalimentación.  La planeación debe considerar las tareas asociadas con el plan de calidad, en este ciclo se hizo la planeación antes de tener el plan de calidad, por lo cual sólo se asignó un recurso a cada tarea de inspección.  El plan de calidad se debe mejorar e interiorizar por cada uno de los integrantes del equipo con el fin de que siempre se tenga presente en la ejecución del proceso.

16  Lecciones aprendidas  Dada la premura del tiempo no se respeto el proceso, dando inicio a tareas sin finalizar otras que eran prerrequisito.  La carga excesiva de tareas que tenia cada integrante, llevo a que el equipo no pudiera apoyar rápidamente a la persona encargada de implementar el algoritmo Credit Score.  Todo el equipo de trabajo debe leer y seguir lo establecido en el documento de administración de configuraciones, ya que a pesar de haberse definido este documento no se está aplicando.

17  Lecciones aprendidas  Todo el equipo de trabajo debe leer y seguir lo establecido en el documento de administración de configuraciones, ya que a pesar de haberse definido este documento no se está aplicando.  Para las tareas que se realizan en grupo, cada integrante debe reportar el avance según su aporte.  Las formas TSPi fueron diligenciadas por los líderes de calidad y planeación en el transcurso del proceso, por lo cual no se aprovecharon al máximo.

18  Acciones a tomar  En la reunión de inicio del ciclo se presentará la planeación para que sea revisada por el equipo de trabajo, realizando los ajustes necesarios.  En caso de que no se finalice una tarea a tiempo y ésta sea prerrequisito para iniciar otra tarea, los responsables de dichas tareas se deben enfocar en terminar la tarea predecesora y luego abordar la tarea dependiente.  En dotProject para las tareas realizadas en grupo, cada integrante debe reportar el avance según su aporte.  La asignación de cada una de las tareas se hará basándose más en la experiencia de cada uno de los integrantes del equipo.