Estimación deProyectos de Software   La cara oculta de las diferencias                             Patricia Scalzone      ...
Temario•   El problema•   Técnicas•   … y las diferencias?•   Contratos
Se acuerdan?
El problema “endémico” de la industria  • Sobreestimación  • Subestimación  • Imposible de estimar
Registros de Estimación de la IndustriaTamaño en Puntos de Función              A            Fallados(y Aprox. Líneas de c...
Qué es estimación?  Es una predicción de cuán largoes un proyecto o cuánto va a costar
Pero...• Tenemos los objetivos del negocio:  – Necesitamos tener la Versión 2.1 lista para la Expo de    Mayo  – Necesitam...
Definiciones de “Buena Estimación”
Técnicas de Estimación• Abordajes Tradicionales  – Líneas de Código  – Function Points  – Use Case Points• Abordajes Ágile...
Ballpark Figure           O“el rango del proyecto”  (método oscilante)
Proyecto:               Feliz                                                      DanielCliente:                El Mejor ...
Story Points (Dog Points)
Módulo                               Tipo                                      Nombre                          Complejidad...
… y las diferencias dónde están?• En la administración de riesgos• En Ítems que se pierden en las  estimaciones
Administración de Riesgos
Cómo seguimos?
Requerimientos Funcionales        Factor                Baja              Media                        AltaSetup/Instalaci...
Requerimientos No Funcionales          Factor                   Baja                 Media                       AltaInter...
Requerimientos No Funcionales       Factor             Baja                     Media                            AltaCarac...
Temas del Proyecto - I       Factor                Baja                   Media                           AltaEstabilidad ...
Temas del Proyecto - II          Factor               Baja   Media   AltaCreación de datos de testInstalación de versiones...
Temas del Proyecto - III
Temas del Equipo      Factor                Baja                    Media                         AltaGrupo de Trabajo    ...
Temas del Cliente - I     Factor                   Baja                           Media                                  A...
Temas del Cliente - II     Factor               Baja                      Media                          AltaUsuarios     ...
Actividades de No Desarrollo Vacaciones             Reuniones de la empresa Feriados               Reuniones del Departame...
La planificación tradicional trata aldesarrollo de software como unaactividad predecibleEl desarrollo de softwarees una ac...
Tipos de Contratos
Resumen•   El problema•   Técnicas•   … y las diferencias?•   Contratos
Muchas graciaspor su participación              Patricia Scalzone              Presidente - VEMN SA              patricias...
Estimación de Proyectos de Software
Estimación de Proyectos de Software
Estimación de Proyectos de Software
Próxima SlideShare
Cargando en…5
×

Estimación de Proyectos de Software

745 visualizaciones

Publicado el

La cara oculta de las diferencias en la estimación de proyectos

0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
745
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
13
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.
  • The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
  • The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
  • 3.2 Details on the Software Industry's Estimation Track RecordThe software industry's estimation track record provides some interesting clues to the nature of software's estimation problems. In recent years, The Standish Group has published a biennial survey called "The Chaos Report," which describes software project outcomes. In the 2004 report, 54% of projects were delivered late, 18% failed outright, and 28% were delivered on time and within budget. Figure 3-2 shows the results for the 10 years from 1994 to 2004.Figure 3-2: Project outcomes reported in The Standish Group's Chaos report have fluctuated year to year. About three quarters of all software projects are delivered late or fail outright. What's notable about The Standish Group's data is that it doesn't even have a category for early delivery! The best possible performance is meeting expectations "On Time/On Budget"—and the other options are all downhill from there.Capers Jones presents another view of project outcomes. Jones has observed for many years that project success depends on project size. That is, larger projects struggle more than smaller projects do. Table 3-1 illustrates this point.Table 3-1: Project Outcomes by Project Size Size in Function Points (and Approximate Lines of Code)EarlyOn TimeLateFailed (Canceled)10 FP (1,000 LOC)11%81%6%2%100 FP (10,000 LOC)6%75%12%7%1,000 FP (100,000 LOC)1%61%18%20%10,000 FP (1,000,000 LOC)<1%28%24%48%100,000 FP (10,000,000 LOC)0%14%21%65%Source: Estimating Software Costs (Jones 1998).As you can see from Jones's data, the larger a project, the less chance the project has of completing on time and the greater chance it has of failing outright.Overall, a compelling number of studies have found results in line with the results reported by The Standish Group and Jones, that about one quarter of all projects are delivered on time; about one quarter are canceled; and about half are delivered late, over budget, or both (Lederer and Prasad 1992; Jones 1998; ISBSG 2001; Krasner 2003; Putnam and Myers 2003; Heemstra, Siskens and van derStelt 2003; Standish Group 2004).The reasons that projects miss their targets are manifold. Poor estimates are one reason but not the only reason. We'll discuss the reasons in depth in Chapter 4, "Where Does Estimation Error Come From?"How Late Are the Late Projects?The number of projects that run late or over budget is one consideration. The degree to which these projects miss their targets is another consideration. According to the first Standish Group survey, the average project schedule overrun was about 120% and the average cost overrun was about 100% (Standish Group 1994). But the estimation accuracy is probably worse than those numbers reflect. The Standish Group found that late projects routinely threw out significant amounts of functionality to achieve the schedules and budgets they eventually did meet. Of course, these projects' estimates weren't for the abbreviated versions they eventually delivered; they were for the originally specified, full-featured versions. If these late projects had delivered all of their originally specified functionality, they would have overrun their plans even more.One Company's ExperienceA more company-specific view of project outcomes is shown in the data reported by one of my clients in Figure 3-3.Figure 3-3: Estimation results from one organization. General industry data suggests that this company's estimates being about 100% low is typical. Data used by permission. The points that are clustered on the "0" line on the left side of the graph represent projects for which the developers reported that they were done but which were found not to be complete when the software teams began integrating their work with other groups.The diagonal line represents perfect scheduling accuracy. Ideally, the graph would show data points clustering tightly around the diagonal line. Instead, nearly all of the 80 data points shown are above the line and represent project overruns. One point is below the line, and a handful of points are on the line. The line illustrates DeMarco's common definition of an "estimate"—the earliest date by which you could possibly be finished.The Software Industry's Systemic ProblemWe often speak of the software industry's estimation problem as though it were a neutral estimation problem—that is, sometimes we overestimate, sometimes we underestimate, and we just can't get our estimates right.But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations.
  • 1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1  Distinguish between estimates, targets, and commitments.
  • 1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1  Distinguish between estimates, targets, and commitments.
  • The answer to the question of what an "estimate" is still leaves us with the question of what a good estimate is. Estimation experts have proposed various definitions of a good estimate. Capers Jones has stated that accuracy with ±10% is possible, but only on well-controlled projects (Jones 1998). Chaotic projects have too much variability to achieve that level of accuracy.In 1986, Professors S.D. Conte, H.E. Dunsmore, and V.Y. Shen proposed that a good estimation approach should provide estimates that are within 25% of the actual results 75% of the time (Conte, Dunsmore, and Shen 1986). This evaluation standard is the most common standard used to evaluate estimation accuracy (Stutzke 2005).Numerous companies have reported estimation results that are close to the accuracy Conte, Dunsmore, and Shen and Jones have suggested. Figure 1-6 shows actual results compared to estimates from a set of U.S. Air Force projects.Figure 1-6: Improvement in estimation of a set of U.S. Air Force projects. The predictability of the projects improved dramatically as the organizations moved toward higher CMM levels. [1]Figure 1-7 shows results of a similar improvement program at the Boeing Company.Figure 1-7: Improvement in estimation at the Boeing Company. As with the U.S. Air Force projects, the predictability of the projects improved dramatically at higher CMM levels. A final, similar example, shown in Figure 1-8, comes from improved estimation results at Schlumberger.Figure 1-8: Schlumberger improved its estimation accuracy from an average overrun of 35 weeks to an average underrun of 1 week. One of my client companies delivers 97% of its projects on time and within budget. Telcordia reported that it delivers 98% of its projects on time and within budget (Pitterman 2000). Numerous other companies have published similar results (Putnam and Myers 2003). Organizations are creating good estimates by both Jones's definition and Conte, Dunsmore, and Shen's definition. However, an important concept is missing from both of these definitions—namely, that accurate estimation results cannot be accomplished through estimation practices alone. They must also be supported by effective project control.[1]The CMM (Capability Maturity Model) is a system defined by the Software Engineering Institute to assess the effectiveness of software organizations.
  • 1.1 Estimates, Targets, and CommitmentsStrictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.A target is a statement of a desirable business objective. Examples include the following:"We need to have Version 2.1 ready to demonstrate at a trade show in May.""We need to have this release stabilized in time for the holiday sales cycle.""These functions need to be completed by July 1 so that we'll be in compliance with government regulations.""We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.Tip #1  Distinguish between estimates, targets, and commitments.
  • …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
  • http://msdn.microsoft.com/en-us/library/bb738695.aspx
  • …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
  • …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
  • …” Empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de "senior" de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en números que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación….”http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil
  • http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil¿En cuantos negocios tiene un coste similar la producción de una unidad que la de un millón? ¿Cuantos negocios tienen un 99% de margen de beneficio en la venta de sus productos? ¿En cuantos negocios las empresas que desarrollan productos terminan incluyendo prestación de servicios, tanto si les gusta como si no? (proporcionando cierta configuración del producto, y servicios técnicos como integración del sistema y mantenimiento). ¿En cuantos negocios los mejores empleados son diez o veinte veces más productivos que los peores? ¿Cuantos negocios toleran como habitual que el 75 o el 80% de los proyectos de desarrollo de productos terminen tarde o desbordando el presupuesto? ¿En cuantas empresas, quienes desarrollan los productos se autoconsideran artistas, y no científicos o ingenieros, y presentan temperamentos difíciles e inestables? ¿En cuantos negocios los clientes terminan siendo cautivos de un determinado proveedor a raíz de las decisiones que alguien tomó diez años antes y que no se pueden eliminar fácilmente?."
  • Algunos intentan otro tipo de contratos…  …”Ante el problema de tener que detallar todo prematuramente, el cliente suele adoptar una posición defensiva que es contraria a sus intereses. El cliente tratará que el sistema sea lo suficientemente flexible para poder cubrir las necesidades que pudieran surgir o cambiar. Por este motivo el sistema implementará ciertas funcionalidades no se llegaran a utilizar.” … “En proyectos reales la aplicación de las metodologías ágiles se enfrenta en muchas situaciones a problemas que la teoría no contemplaba. El principal problema que nosencontramos en los proyectos reales es que los tipos de contratos no encajan con algunas de las prácticas. Estos contratos suelen ser de dos tipos: ·  Contrato de Alcance Cerrado: Que nos obligan a cerrar los requisitos en la primera fase (Metodologías tradicionales)·  Subcontratación de personal: Que no podemos clasificarlo como proyecto, ya que suele ser el cliente el que dicta en qué se emplea ese esfuerzo. Una solución que hemos utilizado en proyectos ha sido definir un nuevo tipo de contrato, en el que especifiquemos la funcionalidad que se va a desarrollar, pero en elque el alcance podrá ser modificado durante la duración del contrato. Este alcance podrá ser modificado porque lo que se ofrece es un esfuerzo que es el que se estima que van a llevar los requisitos acordados, pero que podrán ser intercambiados por otros requisitos de igual dificultad técnica.”  http://www.willydev.net/descargas/prev/metodologiasagiles.pdf 
  • Estimación de Proyectos de Software

    1. 1. Estimación deProyectos de Software La cara oculta de las diferencias Patricia Scalzone Presidente - VEMN SA patricias@vemn.com.ar Daniel Laco Director Ejecutivo - VEMN SA daniell@vemn.com.ar
    2. 2. Temario• El problema• Técnicas• … y las diferencias?• Contratos
    3. 3. Se acuerdan?
    4. 4. El problema “endémico” de la industria • Sobreestimación • Subestimación • Imposible de estimar
    5. 5. Registros de Estimación de la IndustriaTamaño en Puntos de Función A Fallados(y Aprox. Líneas de código) Temprano Tiempo Tarde (Cancelados)10 FP (1.000 LOC) 11% 81% 6% 2%100 FP (10.000 LOC) 6% 75% 12% 7%1.000 FP (100.000 LOC) 1% 61% 18% 20%10.000 FP (1.000.000 LOC) <1% 28% 24% 48%100.000 FP (10.000.000 LOC) 0% 14% 21% 65%
    6. 6. Qué es estimación? Es una predicción de cuán largoes un proyecto o cuánto va a costar
    7. 7. Pero...• Tenemos los objetivos del negocio: – Necesitamos tener la Versión 2.1 lista para la Expo de Mayo – Necesitamos tener la Release estabilizada para las ventas de vacaciones. – Necesitamos tener las funciones listas para el 1 de Julio para cumplir con requisitos de regulaciones del gobierno. – Debemos limitar el costo del próximo Release a 2$ millones, porque es el presupuesto máximo que tenemos.• Son deseables o imperativos, pero no necesariamente alcanzables
    8. 8. Definiciones de “Buena Estimación”
    9. 9. Técnicas de Estimación• Abordajes Tradicionales – Líneas de Código – Function Points – Use Case Points• Abordajes Ágiles – Planning Poker – Story Points
    10. 10. Ballpark Figure O“el rango del proyecto” (método oscilante)
    11. 11. Proyecto: Feliz DanielCliente: El Mejor Estimadores Maxi Andres Total Estimadores 3 Ronda 1 Ronda 2 Grupo Tarea Subtarea Detalle Daniel Maxi Andres Daniel Maxi Andres Sección 1 2 1 Categorías 2 2 2 Ítems Attachs 100 100 40 SeccionAtributos ABMs CategriasAtributos Atributos Back End Usuarios 4 2 8 Niveles de Autorización 8 13 8 Usuarios / Niveles de Admin de Seguridad 13 20 3 Autorización Pantalla de publicación de Proceso de publicación Manejo de Archivos 20 20 13 producto Niveles de autorización 13 20 8 Productos 3 2 5 Soluciones de producción 3 2 5 Recursos de Venta 3 2 5 UI Visualización Visor MHT 3 2 3 Front End Árbol de navegación de 3 3 5 productos Búsqueda Rápida 3 3 5 Buscador de productos Búsqueda Avanzada Filtro Genérico 13 13 20 Localización Multi-idioma 20 20 20Totales 212 226 151 0 0 0 Ronda 1 Ronda 2Daniel 212 0Maxi 226 0Andres 151 0Mínimo 151 0Promedio 196 0Máximo 226 0
    12. 12. Story Points (Dog Points)
    13. 13. Módulo Tipo Nombre ComplejidadDIAGNOSTICO Competencia / Posición competitiva Evualuacion (Criterios) ALTADIAGNOSTICO Menú Principal Diagnóstico Diagnostico Interactivo ALTA Diagnóstico / Resumen del Diagnóstico /DIAGNOSTICO Conclusiones Conclusiones MEDIADIAGNOSTICO no se usa (codigo comentado) Grafico de Ventas y Rentabilidad (1) BAJADIAGNOSTICO no se usa (codigo comentado) Grafico de Ventas y Rentabilidad (2) BAJA Icono en el formulario FrmDIA002DIAGNOSTICO (Gráfico) Grafico de Ventas y Rentabilidad (3) ALTA Activación de Indicadores, Reglas eDIAGNOSTICO Informes Activacion de Indicadores, reglas e informes MEDIA Diagnóstico / Resumen del Diagnóstico /DIAGNOSTICO Resumen Resumen de diagnostico - Puntos clave MEDIA Diagnóstico / Resumen del Diagnóstico /DIAGNOSTICO F.O.D.A Analisis F.O.D.A ALTADIAGNOSTICO icono en el formulario FrmDIA002 (lupa) Informe de indicadores estrategicos (PivotTable) MEDIA Administración del Sistema / Carga deDIAGNOSTICO Preguntas del Diagnóstico Ingreso de CheckList ALTAARQUITECTURA ALTA Ponderación ComplejidadBaja 4Media 5Alta 20Testing % 30Gestión de Proyecto % 10Implementación % 30% Riesgo 30
    14. 14. … y las diferencias dónde están?• En la administración de riesgos• En Ítems que se pierden en las estimaciones
    15. 15. Administración de Riesgos
    16. 16. Cómo seguimos?
    17. 17. Requerimientos Funcionales Factor Baja Media AltaSetup/InstalaciónConversiones de datosInteroperabildiad del Individual Otros sistemas de la misma Heterogéneo.Proyecto tecnología Sistemas de diferentes tecnologíasProcesamiento complejointerno
    18. 18. Requerimientos No Funcionales Factor Baja Media AltaInteroperabilidadMantenibilidadPerformance Poco exigentes o Exigencia de rendimiento Exigencia de rendimiento muy sin relevancia estandar exigentePortabilidadConfiabilidadCódigo que debe serrehusadoSeguridadCapacidad de SupervivenciaFacilidad de usoSistema DistribuidoNro potencial de usuarios < 10 usuarios 10 a 50 usuarios > 50 usuariosConcurrencia
    19. 19. Requerimientos No Funcionales Factor Baja Media AltaCaracterísticasespeciales deseguridadTecnología Estandar, probada Probada, pero nueva en la Novedosa, sin antecedentes y conocida en la organización. organizaciónTesteabilidad Ambiente Ambiente con interacción de Redes y conexiones Client/Server varios servidores. Ej: complejas. SO dispares, Arquitectura SOA organización del cliente restrictiva. Tecnologia nueva y sin experiencia. La Seguridad como un factor del ambiente de prueba (Ej. X509)Afecta a Sistemas en No Si, pero hay franjas de tiempo El sistema es critico, de 7 x 24Producción donde se pueden hacer actualizaciones con parada del sistema
    20. 20. Temas del Proyecto - I Factor Baja Media AltaEstabilidad de los Estables y Relativa variacion y definición Inciertos y con mucharequisitos definidos pobre variaciónTiempo de Entrega Menos de 3 meses 3 a 9 meses Más de 9 mesesProcesar los pedidosde cambios.Administrar elseguimiento de BugsCorregir los bugsCoordinación de laGestión. Reuniones
    21. 21. Temas del Proyecto - II Factor Baja Media AltaCreación de datos de testInstalación de versiones deprueba en locaciones delclienteInteractuar con Clientes oUsuarios.Revisar planificaciones,estimaciones, arquitectura,diseños, planes de puesta enmarcha, casos de test, etc.
    22. 22. Temas del Proyecto - III
    23. 23. Temas del Equipo Factor Baja Media AltaGrupo de Trabajo Con experiencia y Poca experiencia y Sin experiencia en proyectos capacitación en capacitación en proyectos similares proyectos similares similaresMejora de laPruductividadMentoring de nuevosmiembros.
    24. 24. Temas del Cliente - I Factor Baja Media AltaFacilidad deentrenamiento deusuariosCliente Conocido y con buenos Cliente nuevo, con buenas Desconocido, o conocido con antecedentes referencias o relaciones conocidas problemas en proyectos anterioresInterlocutores del Buena formación técnica y Formación Media y regular en Desconocido, o conocido conCliente en gestión de proyectos. gestión de proyectos. Regular problemas en proyectos anteriores Buena actitud de ayuda y asistencia en resolución de servicio. problemasImpacto en Mínimo. Cambios moderados en Cambios significativos enOrganización organización, cultura, métodos de organización, cultura, métodos de trabajo trabajo
    25. 25. Temas del Cliente - II Factor Baja Media AltaUsuarios Pocos usuarios Un Departamento o Unidad Varios Departamentos oInvolucrados de Negocio EmpresasImpacto Externo Afecta principalmente Afecta moderadamente a Afecta a terceros no al Departamento otros Departamentos, involucrados, ciudadanos, afectado Organizaciones o Clientes organizacionesTecnología Estandar, probada y Probada, pero nueva en la Novedosa, sin antecedentes conocida en la organización. organizaciónTiempo de Disponibilidad exclusiva El interlocutor tiene otros El interlocutor mantieneRespuesta del en el proyecto proyectos, pero este tiene muchos proyectos enCliente prioridad simultaneo. El interlocutor no esta asignado al proyecto, solo colabora
    26. 26. Actividades de No Desarrollo Vacaciones Reuniones de la empresa Feriados Reuniones del Departamento Días de enfermedades Configuración de nuevos puestos de trabajo Entrenamiento Instalación de nuevas herramientas Fines de Semana Resolución de problemas de Software y Hardware
    27. 27. La planificación tradicional trata aldesarrollo de software como unaactividad predecibleEl desarrollo de softwarees una actividad de creacióny transmutaciónde conocimiento.
    28. 28. Tipos de Contratos
    29. 29. Resumen• El problema• Técnicas• … y las diferencias?• Contratos
    30. 30. Muchas graciaspor su participación Patricia Scalzone Presidente - VEMN SA patricias@vemn.com.ar Daniel Laco Director Ejecutivo - VEMN SA daniell@vemn.com.ar

    ×