1
1
INGENIERIA DE SOFTWARE Tema 2: Administración de proyectos de
software
Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca Instituto de Computación Oficina 37 [email protected]
Prof. David Martínez Torres
2
Contenido
1. Gráficas PERT y GANTT
2. Métricas del proyecto
3. Mediciones del software
4. Métricas orientadas al tamaño (LDC)
5. Modelo de Estimación de Costos COCOMO
6. Métricas orientadas a los puntos de función
7. Análisis de riesgos
8. Conclusiones
9. Referencias
Prof. David Martínez Torres
2
Introducción
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.
Prof. David Martínez Torres 3
Lo que puede controlar el administrador de proyectos (Variables de la admon de proyectos)
El costo total del proyecto
Por ejemplo, aumentar/disminuir 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
Prof. David Martínez Torres 4
3
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)
Prof. David Martínez Torres 5
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 Prof. David Martínez Torres 6
4
7
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.
Prof. David Martínez Torres
8
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”
Prof. David Martínez Torres
5
9
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
Prof. David Martínez Torres
10
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. Prof. David Martínez Torres
6
11
Camino Crítico
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
Prof. David Martínez Torres
12
Gráficas de barras (GANTT) y redes de actividades (PERT).
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.
Prof. David Martínez Torres
7
13
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
Prof. David Martínez Torres
14
Diagramas GANTT
A las tareas se le puede asignar los recursos
Pueden ser derivados automáticamente de los grafos PERT
Prof. David Martínez Torres
8
15 Prof. David Martínez Torres
16 Prof. David Martínez Torres
9
17
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)
Prof. David Martínez Torres
18
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
Prof. David Martínez Torres
10
19
Ejemplo 1. PERT
Prof. David Martínez Torres
20
Ej 2. PERT
Prof. David Martínez Torres
11
21 Prof. David Martínez Torres
22 Prof. David Martínez Torres
12
23 Prof. David Martínez Torres
24
Hitos en el proceso de requerimientos
Prof. David Martínez Torres
13
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
Prof. David Martínez Torres 25
… 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
Prof. David Martínez Torres 26
14
… 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 líneas de código, así como también elementos que son calculados de mediciones, tal como la calidad del software.
Prof. David Martínez Torres 27
Métricas del proceso
Se pueden aplicar al proceso con la intención de mejorarlo
La eficacia de un proceso de software se mide indirectamente. Se extrae un conjunto de métricas de los resultados que provienen del proceso
Errores detectados antes de la entrega del software
Defectos detectados e informados por los usuarios finales
Productos de trabajo entregados
Esfuerzo humano y tiempo consumido
Prof. David Martínez Torres 28
15
Métricas del proceso
PSP, TSP, CMM, MOPROSOFT
Las métricas del proceso de software se utilizan para propósitos estratégicos
Prof. David Martínez Torres 29
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
Prof. David Martínez Torres 30
16
31
… Métricas del proyecto
Las métricas del proyecto son tácticas
A través de ellas, el gestor de proyectos adapta el flujo de trabajo del proyecto y las actividades técnicas
Estimaciones del esfuerzo y del tiempo para el trabajo actual, para esto se utilizan las métricas de proyectos anteriores
Prof. David Martínez Torres
… Métricas del proyecto
Durante el trabajo técnico, se tienen otras métricas
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
Prof. David Martínez Torres 32
17
Prof. David Martínez Torres 33
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
Prof. David Martínez Torres 34
18
35
4. 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.
Prof. David Martínez Torres
36
… Tamaño del software
El tamaño del sw., puede ser descrito por:
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
Prof. David Martínez Torres
19
37
… 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.
Prof. David Martínez Torres
38
… 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
Prof. David Martínez Torres
20
39
… 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.)
Prof. David Martínez Torres
40
… 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
Prof. David Martínez Torres
21
41
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
Prof. David Martínez Torres
42
5. 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)
Prof. David Martínez Torres
22
43
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.
Prof. David Martínez Torres
44
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.
Prof. David Martínez Torres
23
45
Fórmula para los tres modelos COCOMO
Donde:
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
db cETFaSE
Prof. David Martínez Torres
46
COCOMO: Básico
El factor de ajuste del esfuerzo (F) vale 1 en este modelo
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
Prof. David Martínez Torres
24
47
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 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
Prof. David Martínez Torres
48
… COCOMO: Intermedio
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, very high y extra high.
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
1i
iMEF
Prof. David Martínez Torres
25
49
Conductores de costos
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
Prof. David Martínez Torres
50
… 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
Prof. David Martínez Torres
26
51 Prof. David Martínez Torres
52 Prof. David Martínez Torres
27
53 Prof. David Martínez Torres
54
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
Prof. David Martínez Torres
28
55
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.
Prof. David Martínez Torres
56
6. 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 (19791983) 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 Prof. David Martínez Torres
29
57 Prof. David Martínez Torres
58 Prof. David Martínez Torres
30
59
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)
Prof. David Martínez Torres
60
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:
FP=UFC*TCF
Prof. David Martínez Torres
31
61
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.
Prof. David Martínez Torres
62
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
Prof. David Martínez Torres
32
63
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
Prof. David Martínez Torres
64
Complejidad
Determinado por:
Data Element Types (DETs)
Record Element Types (RETs)
Prof. David Martínez Torres
33
65
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.
Prof. David Martínez Torres
66
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
Prof. David Martínez Torres
34
Ejemplos EI: Alta de empleados [5]
1 FTR y 7 DET’s 6 campos y 1 tecla o botón de Acción
Prof. David Martínez Torres 67
Ejemplos EI: Información de control [6]
1 FTR 9 DET: 6 checkbox, 2 radio button y 1 tecla de Acción
Prof. David Martínez Torres 68
35
69
Ejemplo: External Input
Sistema de Inventario A/B/C
Parte: ________________________ Descripción: _______________ Origen: _________________ Cantidad: _______________ Precio: _____________ Colocación: ______________ Mensaje
____________________________
inventario
auditoria
Prof. David Martínez Torres
Ejemplo EI: Alta cliente [6]
Prof. David Martínez Torres 70
36
71
Matriz de Entradas de Usuario
Prof. David Martínez Torres
72
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 múltiple del mismo campo de datos.
Prof. David Martínez Torres
37
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).
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
Prof. David Martínez Torres 73
Ejemplo EO: Listado de Vendedores [5]
1 FTR: Vendor 3 DET: name, balance y scroll
Prof. David Martínez Torres 74
38
Ejemplo EO’s
2 FTR: Hits y User Sessions 10 DET: Day, Hits, % of Total Hits, User Sessions, los
6 resultados de totales. Prof. David Martínez Torres 75
76
Ejemplo: External Ouput
Impuestos empleados seguros
ahorros
tarifas
14 DET’s, no se cuenta fecha, ni núm de página
Prof. David Martínez Torres
39
Ejemplo EO: Employees by assignment duration[7]
3 FTR: Employee, Job y Job Assignment 7 DET’s: Employee SSN, Employee Name, Job Numer, Job Name, Assignment Duration y los 2 totales. Prof. David Martínez Torres 77
78
Matriz de Salidas de Usuario
Nota: los campos totales de un DET son contados como un
único DET de su propio campo. Esta interpretación está bajo
Debate.
Prof. David Martínez Torres
40
Componente funcional EQ
External Inquiry (EQ): Todas las combinaciones de entradas/salidas que resultan en la recuperación de datos de uno o más ILF’s o EIF’s. El proceso de entrada no actualiza ni mantiene ningún ILF o EIF, y el proceso de salida no contiene datos derivados.
Prof. David Martínez Torres 79
External Inquiry (EQ)
La complejidad de la EQ es valorada igual que una EO (se utiliza la misma matriz de complejidad), pero los puntos de función son los mismos que una EI.
Para el cálculo de complejidad, tanto los DET’s de entrada como de salida se suman, excepto si el mismo DET se usa en la entrada y en salida, solo se cuenta una vez. Lo mismo sucede para los archivos (ILF o EIF).
Prof. David Martínez Torres 80
41
Ejemplo EQ: Listado de empleados [7]
1 FTR: Employee 4 DET’s: (LastName + First Name + MI), SSN, Salary type) y la action Review
Prof. David Martínez Torres 81
Ejemplo EQ: Datos de horarios de los empleados [7]
1 FTR: Bargaining unit (unidad de negociación) 2 DET’s: bargaining unit y tecla selección lista desplegable
Prof. David Martínez Torres 82
42
Menú estático
No se considera un componente funcional. Solo sirve de navegación.
Obtenido de Manual de puntos de función[7]
Prof. David Martínez Torres 83
Ejemplos EQ: Menú dinámico
Prof. David Martínez Torres 84
43
85
Ejemplo: Consulta simple
Prof. David Martínez Torres
86
Ejemplo: Consulta compleja
Prof. David Martínez Torres
44
87
Matriz de Salidas de Usuario
Nota: los campos totales de un DET son contados como un
único DET de su propio campo. Esta interpretación está bajo
Debate.
Prof. David Martínez Torres
88
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 son mantenidos(CRUD) por EI. 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
Prof. David Martínez Torres
45
89
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. Por tal razón, las reglas de conteo NEFPUG han reducido la matriz de complejidad ILF al primer renglón.
Prof. David Martínez Torres
90
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
Prof. David Martínez Torres
46
91
Ejemplo
Prof. David Martínez Torres
Ejemplo ILF: Application Data [7]
The user requires the ability to enter, inquire, and report on information about jobs.
The following entity-relationship (E-R) diagram shows two entities that resulted from data normalization. The entities are job and job description.
Prof. David Martínez Torres 92
47
Ejemplo ILF: Application Data [7]
Prof. David Martínez Torres 93
Ejemplo ILF: Application Data [7]
Prof. David Martínez Torres 94
48
Ejemplo ILF [6]
Prof. David Martínez Torres 95
Ejemplo ILF [6]
Prof. David Martínez Torres 96
49
97
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.
Prof. David Martínez Torres
98
Especificación de un Corrector Ortográfico
Prof. David Martínez Torres
50
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.9354 Prof. David Martínez Torres 99
100
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
Prof. David Martínez Torres
51
101
… 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:
EL TCF varía de 0.65 (si todos los Fj son asignados a cero) a 1.35 (si todos los Fj son asignados a 5)
14
1
01.065.0j
FjTCF
Prof. David Martínez Torres
102
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.?
… Factores técnicos de Complejidad
Prof. David Martínez Torres
52
103
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?
… Factores técnicos de Complejidad
Prof. David Martínez Torres
…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?
Prof. David Martínez Torres 104
53
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”.
Prof. David Martínez Torres 105
106
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.
Prof. David Martínez Torres
54
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: Afectan a la organización que desarrolla el software.
Prof. David Martínez Torres 107
Riesgos posibles en el Software RIESGO TIPO DE
RIESGO
DESCRIPCIÓN
Rotación de personal Proyecto Personal con experiencia abandona el proyecto antes de
que finalice
Cambio de
administración
Proyecto Habrá un cambio de administración organizacional con
diferentes prioridades
No disponibilidad del
hardware
Proyecto El hardware esencial para el proyecto no será entregado
a tiempo
Cambio de
requerimientos
Proyecto y
producto
Habrá más cambios en los requerimientos que lo
anticipado.
Retrasos en la
especificación
Proyecto y
producto
Las especificaciones de las interfaces esenciales no
estarán a tiempo.
Subestimación del
tamaño
Proyecto y
producto
El tamaño del sistema se ha subestimado.
Bajo desempeño de la
herramienta CASE
Producto Las herramientas CASE que ayudan al proyecto no
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
producto
Negocio Un producto competitivo se pone en venta antes de que
el sistema se acomplete Prof. David Martínez Torres 108
55
Riesgos y tipos de riesgos TIPO DE
RIESGO
RIESGOS POSIBLES
Tecnología 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.
Personas 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.
Organizacio
nal
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
as
Es ineficiente el código generado por las herramientas CASE.
Las herramientas CASE no se pueden integrar.
Requerimie
ntos
Se proponen cambios en los requerimientos que requieren rehacer el diseño.
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. Prof. David Martínez Torres 109
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.
Prof. David Martínez Torres 110
56
Análisis de Riesgos TIP
O RIESGO PROBABILIDA
D EFECTOS
O Los problemas financieros de la organización fuerzan a reducciones en el
presupuesto del proyecto.
Baja Catastrófico
P Es imposible reclutar personal con las habilidades requeridas para el
proyecto.
Alta Catastrófico
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
la funcionalidad.
Moderada Serio
R Se proponen cambios en los requerimientos que requieren rehacer el
diseño.
Moderada Serio
O La organización se reestructura de tal forma que una administración
diferente se responsabiliza del proyecto.
Alta Serio
T La base de datos que se utiliza en el sistema no puede procesar muchas
transacciones por segundo como se esperaba.
Moderada Serio
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
requerimientos.
Moderada Tolerable
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 Prof. David Martínez Torres 111
112
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.
Prof. David Martínez Torres
57
113
… 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
Prof. David Martínez Torres
114
… 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.
Prof. David Martínez Torres
58
115
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
Prof. David Martínez Torres
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
5. www.softwaremetric.com
6. David Longstreet. Function Points Analysis Training Course. www.SoftwareMetrics.Com
7. International Function Users Group (IFPUG) (2000) Function Point Counting Practices Manual Release 4.1.1. Chairperson, Counting Practices Committee Valerie Marthaler EDS Troy, Michigan
Prof. David Martínez Torres 116
59
117
¿Preguntas?
Gracias!
Prof. David Martínez Torres