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

Contenido Plan del Proyecto 4.1 Objetivo 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.

4.1 Objetivo de la planeación

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!

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?

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

4.2 Programa de actividades

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

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

Utilizar herramientas automatizadas para 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

4.3 Factores de costos de desarrollo de software.

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

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

¿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 1 0.75 Diseño prueba uso en campo Req. código pruebas de sistema

4.4 Métricas de procesos de desarrollo de software.

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

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

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?

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

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

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

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

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

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

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

¿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

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

Analizar el Dominio de la Información factor de ponderación parámetro de medida conteo simple prom. complejo # 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

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

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

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

4.5 Estimación de costos

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

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)

Descomposición Funcional Declaración realizar un del Alcance “análisis gramatical"

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

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

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

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

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

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

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

Cálculo del 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

4.6 Evaluación de Riesgos

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

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

Administración, Monitoreo y Mitigación de Riesgos ¿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?

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?

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?

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?

Riesgos Asociados a la Madurez del Proceso Cuestionamientos que deben ser resueltos: • ¿has establecido un framework de proceso común? • ¿lo siguen los equipos de proyecto? • ¿tienes soporte de administración para la ingeniería de software? • ¿realizas proactivamente el SQA? • ¿realizas las reuniones técnicas formales? • ¿se utilizan herramientas CASE para el análisis, diseño y pruebas? • ¿están las herramientas integradas con alguna otra? • ¿se han establecido formatos de documentos?

Riesgos de Tecnología Cuestiones que deben ser resueltas: • ¿la tecnología es nueva en tu organización? • ¿se requieren nuevos algoritmos, tecnologías de E/S? • ¿se involucra hardware nuevo o sin probar? • ¿se interfaza la aplicación con un nuevo software? • ¿se requiere una interfaz de usuario especializada? • ¿la aplicación es radicalmente diferente? • ¿estás utilizando nuevos métodos de ingeniería de Sw? • ¿estás utilizando métodos de desarrollo de software no convencionales, tales como métodos formales, inteligencia artificial, redes neuronales, etc? • ¿hay restricciones de desempeño significativo? • ¿existe la duda si la funcionalidad requerida es realizable?

Riesgos Asociados a las Personas Cuestionamientos que deben ser resueltos: • ¿está disponible el mejor personal? • ¿el staff tiene las habilidades adecuadas? • ¿hay suficiente personal disponible? • ¿existe el compromiso completo? • ¿habrá gente que trabaje parcialmente? • ¿el staff tiene las expectativas adecuadas? • ¿el staff tiene el suficiente entrenamiento? • ¿podría la respuesta del staff ser baja?

Registro de la Información de Riesgo Projecto: Software Incrustado para el Sistema XYZ Tipo de Riesgo: Riesgo de Calendarización Prioridad (1 bajo ... 5 critico): 4 Factor de Riesgo: El término del proyecto dependerá de las pruebas, las cuales requieren de componentes de hardware que están bajo desarrollo. Los componentes de hardware pueden ser entregados tarde. Probabilidad: 60 % Impacto: El término de proyecto puede retrasarse por cada día que el hardware no esté disponible para uso de las pruebas de software Técnica de monitoreo: Revisiones de hitos calendarizados con el grupo de hardware Plan de Contingencia: Modificación de la estrategia de pruebas para soportar el retraso usando simulación de software Recursos Estimados: 6 personas-mes a partir del 7/Mar/2002

4.7 Plan de Aseguramiento de la Calidad del Software

Aseguramiento de la Calidad del Software Software Quality Assurance SQA Definición y Estándares de Proceso Revisiones Técnias Formales Análisis y Reporteo Planeación y Revisión de Pruebas Métrica

Plan de Aseguramiento de Calidad El objetivo principal es establecer los lineamientos para implementar el Aseguramiento de Calidad de Software en el ciclo de vida para cada elemento del software. Proporcionar un método para asignar el Nivel de Calidad al software controlado por el plan.

Contenido de un Programa de Aseguramiento de Calidad de Software (IEEE Std. 730) 1.   Propósito. Esta sección especifica la intención y alcance del Programa de Aseguramiento de Calidad. Establece la porción del Ciclo de Vida de Software cubierto por el programa para cada elemento de software. 2.     Documentos de Referencia. Lista completa de documentos referenciados en el texto del Programa. 3.     Administración. Describe la organización, tareas y responsabilidades. 4.     Documentación. Se identifican los documentos para el desarrollo, verificación y validación, uso y mantenimiento de el software. Esto incluirá los criterios e identificación de las revisiones o auditorias. 5.     Normas, prácticas, convenios y medidas. Aquí se identifican los reuqerimientos mandatorios, practicas recomendadasguias aceptadas y sistemas de medida que se emplearán por todos los relacionados con el proyecto, incluyendo a vendedores. 6.     Revisiones y Auditorias. Aquí se definirán las revisiones y auditorias técnicas y administrativas que serán llevadas a cabo conforme a los procedimientos existentes. 7.     Pruebas.

REQUISITOS DOCUMENTALES DE ACUERDO AL NIVEL DE CALIDAD Documentación NIVEL DE CALIDAD A B C D   Clasificación del software R Especificación de Requerimientos de Software Descripción de Diseño de Software S Código Fuente y Documentación del Programa Plan de Verificación y Validación de Software Reporte de Verificación y Validación Documentación para el Usuario Plan de Administración de la Configuración R - Requerido S - Sugerido (Justificar sino se proporciona)

RETENCIÓN DE REGISTROS LUGAR NIVEL DE CALIDAD “A” “B” “C” “D” Bóveda de Documentos X Archivo Teleinformática y Planeación   TIEMPO Vida de la Planta Vida de uso del software Aplicación

4.8 Administración de la Configuración del Software

¿Cuáles son estos Cambios? Cambios en los requerimientos de negocio Cambios en los requerimientos técnicos Cambios en los requerimientos del usuario otros docuementos modelos de Sw Plan de Proyecto datos Prueba código

Configuración de Software programas documentos Las piezas datos

Proceso de Control de Cambios—I la necesidad del cambios es reconocida requerimiento del cambio del usuario el desarrollador evalúa reporte de cambio es generado la autoridad de control de cambios decide el requerimiento es encolado para la acción el requerimiento de cambio es denegado. Se informa al Usuario Proceso de Control de Cambios—II

Proceso de Control de Cambios-II asignar personal a los SCIs checar salida a los SCIs realizar los cambios revisar/auditar los cambios establecer una “línea de fondo” para pruebas Proceso de Control de Cambios—III

Proceso de Control de Cambios-III realizar actividades de SQA y pruebas checar la entrada de los SCIs cambiados promover SCI para la inclusión en siguientes liberaciones reconstruir la versión apropiada revisar/auditar los cambios incluir todos los cambios en la liberación

PLAN DE ADMINISTRACION DE LA CONFIGURACION   1.                   Introducción 1.1              Propósito del Plan 1.2              Alcance 1.3              Definiciones 1.4              Referencias 2.                  Administración 2.1              Organización 2.2              Responsabilidades 2.3              Procedimientos, Directivas y Políticas 3.                  Actividades 3.1              Identificación de la configuración 3.1.1        Identificación de elementos de configuración 3.1.2        Asignación de nombres a elementos de configuración 3.1.3        Obtención de elementos de configuración 3.2              Control de Configuración 3.2.1        Solicitud de cambios 3.2.2        Evaluación de cambios 3.2.3        Aprobación/Rechazo de cambios 3.2.4        Implementación de cambios 3.3              Estado de la configuración 3.4              Auditorias y revisiones 3.5              Control de interfaces 3.6              Control de Vendedores/Subcontratistas 4.                  Planes, Programas 5.                  Recursos