2 Métodos de estimación y costos de SW · 2011. 11. 8. · Estimación La estimación de recursos, costos y agendas para el esfuerzo de desarrollo de Software requiere experiencia,

Universidad Tecnológica de Jalisco Manual de Análisis y diseño II. Maestro

2

2 Métodos de estimación y costos de SW

Gestión del proyecto

El proceso de gestión del proyecto comienza con un conjunto de actividades que globalmente, se denominan planificación del proyecto. La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería de software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto corre el riesgo de construir una elegante solución para un problema equivocado.

Estimación La estimación de recursos, costos y agendas para el esfuerzo de desarrollo de

Software requiere experiencia, acceso a una buena información histórica y coraje para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.

Continúa en la siguiente página

Grado de estructuración definición y variabilidad

Complejidad basada en esfuerzos pasados Tamaño del

esfuerzo

Ámbito de bajo riesgo

Determinantes de la calidad del software y de la efectividad de organización

Proceso

Características del cliente

Condiciones del negocio

Entorno de desarrollo

Tecnología Personas

Producto

Academia de Ingeniería de Software Ana E. Romo González

3

Planificación, Continuación

En la figura anterior se ilustran los factores que aumentan el riesgo. Los ejes

de la figura corresponden a las características del proyecto a estimar.

La complejidad del proyecto

Tiene efecto sobre la incertidumbre, que es inherente a la planificación. La complejidad es una medida relativa que se ve afectada por la familiaridad con anteriores esfuerzos (dependiendo de qué tipo de aplicaciones haya desarrollado un equipo de trabajo anteriormente “tiempo real”, no interactivas, etc).

Tamaño del proyecto

Afecta la precisión y la eficacia de las estimaciones. Al aumentar el tamaño, aumenta la interdependencia entre los módulos. La técnica de descomposición de los módulos no se aplica fácilmente porque pueden seguir siendo demasiado grandes.

Grado de estructuración

La estructuración se refiere a la facilidad con la que las funciones pueden compartirse y la naturaleza jerárquica de la información que debe ser procesada. A medida que aumenta la estructuración, la posibilidad de estimar con precisión aumenta. La disponibilidad de información histórica también determina el riesgo de la estimación. Mejorar antes de que surjan los problemas.

El riesgo Se mide por el grado de incertidumbre de las estimaciones cuantitativas establecidas para los recursos, los costos y las agendas. (Especificación del sistema: se debe tener en cuenta que cualquier cambio en los requisitos de Software significa inestabilidad en los costos y en la agenda de trabajo).

Objetivos de la planificación de proyectos

Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal. Se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente a medida que progresa el proyecto.


4

Recursos Estimación de recursos requeridos para acometer el esfuerzo del desarrollo de Software. Cada recurso queda especificado mediante 4 características:

• Descripción del recurso • Informe de disponibilidad • Fecha cronológica en la que se requiere

Tiempo durante el que será aplicado

Recursos humanos

Se evalúa el ámbito y se seleccionan las habilidades técnicas que se requieren para el desarrollo. Especificar:

1. Posición dentro de la organización (ing. de Software, señor, etc), 2. Especialidad (Telecomunicaciones, bases de datos, etc.)

El número de personas requerido para el proyecto de Software, sólo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo.

Recursos de hardware

Considerar: 1. Sistema de desarrollo 2. Máquina objetivo 3. Demás elementos del nuevo sistema

Sistema de desarrollo: Llamado sistema anfitrión está compuesto por la computadora que se empleará durante el desarrollo y sus periféricos. Máquina objetivo: En que tipos de máquina se ejecutará el sistema. Demás elementos del nuevo sistema: Lectores de código de barras, impresoras térmicas, etc.

Gente

Herramientas HW/SW

Especificar • Habilidades requeridas • Disponibilidad • Duración de las tareas • Fecha de comienzo

Especificar • Descripción • Disponibilidad • Duración del uso • Fecha de distribución


5

¡Error! No hay texto con el estilo especificado en el documento. Métricas de estimación y costos

El proceso del software y las métricas del producto son una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software y de los proyectos que dirigen utilizando el proceso como un marco de referencia. La productividad en un sistema de manufactura se mide contando el número de unidades que se producen y dividiendo éste entre el número de personas-hora requeridas para producirlas. Sin embargo, para cualquier problema de software, existen muchas soluciones diferentes con distintos atributos. Sin embargo, los administradores tienen que estimar la productividad de los ingenieros en el proceso de desarrollo de software. Estas estimaciones son necesarias para la estimación del proyecto y para valorar si los procesos o las mejoras tecnológicas son efectivas. Para realizar estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles:

1. Dejar la estimación para más adelante 2. Basar las estimaciones en proyectos similares ya terminados 3. Utilizar técnicas de descomposición relativamente sencillas para

generar las estimaciones de coste y de esfuerzo del proyecto. 4. Utilizar uno o más modelos empíricos para la estimación del coste

y esfuerzo del software.

La primera opción no es practica las estimaciones deben ser a priori. La segunda opción e razonable si el proyecto es bastante similar, las opciones restantes con métodos viables para la estimación del proyecto de software, utilizan un enfoque de divide y vencerás y se pueden utilizar los modelos empíricos de estimación como complemento de las técnicas de descomposición.

Mediciones de SW

� Métricas orientadas al tamaño � Métricas orientadas a la función � Métricas ampliadas de puntos de función � Técnicas de descomposición

o Tamaño del SW o Basada en el problema o Basada en el proceso

� Modelos empíricos de estimación (COCOMO) � Desarrollar/comprar


6

1. Métricas orientadas al tamaño

Éstas se relacionan con el tamaño de alguna salida de una actividad. La medida más común relacionada con el tamaño son las líneas de código fuente entregadas.

�Provienen de la normalización de las medidas de calidad y/o productividad considerando el “tamaño” del SW que se ha producido. Crear una tabla:

Proyecto Alfa: desarrollaron 12,100 líneas de código con 24 personas-mes, con un costo 168,000 (A,D,C,P), 365 páginas de documentación, registraron 134 errores de SW y 29 después de entregarse dentro del 1er. Año de utilización, 3 personas. Para desarrollar métricas se comparan de distintos proyectos y se sacan normalización.

Comparar la productividad de los diferentes lenguajes de programación

también da impresiones engañosas de productividad del programador. Entre más expresivo sea un lenguaje de programación, más baja es la productividad aparente. Una alternativa a la utilización del tamaño del código como atributo estimado del producto es utilizar alguna medida de la funcionalidad del código.

Métricas orientadas a la función

Fueron propuestos por Albrecht (1979) y refinados por Albrecht y Gaffney (1983). Los puntos de función son independientes del lenguaje por lo que se puede comparar la productividad en los diversos lenguajes de programación. Utilizan una medida de funcionalidad entregada por la aplicación como un valor de normalización. Ya que la funcionalidad no se puede medir directamente. Los PDF se derivan con una relación empírica según las medidas contables (directas) del dominio de información y las evaluaciones de la complejidad del Software


Proyecto LDC Esfuerzo Costo $(000)

Pag.Doc. Errores Defectos Personal

A lfa Beta G amma . . .

12 ,100 27 ,200 20 ,200

24 62 43

168 440 314

365 1224 1050

134 321 256

29 86 64

3 5 6


7

Métricas orientadas a la función, Continuación

Se determinan 5 características del dominio de la información y se proporcionan las cuentas en la posición apropiada de la tabla.

• Número de entradas del usuario. Se cuenta cada entrada del usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deben diferenciar de peticiones.

• Número de salidas. Se cuenta cada salida que proporciona al usuario

información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos de particulares dentro de un informe se cuentan de forma separada.

• Número de peticiones del usuario. Se define como una entrada

interactiva que produce la generación de alguna respuesta del Software inmediata en forma de salida interactiva.

• Numero de archivos. Se cuenta cada archivo maestro lógico de datos

que puede ser una parte de una gran base de datos o un archivo independiente.

• Número de interfaces externas. Se cuentas todas las interfaces

legibles por la máquina (Archivos o cintas) que se utilizan para transmitir información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad y se le asigna un valor de peso que varía desde 3 (para las entradas externas sencillas) hasta 15 (para archivos internos complejos). Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante la determinación de la complejidad es algo subjetiva.


8

Tabla de puntos de función (Problema abierto)

Ejercicio 1

Cálculos de puntos de función

Para calcular puntos de función se utiliza la siguiente relación: PF = cuenta total X [0.65 + 0.01 X ∑ ( Fi )] en donde, cuenta total es la suma de todas las entradas PF obtenidas. Fi (i = 1 a 14) son “Valores de ajuste de la complejidad” según las respuestas de las siguientes preguntas: 1.¿Requiere el sistema copias de seguridad y de recuperación fiables? 2.¿Se requiere comunicación de datos? 3.¿Existen funciones de procesamiento distribuido? 4.¿Es crítico el rendimiento? 5.¿Se ejecutará el sistema en un entrono operativo existente y fuertemente utilizado? 6.¿Requiere el sistema entrada de datos interactiva? 7.¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? 8.¿Se actualizan los archivos maestros en forma interactiva? 9.¿Son complejas las entradas, las salidas, los archivos o las peticiones? 10.¿Es complejo el procesamiento interno? 11.¿Se ha diseñado el código para ser reutilizable? 12.¿Están incluidas en el diseño la conversión y la instalación? 13.¿Se ha diseñado el sistema permitir múltiples instalaciones en diferentes organizaciones? 14.¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario? Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial) .

0: Sin influencia, 1: Incidental, 2: Moderado, 3: Medio, 4: Significativo, 5: Esencial

Resultado del ejercicio 1

PF =

Los valores constantes de la ecuación y los factores de peso que se aplican a las cuentas de los dominios de información se determinan empíricamente. Una vez que se han calculado los puntos de función, se utilizan de forma análoga a las LDC como forma de normalizar las medidas de productividad, calidad y otros atributos del software.


Factor de ponderación

Par ámetros de medici ón

C uenta S imple M edio C omplejo N úmero de entradas de usuario

X

3

4

6

=

N úmero de salidas de usuario

X

4

5

7

=

N úmero de peticiones de usuario

X

3

4

6

=

N úmero de archivos

X

7

10

15

=

N úmero de interfaces externas

X

5

7

10

=

Cuenta total


9

Métricas orientadas a la función, Continuación

Puntos de función ampliados

La medida de punto de función Enfatiza la dimensión de datos (los valores de dominios de información de PF) para la exclusión de dimensiones (control) funcionales y de comportamiento. Una extensión se denomina puntos de característica (alta complejidad en los algoritmos), los valores de dominio de información se cuentan otra vez y se pesan como en el modelo anterior. Además cuenta otra característica del Software – los algoritmos – Un algoritmo se define como: un problema de cálculo limitado que se incluye dentro de un programa de computadora

específico, ejem. Invertir una matriz, manejar una interrupción, etc. Otra extensión propuesta por Boeing se denomina Punto de función 3D adecuada a aplicaciones que enfatizan las capacidades de control y función. Evalúa la dimensión de datos exactamente igual al modelo anterior. Las cuentas de datos retenidos (ejem. Archivos), y los datos externos (entradas, salidas, peticiones). La dimensión funcional: se mide considerando el número de operaciones internas requeridas para transformar datos de entrada en datos de salida. La dimensión de control: se mide contando el número de transiciones entre estados. La siguiente tabla proporciona estimaciones del número medio de líneas de código que se requieren para construir un punto de función

Lenguaje de programación LDC / PF (media) Ensamblador C COBOL FORTRAN Pascal C++ Ada95 Visual Basic Small Talk PowerBuilder (generador de código) SQL

320 128 106 106 90 64 53 32 22 16 12

Los conteos de los puntos de función se pueden utilizar junto con las técnicas de estimación de líneas de código. Se utiliza para estimar el tamaño final del código como el número promedio de líneas de código (LCP):

Tamaño del código = LCP x Número de puntos de función.

Productividad = PF / personas-mes

Calidad = errores / PF Costo = pesos / PF Documentos = Pag. Doc. / PF Esfuerzo = PF / ProdMedia (personas-mes)


10

Técnicas de descomposición

Consisten en descomponer el problema, volviéndolo a definir como un conjunto de pequeños problemas. Ya que en la mayoría de los casos el problema a resolver es demasiado complejo, para considerarlo como un todo.

Tamaño del software

El tamaño representa el primer reto importante del planificador de proyectos. En el contexto de la planificación de proyectos, el tamaño se refiere a una producción cuantificable del proyecto de software. Si se toma un enfoque directo, el tamaño se puede medir en LDC. Si se selecciona un enfoque indirecto, el tamaño se representa como PF.

Varios métodos combinan estadísticamente para crear una estimación de tres puntos o del valor esperado. Esto se lleva a cabo desarrollando valores de tamaño optimista (bajos), y más probables, y pesimistas (bajos), y se combinan utilizando la ecuación de PF.

6/)4( pessmopt SSSVE ++=

NOTA: Ver la Técnica de descomposición Estimación basada en el problema

Ejercicio 2

Calcular tamaño del software con Puntos de Función Parámetros de medición

Optimista Más probable Pesimista VE

Número. de entradas

Número de salidas

Número de peticiones

Número de archivos

Número de interfaces externas

Emplear la tabla de Puntos de función del problema 1, sustituyendo PF =


11

Estimación basada en el problema

El planificador de proyecto comienza con un enfoque limitado para el ámbito del software y desde este estado intenta descomponer el software en funciones que se pueden estimar individualmente. Estimando para cada función las LDC y PF. En general, el dominio del proyecto debería calcular las medias de LDC/pm o PF/pm, agrupando los proyectos por tamaño, área de aplicación o complejidad y otros parámetros relevantes. El planificador estima un valor de tamaño optimista, más probable y pesimista para cada función. Entonces se calcula un valor de tres puntos o esperado. El valor esperado de la variable de estimación (tamaño), VE, se puede calcular como una media ponderada:

siendo optS = Estimaciones optimistas

mS = Estimaciones probables

pessS = estimaciones pesimistas

Una vez determinado el valor esperado de la variable de estimación, se aplican datos históricos de productividad y LDC y PF.

Ámbito del problema

Ejercicio 3

Desarrollo de un paquete de software para una aplicación de diseño asistido por computadora CAD. El software de CAD aceptará del ingeniero de datos de geometría bi – y tri-dimensional. El ingeniero controlará e interactuará con el sistema CAD a través de una interfaz de usuario que exhibirá características de un buen diseño hombre-máquina. Todos los datos geométricos y cualquier información adicional se mantendrán en una base de datos de CAD. Los módulos de análisis del diseño se desarrollarán de forma que produzcan la salida requerida en una forma que pueda ser mostrada en una gran variedad de dispositivos gráficos. El software estará diseñado para poder controlar e interactuar con dispositivos periféricos tales como un ratón, un digitalizar, una impresora láser y un trazador.

Tabla de estimación de LDC

Función

OP

MP

PES

VE

$/L

L/mes

Costo

Meses

Control de interfaz de usuario

Análisis geométrico bidimensional

Análisis geométrico tridimensional

Gestión de estructura de datos

Visualización de gráficos

Control de periféricos

Análisis de diseño

Total

*

*

*


12

Estimación basada en el proceso

La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar. Descomponer el proceso en un conjunto de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Esta técnica comienza con un esbozo de las funciones del software obtenidas a partir del ámbito del proyecto. Para cada función se debe llevar a cabo una serie de actividades del proceso de software. Las funciones y las actividades del proceso de software relacionadas se pueden representar como parte de una tabla similar a la siguiente: El planificador estima el esfuerzo (personas/mes) que se requerirá para llevar a cabo cada una de las actividades del proceso de software en cada función.

Tabla de estimación basada en el proyecto

Actividad

CC Planificación

Análisis

de riesgo

Ingeniería Construcción

entrega EC Totales

Tarea

Análisis Diseño Código Prueba

Función

IUFC 0.50 2.50 0.40 5.00 n/a 8.40

AG2D 0.75 4.00 0.60 2.00 n/a 7.35

AG3D 0.50 4.00 1.00 3.00 n/a 8.50

FPGC 0.50 3.00 1.00 1.50 n/a 6.00

GBD 0.50 3.00 0.75 1.50 n/a 5.75

CP 0.25 2.00 0.50 1.50 n/a 4.25

MAD 0.50 2.00 0.50 2.00 n/a 5.00

Totales 0.25 0.25 0.25 3.50 20.50 4.75 16.50 45.25

%Esfuerzo

1% 1% 1% 8% 45% 10% 36%

CC = Comunicación cliente EC= Evaluación cliente


13

Como último paso se calculan los costes y el esfuerzo de cada función, y la

actividad del proceso de software. Si la estimación basada en el proceso se realiza independientemente de la estimación de LDC o PF, ahora tendremos dos o tres estimaciones del coste y del esfuerzo que se pueden comparar y evaluar.

Modelos empíricos de estimación

Un modelo de estimación para el software de computadora utiliza fórmulas derivadas empíricamente para redecir el esfuerzo como una función de LDC o PF. Un modelo común de estimación se extrae utilizando el análisis de regresión sobre los datos recopilados de proyectos de software anteriores. La mayoría de los modelos de estimación tienen algún componente de ajuste del proyecto que permite ajustar el esfuerzo en personas-mes (E), por ejemplo, la complejidad del problema, experiencia del personal, entorno de desarrollo).

El modelo COCOMO

Barry Boehm, en su libro sobre economía de la ingeniería de software, introduce una jerarquía de modelos de estimación de software con el nombre de COCOMO (Constructive Cost Model). El modelo COCOMO original (conocida como COCOMO 81) se ha convertido en uno de los modelos de estimación de coste del software más utilizados y estudiados de la industria. La primera versión del modelo COCOMO fue un modelo de tres niveles donde éstos reflejaban el detalle del análisis de la estimación del costo. El primer nivel (básico) provee una estimación inicial burda, el segundo nivel la modifica utilizando varios multiplicadores del proyecto y del proceso, y el nivel más detallado produce estimaciones para las diferentes fases del proyecto.

Tipos de proyectos en COCOMO

1. Modo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre un conjunto de requisitos poco rígidos.

2. Modo semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos.

3. Modo empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido.


14

Ecuaciones de COCOMO básico

COCOMO (Constructive Cost MOdel) E=ab(KLDC)exp(bb) D=cb(E) exp (db) N=E/D

Tabla de COCOMO básico

Ejercicio 4

Calcular COCOMO básico para el problema del sistema CAD del ejercicio 3 E = D = N =

El punto objeto Es una medida indirecta de software (cuando se utilizan 4GLs o lenguajes comparables para el desarrollo de software) que se calcula utilizando el total de (1) pantallas (de la interfase de usuario), (2) informes, y (3) componentes que probablemente se necesiten para construir la aplicación. Son una estimación con peso:

1. El número de pantallas independientes que se despliegan. Pantallas sencillas cuentan como 1 PO (Punto de objeto), las moderadamente complejas como 2 PO y las muy complejas como 3 PO.

2. El número de informes que se producen. Para informes simples, cuentan como 2 PO, para informes moderadamente complejos 5 PO y para informes difíciles de producir 8 PO.

3. El número de módulos 3GL que deben desarrollarse para complementar el código 4GL. Cada módulo 3GL cuenta como 10 PO.

0.32

2.5

1.20

3.6

Empotrado

0.35

2.5

1.12

3.0

Semi acoplado

0.38

2.5

1.05

2.4

Orgánico

db cb bb ab Proyecto


15

Tabla para el cálculo del PO

Tipo de objeto Peso de la complejidad

Básico Intermedio Avanzado

Pantalla 1 2 3

Informe 2 5 8

Componente 3GL 10

Una vez que se ha determinado la complejidad, se valora el número de pantallas, informes y componentes. La cuenta de punto objeto se determina multiplicando el número original de instancias de objeto por el factor de peso y se suman para obtener la cuenta total del punto objeto.

Ejercicio 5

Calcular PO para el Sistema CAD del ejercicio 3 PO =

Punto objeto nuevo

Cuando se va a aplicar el desarrollo basado en componentes o la reutilización de software en general, se estima el porcentaje de reutilización (% reutilización) y se ajusta la cuenta del punto objeto: PON = (puntos objeto) x [(100 - % reutilización) /100]

Donde PON = Puntos objeto nuevos

Esfuerzo con punto objeto nuevo

Para obtener una estimación del esfuerzo basado en el valor PON calculado. Se debe calcular la proporción de productividad para los diferentes niveles de experiencia del desarrollador y de madurez del entorno de desarrollo. Una vez determinada la proporción de productividad, se puede obtener una estimación del esfuerzo del proyecto. Mediante la siguiente tabla:

Experiencia / capacidad del desarrollador

Muy baja

Baja Normal Alta Muy alta

Madurez/ capacidad del entorno

Muy baja

Baja Normal Alta Muy alta

PROD

4 7 13 25 50

Esfuerzo estimado = PON / PROD Donde PROD = es la productividad.


16

Ejercicio 6

Calcular PON tomando en cuenta el ejercicio 5 PON =

La decisión de desarrollar-comprar

En muchas áreas de aplicación del software, a menudo es más rentable adquirir el software de computadora que desarrollarlo. En una decisión de desarrollarlo o comprarlo se pueden complicar aún más con las opciones de adquisición: (1) el software se puede comprar (con licencia) ya desarrollado; (2) se pueden adquirir componentes de software totalmente experimentado o parcialmente experimentado y modificarse e integrarse para cumplir las necesidades especificas. O (3) el software puede ser construido de forma personalizada por una empresa externa.


17

Proyecto 1

Sistema SEP

La Universidad Tecnológica de Jalisco, aplica diferentes Test psicométricos a los alumnos que ingresan a la institución, con la intención de definir un perfil que permita apoyar el programa de tutorias y la colocación de alumnos en estadías. El sistema actual permite dar de alta alumnos de manera externa mediante el código del alumno, proporcionado por servicios escolares, pero no cuenta con facilidades para el mantenimiento debido a que los requerimientos originales especificaba que la información la proporcionaría servicios escolares mediante un acceso a su base de datos. La herramienta (SEP) Sistema de Evaluación Psicométrica, permite realizar la calificación automatizada de 3 test psicométricos, una vez que se ha presentado la aplicación. Estos son:

o Dominos. Mide CI o 16 FP. Mide 16 factores de personalidad o Terman. Mide CI y capacidad de aprendizaje

Éste último no se aplica debido a que no aporta información relevante para la institución. El sistema genera reportes que son resultado de la evaluación. Fue desarrollado en Cbuilder. Del sistema actual solamente se cuenta con el código ejecutable por lo que se necesita reingeniería. Los nuevos requerimientos especifican que se permita el mantenimiento de alumnos (altas, bajas, modificaciones, consultas), seguridad en el sistema, así como el cálculo automatizado de otros 2 test:

o Raven (inteligencia) o Encuesta de hábitos y actitudes hacia el estudio.

Del primero aún no se realiza la aplicación manualmente. No se cuenta con documentación que permita darle mantenimiento.

Proyecto 2

Sistema SEIE

El Sistema Estadístico de Ingreso a Exposiciones (SIEI) genera estadísticas de visitantes a exposiciones. Debe permitir la captura de datos fijos (nombre, domicilio, teléfono, correo electrónico, etc.) de los visitantes y la captura de datos variables (preguntas específicas de cada exposición, las cuales podrán ser abiertas ¿XYZ? o de selección múltiple. El sistema deberá contar con un módulo de configuración para cada expo, y uno de mantenimiento para preguntas, solicitando la pregunta y las posibles opciones. Deberá generar gráficas de cada pregunta con un resumen de respuestas de las que hayan sido abiertas. El Software recibe información de entrada de las capturistas que deberán entregar un formato a cada visitante e imprimirá una etiqueta de acceso a la exposición con el nombre del visitante y un folio. Podrá interrumpirse la captura de datos para continuar posteriormente con las repuestas del visitante. Se mantendrá el control de acceso de usuarios con 3 categorías:

1. Mantenimiento. Instala el sistema y puede dar de alta preguntas 2. Capturista 3. Empresario. Verifica estadísticas e imprime.


18

Calcular PF

Para calcular puntos de función se utiliza la siguiente relación: PF = cuenta total X [0.65 + 0.01 X ∑ ( Fi )] en donde, cuenta total es la suma de todas las entradas PF obtenidas. Fi (i = 1 a 14) son “Valores de ajuste de la complejidad” según las respuestas de las siguientes preguntas: 1.¿Requiere el sistema copias de seguridad y de recuperación fiables? 2.¿Se requiere comunicación de datos? 3.¿Existen funciones de procesamiento distribuido? 4.¿Es crítico el rendimiento? 5.¿Se ejecutará el sistema en un entrono operativo existente y fuertemente utilizado? 6.¿Requiere el sistema entrada de datos interactiva? 7.¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? 8.¿Se actualizan los archivos maestros en forma interactiva? 9.¿Son complejas las entradas, las salidas, los archivos o las peticiones? 10.¿Es complejo el procesamiento interno? 11.¿Se ha diseñado el código para ser reutilizable? 12.¿Están incluidas en el diseño la conversión y la instalación? 13.¿Se ha diseñado el sistema permitir múltiples instalaciones en diferentes organizaciones? 14.¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario? Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial) .

0: Sin influencia, 1: Incidental, 2: Moderado, 3: Medio, 4: Significativo, 5: Esencial PF=

Factor de ponderación

Par ámetros de medici ón

C uenta S imple M edio C omplejo N úmero de entradas de usuario

X

3

4

6

=

N úmero de salidas de usuario

X

4

5

7

=

N úmero de peticiones de usuario

X

3

4

6

=

N úmero de archivos

X

7

10

15

=

N úmero de interfaces externas

X

5

7

10

=

Cuenta total


19

Calcular tamaño del software con PF

6/)4( pessmopt SSSVE ++=

Parámetros de medición

Optimista Más probable Pesimista VE

Número. de entradas

Número de salidas

Número de peticiones

Número de archivos

Número de interfaces externas

PF =


20

Calcular LDC

Divida el ámbito del proyecto en por lo menos 6 funciones y calcule LDC

Función

OP

MP

PES

VE

$/L

L/mes

Costo

Meses

Total

*

*

*


21

Calculo de COCOMO

Seleccione un tipo de proyecto, tome los valores de la tabla y calcule COCOMO básico E=ab(KLDC)exp(bb) D=cb(E) exp (db) N=E/D E = D = N =

Calcule Punto objeto y punto objeto nuevo

Tipo de objeto Peso de la complejidad

Básico Intermedio Avanzado

Pantalla 1 2 3

Informe 2 5 8

Componente 3GL 10

PO = PON = (puntos objeto) x [(100 - % reutilización) /100] PON =


22

3. Reingeniería de Software e ingeniería de reversa

Sistemas heredados

Son sistemas de SW tradicionales esenciales para el apoyo a negocios. Las compañías de apoyan en estos sistemas por lo que conviene mantenerlos en operación.

Antecedentes La cantidad de código en los sistemas heredados es inmensa. En 1990, se estimó que existían 120 mil millones de líneas de código. Se escribieron en COBOL, o FORTRAN. Desde 1990, ha habido un gran incremento en la utilización de las computadoras para el apoyo de los procesos de negocios. Por lo tanto, se estima que debe haber alrededor de 250 mil millones de líneas de código fuente en existencia que requieren mantenimiento. Muchas de estas líneas no están escritas en lenguajes orientados a objetos y aún se ejecutan en computadoras mainframe.

Reingeniería de SW

Se refiere a reimplementar sistemas heredados para hacerlos más mantenibles. La reingeniería comprende la redocumentación del sistema, la organización y reestructura del sistema, la traducción del sistema a un lenguaje de programación más moderno y la modificación y actualización de la estructura y los valores de los datos del sistema. La funcionalidad del software no se cambia y, normalmente, la arquitectura del sistema también permanece igual.

Ventajas de la reingeniería

a. Riesgo reducido Existe un alto riesgo en volver a desarrollar software esencial para una organización. Se cometen errores en la especificación del sistema, existen problemas en el desarrollo, etcétera.

b. Costo reducido El costo de la reingeniería es mucho menor que los

costos de desarrollar nuevo software. Puede ser 4 veces menos costoso que reescribir el sistema.

Ingeniería directa y reingeniería


23

Posible proceso de reingeniería

El proceso de reingeniería

1.- Traducción del código fuente El programa se convierte de un lenguaje de programación antiguo a una versión más moderna del mismo lenguaje o a un lenguaje diferente. 2. Ingeniería inversa Se analiza el programa y se extrae información de él, la cual ayuda a documentar su organización y funcionalidad. 3. Mejora de la estructura del programa Se analiza y modifica la estructura de control del programa para hacerlo más fácil de leer y comprender. 4. Modularización del programa Donde sea apropiado, se agrupan las partes relacionadas del programa y la redundancia se elimina. En algunos casos, esta etapa comprende la transformación arquitectónica. 5. Reingeniería de datos Se cambian los datos procesados por el programa para reflejar los cambios en él.

Enfoques de la reingeniería


24

Factores principales que afectan los costos

1. La calidad del software al que se aplica reingeniería. Entre más baja sea la calidad del software y de su documentación asociada (si existe), más altos serán los costos de la reingeniería. 2. Las herramientas de apoyo disponibles para la reingeniería. Normalmente no es costeable hacer reingeniería a un sistema de software a menos que se utilicen herramientas CASE para automatizar muchos de los cambios en el programa. 3. La amplitud de la conversión de datos requerida Si la reingeniería requiere que se conviertan grandes volúmenes de datos, entonces los costos del proceso se incrementan significativamente.

4. La disponibilidad de personal experto Si el personal responsable de dar mantenimiento al sistema no se involucra en el proceso de reingeniería, esto incrementará los costos. Los ingenieros encargados de la reingeniería tienen que invertir gran cantidad de tiempo para comprender el sistema.

1. Traducción del código fuente

Traducción del código fuente por niveles

1. Actualización de la plataforma de hardware. La organización desea cambiar su plataforma estándar de hardware. Los compiladores para el lenguaje original pueden no estar disponibles para el nuevo hardware. 2. Debilidad en las habilidades del personal. Existe una falta de personal de mantenimiento capacitado para el lenguaje original. Este problema es muy importante cuando los programas se escribieron en un lenguaje no estándar que está fuera de circulación. 3. Cambios en las políticas organizacionales. Una organización decide adoptar un estándar para un lenguaje de programación con el fin de minimizar los costos del software de ayuda. Dar mantenimiento a muchas versiones de los compiladores antiguos es muy costoso. 4. Falta de software de apoyo. Los proveedores del compilador de lenguaje están fuera de circulación de los negocios o no existe continuidad en el apoyo de este producto.


25

2. Ingeniería inversa

La ingeniería inversa es el proceso de analizar el software con el objetivo de recuperar su diseño y especificación. El programa mismo no cambia por el proceso de ingeniería inversa. 1.Se puede aplicar ingeniería inversa al diseño y a la especificación de un sistema existente por lo que éstos pueden servir como una entrada a la especificación de requerimientos para la sustitución del programa. 2.De forma alternativa, se puede aplicar ingeniería inversa al diseño y a la especificación para que sirvan como ayuda al mantenimiento del programa. Con esta información adicional, no es necesario aplicar la reingeniería al código del sistema.

El proceso de ingeniería inversa

3. Mejora de la estructura del programa

La necesidad de optimizar la utilización de la memoria y la falta de comprensión de la ingeniería de software por varios programadores han generado que muchos sistemas heredados no estén bien estructurados. Su estructura de control está enmarañada con muchas ramas no condicionales y lógica de control no intuitiva. Esta estructura también se ha degradado por el mantenimiento regular. Los cambios al programa han hecho que algún código no sea alcanzable, pero esto sólo se descubre después de un análisis profundo. A menudo, los programadores del mantenimiento no se atreven a remover el código en el caso de que se acceda a él de forma indirecta.

Simplificación de la condición

Condición compleja if not (A > B and (C < D or not E > F) ) )... Condición simplificada


26

Reestructuración automatizada de programas

Problemas de la reestructuración automatizada de programas

1.Pérdida de comentarios Si el programa tiene líneas de comentarios, invariablemente éstas se pierden como parte del proceso de reestructuración. 2. Pérdida de documentación De forma similar, se pierde la correspondencia entre la documentación de programas externos y el programa. Sin embargo, en muchos casos los comentarios y la documentación de un programa no están actualizados, por lo que esto no es un factor importante. 3. Demandas de computación pesadas Los algoritmos incrustados en las herramientas de reestructuración son complejos. Aun con el hardware moderno y rápido se puede llevar mucho tiempo completar el proceso de reestructuración para programas grandes.

Métricas para identificar programas candidatos a reestructuración

o la tasa de caídas;

o el porcentaje de código fuente que cambia por año;

o la complejidad del componente. Otros factores, como el grado de cumplimiento de los estándares actuales de los programas o componentes, se deben tomar en cuenta al tomar las decisiones sobre reestructuración.

4. Modularización del programa

La modularización del programa es el proceso de reorganizar un programa con el fin de que las partes relacionadas se ubiquen conjuntamente y se consideren como un solo módulo. Una vez hecho esto, es más fácil eliminar las redundancias en estos componentes relacionados, optimizar sus interacciones y simplificar su interfaz con el resto del programa. Si el sistema se distribuye, los módulos creados se encapsulan como objetos y se acceden a través de una interfaz común.


27

Tipos de módulos que se crean durante el proceso de modularización del programa

1.Abstracciones de datos Éstos son tipos de datos abstractos creados al asociar los datos con componentes del procesamiento. 2.Módulos de hardware Éstos están fuertemente relacionados con las abstracciones de datos y recolectan conjuntamente todas las funciones utilizadas para controlar un dispositivo particular de hardware. 3.Módulos funcionales Éstos son módulos que recolectan conjuntamente funciones que llevan a cabo tareas similares o muy relacionadas. Este tipo de modularización se considera cuando no es práctico recuperar las abstracciones de datos del programa. 4.Módulos de apoyo al proceso Éstos son módulos donde se agrupan todas las funciones y elementos de datos específicos requeridos para apoyar un proceso de negocios en particular.

Recuperación de abstracciones de datos

Para reducir costos del cambio a áreas de datos compartidas, el proceso de modularización del programa se centra en la identificación de abstracciones de datos. Los pasos involucrados en convertir áreas de datos globales compartidas en objetos o tipos de datos abstractos son: 1. Analizar áreas de datos comunes para identificar las abstracciones lógicas de datos. 2. Crear un tipo de datos abstracto o un objeto para cada una de estas abstracciones. Si el lenguaje de programación no tiene características para ocultar datos, simular un tipo de datos abstracto suministrando funciones para actualizar y acceder a todos los campos de los datos. 3. Utilizar un sistema de navegación de programas o un generador de referencia cruzada para encontrar todas las referencias a los datos. Reemplazar éstas con llamadas a las funciones apropiadas.

Documents

2 Métodos de estimación y costos de SW · 2011. 11. 8. · Estimación La estimación de recursos, costos y agendas para el esfuerzo de desarrollo de Software requiere experiencia,