1. Juicio de expertos (Wideband Delphi)
1.1. El método wideband Delphi es una técnica de estimación estructurada en grupo. Deriva de un método creado en los 40.
1.2. Se basa fundamentalmente en que varios expertos, tras crear estimaciones individuales, se reunen para ponerse de acuerdo en una estimación.
1.3. Proceso mejorado
1.3.1. 1 - El coordinador presenta a cada experto la especificación y un formulario de estimación.
1.3.2. 2 - Los estimadores trabajan individualmente. (Se puede hacer esto tras el paso 3)
1.3.3. 3 - Se hace una reunión en la que los expertos hablan de los posibles problemas de estimación.
1.3.4. 4 - Los expertos rellenan las estimaciones y se las dan al coordinador de manera anónima.
1.3.5. 5 - El coordinador prepara un resumen de las estimaciones y la reparte a todos los expertos.
1.3.6. 6 - Se reunen tanto el coordinador como los expertos para ver variaciones en las estimaciones.
1.3.7. 7 - Los expertos votan anónimamente si aceptan la estimación media. Si alguien vota que no se vuelve al paso 3.
1.3.8. 8 - La estimación final es una estimación única (single-point estimate). También podría ser un rango creado durante la estimación en la que la single-point es el caso esperado (recordad lo de caso más probable, menos probable y caso esperado).
2. Componente estándar
2.1. se basa en matener una base de datos historica con informacion de componetes usados en proyectos previos
2.1.1. Caracteristicas
2.1.1.1. Metodologia basada en puntos de funcion, PROBE y RWSC
2.1.1.2. Concidera la informacion historica en funcion del contexto de cada proyecto
2.1.1.3. Este metodo se utilizan los PF como unidad de medida de esfuerzo del equipo
2.1.1.4. Loos Requisitos son Clasificados en componentes estandares(PROBE) y no del proyecto que se va a desarrollar
2.1.2. Proceso del CEPF
2.1.2.1. Definicion de Elementos Basicos
2.1.2.2. Uso del Metodo CEPF
2.1.2.3. Mantener Historia
2.1.2.4. Estimacion
2.1.3. Uso del metodo CEPF
2.1.3.1. Buscar Parametros de Estimacion
2.1.3.2. Calcular el tamaño del proyecto
2.1.3.3. Obntener estimacion del proyecto
3. Puntos de función (Function Points)
3.1. s una técnica de medición de las funcionalidades ofrecidas por un software desde el punto de vista de sus usuarios. Punto de función (FP, pos sus siglas en inglés) , que es su unidad de medida, tiene por objetivo tornar la medición independiente de la tecnología utilizada para su construcción.
3.2. Las principales técnicas de estimación de proyectos de desarrollo de software asumen que el tamaño de software es un vector importante para la determinación del esfuerzo para su construcción. Por lo anterior, saber su tamaño es uno de los primeros pasos del proceso de estimación de esfuerzo, plazo y costo.
3.3. Es importante destacar que los puntos de función no miden directamente el esfuerzo, la productividad y el costo. Es exclusivamente una medida de tamaño funcional del software. Los puntos de función en conjunto con otras variables, son usados para derivar la productividad, estimar el esfuerzo y el costo del proyecto de software.
4. Puntos de casso de uso (Use Case Points)
4.1. Su principal ventaja es su rápida adaptación a empresas que ya estén utilizando la técnica de Casos de Uso.
4.1.1. Pasos de Metodo
4.1.1.1. 1.- Clasificar cada interacción entre actor y caso de uso según su complejidad y asignar un peso en función de ésta. Para poder clasificar la complejidad de los actores debemos analizar la interacción de éste con el sistema que se va a desarrollar.
4.1.1.2. 2.- Calcular la complejidad de cada caso de uso según el número de transacciones o pasos del mismo. Para calcular la complejidad de un caso de uso debemos determinar el número de transacciones, incluyendo los caminos alternativos.
4.1.1.3. 3.- Calcular los Puntos Casos de Uso No Ajustados (UUCP) del sistema. Se obtienen sumando los Puntos Casos de Uso de todos y cada uno de los actores y casos de uso que se han identificado y catalogado en función de su complejidad.
4.1.1.4. 4.- Cálculo de los Factores Técnicos (TCF). A cada uno de los Factores Técnicos de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media.
4.1.1.5. 5.- Cálculo de los Factores de Entorno. A cada uno de los Factores de Entorno de la tabla siguiente se le asigna un valor de influencia en el proyecto entre 0 (no tiene influencia) a 5 (esencial), 3 se considera de influencia media.
4.1.1.6. 6) Obtención de los Puntos Casos de Uso Ajustados. Una vez calculados los dos factores calculamos el valor ajustado de Puntos Casos de Uso con la siguiente fórmula
5. Agile Points (Story Points)
5.1. Los puntos de historia son un artefacto abstracto que nos permite ponernos de acuerdo más fácilmente en la complejidad, esfuerzo y riesgo que tiene una determinada tarea
5.1.1. Complejidad: Una historia que es más compleja que otra tendrá más puntos historia.
5.1.2. Incertidumbre o riesgo: Es la probabilidad de que algo no esperado aparezca en la historia, siempre por falta de información previa. Aquí no se cuenta lo que suele ir mal. Por ejemplo, si cada vez que tocamos el módulo de autenticación rompemos algo, eso no debe reflejarse en la estimación (porque no queremos tapar los puntos de mejora).
5.1.3. Esfuerzo: Quizás una historia no tiene complejidad pero si requiere esfuerzo (ejemplo, cambiar literales en todas las pantallas de la aplicación), también tendrá más puntos historia que otra más corta.
5.2. Caractericitcas
5.2.1. El «tiempo que se tardará» frente «al tamaño»
5.2.2. Mayor consenso entre las personas del equipo
5.2.3. Menor tiempo de estimación
5.2.4. Menor estrés en el equipo
6. Fuzzy Logic
6.1. la logica difusiba o Fuzzy Logic es una metodologia que proporciona una manera simple y elegante de obtener una conclusion a partir de informacion de entrada vaga,ambigua,imprecisa, con ruido o incompleta
6.1.1. Zadeh dice: "La Logica difusa trata fr copiar la forma en que los humanos toman decisiones. lo curioso es que, auque baraja informacion imprecisa, esta logica es en cierto modo muy precisa: sepuede aparcar un coche en muy poco espacio sin darle al de atras. Suena a paradoja, pero es asi."
6.1.1.1. Tipo de sistemas de logica difusa
6.1.1.1.1. Sistema Tipo Mamdani
6.1.1.1.2. Sistemas de Tipo Sugeno
6.1.1.2. 7 verdades de la logica difusa
6.1.1.2.1. 1.- logica confusa no es confusa, la logica confusa no es intrinsecamente imprecisa, no viola el sentido comun ni produce resultados inequivocos.
6.1.1.2.2. 2.- La logica confusa es diferente de probabilidad
6.1.1.2.3. 3.- Diseñar sistemas borrosos es facil, lo que la gente piensa realmente de un problema.
6.1.1.2.4. 4.- Los sitemas borrisis son estables y facilmente ajustables y pueden ser validados.
6.1.1.2.5. 5.- Los sistemas borrosos son Redes Neuronales
6.1.1.2.6. 6.- La logica confusa es mas que control de proceso
6.1.1.2.7. 7.- La lógica confusa es un proceso de representación y razonamiento.
7. Proxy Baded Estimation (PROBE)
7.1. La estimación de proyectos software es una tarea muy compleja, pero de vital importancia en toda la etapa de desarrollo del software.
7.2. Algunos de los principios a tener en cuenta para la realización de una estimación de software.
7.2.1. Retrasar la estimación lo máximo posible. Cuanto más se retrase, más precisa será.
7.2.2. Hacer estimación por analogía. Utilizar el costo de proyectos similares.
7.2.3. Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.
7.2.4. Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en el proyecto.
7.2.5. Existen técnicas de descomposición. Estimas el costo descomponiendo el producto y/o el proceso.
7.2.6. Existen modelos empíricos. Modelos de regresión que relacionan esfuerzo con tamaño o funcionalidad.
7.3. Factores importantes a considerar
7.3.1. Complejidad del proyecto.
7.3.2. Tamaño del proyecto.
7.3.3. Estabilidad de los requerimientos.
7.3.4. Facilidad de identificar funciones.
7.3.5. Estructura de la información.
7.3.6. Disponibilidad de información histórica.