Definicin y Propuesta de un Marco de Estimacin de Proyectos Software
DEFINICIN Y PROPUESTA DE UN MARCO DE
ESTIMACIN DE PROYECTOS SOFTWARE Antonio Lpez-Fuensalida Doctorado U..E.D. !""#-!""! P$%ina # Definicin y Propuesta de un Marco de Estimacin de Proyectos Software INDICE 1. Resumen 4 2. ntroduccin 5 3. Mtricas base utilizadas en el estudio 8 3.1. Mtodo de Puntos Funcin del FPUG V 4.1 8 3.2. Tablas resumen del mtodo de Albrecht 10 de Puntos Funcin 4. Estudio de situacin actual 12 4.1. Repositorio del SBSG V. 6.0 12 4.1.1. Datos Demogrficos del Repositorio 12 4.1.2. Anlisis de Datos Demogrficos 15 4.1.3. Tablas resultado del Repositorio 16 4.1.4. Anlisis de aplicacin a CM del Repositorio 20 4.2. Otras referencias 23 4.2.1. DASMA Aproximacin a los Puntos Funcin 23 a travs de cinco componentes 4.2.2. niciativa COSMC-FFP V 2.1 25 4.2.2.1 Principios de identificacin COSMC-FFP 25 5. Aproximacin a la evaluacin de complejidad de modelos 28 conceptuales de bases de datos 5.1. Mtricas del modelo entidad/relacin 28 orientadas a la estimacin esfuerzos de mantenimiento 5.2. Mtricas del modelo entidad/relacin 30 orientadas a la estimacin del nivel de calidad del modelo 5.3. Conclusiones y propuestas 31 6. Mediciones en el mbito de CM Comunidad de Madrid 32 6.1. Mediciones de procesos - Estimaciones por entornos 32 6.2. Mediciones de datos - Esfuerzo de proyectos y 40 complejidad de los modelos de datos 7. Conclusiones y propuestas 47 7.1. Estimaciones iniciales de tamao y esfuerzo 48 7.2. Estimaciones tempranas 49 7.3. ntroduccin de los factores de ajuste 50 8. Aplicacin para la estimacin de proyectos: Proyecto MDE 52 P$%ina ! Definicin y Propuesta de un Marco de Estimacin de Proyectos Software
Bibliografa Manual de Medicin de Puntos de Funcin V 4.1 del FPUG Practical Project Estimation (SBSG Release 6.0) Manual de Medicin COSMC-FFP Versin 2.1 Mtrica V3 Ministerio de Administraciones Pblicas Pressman, R.S, "ngeniera del Software. Un enfoque prctico" 3 edicin. Prentice-Hall, 1993. Ponencias Conferencia FESMA 2000 Function Point Approximation with the five Logical Components Manfred &undsc'u'( Presidente de DASMA An approach to evaluate the complexity of conceptual database models Uni)ersidad *astilla-La Manc'a Software Project Estimation based on knowledge adquisition Facultad de +nform$tica Uni). Polit,cnica de Madrid y E.-.S. de +nform$tica de la Uni). *arlos +++ de Madrid Ponencias 19th nternational Conference on Conceptual Modeling ER2000 Salt La.e *ity( Uta'( USA( /cto0er !""" Measuring the Quality of Entity Relationship Diagrams Uni)ersidad *astilla-La Manc'a nternational Journal of Software Engineering and Knowledge Engineering A Metric-based approach forpredicting conceptual data models maintainability Uni)ersidad *astilla-La Manc'a P$%ina 1 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software 1. Re!"e# El trabajo consiste en la realizacin de un anlisis de la situacin actual de propuestas sobre mtricas y estimacin de proyectos de desarrollo de software alrededor de la lnea de estimacin en base a puntos funcin, con el objetivo de realizar una propuesta sobre un marco de estimacin de proyectos software para una organizacin, en este caso, para su aplicacin en CM nformtica y Comunicaciones de la Comunidad de Madrid, con el fin de su validacin, ajuste y mejora progresiva a travs de la recogida de datos iniciales y de cierre de los proyectos. Para ello, y partiendo de las conclusiones del trabajo, se ha diseado y desarrollado una herramienta de ayuda a la estimacin (Proyecto MDE) que permitir el almacenamiento de datos de proyectos en un repositorio, cuya explotacin permitir validar las estimaciones propuestas y el establecimiento de nuevos parmetros de estimacin. El objetivo aadido de esta propuesta es la difusin de las tcnicas de estimacin y planificacin de proyectos en la organizacin para una mejora en la calidad de los procesos internos de desarrollo de software, siendo sta un rea clave del proceso con claras deficiencias en CM, tras un proceso de evaluacin seguido segn el marco de referencia de CMM en su nivel 2, objetivo de la organizacin a futuro. El trabajo aade una nueva va de investigacin en cuanto a la bsqueda de mtodos de estimacin temprana de proyectos en base a la complejidad del modelo de bases de datos relacional que lo soporta, siendo ste un elemento analizado en las primeras fases del desarrollo y que, al menos en la Comunidad de Madrid, es un elemento fijo y disponible en herramientas homogneas de modelado de datos (ERwin) que permiten un anlisis de complejidad relacionado con los tiempos de desarrollo posteriores. El clculo de una tasa de complejidad del modelo de datos relacional en base a la recogida de determinadas mtricas relativas a las entidades y su complejidad, atributos y relaciones del modelo, permite hacer esta propuesta segn los datos de proyectos analizados. P$%ina 2 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software $. I#%ro&!''i(# La estimacin de proyectos de desarrollo de software es uno de los principales problemas con los que se enfrenta una organizacin cuya actividad se centra en la prestacin de servicios informticos. Habitualmente, el poco rigor en el proceso de dimensionamiento de los proyectos incide en una mala planificacin de recursos, en retrasos en las entregas o en cierres precipitados con un nivel de calidad y de pruebas insuficiente, que trae como consecuencia la implantacin de un mal producto y un alto grado de insatisfaccin por parte del cliente. Para una empresa que, normalmente, gestiona mltiples proyectos a la vez, los retrasos o desviaciones en un proyecto producen fuertes impactos de unos proyectos sobre otros, por lo que resulta vital para ella realizar estimaciones acertadas. Para muchas empresas, estas diferencias entre el esfuerzo presupuestado y el esfuerzo realizado, supone su progreso o su desaparicin. Normalmente hay dos fuerzas contrarias que inciden en las estimaciones de esfuerzo y coste de los proyectos. Por un lado, la adopcin de una actitud "prudente por parte de los responsables del desarrollo, que les lleva a aadir a las estimaciones ciertos mrgenes de holgura o colchn para absorber posibles desviaciones. Por otro lado, el ajuste a la baja producido por la necesidad de competir en un mercado abierto con mltiples ofertas. El presente trabajo se va a centrar en el anlisis de las tcnicas de estimacin de proyectos de desarrollo de software. Tras una visin de algunos mtodos utilizados en el mundo de las mtricas del software, el trabajo se va a desarrollar en las siguientes fases: Definicin del alcance de la investigacin. Anlisis de modelos de referencia internacionales. Recogida de datos para estimacin de proyectos en la organizacin de CM. Anlisis y propuestas. Anlisis de datos de esfuerzo y complejidad de modelos de datos en proyectos de la organizacin. Conclusiones y propuestas derivadas del anlisis. Desarrollo marco terico de estimacin para proyectos. Creacin de una herramienta destinada a contener un repositorio de datos de proyectos para facilitar su estimacin con capacidad de ajuste y mejora. Guas de aplicacin de las tcnicas propuestas. El mbito de aplicacin del trabajo va a ser el de CM nformtica y Comunicaciones de la Comunidad de Madrid, una organizacin orientada a la prestacin de servicios informticos y de comunicaciones a la administracin pblica de la Comunidad de Madrid. Entre esos servicios estn los de desarrollo de proyectos informticos dirigidos a las diferentes Consejeras de la Comunidad. P$%ina 3 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Una reciente evaluacin de la organizacin en relacin a fijar su nivel de madurez segn el modelo de referencia CMM 4*apa0ility Madurity Model5, ha puesto de manifiesto el posicionamiento en un nivel 1 de la organizacin, siendo uno de los puntos dbiles de la empresa el proceso de estimacin y planificacin de proyectos. Considerando el rea clave de proceso (KPA segn terminologa CMM) de la estimacin y planificacin de proyectos como un claro objeto de mejora en la organizacin, el presente trabajo se va a centrar en la recopilacin de datos sobre proyectos desarrollados en CM, tanto en esfuerzo como en tamao, como base para posteriores investigaciones. Adems, como otro material a incluir en el anlisis se incluirn datos acerca de la complejidad de los modelos de datos y de los procesos resultantes. Siendo stos un factor comn a todos los proyectos, se tratarn de buscar correlaciones entre la complejidad de los modelos de datos relacionales de las aplicaciones y el esfuerzo necesario para su desarrollo. Dado que en otros pases se han realizado mediciones de proyectos y se tienen datos por entornos tecnolgicos, se aadir esta informacin al estudio, tratando de detectar correlaciones entre estos datos y los obtenidos en CM. En cuanto a mediciones internacionales, destaca el repositorio de mediciones de proyectos del ISBSG, +nternational Software &enc'mar.in% Standards 6roup, organismo sin nimo de lucro que ha recopilado informacin de proyectos de mltiples pases. Se analizarn los datos del mismo, tratando de aplicarlos al entorno de CM. Como resultado del estudio y de sus conclusiones se definir la funcionalidad de una herramienta para la ayuda a la estimacin de proyectos (aplicacin MDE) que se utilizar para el almacenamiento de los datos de proyectos en el mbito de CM. El objetivo es que esta recopilacin de datos, el ajuste y mejora progresivos de los criterios de estimacin, constituyan un marco de referencia para los responsables de proyectos de desarrollo y contribuyan a la mejora en la planificacin y estimacin de proyectos. Los datos a recopilar son los de algunos de los proyectos desarrollados por CM en los aos 1998, 1999, 2000 y 2001. Para facilitar el anlisis, se seleccionarn proyectos de varios entornos de programacin, pero que sean nuevos proyectos y no versiones de otros anteriores, para simplificar el proceso de medicin. En CM se utilizan diferentes herramientas y lenguajes de desarrollo, pero se pueden considerar algunos entornos claramente predominantes, que sern la base del estudio: Forms 1."72.3 4/racle5 Es el entorno mayoritario de desarrollo desde 1990. Existen en la organizacin alrededor de 250 proyectos en produccin en este entorno. Desde 1999 se inici un proceso de migracin a la versin Forms 4.5 que acab a finales de 2001. Se utiliza en las aplicaciones de este entorno Pro*C para los programas de listados o procesos batch pesados de actualizacin. Delp'i 4&orland5 Es una herramienta de desarrollo orientada a objetos que se utiliza en la organizacin desde finales de 1995 para aplicaciones cliente/servidor en dos P$%ina 8 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software capas (BD/aplicacin) en entorno Windows. Las aplicaciones de este entorno se han orientado a proyectos de un nmero bajo-medio de usuarios (entre 5 y 20). Se han desarrollado proyectos en versiones 1.0, 3.0 y 5.0. Para los listados en este entorno se utiliza Quick Report, componentes incluidos en la herramienta. Las aplicaciones en este entorno trabajan contra una BD relacional: Paradox, nterBase u Oracle (el ms extendido con mucha diferencia sobre los otros dos). De)eloper7!""" 4/racle5 Nueva plataforma de desarrollo de Oracle que contiene tanto el mdulo Forms para el diseo de formularios, como el Reports para el desarrollo de listados y el Graphics para el diseo de grficos en la aplicacin. Entre las mltiples arquitecturas de implantacin de las aplicaciones en este entorno, en CM se est implementando en una arquitectura de 3 capas (BD, con Oracle sobre mquinas UNX, Aplicacin, sobre una granja de servidores Windows NT/2000, y Presentacin, en PC's con Windows 98/2000/XP desde un navegador estndar en una ntranet. 9a)a 49&uilder5 Entorno usado ms recientemente en la organizacin para aplicaciones en ntranet e nternet. Por ser ms novedoso, se ha excluido del estudio y mediciones ya que la organizacin est en la fase inicial de aprendizaje y estabilizacin por lo que las mtricas no son demasiado fiables. De cualquier forma, en el marco de estimacin propuesto ser otro de los entornos tecnolgicos de recogida de datos de proyectos. Para todos los entornos de desarrollo en CM, la base de datos utilizada de manera corporativa casi con generalidad es Oracle, siendo realizado el modelado de datos con la herramienta ERwin. P$%ina : Definicin y Propuesta de un Marco de Estimacin de Proyectos Software ). M*%ri'a bae !%ili+a&a e# el e%!&io De las diferentes orientaciones de las mtricas del software, para el presente trabajo se va a tomar como referencia las mtricas orientadas a la funcin. Son medidas indirectas del software y del proceso por el que se desarrolla. En lugar de calcular las LDC (lneas de cdigo), como otros sistemas de estimacin, se centran en la funcionalidad del producto. Fueron en principio propuestas por Albrecht en 1979 quien propuso un mecanismo de acercamiento a la medida de la productividad llamado mtodo de los puntos de funcin, sto es, una cuantificacin de la complejidad del software en relacin a la funcionalidad aportada al usuario. Dentro de los mtodos para la medida de puntos funcin, destacan las dos inciativas que se van a analizar, la proveniente del FPUG y la de COSMC-FFP que se describen ms adelante. Anlisis de repositorios internacionales demuestran que son los ms extendidos en este tipo de mediciones. ).1. M*%o&o &e P!#%o F!#'i(# &el IFPU, - ..1 El FPUG, +nternational Function Point User 6roup, ha difundido un Manual de Medicin de Puntos Funcin, que actualmente est en su versin 4.1, para establecer el mtodo de medicin propuesto por Albrecht y potenciar su uso. El esquema general para la medicin de puntos de funcin es el siguiente. La medida de puntos funcin no ajustados (UFPC) refleja la funcionalidad especfica medible proporcionada al usuario por el proyecto o aplicacin. P$%ina ; Determinacin del tipo de Medicin Medicin de las Funciones de Datos Medicin de las Funciones Transaccionales Determinacin de los Puntos Funcin Ajustados dentificacin del Alcance de la Medicin y los Lmites de la Aplicacin Determinacin de los Puntos Funcin No Ajustados Determinacin del Valor del Factor de Ajuste Definicin y Propuesta de un Marco de Estimacin de Proyectos Software La funcionalidad especfica de usuario de la aplicacin es evaluada en trminos de <u, es lo <ue se entrega con la aplicacin, no de cmo se entrega. Se cuentan solamente los componentes solicitados y definidos por el usuario. La medida de puntos funcin no ajustados tiene dos tipos de funcin: de datos y transaccional. Estos tipos de funcin son definidos ms adelante, como muestra el siguiente diagrama. Para el clculo de los puntos funcin se tienen en cuenta: Nmero de entradas de usuario (EI), que proporcionan a la aplicacin datos aportados por el usuario. Nmero de salidas del usuario (EO), es decir, pantallas, listados, mensajes de error, etc. Nmero de peticiones de usuario (EQ), entendiendo por stas a las entradas interactivas que requiere algn tipo de respuesta por parte del usuario. Nmero de archivos, o sea, nmero de agrupaciones lgicas de datos de la aplicacin (ILF). Nmero de interfaces externas, o archivos que sirven para la transmisin de datos a otros sistemas (EIF).. Para cada uno de estos elementos, se le asigna un nivel de complejidad (simple, medio o complejo) que segn la tabla siguiente tiene asociado un coeficiente multiplicador: Par/"e%ro &e "e&i&a N0" Si"1le Me&io Co"1le2o P!#%o Entradas de usuario x 3 x 4 x 6 Salidas de usuario x 4 x 5 x 7 Peticiones de usuario x 4 x 5 x 7 Archivos x 7 x 10 x 15 nterfaces externas x 5 x 7 x 10 To%al A esta suma total se le llama "puntos de funcin no ajustados. En cada organizacin esta suma total se ve ajustada por la respuesta a una serie de cuestiones (14) que caracterizan a la aplicacin que se est midiendo. Cada una de las 14 preguntas se valoran de 0 a 5 segn P$%ina = Funciones de Datos Funciones Transaccionales Ficheros Lgicos nternos Ficheros de nterfaz Externos Entradas Externas Salidas Externas Consultas Externas Medida de Puntos Funcin No Ajustados Definicin y Propuesta de un Marco de Estimacin de Proyectos Software los siguientes criterios: - 0 Sin influencia - 1 ncidental - 2 Moderado - 3 Medio - 4 Significativo - 5 Esencial Las 14 preguntas de ajuste que constituyen los factores de complejidad son las siguientes: 1. Requiere el sistema copias de seguridad y de recuperacin fiables? 2. Se requieren comunicaciones de datos? 3. Existen funciones de procesamiento distribuido? 4. Es crtico el rendimiento? 5. Ser ejecutado el sistema en un entorno 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 mltiples pantallas o variadas operaciones? 8. Se actualizan los archivos maestros de manera interactiva? 9. Son complejas las entradas, las salidas, los archivos o las peticiones? 10. Es complejo el procesamiento interno? 11. Se ha diseado el cdigo para ser reutilizable? 12. Estn incluidas en el diseo la conversin y la instalacin? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14. Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario? En funcin de los pesos de estos 14 factores, el coeficiente corrector a aplicar al nmero de puntos de funcin no ajustados vara entre 0,65 y 1,35. Teniendo mediciones en una organizacin del esfuerzo para el desarrollo por punto de funcin, podemos trasladar las estimaciones en puntos de funcin a horas/hombre y, por tanto, a plazos y costes de realizacin. ).$. Tabla re!"e# &el "*%o&o &e Albre'3% &e P!#%o F!#'i(# Las tablas siguientes resumen el clculo de los puntos de funcin no ajustados, segn Albrecht, para un proyecto de software. Recordemos los significados de las siglas empleadas: ILF Fic'eros L%icos +nternos ILF Fic'eros de +nterfaz E>terna DET Dato Elemental RET 6rupo de Datos ?elacionados EI Entradas EO Salidas EQ *onsultas Las tablas sirven para la evaluacin de la complejidad y de la contribucin de las funciones P$%ina #" Definicin y Propuesta de un Marco de Estimacin de Proyectos Software de datos y transaccionales al clculo de puntos funcin: I4F Cople!i"a" DETs PF # DETs RETs # a #= !" a 3" 3# m$s # a #= !" a 3" 3# m$s # Baja Baja Media 7 7 10 ! a 3 Baja Media Alta 7 10 15 8 m$s Media Alta Alta 10 15 15 EIF Cople!i"a" DETs PF # DETs RETs # a #= !" a 3" 3# m$s # a #= !" a 3" 3# m$s # Baja Baja Media 5 5 7 ! a 3 Baja Media Alta 5 7 10 8 m$s Media Alta Alta 7 10 10 EI Cople!i"a" DETs PF # DETs FRTs # a #2 3 a #3 #8 o m$s # a #2 3 a #3 #8 o m$s " o # Baja Baja Media 3 3 4 ! Baja Media Alta 3 4 6 1 m$s Media Alta Alta 4 6 6 EO 5 E6 Cople!i"a" DETs PF # DETs FRTs # a #2 3 a #3 #8 o m$s # a #2 3 a #3 #8 o m$s " o # Baja Baja Media 4 4 5 ! Baja Media Alta 4 5 7 1 m$s Media Alta Alta 5 7 7 Para la determinacin de los puntos de funcin no ajustados contabilizaremos: Si"1le Me&io Co"1le2o PF EI Entradas de Usuario x 3 x 4 x 6 EO Salidas de Usuario x 4 x 5 x 7 E6 Consultas x 4 x 5 x 7 I4F Archivos Lgicos x 7 x10 x15 IEF nterfaces Externas x 5 x 7 x10 PFNA 77 P$%ina ## Definicin y Propuesta de un Marco de Estimacin de Proyectos Software .. E%!&io &e la i%!a'i(# a'%!al De las diferentes iniciativas a nivel mundial en el estudio de las mtricas del software, se van a analizar para este trabajo las siguientes fuentes: Repositorio del SBSG V 6.0. Trabajos presentados en diferentes Congresos, Conferencias y publicaciones sobre mtricas del software por diferentes autores, Universidades y asociaciones Nacionales de Mtricas. ..1. Re1oi%orio &el ISBS, - 8.9 SBSG, +nternational Software &enc'mar.in% Standards 6roup, es una asociacin sin nimo de lucro que recopila mediciones de datos sobre proyectos de software en todo el mundo. Forman parte de SBSG las siguientes asociaciones de mtricas: Ao'. Pa E#%i&a& Web Si%e : e"ail ASMA Australia Asociacin Australiana de Mtricas del Software www.asma.org.au DASMA Alemania Asociacin Alemana de Mtricas del Software www.dasma.de NASSCOM ndia Asociacin Nacional de Software y Servicios gasha@in.ibm.com GUFP talia Grupo de Usuarios taliano de Puntos Funcin www.gufpi.com JFPUG Japn Grupo de Usuarios Japons de Puntos Funcin nishiyama@s@rdc.east.nft.co.jp NESMA Holanda Asociacin Holandesa de Mtricas del Software www.nesma.nl AEMES Espaa Asociacin Espaola de Mtricas del Software www.aemes.es UKSMA Reino Unido Asociacin nglesa de Mtricas del Software www.uksma.co.uk FPUG EEUU Grupo nternacional de Usuarios de Puntos Funcin www.ifpug.org ..1.1. Da%o De"ogr/fi'o &el Re1oi%orio &e ISBS, - 8.9 En su versin 6, la distribucin de proyectos analizados por pases es la siguiente: Pro5e'%o 1or 1ae Pa Pro5e'%o Por'e#%a2e Australia 219 30.6 Austria 1 0.1 Brasil 2 0.3 Canad 88 12.3 Dinamarca 1 0.1 Francia 61 8.5 Alemania 4 0.6 Hong Kong 3 0.4 ndia 7 1.0 P$%ina #! Definicin y Propuesta de un Marco de Estimacin de Proyectos Software talia 1 0.1 Japn 19 2.7 Holanda 47 6.6 Nueva Zelanda 2 0.3 Noruega 4 0.6 Portugal 2 0.3 Suecia 1 0.1 Suiza 1 0.1 Reino Unido 87 12.2 EEUU 158 22.1 Uruguay 1 0.1 Otros 7 1.0 To%al ;18 100.0 Las siguientes tablas recogen la distribucin de proyectos por diferentes conceptos. Las diferencias en los totales son consecuencia de que no todos los proyectos incluidos en el inventario estn completamente clasificados bajo todos los criterios. Ti1o &e Orga#i+a'i(# Ti1o &e orga#i+a'i(# Pro5e'%o Por'e#%a2e Automocin 10 1.6 Agricultura y Pesca 6 0.9 Banca 94 14.8 ndustria Qumica 5 0.8 Comunicaciones 45 7.1 Servicios 10 1.6 Ordenadores 8 1.3 Construccin 1 0.2 Consumo 1 0.2 Defensa 6 0.9 Electricidad, Gas, Agua 47 7.4 Electrnica 5 0.8 Energa 4 0.6 Servicios Financieros 79 12.4 Seguros 83 13.1 Fabricacin 55 8.6 Salud 5 0.8 Minera 6 0.9 Servicios Profesionales 5 0.8 Administracin Pblica 85 13.4 Servicios Ocio 2 0.3 Transporte y Almacenamiento 8 1.3 Wholesale & Retail Trade; 9 1.4 Otros 57 9.0 To%al 8)8 100.0 Ti1o &e Dearrollo Ti1o &e &earrollo Pro5e'%o Por'e#%a2e Mantenimiento 322 40.7 Nuevo Desarrollo 422 53.4 Redesarrollo 45 5.7 Otros 2 0.3 To%al ;<1 100.0 P$%ina #1 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software U!ario 'o#'!rre#%e U!ario 'o#'!rre#%e Pro5e'%o Por'e#%a2e < 2 25 9.7 2 5 66 25.6 > 5 167 64.7 To%al $=> 100.0 Ti1o &e le#g!a2e Ti1o 4e#g!a2e Pro5e'%o Por'e#%a2e 2GL 4 0.6 3GL 306 45.1 4GL 309 45.5 ApG 60 8.8 To%al 8;< 100.0 4e#g!a2e Pri"ario &e Progra"a'i(# 4e#g!a2e &e Progra"a'i(# Pro5e'%o Por'e#%a2e Assembler / 2GL 4 0.6 Access 30 4.4 C 25 3.7 C++ 24 3.6 Clipper 9 1.3 COBOL 171 25.3 COBOL 36 5.3 CSP 7 1.0 EASYTREVE 9 1.3 HPS 10 1.5 DEAL 6 0.9 Java 4 0.6 NATURAL 63 9.3 ORACLE, ORACLE Forms 31 4.6 Other 3GL 9 1.3 Other 4GL 47 7.0 Other ApG 19 2.8 PL/ 40 5.9 POWERBULDER 19 2.8 RALLY 6 0.9 SQL, SQL Forms, SQL Windows 37 5.5 TELON 31 4.6 Visual Basic 37 5.5 Otros 2 0.3 To%al 8;= 100.0 Pla%afor"a &e Dearrollo Pla%afor"a &e Dearrollo Pro5e'%o Por'e#%a2e Mainframe 418 61.7 Midrange 149 22.0 PC 111 16.4 To%al 8;> 100.0 P$%ina #2 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software T*'#i'a !a&a e# el &earrollo T*'#i'a !a&a e# el &earrollo Pro5e'%o Por'e#%a2e Modelado de reas de Negocio 73 16.2 Modelado de Datos 286 63.6 Modelado de Eventos 50 11.1 JAD (Joint Application Development) 88 19.6 Equipos Multifuncionales 104 23.1 Anlisis Orientado a Objetos 39 8.7 Diseo Orientado a Objetos 49 10.9 Modelado de Procesos 182 40.4 Prototipado 135 30.0 RAD (Rapid Application Development) 48 10.7 Pruebas de Regresin 91 20.2 Time boxing 23 5.1 Otros 54 12.0 To%al .=9 100.0 M*%o&o &e P!#%o F!#'i(# U%ili+a&o M*%o&o P!#%o F!#'i(# Pro5e'%o Por'e#%a2e Albrecht 2 0.3 Automated 6 0.8 Backfired 1 0.1 Dreger 10 1.3 Feature Points 2 0.3 FFP 1.0 3 0.4 FPUG addendum to existing standards 85 10.7 FPUG 2 14 1.8 FPUG 3 90 11.4 FPUG 4 432 54.6 FPUG n-house 28 3.5 FPUG unspecified 75 9.5 Mark 35 4.4 Retrofitted 3 0.4 Otros 7 0.9 To%al ;<1 100.0 ..1.$. A#/lii &e Da%o De"ogr/fi'o &el Re1oi%orio &e ISBS, - 8.9 De las tablas anteriores se deducen algunos datos significativos respecto a los indicadores de los 716 proyectos del Repositorio Los pases que ms proyectos han aportado al repositorio son Australia (30,6%), EEUU (22,1%), Canad (12,3%) y Reino Unido (12,2%). Una gran mayora de los proyectos se incorporan al Repositorio entre los aos 1994 y 1998. Los sectores ms representados son Banca (14,8%), Administracin Pblica (13,4%), Seguros (13,1%) y sistemas financieros (12,4%). Los tipos de lenguaje ms utilizados son 3GL (45,1%) y 4GL (45,5%). Destacan los lenguajes de desarrollo COBOL (25,3%), Natural (9,3%), PL/1 (5,9%), Visual Basic (5,5%) y Oracle Forms (4,6%). La plataforma mayoritaria de desarrollo de los proyectos es mainframe (61,7%), equipos medios (22%) y PC (16,4%). P$%ina #3 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Las tcnicas de desarrollo ms utilizadas son el modelado de datos (63,6%), modelado de procesos (40,4%) y prototipado (30%). El mtodo de medicin de puntos funcin mayoritario es FPUG, en sus diferentes versiones (91,5%). Hay algunos otros medidos con Mark (4,4%), Dreger (1,3%) o FFP 1.0 (0,4%). ..1.). Tabla re!l%a&o &el Re1oi%orio ISBS, R 8.9 De los proyectos analizados e incluidos en el Repositorio, podemos extraer determinadas mtricas aplicables. El SBSG analiza las siguientes: PDR (Project Delivery Rate) (horas/persona por punto funcin). Esfuerzo (en horas/persona). Duracin (horas/das/meses). Velocidad de desarrollo (puntos funcin desarrollado por unidad de duracin del proyecto). Las mtricas, como se ha indicado anteriormente al ver los atributos de los proyectos medidos, se analizan por tipo de organizacin, lenguaje usado, plataforma, etc. En las tablas que veremos a continuacin, se analiza el PDR (horas por PF), por diversos criterios y analizando el total de proyectos (N), los valores Mnimo, Medio y Mximo, y algunos percentiles (P10, P25, P75 y P90). Veamos algunas de las ms significativas o aplicables al objeto del trabajo. PDR 1or Ti1o &e Orga#i+a'i(# Ti1o N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ Banca 52 4.6 6.2 7.5 13.2 18.3 21.6 28.2 13.4 6.2 Energa 36 0.9 2.7 3.3 6.4 13.6 19.7 35.9 9.6 8.0 Finanzas 53 0.5 3.3 5.8 8.0 13.2 17.6 30.4 9.4 5.8 Adm. Pblica 49 0.4 1.4 2.6 6.5 15.6 27.7 68.9 12.2 15.3 -/-AL 1!8 ".! !." 2.# :.1 #1.1 #=.1 8;.= =.: ;.; PDR 1or Ti1o &e Pla%afor"a &e &earrollo Ti1o N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ Mainframe 226 0.9 3.1 4.9 9.0 15.5 20.0 68.9 11.2 8.9 Eq. Medios 51 0.7 2.0 4.3 6.1 9.1 14.9 41.5 7.9 7.0 PC 51 0.2 0.9 1.8 3.5 6.1 8.2 59.4 5.6 8.9 -/-AL 1!; ".! !." 2.# :.1 #1.! #=.! 8;.= =.; ;.= PDR 1or 4e#g!a2e ADearrollo e# Mai#fra"eB 4e#g!a2e N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ COBOL 70 0.9 3.0 5.9 11.8 18.0 21.6 48.1 13.3 9.9 NATURAL 41 0.9 1.9 3.2 6.6 9.8 13.6 23.2 7.3 4.9 PL/1 22 2.9 3.5 4.4 5.5 11.1 12.2 14.2 7.1 3.6 -/-AL 1!; ".! !." 2.# :.1 #1.! #=.! 8;.= =.; ;.= P$%ina #8 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software PDR 1or 4e#g!a2e ADearrollo e# EC!i1o Me&ioB 4e#g!a2e N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ C 6 5.5 - 6.3 7.1 13.3 - 21.9 10.5 6.6 COBOL 8 4.3 - 6.1 7.3 9.0 - 10.3 7.4 2.0 ORACLE 8 1.7 - 1.9 2.6 4.2 - 14.9 4.3 4.4 SQL 10 0.7 1.5 3.6 7.1 10.7 12.8 12.9 7.0 4.5 PDR 1or 4e#g!a2e ADearrollo e# PCB 4e#g!a2e N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ Access 21 0.2 0.4 1.2 1.8 2.2 2.9 3.8 1.7 1.0 C 6 0.9 - 7.2 13.4 21.6 - 59.4 19.4 21.2 ORACLE 3 3.5 - - 3.9 - - 5.0 4.1 0.8 Visual Basic 3 2.6 - - 6.3 - - 7.1 5.3 2.4 I"1a'%o obre el PDR &el "/?i"o eC!i1o &e %raba2o e# 1ero#a Pero#a N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ 1 a 4 96 -18.5 -7.9 -4.9 -2.0 0.3 2.6 40.0 -1.9 6.6 5 a 8 62 -11.2 -8.1 -3.5 -0.2 4.0 7.9 27.2 0.5 6.7 9 o ms 37 -8.8 -5.3 -2.2 1.5 6.7 12.0 55.3 4.6 12.3 Ratio de Desarrollo de Proyecto (horas por PF) dado el tamao del proyecto en Puntos Funcin y el mximo de personas del equipo de desarrollo (Pro@ect Deli)ery ?ate) PDR D C ? Si+e E1 ? M?Tea" E$ Clae C E1 E$ N R$AA2B MF 12.62 -0.195 0.448 180 0.155 MR 9.441 -0.274 0.829 48 0.384 PC 7.674 -0.386 1.203 69 0.319 3GL 8.453 -0.089 0.383 109 0.096 4GL 17.70 -0.461 1.009 138 0.406 ApG 20.75 -0.385 0.716 34 0.538 MF & 3GL 6.412 -0.010 0.217 81 0.039 MF & 4GL 20.75 -0.378 0.711 63 0.287 MF & ApG 26.55 -0.329 0.379 27 0.419 MR & 3GL 8.892 -0.122 0.556 15 0.258 MR & 4GL 31.41 -0.529 1.073 26 0.505 PC & 3GL 209.9 -0.845 1.398 10 0.667 PC & 4GL 9.484 -0.415 1.038 47 0.342 P$%ina #: Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Esfuerzo en horas dado el tamao del proyecto y el mximo de personas del equipo de desarrollo (Pro@ect Aor. Effort) PWE D C ? Si+e E1 ? M?Tea" E$ Clae C E1 E$ N R$AA2B MF 12.62 0.805 0.448 180 0.724 MR 9.441 0.726 0.829 48 0.734 PC 7.674 0.614 1.203 69 0.666 3GL 8.453 0.911 0.383 109 0.723 4GL 17.70 0.539 1.009 138 0.739 ApG 20.75 0.615 0.716 34 0.797 MF & 3GL 6.412 1.010 0.217 81 0.744 MF & 4GL 20.75 0.622 0.711 63 0.749 MF & ApG 26.55 0.671 0.379 27 0.761 MR & 3GL 8.892 0.878 0.556 15 0.743 MR & 4GL 31.41 0.471 1.073 26 0.770 PC & 3GL 209.9 0.155 1.398 10 0.731 PC & 4GL 9.484 0.585 1.038 47 0.749 Duracin en meses segn el tamao del proyecto y el mximo de personas del equipo de desarrollo. Mee D C ? Si+e E1 ? M?Tea" E$ Clae C E1 E$ N R$AA2B MF 0.655 0.453 -0.042 164 0.442 MR 0.417 0.484 0.023 46 0.449 PC 0.518 0.421 0.005 57 0.290 3GL 0.412 0.524 0.002 94 0.538 4GL 0.774 0.355 0.090 132 0.333 ApG 1.396 0.258 0.223 33 0.486 MF & 3GL 0.390 0.527 0.032 70 0.548 MF & 4GL 0.933 0.373 -0.027 60 0.333 MF & ApG 1.161 0.344 0.140 26 0.633 MR & 3GL 0.137 0.757 -0.170 14 0.606 MR & 4GL 0.288 0.543 -0.003 26 0.372 PC & 3GL 3.899 0.207 -0.237 8 0.105 PC & 4GL 0.649 0.357 0.092 45 0.292 Ratio de Desarrollo de Proyecto (horas por PF) dado el tamao del proyecto nicamente: PDR D C ? Si+e E
Clae C E N R$AA2B MF 14.35 -0.072 384 0.008 MR 14.89 -0.100 108 0.005 PC 3.78 0.016 116 0.000 3GL 13.34 -0.027 285 0.000 4GL 10.07 -0.101 290 0.009 ApG 39.54 -0.284 46 0.234 MF & 3GL 15.10 -0.050 193 0.000 MF & 4GL 12.47 -0.050 112 0.000 P$%ina #; Definicin y Propuesta de un Marco de Estimacin de Proyectos Software MF & ApG 33.81 -0.247 42 0.197 MR & 3GL 7.24 0.068 40 0.000 MR & 4GL 18.07 -0.149 58 0.012 PC & 3GL 0.587 0.390 10 0.610 PC & 4GL 3.38 -0.026 81 0.000 Esfuerzo en horas dado el tamao del proyecto nicamente PWE D C ? Si+e E
Clae C E N R$AA2B MF 14.35 0.928 384 0.631 MR 14.89 0.900 108 0.540 PC 3.78 1.016 116 0.473 3GL 13.34 0.973 285 0.492 4GL 10.07 0.899 290 0.492 ApG 39.54 0.716 46 0.672 MF & 3GL 15.10 0.950 193 0.650 MF & 4GL 12.47 0.896 112 0.618 MF & ApG 33.81 0.753 42 0.714 MR & 3GL 7.24 1.068 40 0.727 MR & 4GL 18.07 0.851 58 0.483 PC & 3GL 0.587 1.390 10 0.955 PC & 4GL 3.38 0.974 81 0.519 Duracin en meses segn el tamao del proyecto nicamente Mee D C ? Si+e E
Clae C E N R$AA2B MF 1.081 0.344 315 0.229 MR 0.522 0.458 94 0.455 PC 0.502 0.423 93 0.255 3GL 0.971 0.351 213 0.189 4GL 0.622 0.405 264 0.340 ApG 1.472 0.280 46 0.263 MF & 3GL 0.769 0.415 138 0.241 MF & 4GL 0.807 0.381 102 0.380 MF & ApG 1.014 0.357 43 0.310 MR & 3GL 0.170 0.676 34 0.660 MR & 4GL 0.515 0.455 53 0.401 PC & 3GL 0.331 0.459 12 0.120 PC & 4GL 0.526 0.408 73 0.276 Velocidad de desarrollo segn el tamao del proyecto nicamente PFEMe D C ? Si+e E
Clae C E N R$AA2B MF 0.925 0.656 315 0.521 MR 1.914 0.542 94 0.540 PC 1.991 0.577 93 0.392 3GL 1.030 0.649 213 0.449 4GL 1.607 0.595 264 0.526 ApG 0.679 0.720 46 0.713 P$%ina #= Definicin y Propuesta de un Marco de Estimacin de Proyectos Software MF & 3GL 1.300 0.585 138 0.390 MF & 4GL 1.239 0.619 102 0.620 MF & ApG 0.986 0.642 43 0.602 MR & 3GL 5.875 0.324 34 0.296 MR & 4GL 1.941 0.545 53 0.491 PC & 3GL 3.020 0.541 12 0.183 PC & 4GL 1.901 0.592 73 0.450 PDR segn el tamao mximo del equipo de desarrollo PDR D C ? Ma?Tea" E
Clae C E N R$AA2B MF 5.225 0.308 180 0.091 MR 2.153 0.664 48 0.326 PC 1.242 0.836 69 0.243 3GL 6.039 0.269 110 0.065 4GL 1.936 0.621 139 0.233 ApG 1.824 0.795 32 0.221 MF & 3GL 6.730 0.222 81 0.051 MF & 4GL 4.083 0.354 63 0.108 MF & ApG 2.673 0.646 28 0.134 MR & 3GL 4.592 0.502 15 0.293 MR & 4GL 1.706 0.726 24 0.571 PC & 3GL 12* PC & 4GL 1.202 0.630 49 0.158 (*) La regresin para PC & 3GL no daba buenos resultados por el pequeo nmero de proyectos.
..1... A#/lii &e a1li'a'i(# a ICM &e la Tabla &el Re1oi%orio &el ISBS, Del Repositorio del SBSG, y para los entornos analizados en CM, podra ser de aplicacin: PDR 1or Ti1o &e Orga#i+a'i(# Ti1o N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ Adm. Pblica 49 0.4 1.4 2.6 6.5 15.6 27.7 68.9 12.2 15.3 Coentario$ De la comparativa por tipo de organizacin, lo nico que se puede analizar es que para Administracin Pblica los ratios de PDR (horas por PF) son algo ms altos que para otras organizaciones considerndose este tipo de organizacin por tanto menos productiva. PDR 1or Ti1o &e Pla%afor"a &e &earrollo Ti1o N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ PC 51 0.2 0.9 1.8 3.5 6.1 8.2 59.4 5.6 8.9 Coentario$ El hecho de que se desarrolle sobre PC significa una productividad ms alta, justificada por las mayores facilidades del entorno visual de programacin para la edicin, codificacin y puesta a punto de programas. PDR 1or 4e#g!a2e ADearrollo e# EC!i1o Me&ioB 4e#g!a2e N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ ORACLE 8 1.7 - 1.9 2.6 4.2 - 14.9 4.3 4.4 P$%ina !" Definicin y Propuesta de un Marco de Estimacin de Proyectos Software PDR 1or 4e#g!a2e ADearrollo e# PCB 4e#g!a2e N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ ORACLE 3 3.5 - - 3.9 - - 5.0 4.1 0.8 VB - Delphi 3 2.6 - - 6.3 - - 7.1 5.3 2.4 Coentario$ De los dos cuadros anteriores se deduce que hay pocos proyectos en el Repositorio de los entornos analizados (total 14), tanto en el caso de ORACLE en equipos medios como en PC, pero ah estn los ratios como punto de referencia para compararlos con los obtenidos en CM. I"1a'%o obre el PDR &el "/?i"o eC!i1o &e %raba2o e# 1ero#a Pero#a N Mi# P19 P$= Me& P;= P<9 Ma? Me&ia S%&De@ 1 a 4 96 -18.5 -7.9 -4.9 :$.9 0.3 2.6 40.0 -1.9 6.6 5 a 8 62 -11.2 -8.1 -3.5 :9.$ 4.0 7.9 27.2 0.5 6.7 9 o ms 37 -8.8 -5.3 -2.2 1.= 6.7 12.0 55.3 4.6 12.3 Coentario$ Est clara la influencia del tamao del equipo de trabajo sobre el PDR. Por ello, vamos a usar este parmetro en la propuesta de estimacin como factor de ajuste. Usaremos, por tanto, los factores de ajuste siguientes relativos al tamao del equipo de trabajo: Ratio de Desarrollo de Proyecto (horas por PF) dado el tamao del proyecto en Puntos Funcin y el mximo de personas del equipo de desarrollo (Pro@ect Deli)ery ?ate) PDR D C ? Si+e E1 ? M?Tea" E$ Clae C E1 E$ N R$AA2B PC & 4GL 9.484 -0.415 1.038 47 0.342 Esfuerzo en horas dado el tamao del proyecto y el mximo de personas del equipo de desarrollo (Pro@ect Aor. Effort) PWE D C ? Si+e E1 ? M?Tea" E$ Clae C E1 E$ N R$AA2B PC & 4GL 9.484 0.585 1.038 47 0.749 Duracin en meses segn el tamao del proyecto y el mximo de personas del equipo de desarrollo. Mee D C ? Si+e E1 ? M?Tea" E$ Clae C E1 E$ N R$AA2B PC & 4GL 0.649 0.357 0.092 45 0.292 Ratio de Desarrollo de Proyecto (horas por PF) dado el tamao del proyecto nicamente: PDR D C ? Si+e E
Clae C E N R$AA2B PC & 4GL 3.38 -0.026 81 0.000 Esfuerzo en horas dado el tamao del proyecto nicamente PWE D C ? Si+e E
P$%ina !# Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Clae C E N R$AA2B PC & 4GL 3.38 0.974 81 0.519 Duracin en meses segn el tamao del proyecto nicamente Mee D C ? Si+e E
Clae C E N R$AA2B PC & 4GL 0.526 0.408 73 0.276 Velocidad de desarrollo segn el tamao del proyecto nicamente PFEMe D C ? Si+e E
Clae C E N R$AA2B PC & 4GL 1.901 0.592 73 0.450 PDR segn el tamao mximo del equipo de desarrollo PDR D C ? Ma?Tea" E
Clae C E N R$AA2B PC & 4GL 1.202 0.630 49 0.158 P$%ina !! Definicin y Propuesta de un Marco de Estimacin de Proyectos Software ..$. O%ra refere#'ia Algunos autores, asociaciones y Universidades han presentado en Congresos de los ltimos aos trabajos interesantes y de aplicacin al mbito del trabajo. Las Conferencias anuales de Asociaciones de Mtricas son un buen foro para ello. La Conferencia Europea de FESMA del ao 2000 fue organizada por AEMES, la Asociacin Espaola de Mtricas del Software, en Octubre del ao 2000. De los muchos trabajos presentados, el de la Asociacin Alemana de Mtricas es el que se analiza a continuacin: ..$.1. DASMA F A1ro?i"a'i(# a lo P!#%o F!#'i(# a %ra@* &e 'i#'o 'o"1o#e#%e Veamos algunos resultados de investigaciones realizadas en Alemania entre los aos 1996 y 1998 en una compaa de Seguros, CNV AG, acerca de la proporcionalidad entre la distribucin de los puntos funcin de un proyecto entre sus cinco componentes (E, EO, EQ, LF y EF). La investigacin fue presentada en la Conferencia FESMA 2000 en Madrid por Manfred Bundschuh, Presidente de DASMA. Las mediciones se realizan en un entorno de desarrollo mayoritariamente en COBOL con un generador de cdigo, y bases de datos en MS y DB2. Los proyectos analizados son 39. El mtodo usado es el definido por FPUG 4.0 en cuando a Puntos Funcin no Ajustados. Calcularon el porcentaje de los cinco componentes. Algunos valores en otras publicaciones resultan consistentes con estos valores. Es interesante el anlisis comparativo con otras referencias a nivel mundial en cuanto a la distribucin porcentual del peso de los cinco componentes:
Ti1o &e F!#'io#e AGB N0"ero &e Pro5e'%o EI EO E6 I4F EIF CNV 1996 8 34 35 11 18 2 CNV 1997 12 18 43 12 18 9 CN- 1<<8E<; D FESMA 1<<> $9 $; )< 11 1> = CNV 1998 19 21 41 13 15 9 CN- A1<<8:1<<>B )< $= )< 1. 1; 8 SBSG Rel. 5 451 37,2 23,5 13,2 22,3 3,8 Metricviews 26-39 22-24 12-14 24 4-12 Checkpoint 20 24 10 43 3 Nigel Scrivens (HB 33 21 19 23 4 SBSG Rel. 5 Enhancement Projects 119 36 32 12 15 5 Me&ia &e @aloreI $>J8 $8 1)J> $9J1 =J> AHB Nigel Scrivens from shl.com via nternet reported industry averages Tambin se analiza en el trabajo la complejidad en Puntos Funcin de los diferentes tipos de funcin. Como se puede ver, hay pesos ms o menos homogneos que pueden servir como referencia a procesos de estimacin temprana de proyectos. Los datos de la versin 5.0 del SBSG se analizan por zonas geogrficas (continentes). P$%ina !1 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software
Co"1le2i&a& Me&ia 1or F!#'i(# EI EO E6 I4F EIF IFPU, . = . 19 ; ISBS, Rel. = To%al .J) =J. )J> ;J. =J= Aia Pa'ifi' 4,0 5,6 3,9 7,4 5,6 E!ro1a 4,2 4,9 3,8 7,2 5,3 A"*ri'a &el Nor%e 4,9 5,2 3,8 7,6 5,5 CN- 1<<> To%al .J8 =J= .J) >J9 =J< PC 4,1 5,7 3,9 7,1 5,3 Ko% 4,9 5,5 4,6 8,5 6,1 CN- 1<<< To%al .J8 =J; .J) >J$ 8J1 PC 4,0 5,7 3,9 7,3 5,4 Ko% 4,8 5,7 4,5 8,5 6,2 La propuesta de este trabajo es la posible aplicacin a estimaciones tempranas de proyectos del peso porcentual de estos cinco factores en el tamao de un proyecto, lo cual indica que, conociendo la medicin de uno de ellos, podemos extrapolar el tamao total del proyecto. En esta lnea de anlisis se va a basar la propuesta de este trabajo de realizar un anlisis inicial de la complejidad del modelo de datos para una extrapolacin a la estimacin de la totalidad del tamao del proyecto. Adems, se buscar correlaciones entre las mtricas del modelo y el tamao final del proyecto. P$%ina !2 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software ..).1. I#i'ia%i@a COSMIC:FFP El *ommon Software Metrics +nternational *onsortium, COSMC, es un grupo de expertos internacionales que han tratado de recoger las mejores prcticas de estimacin de proyectos con el objetivo de la elaboracin de una mtrica de tamao funcional del software. Sus principales impulsores son Cahrles Symons y Alain Abran, conocidos por su participacin en el desarrollo de los mtodos M.++ Function Points y Full Function Points ?elease +, respectivamente. Parten de otros mtodos y tcnicas (FPUG 4.1, NESMA, Mk 1.3.1. y FFP) as como de los conceptos de la norma SO 14143. En Mayo de 2001 han liberado la Versin 2.1 del Manual de Medicin */SM+* FFP, como mtodo de recuento de puntos funcin. Este Manual est disponible en versiones en ingls, francs y espaol en el WEB de COSMC (http://www.cosmicon.com) o en la pgina del laboratorio de nvestigacin del Software de la Universidad de Quebec, en Canad, institucin que ha participado muy directamente en el proyecto. (http://www.lrgl.uqam.ca/ffp.html). Hay que sealar que en el Manual de Medicin V 2.1 aparecido en Mayo de 2001, faltan por completar algunos captulos de gran inters en relacin a comparativas entre el mtodo COSMC-FFP y los mtodos FPUG 4.1 y Mark 3.1.1. En el Manual de COSMC-FFP indica su aplicacin a todos los sistemas de software, incluidos los de tiempo real, basndose en algunas crticas al mtodo del FPUG por su no aplicabilidad a todos los tipos de software (nce, 1991).. ..).1.1. Pri#'i1io &e i&e#%ifi'a'i(# COSMIC:FFP Bsicamente, el mtodo COSMC-FFP parte de la posible descomposicin del software en una o varias capas segn diferentes niveles de abstraccin. Define fronteras entre las capas y diferentes tipos de subprocesos de manejo de datos (entradas, salidas, lecturas o escrituras). Cada proceso funcional consta de una serie de sub-procesos de manejo de datos de esos tipos. Por cada sub-proceso le asigna una unidad de medida C%s& 4*/SM+* Functional Size Unit5 por cada sub-proceso identificado. El Manual de Medicin aporta reglas para la identificacin de las capas de software, procesos y sub-procesos de manejo de datos, datos y grupos de datos, y para la acumulacin de las mediciones hasta llegar a fijar el tamao funcional del producto software. Los conceptos utilizados por el mtodo son los siguientes: '( Capa El software a ser medido puede ser particionado en una o ms piezas, de manera que cada pieza opere en un nivel de abstraccin funcional diferente, existiendo un nivel jerrquico de dependencia entre ellas. En un ambiente multicapa, una capa intercambia datos con otras a travs de procesos funcionales. )( Frontera Es el lmite que separa el software perteneciente a una capa con las capas circundantes. Por convencin, los usuarios de una pieza de software estn fuera de la frontera de que marca los lmites de la capa a la que pertenece esa pieza. P$%ina !3 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software *( +s&arios "e so%t,are Son seres humanos, dispositivos u otros sistemas de software que acceden a productos software. Tambin, por definicin, las piezas de software dentro de las capas vecinas inmediatas son consideradas como usuarios cuando interactan con la pieza medida. -( Re.&eriientos %&ncionales "el &s&ario (F+R) Son aquellas especificaciones que describen la manera en que las funciones del software deben ser implementadas. /( Proceso %&ncional Conjunto de movimientos de datos (entrada, salida, lectura, escritura) que implementan un conjunto coherente y lgicamente indivisible de requerimientos funcionales de usuario. Tambin usado el concepto de *omponente funcional de 0ase 4*F&5. 0( Gr&pos "e "atos Conjunto no redundante de datos o atributos que describen a un objeto o entidad. Cada grupo de datos tiene una persistencia (transitoria, corta o indefinida) en relacin a los procesos que los tratan. 1( Entra"a Movimiento de informacin o de datos procedentes del usuario hacia una capa del sistema a travs de su frontera. Se contabiliza una entrada por cada grupo de datos transferido. 2( Sali"a Movimiento de informacin o de datos procedentes del usuario hacia una capa del sistema a travs de su frontera. 3( Lect&ra Movimiento de informacin desde un archivo (almacenamiento) al proceso funcional al que pertenece. '4( Escrit&ra Envo de informacin desde el proceso funcional al que pertenece a un archivo (almacenamiento). Dentro del proceso de medicin se realizan las siguientes tareas: dentificacin de las capas de software. dentificacin de las fronteras del software. dentificacin de los procesos funcionales. dentificacin de los grupos de datos. dentificacin de los atributos de datos. El mtodo propone la contabilizacin de unidades de medida (Cfsu) en la siguiente matriz. Cada grupo de datos se representa en una columna. Los sub-procesos identificados P$%ina !8 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software (entradas-E, salidas-X, lecturas-R, escrituras-W) se acumulan a la derecha de la matriz. En el cruce de procesos-grupos de datos se anotan los sub-procesos de movimientos de datos que realiza el proceso funcional con cada grupo de datos. Un ejemplo de medicin de algunos valores podra ser el siguiente: CAPA PROCESOS FUNCIONA4ES ,r!1o Da%o 1 ,r!1o Da%o $ ..... E#%ra&a E Sali&a L 4e'%!ra R E'ri%!ra W C 1 Proceso Funcional A 1R, 1W 1R 2 2 1 Proceso Funcional B 2R 1W 2 1 Proceso Funcional C Total C ' ) - ) C 2 Proceso Funcional A Proceso Funcional B Proceso Funcional C Proceso Funcional D Total C ) El resultante de la medicin es, por tanto:
TallaCfsu(capa) = _ talla(entradas)+ _ talla(salidas)+ _ talla(lecturas)+ _ talla(escrituras) A pesar de las crticas al modelo de medicin por puntos funcin del FPUG, y de cara a los futuros trabajos, se considera menos aplicable al entorno de aplicaciones de de gestin desarrolladas en CM en mtodo COSMC-FFP, por lo que se ha optado por utilizar el mtodo de estimacin de Albrecht con determinados ajustes. P$%ina !: Definicin y Propuesta de un Marco de Estimacin de Proyectos Software =. A1ro?i"a'i(# a la e@al!a'i(# &e 'o"1le2i&a& &e "o&elo 'o#'e1%!ale &e bae &e &a%o De cara a profundizar en el establecimiento de mtricas sobre modelos de datos, vamos a revisar diferentes trabajos en este campo con diferentes orientaciones (al esfuerzo de mantenimiento, al nivel de calidad del modelo, etc). El objetivo es la bsqueda del anlisis de estas mtricas para su aplicacin en la estimacin de esfuerzos de desarrollo de proyectos partiendo de la complejidad del modelo de datos que lo sostiene: =.1. M*%ri'a &el "o&elo e#%i&a&Erela'i(# orie#%a&a a la e%i"a'i(# ef!er+o &e "a#%e#i"ie#%o Se han analizado trabajos de la Universidad de Castilla-La Mancha en relacin a la aplicacin a estimaciones de tiempos de mantenimiento de aplicaciones en funcin de la complejidad del modelo de datos del sistema a mantener. Fueron expuestos en la Conferencia FESMA-AEMES de Octubre de 2000. Extraigamos de este trabajo la relacin de indicadores de complejidad de un modelo conceptual de una base de datos relacional. Rela'i(# &el i#&i'a&or I#&i'a&or C(&igo Mtricas Entidades Nmero de entidades NE Mtricas - Atributos Nmero de atributos NA Atributos derivados DA Atributos compuestos CA Atributos multivalor MVA Mtricas - Relaciones Nmero de Relaciones NR Relaciones M:N M:NR Relaciones 1:N 1:NR Relaciones Binarias BinaryR En dicho trabajo, y mediante mediciones de tiempos de mantenimiento dedicados a estos sistemas, a travs de la metodologa MANTCA, consiguen datos como los siguientes: NE NA NR MINR 1INR Bi#ar5R Tie"1o &e Ma#%e#i"ie#%o A3oraB ER 1 9 98 6 0 6 6 12 ER $ 17 72 18 0 18 18 17 ER ) 13 84 13 0 13 13 12 ER . 9 80 9 0 9 9 12 ER = 48 178 109 2 101 103 208 Por lo que establecen la siguiente correlacin (tiempo de mantenimiento en horas por cada tipo de indicador del modelo de datos): TMTOE NE TMTOE NA TMTOE NR TMTOE MINR TMTOE 1INR TMTOE Bi#ar5R P$%ina !; Definicin y Propuesta de un Marco de Estimacin de Proyectos Software 0.989 0.971 0.997 1 0.996 0.996 Se han realizado algunas otras propuestas para evaluar de manera objetiva algunas mtricas que nos indiquen la complejidad de un modelo entidad/relacin (en adelante ER). Dado que el modelo de datos es uno de los primeros elementos analizados en un sistemas en la fase de su definicin funcional y que generalmente (al menos s en CM) se utilizan herramientas de modelado de datos, parece interesante profundizar en propuestas para estimacin de proyectos de desarrollo basndose en el anlisis del modelo ER diseado en las primeras fases de su definicin. Se han analizado diferentes fuentes de informacin en este sentido. El Departamento de nformtica de la Universidad de Castilla-La Mancha han dirigido sus estudios a la propuesta de determinadas mtricas asociadas al modelo de datos: De cara a la caracterizacin de estas mtricas acuden a los marcos formales establecidos por Briand, Morasca y Basili (1996-1999) y Zuse (1998) que establecen las condiciones de validacin y caracterizacin de las mtricas. Briand, Morasca y Basili, en la obra BProperty-0ased software en%ineerin% measurementC, presentan las propiedades que deberan cumplir todas las medidas que pretendan representar los atributos de tamao, longitud, complejidad, acoplamiento y cohesin de un sistema software. Por sistema se entiende un conjunto de elementos interrelacionados mediante relaciones binarias. En un sistema (S), compuesto de elementos (E), establece relaciones binarias (R): 5o ne6ati7i"a". El sistema no tendr un tamao negativo: tamao (S) >= 0 8alor n&lo( Para un sistema sin elementos: E = => tamao (S) = 0 A"iti7i"a" "e "&los( Si m1 y m2 son mdulos del sistema, se cumple que: (m1 S y m2 S y E = Em1 Em2 y Em1 Em2 = ) tamao (S) = tamao (m1) + tamao (m2) Coposicin "e "&los "is!&ntos. Tamao de un sistema compuesto de mdulos disjuntos: tamao (S) = tamao (me) / e E. Monotonici"a": Para dos sistemas S' y S'': (S' = <E',R'> y S'' = <E'',R''> y E' E'') tamao (S') tamao (S'') Coposicin "e "&los no "is!&ntos. Tamao de sistema compuesto de mdulos no disjuntos: (m1 S y m2 S y E = Em1 Em2) tamao (S) tamao (m1) + tamao (m2) En diferentes trabajos de la citada Universidad demuestran el cumplimiento total o parcial de estas propiedades por parte de las mtricas definidas. Las mtricas definidas son las siguientes: P$%ina != Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Mtricas de entidades: o NE: Nmero de entidades del modelo. Mtricas de atributos: o NDA Nmero de atributos derivados. o NCA Nmero de atributos compuestos. o NMVA Nmero de atributos multivalor. Mtricas de las relaciones: o NR Nmero de relaciones del modelo. o NM:NR Nmero de relaciones M:N. o N1:NR Nmero de relaciones 1:N, incluyendo relaciones 1:1. o NN-AryR Nmero de relaciones N-arias no binarias. o NBinaryR Nmero de relaciones binarias. o NS_AR Nmero de relaciones maestro/detalle (padre/hijo). o NRefR Nmero de relaciones reflexivas. o NRR Nmero de relaciones redundantes. Otras mtricas estudiadas:
o RD Grado de referenciabilidad. Nmero de claves ajenas. o DRT Profundidad del rbol referencial. Longitud del mximo camino referencial del esquema relacional. o NR Ratio de normalidad. Nmero de tablas en 3FN o superior dividido entre el nmero de tablas. En posteriores trabajos de la Universidad de Castilla-La Mancha profundizan en la caracterizacin de estas mtricas relativas al modelo de datos relacional segn el marco de referencia de Zuse (1998) comprobando el grado de cumplimiento de cada una de ellas de los axiomas propuestos por este autor. Los trabajos continan, proponindose lneas de investigacin posteriores y experimentos para la demostracin emprica en proyectos reales del impacto de las mismas. =.$. M*%ri'a &el "o&elo e#%i&a&Erela'i(# orie#%a&a a la e%i"a'i(# &el #i@el &e 'ali&a& &el "o&elo De un modo similar a los trabajos de anlisis de mtricas dirigidas a la complejidad del modelo de base de datos relacional para su aplicacin a la estimacin del esfuerzo de mantenimiento, posteriores trabajos de la Universidad de Castilla-La Mancha analizan posibles mtricas dirigidas al anlisis de la calidad del modelo. Partiendo de la norma SO/EC 9126 4B+nformation tec'nolo%y D Software product <ualityC5, definen varias caractersticas para evaluar la complejidad de un modelo ER: Understanda0ility. Facilidad de que el modelo pueda ser entendido. P$%ina 1" Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Le%i0ility. Facilidad para que el modelo pueda ser ledo, con criterios estticos. Simplicity. Que el modelo ER contenga el mnimo nmero de construcciones. Analysa0ility. Capacidad de poder analizar el modelo buscando deficiencias o de cara a su mantenimiento. Modifia0ility. Capacidad para que el modelo permita implementar cambios. Sta0ility. Capacidad del modelo para no volverse inestable ante cambios. -esta0ility. Capacidad del modelo para permitir probar los cambios. Con estas caractersticas, se analizan una serie de modelos ER midiendo determinadas mtricas propuestas: RvsE N Relaciones / (N Entidades + N Relaciones) EAvsE N Atributos de Entidades / (N Atrib. Ent. + N Entidades) RAvsR N Atributos de Relaciones / (N Atrib. Rel. + N Relaciones)
M:NRel N Rel. M:N / N Relaciones 1:NRel N Rel. 1:N / N Relaciones
N-aryRel N Rel. 1:N-ary / N Relaciones
BinaryRel N Rel. Binary / N Relaciones Tras una recogida de datos aplican un mtodo de rboles de regresin de manera que establecen la complejidad del modelo respecto a las caractersticas de calidad analizando los valores concretos de las mtricas anteriores, buscando una funcin F que aplicada sobre las mtricas anteriores nos indique el valor de los criterios de calidad. Por ejemplo: F (RvsE; EAvsE ; RAvsR; M:NRel; 1:NRel; N-aryRel; BinaryRel) = Understanda0ility =.). Co#'l!io#e 5 1ro1!e%a Tras el anlisis de los trabajos expuestos anteriormente, las mtricas orientadas al anlisis de los modelos de datos tienen suficiente base terica para considerarse relacionadas con la complejidad del sistema de informacin que funciona sobre estos modelos y, por tanto, a las estimaciones de tamao y esfuerzo de desarrollo de los mismos.. Por tanto, se sugiere el anlisis de mtricas relativas a las entidades, atributos y relaciones de modelos de datos en diferentes proyectos de CM, con el fin de aportarlas a la propuesta de marco de estimacin propuesto al final del trabajo. Dado que en CM los modelos relacionales se definen con la herramienta CASE ERWin, se propone el anlisis automatizado de algunas de las mtricas propuestas para el anlisis de impacto y correlacin entre las mismas y los datos de esfuerzo del proyecto. Para ello, en el siguiente captulo se analizan algunas mediciones de proyectos y de sus modelos de datos en el mbito de CM. P$%ina 1# Definicin y Propuesta de un Marco de Estimacin de Proyectos Software 8. Me&i'io#e e# el /"bi%o &e ICM F Co"!#i&a& &e Ma&ri& 8.1. Me&i'io#e &e 1ro'eo : E%i"a'io#e 1or e#%or#o Se ha distribuido entre las diferentes reas de desarrollo el siguiente formulario orientado a recoger la opinin de los expertos en desarrollo segn el nivel del programador y el tipo de programa:
ESTIMACIONES DE PRO,RAMAS POR ENTORNOS
DE4PKI
TPO NVEL DEL COMPLEJDAD DE PROGRAMA PROGRAMADOR BAJA MEDA ALTA
ENTRADAS BAJO NORMAL ALTO
CONSULTAS BAJO NORMAL ALTO
LSTADOS BAJO NORMAL ALTO
FORMS ).9E..=EPROHC
TPO NVEL DEL COMPLEJDAD DE PROGRAMA PROGRAMADOR BAJA MEDA ALTA
ENTRADAS BAJO NORMAL ALTO
CONSULTAS BAJO NORMAL ALTO
LSTADOS BAJO NORMAL ALTO
FORMS 8.9EREPORTS
TPO NVEL DEL COMPLEJDAD DE PROGRAMA PROGRAMADOR BAJA MEDA ALTA
ENTRADAS BAJO NORMAL ALTO
CONSULTAS BAJO NORMAL ALTO
LSTADOS BAJO NORMAL ALTO
P$%ina 1! Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Los formularios han sido rellenados por un conjunto de evaluadores con perfil de Jefe de Proyecto, Analista y Programador de diferentes niveles y reas de desarrollo. Se recogen tiempos en horas para procesos de entrada, listados y consultas y de baja, mediana o alta complejidad. Para tener un abanico ms amplio de resultados se pide la valoracin sobre diferentes niveles de eficiencia de programadores (bajo, normal o alto). En los cuadros se pueden observar tambin los puntos funcin asignados a cada uno de estos procesos segn el manual de Puntos Funcin del FPUG. Se adjuntan en las siguientes pginas los cuadros de valores recogidos por cada entorno de trabajo: P$%ina 11 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software
PRO,. NI-E4 BAMO PRO,. NI-E4 NORMA4 PRO,. NI-E4 A4TO EI EO E6 EI EO E6 EI EO E6 ENTORNO E-A4UADOR POND TOT B M A B M A B M A B M A B M A B M A B M A B M A B M A 1 2 8 2 3 : 2 3 : 1 2 8 2 3 : 2 3 : 1 2 8 2 3 : 2 3 :
< PROG( 5I8EL ALTO S=5ORMAL 01:4' < P$%ina 12 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software P$%ina 13 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software P$%ina 18 PRO,. NI-E4 BAMO PRO,. NI-E4 NORMA4 PRO,. NI-E4 A4TO EI EO E6 EI EO E6 EI EO E6 ENTORNO E-A4 POND TOT B M A B M A B M A B M A B M A B M A B M A B M A B M A 1 2 8 2 3 : 2 3 : 1 2 8 2 3 : 2 3 : 1 2 8 2 3 : 2 3 :
< PROG( 5I8EL ALTO S=5ORMAL 00:*/ < Definicin y Propuesta de un Marco de Estimacin de Proyectos Software PRO,. NI-E4 BAMO PRO,. NI-E4 NORMA4 PRO,. NI-E4 A4TO EI EO E6 EI EO E6 EI EO E6 ENTORNO E-A4UADOR POND TOT B M A B M A B M A B M A B M A B M A B M A B M A B M A 1 2 8 2 3 : 2 3 : 1 2 8 2 3 : 2 3 : 1 2 8 2 3 : 2 3 :
< PROG( 5I8EL BA>O '--:' < P$%ina 1: Definicin y Propuesta de un Marco de Estimacin de Proyectos Software S=5ORMAL
< PROG( 5I8EL ALTO S=5ORMAL 03:-) < P$%ina 1; Definicin y Propuesta de un Marco de Estimacin de Proyectos Software
PRO,. NI-E4 BAMO PRO,. NI-E4 NORMA4 PRO,. NI-E4 A4TO EI EO E6 EI EO E6 EI EO E6 B M A B M A B M A B M A B M A B M A B M A B M A B M A MEDIA TOTAL )* /4 3) '2 -4 1* '2 *1 01 '- *- 01 ') )0 /' '' )0 -2 3 )- -0 1 '2 *1 1 '2 **
PRO,. NI-E4 BAMO PRO,. NI-E4 NORMA4 PRO,. NI-E4 A4TO G SOBRE MEDIA TOTA4 EI EO E6 EI EO E6 EI EO E6 POR ENTORNOS B M A B M A B M A B M A B M A B M A B M A B M A B M A
P$%ina 1= Definicin y Propuesta de un Marco de Estimacin de Proyectos Software AnAlisis "e "atos B concl&siones$ Hay que hacer las siguientes consideraciones a los resultados recogidos: 1) Existen diferencias notables entre los evaluadores por lo que se ha optado por hacer una media ponderada de los tiempos segn unos pesos que indican el alejamiento de los valores de la media, es decir, se penalizan los tiempos ms altos y ms bajos. Los pesos asignados van de 1 a 4. Este criterio coincide con las recomendaciones de Puttman de hacer medias ponderadas eliminando o quitando peso a los valores mnimos y mximo. 2) Se ha calculado el porcentaje de sobrecoste de tiempos de un programador de nivel bajo sobre los tiempos de programadores considerados de nivel normal. Tambin el porcentaje de mayor rendimiento por el hecho de tener programadores de nivel alto. Se observa cierta valoracin homognea en este sentido. Para un programador de nivel bajo se dan valores de hasta un + 50% sobre los tiempos normales de los procesos. Para un programador de nivel alto se observa un porcentaje de reduccin de tiempos sobre los considerados de nivel normal que llega al 30%. 3) Se ha analizado tambin cmo se han estimado los tiempos para los procesos de los tres entornos. Para ello se ha calculado la media de las medias ponderadas de los tres entornos y las desviaciones de los valores de cada entorno sobre la media general. Se observa que el entorno ms cercano a la media es el de Forms 3.0/4.5. El entorno se Delphi se considera el ms productivo (casi un 25% ms). Tambin se ve que los tiempos para el entorno de Forms 6.0 se consideran un 20% mayores de la media. La interpretacin de estos datos es que, efectivamente, el entorno de Delphi (desarrollo sobre Windows en el PC) se considera bastante rpido. Es tambin un entorno utilizado desde hace 6-7 aos por lo que el nivel de conocimiento es alto. El entorno Forms 3.0 es tambin utilizado desde hace bastantes aos. Es nuevo el uso de Forms 4.5 tras una migracin desde el entorno anterior. El nivel de uso y conocimiento es alto, por lo que los tiempos, an siendo superiores a los de Delphi, estn casi en la media. Por ltimo, en cuanto al entorno Forms 6.0 y Reports 6.0, hay que indicar que es el ms reciente en CM. Se usa desde hace unos dos aos y ha sido la evolucin de los entornos anteriores de Forms 3.0. Se penalizan los tiempos respecto a la media en casi un 20%. 4) Tambin se han evaluado los puntos funcin realizados segn esos tiempos y la referencia para esos procesos del Manual de Puntos Funcin del FPUG. P$%ina 2" Definicin y Propuesta de un Marco de Estimacin de Proyectos Software No se dan valores homogneos de nmero de horas por punto funcin, con lo que se deduce que el mtodo de puntos funcin, segn los criterios del Manual del FPUG no se cumplen en las estimaciones realizadas en CM. En general lo que se observa en las estimaciones es que hay un incremento entre procesos simples, medios y bajos en cuanto a nmero de horas bastante mayor que si lo observamos en puntos funcin. Por ejemplo, para una consulta o salida, el FPUG considera (4, 5, 7) como puntos funcin asociados a complejidad baja, media, alta. Los incrementos observados en horas son mayores. 5) Analizando las estimaciones segn el tipo de proceso, se observa que, en general, se consideran los procesos de entrada de datos los ms complejos, despus los listados y por ltimo las consultas. La razn de sto puede ser que a los procesos de entrada estn asociadas validaciones y almacenamiento de los valores recogidos, operaciones que no se realizan en listados o consultas. P$%ina 2# Definicin y Propuesta de un Marco de Estimacin de Proyectos Software 8.$. Me&i'io#e &e &a%o : Ef!er+o &e 1ro5e'%o 5 'o"1le2i&a& &e lo "o&elo &e &a%o Sobre proyectos desarrollados en los ltimos aos en CM, se ha analizado la complejidad de su modelo de datos y la distribucin de indicadores en los mismos. Para ello se ha aprovechado que todos los modelos de datos en CM estn soportados por la herramienta de modelado de datos ERWin. De algunos reports obtenidos por la herramienta se han tipificado los siguientes indicadores: Rela'i(# &el i#&i'a&or I#&i'a&or C(&igo Mtricas Entidades Nmero de entidades NE Complejidad (N Atributos) NEB,NEM,NEA Mtricas - Atributos Nmero de atributos NA Ratio Atributos/Entidad NAvsE Mtricas - Relaciones Nmero de Relaciones NR Ratio Relaciones/Entidad NRvsE La tasa de complejidad del modelo de datos vendr dada por una funcin del siguiente tipo: F(NE;NEB;NEM;NEA;NA;NAvsE;NE;NRvsE) Se pretende mostrar en este trabajo la relacin entre la complejidad del modelo de datos y los puntos funcin relativos a las funciones de datos. Si el porcentaje relativo a stas (LF bsicamente) se mantiene constante en relacin a los puntos funcin de todo el proyecto, se podra decir que una vez estimada esta complejidad, se podran hacer estimaciones globales del proyecto bastante bien ajustadas. A continuacin se reflejan algunos cuadros con los valores recogidos en proyectos de CM y otro cuadro obtenido por DASMA, Asociacin Alemana de Mtricas del Software, en proyectos realizados entre los aos 1996-98 y en los que han sido medidos los diferentes tipos de funcin y su nivel de complejidad. P$%ina 2! Definicin y Propuesta de un Marco de Estimacin de Proyectos Software NOMBRE DATOS PROYECTO ESFUERZO A5 < PR < TOT
Fianzas VMA 1.040 22(12 1.261 31(:: $.).=
CT - Archivo Histrico 391 1;(8= 581 3:(2= 1.911
ONG - Org. No Gunernamentales 224 !8(3; 592 :"(!8 >.)
Proyectos Normativos 326 32(82 216 18(!" =<;
Gestin de Publicaciones 1.148 8;(38 458 !:(13 1.8;=
Registro de Emisoras 130 !#(11 458 :3(#8 89<
VESO - Vertidos Slidos 91 ##(## 717 ;:(31 >1<
Prog. Escuela 542 #3(=3 2.840 ;1(3; ).)<>
Escuelas nfantiles 328 #:(2" 1.540 ;#(8; 1.>>=
VRU - Vivienda Rural 350 13(3# 600 8"(;; <>8
SOAD - Solicitudes de Admisin 318 !"(:! 1.196 ::(=1 1.=)=
RCP - Registro de Casos Psiquitricos 508 #;(81 2.200 ;"(8= $.;$;
RS - Cuadros de Mando 723 !:(12 1.894 :#(8! $.8..
GATA - Gestin de Tributos 9.208 11(!= 18.417 88(3= $;.8=>
TOTALES M+ =# ## !#8 !: 3=: MED '(43/ *':4' )(*// 00:-2 *(-2' MAE =.!"; 8= #;.2#: ;; !:.83; P$%ina 21 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software NOMBRE Nm. Nm. Complejidad Entidades (N Atrib) PFUN Complejidad Entidades (N Atrib) - FPUG PFUN % Fmero ?atio PROYECTO Ent. Atrib. < 5 G 6-20 G > 20 G I4F < 19 G 20-50 G > 50 G IFPU, DF Relaciones Atri07E ?el7Ent 1 '4 '/ 1 '4 '/ Total
MAE =("8 MED 1:42 M+ 3(;3 Datos de proyectos en CM ordenados por nmero de entidades P$%ina 2; Definicin y Propuesta de un Marco de Estimacin de Proyectos Software ;. Co#'l!io#e 5 1ro1!e%a Despus de analizada la informacin recogida, tanto por parte de CM como del Repositorio del SBSG y de otras fuentes, se propone crear un marco de estimacin de proyectos inicial para CM con el objetivo de ir ajustndolas progresivamente tras el uso de un diccionario de proyectos (aplicacin MDE) que recoger datos de estimaciones iniciales y mtricas finales de cada proyecto, por lo que se podr ir comprobando la fiabilidad de las estimaciones y factores de ajuste propuestos: De los datos contenidos en los cuadros anteriores se pueden deducir los siguientes criterios: Datos so0re esfuerzo en el desarrollo de proyectosI 1) De los proyectos analizados se confirma una distribucin porcentajes de anlisis y programacin entre un 30-70% y un 35-65%. ste era un porcentaje habitual en estimaciones macro de proyectos y de distribucin de plantilla. Tambin vamos a utilizar como primera referencia en cuanto a tiempos de un Jefe de Proyecto de un 10% del tiempo de programacin. 2) En cuanto a la complejidad de las entidades (en nmero de atributos) se observa que la propuesta del mtodo del FPUG es poco discriminatoria. En los modelos de datos analizados casi un 85% de las entidades estn entre 1 y 19 atributos. Un 13,81% estn entre 20-50 atributos y poqusimas entidades (0,83%) superan los 50 atributos. Esa impresin es coincidente con los trabajos de DASMA comparando propuestas de complejidad media en puntos de funcin del componente LF, es decir de los ficheros lgicos internos. Recordemos: FPUG 10 SBSGR 5.0 7,4 CNV 8 Parece ms apropiado buscar unos rangos de nmero de atributos por entidad que distribuyan ms la complejidad que aporta el tratamiento de la entidad a los puntos funcin. Hemos trabajado con los rangos: < 5 (31,08%) Tablas tipo catlogo. Tablas de complejidad baja. 6-20 (53,73%) Tablas de complejidad media. > 20 (14,64%) Tablas de complejidad alta. Se propone asignar a este tipo de tablas una distribucin de pesos en puntos funcin de (5, 10 y 15) para no alejarnos mucho del modelo de peso seguido por otras organizaciones que siguen las indicaciones del FPUG. 3) No hay una correlacin homognea entre horas por punto funcin en las estimaciones de proyectos, por lo que se propone aplicar las estimaciones de los expertos en CM, segn el tipo de proceso, ajustndolas despus con otros factores que se detallarn en el siguiente punto. P$%ina 2= Definicin y Propuesta de un Marco de Estimacin de Proyectos Software ;.1. E%i"a'i(# i#i'ial &e %a"aOo 5 ef!er+o &e !# 1ro5e'%o Se usar bsicamente el Mtodo de medicin del FPUG, pero con algunas variantes. Recordemos las tablas de estimacin de puntos funcin no ajustados del Manual del FPUG 4.1. Si"1le Me&io Co"1le2o PF EI Entradas de Usuario x 3 x 4 x 6 EO Salidas de Usuario x 4 x 5 x 7 E6 Consultas x 4 x 5 x 7 I4F Archivos Lgicos x 7 x10 x15 IEF nterfaces Externas x 5 x 7 x10 PFNA 77 Se puede realizar la misma tabla para el clculo de tiempos en horas relativos a los procesos de entradas, salidas y consultas aplicndoles las estimaciones medias por tipo de proceso y complejidad recogida en CM. En la aplicacin MDE propuesta ms adelante para la recogida de datos, stos sern parmetros iniciales con posibilidad de ser ajustados posteriormente. Si"1le Me&io Co"1le2o KORAS EI Entradas de Usuario x 14 x 35 x 67 EO Salidas de Usuario x 14 x 30 x 56 E6 Consultas x 11 x 27 x 50 Kora 77 Segn las estimaciones recogidas en el Repositorio del SBSG, los puntos funcin relativos a las funciones de datos (LF e EF) van del 27 al 34% del total (en datos relativos a estimaciones iniciales y mediciones una vez acabado el proyecto). Vamos a tomar el valor de un 25-30% ya que los ficheros externos no tienen un peso relevante y no aportan mucha complejidad. En el Repositorio a este concepto se le da un 4-5%. Las funciones de datos que corresponden al anlisis de las entidades del modelo, quedan como sigue: Si"1le Me&io Co"1le2o PF < 5 6-20 > 20 I4F Archivos Lgicos x = x10 x15 IEF nterfaces Externas x 5 x 7 x10 PFNA 77 Se han hecho dos cambios: Los puntos funcin de Archivos de complejidad baja se consideran 5 PF en vez de 7. Son porcentualmente muchos en los proyectos analizados (31,08%) y son de muy baja complejidad (catlogos y tablas auxiliares). Los rangos de nmeros de atributos para calcular la complejidad de una entidad, se P$%ina 3" Definicin y Propuesta de un Marco de Estimacin de Proyectos Software consideran (< 5, 6-20, > 20) sobre los recomendados por el FPUG que son muy poco discriminatorios de la complejidad, ya que un % muy alto (84,81%) quedan en el primer tramo (1-20 atributos). ;.$. E%i"a'io#e %e"1ra#a Si se quieren obtener estimaciones tempranas de un proyecto se pueden utilizar los coeficientes tipo de reparto porcentual del peso de los cinco componentes de un proyecto segn los datos del repositorio del SBSG en sus versiones 5 y 6, y de datos recogidos en la conferencia FESMA 1998:
Ti1o &e F!#'io#e AGB EI EO E6 I4F EIF FESMA 1998 27 39 11 18 5 SBSG Rel. 5 37,2 23,5 13,2 22,3 3,8 SBSG Rel. 6 33,5 23,5 16,0 22,1 5,0 En funcin del tipo de funcin que nos resulte ms fcil de medir segn la informacin que se tiene del proyecto, podemos despus extrapolar una estimacin inicial temprana global del proyecto. Estos datos son coincidentes con los obtenidos por DASMA en que el porcentaje de puntos funcin relativo a los LF va de un 18,22% a un 19,48%. Se usar, por tanto, si se quiere partir del anlisis de complejidad del modelo de datos, de la medida de los indicadores asociados al mismo de nmero de entidades, atributos y relaciones, adems del anlisis de complejidad de las entidades. Hecho sto, extrapolaremos los valores de puntos funcin global del proyecto segn la complejidad del modelo de datos, asocindole a stos un 20-22%. P$%ina 3# Definicin y Propuesta de un Marco de Estimacin de Proyectos Software ;.). I#%ro&!''i(# &e fa'%ore &e a2!%e 1ara ICM Se descarta la aplicacin de los 14 factores de ajuste propuestos en el Manual del FPUG por su poca adaptacin al tipo de aplicaciones y de infraestructuras utilizadas actualmente en la Comunidad de Madrid. Muchos de los factores son difciles de valorar para CM o no tienen ninguna incidencia. Vamos a aplicar algunos factores de ajuste. Son los siguientes: E#%or#o &e &earrollo Segn las estimaciones realizadas por los expertos en CM por entornos expuestos en puntos anteriores, aplicaremos los siguientes factores de ajuste por entornos: E#%or#o Fa'%or &e a2!%e Delphi - 0.25 Forms 4.5/Pro*C + 0.06 Developer + 0.18 Se incluir en el futuro un coeficiente para los desarrollos en Java ya que actualmente es un entorno en crecimiento, pero poco asentado en CM. Ta"aOo &el eC!i1o &e %raba2o Creyendo que este factor tiene influencia sobre los plazos de realizacin de un proyecto, y no teniendo medidas internas en CM sobre este factor, incluiremos los valores propuestos por el SBSG en su Repositorio R 6.0: Ta"aOo Fa'%or &e a2!%e < 4 - 2.0 h / PF 5 - 8 - 0.2 h / PF > 8 + 1.5 h / PF E?1erie#'ia &el eC!i1o &e %raba2o Se asignan unos coeficientes de ajuste en funcin del nivel de experiencia de los participantes en el proyecto que cubren el abanico de coeficientes que se ajustan a las estimaciones recogidas para CM y el impacto de este criterio en la estimacin, que va de un 1.50 a un 0.70. Este factor slo se podr aplicar una vez conocida la composicin del equipo para un proyecto. Ni@el E?1erie#'ia C(&igo Fa'%or &e a2!%e Bajo 1 1.50 Flojo 2 1.25 Normal 3 1.00 Experto 4 0.85 Muy experto 5 0.70 P$%ina 3! Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Para un proyecto concreto y conocido el equipo de trabajo, el ajuste en el siguiente ejemplo podra ser: EC!i1o Pero#a Ni@el Fa'%or 1 Bajo 1.50 2 Flojo 1.25 3 3 Normal 1.00 2 4 Experto 0.85 5 Muy experto 0.70 / Coe%iciente 4(3-
P$%ina 31 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software >. A1li'a'i(# 1ara la e%i"a'i(# &e 1ro5e'%oI Pro5e'%o MIDE Con los criterios base derivados de este trabajo, se ha desarrollado en CM una aplicacin para la ayuda a la estimacin de proyectos. El proyecto se ha denominado MDE. En esta aplicacin se han implementado las conclusiones de este trabajo y se quiere que sea un marco de partida para la recopilacin de datos de estimaciones de proyectos y datos reales que permitan ajustar y mejorar los criterios de estimacin. Es una aplicacin para la recogida de datos de proyectos en donde se almacene: Datos de identificacin y catalogacin del proyecto (entorno de desarrollo). Estimaciones en tiempos de desarrollo del proyecto, tras la valoracin de complejidad de los procesos y funciones de datos y aplicacin de los factores de ajuste. Datos sobre esfuerzo realizado para el desarrollo del proyecto. Datos sobre tamao en PF del proyecto. Dada la estimacin de nmero de procesos y su complejidad, aplicando el mtodo de Puntos Funcin, el sistema ayuda a aplicar las tablas de estimacin de tamao. Mtricas sobre complejidad del modelo de datos de los proyectos. Ratios y mtricas derivadas del anlisis estadstico del Repositorio MDE. La aplicacin es una aplicacin Windows, hecha en lenguaje Delphi 5.0 contra base de datos Oracle. Se pretende con ello tener una herramienta de ayuda a la estimacin de proyectos y construir un repositorio de proyectos para ir ajustando los parmetros de estimacin en funcin de los proyectos analizados tras su terminacin. Los responsables de desarrollo sern los encargados de ajustar los factores de cada entorno de desarrollo como administradores del repositorio. Algunas pantallas de la aplicacin son las siguientes: Pantalla de entrada a la aplicacin con las opciones de men P$%ina 32 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Pantalla de mantenimiento de los factores de ajuste por entornos de desarrollo Pantalla de mantenimiento de los factores de ajuste por tamao del equipo de desarrollo (en horas por PF) P$%ina 33 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Pantalla de mantenimiento de los factores de ajuste por experiencia del equipo de desarrollo Mantenimiento de coeficientes de clculo de tiempos por perfiles de ngenieros y Analistas en relacin al tiempo de programacin estimado para el desarrollo Mantenimiento de tiempos estimados de programacin por tipo de proceso y complejidad expresado en horas P$%ina 38 Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Mantenimiento de proyectos Pantalla de recogida de datos iniciales de tipos de proceso y complejidad P$%ina 3: Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Mantenimiento de proyectos Pantalla de recogida de datos de ajustes por entorno, experiencia y tamao del equipo de trabajo P$%ina 3; Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Mantenimiento de Proyectos Valores finales calculados en base a los datos introducidos Anotacin de tiempos reales al cierre del proyecto P$%ina 3= Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Generacin de listados Obtencin dinmica de listados sobre el repositorio y explotacin de datos (herramienta GLS de CM) Seleccin dinmica de variables, filtros, etc, sobre el diccionario de datos de la aplicacin P$%ina 8" Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Ayuda de la aplicacin Contenidos: conceptos de estimacin de proyectos y de mtricas del software con ejemplos (Contenidos del trabajo de Doctorado de la asignatura sobre Mtricas de Software) P$%ina 8# Definicin y Propuesta de un Marco de Estimacin de Proyectos Software Con la sucesiva recogida de datos en la aplicacin MDE y su uso para facilitar a los responsables de proyecto la estimacin inicial, se pretende dentro del mbito de CM: Tener criterios homogneos de estimacin de proyectos. Recoger las tcnicas y criterios en la normativa y procedimientos de calidad. Difundir las tcnicas y crear cultura de estimacin de proyectos. Realimentar el diccionario de proyectos para una mejora en los coeficientes de clculo y ajuste de mtricas de proyectos. Mejora en las planificaciones de recursos y proyectos en la organizacin. Se propone, tras un periodo de recogida de datos, posteriores trabajos de anlisis de los mismos y el establecimiento de los ratios y coeficientes de clculo de productividad y duracin de proyectos propuestos por el SBSG en su repositorio, cruzando estos datos recogidos en CM con los recogidos a nivel internacional, tratando de hacer propuestas alternativas a los mtodos actuales de medicin de proyectos software. Tras un periodo de recogida de datos de proyectos, y explotando estadsticamente el mismo, se proponen las siguientes mtricas: E%!&io &el PDR (Pro!ect Deli7erB Rate): 3ora 1or PFI Por entornos de desarrollo Por tamao en PF del proyecto Por tamao en personas del equipo de desarrollo Por nivel de experiencia del equipo de desarrollo E%!&io &e e%i"a'i(# &e %ie"1o &e &earrolloI Meses en funcin de tamao del equipo de desarrollo y tamao en PF. Simulaciones de tiempos de desarrollo en funcin de tamao del equipo. Simulaciones de tiempos de desarrollo en funcin de la experiencia del equipo. E%!&io &e %a"aOo e# PF &el 1ro5e'%o 5 &i%rib!'i(# &e 'o"1o#e#%eI Porcentaje de peso de los diferentes tipos de funciones de procesos y datos. E%!&io obre la "*%ri'a &e 'o"1le2i&a& &el "o&elo &e &a%oI Catalogacin de mtricas de datos por proyectos. Ratios de complejidad media de entidades, atributos y relaciones. Anlisis de relacin entre las mtricas de datos y el tamao del proyecto. Anlisis de relacin entre las mtricas de datos y distribucin de funciones de procesos y datos del proyecto. Tasa de complejidad del modelo de datos. Ajuste progresivo de los coeficientes asociados a las mtricas del modelo: Cople!i"a" = (NE*H#+NEB*H!+NEM*H1+NEA*H2+NA*H3+NAvsE*H8+NE*H:+NRvsE*H;) P$%ina 8!