Contenido INGENIERIA DE SOFTWARE Tema 2: Administración de proyectos de software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx IEC 37 1 1. Administración de proyectos de software 2. Gráficas PERT y GANTT 3. Métricas del proyecto 4. Mediciones del software 5. Métricas orientadas al tamaño (LDC) 6. Modelo de Estimación de Costos COCOMO 7. Métricas orientadas a los puntos de función 8. Análisis de riesgos 9. Conclusiones 10. Referencias 2 1. Administración de proyectos La administración de proyectos consiste en gestionar la producción de un producto dentro del tiempo dado y los límites de fondos. Requiere recursos humanos Involucra no sólo la organización técnica y las habilidades organizacionales, sino también el arte de administrar personas. Lo que puede controlar el administrador de proyectos (Variables de la admon de proyectos) El costo total del proyecto Por ejemplo, aumentar los gastos Las capacidades del producto Como eliminar una lista de características La calidad del producto Como aumentar el tiempo medio entre fallas La duración del proyecto Por ejemplo, reducir el tiempo programado 20% O posponer un mes la fecha de terminación Componentes de la administración de proyectos Estructura (elementos organizacionales involucrados) Proceso administrativo (responsabilidades y supervisión de los participantes) Proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo) Programa (tiempos en los que deben realizarse las porciones del trabajo) Mapa Conceptual típico para la administración de un proyecto 1. Comprender el contenido, alcance y marco del tiempo del proyecto 2. Identificar el proceso de desarrollo (modelos, métodos, herramientas, lenguajes, documentación y apoyo) 3. Determinar la estructura organizacional (elementos organizacionales involucrados) 4. Identificar el proceso administrativo (responsabilidades de los participantes) 5. Desarrollar una programación (tiempos en los que deben realizarse las porciones del trabajo) 6. Desarrollar el plan de personal TSP, PSP, CMM, MOPROSOFT 7. Iniciar la administración de riesgo 8. Identificar los documentos que se producirán 9. Iniciar el proceso
Planeación de proyectos Se refiere a la identificación de actividades, hitos y entregas producidas por un proyecto Para eso, se requiere un plan del proyecto: fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo El plan del proyecto, puede contener otros tipos de planes Plan de calidad Plan de validación Plan de administración de la configuración Plan de mantenimiento Plan de desarrollo del personal Herramientas para la planeación de proyectos: PERT, GANTT. 2. Gráficas PERT y GANTT Siempre hay plazos, algunos más ajustados y otros mas holgados. Son exigibles. Responden a compromisos (verbales o escritos) cómo enfrentarlos? Buena estimación de tiempo, esfuerzo y costos. Especialmente Ruta Crítica. Se recomienda uso de modelos incrementales. Conversarlos con el Jefe (lograr un acuerdo) y luego con el usuario(s)/cliente lograr un consenso). Afinar la planificación. Comunicarla : que todos los involucrados la conozcan 7 8 Gráficas PERT y GANTT Calidad v/s plazos Origen de los retrasos Compromisos poco realistas (presiones). Cambios de requisitos. Subestimación de esfuerzos y/o recursos requeridos. Errores predecibles e impredecibles no considerados en la planificación. Dificultades técnicas imprevistas. Dificultades humanas imprevistas. Falta de comunicación dentro del equipo del proyecto. Subestimar los retrasos y no administrar medidas correctivas 9 Principios básicos Compartimentación: El proyecto debe dividirse en un número de actividades y tareas manejables. Interdependencia: Cómo dependen unas tareas de otras para su ejecución? Asignación de tiempo: a cada tarea. Ej. Personas-día de esfuerzo Validación del esfuerzo: Verificar que no se ha asignado más horas de trabajo que las disponibles. Responsabilidades definidas: Cada tarea que se programe debe asignarse a un miembro del equipo específico. Resultados definidos: Cada tarea programada debe tener un resultado definido. Hitos definidos: Momentos de control global o por módulo. 10 Camino Crítico Gráficas de barras (GANTT) y redes de actividades (PERT). Es la secuencia de tareas cuyo atraso provoca atrasos en el fin del proyecto Las herramientas lo calculan automáticamente (grafos PERT y Gantt) Una tarea no crítica tiene un margen de tiempo a partir del cual se convierte en crítica Por lo tanto: El mayor esfuerzo de la estimación debe ser en las tareas críticas Para comprimir tareas en el cronograma, debe comenzar el análisis por las tareas críticas Se utilizan notaciones gráficas para ilustrar la planificación del proyecto. Muestra la partición del proyecto en tareas. Las tareas no deben ser muy pequeñas. Estas deben de tener una duración de una semana o dos. Las gráficas de actividades muestran las dependencias entre tareas y la ruta crítica. Las gráficas de barras muestran la planificación contra el tiempo del calendario de actividades. 11 12
Diagramas GANTT Técnica de control de proyectos, que puede ser utilizada para Scheduling y Plan de recursos Cada barra representa una actividad Se dibujan contra una línea de tiempo La longitud de cada barra representa la longitud de tiempo de esa actividad A las tareas se le puede asignar los recursos Diagramas GANTT Pueden ser derivados automáticamente de los grafos PERT Los GANTT ayudan a planear la utilización de recursos 13 14 15 16 Grafos PERT Program Evaluation and Review Technique Grafo dirigido etiquetado Los nodos representan actividades y los ejes dependencias Los nodos pueden tener varios tipos de información Nombre, fecha de inicio y finalización Algunos nodos pueden ser definidos como milestones (hitos, puntos de control) 17 Grafos PERT Que se puede calcular? Fecha más temprana y tardía de comienzo Fecha más temprana y tardía de finalización Se puede determinar el camino crítico de un proyecto Ventajas de los grafos PERT Fuerza al líder del proyecto a planear (debe definir que tareas son necesarias) Expone claramente las actividades críticas del proyecto Expone paralelismo de tareas y por lo tanto ayuda a la asignación de recursos Permite al líder del proyecto a monitorear y controlar el proyecto Los PERT son mejores para monitorear el progreso y el retraso de las actividades 18
Ejemplo 1. PERT Ej 2. PERT 19 20 21 22 Hitos en el proceso de requerimientos 23 24
3. Introducción Métricas Medición proceso por el cual números ó símbolos son asignados a atributos de entidades en el mundo real, de manera semejante como se les atribuye reglas definidas 3. Introducción Métricas Métricas son estándares (i.e., escalas comunmente aceptadas) que definen atributos medibles de entidades, sus unidades y sus alcances Medida es una relación entre un atributo y una escala de medición 3. Introducción Métricas Las métricas de software son medidas que se usan para cuantificar el software, los recursos del desarrollo de software, y/o el proceso de desarrollo de software. Esto incluye elementos que son medibles de forma directa, tal como las líneas de código, así como también elementos que son calculados de mediciones, tal como la calidad del software. Métricas del proceso Se puede aplicar al proceso con la intención de mejorarlo La eficacia de un proceso de sw se mide indirectamente. Se extrae un conjunto de métricas de los resultados que provienen del proceso Errores detectados antes de la entrega del sw Defectos detectados e informados por los usuarios finales Productos de trabajo entregados Esfuerzo humano y tiempo consumido Métricas del proceso PSP, TSP, CMM, MOPROSOFT Las métricas del proceso de software se utilizan para propósitos estratégicos Métricas del proyecto En el proyecto se puede aplicar para ayudar a: Estimar costos Control de calidad Evaluación de productividad Control de proyectos Finalmente para evaluar la calidad de productos técnicos para ayudar en la toma de decisiones tácticas a medida que el proyecto evoluciona.
Métricas del proyecto Las métricas del proyecto son tácticas Esto es, las métricas de proyectos y los indicadores derivados de ellos los utiliza un gestor de proyectos y un equipo de sw para adaptar el flujo de trabajo del proyecto y las actividades técnicas La primera aplicación de las métricas de proyectos de sw ocurre durante la estimación, para esto se utilizan las métricas de proyectos anteriores Estimaciones del esfuerzo y del tiempo para el trabajo actual Métricas del proyecto Durante el trabajo técnico, se tienen otras métricas Índices de producción: páginas de documentación, horas de revisión, puntos de función y líneas fuentes entregadas Las métricas para el proyecto se utilizan para: Minimizar la planificación de desarrollo Evaluar la calidad de los productos en el momento actual 31 Porqué usar métricas? Sin mediciones no hay forma de determinar si el proceso esta mejorando. Las métricas permiten el establecimiento de metas significativas para la mejora. Se puede establecer una línea de inicio de la cual las mejoras pueden ser medidas Las métricas permiten identificar las causas de defectos que tienen mayores efectos en el desarrollo de software Cuando se aplican métricas a un producto pueden ayudar a identificar: Que requerimientos del usuario son probables de cambiar Que módulos son más propensos a errores Cuanta prueba debería ser planeada para cada modulo Quienes se benefician de las métricas? Administradores Que cuesta cada proceso? Que tan productivo es el personal? Que tan bueno es el código que esta siendo desarrollado? Estará satisfecho el usuario con el producto? Como podemos mejorarlo? Ingenieros Son comprobables los requerimientos? Se han encontrado todas las fallas? Conocemos las metas del producto o proceso? Que podemos predecir de nuestro producto software en el futuro? 4. Medición Directa e Indirecta La medición directa de un atributo de una entidad no involucra otros atributos o entidades La medición indirecta es útil en hacer visible la interacción entre mediciones directas La medición indirecta es favorable cuando el tamaño de medidas empíricas es bastante grande (i.e., muchas relaciones y muchas entidades) 35 36
Métricas simples orientadas al tamaño Errores por KLDC (miles de líneas de código) Defectos por KLDC Páginas de doc. Por KLDC Errores/persona-mes LDC/persona mes 5. Tamaño del software Uno de los atributos más útiles es el tamaño de un producto software, que puede ser medido estáticamente, i.e., sin ejecutar el sistema Es necesario definir el tamaño del sw., en términos de más de un atributo interno, que cada uno capture un aspecto clave del tamaño del sw. La medición del tamaño debe reflejar esfuerzo, costo y productividad. 38 Tamaño del software El tamaño del sw., puede ser descrito por la longitud, funcionalidad y complejidad. Longitud es el tamaño físico del producto. Funcionalidad es una medida de las funciones suministradas al producto Complejidad es un atributo que puede ser interpretado de muchas maneras Reuso también es un atributo que tiene que ver con el tamaño, específicamente la cantidad o tamaño de reuso dentro de un programa Tamaño del sw.: Longitud En el desarrollo de sw., hay tres productos principales de desarrollo: especificación, diseño y codificación La longitud de la especificación puede indicar cuánto tiempo se necesita para que se realice el diseño, qué a su vez es un predictor de longitud del código. Tradicionalmente, la longitud de código se refiere a la longitud de código basado en texto. 39 40 Longitud: Código-LOC La medida más comúnmente usada de la longitud del programa fuente es el número de líneas de código (LOC) NCLOC CLOC Longitud total: (LOC) = NCLOC + CLOC Longitud: Problemas - Código Conforme el desarrollo de software utiliza más herramientas automatizadas, la medición de líneas de código es cada vez menos significativa Herramientas que generan código a partir de especificaciones Herramientas de programación visual Cual puede ser la medida de longitud para objetos que no son textuales? Como puede uno contar componentes que son construidos externamente? (librerías, repositorios, funciones heredadas, patrones de diseño, etc.) 41 42
Longitud: Problemas - Código La medición del tamaño LOC necesita ser reemplazada por otras medidas tales como: Puntos de objetos (usados en COCOMO 2.0) Medir la longitud tomando en cuenta la porción de código reutilizado Resumen: Tamaño del Software Las métricas orientadas al tamaño son medidas directas del software. Esas métricas incluyen esfuerzo (personas-tiempo), dinero gastado, LOC, # de páginas de documentos creados, errores y número de personal La medida básica para la longitud es LOC. Las métricas simples orientadas al tamaño pueden ser generadas de LOC como sigue: Productividad = KLOC/persona-mes Calidad = defectos/kloc Documentación = páginas de documentos / KLOC 43 44 6. Modelo de estimación de costos COCOMO COCOMO (Constructive Cost Model) (Boehm, 1981): Es un modelo que se basa en entradas que relacionan al tamaño del sistema y un número de conductores de costo que afectan la productividad COCOMO II, la versión actualizada, considera cambios en la tecnología de ingeniería de sw, incluyendo sw OO, sw creado vía modelos de desarrollo evolutivos o espiral, reuso de sw y nuevas construcciones de sistemas usando componentes sw del estante (COTS-Commercial off the shelf) Modelos del COCOMO Modelo básico. Se aplica cuando se conoce poco del proyecto. El esfuerzo (persona-mes) se calcula en función del tamaño del programa (KLOC) Modelo intermedio. Se aplica después de la adquisición de requerimientos. Calcula el esfuerzo como una función del tamaño del programa y un conjunto de conductores de costo (para el producto, hw, personal y proyecto) Modelo avanzado. Se aplica después de que el diseño es completado. Calcula el esfuerzo en función del tamaño del programa y un conjunto de conductores de costo valorados en cada fase del ciclo de vida del software. 45 46 Tipos de proyectos del COCOMO Modo orgánico: involucra procesamiento de datos, tiende a usar base de datos y se centra en operaciones y recuperación de datos. Ej. Sistemas de contabilidad o bancarios Modo empotrado: Contiene sw de tiempo real, que es parte integral de sistemas grandes, basados en hw. Ej. sistema de misiles guiados, sw de control de navegación para un avión. Modo semi-acoplado: Algún sistema entre orgánico y empotrado. Ej. Un sistema de procesamiento de transacciones con requisitos fijos para un hw de terminal, un sw de gestión de base de datos. 47 Fórmula para los tres modelos COCOMO Donde: b E = as F T = ce E es el esfuerzo en persona-mes T es el tiempo de desarrollo S es el tamaño medido en KLOC F es el factor de ajuste del esfuerzo (1 en el modelo básico) Los factores a, b dependen del tipo de modelo de COCOMO, y los factores c y d dependen del tipo de proyecto d 48
COCOMO: Básico El factor de ajuste del esfuerzo (F) vale 1 en este modelo Valores de los factores a, b, c y d COCOMO: Intermedio El factor de ajuste del esfuerzo (F) se calcula usando 15 conductores de costo Valores de los factores a, b, c y d Modo a b c d Orgánico 2.4 1.05 2.5 0.38 Semi-acoplado 3.0 1.12 2.5 0.35 Empotrado 3.6 1.20 2.5 0.32 Modo a b c d Orgánico 3.2 1.05 2.5 0.38 Semi-acoplado 3.0 1.12 2.5 0.35 Empotrado 2.8 1.20 2.5 0.32 49 50 COCOMO: Intermedio Conductores de costos Conductores de costo: atributos del producto, del hardware, del personal y del proyecto Cada conductor de costo es valorado en una escala ordinal de 0-5: very low, low, nominal, high, h very high h y extra high. h Basado en la valoración, se determina el multiplicador de esfuerzo (ME) a partir de las tablas publicadas por Boehm, 1981. El producto de todos los multiplicadores de esfuerzo es (F) 15 F = i = 1 ME i 51 Atributos del producto RELY Required software reliability DATA Database size CPLX Product complexity Atributos del hardware TIME Execution time constraint STOR Main store constraint VIRT Virtual machine volatility TURN Computer turnaround time 52 Conductores de costos Atributos del personal ACAP Analyst capability AEXP Applications experience PCAP Programmer capability VEXP Virtual Machine experience LEXP Language experience Atributos del proyecto MODP Modern programming practices TOOL Software tools SCED Development schedule 53 54
55 56 COCOMO: Avanzado Las 4 fases usadas en el modelo detallado de COCOMO son: planeación de requerimiento y diseño del producto (RDP), diseño detallado (DD), pruebas de código y por unidad (CUT), e integración y pruebas (IT) Cada conductor de costo se descompone por cada fase como se ve en la tabla La estimación realizada para cada módulo se combinan en subsistemas y eventualmente se estima todo el proyecto Conductor de costo valor RDP DD CUT IT ACAP(Analyst Capability) very Low 1.80 1.35 1.35 1.50 low 0.85 0.85 0.85 1.20 Nominal 1.00 1.00 1.00 1.00 High 0.75 0.90 0.90 0.85 Very High 0.55 0.75 0.75 0.70 57 Ejemplo Para predecir el esfuerzo requerido para implementar el sw para un mejor sistema de conmutación telefónica, se ha determinado que el sistema requerirá 5000 KLOC. El software es empotrado, dado que es un sistema de tiempo real, que es parte de un gran sistema hw complejo. Determine el esfuerzo y la duración utilizando COCOMO, así como, el número de personas en el total del tiempo de desarrollo. 58 7. Métricas orientadas a la función La funcionalidad es otro atributo del tamaño del sw. La idea es que un producto con más funcionalidad será más grande en tamaño. Estas métricas son medidas indirectas del sw., que se centran en la funcionalidad y la utilidad Las 1er Métrica orientada a la función fue propuesta por Albrecht (1979 1983) quien sugirió una aproximación a la medición de la productividad llamado el método de Punto de Función (FP) Los puntos de función (FPs) miden la cantidad de funcionalidad en un sistema basado en la especificación del sistema Estimación antes de la implementación 59 60
Punto de Función (FP) /1 Se componen de medidas directas denominadas puntos de función, tales como : External Inputs (Entradas externas) External Outputs (Salidas externas) External Inquiry (Consultas externas) Internal Logical File (Archivo lógico interno) External Interface File (Archivo de interfase externa) 61 62 Punto de Función (FP) /2 Los Puntos de Función se calcula en dos pasos: Cálculo de los Puntos de Función Sin Ajustar(UFC, Unadjusted Function point Count) Cálculo del Factor Técnico de Complejidad(TCF, Technical Complexity Factor) El punto de función final (ajustado) es: Conteo de FP Sin ajustar (UFC) Se listan todos los tipos de función encontrados en el sistema Se le asigna a cada tipo de función una complejidad(baja, media o alta), con su correspondiente valor en puntos de función. Se suman todos los puntos de función, dando como resultado los puntos de función sin ajustar. FP=UFC*TCF 63 64 Ej. Resultados de los puntos de función sin ajustar Internal Logical Files Selected Parts File low 7 Selected Parts Table low 7 External Interface File Parts Master File low 5 External Inquiries Parts Description low 3 Parts Inventory low 3 External Outputs Parts Inventory Report avg 5 Control Report avg 5 Control Report Summary low 4 External Inputs Add Part low 3 Remove Part low 3 Create Selected Parts File high 6 Total 51 65 Valores de los puntos de función Ej. si todas la funciones tienen complejidad media tendremos: UFC = 4*T_EI+5*T_EO+4*T_EQ+10*T_EIF+7*T_ILF 66
Complejidad Determinado por: Data Element Types (DETs) Record Element Types (RETs) Data Element Types (DET's) Los DET's son campos que no se repiten, reconocibles por el usuario, contenidos en el ILF Ej. Los campos físicamente almacenados en campos múltiples (como números de cuenta, fechas, hora) deberían ser contados como un campo cuando el usuario se refiere a ellos como un elemento. 67 68 Componente funcional EI El conteo se hace para las siguientes categorías, como procesos elementales: External Inputs (EI): Los datos cruzan los límites de afuera hacia adentro. Estos datos pueden venir de una pantalla de entrada o de otra aplicación. Los datos son usados para mantener uno o más archivos lógico internos (ILF s). Los datos pueden ser datos orientados a la aplicación ó información de control. Si los datos son info. de control, no se tiene que actualizar un ILF Ejemplos EI s 69 Ejemplos EI s Ejemplo: External Input Sistema de Inventario A/B/C Parte: Descripción: Origen: Cantidad: Precio: Colocación: Mensaje inventario auditoria 72
Ejemplos EI s Matriz de Entradas de Usuario 74 Conteo de External Input Contar todos los elementos de datos únicos o archivos lógicos usados. No incluir números de páginas, literales o encabezados de columnas en la cuenta de elementos de datos. Contar un solo DET para todos los campos que muestren mensajes de error (o mensajes de confirmación), campos de control o almacenamiento multiple del mismo campo de datos. El conteo de los puntos de función es una medida estadística. Se basa en un gran número de observaciones diferentes. Componente funcional EO External Outputs (EO): Los datos derivados cruzan los límites de adentro hacia fuera. Los datos crean reportes o archivos de salida enviados a otras aplicaciones. Estos reportes y archivos son creados de uno o mas ILF s o archivos de interfase externos (EIF s) s). Los datos derivados son datos que son procesados más allá de la edición directa de información de ILF s. Los datos derivados son usualmente el resultado de algoritmos o cálculos. Los datos derivados ocurren cuando uno o más elementos de datos son combinados con una fórmula para generar o derivar elementos de datos adicionales 75 Ejemplos EO s Ejemplos EO s
Ejemplo: External Ouput Análisis de la EO anterior. empleados Impuestos seguros tarifas ahorros Un reporte típico de nómina accedería a mas de 3 archivos de negocios (archivo de empleados, de tasas, de seguros, de ahorros, de tarifas de salarios). El total para los campos tasas, seguros, pago bruto, pago neto ya determina que el tipo de función es una EO. La EO tendría 15 DET's ymásde3ret's, s, por tanto se clasifica como complejidad high. Los DET's incluirían todas las 8 columnas. Adicionalmente, el total de una columna se cuenta como un DET separado. Además la fecha y el campo departamento se incluirían en el conteo de los DET's. Sin embargo el número de página no se contaría como un DET separado. Los diferentes formatos de impresión causados por las diferentes características de las impresoras no se contarían como EO's separadas. 79 80 Matriz de Salidas de Usuario Componente funcional EQ External Inquiry (EQ): Todas las combinaciones de entradas/salidas que resultan de la adquisición de datos de uno o más ILF s o EIF s. El proceso de entrada no actualiza ningún ILF, y el proceso de salida no contiene datos derivados. Nota: los campos totales de un DET son contados como un único DET de su propio campo. Esta interpretación está bajo Debate. 81 Ejemplos EQ Ejemplos EQ
Ejemplo: Consulta simple Ejemplo: Consulta compleja 85 86 Complejidad EQ Determinar la complejidad del lado de entrada EI Determinar la complejidad del lado de salida EO La complejidad de EQ es la más alta de las dos Ejemplo Lado EI low Lado EO average EQ average Matriz de Entradas de Usuario 87 88 Matriz de Salidas de Usuario Punto de Función (FP) /4 El conteo se hace para las siguientes categorías: Internal Logical File (ILF) : Un ILF es un grupo de datos definidos por el usuario que están relacionados lógicamente, que residen en su totalidad dentro de los límites de la aplicación y que son actualizados a través de entradas externas. External Interface File (EIF): Un EIF es un grupo de datos definidos por el usuario que están relacionados lógicamente y que solo son usados para propósitos de referencia. Los datos residen enteramente fuera de la aplicación y son mantenidos por otra aplicación. Este archivo(s) es un ILF para otra aplicación Nota: los campos totales de un DET son contados como un único DET de su propio campo. Esta interpretación está bajo Debate. 89 90
Complejidad ILF y EIF En la práctica sin embargo, las mayoría de ILFs tendrán solo un tipo de RET y menos de 50 DETs. Record Element Type (RET) Subgrupo de elementos de datos en ILF Reconocibles por el usuario Ningún proceso elemental propio Tipos Obligatorio Opcional Contar 1 RET por subgrupo Por tal razón, las reglas de conteo NEFPUG han reducido la matriz de complejidad ILF al primer renglón. 91 92 Ejemplo FP: Ejemplo /1 Espec., de un corrector ortográfico: El corrector acepta como entrada un archivo con el documento y un archivo del diccionario personal opcional. El corrector, lista todas las palabras que no están contenidas en alguno de los archivos. El usuario puede consultar el número de palabras procesadas y el número de errores ortográficos encontrados en alguna etapa durante el procesamiento. 93 94 Especificación de un Corrector Ortográfico 95 FP: Ejemplo /1(cont...) Ni=2 (EI): nombre del archivo del documento, nombre del diccionario personal No=3 (EO): reporte de palabras incorrectas, número de palabras procesadas en el mensaje, número de errores en el mensaje Nq=2 (EQ): palabras procesadas, errores encontrados Nef=2 (EIF): archivo del documento, diccionario personal Nif=1 (ILF): diccionario UFC=4x2+5x3+4x2+10x2+7x1=58 Suponer que: F1=F2=F6=F7=F8=F14=3; F4=F10=5 y el resto son cero. TCF=0.65+0.01(18+10)=0.93 FP=58x0.93 54
Factores técnicos de Complejidad TCF es una suma de pesos de 14 componentes: F1 Comunicación de los datos F2 Procesamiento distribuido F3 Rendimiento F4 Configuración del equipo F5 Volumen de transacciones F6 Entrada de datos On-line F7 interfase con el usuario F8 Actualización On-line F9 Procesamiento complejo F10 Reusabilidad F11 Facilidad de Instalación F12 Facilidad operacional F13 Multiples sitios F14 Facilidad de cambios Factores técnicos de Complejidad Cada componente tiene un rango de 0-5 0 = No influencia 1 = Incidental (poco, accidental) 2 = Moderado 3 = Medio 4 = Significativo 5 = Esencial El TCF puede ser calculado como: 14 TCF = 0.65 + 0.01 Fj j= 1 97 EL TCF varía de 0.65 (si todos los F j son asignados a cero) a 1.35 (si todos los F j son asignados a 5) 98 Factores técnicos de Complejidad 1. Comunicación de datos Cuántas herramientas de comunicación hay para ayudar en la transferencia o intercambio de información de la aplicación o sistema? 2. Procesamiento de datos distribuidos Cómo son manejados los datos distribuidos y las funciones de procesamiento? 3. Nivel de ejecución El tiempo de respuesta o el nivel de eficiencia es requerido por el usuario? 4. Configuración más usada Qué tanto se usa la plataforma de hardware en donde la aplicación se va a ejecutar? 5. Nivel de transacciones Qué tan frecuentemente se ejecutan las transacciones al día, semana, mes, etc.? 99 Factores técnicos de Complejidad 6. Captura de datos En Línea Qué porcentaje de información se captura En Línea? 7. Eficiencia del usuario final Se diseñó la aplicación pensando en la eficiencia del usuario final? 8. Actualización En Línea Cuántos ILF s se actualizan en transacciones En Línea? 9. Procesamiento complejo La aplicación tiene mucho procesamiento lógico o matemático? 10. Reusabilidad La aplicación se desarrolló para cumplir una o muchas necesidades del usuario? 100 Factores Técnicos de Complejidad 11. Facilidad de Instalación Qué tan difíciles son la conversión y la instalación? 12. Facilidad de Operación Qué tan efectivos y/o automatizados son los procedimientos de inicio, respaldo y recuperación? 13. Múltiples Sitios La aplicación se diseñó, desarrolló y soportó específicamente para ser instalada en múltiples sitios para varias organizaciones? 14. Facilidad de mantenimiento La aplicación se diseñó, desarrolló y soportó específicamente para facilitar el mantenimiento? 8. Análisis de Riesgos Una tarea importante del administrador de proyectos es anticipar los riesgos que podrían afectar la programación del proyecto o la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Los resultados del análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificarlos y crear planes para minimizarlos, se le llama administración de riesgos.
Manejo de Riesgos La tarea principal del administrador consiste en minimizar riesgos. El riesgo inherente en una actividad se mide en base a la incertidumbre que presenta el resultado de esa actividad. Las actividades con alto riesgo causan sobre-costes en cuanto a planeación y costos El riesgo es proporcional al monto de la calidad de la información disponible. Cuanto menos información, mayor el riesgo. Categorías de Riesgos RIESGOS DEL PROYECTO. Afectan la calendarización o los recursos del proyecto. RIESGOS DEL PRODUCTO: Afectan la calidad o desempeño del software que se está desarrollando. RIESGOS DEL NEGOCIO: O Afectan a la organización que desarrolla el software. 103 Riesgos posibles en el Software RIESGO TIPO DE DESCRIPCIÓN RIESGO Rotación de personal Proyecto Personal con experiencia abandona el proyecto antes de que finalice Cambio de Proyecto Habrá un cambio de administración organizacional con administración diferentes prioridades No disponibilidad del Proyecto El hardware esencial para el proyecto no será entregado hardware a tiempo Cambio de Proyecto y Habrá más cambios en los requerimientos que lo requerimientos producto anticipado. Retrasos en la Proyecto y Las especificaciones de las interfaces esenciales no especificación producto estarán a tiempo. Subestimación del Proyecto y El tamaño del sistema se ha subestimado. tamaño producto Bajo desempeño de la Producto Las herramientas CASE que ayudan al proyecto no herramienta CASE tienen el desempeño anticipado Cambio de tecnología Negocio La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología. Competencia del Negocio Un producto competitivo se pone en venta antes de que producto el sistema se acomplete TIPO DE RIESGO Tecnología Personas Organizacio nal Riesgos y tipos de riesgos RIESGOS POSIBLES La base de datos que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba. Los componentes de software a reutilizarse contienen defectos que limitan la funcionalidad. Es imposible reclutar personal con las habilidades requeridas para el proyecto. El personal clave está enfermo y no disponible en momentos críticos. La capacitación solicitada para el personal no está disponible. La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto. Los problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto. Herramient Es ineficiente el código generado por las herramientas CASE. as Las herramientas CASE no se pueden integrar. Requerimie Se proponen cambios en los requerimientos que requieren rehacer el diseño. ntos Los clientes no comprenden el impacto de los cambios en los requerimientos. Estimación El tiempo requerido para desarrollar el software está subestimado. La tasa de reparación de defectos está subestimada. El tamaño del software está subestimado. Riesgos y tipos de riesgos La probabilidad de que el riesgo se valore como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%). Los efectos del riesgo pueden ser valorados como catastróficos, serio, tolerable o insignificante. TIP O O Análisis de Riesgos RIESGO Los problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto. PROBABILIDA D Baja EFECTOS Catastrófico P Es imposible reclutar personal con las habilidades requeridas para el Alta Catastrófico proyecto. P El personal clave está enfermo y no disponible en momentos críticos. Moderada Serio T Los componentes de software a reutilizarse contienen defectos que limitan Moderada Serio la funcionalidad. R Se proponen cambios en los requerimientos que requieren rehacer el Moderada Serio diseño. O La organización i se reestructura de tal forma que una administración i i Alta Serio diferente se responsabiliza del proyecto. T La base de datos que se utiliza en el sistema no puede procesar muchas Moderada Serio transacciones por segundo como se esperaba. E El tiempo requerido para desarrollar el software está subestimado. Alta Serio H Las herramientas CASE no se pueden integrar. Alta Tolerable R Los clientes no comprenden el impacto de los cambios en los Moderada Tolerable requerimientos. P La capacitación solicitada para el personal no está disponible. Moderada Tolerable E La tasa de reparación de defectos está subestimada. Moderada Tolerable E El tamaño del software está subestimado. Alta Tolerable H Es ineficiente el código generado por las herramientas CASE. Moderada Insignificante
9. Conclusiones La planificación temporal es de suma importancia para llevar un control de la terminación a tiempo de la tareas de un proyecto. Las herramientas PERT y GANTT ayudan a la realización de la planificación temporal PERT, para monitorear el progreso y el retraso de las actividades, tomando como base la ruta crítica GANTT, ayudan a planear la utilización de recursos, así también, muestra de forma gráfica el calendario del proyecto. 9. Conclusiones Las métricas de software es una parte de la Ingeniería de software que proporcionan productos cuantitativos orientados a medidas de características de sistemas de información, así como sus procesos de desarrollo y operación. Permiten la estimación de esfuezo, duración, productividad, calidad, documentación, así como también costo de desarrollo del sw. En todo desarrollo de software, siempre es indispensable hacer un presupuesto para desarrollar, comprar o aplicar outsourcing 109 110 9. Conclusiones Hemos visto que el método de Puntos de Función y COCOMO se complementan. Mientras COCOMO mediante LDC y otros parámetros calcula el esfuerzo y duración, los puntos de función mediante funciones de usuario calcula puntos de función ajustados, los cuales para cierto lenguaje de programación le corresponde un número de LDC, que son la entrada para COCOMO. Debido a que los métodos COCOMO y FP son métodos comúnmente usados por la comunidad de métricas de software; la mayoría de herramientas como BYL, COSMOS, COSTAR, Jmetric, etc., contienen estos dos métodos. 10. Referencias 1. Pressman, S Roger (1998) Ingeniería del Software: Un enfoque práctico, 4a edición McGraw-Hill. 2. Somerville, Ian (2002) Ingeniería de software. 6a edición. Addison Wesley. 3. Braude Eric J. (2003) Ingeniería de Software Una perspectiva orientada a objetos, Alfaomega 111 112 10. Referencias 1. Software Metrics: A Rigorous and Practical Approach, (2nd ed.) (638p.), N.E. Fenton and S.L. Pfleeger, PWS Publishing, 1998. 2. Eric J. Braude. (2003) Ingeniería de Software: una perspectiva orientada a objetos. Alfaomega, México 3. Roger S. Pressman. (2005) Ingeniería de software. Un enfoque práctico. 6ª edición, McGraw Hill, México 4. Ian Somerville (2002) Ingeniería de Software. 6ª edición, Addison Wesley, México Preguntas? Gracias! 114