Ingeniería de Software: Tema2 Administración de …dtorres/cursos/ingsw/tema2.pdf · COCOMO II,...

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


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


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)


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.


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”


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


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


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.


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


14

Diagramas GANTT

A las tareas se le puede asignar los recursos

Pueden ser derivados automáticamente de los grafos PERT


8

15 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)


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


10

19

Ejemplo 1. PERT


20

Ej 2. PERT


11



12


24

Hitos en el proceso de requerimientos


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


… 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


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.


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


15

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


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


… 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


17


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


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.


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


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.


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


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.)


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


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


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)


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.


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.


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


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


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


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


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


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


26



27


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


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.


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



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)


60


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


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.


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


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


64

Complejidad

Determinado por:

Data Element Types (DETs)

Record Element Types (RETs)


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.


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


34

Ejemplos EI: Alta de empleados [5]

1 FTR y 7 DET’s 6 campos y 1 tecla o botón de Acción


Ejemplos EI: Información de control [6]

1 FTR 9 DET: 6 checkbox, 2 radio button y 1 tecla de Acción


35

69

Ejemplo: External Input

Sistema de Inventario A/B/C

Parte: ________________________ Descripción: _______________ Origen: _________________ Cantidad: _______________ Precio: _____________ Colocación: ______________ Mensaje

____________________________

inventario

auditoria


Ejemplo EI: Alta cliente [6]


36

71

Matriz de Entradas de Usuario


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.


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


Ejemplo EO: Listado de Vendedores [5]

1 FTR: Vendor 3 DET: name, balance y scroll


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


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.


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.


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).


41

Ejemplo EQ: Listado de empleados [7]

1 FTR: Employee 4 DET’s: (LastName + First Name + MI), SSN, Salary type) y la action Review


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


42

Menú estático

No se considera un componente funcional. Solo sirve de navegación.

Obtenido de Manual de puntos de función[7]


Ejemplos EQ: Menú dinámico


43

85

Ejemplo: Consulta simple


86

Ejemplo: Consulta compleja


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.


88


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


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.


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


46

91

Ejemplo


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.


47





48

Ejemplo ILF [6]


Ejemplo ILF [6]


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.


98

Especificación de un Corrector Ortográfico


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


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


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.?



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

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?


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”.


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.


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.


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.


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.


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


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.


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


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


http://www.softwaremetric.com/

http://www.softwaremetrics.com/

59

117

¿Preguntas?

Gracias!


Ingeniería de Software: Tema2 Administración de …dtorres/cursos/ingsw/tema2.pdf · COCOMO II,...

Documents

Transcript of Ingeniería de Software: Tema2 Administración de …dtorres/cursos/ingsw/tema2.pdf · COCOMO II,...