PLAN DEL PROYECTO

1. PLAN DEL PROYECTO UNIDAD 4 Ing. Francisco Mauro Salgado

2. Contenido • Plan del Proyecto • 4.1Objetivo de la planeación • 4.2 Programa de actividades. • 4.3 Factores de costos de software. • 4.4 Métricas de procesos de desarrollo de software. • 4.5 Estimación de los costos • 4.6 Evaluación de riesgos. • 4.7 Plan de aseguramiento de la calidad de software. • 4.8 Plan del control de la configuración.

3. 4.1 Objetivo de la planeación

4. Planeación de Proyectos de Software El objetivo principal de la planeación del proyecto es establecer una estrategia pragmática para controlar, rastrear y monitorear un proyecto técnico complejo ¿Por qué? ¡Para que los resultados finales se obtengan a tiempo y con calidad!

5. Pasos • Alcance – entender el problema y el trabajo que debe ser realizado • Estimación – ¿qué tanto esfuerzo? ¿cuánto tiempo? • Riesgo – ¿qué puede salir mal? ¿cómo evitarlo? ¿qué podemos hacer? • Calendarización – ¿cómo ubicamos los recursos a través del tiempo? ¿cuáles son los hitos? • Estrategia de Control – ¿cómo controlar la calidad?¿cómo controlar el cambio?

6. ¡Escríbalo! Alcance del Proyecto Estimaciones Riesgos Calendario Estrategia de Control Plan de Proyecto de Software

7. 4.2Programa de actividades

8. Definir conjuntos de tareas • Datos de métricas que indican un área problema no deben ser considerados “negativos”. Estos datos son meramente un inidicador en la mejora del proceso • No obsesionarse una simple métrica para exluicr otras métricas importantes

9. Definir una Red de Tareas I.5a Implement. del Concepto I.3a Valuación de Riesgos Técnicos I.5b Implement. del Concepto I.6 Reacción del Cliente I.3b Valuación de Riesgos Técnicos I . 1 I . 2 I.4. Prueba del Concepto Planeación del Concepto Alcance del Concepto Integrar a,b,c I.3c Valuación de Riesgos Técnicos I.5c Implement. del Concepto Las 3 tareas I5 son aplicadas en paralelo a 3 diferentes funciones del concepto Las 3 tareas I3 son aplicadas en paralelo a 3 diferentes funciones del concepto

10. Utilizar herramientas automatizadaspara generar una gráfica de Gantt Tareas del Proyecto semana 1 semana 2 semana 3 semana 4 semana 5 I.1.1 Identificar necesidades y beneficios Reunión con los clientes Identificar necesidades y restr. del proy. Establecer la declaración del producto Hito: Declaración del Producto Definida I.1.2 Definir la salida/control/entreada (OCI) Alcance de las funciones de teclado Alcance de las funciones por voz Alcance de los modos de interacción Alcance del documento de diagnóstico Alcance de otras funciones Documentar OCI (outpu, control, input) FTR: Revisar OCI con el cliente Revisar OCI como se requiere Hito: OCI definida (output,control,input) I.1.3 Definir la funcionalidad/comportamiento Definir las funciones de teclado Definir las funicones de entrada por voz Describir los modos de interacción Describir el chequeo de ortografía/redacc. Describir otras funciones del WP FTR: Revisar definición OCI con cliente Revisar como se requiere Hito: Definición de OCI completada I.1.4 Aislar los elementos de software Hito: Elementos de Software Definidos I.1.5 Investigar disponibilidad de Sw existente Investigar componentes de edición de texto Investigar componentes de entrada de voz Investigar componentes de adm. de arch. Investigar componentes ortogr./redacción Hito: Identificación de componente reusables I.1.6 Definir características técnicas Evaluar la entrada por voz Evaluar el chequeo de gramática Hito: Características Técnicas Evaluadas I.1.7 Hacer una estimación rápida del tamaño I.1.8 Crear la Definición del Alcance Revisar el alcance de docs con el cliente Revisar el documento como se requiere Hito: Documento de Alcance completado

11. 4.3 Factores de costos de desarrollo de software.

12. El Costo del Cambio de Requerimientos 60-100x 1.5-6x 1x Después de liberación Desarrollo Definición

13. Utilización vs. Deterioro Incremento de tasa de fallas debido a efectos colaterales Tasa de Fallos cambio curva actual Curva idealizada Tiempo

14. ¿Por qué se pagan las actividades de SQA? costo para encontrar y corregir un defecto 100 60.00-100.00 escala logarítmica 10.00 10 3.00 1.50 1.00 0.75 1 prueba Diseño uso en campo Req. código pruebas de sistema

15. 4.4Métricas de procesos de desarrollo de software.

16. Medición y Métrica ... recolectar métricas es muy difícil ... consume mucho tiempo ... es muy burocrático ... no probarán nada ... Cualquier cosas que necesites cuantificar debe ser medido y de alguna forma es superior a no medirlo del todo Tom Gilb

17. ¿Por qué debemos medir? • Señalar • Evaluar • Predecir • Mejorar

18. Medidas para el Administrador proceso métricas de proceso métricas de proyecto medición métricas de producto producto ¿Qué usamos como base? • ¿tamaño? • ¿función?

19. Métricas de Proceso • mayor enfoque sobre la calidad lograda como consecuencia del proceso repetible o administrado • datos de SQA estadísticos • análisis y categorización de errores • eficiencia en remoción de defectos • propagación de fase en fase • reuso de datos

20. Métricas de Proyecto • Esfuerzo/Tiempo por Tarea de IngSw • Errores no cubiertos por hora de revisión • Fechas de entrega reales vs programadas • Cambios (número) y sus características • Distribución del esfuerzo sobre tareas de IngSw

21. Métricas sobre Producto • enfoque en la calidad de los entregables • medidas del modelo de análisis • complejidad del diseño • complejidad algorítmica interna • complejidad arquitectónica • complejidad del flujo de datos • medidas de código (v.g. Halstead) • medidas de la efectividad del proceso • v.g. eficiencia en remoción de defectos

22. Lineamientos sobre Métricas • Utilizar el sentido co´mún y la sensitividad organizacional al interpretar los datos de las métricas • Proveer retroalimentación regular a los individuos y equipos que han trabajado en recolectar medidas y métricas. • No utilizar las métricas para amedrentar a los individuos • Trabajar con los practicantes y equipos para establecer metas y métricas claras que serán utilizadas para medirlos • Nunca utilizar las métricas para amenazar a los individuos o equipos

23. Normalización de las métricas Los datos normalizados son utilizados para evaluar el proceso y el producto (pero nunca a los individuos) normalización orientada al tamaño —Por líneas de código normalización orientada a la función —Por puntos función

24. Métricas típicas orientadas al tamaño • Errores por KLOC (Miles de Líneas de Código) • Defectos por KLOC • $ por LOC • páginas de documentos por KLOC • errores / persona-mes • LOC / persona-mes • $ / página de documentación

25. Métricas Típicas Orientadas a Función • errores por FP (cientos de líneas de código) • defectos por FP • $ por FP • páginas de documentación por FP • determinar el tipo de proyecto • valorar el grado de rigor requerido • identificar el criterio de adapación • calcular el valor de Task Set Selector (TSS) • interpretar el TSS para determinar el grado de rigor • seleccionar las tareas de ingeniería de softwre apropiadas • FP por persona-mes

26. ¿Por qué la preferencia a FP? independencia del lenguaje de programación utiliza inmediatamente características contables del “dominio de información” del problema no “penalizar” implementaciones que requieren menos LOCs que otras (vs. mantenimiento) facilitan el reuso y favorecen a las iniciativas orientadas a objetos

27. Calcular Puntos Función Analizar el dominio de la información de la aplicaciòn y desarrollar el conteo Establecer el conteo para cada dominio de entrada e interfaces de sistema Pesar cada conteo por evaluación de la complejidad Asignar el nivel de complejidad o peso para cada conteo evaluar la influencia de factores globales que afecten la aplicación Grado de importancia de factores externos Fi tales como reuso, concurrencia, SO,... Puntos función =  (conteo x peso) x C Calcular puntos función donde: Factor de complejidad: C = (0.65 + 0.01 x N) Grado de influencia: N = Fi

28. Analizar el Dominio de la Información factor de ponderación conteo simple prom. complejo parámetro de medida # de entradas de usuario X 3 4 6 = # de salidas de usuario X 4 5 7 = # de consultas X 3 4 6 = # de archivos X 7 10 15 = # of interfaces ext. X 5 7 10 = conteo-total factor de complejidad puntos función

29. Considerar la Complejidad Los factores se tasan en una escala 0 (sin importancia) – 5 (muy importante) comunicaciones de datos funciones distribuidas configuración pesada tasa de transacción entrada de datos en lìnea eficiencia para el usuario actualización en línea procesamiento complejo facilidad de instalación facilidad operacional sites múltiples facilidad de cambios

30. Medición de la Calidad • Corrección – grado en el cual un programa opera conforme a las especificaciones • Mantenibilidad – grado en el que un programa es conveniente al cambio • Integridad – grado en el cual un programa permite el ataque externo • Usabilidad – grado en el cual un programa es fácil de usar

31. Eficiencia de Remoción de ErroresDefect Removal Efficiency DRE = (errores) / (errores + defectos) donde errores = problemas encontrados antes de la liberación defectos = problemas encontrados después de la liberación

32. 4.5Estimación de costos

33. Estimación de Costos el alcance del proyecto debe ser explícitamente definido la descomposición de tareas y/o funciones es necesaria las mediciones(métricas) históricas son de gran ayuda Por lo menos 2 diferentes técnicas debieran utilizarse recordar la falta de certidumbre inherente

34. Técnicas de Estimación • experiencia de proyectos pasados (similares) • técnicas de estimación convencional • división de tareas y estimación de esfuerzo • estimación de tamaño (v.g. FP) • herramientas (v.g., Checkpoint)

35. Descomposición Funcional descomposición funcional Declaración realizar un del Alcance “análisis gramatical"

36. Métodos Convencionales:LOC/FP • calcular LOC/FP utilizando estimaciones de valores del dominio de información • recurrir al esfuerzo histórico de proyectos

37. Ejemplo de LOC Costo LOC estim. LOC/pm $/LOC Effort (months) Funciones 315 UICF 2340 14 32,000 7.4 5380 2DGA 220 20 107,000 24.4 220 3DGA 6800 20 136,000 30.9 DSM 3350 240 18 60,000 13.9 CGDF 4950 200 22 109,000 24.7 2140 140 60,000 15.2 PCF 28 18 300 8400 151,000 28.0 DAM Totals 33,360 655,000 145.0

38. Ejemplo FP peso parámetro de medida counteo # entradas de usuario 160 x 4 = 40 # salidas de usuario 125 x 5 = 25 # de consultas 48 x 4 = 12 # de archivos 28 x 7 = 4 0.25 p-m / FP = 120 p-m # interfaces externas 28 x 7 = 4 algoritmos 180 x 3 = 60 569 conteo total factor de complejidad .84 478 puntos función

39. Estimación basada en herramientas características del proyecto factores de calibración datos de LOC/FP

40. Empirical Estimation Models Forma general: exponente esfuerzo = coefte_afinación * tamaño usualmente referido como personas-mes de esfuerzo requerido derivado empíricamente usualmente LOC pero pueden ser FPs constante o número derivado basado en la complejidad del proyecto

41. Lineamientos de Estimación estimar utilizando por lo menos 2 técnicas obtener estimaciones de fuentes independientes evitar el sobre-optimismo, asumir las dificultades si se ha llegado a una estimación, trabajar sobre ella ajustarse al personal que hará el trabajo – tienen el mayor impacto

42. $380,000 $380,000 $450,000 $450,000 $275,000 $275,000 $310,000 $310,000 $490,000 $490,000 $210,000 $210,000 $400,000 $400,000 $350,000 $350,000 $500,000 $500,000 Decisión de compra simple (0.30) construir difícil (0.70) cambios menores (0.40) reusar sistema X simple (0.20) cambios mayores (0.60) comprar complejo (0.80) cambios menores (0.70) Outsourcing cambios mayores (0.30) sin cambios (0.80) con cambios (0.40)

43. Cálculo del Costo Esperado costo esperado=  (RutaProbabilidad)i x (CostoRutaEstim) i Por ejemplo, el costo esperado para ‘construir’ costo esperadoconstruir = 0.30($380K)+0.70($450K) = $429 K en forma similar, costo esperadoreuso = $382K costo esperadocomprar = $267K costo esperadooutsrc = $410K

44. 4.6 Evaluación de Riesgos

45. Construir una Tabla de Riesgos Riesgo Probabilidad Impacto RMMM (Risk Mitigation Monitoring & Management) (Admón. y Monitoreo de la Mitigación de Riesgos)

46. Construir la Tabla de Riesgos • Estimar la probabilidad de ocurrencia • Estimar el impact sobre el proyecto en una escala del 1 al 5, donde • 1 = bajo impacto sobre el éxito del proyecto • 5 = impacto catastrófico sobre el éxito del proyecto • ordenar la tabla por probabilidad e impacto

47. Administración, Monitoreoy Mitigación de Riesgos • mitigación • ¿Cómo se puede evitar el riesgo? • monitoreo • ¿Qué factores podemos vigialar que nos permitan ser capaces de determinar si el riesgo es más o menos probable? • administración • ¿con qué planes de contigencia contamos si el riesgo se vuelve realidad?

48. Riesgos Asociados al Tamaño del Producto Atributos que afectan al riesgo: •¿tamaño estimado del proyecto en LOC o FP? •¿tamaño estimado del proyecto en número de programas, archivos, transacciones? • ¿porcentaje de desviación en el tamaño del producto del promedio de los productos anteriores? • ¿tamaño de las bases de datos creadas o utilizadas por el producto? • ¿número de usuarios del producto? • ¿número de cambios proyectados a los requerimientos del proyecto?¿antes de la entrega? ¿después de la entrega? • ¿cantidad de software reusado?

49. Riesgos Asociados al Impacto del Negocio Atributos que afectan al riesgo: • ¿afectación de este producto en las utilidades de la empresa? • ¿visibilidad de este producto por la alta gerencia? • ¿razonabilidad del tiempo de entrega? • ¿número de clientes que utilizarán este producto? • restricciones de interoperabilidad • ¿sofisticación de los usuarios finales? • ¿cantidad y calidad de documentación del producto que debe ser producida y enviada al cliente? • restricciones gubernamentales • ¿costos de entregar tarde el producto? • ¿costos asociados con un producto defectuoso?

50. Riesgos Asociados al Cliente Cuestionamientos que deben ser resueltos: • ¿se ha trabajado con ese cliente en el pasado? • ¿el cliente tiene una idea sólida de lo que requiere? • ¿el cliente está de acuerdo en trabajar contigo? • ¿el cliente participaría en las revisiones? • ¿el cliente es técnicamente sofisticado? • ¿el cliente permitiría el poder hacer el trabajo – esto es, el cliente resistiría observar sobre tus hombros durante el trabajo técnico detallado? • ¿el cliente entiende el proceso de ingeniería de software?