Características principales



Documentos relacionados
Guía práctica para COCOMO 2.0 Ingeniería de Software Avanzada

Estimación de Costos

Estimación de Proyectos Software

Los modelos de estimación de costos analizan la economía y deseconomía de escala. Es frecuente lograr economía en proyectos gracias a la inversión en

ADMINISTRACIÓN DE PROYECTOS. Facultad de Estadística e Informática

Estimación de Costos de Proyectos de Software

- COCOMO - UN MODELO DE ESTIMACION DE PROYECTOS DE SOFTWARE RESUMEN. Adriana Gómez, María del C.López, Silvina Migani, Alejandra Otazú

SW-CMM Capability Maturity Model for Software

Estimación de costos y esfuerzos. Calidad en el Desarrollo de Software. Estimación de costos para el software. Planificación de proyectos

Estimación de Proyectos Software TEMA 7: COCOMO II Ana Mª Moreno S.-Capuchino Pag. 84

Ingeniería de Software Avanzada

P.S.P. Programa Educativo. Tecnologías de la Información y Comunicación. Alumno. José Alfredo Ramírez Jaguey

Los procesos de software. Un proceso de software se define como un:

ESTIMACIÓN DE COSTOS UTILIZANDO EL MODELO COCOMO II. Gónzalez Nuñez Humberto Mendoza Hidrogo Greta Rosales López Zahira Oviedo Hernándes Guillermo

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

Ingeniería de Software

Tecnología de la Información. Administración de Recursos Informáticos

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F SUMA FACTORES DE AJUSTE: 32

Técnicas de gestión de proyectos

Qué es el Modelo CMMI?

Gestión de las Pruebas Funcionales

La Medición funcional en la gestión de proyectos de software

CAPÍTULO 5. Un modelo empírico de estimación para software puede utilizar fórmulas

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

JUSTIFICACIÓN DEL DESARROLLO DE UN SE

Personal Software Process

CMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM

Gestión y Desarrollo de Requisitos en Proyectos Software

Medición de Productividad de Software

MINING SOLUTIONS LIMITADA

Escuela Politécnica Superior. Organización Empresarial y Proyectos. Capítulo 6. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS

Programa de Desarrollo Profesional en Mejora del Proceso de Software

CICLO DE VIDA DEL SOFTWARE

E t s ima m c a i c ón ó n en e n pr p oy o e y c e t c os o s de d s f o twa w r a e

Copyright bizagi. Gestión de Cambios Documento de Construcción Bizagi Process Modeler

TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC CALIDAD DE SOFTWARE Guía para Examen Segundo Parcial Grupo 6501

Instalación de Sistemas de Automatización y Datos

FÁBRICA DE SOFTWARE. Presentado por: Ing. Juan José Montero Román Gerente de Fábrica de Software USMP

Proceso de desarrollo del software modelo en cascada

2 EL DOCUMENTO DE ESPECIFICACIONES

Industrial Data ISSN: Universidad Nacional Mayor de San Marcos Perú

Sede Escazú, Plaza Tempo

CURSO COORDINADOR INNOVADOR

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Técnica 2(Instrumental)

DISEÑO DE SOFTWARE INTEGRADO Unidad I: Introducción al Diseño de Software Integrado. Profesor: Cristián Chávez T

Ingeniería de Software

Qué ofrece un diagnóstico a un área de calidad. Agosto ra visita de ISQI - HASTQB

Planeación del Proyecto de Software:

Calidad. Preparado por: Amelia Soriano. Referencias. Rational Unified Process Version Copyright Rational Software Corporation

CMMI. Capability Maturity Model Integration. José María Molero Alonso Juan Resinas Arias de Reyna Antonio Pablo Vicente Domínguez Palacios

3. METODOLOGIA, ESTRATEGIAS, TECNICAS Y HERRAMIENTAS PARA EL DESARROLLO DEL PROYECTO

Sistema de Gestión de Proyectos Estratégicos.

Técnico Certified Software Engineer Professional (CSIP)

Ingeniería de Software. Procesos. Proyecto de Ingeniería. Metodologías. Metodologías. Metodologías. Metodologías de desarrollo

Agile ITIL. Proyectos de Implantación Ágil


SCRUM Metodología de trabajo ágil

PROF PROF INFORME VISIÓN GLOBAL DE CMM ÍNDICE

Programa Memoria del Proyecto: Páginas Amarillas

ANÁLISIS Y GESTIÓN DEL DESARROLLO DE SOFTWARE TEMA 1: INTRODUCCIÓN AL PROCESO SOFTWARE PERSONAL

Manual Operativo SICEWeb

Análisis y cuantificación del Riesgo

everis, líder en implantación de soluciones de Business Intelligence

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP TEMA 4 MODELOS, METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD

Caso Particular: Administración y Control de Proyectos II. Planificación Aprobada. Ejecución y Control. Administración del Cambio

Implementación de Paquetes

Information Technology Infrastructure Library

Conceptos Básicos. El Instituto de administración de Proyectos, PMI, define un proyecto como:

Ingeniería de Software

Instituto Nacional de Tecnología Industrial TESTING DE SOFTWARE

Marketing de comportamiento

Adelacu Ltda. Fono Graballo+ Agosto de Graballo+ - Descripción funcional - 1 -

Diplomado: Administración de Centros de Cómputo (Sites)

MODERNIZANDO PCN Y RECUPERACION DE DESASTRES UTILIZANDO VIRTUALIZACION Y LA NUBE

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

RUP: Disciplina de Manejo de Cambios y Configuraciones

Medición de la Productividad de Proyectos de Software Desarrollados en Dos Empresas Ecuatorianas.

Tema 3 Metodologías de Desarrollo de Software

Certificación Certificación como Business Process Management Professional (CPP)

Tabla Tabla de equivalencia entre asignaturas de Ingeniería Técnica en Informática de Gestión al Grado en Ingeniería Informática. Créd LRU.

Ciclo de vida del Software

Implantación de Aplicaciones Web Fecha:

1.1 Aseguramiento de la calidad del software

PROCEDIMIENTO PARA EL ANALISIS DE RIESGOS R12-MLACSH-DMSH

Ciclo de Vida del Desarrollo de un Sistema de Información. Departamento de Ingeniería Industrial Universidad de Chile

BUSINESS INTELLIGENCE PARA LA EMPRESA CARLON S.A EN EL PROCESO DE PRODUCCION

Ingeniería de Software: Parte 2

Ingeniería de Software I

10 PRÁCTICAS BASALES DE LA GESTIÓN DE PROYECTOS INFORMÁTICOS EN CUBA

Transcripción:

Modelo COCOMO 2.0 Nuevo escenario cambios en tecnología de software nuevos modelos de ciclo de vida nuevas herramientas reingeniería generadores de aplicaciones enfoques orientados a objetos etc Modelo COCOMO 2.0 Características principales mayor variedad de técnicas y tecnologías uso de diferentes modelos de tamaño según se avanza en el desarrollo y se conoce más del sistema se basa en tres etapas principales de un proceso de desarrollo, reconociendo que es imposible conocer tamaño en LOC en forma temprana en el ciclo de vida dado que es nuevo, no hay datos publicados acerca de su precisión Page 1

Modelo COCOMO 2.0 Etapa 1 normalmente se conoce poco del tamaño probable del producto final, se trabaja con prototipos para resolver aspectos de alto riesgo, por lo que el tamaño se estima en puntos de objeto ( u object points, que capturan el tamaño en términos de generadores de esfuerzo de alto nivel: número de tablas de datos de clientes y de servidores, % de pantallas e informes reusados desde proyectos anteriores) Modelo COCOMO 2.0 Etapa 2 se ha decidido continuar con el desarrollo, pero deben explorarse arquitecturas y conceptos de operación alternativos... se conoce más que en la etapa anterior, pero no suficiente como para estimar con precisión... se utilizan puntos de función como estimador de tamaño pues ofrecen una descripción mejor que los puntos de objeto para estimar la funcionalidad capturada en los requerimientos Page 2

Modelo COCOMO 2.0 Etapa 3 ha comenzado el desarrollo y se cuenta con mucha más información, se estima el tamaño en términos de LOC y se utilizan los cost drivers de una manera similar al modelo original, incorporando modelos de reuso, nuevos cost drivers, nuevos valores de parámetros, tomando en cuenta además la mantención Cocomo 2: Etapa 1 Estimación de esfuerzo: E=NOP/PROD E: esfuerzo en personas-mes NOP: New Object Points, NOP PROD: razón de productividad Page 3

Cocomo 2: Etapa 1 Paso 1: Identificación de los tipos de objeto: Ventanas Informes Componentes de tercera generación Paso 2: Clasificación de cada tipo de objeto en niveles de complejidad. Cocomo 2: Etapa 1 Ventanas Número de vistas Número y fuentes de tablas de datos Contenidas Total < 4 Total < 8 Total >8 <3 simple simple media 3-7 simple media difícil >8 media difícil difícil Informes Número de vistas Número y fuentes de tablas de datos Contenidas Total < 4 Total < 8 Total >8 0-1 simple simple media 2-3 simple media difícil >4 media difícil difícil Page 4

Cocomo 2: Etapa 1 Paso 3: Calculo de los puntos objetos (Object Points, OP). Tipo de objeto Complejidad - Peso Simple Media Difícil Subtotal Ventana x 1 x 2 x 3 = Informe x 2 x 5 x 8 = Componente de 3GL x 10 = Total OP = Cocomo 2: Etapa 1 Paso 4: Calculo de los Nuevos Puntos Objetos (New Object Points, NOP). NOP= (OP)/(100-%r)/100,donde %r corresponde a los objetos de proyectos previos que serán reutilizados en el proyecto actual. Page 5

Cocomo 2: Etapa 1 Paso 5: Determinación de la razón de productividad PROD: Experiencia y capacidad de los desarrolladores Muy Baja Baja Nominal Alta Muy Alta Madurez y capacidad de ICASE Muy Baja Baja Nominal Alta Muy Alta PROD 4 7 13 25 50 Cocomo 2: Etapa 1 Paso 6: Calculo del esfuerzo. E=NOP/PROD Page 6

Estimación del esfuerzo: PM nominal = A* (Tamaño) B,donde» A: constante (Temporalmente Etapa 2 A= 2,45; Etapa 3 A= 2,55)» B: factor de economía y des-economía» Tamaño: KSLOC Factor de escala de economía y des-economía: B= 0,91 + 0,01* Σ w i Page 7

Factores de escala:» Precedentedness (PREC): captura la experiencia previa en cuanto al desarrollo de proyectos similares.» Development Flexibility (FLEX): cuán flexible es el proceso de desarrollo en relación con los requerimientos establecidos.» Architecture/ Risk Resolution (RESL): pondera el nivel de riesgo asociado al proyecto y el porcentaje de respuesta que es capaz de lograr la organización ante la ocurrencia de algún riesgo.» Team Cohesion (TEAM): captura el tipo de interacción al interior del proyecto y su impacto sobre él.» Process Maturity (PMAT): nivel de madurez de la organización en relación con las áreas de prácticas claves (Key Practices Areas, KPA) del CMM. Scale Muy Bajo Nominal High Very Extra Fators Bajo High High (w i ) 5 4 3 2 1 0 PREC thoroughly unpreceden ted largely unpreceden ted FLEX rigorous occasional relaxation RESL little some (20%) (40%) TEAM PMAT very difficult interactions some difficult interactions somewhatu nprecedent ed some relaxation often (60%) basically cooperative interactions generally familiar general conformity Generally (75%) Largely cooperative largely familiar throughly familiar some general conformity goals mostly full (90%) (100%) highly cooperative Weighted average of Yes answers to CMM Maturity Questionnaire seamless interaction Page 8

Factor de escala PMAT: KPA (18): Gestión de los requerimientos, Planificación del proyecto, Monitoreo y seguimiento del proyecto, Gestión de subcontratos, SQA, SCM, Organización centrada en el proceso, Definición del proceso, Programas de capacitación, Gestión de software integrada, Coordinación intergrupal, Ingeniería del producto de software, Revisiones por pares, Gestión cuantitativa del proceso, Gestión de calidad del software, prevención de defectos, Gestión del cambio tecnológico, Gestión del cambio del proceso. Cada una de estas áreas es catalogada como:» Casi siempre (>90%)» Frecuentemente (60-90%)» Cerca de la mitad de las veces(40-60%)» Ocasionalmente (10-40%)» Rara vez (<10%)» No se aplica» No se sabe PMAT= 5 - Σ (((KPA%*i)/100)*5/18),i=1,..,18 Page 9

Estimación de tamaño: LOC:» Checklist de definición de LOC del SEI Function Points» Se contabilizan sólo los UFP, los cuales son transformados a LOC mediante tablas pre-establecidas. Estimación de tamaño, Ajuste para reuso Entradas:» ASLOC: amount of software to be adapted» DM: % design modified» CM: % code modified» IM: % of modification to the original integration effort required for integrating the reused software Page 10

Estimación de tamaño, Ajuste para reuso SU: software understanding AA: nivel de evaluación y asimilación requerido para determinar cuando un modulo es apropiado o no para la aplicación y para integrar su descripción a la descripción del producto. UNFM: programmer`s relative unfamiliarity with the software. Muy Bajo Nominal High Very High Bajo SU (%) 50 40 30 20 10 Structure Application Clarity Self Descriptive ness Very low cohesion, high coupling, spaghetti code No match between program and application world views Obscure code; documentatio n missing, obscure or obsolete Moderately low cohesion, high coupling Some correlation between program and application Some code commentary and headers; some useful documentation Reassonably well structured, some weak areas Moderate correlation between program and application Moderate levels of code commentary, headers, documentations High cohesion, low coupling Good correlation between program and application Good code commentary and headers, useful documentation; some weak areas Strong modularity, information hiding in data/control structures Clear match between program and application world views Self descriptive code, documentation up to date, well organized with design rationale Page 11

AA Increment 0 None Level of AA Effort 2 Basic module search and documentation 4 Some module Test and Evaluation, documentation 6 Considerable module Test and Evaluation, documentation 8 Extensive module Test and Evaluation, documentation UNFM Increment Level of Unfamiliarity 0,0 Completely familiar 0,2 Mostly familiar 0,4 Somewhat familiar 0,6 Considerably familiar 0,8 Mostly unfamiliar 1,0 Completely unfamiliar Page 12

Estimación de tamaño, Ajuste para reuso ESLOC=[ASLOC(AA+AAF(1+0,02(SU)(UNFM)))]/100, AAF<=0,5 ESLOC=[ASLOC(AA+AAF+(SU)(UNFM))]/100, AAF>0,5 AAF= 0,4(DM) + 0,3(CM) + 0,3(IM), donde» ESLOC: líneas de códifo equivalentes Estimación de tamaño, Ajuste para reingeniería PM nominal = A* (Tamaño) B + [ASLOC (AT/100)/ATPROD] ASLOC: amount of software to be adapted AT: %of code that is re-engineering by automatic translation ATPROD: productivity for automated translation (temporalmente, 2400) Page 13

Re-engineering target AT Batch processing 96% Batch with SORT 90% Batch with DBMS 88% Batch, SORT, DBMS 82% Interactive 50% Ajuste del esfuerzo nominal Etapa 2: PM ajustado = PM nominal * Π EM i,,i=1,..,7 Etapa 3: PM ajustado = PM nominal * Π EM i,,i=1,..,17 EM: effort multipliers (cost drivers) Page 14

Ajuste del esfuerzo nominal: Etapa 2 PERS (Personal Capability): captura las potencialidades de analistas y programadores (ACAP y PCAP) y la tasa de rotación del personal (PCON). RCPX (Product Reliability and Complexity): contempla la influencia de la confiabilidad del software (RELY), el tamaño de la base de datos (DATA), la complejidad del producto (CPLX), y la documentación requerida (DOCU). RUSE (Required Reuse): esfuerzo adicional requerido para construir componentes que deberán ser reutilizados tanto en el proyecto como por proyectos futuros. (RUSE). PDIF (Plataform Difficulty): refleja es esfuerzo adicional requerido como producto de las restricciones de tiempo de ejecución (TIME), almacenamiento principal (STOR), y volatilidad de la plataforma (PVOL). PREX (Personnel Experience): abarca la experiencia en relación con la aplicación (AEXP), la plataforma (PEXP), y el lenguaje y las herramientas para el desarrollo (LTEX). FCIL (Facilities): captura el uso de herramientas de apoyo al desarrollo del software (TOOL) y si el proceso de desarrollo es realizado en lugares múltiples (SITE). SCED (Schedule): busca capturar restricciones de tiempo de desarrollo impuestas. Page 15

Ajuste del esfuerzo nominal: Etapa 3 Factores de producto» RELY, DATA, CPLX, RUSE, DOCU Factores de plataforma» TIME, STOR, PVOL Factores de plataforma» ACAP, PCAP, AEXP, PEXP, LTEX, PCON Factores del proyecto» TOOL, SITE, SCED Estimación del tiempo de desarrollo TDEV= [3,67*(PM x ) (0,28+0,2*(B-1.01)) ]*SCED%/100 TDEV: tiempo de desarrollo desde la etapa de requerimientos hasta la aceptación del producto en relación con los requerimientos. PM x : estimación de personas mes excluyendo el multiplicador SCED Page 16

Mantención: (Tamaño) M = [(Tamaño del Código Base)*MCF]MAF MCF: maintenance change factor, % de cambios en el código base (similar al ACT de Cocomo 81) MCF= (Tamaño agregado + Tamaño modificado)/tamaño del Código Base Mantención: MAF : maintenance adjustment factors MAF= 1+((SU/100)*UNFM) PM M =A*(Tamaño M ) B * Π EM i,,i=1,..,17 PM M= T M* FSP M Page 17

Cocomo 2 Rangos de esfuerzo: Modelo Estimación optimista Estimación pesimista Etapa 1 0,5 E 2,0 E Etapa 2 0,67 E 1,5 E Etapa 3 0,80 E 1,25 E Cocomo 2 Trabajos futuros: COCOTS (COnstructive COTS) COQUALMO (COnstructive Quality MOdel) CORADMO (COnstructive Rapid Application Development MOdel) COSSEMO (COnstructive Staged Schedule and Effort MOdel) COPROMO (COnstructive PROductivity improvement Model) Page 18