109 Metodologia Para La Estimacion De Tiempos De Un Proyecto
•Transferir como PPTX, PDF•
1 gostou•3,037 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 109 Metodologia Para La Estimacion De Tiempos De Un Proyecto
Semelhante a 109 Metodologia Para La Estimacion De Tiempos De Un Proyecto (20)
Mais de GeneXus
Mais de GeneXus (20)
Último
Último (10)
109 Metodologia Para La Estimacion De Tiempos De Un Proyecto
- 1. GX Consulting Development Framework: Metodología para la estimación de tiempos de un proyecto Ing. Marcela Corbo, MBA GenexusConsulting Ing. Alejandra Lemos, PMP GenexusConsulting
- 4. ¿Qué necesitamos para estimar?
- 5. ¿Qué necesitamos para estimar? Model Driven Design Herramientas Visión de datos Visión de procesos Articulación Visión de explotación
- 7. Clasificación de Objetos GeneXus Categorías Complejidad Interfases Patrones Servicios Flujos Muy alta Alta Media Baja
- 8. Primer paso Identificamos para cada funcionalidad, el/los objetos GeneXus necesarios, y lo clasficamos.
- 9. Segundo paso Por cada módulo, generamos un resumen de los objetos a construir.
- 10. Tercer paso Ponderamos cada objeto con horas de esfuerzo de construcción. Las medidas de esfuerzo son propias de cada proyecto.
- 11. ¿Qué etapas se estiman?
- 12. Cuarto paso Incluimos en la estimación las etapas del proyecto, que correspondan.
- 13. Validación de la estimación Experiencia Juicio experto Analogía Registros históricos Puntos de función GXPoints
- 15. Analogy
- 16. Tichneor ILF
- 17. FP Prognosis
- 18. NESMA
- 19. Backfiring (LOC)
- 21. Estimación Experiencia Ponderar por GXPoints Especificaciones Esfuerzo Total Recuento de objetos GX Ponderación por esfuerzo Recuento de puntos de función Ponderación por productividad
- 22. Cronograma Se plasman los cálculos individuales de las tareas. Tomando en cuenta: Precedencias Recursos Hitos previstos
- 23. Corroborar estimaciones Especificaciones Esfuerzo Total Recuento de objetos GX Ponderación por esfuerzo Recuento de puntos de función Ponderación por productividad Producto Recuento de GXPoints
- 24. Automatización Conteo post mortem
- 26. ¿De qué depende la productividad?
- 27. Equipo
- 28. Metodología Administración de ambientes Pautas de desarrollo Reutilización de código y conocimiento Desarrollo uniforme
- 29. Herramientas
- 30. Comunicación
- 32. ¿Genexus? = Productividad PF/MH
- 34. Preguntas Ing. Marcela Corbo, MBA Gerente de Proyecto – GeneXus Consulting mcorbo@genexusconsulting.com Ing. Alejandra Lemos, PMP Gerente de Proyecto – GeneXus Consulting alemos@genexusconsulting.com
Notas do Editor
- Sofi
- Cuántas veces tuvo que contestar las preguntas: ¿cuánto tiempo más o menos me lleva un sistema que haga tal o cual cosa? ¿Cuánto me cuesta?¿Cómo hizo para responder?
- En GeneXus Consulting hemos estado trabajando en propuesta metodológica que nos ayude en la estimación de los proyectos.Por lo que, a nivel de GeneXus Consulting Development Framework nos ubicaremos en una etapa de métricas que engloba a todo el proyecto.
- Cuando vamos a estimar los tiempos para un proyecto contamos con especificaciones con diferentes grados de avance. Dependiendo de la profundidad de dichas especificaciones y de las certezas que tengamos, tendremos mejores o peores estimaciones. El punto de partida de nuestra metodología se basa en un conjunto de especificaciones funcionales nos brindan 3 visiones:La visión de datos: un modelo de datos a veces especificado como un diagrama de clases UML a veces expresado en las propias transacciones en GX. La visión de procesos: diagramas de procesos, a veces especificados en GXFlowLa visión de las actividades y su articulación: expresada muchas veces en casos de uso.
- Cuando el equipo funcional está a cargo de Genexus consulting, empleamos la metodología Model Driven design (explicado en la charla de Mayda de hoy en la mañana), para obtener esas visiones.Cuando el equipo funcional es independiente, tratamos de complementar las especificaciones entregadas aplicando esta metodología de diseño. Es nos permite determinar con bastante claridad los componentes básicos del sistema y definir como se articulan para componer así la aplicación. Para quienes no participaron de la charla de Mayda, repasamos algunos de los conceptos mas importantes. Básicamente una aplicación tiene 4 visiones o perspectivas bajo las cuales se diseña. Estas son: Visión de Datos – Modelo de entidadesVisión de Procesos – Modelo de Procesos Actividades + Articulación u orquestamiento – Casos de uso Visión de explotación – Modelo de medición Definir estas 4 visiones trae como resultado exponer un conjunto de "Operaciones Básicas" o "Servicios" asociados a mis Entidades de Negocio y que son la materia prima para la construcción de una aplicación bajo el paradigma SOA .Ya hemos hablado de las 3 primeras visiones, aclaramos que la visión de explotación no la estaremos profundizando aquí dado que nuestra metodología de estimación está aplicada a la construcción de un sistema operacional. Continuando con la letra del problema les contamos que los otros elementos conocidos son las herramientas con las que contamos para hacer la construcción. Estas herramientas son: GeneXus, independientemente de la versión y el generador que se elija.GXPortal, como integrador y administrador de la seguridad.GXFlow, para modelar los procesos de negocios.K2BTools / Patterns, para unificar criterios de diseño y mejorar la productividad.Todas estas herramientas requieren capacitación para su uso, pero como beneficio nos simplifican en gran medida la implementación.
- Que tomamos en cuenta para clasificar los objetos: si se utilizará la interfaz diseñada con k2bpatterns por default, la cantidad de atributos, la cantidad de reglas, cantidad de relaciones, etc. En el caso de tener muchas herencias, debemos tomar en cuenta si resolveremos la implementación con web panels y web components, etc. Para el caso de los webpanels y si serán entrypanels (paneles en general para pedir datos de entrada para un proceso) o querypanels, en ese caso se tomará en cuenta si se resuelve o no con tabla base, o si requiere una programación muy compleja para devolver los datos deseados. (duda con los data providers – resuelven esto:) ) Para el caso de los servicios, la complejidad muchas veces dependerá de si es un cálculo complicado, la cantidad de entidades involucradas, las relaciones, etc.Para cada caso de uso, tomamos en cuenta el tiempo que insume programar la instancia de pattern (es muy menor) y su aplicación En el caso en que el caso de uso que estamos estimando sea una actividad de un proceso de flow entonces se tomará en cuenta el tiempo de diseño (configurar datos relevantes, restricciones, etc) – esto en la x es igual ??? Paso 1.Primero categorizamos los objetos, en interfaces y servicios, y los clasificamos según su complejidad.Los objetos interfaces son aquellos que presentan una interfaz para el usuario (puede ser un webpanel o una transacción). Los objetos que se resuelven con procedimientos Genexus, serían servicios. Para cada uno de los objetos, ponemos 4 escalas de complejidad desde baja hasta muy alta. Paso 2.Se pondera cada uno de estos tipos de objetos, con la cantidad de horas de esfuerzo que lleva su construcción.Estas ponderaciones son propias de cada equipo de trabajo, más adelante se presentan los motivos por los cuales estos valores pueden variar.Paso 3.Que tiempos medimos?El tiempo que estimamos incluye el tiempo que se necesita para comprender más la funcionalidad y expresarla de modo que un desarrollador sin experiencia pueda construirlo. (Incluye los tiempos de comprensión de las especificaciones, reuniones de kick off para aclaraciones, etc). El tiempo de construcción propiamente dicho con las interacciones necesarias con el equipo funcional. El tiempo de ajustes a las validaciones funcionales individuales por módulo que se realicen. Los tiempos de integración al consolidado, pruebas de integración con el resto de los módulos y ajustes a una validación funcional integrada. También se consideran los tiempos necesarios para la integración con GXFlow, GXPortal y GXQuery que dependerán de la versión de Genexus con la que se esté trabajando (para el caso de la X, la integración con GXFLow está implícita). Duda (que pasa con el query en la x esta integrado?) Identificadas las tareas del proyecto que se desean estimar, se ponderan a partir del esfuerzo estimado para la construcción. Estas tareas varían según cada proyecto, así como sus ponderaciones.Esto da un total final de horas que nos permitirá dar un costo aproximado. Y según la cantidad de RRHH que podamos disponer tendríamos un orden de magnitud de la duración.La duración total dependerá no sólo del equipo de trabajo, sino también, de las precedencias en los desarrollos. No siempre es viable paralelizar.
- Las etapas que consideramos para medir la productividad son las mismas que se consideran para realizar las estimaciones, desde el diseño hasta la entrega a test.
- Experiencia:¿Qué psersonas hacen las estimaciones? Gerentes de proyecto o líderes de desarrollo. Son personas con experiencia previa en proyectos, tanto en desarrollo, como en análisis.Registros históricos:GXPoints / Puntos de función: como medidas de esfuerzo (hice tantos XX en tanto tiempo).
- Cómo podemos hoy saber si una kb es más grande que otra?Por cantidad de objetos no nos sirve, porque capaz que 1.000 objetos en una kb tienen mucho más complejidad que 1.000 objetos de otra kb.La cantidad de líneas de código tampoco es una métrica válida, porque dependiendo del generador puede que genere más líneas para una misma funcionalidad.Es importante entonces, establecer una métrica única para poder medir con una misma medida.
- Cronograma: Sirve para los cálculos individuales de las tareas, luego para el armado del cronograma tomar en cuenta precedencias, recursos, etc
- Nuestras estimaciones se basan en un dato conocido de productividad.Cuánto mas exacto sea ese dato de productividad, mejores serán mis estimaciones. Es por ello que este modelo necesita retroalimentarse. Una vez que construí la funcionalidad, necesito tomar las medidas para calcular la productividad y comparar con los datos anteriores. Para poder obtener la productividad en puntos de función cuento la cantidad de puntos de función construidos y los divido por el tiempo que me llevó construirlos. Para obtener la productividad en gxpoint, realizo el mismo proceso. La ventaja que me brinda medir la productividad en términos de gxpoint es que la cuenta se realiza automáticamente.
- Para la comunidadGenexus, sería un avance importante tener medidas de productividad en GXPoints, pero necesitamos obtener medidas de productividad en puntos de función porque es el punto de función es una medida universal. La mala noticia es que la cuenta de puntos de función es algo difícil de realizar, requiere de expertiz en el tema y además lleva mucho tiempo. Personalmente he participado en ese proceso y es un trabajo muy engorroso. Es por eso que estamos tratando de encontrar una correlación entre gxpoint y puntos de función. Esto nos permitiría obtener medidas de productividad en puntos de función, simplemente presionando una tecla. Existen consultoras que se dedican a clasificar los lenguajes a partir de líneas de código. La técnica consiste en determinar cuántas líneas de código es necesario escribir para obtener un punto de función. Es bastante razonable entonces pensar en realizar esto a partir de la spec (que es lo que toma en cuenta la medición de los gxpoint)
- Ayer se presentó un prototipo que permite definir en una capa entre la especificación de requerimientos y la construcción de la base de conocimiento Genexus, las entidades que tendrá mi solución. Una vez definidas esas entidades, el modelo genera a partir de ellas, una cantidad de objetos que dan soporte a esas entidades. Si yo contara los gxpoint de todos esos objetos generados tendría la cota inferior de la cantidad de gxpoint que tendrá mi aplicación.
- Sabemos que para estimar necesitamos conocer nuestra productividad, pero además necesitamos que sea buena. La idea aquí es presentar los factores que a nuestro entender afectan en forma directa a la productividad.
- Quiénes juegan y en qué posiciónEsta es la conformación básica de un equipo de Genexusconsulting. Es una estructura jerárquica de roles en la que cada rol tiene responsabilidades perfectamente definidas. Lo importante aquí a destacar es que independientemente de cuántas personas conformen el equipo tenemos que cubrir todos los roles.
- Como se juega? Una vez que armamos el equipo y sabemos lo que tenemos que construir comienza el desarrollo. Para construir hay que tener muy claras la reglas de juego. Carolina Torrado y Paula Blanco dieron una charla al respecto (administración de ambientes) Cuales son los factores de la metodología que tienen una relación directa con la productividad: Tener una buena administración de los ambientes.Tener bien definido el protocolo de comunicación entre esos ambientes, es decir cómo voy a pasar cosas de un ambiente a otro. Y contar conPautas de desarrollo claras.Las pautas de desarrollo nos brindan la posibilidad de tener: Reutilización de código y conocimiento Buenas prácticas, evitando elretrabajo. Desarrollo uniformeMayor calidad del producto finalLa reducción de los tiempos de desarrollo, capacitación y testeo
- Con que juego ? Voy en moto o voy en ferrariUsando patterns (K2BTools por Ejemplo) y toda la suite de productos Genexus (GXPortal como organizador de seguridad y de acceso, GXFlow, GXQuery y GXPortal), se tiene un impacto fenomenal en la productividad
- Seguimiento y control del desarrollo. Para hacer el seguimiento y control del desarrollo realizamos Reuniones de seguimiento semanales donde participan los líderes de frente, el referente tecnológico, el gerente y el director del equipo. El objetivo es hacer el seguimiento del cronograma, para detectar desvíos tomando acciones correctivas en forma temprana, Evaluar los controles de cambio, etc. El cronograma es una excelente herramienta donde queda documentado exactamente el esfuerzo en horas hombre para la construcción de determinada funcionalidad en cada una de las etapas (diseño, construcción y test unitario) Todas esas horas sirven para corroborar las estimaciones.
- Respecto a la productividad promedio en Puntos Funcionales tomamos las siguientes referencias de productividad De diversas fuentesDesarrollo en 3GL (Cobol, etc.) : Entornos de 10 PF por MH (Puntos Funcionales por Mes Hombre)Desarrollo en Java, C#, Visual Estudio: Entornos de 20 PF por MHDesarrollo en 4GL: Entornos de 40 PFGrompone el año pasado en el Encuentro, hablaba de que la tecnología estaba permitiendo llegar a los 25 PF por MH ( y luego aclaró que con GX podría ser bastante más).Hoy podemos afirmar que mejorando nuestras técnicas, nuestros números son: Sin usar patterns, estamos obteniendo valores superiores a 100 PF por MH y usando toda la suite, entre 200 y 300 PF por MHEn cualquier caso es un aumento formidable con respecto al standard de construcción de hoy.
- Esta metodología es simplemente una propuesta. Cada uno debe encontrar la manera de ponderar correctamente cada tipo de objeto y actividad, según su equipo y el proyecto.La forma de estimar cada vez mejor es haciendo un seguimiento del cronograma, obtener métricas y corroborar las estimaciones. Tener buena productividad es bueno para todos por eso que los invitamos a colaborar con este proyecto.