ESTIMACIÓN
ESTIMACIÓN
Director de Proyectos → tiene que realizar 3 tareas críticas para que un proyecto termine bien:
ESTIMACIÓN de duración , costo y esfuerzo
PLANIFICACIÓN de tareas a realizar, asignación de recursos, tiempos, etc para poder construir el producto
SEGUIMIENTO de realización del trabajo y tomar medidas correctivas si hay desviaciones.
Def: es el proceso de asignar valor a un conjunto de variables con un grado de incertidumbre. La idea es que sea casi exacta. Es un cálculo anticipado que hago con un rango aceptable.
Problemas cuando Estimo:
Estimaciones optimistas (nadie entiende porqué, decimos es fácil, decirlo es irresponsable en proyectos grandes)
No registrar experiencias pasada
Omitir tareas importantes por falta de tiempo o por comprometer el cronograma (Sacrifico Calidad)
No sabemos cómo estimar, no contamos con suficiente información para el nivel de precisión esperado.
La estimación la hace marketing, ventas, etc..(La debe hacer el Equipo de Desarrollo porque debe hacer un análisis de cómo se tiene que hacer)
No conocemos la tecnología o el dominio (Debe haber un tiempo extra si no se conoce, que debemos incluirlo en la planificación temporal)
No reconocemos las diferencias de escala
MITO: “Tengo poca información entonces no puedo estimar, es inutil e imposible” → FALSOOOO!
En software siempre puedo estimar
La estimación es con cierto nivel de incertidumbre (Al comienzo sin experiencia capaz sea grande, pero la idea es ir adquiriendo experiencia y ver con que rango de tolerancia el equipo va a desarrollar)
Me baso en la experiencia anterior donde me sirve como base para trabajar
x es el tiempo óptimo de desarrollo en etapas
y es errores de estimación (al comienzo es 4 para arriba y 4 para abajo)
Ajustó a medida que voy pasando etapas
FACTORES QUE INFLUYEN EN ESTIMACIÓN
Tamaño del proyecto (La complejidad no crece linealmente con el tamaño, Ej: capaz si voy metiendo más gente me demore mas tiempo en la realización del proyecto)
Tipo de Software (conocemos, es complejo?)
Factores del personal (Armo grupo de desarrollo, el número de programadores no es ilimitado)
Tecnología (Hacemos capacitación?)
¿QUÉ ESTIMO?
TAMAÑO: ¿Qué tamaño tiene el producto que quiero construir? (KLDC y otras)
ESFUERZO: ¿Cuántas horas-persona necesito para construir?
CRONOGRAMA: ¿En cuanto tiempo puedo hacerlo? Hay tareas que dependen de otras por ejemplo el hacer pruebas después de desarrollar. o tareas que puedo hacer en paralelo
COSTO: ¿Cuánto me va a costar?
En muchos casos se comienza con el esfuerzo para sacar el tiempo y el costo.
MÉTODOS DE ESTIMACIÓN EMPÍRICOS o MÉTODOS BASADOS EN LA EXPERIENCIA
Uno conocido es el MÉTODO DE PARKINSON:
No es un método bueno porque las estimaciones las hago en base a :
Cantidad de personal
Cantidad de tiempo que se dispone
“El trabajo se expande hasta consumir todos los recursos disponibles” (Ley de Parkinson)
Es muy común en administraciones o sectores públicos. Es el peor de los escenarios.
Problemas
Tenemos todo un tiempo y esperamos hasta el último día para recién terminarlos cuando podríamos haberlo tenido antes, lo mismo con la comunicación.
“A medida que algo aumenta, disminuye su eficiencia”
El tiempo para terminar una tarea→ aumenta, la tarea era compleja.
El tiempo para terminar una tarea→ disminuye, la tarea era sencilla.
Nos basamos en el “PRECIO PARA VENDER”
Si los mercados me dan las estimaciones estamos en problemas también aquí, capaz porque:
Estamos condicionados y tenemos que hacerlo rápido por contrato.
El precio se fija en función de lo que está dispuesto a pagar el cliente
Tengo que ver si me conviene usar con otros métodos puede ser aceptable
Es peligroso si lo uso solo.
MÉTODOS DE DESCOMPOSICIÓN o BASADO EN LOS COMPONENTES DEL PRODUCTO O PROCESO DE DESARROLLO
Descomponer
Estimar cada parte
Sumar, ajustar y contar el costo de las uniones
Tenemos 2 métodos:
BOTTOM-UP
Descomponer el proyecto en menores unidades posibles
Estimar cada unidad
Calcular el coste total
TOP-DOWN
Mirar todo el proyecto y descomponer en grandes bloques o fases
Estimar el coste de cada componente
Cualquiera de los dos es válido y está bien pero preferiblemente se recomienda el primero.
MÉTODOS ALGORÍTMICOS
Usar un Algoritmo que toma datos del sistema (Funciones, pantallas, inputs…)
Usar Factores de Ajuste de Complejidad y
Devolver un número.
Son más precisos, son estudios realizados y que sirven cuando no tenemos experiencia previa donde nos podemos basar y realizar ajustes. Nos da una seguridad de que la estimación está bastante aproximada a una realidad.
Se basan en la utilización de fórmulas que aplicadas sobre los modelos top-down o bottom-up producen una estimación del coste del proyecto.
Tenemos una aplicación a desarrollar con diferentes características, si las analizamos y son estimaciones. En base a eso sacamos el coste.
Método de Putman
Planteó un método que relaciona cantidad de personas con duración de proyecto.
Y = Personas/mes en un punto determinado (cantidad de personas en un determinado mes)
K = Esfuerzo total del proyecto, (Área bajo la curva) (este esfuerzo lo sacamos con algún método)
a = Cte. asociada a la aceleración de entrada de personas en el proyecto, (está tabulada)
t = instante del tiempo.
Dividimos el sistema en módulos, donde estimamos cada módulo en 3 valores:
Optimista (O) : es el menor tamaño/esfuerzo imaginable
Pesimista (P): es el mayor tamaño/ esfuerzo imaginable
Medio (M)
Después calculamos la estimación donde:
La fórmula puede variar para dar más peso a la estimación pesimista (Lo peor que puede pasar)
Métricas de Punto de Función (Albrecht)
Def: es una métrica que se puede aplicar en las primeras fases de desarrollo donde se basa en características fundamentalmente “Externas” de la aplicación a desarrollar.
Mide 2 tipos de características:
Los Elementos de Función (entradas, salidas, ficheros, etc)
Los Factores de Complejidad
Inicialmente la aplico Albrecht en IBM
Me dice:
de donde obtengo la información (que entidad me da la información)
como es la complejidad
Elaboró una salida (que entidad recibe la entidad)
E-P-S
La pregunta que tenemos que hacer es ¿Cómo medimos el Sw?
Elementos de Función
Def: son elementos fácilmente identificables en los Diagramas de Especificación del sistema (DFD, Entidad - Relacion, DD- Diccionario de datos). Más orientados a las metodologías. Los usuarios los entienden perfectamente y observamos al sistema como una caja negra.
Algunas definiciones que debemos tener en cuenta antes son:
Proceso elemental: es la menor unidad de actividad que tiene sentido para el usuario, lo vemos desde el punto de vista del usuario que es el conocedor del sistema en estudio.
Datos e información de control: son datos elementales con los que trabaja el sistema en estudio. Se componen de datos propios del sistema más el control que solicita el usuario como mensajes de error, claves de seguridad, etc.
Lógica de proceso: son los procesos que se producen como consecuencia de un proceso elemental que pueden ser de 2 tipos:
Ediciones, algoritmos o cálculos
Accesos a un fichero para consulta o actualización.
Tenemos las siguientes funcionalidades o elementos de función: (Están en DFD- Diagrama de Flujos de Datos)
a. Entradas
Def: es información que llega desde el exterior al sistema. Tiene una sola dirección (Exterior a Interior del sistema). Siempre actualiza algún fichero interno.
Ej: formulario de carga de algo.
Complejidad:
b. Salidas
Def: es la información elaborada por el sistema y que son transmitidas al usuario. Tiene una sola dirección (Interior al exterior del sistema)
Complejidad:
Def: son entradas que producen inmediatamente una salida. No se modifican los datos del sistema.
Ingreso una entrada, eso se busca a través de un proceso y devuelve una salida.
Complejidad:
Calculamos la complejidad de la parte de entrada
Calculamos la complejidad de la parte de salida
Nos quedamos sólo con la complejidad mayor de las dos.
d. Ficheros Lógicos o Internos
Def: son agrupaciones de datos, tal como los percibe el usuario. Es diferente de:
Entidades y Relaciones
Tablas o archivos resultantes del diseño físico
La agrupación de datos serán accedidos y actualizados por el sistema. Es responsabilidad del sistema
Lo podemos observar en un DFD (Diagrama de Flujo de Datos). Ej: cuando vemos factura, uno tiene la costumbre de ver cabecer, cuerpo y pie y ya empezamos a armar como DER, no lo tenemos que ver así sino como Factura solamente.
Complejidad:
Def: son ficheros a los que acceden la aplicación con el objetivo de obtener información. Son mantenidos por otras aplicaciones, hacemos consultas y sacamos información. Nunca los actualiza el sistema.
Ej: son los servicios que tiene mi sistema. Solicito mapas para mostrar a través de API a mi sistema.
Complejidad:
Puntos de Función sin ajustar (PFSA)
Todo lo visto antes en relación a la complejidad se registra en una tabla como la siguiente:
Los valores de peso están tabulados según el tipo de complejidad que uno toma (están en libros). Me dijo cuantas entradas simples tengo y multiplicó con peso de simple, cuantas media hay y multiplicó con ese peso y cuantas complejas hay y multiplicó con peso y así obtener el total de entradas.
Factores de complejidad
Def: son 14 factores que completan la visión externa del sistema. No están recogidos en la funcionalidad del sistema. Los valores que toman son entre 0 a 5.
¿Cuáles son los factores?
Comunicación de Datos: si los datos usados en el sistema se envían o reciben por algún medio de comunicación.
Proceso Distribuido: si existen procesos o datos distribuidos y su control forman parte del sistema.
Objetivo de rendimiento: si el rendimiento es un requisito del sistema. Es decir es criterio algún factor como tiempo de respuesta o cantidad de operaciones por hs. Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento.
Configuración de explotación usada por otros sistemas: El sistema tiene que ejecutarse en un equipo en el que coexista con otros compitiendo por los recursos y teniendo que tenerse en cuenta en la fase de diseño.
Es si nosotros damos algún servicio para que otra gente pueda ver.
Tasa de transacciones: si es elevada, se debe tener consideraciones especiales durante el diseño, la codificación e instalación.
Ej: En horas picos de los supermercados, cuando la cajera saca el ticket está un rato la máquina para sacar el ticket.
Entrada de datos Online: la entrada de datos será directa desde el usuario a la aplicación de forma interactiva.
Eficiencia con el usuario final: es una demanda por parte del usuario en su trabajo, es decir se tiene que diseñar e implementar el sistema con interfaces fáciles de usar y con ayudas integradas. Ej:
Menús, uso de ratón, ayuda en línea. Movimiento automático del cursor, efectos de scroll, teclas de función predefinidas, lanzamiento de procesos batch desde transacciones online, selección mediante cursos de daos de la pantalla, posibilidad de “hard-copy”, ventanas de “Pop-up”, aplicación bilingüe, aplicación multilingüe.
Actualizaciones en Línea: los ficheros maestros y las BD son modificadas directamente de forma interactiva.
Lógica de Proceso Interno compleja: en caso de ser así está en función de las siguientes características:
Especificación de algoritmos matemáticos complejos
Proceso con lógica compleja
Especificación con muchas excepciones que son consecuencia de transacciones incompletas, que deberán tratarse
Manejo múltiples dispositivos de entrada/ salida
Se incorporaron sistemas de seguridad y control.
Reutilización del código: se tiene que hacer consideraciones especiales durante el diseño, codificación y mantenimiento para que el código se reutilice en otras aplicaciones o lugares. Hablaremos de reutilización: dentro de la propia aplicación, por varios sistemas, parametrizable.
Si tengo que ser genérico y documentar para reutilizar.
Contempla la conversión e instalación: se proveerán facilidades de conversión en el sistema, se tendrá que hacer consideraciones especiales durante el diseño, codificación y pruebas para que la conversión del sistema antiguo sea fácil de realizar durante la puesta en marcha del sistema nuevo.
Hay que tener en consideración la instalación que es todo un proceso de preparación y por ejemplo la migración de datos del sistema viejo al nuevo.
Facilidad de operación:
Operación del sistema: los trabajos asignados al centro de proceso de datos. El arranque, parada, recuperación ante fallos, copias de seguridad o minimización de las actividades manuales en el CPD.
Se valora cuando ha sido descrita desde las primeras fases dedicando especial atención durante el diseño, codificación y pruebas.
Instalaciones Múltiples: El sistema ha de incluir los requerimientos de diversas empresas o departamentos en donde se ejecutará (incluso plataformas, máquinas, SO). Estas características estarán presentes durante el diseño, codificación y pruebas.
Facilidad de cambios: Se tendrá que hacer consideraciones especiales durante el diseño, codificación y mantenimiento para que en el sistema sea fácil de introducir cambios y fácil de adaptar al usuario. Ítems a tener en cuenta:
Consultas flexibles del usuario: Simples con condiciones. lógicas And/Or que implican un único fichero lógico, Medias con cond. lógicas sobre más de 1 F.L. (X2), Complejas con condiciones lógicas complejas que afectan a varios F.L. (X3)
Parámetros de la aplicación con tablas ajenas al código:
El cambio se hace efectivo al arrancar el sistema
El cambio es interactivo (X2)
Con estos 14 factores volcamos a una tabla donde calculamos su complejidad con una escala del 0 al 5. Sumo todo y obtengo Factor de Complejidad Total (FC).
Realizamos el cálculo de Puntos de Función Ajustado (PFA)
Cada factor de complejidad afecta en +/- 2,5% en los PFSA
PFSA * 65% <= PFA <= PFSA * 135%
COMBINACIÓN DE LOS ANTERIORES
Haciendo esto tengo cálculos más precisos donde vamos a tener más seguridad de las estimaciones que haga.
PUNTOS DE FUNCIÓN DE MK2
En definitiva, son dos métodos similares. El método de Albretch evolucionó a un método que se llama MK2.
Transacción Lógica:
Def: es una combinación única de entrada → proceso → salida desencadenada por un único evento de interés para el usuario, o una necesidad de recuperar información.
Ejemplo:
crear un cliente
actualizar una cuenta
generar un informe mensual
En definitiva, es una combinación de uno o más tipos de entrada, algún procesamiento, y uno o más tipos de salida correspondientes a un proceso lógicamente único
Ejemplos de transacciones
Extracción de un registro (o selección de registros de acuerdo a los parámetros de entrada) de un fichero maestro, y mostrarlo o imprimirlo
Añadir un nuevo cliente a un fichero maestro de clientes
Calcular el plan mensual de requerimientos de materiales
Es tarea del analista decidir qué es lo que se trata como transacción lógica, teniendo en cuenta qué es lo que genera procesamientos diferentes desde el punto de vista de los requerimientos del usuario.
Los procesos internos que suceden repetidas veces deben contarse en la transacción en la que aparecen. No deben contarse como transacciones diferentes a menos que se desencadenan por un suceso de significado para el usuario
Entidades
Def: es cualquier cosa del mundo real (objetos, transacciones, periodo de tiempo, etc.) donde queremos saber información.
Ejemplo:
Empleado (si)
Fecha de nacimiento (no), es un detalle
Entidades primarias
Def: son entidades para las que el sistema se ha construido con la intención de recolectar y almacenar datos.
Ejemplo: proveedor, cliente, pago, orden, etc. son todos tipos de entidades primarias
Cuenta de entidades
Hay que contar el número de entidades primarias a las que se hace referencia en una transacción (no el número de referencias a entidades en una transacción)
Por ejemplo, si una entidad es referenciada dos veces en una transacción (una para leer y otra para modificarla), se cuenta solamente una referencia a esa entidad en esa transacción.
Si una entidad se relaciona con ella misma, habrá que contarla dos veces
En el caso de tener que resolver relaciones 'varias a varias' (por ejemplo, en el modelo entidad relación)
las entidades se tratarán como si fueran una entidad más
Entidades Secundarias
Pueden aparecer ficheros con datos fijos que se utilizan con el propósito de referencia, validación, adaptación del sistema, etc
Ejemplos códigos de países, unidades de medida, departamentos, mensajes de error, etc
Todas estas entidades no primarias se engloban en una única denominada Entidad del Sistema
Si hay una referencia a estos ficheros de parámetros, la regla es contar una referencia a la Entidad del Sistema
Datos (Entrada / Salida)
Contar tipos de elementos de datos no ocurrencias de elementos de datos
Considerar todos los mensajes de error como posibles ocurrencias del tipo de datos "mensaje de error"
Considerar todos los mensajes del operador, como posibles ocurrencias del tipo "mensajes del operador"
Cuando un elemento de datos de entrada se vuelve a mostrar como salida, hay que contarlo como entrada y como salida
Cada transacción lógica debe tener, al menos, un elemento de datos de entrada
La cuenta de PF sin ajustar:
donde
Wi = es el peso para un elemento de datos de entrada
We = es el peso para una entidad referenciada
Wo = es el peso para un elemento de datos de salida
Ni = son los elementos de Datos de Entrada
Ne = son los elementos de Entidades Referenciadas
No = son los elementos de Datos de Salida
Pesos standards
Wi = 0.58
We = 1.66
Wo = 0.26
Ajuste de complejidad técnica
Se modifica el ajuste Albrecht en dos sentidos
Se amplía la lista de características generales. Se incluyen 5 características específicas más y se permite introducir otras (14 +5 = 19 en MK2)
Se permite determinar el peso del total de los grados de influencia por calibrado de la instalación
el peso de cada influencia se obtiene por un proceso de calibración, en vez de utilizar constantes
El factor se denomina 'Ajuste de la Complejidad Técnica', más que 'Factor de Ajuste del Valor'
Las cinco características técnicas que se incluyen son:
Requerimientos de otras Aplicaciones
Son los requerimientos del sistema para interfaces o comparación de datos deben ser sincronizados con otras aplicaciones.
El valor 5 se da cuando se deben sincronizar los requerimientos del sistema con cuatro o más aplicaciones
Seguridad, Privacidad y Auditoría
El valor 1 - Si el sistema debe cumplir requerimientos personales (incluso legales) de privacidad
El valor 2 a 4 - Si el sistema debe cumplir requerimientos excepcionales de seguridad para prevenir pérdidas de naturaleza financiera o militar
El valor 5 - Si se requiere el criptografiado de los datos de las comunicaciones
Necesidad de Adiestramiento al Usuario (Capacitación)
El valor 0 - Si no es necesario material ni cursos
El valor 1 a 4 - Si se requiere entrenamiento especial o se proporcionan facilidades de ayuda on line
utilización de facilidades de "help” estándares
desarrollo de facilidades de "help” especiales
entrega de material especial de adiestramiento
El valor 5 - Se requiere un sistema separado de entrenamiento o simulador
Uso directo de otras empresas
El valor 0 - No existe otra empresa conectada al sistema
El valor 1 - Los datos se envían o reciben de empresas conocidas
El valor 2 - Las Empresas conocidas están conectadas al sistema en modo de lectura solamente
El valor 3 y 4 - Las Empresas conocidas están conectadas directamente al sistema con capacidad de actualización on line
El valor 5 - Empresas desconocidas (público en general o un grupo demasiado extenso como para ser adiestrado) pueden acceder al sistema
Documentación
Cuento con 1 por cada tipo de documento listado a continuación que se entrega al final del proyecto
Especificación Funcional del Sistema (datos y procesos)
Especificación Técnica del Sistema
Documentación del programa (al menos diagramas de flujo)
Librería de Elementos de Datos
Elemento de Datos/ Registro/ X referencia del programa
Manual de usuario
Folleto de información general del sistema
Material de curso de adiestramiento al usuario
Documentos de coste/beneficio del sistema
Informe de petición de cambios y errores
A continuación que se entrega al final del proyecto. Se calcula el grado de influencia utilizando la siguiente tabla
Ajuste de la complejidad técnica (TCA)
Sumatoria GI es la suma del grado de Influencia para las 19 características de la aplicación, más las definidas por el cliente
El valor actual medio industrial de C es 0.005 por lo tanto
COCOMO (COnstructive COnst MOdel)
Def: es una herramienta utilizada para la estimación de algunos parámetros (costes en personas, tiempo,KLDC...) ;
en el diseño y construcción de programas
en la documentación asociada requerida
para desarrollarlos, operarlos y mantenerlos (Boehm), es decir, en la aplicación práctica de la Ingeniería del Software.
Es un modelo viejo, hasta hoy ya sufrió 2 evoluciones.
1 VARIACIÓN - COCOMO 81
Inicialmente se creó un modelo con un único modo de desarrollo, pero posteriormente se vio que la aplicación del modelo a una amplia variedad de entornos implicaba la creación de tres modelos de desarrollo, que están dividido por la cantidad de líneas de código:
Presenta una jerarquía de modelos de estimación según el nivel de detalle empleado en su utilización:
Lo que normalmente se toma es modelo de CV en espiral donde en cada vuelta etapas, donde se recalculan las estimaciones, porque tenemos precisiones y debemos ajustar las estimaciones.
Las estimaciones relacionadas con el coste (esfuerzo) se expresan en meses/hombre (tiempo que requeriría una sola persona para desarrollar el sistema), considerando que la dedicación de una persona es de 1 mes/h → 152 horas/mes
Modelo Básico:
Ejemplo
Un estudio inicial determina que el tamaño del producto estará alrededor de 32.000 LDC a partir de las anteriores ecuaciones obtendremos que las características del proyecto serían:
Por el tamaño del producto a desarrollar vemos que debemos aplicar las ecuaciones asociadas al modo orgánico, obteniendo lo siguiente
ED = 2,4 (32)1,05 = 91 hombre- mes
TD = 2,5 (91)0,38 = 14 meses
PR = 32.000 / 91 = 352 líneas/hombre- mes
PE = 91 / 14 = 6,5 hombres = 7 hombres
Modelo Intermedio
Este modelo es una versión ampliada del modelo Básico, en la que se presenta una mayor precisión en las estimaciones, manteniendo prácticamente la misma sencillez del anterior modelo. Esta mayor precisión viene dada por la incorporación de 15 factores que reflejan la influencia de ciertos elementos sobre el coste del software.
Estos 15 factores se agruparon en cuatro grandes grupos Atributos del Producto, del Computador, del Personal y del Proyecto
Cada uno de estos 15 atributos tiene asociado un factor multiplicador para estimar el efecto de éste sobre el esfuerzo nominal
Esfuerzo total: ED = EN * ϑfi
donde fi se corresponde con los 15 factores descritos anteriormente.
Si se observan los valores para el modelo Intermedio, se puede ver que los coeficientes escalares (3’2, 3’0, 2’ 8) decrecen a medida que se incrementa la complejidad del modo de desarrollo, al contrario que en el modelo básico.
Esta diferencia indujo a Conte y otros a presentar un conjunto de ecuaciones alternativas, cuyo comportamiento, según sus autores, mejora el de las ecuaciones originales del modelo Intermedio
Modelo Detallado
Este modelo presenta principalmente dos mejoras respecto al anterior modelo
Los factores correspondientes a los atributos son sensibles a la fase sobre la que se realizan las estimaciones, puesto que aspectos tales como experiencia en la aplicación, utilización de herramientas software, etc, tienen mayor influencia en unas fases que en otras
Establece una jerarquía de tres niveles de productos, de forma que
Los aspectos que presentan gran variación a bajo nivel, se consideran a nivel módulo
Los que presentan pocas variaciones a nivel de subsistema
Los restantes se consideran a nivel sistema
Calibración del modelo
El modelo puede ajustarse para mejorar la precisión de sus estimaciones, por las características propias de una instalación particular.
Este proceso puede realizarse por diversos procedimientos, no excluyentes
Calibrar las ecuaciones del esfuerzo nominal de acuerdo al comportamiento del proyectos finalizados
Consolidar o eliminar algunos de los atributos directores del coste
Añadir otros atributos que pueden ser más significativos en la instalación en particular
Situación a principios de los 90
Al inicial modelo de estimación de costes COCOMO 81 le siguió una actualización para el lenguaje Ada en 1987 que recibió el nombre de Ada COCOMO. Desde entonces el desarrollo de nuevos ciclos de vida ocasionados por la evolución del desarrollo del software, ha incrementado la dificultad de estas estimaciones. Y estamos hablando de términos como desarrollo rápido de aplicaciones, aplicaciones no secuenciales, reusabilidad del software, reingeniería, programación orientada a objetos etc.
2 VARIANTE - COCOMO 2
Actualmente una nueva generación de procesos y productos software está cambiando la forma en que las organizaciones desarrollan software, intentando ser más competitivas.
Estas nuevas aproximaciones procesos software colaborativos, evolucionarios, y centrados en los riesgos
generadores de aplicaciones y lenguajes de cuarta generación ;
“commercial off the shelf”(COTS) y dependientes de la reutilización que se deba hacer del software llevan a significativos beneficios
en términos de calidad software y reducción de coste que supone su desarrollo, reducción de riesgos y del
tiempo de ciclo
Objetivos
El desarrollo de un modelo de estimación de costes y planificación que pudiera ser utilizado en el ciclo de vida de la década de los 90 y posterior al 2000
Desarrollar una base de datos indicativa del coste del software y un soporte de herramientas con la capacidad suficiente para el continuo progreso y perfeccionamiento del modelo
Proporcionar un cuantioso y analítico marco de trabajo, y un conjunto de herramientas y técnicas para la evaluación de los efectos que la tecnología software tiene sobre el coste de los ciclos de vida software y de planificación
Capacidades
Los ajustes a medida dependen del software a desarrollar,
Se involucra en la estimación del coste a los puntos objeto (object points), puntos función (function points) y líneas de código fuente
Esto se utiliza para la modelizaciones no lineales para atender a la reingeniería y reusabilidad del software,
y todo esto sobre la base del anterior COCOMO
4 elementos principales
Preservar las habilidades y apertura del modelo original, para que continúe siendo un modelo abierto y público ( parametrizaciones, etc)
Adaptar la estructura de COCOMO II a los futuros sectores del mercado software descritos antes
Adaptar las entradas y salidas de los submodelos de COCOMO II al nivel de información disponible en cada etapa
Permitir a los submodelos de COCOMO II ajustarse a la medida dependiendo de la estrategia utilizada en cada proyecto particular (atender a las distintas calibraciones de los submodelos que se utilicen para obtener mayor fiabilidad en la estimación global)
COCOMO II permite a los proyectos suministrar a los parámetros de coste una información rudamente granulada en los primeros estados del proyecto, para ir incrementándose más detalladamente granulada según se avanza en los estados.
El modelo COCOMO II proporciona los siguientes 3 estados (series de modelos) para la estimación de Generadores de Aplicaciones, Integración de Sistemas, e infraestructura de proyectos software
Incluye este modelo, el desarrollo y mantenimiento último del producto software. Se utilizan:
Instrucciones fuente y/o puntos función para la estimación, existiendo modificadores que los operan un conjunto de :
17 factores multiplicativos de evaluación de coste, y
5 modos para dimensionar el proyecto, que sustituyen a los anteriores modos Orgánico, Semiempotrado y Empotrado del COCOMO original.
PUNTOS DE CASO DE USO (PCU)
Def: es una forma de estimar el esfuerzo de un proyecto tomando como base los CU de la metodología de Proceso Unificado (PU). El cálculo es en función de Actores y Casos de Usos.
Peso de Actores sin ajustar(UAW) = Actores * Peso
Peso de CU sin ajustar (UUCW) = Casos de Uso * Peso
Punto de CU sin ajustar (UUCP) = UAW + UUCW
Punto de CU (UCP)= UUCP*TCF*ECF
TCF Technical Complexity Factor
ECF Environmental Complexity Factor
Estimación total (horas persona) = UCP * Factor de Productividad (Horas Persona por Punto de Caso de Uso)
Factor de productividad típico = 20
Pesos de CU
Pesos de Actores
Cálculo de PCU sin Ajustar
Falta realizar los ajustes por factores:
Técnicos y
Ambientales
13 FACTORES TÉCNICOS
A cada ítem se le asigna un valor de entre 0 a 5 y se multiplica por el peso Technical Complexity Factors: TCF=0.6+ (0.01*TFactor)
Fórmula para calcular TCF:
8 FACTORES AMBIENTALES
A cada ítem se le asigna un valor de entre 0 a 5 y se multiplica por el peso Environmental Complexity Factors: ECF= 1.4+ ( 0.03 * EFactor)
La estimación del esfuerzo que hacemos en PCU no es del total del proyecto, si no que es aproximadamente un 40% del proyecto. Lo que se debe hacer es llevarlo al 100% con una regla de 3 simples.
ESTIMACIONES ÁGILES
Estos métodos están muy de auge. Tienen las principales características
Las estimaciones son hechas por el equipo de trabajo
Las estimaciones no pretenden ser absolutas sino relativas
Se busca consenso entre los estimadores
Proceso (Wideband simplificado)
Tomar una US
Debatir brevemente
Cada integrante del equipo propone el valor
Se repite el proceso si no hay consenso
Valores
1 a n en general n= 5
Fibonacci 1, 2, 3, 5, 8, 13,…,“no estimable”
Comienzan a ser más precisa al conocer mi velocity
Estimaciones Agiles del Proyecto completo
Se toma el backlog completo
Se estiman todos los ítems del backlog
Se aplica la “velocidad esperada”. Si no se conoce, se estima
Esto implica definir un equipo o equipos a asignar
Se calcula la duración total del proyecto
Comentarios
Publicar un comentario