departamento de lenguajes y sistemas …oa.upm.es/367/1/pedro_salvetto_leon.pdf · los modelos de...

DEPARTAMENTO DE LENGUAJES Y SISTEMAS INFORMTICOS E INGENIERA DE SOFTWARE

Facultad de Informtica Universidad Politcnica de Madrid

Doctorado Conjunto en Ingeniera Informtica UPM-ORT

TESIS DOCTORAL

Modelos Automatizables de Estimacin muy Temprana del Tiempo y Esfuerzo de Desarrollo de Sistemas de

Informacin

Autor Pedro Fernando Salvetto de Len

Magster en Computacin y Sistemas de Informacin

Directores Francisco Javier Segovia Prez

Doctor en Informtica

Juan Carlos Nogueira de Len Ph.D. in Software Engineering

Ao: 2006

Esta Pgina ha sido dejada intencionalmente en blanco

Dedico este trabajo a mis Tres Maras y a la memoria de mi abuela Amelia

que aunque ya no se encuentra fsicamente entre nosotros ha

sido mi mayor mentora y nunca ha dejado de acompaarme.

Agradecimientos En primer lugar deseo expresar mi agradecimiento a la Universidad Politcnica de

Madrid, la Universidad ORT Uruguay, el Programa de Desarrollo Tecnolgico financiado por el Banco Interamericano de Desarrollo y la Fundacin Banco Santander Central Hispa-no que hicieron posible que realizara este doctorado.

Mi ms sincero y profundo agradecimiento a mis directores de tesis. Sin ellos no hubiera podido superar los momentos ms difciles. Formaron un equipo perfecto comple-mentndose en todo y lograron que estos aos de arduo trabajo me proporcionaran los ma-yores beneficios. Con gran sabidura siempre supieron encontraron las palabras de aliento adecuadas y reconocer los momentos oportunos tanto para tomar distancia y permitirme reflexionar como para acercarse y orientarme. Gracias Juan Carlos por tu paciencia, las numerosas y productivas reuniones que mantuvimos durante todo este tiempo y tu constan-te apoyo. Gracias Javier por tu constante apoyo y por haber encontrado siempre, en tu complicada agenda actual en el Decanato, tiempo para contestar mis correos y llamadas, mantener largas reuniones durante mis estancias en UPM y las tuyas en ORT. Gracias a ambos por sus inteligentes y oportunos comentarios, por compartir conmigo su experiencia y conocimiento y las horas dedicadas a la lectura de esta tesis. Realmente fue un privilegio tener no uno sino dos directores de su talla acadmica y humana.

En la etapa de investigacin deb seguir un camino sinuoso no exento de riesgos e in-certidumbres que complicaron los aspectos logsticos y administrativos. Si he llegado hasta aqu es porque en todas estas difciles instancias fui escuchado, acompaado y apoyado con paciencia y comprensin por numerosas instituciones y personas. Entre las institucio-nes fue central el papel del Programa de Desarrollo Tecnolgico, la Facultad de Informti-ca de la Universidad Politcnica de Madrid, su Decanato y Vicedecanato de Doctorado y Postgrado y la Universidad ORT Uruguay, su Rectorado, su Decanato de Desarrollo Aca-dmico y su Facultad de Ingeniera. Entre las personas debo mencionar al Dr. Pablo Darscht, la Cra. Myriam Aldabalde, la Ec. Michele Schneck y Graciela Burgueo, en el PDT; al Dr. Javier Segovia, la Dra. Ernestina Menasalvas y el Dr. Jos Lus Morant en la Facultad de Informtica de UPM; el Dr. Jorge Grnberg, el Ing. Mario Fernndez, el Dr. Juan Carlos Nogueira, la Dra. Patricia Corbo y el Ms.C. Julio Fernndez en la Universidad ORT Uruguay.

No hubo gestin que Mara del Coro Prez Garca y Dori Martn no pudieran realizar en la Facultad de Informtica de UPM y Conchita de Frutos en la residencia del Rectorado. Muchas gracias amigas por su rpida y eficaz respuesta a todas mis solicitudes.

El Cuerpo Acadmico del Departamento de Lenguajes y Sistemas Informticos, el personal y estudiantes de la Facultad de Informtica de UPM, y el fraterno y hospitalario pueblo espaol en su conjunto lograron que durante mis estancias en Madrid me sintiera mejor que en casa.

Mi reconocimiento y gratitud al Ms.C. Julio Fernndez, Decano de Desarrollo Aca-dmico de Universidad ORT Uruguay, por haber estado siempre disponible, las numerosas, interesantes e instructivas discusiones sobre los modelos, sus sabios consejos y su continuo y consistente apoyo y aliento.

Un especial agradecimiento a quienes apoyaron el desarrollo de las herramientas e hicieron posible la recoleccin de datos para esta investigacin, el Ing. Enrique Latorres y Jos Lus Subelz del Departamento de Informtica del Ministerio de Transporte y Obras Pblicas, el A/P Juan Andrs Leyras del Departamento de Informtica de Sanidad Policial, Mario Accorenti del Departamento de Informtica de Casa de Galicia, los ingenieros Nico-

ls Jodal, Karina Santo, Jos Lus Chalar, Claudia Araujo, Cecilia Belletti y Gustavo Ca-rriquiry de Artech Consulting, el contador Gonzalo Prez y el Ing. Joaqun Gonzlez de CONEX, scar Camargo de la Universidad del Trabajo y Universidad ORT Uruguay y la Facultad de Ingeniera de Universidad ORT Uruguay.

Muchas gracias Claudia por tu enorme paciencia y porque, a pesar de tus ocupacio-nes, siempre encontraste el tiempo para apoyar la recoleccin de datos y participar de las entrevistas. Gracias Jos Lus por tu esfuerzo, an a las seis de la maana, nuestras reunio-nes de trabajo fueron muy disfrutables.

Los interesantes y constructivos comentarios del Dr. Lus Olsina de la Universidad Nacional de la Pampa, acerca de los trabajos de fin de carrera de los estudiantes que desa-rrollaron las herramientas y recogieron las mtricas, durante las defensas, as como las charlas que mantuvimos durante sus estancias en Universidad ORT fueron muy valiosos. Gracias Lus por tu apoyo constante.

Mi reconocimiento al Departamento de Biblioteca de Universidad ORT, su dedica-cin y profesionalismo facilitaron enormemente este trabajo. Merece una mencin especial el trabajo de las biblioteclogas Magela Sellanes y Mariela Balverde. Su paciencia no co-noci lmites. Tuvieron que administrar una biblioteca ms en mi casa! Muchas gracias Magela y Mariela por su trabajo profesional y abnegado.

Pedro Fernando Salvetto de Len Montevideo, 8 de mayo de 2006

Reconocimientos Este doctorado fue financiado por la Universidad Politcnica de Madrid, y la Univer-

sidad ORT Uruguay. Las estancias y traslados a Madrid fueron financiados por el Banco Interamericano

de Desarrollo a travs del Programa de Desarrollo Tecnolgico (contrato Beca Crdito de Postgrado S/C/BE/04/06) y el Rectorado de la Universidad Politcnica de Madrid a travs de la Beca de la Fundacin Santander Central Hispano.

La Asistencia a congresos y conferencias fue financiada por el Fondo de Investiga-cin de la Facultad de Ingeniera de la Universidad ORT Uruguay y la Facultad de Infor-mtica de la Universidad Politcnica de Madrid.

La inscripcin a congresos y conferencias fueron financiadas por el PDT, la AEMS y el CLEI.

RESUMEN

i

Resumen A diferencia de los procesos de produccin industrial, los procesos de produccin de

software generan productos intangibles y requieren comunicacin y coordinacin intensi-vas lo que contribuye a aumentar los riesgos y dificultar la estimacin.

A pesar de largos aos de investigacin y desarrollo el problema de la estimacin formal y estructurada (independiente del juicio experto) del tiempo y esfuerzo requeridos para desarrollar un sistema de informacin intensivo en gestin de datos permanece abier-to. Las tcnicas de estimacin ms extendidas actualmente se apoyan en la premisa - poco realista - de estabilidad de requisitos, requieren expertos humanos y se basan en mtricas disponibles recin en la fase de diseo temprano del sistema.

Esta tesis desarrolla y valida: (a) Indicadores formales, y muy tempranos de complejidad esencial de SI, calcu-

lables a partir del conjunto de las visiones de datos de sus usuarios finales. Estos indicado-res son independientes (1) del juicio experto, (2) de la tecnologa usada para desarrollar el SI y (3) del conjunto de visiones de datos de los usuarios sobre la base del cual se obtenga (la forma en que los usuarios ven los datos del SI).

(b) Modelos estticos, globales, formales, independientes del juicio experto, de estimacin muy temprana del tiempo y esfuerzo de desarrollo de SI. Estos modelos em-plean, como parmetros de entrada, la eficiencia del grupo de desarrollo, la volatilidad de los requisitos y la complejidad esencial del sistema a desarrollar medida con los indicado-res referidos en (a).

Los indicadores de complejidad esencial son aplicables a sistemas de gestin intensi-va de datos y son calculables muy temprana y automticamente a partir de las visiones de datos de los usuarios finales del sistema.

Los modelos de estimacin de tiempo y esfuerzo son aplicables a Sistemas de In-formacin de Gestin Intensiva de Datos desarrollados en torno a bases de datos relaciona-les, con procesos evolutivos y giles, metodologas de desarrollo orientadas a los datos y generacin automtica de cdigo a partir de especificaciones formales.

Los indicadores de complejidad esencial pueden generalizarse a SI desarrollados con otras herramientas y metodologas y, a partir de su experiencia previa, cada organizacin puede construir sus propios modelos de estimacin. Con este propsito se han desarrollado herramientas que permiten calcularlos automticamente a partir de informacin ingresada manualmente sobre las vistas de datos de usuario, el esquema relacional o extrayendo au-tomticamente las mtricas para calcularlo a partir de un esquema de bases de datos rela-cional preexistente.

Los modelos son aplicables continua y muy tempranamente desde la etapa de inge-niera de requisitos y no desconocen los inevitables cambios en los requisitos, y las condi-ciones de ejecucin del proyecto; sino que los asumen y apoyan su gestin sobre bases ob-jetivas.

RESUMEN

ii

Abstract Contrary to the industrial processes of production, the software production processes

generate intangible products and require intensive communication and coordination which contributes to increase the risks and to complicate the estimation. In spite of long years of investigation and development, the formal and structured estimation (independently of the expert judgment) of the time and effort required to develop a MIS remains as an open problem. The most extended estimation techniques at present are supported by the premise not so realistic - of stability of requirements, and require human experts. The present models of estimation are based on metrics available in the early design phase.

This thesis develops and validates (1) early IS complexity metric and formal (able to be automated) (2) early time and effort of information systems development esti-

mation models. The development of the systems to be studied is based on relational data bases, with

evolutionary and agile processes and automatic generation of code from formal specifica-tions. These models employ as input parameters the development team efficiency, the re-quirement volatility, the development speed and the essential complexity of the system to be developed. This complexity is measured automatically from the users data views of the system with independence of the technology to utilize.

These models are applicable continuously, very early at the requirement engineering phase and on and dont deny, but assume the inevitable requirements changes and support their management.

TABLA DE CONTENIDO

iii

TABLA DE CONTENIDO

I INTRODUCCIN Y MOTIVACIONES ....................................................................... I1 I.A Introduccin..................................................................................................I2 I.B Objetivos del Trabajo....................................................................................I6

I.B.1 Subojetivos ..........................................................................................I6 I.C Aportaciones Realizadas por esta Tesis ........................................................I7

I.C.1 Tericas ...............................................................................................I7 I.C.2 Prcticas ..............................................................................................I7

I.D Organizacin del trabajo...............................................................................I8

PARTE 1 ESTADO DE LA CUESTIN II ESTADO DE LA CUESTIN ................................................................................II1

II.A Introduccin................................................................................................ II2 II.B Estimacin y Gestin del Riesgo en Ingeniera de Software ...................... II2

II.B.1 El enfoque tradicional de Riesgo.............................................................II3 II.B.2 Una Visin Holstica: Oportunidades, Amenazas, Riesgos...........................II4 II.B.3 Prcticas recomendadas, guas y listas de verificacin...............................II4 II.B.4 Conclusiones sobre el enfoque tradicional de gestin de riesgo ..................II5 II.B.5 Enfoques Probabilistas de Estimacin del Riesgo ......................................II6 II.B.6 Estado de la Prctica ............................................................................II7 II.B.7 Conclusiones sobre Gestin del Riesgo ....................................................II8

II.C Mtricas de Software .................................................................................. II8 II.C.1 Teora de medicin ...............................................................................II9 II.C.2 Conclusiones sobre Teora de la medicin.............................................. II13 II.C.3 Mtricas ............................................................................................ II13 II.C.4 Conclusiones sobre mtricas................................................................ II31

II.D Estimacin de Tiempo y Esfuerzo de Desarrollo ....................................... II31 II.D.1 La Estimacin en Etapas Tempranas del Proceso de Desarrollo................. II32 II.D.2 Qu debe estimarse?......................................................................... II34 II.D.3 Estimacin de Tiempo y Esfuerzo ......................................................... II34 II.D.4 Conclusiones sobre estimacin............................................................. II58

II.E Modelos Matemticos de los Datos: Dos Aportes Pioneros Germinales ... II59 II.E.1 el modelo relacional (Codd, 1970) ........................................................ II59 II.E.2 El Diseo de Sistemas Basado en la Estructura de los Datos (Warnier, 1973) II

59 II.E.3 Diagramas de Warnier-Orr .................................................................. II60 II.E.4 Metodologa de Warnier-Orr (DSED) ..................................................... II60 II.E.5 Elaboracin del Modelo de Datos .......................................................... II60

II.F Procesos de Desarrollo.............................................................................. II61 II.F.1 Procesos de Desarrollo giles vs. Conducidos por la Planificacin y

Documentacin Intensivas................................................................... II61 II.G Resumen Contextual................................................................................. II66

PARTE 2 ESTUDIO Y RESOLUCIN DEL PROBLEMA III PLANTEAMIENTO DEL PROBLEMA................................................................... III1

III.A Introduccin...............................................................................................III2 III.B Planteamiento............................................................................................III3 III.C Objetivos del trabajo .................................................................................III5

IV DESARROLLO DE LA SOLUCIN ....................................................................... IV1 IV.A Introduccin................................................................................................IV2 IV.B Definiciones, Hiptesis y Supuestos Usados para Plantear la Solucin......IV2

IV.B.1 Hiptesis acerca de los Sistemas Observados.......................................... IV6 IV.C Alcance de la Investigacin y mbito de Aplicacin de sus Resultados .....IV6

IV.C.1 mbito de Aplicacin de los Resultados Obtenidos ................................... IV7 IV.D Modelo Conceptual......................................................................................IV7 IV.E Metodologa ................................................................................................IV8

IV.E.1 Etapas Seguidas.................................................................................. IV8 IV.E.2 Desarrollo de Modelos........................................................................ IV10

V MODELO CONCEPTUAL ......................................................................................V1 V.A Introduccin................................................................................................. V2 V.B La Herramienta de Especificacin Formal .................................................... V2 V.C Los Modelos a Construir............................................................................... V5

V.C.1 Medicin independiente del juicio experto de los parmetros de los modelos V6

TABLA DE CONTENIDO

iv

V.C.2 La Complejidad Esencial de un SIGIDES y Nuestras Hiptesis Iniciales........ V7 V.C.3 Indicador de Complejidad Esencial y su Semntica ................................... V8 V.C.4 Nomenclatura de Modelos y Relaciones entre Mtricas, Modelos e Indicadores

V9 VI METODOLOGA ............................................................................................ VI1

VI.A Definicin de las caractersticas del soporte emprico y experimental de la investigacin .........................................................................................................VI2 VI.B Seleccin de la herramienta de especificacin formal ................................VI4

VI.B.1 Determinacin de las caractersticas que deba poseer .............................VI4 VI.B.2 Bsqueda de Herramientas con las caractersticas de la Definicin III-15 ...VI4

VI.C Desarrollo del modelo conceptual...............................................................VI5 VI.D Planificacin del trabajo de campo .............................................................VI6 VI.E Desarrollo y Validacin de las Herramientas de Apoyo al Trabajo de Campo VI6 VI.F Desarrollo del Trabajo de Campo................................................................VI6 VI.G Anlisis de los Resultados del Trabajo de Campo y Depuracin de Observaciones.......................................................................................................VI7 VI.H Desarrollo de Modelos.................................................................................VI7

VI.H.1 Variables Independientes Identificadas ..................................................VI8 VI.H.2 Modelos e Indicadores de Complejidad Esencial Desarrollados ..................VI9

VI.I Evaluacin de la Calidad de los Resultados Obtenidos .............................VI10 VI.I.1 Metodologa...................................................................................... VI10 VI.I.2 Conclusiones .................................................................................... VI11

VI.J Generalizacin de los resultados ..............................................................VI11 VII LOS PROYECTOS OBSERVADOS Y LOS DATOS RECOPILADOS ..............................VII1

VII.A Los Proyectos observados......................................................................... VII2 VIII RESUMEN DE MODELOS DE ESTIMACIN E INDICADORES DE COMPLEJIDAD ESENCIAL

OBTENIDOS ......................................................................................... VIII1 VIII.A Introduccin.............................................................................................VIII2 VIII.B Desarrollo y Validacin de los Modelos de Estimacin de Esfuerzo y Tiempo VIII2

VIII.B.1 Variables Independientes y Datos Recopilados ..................................VIII2 VIII.B.2 Resumen de los Modelos de Estimacin e Indicadores de Complejidad

esencial Obtenidos ............................................................................VIII3 IX MODELOS DE ESTIMACIN MUY TEMPRANA DE ESFUERZO Y TIEMPO E INDICADORES DE

COMPLEJIDAD ESENCIAL DE LA ESTRUCTURA DE LOS DATOS............................ IX1 IX.A Estadsticos Descriptivos de los Datos de Entrada y Variables Respuesta .IX2 IX.B Estudio de Correlaciones entre las Variables Observadas ..........................IX5 IX.C Modelos de Estimacin Temprana de Tiempo y Esfuerzo ...........................IX8

IX.C.1 Modelos de Estimacin Temprana Basados en las Mtricas de Complejidad de Bases de Datos Relacionales definidas por el grupo ALARCOS ................... IX9

IX.C.2 Modelos de Estimacin muy Temprana de Esfuerzo Basados en los Indicadores de Complejidad de la Estructura de los Datos (ICEDE e ICEDT)............... IX17

IX.C.3 Modelos de Estimacin muy Temprana de Tiempo Basados en los Indicadores de Complejidad de la Estructura de los Datos (ICEDE e ICEDT) ................... IX20

IX.D Conclusiones sobre las Mtricas de Complejidad de la Base de Datos, los indicadores de Complejidad Esencial y los Modelos Basados en Ellos ................IX23

X MODELOS DE ESTIMACIN POST MRTEM DE ESFUERZO Y TIEMPO...........................X1 X.A Introduccin................................................................................................. X2 X.B Estudio de Correlaciones entre las Variables Observadas ........................... X2 X.C Modelos de Estimacin Post Mrtem de Tiempo y Esfuerzo obtenidos en Base a los Indicadores de Complejidad de la Estructura de los Datos ICEDE e ICEDT .. X8

X.C.1 Modelos de Estimacin Post Mrtem de Esfuerzo ...................................... X8 X.C.2 Modelos de Estimacin Post Mrtem de Tiempo........................................ X9 X.C.3 Comentarios sobre los Modelos de Estimacin Post Mrtem de Esfuerzo Basado

en el ICEDE (MEPMEICEDE)................................................................... X9 X.C.4 Comentarios sobre los Modelos de Estimacin Post Mrtem de Esfuerzo Basado

en el ICEDT (MEPMEICEDT) ................................................................. X10 X.C.5 Comentarios sobre los Modelos de Estimacin Post Mrtem de Tiempo Basados

en el ICEDE (MEPMTICEDE) ................................................................. X12 X.C.6 Comentarios sobre los Modelos de Estimacin Post Mrtem de Tiempo Basados

en el ICEDT (MEPMTICEDT) ................................................................. X14 XI EVALUACIN DE LA PRECISIN Y CONSISTENCIA DE LOS MODELOS DE ESTIMACIN

OBTENIDOS ............................................................................................ XI1 XI.A Estructura de Este Captulo.........................................................................XI2

TABLA DE CONTENIDO

v

XI.B Criterios de Evaluacin de la Precisin y Consistencia de los Modelos de Estimacin.............................................................................................................XI2

XI.B.1 Modelos de Estimacin de Esfuerzo........................................................XI6 XI.C Resumen de Errores Cometidos por los Modelos de Estimacin de Esfuerzo XI8

XI.C.1 Modelos de Estimacin de Tiempo .........................................................XI9 XI.D Resumen de Errores Cometidos por los Modelos de Estimacin de Tiempo .XI11 XI.E Evaluacin de la calidad y consistencia de los modelos de estimacin ....XI12

XI.E.1 Evaluacin de los Modelos de Estimacin de Esfuerzo ............................ XI12 XI.E.2 Evaluacin de Modelos de Estimacin de Tiempo ................................... XI15

XI.F Conclusiones .............................................................................................XI18 XII VALIDACIN EMPRICA DE LOS INDICADORES DE COMPLEJIDAD DE LA ESTRUCTURA DE

LOS DATOS (ICED) Y LOS MODELOS EMPRICOS DE ESTIMACIN ...................XII1 XII.A Introduccin.............................................................................................. XII2 XII.B Validacin de los modelos de estimacin de esfuerzo .............................. XII3

XII.B.1 Normalidad de los Residuos .................................................................XII3 XII.B.2 Grficos de Dispersin de Errores Relativos vs. Magnitud de Esfuerzo y del

ICEDE...............................................................................................XII3 XII.B.3 Anlisis Exploratorio de Datos..............................................................XII3 XII.B.4 Pruebas para Muestras Relacionadas ....................................................XII6 XII.B.5 Pruebas Paramtricas de Comparacin de Medias................................. XII12 XII.B.6 Conclusiones sobre los modelos de estimacin de esfuerzo.................... XII16

XII.C Validacin de los modelos de estimacin de tiempo............................... XII17 XII.C.1 Normalidad de los Residuos ............................................................... XII17 XII.C.2 Grficos de Dispersin de Errores Relativos vs. Magnitud de Tiempo y del ICEDT

XII17 XII.C.3 Anlisis Exploratorio de Datos............................................................ XII17 XII.C.4 Pruebas no Paramtricas para Muestras Relacionadas ...........................XII20 XII.C.5 Pruebas Paramtricas de Comparacin de Medias................................. XII21 XII.C.6 Conclusiones sobre los modelos de estimacin de tiempo ...................... XII24

XII.D Conclusiones sobre los Modelos de estimacin temprana de tiempo y esfuerzo y los indicadores de complejidad ICEDE e ICEDT ............................................. XII24

PARTE 3 CONCLUSIONES Y LNEAS DE TRABAJO FUTURAS XIII CONCLUSIONES Y LNEAS DE TRABAJO FUTURAS.......................................... XIII1

XIII.A Conclusiones ...........................................................................................XIII2 XIII.B mbito De Aplicacin de Estos Resultados, Limitaciones y Lneas de Trabajo Futuras ...............................................................................................................XIII4

XIII.B.1 mbito de Aplicacin .....................................................................XIII4 XIII.B.2 Limitaciones .................................................................................XIII5 XIII.B.3 Posibilidades de Generalizacin de los Resultados y Lneas de Trabajo Futuras

XIII5 XIV REFERENCIAS.......................................................................................... XIV1

ANEXOS XV ANEXO I SELECCIN DE LA HERRAMIENTA DE ESPECIFICACIN FORMAL ...............XV1

XV.A Introduccin............................................................................................... XV1 XV.B Definicin de sus Caractersticas ............................................................... XV1 XV.C Bsqueda de Herramientas con las caractersticas de la Definicin IV-15 XV2

XVI ANEXO II HERRAMIENTAS DE OBTENCIN AUTOMTICA DE MTRICAS.............. XVI1 XVI.A Obtencin de Mtricas a Partir de Bases de Conocimiento Genexus....... XVI2

XVI.A.1 Introduccin.................................................................................. XVI2 XVI.A.2 Requisitos Funcionales y No Funcionales de la Herramienta ................. XVI2 XVI.A.3 Funcionalidades ............................................................................. XVI3 XVI.A.4 Informacin Extrada ....................................................................... XVI7

XVI.B Herramienta de obtencin automtica de mtricas de complejidad de bases de datos relacionales .............................................................................................. XVI9

XVI.B.1 Introduccin.................................................................................. XVI9 XVI.B.2 Integridad y Confidencialidad .......................................................... XVI9 XVI.B.3 Proceso automtico........................................................................ XVI9 XVI.B.4 Aplicacin DBSE (DataBase Structure Extractor) .............................. XVI10 ORACLE ......................................................................................... XVI12 Otros Sistemas de Gestin de Bases de Datos (DBMS)......................... XVI14

XVI.C Aplicacin V2M (View to Metrics) .......................................................... XVI21 XVI.C.1 Descripcin................................................................................... XVI21

TABLA DE CONTENIDO

vi

XVI.D IDE integrado a GENEXUS para obtencin de mtricas en tiempo real . XVI26 XVI.D.1 REQUISITOS FUNCIONALES.......................................................... XVI26

XVII ANEXO III FRECUENCIAS DE LAS VARIABLES OBSERVADAS.......................... XVII1 XVII.AFrecuencias de las Variables sin Trasformar XVII1 XVII.BFrecuencias de las Variables Transformadas Mediante Logaritmo XVII6

XVIII ANEXO IV TABLAS Y GRFICAS MODELOS DE ESTIMACIN TEMPRANA DE TIEMPO Y ESFUERZO .........................................................................................XVIII1

XVIII.A METE1 (Modelo de estimacin Temprana de Esfuerzo en base a mtricas grupo ALARCOS) ............................................................................................. XVIII1 XVIII.B METT1 (Modelo de estimacin Temprana de Tiempo en base a mtricas grupo ALARCOS) ............................................................................................. XVIII8 XVIII.C Correlaciones Entre Indicadores de Complejidad Tiempo y Esfuerzo XVIII16 XVIII.D METEICEDE (Estimacin Temprana de Esfuerzo Basada en el ICEDE) XVIII18 XVIII.E METEICEDT (Estimacin Temprana de Esfuerzo Basada en el ICEDT) XVIII25 XVIII.F METTICEDE (Estimacin Temprana de Tiempo Basada en el ICEDE) XVIII32 XVIII.G METTICEDT (Estimacin Temprana de Tiempo Basada en el ICEDT) XVIII39

XIX ANEXO V GRFICOS Y TABLAS MODELOS DE ESTIMACIN POST MRTEM DE TIEMPO Y ESFUERZO ............................................................................................ XIX1

XIX.A MEPMEICEDE (Estimacin Post Mrtem de Esfuerzo Basada en el ICEDE) XIX1 XIX.B MEPMEICEDT (Estimacin Post Mrtem de Esfuerzo Basada en el ICEDT) XIX9 XIX.C MEPMTICEDE (Estimacin Post Mrtem de Tiempo Basada en el ICEDE) . XIX18 XIX.D MEPMTICEDT (Estimacin Post Mrtem de Tiempo basada en el ICEDT) . XIX27

XX ANEXO VI TABLAS Y GRFICAS EVALUACIN DE MODELOS DE ESTIMACIN...........XX1 XX.A Esfuerzo ..................................................................................................... XX1

XX.A.1 Todos los Casos ................................................................................. XX1 XX.A.2 Casos Seleccionados para el Desarrollo de los Modelos ........................... XX3 XX.A.3 Casos de Contraste ............................................................................ XX5

XX.B Tiempo ....................................................................................................... XX7 XX.B.1 Todos los Casos ................................................................................. XX7 XX.B.2 Casos Seleccionados para el Desarrollo de los Modelos ........................... XX9 XX.B.3 Casos de Contraste .......................................................................... XX11

XX.C Grficos de Errores Relativos y Pred(K) Modelos de Estimacin de Esfuerzo XX13 XX.D Grficos de Errores Relativos y Pred(K) Modelos de Estimacin de Tiempo XX14 XX.E Grficos y Tablas ......................................................................................XX15

XX.E.1 Esfuerzo.......................................................................................... XX15 XX.E.2 Errores en la Estimacin de Esfuerzo .................................................. XX70 XX.E.3 Tiempo ........................................................................................... XX89

I INTRODUCCIN Y MOTIVACIONES

MODELOS AUTOMATIZABLES DE ESTIMACIN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIN I1




I.A INTRODUCCIN

La ingeniera de software tiene numerosos puntos de contacto con disciplinas ms antiguas como la arquitectura y la ingeniera civil. Sin embargo, debido a su juventud y la intangibilidad del producto que genera, no ha alcanzado, todava, el mismo grado de for-malizacin [KAV01, MCC96, CON, SOM01]. Carece de patrones de medida de tamao del software independientes del juicio experto y que puedan ser tiles para seguir el avance de los proyectos de desarrollo, estimar tempranamente sus costos, gestionar cambios, apo-yar relaciones contractuales ms laxas y naturales sin riesgo para las partes, y aumentar la transparencia e integracin de la relacin entre clientes y desarrolladores [KAV01, HUM01, GSA00, GSA03].

Cuando un cliente desea contratar el desarrollo de un sistema de informacin se pre-senta el problema de la estimacin del tamao funcional del sistema y el costo de su desa-rrollo.

Tanto usuarios como desarrolladores nos hemos acostumbrado a proyectos que so-brepasan los plazos y costos previstos.

As, es comn que el cliente solicite un precio cerrado. Esto ocurre cuando ninguna de las partes ha terminado de comprender el alcance del sistema de informacin que se desea desarrollar con consecuencias negativas para todos los involucrados. El desarrollador puede tomar coberturas excesivas, poniendo en peligro la factibilidad del negocio, resul-tando condiciones injustas para el cliente y desfavorables para su prestigio u optar por el precio de mercado. En el ltimo caso el cliente esta tomando, junto con el desarrollo que contrata, un riesgo del que no es consciente y es posible que el proyecto resulte inviable desde el punto de vista econmico o temporal [HUM01, MCC98]. Frecuentemente, al comparar ofertas, no se realiza una evaluacin del riesgo que implica cada una de ellas y se comienza contratando un desarrollo por un precio atractivo, que luego termina superando los precios, inicialmente ms altos, de otras ofertas.

La industria, la academia y la sociedad en general, reclaman que el desarrollo de software se aleje ms de ser una actividad artesanal, se profesionalice y comience a ser ms predecible.

Una de las principales dificultades para ello es nuestra pobre comprensin de los procesos internos que se producen en los equipos de trabajo. Sin embargo, hasta tanto al-cancemos ese conocimiento, podemos construir modelos empricos que nos permitan esti-mar [BOE99b].

Un problema de los modelos de estimacin actuales es que son dependientes del jui-cio experto y requieren gerentes con experiencia para aplicarlos [NOG00].

Los gerentes con experiencia, son naturalmente escasos [NOG00] y la tendencia ac-tual hacia metodologas giles con equipos reducidos, altamente motivados y comprometi-dos con el proyecto profundiza el problema.

Para reducir la incidencia de estos problemas es importante disminuir las fuentes de variacin tanto en el proceso de desarrollo como en el de estimacin. Entre las principales se encuentran la tecnologa, el juicio experto y las mtricas de tamao no tomadas autom-tica y tempranamente como LOC y FP [KAV01, SAL04a, SAL04b, SAL05].

Independizar la estimacin (no la interpretacin de sus resultados) del juicio experto (1) aumenta la credibilidad de la industria, (2) facilita la relacin entre clientes y desarro-



lladores aumentando su transparencia, (3) puede ser el comienzo de metodologas de ges-tin de contratos que no se basen en un precio cerrado en el momento en que menos se sa-be del proyecto sino en una metodologa de clculo de acuerdo a las condiciones de ejecu-cin del proyecto (volatilidad de requisitos, eficiencia de la organizacin, esfuerzo medio o velocidad de desarrollo, etc.) y la complejidad del sistema a construir, (4) contribuye a po-ner en evidencia, sobre bases objetivas, los riesgos que introducen las fechas fijadas con criterios no tcnicos (por ejemplo polticos, o no objetivos) y apoya (5a) la gestin conjun-ta de los cambios, (5b) la discusin sobre bases objetivas y claras, para todos los actores, de plazos, alcance de los proyectos y los riesgos derivados de ellos [KAV01] y (5c) equi-pos pequeos que no dispongan de gerentes con experiencia [LAT03, SAL04a, SAL04b, SAL05].

Existen numerosas fuentes de variacin en el proceso de software que dificultan la estimacin temprana [SOM01, MCC96].

Disciplinas como la arquitectura e ingeniera civil disponen de planos, maquetas etc. a partir de las cuales es posible extraer mtricas en escala de proporcin. Esto permite ajus-tar el diseo del producto a desarrollar y, al mismo tiempo, evaluar, sobre bases concretas y objetivas, su impacto sobre los costos, plazos e incluso las tecnologas adecuadas para su construccin.

Indicadores calculables tempranamente sobre la base de las visiones de datos de los usuarios y modelos que, a partir de ellos y las condiciones de ejecucin del proyecto, per-mitan estimar plazos y costos, seguramente no elevarn la formalizacin de la ingeniera de software a niveles tan altos como los de las disciplinas antes mencionadas, pero impactarn el estado del arte y sern tiles a la hora de definir el alcance, estimar plazos y costos de un proyecto y negociar las condiciones de su ejecucin [KAV01].

Un modelo formal de estimacin del tiempo y esfuerzo de un proyecto de desarrollo apoya la generacin de condiciones de competencia ms justas y transparentes para los oferentes que realizan ofertas serias tomando en cuenta todos los aspectos del proyecto, especialmente sus riesgos.

En cualquier caso, existen problemas para gestionar los cambios. Sera muy til dis-poner de un modelo que, a partir de la especificacin, calculara un tamao funcional sobre la base de cuyas unidades se pudiera cotizar un proyecto de desarrollo, comparar tamaos funcionales de distintos sistemas de informacin y constituyera un estndar de medida de tamao funcional sobre cuya base clientes y desarrolladores pudieran gestionar los cam-bios aumentando la transparencia, disminuyendo los riesgos para ambas partes y propi-ciando condiciones justas de competencia.

Las fechas establecidas con criterios polticos, de mercadotecnia u otros, sin sus-tento tcnico, constituyen uno de los mayores riesgos para los proyectos de desarrollo de software [BOE89, JON94, MCC98]. Quienes manejan el negocio, tienen sus motivos para solicitar el desarrollo del sistema en cierto tiempo, sin embargo, como construimos ele-mentos intangibles resulta difcil explicar por qu no es posible cumplir estos plazos con una razonable probabilidad de xito.

En otras reas de la ingeniera que desarrollan productos fsicos, estas discusiones son ms fciles o ni siquiera tienen lugar ya que existen modelos y experiencia previa sig-nificativa para el usuario y aceptados por todos, que permiten conducir la discusin sobre bases objetivas.

Disponer de medidas de complejidad y modelos de estimacin del tiempo y esfuerzo de desarrollo independientes del juicio experto y que pueden ser automatizados sirve a va-rios fines:



(1) mostrar que la evaluacin que presentamos no responde a falta de voluntad u otros motivos personales

(2) proporcionar una herramienta para priorizar requisitos, negociar el alcance del proyecto y planificar las versiones a desarrollar sobre bases objetivas

(3) dar transparencia al proceso de estimacin hacindolo repetible y confiable y permitiendo que diferentes expertos arriben a los mismos resultados a partir del mismo es-cenario [KAV01].

Putnam [PUT92, PUT97, PUT03] formaliza la frontera entre lo posible y lo imposi-ble.

Nogueira [NOG00a] proporciona un modelo para calcular la probabilidad de cumplir determinado plazo para sistemas de tiempo real desarrollados a partir de especificaciones formales.

En suma, indicadores y modelos de estimacin basados en mtricas presentes en eta-pas iniciales, tomadas a partir del modelo esencial de datos obtenido desde las visiones de los usuarios finales, independientes del juicio experto y la tecnologa contribuyen a (1) aumentar la formalizacin de la ingeniera de software; (2) independizar mtricas y mode-los del juicio experto; (3) aportar elementos objetivos para hacer ms tangible el software antes de su construccin y (4) apoyar nuevas formas de gestin de proyectos y contratos.

El riesgo de desarrollo de software concit el inters de la industria desde sus inicios, pero no fue estudiado en forma sistemtica y detallada hasta que Boehm [BOE89] propone y sintetiza una metodologa de gestin del riesgo [KON97a]. Su trabajo fue complementa-do por Charette [CHA89, CHA97]. Sobre estas bases descansan aproximaciones al tema de la gestin del riesgo como las de Hefner [HEF94], Karolak [KAR96], Michaels [MIC96], Pandelios [PAN96] y Williams [WIL99], taxonomas y guas para la identificacin de ries-gos [CAR93] y aproximaciones cuantitativas a la gestin del riesgo [FAI94].

La palabra riesgo frecuentemente tiene connotaciones negativas y desencadena una presin cultural para ignorarlos [CAR93].

A diferencia de los procesos de produccin industrial, los procesos de produccin de software generan productos intangibles y requieren comunicacin y coordinacin intensi-vas. Esto contribuye a aumentar los riesgos y dificultar la estimacin.

Las herramientas estndar de planificacin como PERT y CPM no toman en cuenta las comunicaciones y coordinaciones entre los actores ni los trabajos que fracasan y las ac-ciones correctivas necesarias [NOG00a].

El desarrollo de software es un caso particular de proyecto donde [NOG00a]: (a) existe una gran incertidumbre sobre su resultado final, su costo,

sus riesgos, y el esfuerzo y el tiempo que implica su desarrollo (b) el producto final es intangible (desde el punto de vista fsico) (c) su valor real depende no slo de su correccin, sino del momento

en que se pone en servicio, la calidad apreciada por el usuario, su facilidad de uso, mantenimiento y extensin.

Existen, tanto en el proceso de desarrollo de software como en el de estimacin, nu-merosas fuentes de variabilidad que dificultan el desarrollo de modelos de estimacin y contribuyen a su imprecisin especialmente en etapas tempranas del ciclo de vida, que es cuando resultan de mayor utilidad, incluso para decidir continuar o abandonar [BOE81, BOE95, BOE00, NOG00, SAL04a, SAL04b, SAL05, SOM01, MCC96].



A consecuencia de ello, los modelos empricos de estimacin de uso ms extendido actualmente

(a) introdujeron numerosos parmetros que deben ser evaluados mediante juicio experto

(b) toman como entrada medidas de tamao que, en etapas tempranas del ci-clo de vida, slo pueden ser estimadas inexactamente como LOC o FP.

Estos modelos parecen funcionar mucho mejor en manos de sus creadores, de ex-pertos altamente entrenados en su uso y/o de quienes disponen de bases de datos con in-formacin histrica para calibrarlos [PUT97, PUT03].

El esfuerzo y tiempo guardan relaciones exponenciales con la mayora de las varia-bles independientes [BOE81, BOE95a, BOE00b, PUT97, PUT03]. De esta forma, el efecto conjunto de diferencias poco importantes en la estimacin de los valores de mltiples pa-rmetros, hace posible que, observando un mismo escenario, distintos evaluadores obten-gan estimaciones significativamente diferentes.

Esto contribuye a explicar que, a pesar de la existencia de modelos de estimacin como COCOMO [BOE81], COCOMO II [BOE95a, BOE00b] y su variante en desarrollo COSYSMO [VAL03] y SLIM [PUT97], entre muchos otros, frecuentemente los presu-puestos y los tiempos de desarrollo son subestimados [BOE81, BOE88a, BOE00b, PUT97, PUT03, MCC96]. La percepcin del xito o fracaso de la ejecucin de un proyecto surge de la diferencia entre lo originalmente planificado y lo que en los hechos sucedi. As, hay proyectos que nacen destinados a ser percibidos como fracasos. Esto contribuye a explicar la crisis del software caracterizada por frecuentes incumplimientos de los plazos y costos planificados.

A pesar de largos aos de investigacin y desarrollo, el problema de la estimacin formal y estructurada (independiente del juicio experto) del tiempo y esfuerzo requeridos para desarrollar un SI permanece abierto. Las tcnicas de estimacin ms extendidas ac-tualmente se apoyan en la premisa - poco realista - de estabilidad de requisitos y el entorno de desarrollo del proyecto y requieren expertos humanos.

Los gerentes deben tomar decisiones tempranas bajo alta incertidumbre, o mitigarla pagando con tiempo y encareciendo el proyecto [BOE89, NOG00a].

Esta situacin se hace ms crtica con el advenimiento de la hipercompetencia donde el valor de un producto depende ms del momento de su puesta en produccin que de su calidad. En estos casos, suele no haber opciones. Las decisiones deben ser tempranas.

En el momento en que habitualmente se solicita a los desarrolladores que estimen tiempo y esfuerzo, estos conocen tan poco sobre el proyecto que puede suceder que las es-timaciones pesimistas sean 16 veces mayores que las optimistas [BOE81, BOE89, MCC96, LUM03]. Esta situacin es mencionada por algunos autores como el cono de incertidumbre [BOE81, BOE89, SOM01].

Debido, entre otras causas, a (1) el enfoque no estructurado de los modelos y tcnicas de estimacin de riesgo, tiempo y esfuerzo de desarrollo, (2) las numerosas e importantes fuentes de variabilidad en el proceso de desarrollo de software, (3) que se trata de un pro-ceso intensivo en interaccin humana y trabajo intelectual, (4) que la estimacin se basa en juicio experto y (5) que en las etapas iniciales del ciclo de vida es cuando usuarios y des-arrolladores conocen menos del sistema a desarrollar y a la vez el momento en que la esti-macin es ms necesaria, incluso para tomar la decisin de seguir o abandonar; se realizan estimaciones tempranas y se comenten errores muy importantes.



I.B OBJETIVOS DEL TRABAJO

Este trabajo de tesis doctoral tiene dos objetivos centrales: (O1) desarrollar y validar indicadores de complejidad esencial y modelos

formales (automatizables) de estimacin temprana del tiempo y es-fuerzo de proyectos de desarrollo de sistemas de informacin, basados en bases de datos relacionales, con procesos evolutivos y giles y ge-neracin automtica de cdigo a partir de especificaciones formales. Estos modelos emplearn como parmetros de entrada la eficiencia del grupo de desarrollo, la volatilidad de los requisitos, la complejidad del sistema a desarrollar y la velocidad inicial de ejecucin del pro-yecto. La complejidad ser medida con independencia de la tecno-loga a partir de las vistas de datos de los usuarios finales del sis-tema a desarrollar. Los modelos buscados debern: (a) ser aplicables continua y muy tempranamente desde la etapa de ingeniera de requi-sitos y (b) no desconocer los inevitables cambios en los requisitos, si-no asumirlos y apoyar su gestin.

(O2) analizar las posibilidades de generalizacin de los resultados anterio-res a sistemas de informacin desarrollados en torno a bases de datos relacionales pero usando otras herramientas.

Para alcanzarlos se definieron los subobjetivos que se presentan en el apartado si-guiente.

I.B.1 SUBOJETIVOS

(SO1) Identificar mtricas e indicadores obtenibles automticamente, a partir de la especificacin de un sistema de informacin, que contribuyen a definir su complejidad esencial cognitiva e intelectual medida con independencia de la tecnologa.

(SO2) Estudiar la forma en que estos indicadores van apareciendo a lo largo del ciclo de vida de un proyecto de desarrollo de software y, especialmente, cu-les se encuentran disponibles en etapas muy tempranas del mismo.

(SO3) Desarrollar modelos empricos, estticos y globales que, tomando como variables independientes indicadores de la complejidad del sistema a desarro-llar, la volatilidad de los requisitos, la eficiencia del grupo de desarrollo, y la velocidad inicial de ejecucin del proyecto permitan estimar las variables de-pendientes esfuerzo y tiempo necesarios para su desarrollo.

(SO4) Sobre la base de estos modelos estudiar la existencia de una complejidad esencial deducible a partir de la estructura de los datos [DEM82].

(SO5) Definir un indicador de complejidad esencial de un sistema de informa-cin funcin de estas mtricas tempranas.

(SO6) Validar empricamente estos modelos. (SO7) Estudiar las posibilidades de generalizacin de los resultados anteriores al

mbito de sistemas de informacin desarrollados en torno a bases de datos re-lacionales pero aplicando otras metodologas y herramientas



(SO8) Sentar las bases para comenzar la formacin de una base de datos de m-tricas de proyectos que posibilite la definicin de modelos ms precisos y que contemplen distintos niveles de eficiencia.

I.C APORTACIONES REALIZADAS POR ESTA TESIS

La persecucin de los objetivos y subojetivos antes referidos redund en las siguien-tes aportaciones:

I.C.1 TERICAS

(AT1) Indicadores de complejidad esencial de la estructura de datos calculables temprana y automticamente a partir de las vistas de datos de los usuarios finales del sistema.

Impacta el estado del arte de las mtricas para sistemas de informacin intensivos en proceso de datos desarrollados en torno a bases de datos relacionales.

(AT2) Modelos empricos, estticos y globales de estimacin muy temprana del tiempo y esfuerzo de un proyecto de desarrollo de software de gestin que no re-quieren juicio experto y pueden ser automatizados.

Impacta el estado del arte de (1) los modelos empricos estticos y globales de es-timacin para sistemas de informacin intensivos en proceso de datos desarrollados en tor-no a bases de datos relacionales, (2) las metodologas de gestin de los procesos de desa-rrollo de estos sistemas, especialmente la planificacin, gestin de cambios y negociacin de tiempos y costos, introduciendo nuevas posibilidades de gestin de contratos que dismi-nuyen el espacio semntico entre clientes y desarrolladores y los riesgos para ambas partes y el proyecto en general.

Este impacto es extensible a sistemas no desarrollados con la herramienta y metodo-loga con que se desarrollaron los proyectos observados ya que se desarroll y public una herramienta que permite medir la complejidad de cualquier conjunto de vistas de datos de usuarios (ver (AP2)) y luego este indicador puede ser vinculado con la experiencia previa de la organizacin, haciendo posible el desarrollo de modelos propios.

(AT3) Generalizacin del indicador de complejidad esencial. Esta es posible a partir de las aportaciones (AP1) a (AP5)

I.C.2 PRCTICAS

(AP1) Recopilacin y publicacin de datos de 20 proyectos (AP2) Herramienta de recoleccin automtica de mtricas a partir de especificacio-

nes formales (AP3) Herramienta de generacin automtica del indicador de complejidad de la es-

tructura de los datos a partir de las vistas de usuario o el esquema de bases de da-tos relacionales

(AP4) Ambiente de Desarrollo integrado a la herramienta de especificacin formal que permite tomar automticamente las mtricas del PSP [HUM95, HUM97].

(AP5) Las aportaciones (AP1) a (AP3) posibilitan comenzar a formar una base de datos de proyectos que permita aumentar la precisin y calidad de los modelos.



(AP6) Disponer de indicadores formales de complejidad esencial de sistemas de in-formacin.

(AP7) Disponer de modelos de estimacin formales de tiempo y esfuerzo de desa-rrollo de sistemas de informacin.

I.D ORGANIZACIN DEL TRABAJO

En el Captulo II se discute el estado de la cuestin, en el captulo III se plantea el problema a resolver, en el captulo IV se desarrolla la solucin y se presentan los axiomas, supuestos y definiciones en que se basa el trabajo, el alcance de la investigacin y mbito de aplicacin de sus resultados, el modelo conceptual de la investigacin y la metodologa aplicada. En el Captulo V se desarrolla el modelo conceptual de la investigacin, discu-tiendo las caractersticas de la herramienta de especificacin formal usada para desarrollar los proyectos observados, los modelos matemticos en que se basa la herramienta de espe-cificacin y su metodologa asociada, los modelos que deseamos construir y nuestras hip-tesis de trabajo. En el captulo VI se define el soporte experimental de la investigacin, las decisiones tomadas para llevar adelante la recopilacin de datos y se presentan los datos recogidos. En el Captulo VII se desarrollan los modelos de estimacin temprana de tiempo y esfuerzo y definen los indicadores de complejidad esencial de sistemas de informacin. En el captulo VIII se desarrollan los modelos de estimacin post mortem de tiempo y es-fuerzo. En el Captulo IX se evala la precisin y consistencia de estos modelos. En el Ca-ptulo X se realiza una validacin emprica de los indicadores de complejidad y los mode-los de estimacin. Finalmente, en el Captulo XI se ofrecen conclusiones, se discute el m-bito de aplicacin de los resultados obtenidos, las posibilidades de generalizacin y se pro-ponen lneas de trabajo futuras. En el Anexo I se explica la seleccin de la herramienta de especificacin formal usada para realizar el trabajo. En el ANEXO II se presenta la fre-cuencia de las variables observadas. En el ANEXO III se encuentran tablas y grficos utili-zados para el estudio de los modelos de estimacin temprana de tiempo y esfuerzo y en el ANEXO IV los correspondientes a los modelos de estimacin temprana de tiempo y es-fuerzo. En el ANEXO V se encuentran las tablas y grficos correspondientes a la evalua-cin de los modelos de estimacin. Finalmente en el ANEXO VI se incluye una breve des-cripcin de las herramientas de obtencin automtica de mtricas desarrolladas para apoyar esta investigacin y la continuacin de la misma generalizando los resultados obtenidos para sistemas de informacin desarrollados a partir de especificaciones formales al de los desarrollados en torno a bases de datos relacionales.

Por razones de espacio, los anexos no se imprimieron. En el CD que acompaa la parte impresa de la tesis se encuentra una versin completa incluyendo los anexos, las herramientas desarrolladas y las publicaciones realizadas durante la investigacin.

PARTE 1 ESTADO DE LA CUESTIN

MODELOS AUTOMATIZABLES DE ESTIMACIN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIN



MODELOS AUTOMATIZABLES DE ESTIMACIN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIN

Pgina dejada intencionalmente en blanco

II ESTADO DE LA CUESTIN

MODELOS AUTOMATIZABLES DE ESTIMACIN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIN II1




II.A INTRODUCCIN

Esta investigacin, toca temas sobre los que se han realizado muchos trabajos, tanto vinculados con la informtica como anteriores a su existencia. Desde siempre, el hombre tuvo necesidad de estimar el valor de variables cuyas relaciones desconoca o para las cua-les no dispona todava de modelos formales que permitieran estimarlas. En este captulo se presenta una apretada sntesis del estado de la cuestin en:

(a) estimacin y gestin del riesgo incluyendo el enfoque tradicional, una visin holstica que considera tanto las amenazas como las oportunidades, enfoques probabilistas y el estado de la prctica

(b) mtricas de software haciendo una breve introduccin de la teora de medicin y sus conceptos bsicos, presentando un enfoque de alta formalizacin debido a Zuse [ZUS91] y otro ms adecuado a la madurez actual de la ingeniera de software debido a Briand [BRI95a, BRI95b ]

(c) estimacin de tiempo y esfuerzo de desarrollo de software discu-tiendo su factibilidad, especialmente en etapas muy tempranas del ciclo de vida y su relacin con la crisis del software.

(d) modelos matemticos de los datos en que se incluyen los modelos de Codd y Warnier-Orr

(e) procesos de desarrollo donde se comentan los procesos conducidos por la planificacin y documentacin intensivas y los procesos gi-les

(f) finalmente se incluyen conclusiones.

II.B ESTIMACIN Y GESTIN DEL RIESGO EN INGENIERA DE SOFTWARE

Segn Kaplan y Garrick [KAP81] el riesgo queda definido por un conjunto de triple-tas (fuente, probabilidad, consecuencia).

Este es un enfoque informal ya que la probabilidad se evala subjetivamente y res-ponde al grado de creencia del evaluador respecto de la posibilidad de que el evento ocurra [KON97a] y no realmente a una distribucin de probabilidad.

La estimacin de la probabilidad resulta muy difcil ya que, en general, se dispone de poca informacin histrica y la estimacin de las probabilidades de los eventos es muy ar-dua en un ambiente sujeto a cambios constantes como el desarrollo de software [KON97b, JOR00b]. Podra utilizarse una estimacin del riesgo basada en la frecuencia de ocurren-cias anteriores del mismo, pero, en ingeniera de software (1) rara vez se dispone de infor-macin estadstica de calidad y volumen suficientes para tener significacin estadstica y (2) el mercado, la tecnologa y las metodologas cambian rpidamente y la informacin del pasado tiene una significacin relativa. Por esto, los grados de creencia (probabilidades subjetivas) [KON97b] son frecuentemente usados.

Lo mismo puede decirse de la estimacin de las prdidas sufridas con la complica-cin adicional de que aqu pueden verse afectados mltiples reas del negocio y usuarios con diferentes puntos de vista.



Los mtodos de la gestin de riesgo introducidos en los aos 90 eran listas de comprobacin simples, tablas de calificacin, y, a veces, herramientas complejas de clculo. Estas tcnicas simples - muchas de ellas presentadas en libros de texto y seminarios de la industria - fueron basadas en teoras falsas, suposiciones poco realistas, y matemticas falsas. [KON01] El clculo modela datos subjetivos usados para efectuar clculos de riesgos con ocho dgitos de precisin. Los practicantes de la industria pudieron no haber en-tendido explcitamente las bases inestables en las cuales se sustentan estos mto-dos, pero, intuitivamente, concluyeron que dedicar tiempo a la gestin de riesgo no es rentable.[KON02] Es necesario considerar mtodos que tomen en cuenta no slo las amenazas sino las

oportunidades [NOG00, KON02, BOE02]. Las tcnicas mas comnmente usadas para la evaluacin, reduccin y supervisin del

riesgo constituyen aproximaciones no estructuradas, ya que se basan en listas de verifica-cin y prcticas recomendadas y necesitan de expertos humanos para su aplicacin. Esto presenta tres problemas (1) puede suceder que, aplicando su juicio experto y sobre la base de su experiencia, distintos evaluadores arriben a conclusiones diferentes [NOG00, DAV01, CHA03, MOL03b, MOL04a, MOL04c, MOL04d; JOR00a, JOR00b, JOR00c, JOR04f, JOR05b] (2) los expertos son un recurso escaso y su falta puede atrasar las tareas de evaluacin [IDR03, JOR03] y (3) estos expertos pueden representar un costo que no puede ser absorbido por pequeos grupos de trabajo propios de metodologas giles y/o proyectos de pequea escala frecuentes en economas reducidas como la de Uruguay [LAT03].

El conocimiento de que disponemos para la gestin del riesgo es el resultado de las contribuciones de numerosos autores y organizaciones.

Merecen una mencin especial las contribuciones significativas realizadas por Barry Boehm a lo largo de ms de 10 aos de dedicacin al tema, tanto por su profundidad como por la amplitud de las reas cubiertas. En su tutorial [BOE89] - que marca un antes y un despus en la gestin del riesgo en la ingeniera de software - se basa buena parte de este apartado. Las contribuciones de Lawrence Putnam [PUT76, PUT78, PUT80, PUT92, PUT96, PUT97, PUT03] a la identificacin del riesgo con un enfoque estadstico, estable-ciendo la zona temporal imposible y la zona dentro de la cual el uso de los recursos se de-grada y la germinal - aunque no tan extensa - contribucin de Juan Carlos Nogueira [NOG00] a la investigacin de la estimacin formal y estructurada del riesgo de los pro-yectos de desarrollo de software de tiempo real, que abri una prometedora lnea de inves-tigacin.

II.B.1 EL ENFOQUE TRADICIONAL DE RIESGO

El Diccionario de la Real Academia Espaola lo define como (1) contingencia o proximidad de un dao, (2) someterse a influjo de suerte o evento, sin poder reclamar por la accin de estos. El diccionario Webster como la posibilidad de prdida, dao o perjuicio. Distinguimos los riesgos de otros eventos que pueden ocurrir durante el desarrollo de un proyecto [ROO93] porque (1) hay una consecuencia negativa asociada con el evento, (2) existe una probabilidad de que el evento ocurra (no hay certeza de ello) y (3) podemos eva-luar el grado en que podemos cambiar el resultado.

Un proyecto de desarrollo de software involucra diversos actores (desarrolladores, usuarios, clientes y encargados del mantenimiento). As el concepto de resultado no desea-do es multidimensional [BOE91].

Clientes y desarrolladores quedarn insatisfechos cuando no puedan cumplirse los plazos y presupuestos, los usuarios cuando el producto no tiene la facilidad de uso, funcio-



nalidad, interfaz de usuario, requisitos no funcionales y confiabilidad requeridos y los en-cargados de mantenimiento cuando los niveles de calidad del software no son los adecua-dos.

II.B.2 UNA VISIN HOLSTICA: OPORTUNIDADES, AMENAZAS, RIESGOS

La aproximacin anterior es una consecuencia natural de la crisis del software y el nfasis en la gestin sistemtica y activa de las amenazas a los proyectos. En este enfoque se usa la palabra riesgo para referir tanto a riesgos como a amenazas.

El enfoque de esta tesis es que el riesgo da lugar tanto a amenazas como oportunida-des [NOG00, BOE02, KON02].

A consecuencia de la hipercompetencia, entre las mayores amenazas se encuentra la prdida de oportunidades y nichos de mercado por un excesivo nfasis en la calidad del producto que desatiende el momento de puesta en el mercado [CUS97, CUS99, NOG00, BOE04].

II.B.2.1 RIESGO VS. OPORTUNIDAD

El Riesgo y la Oportunidad van de la mano. No se puede alcanzar el xito sin algn grado de riesgo. El riesgo en si mismo no es malo; es esencial para el pro-greso, y la falla frecuentemente es una parte central del aprendizaje. Pero debemos aprender a equilibrar las posibles consecuencias negativas del riesgo contra los posibles beneficios de sus oportunidades asociadas.[VAN92] El proceso de toma de decisiones puede desarrollarse bajo tres modalidades: (1) quien decide conoce exactamente todas las alternativas, sus consecuencias y las

posibilidades de que ocurra cada una de ellas, la decisin es tomada bajo certeza y el pro-ceso de decisin consiste simplemente en seleccionar la alternativa con el mejor resultado. Desgraciadamente, esta situacin rara vez se da.

(2) no se dispone de un conocimiento total del futuro, pero se conoce la distribucin de la probabilidad de ocurrencia de los distintos estados de la naturaleza y sus consecuen-cias, la decisin se toma sujeta a riesgo y existen diversas tcnicas para apoyarla.

(3) no se dispone de informacin precisa sobre la distribucin de probabilidad de los distintos estados de la naturaleza, la decisin se toma bajo incertidumbre existiendo diver-sos mtodos para apoyarla (maximin, minimax, Laplace, etc.).

En esta tesis entendemos que se est tomando decisiones bajo riesgo nicamente cuando se conoce la distribucin de probabilidad de los distintos estados de la naturaleza. En este caso, la exposicin al riesgo (ERi, Ecuacin II-1) se calcula como el producto de la probabilidad de que ocurra un evento por el resultado esperado de su ocurrencia [BOE89]. Este resultado puede ser positivo (oportunidad) o negativo (amenaza) [NOG00, BOE02].

Ecuacin II-1

La exposicin total al riesgo es la suma de las exposiciones al riesgo resultantes de cada evento.

Ecuacin II-2

II.B.3 PRCTICAS RECOMENDADAS, GUAS Y LISTAS DE VERIFICACIN

Tradicionalmente, la evaluacin y mitigacin del riesgo se ha basado en prcticas re-comendadas y listas de verificacin.

ER P(Evento )ResultadoEsperado(Evento )i i i=

n

ii 1

TER ER=

=



Boehm [BOE89] propone una metodologa de evaluacin y gestin del riesgo, que a pesar de constituir un abordaje sistemtico y robusto, se apoya en heursticas, listas de veri-ficacin, juicio experto y evaluacin subjetiva de probabilidades.

Estas tcnicas tienen en comn la debilidad de depender del juicio experto. No cons-tituyen un abordaje estructurado del problema y no son adecuadas para ser automatizadas integralmente, an cuando pueden desarrollarse herramientas que apoyan el proceso ac-tuando como ayuda memoria y facilitando los clculos y la generacin de informes.

De todos modos, han sido una valiosa ayuda para la gestin del riesgo de los proyec-tos de desarrollo de software, como lo evidencia el hecho de que, si bien los ndices de proyectos que sobrepasan los costos y tiempos previstos y/o son cancelados no son alenta-dores han bajado con el tiempo [STA94, STA98, STA04].

El Software Engineering Institute de la Universidad de Carnegie Mellon [SEI96] propone un marco de trabajo compuesto por (1) siete principios de gestin del riesgo, (2) un proceso de gestin continua del riesgo (CRM, Continuous Risk Management) [DOR96], (3) una metodologa de evaluacin de riesgo (SRE, Software Risk Evaluation) [WIL99], (4) una metodologa de gestin del riesgo a nivel de los equipos de desarrollo (TRM, Team Risk Management) [HIG94] y (5) una taxonoma de riesgos que se formaliza en un cuestionario para asegurar que no quedan riesgos sin considerar [CAR93]. Este en-foque considera los aspectos temporales, metodolgicos y humanos.

Si bien estudia sistemticamente muchos aspectos relacionados con el riesgo, la aproximacin a la gestin del riesgo del SEI presenta debilidades como:

(a) tratamiento informal del riesgo ya que se define la severidad del riesgo de acuerdo a estimaciones subjetivas tanto de la probabilidad de que el riesgo se presente como de la magnitud de la prdida (ver USAF ms adelante)

(b) la taxonoma de riesgos que se usa es exhaustiva y ha probado ser valiosa, pero tiene aspectos cuya evaluacin es subjetiva.

(c) las guas y prcticas recomendadas son principalmente heursticas. En suma, se requieren expertos humanos para aplicar esta metodologa y se trabaja

bajo incertidumbre ms que bajo riesgo. Jones destaca que el riesgo es dependiente del dominio de software en que nos en-

contremos y, desde el punto de vista de la prevencin, clasifica los riesgos segn sean o no resistentes al control.

Entre los que no son resistentes al control menciona el aumento de los requisitos de usuario, la excesiva presin en el cronograma, la baja calidad, los sobrecostes y el control de configuracin inadecuado. Como resistentes al control considera el papeleo excesivo, la documentacin de usuario inadecuada, la baja satisfaccin de los usuarios, los costos de litigio y la friccin entre el personal del cliente y el del contratista [JON94].

Entre los riesgos ms importantes para Boehm [BOE89, BOE98] se encuentran la planificacin temporal y presupuestos poco realistas. Para Jones [JON94] los riesgos ms significativos son la medicin inadecuada y la excesiva presin en la planificacin. Esto destaca la importancia fundamental de la estimacin temprana de tiempo y esfuerzo.

II.B.4 CONCLUSIONES SOBRE EL ENFOQUE TRADICIONAL DE GESTIN DE RIESGO

Se basa en guas, listas de verificacin, cuestionarios, factores de riesgo, procesos de gestin de riesgos y metodologas.



Todas ellas tienen debilidades comunes:

se apoyan en expertos humanos

no son repetibles

estiman subjetivamente probabilidades e impactos esperados de los riesgos

manejan informalmente el trmino riesgo

II.B.5 ENFOQUES PROBABILISTAS DE ESTIMACIN DEL RIESGO

La evaluacin probabilista del riesgo, es de amplia aplicacin en disciplinas ms ma-duras que la ingeniera del software como la industria aeroespacial y la ingeniera nuclear.

Karolak [KAR96] es el primer autor que trata estructuradamente el riesgo en el mbi-to del desarrollo de sistemas de informacin, aunque se apoya en expertos y realiza estima-ciones subjetivas. Dale Karolak utiliza una aproximacin bayesiana apoyada en probabili-dades subjetivas. Considera tres dimensiones de riesgo: tcnica, costo, cronograma y un cuarto elemento de riesgo constituido por las actividades de gestin de riesgo.

El principal mrito de esta aproximacin es que puede apoyarse en herramientas au-tomticas. De hecho el autor cre una. Sin embargo, a pesar de que la tarea puede ser apo-yada por herramientas automticas, no puede automatizarse la estimacin de las probabili-dades subjetivas. Esta metodologa requiere expertos humanos, y, en el fondo, no es ms estructurada que las anteriores y tampoco es repetible. Su valor radica en ser la primera aproximacin con un enfoque que tiende a la estructuracin.

II.B.5.1 EVALUACIN PROBABILISTA DEL RIESGO

La evaluacin probabilista del riesgo (Probabilistic Risk Assessment, PRA) es un mtodo aplicado en la NASA [NAS02, GRE01] para la gestin del riesgo de sus proyectos aeroespaciales que est dirigido a cuantificar la exposicin al riesgo causada por eventos de muy baja probabilidad y consecuencias importantes. Es una aproximacin bayesiana que trata de cuantificar los efectos de las acciones de mitigacin de riesgos y su costo be-neficio.

La metodologa propone los siguientes pasos: (1) Identificacin de estados finales de inters (relativo al PRA) (2) Familiarizacin con el sistema tal como es y recoleccin de in-

formacin (3) Identificacin de eventos iniciales (IE) (4) Definicin y modelado de escenarios vinculando los eventos

iniciales con sus eventos finales (EF) mediante eventos pivote (EP)

(5) Modelado de eventos pivote mediante rboles de fallas (6) Cuantificacin del riesgo (7) Anlisis de incertidumbre (8) Clasificacin de riesgos segn importancia

Esta aproximacin es interesante, pero poco adecuada al grado de madurez actual de la ingeniera de software, que se encuentra en sus etapas iniciales. No disponemos de in-formacin probabilstica detallada sobre los eventos que pueden presentarse en los comple-jos procesos sociales que involucra el desarrollo de software, que ni siquiera comprende-mos todava muy bien. Hemos presentado aqu esta aproximacin porque pensamos que es



hacia donde debemos ir, pero, previamente, debemos alcanzar un mayor grado de formali-zacin.

Nogueira [NOG00] trata de forma estructurada y repetible la estimacin del riesgo en el mbito de desarrollo de sistemas de tiempo real. Define un modelo formal de estimacin de riesgo para sistemas de tiempo real desarrollados en un ambiente grfico en que los sis-temas son representados mediante un grafo. Los vrtices representan operadores y los ar-cos flujos de datos entre ellos. Este mtodo fue calibrado mediante simulacin de proyec-tos de desarrollo de software de tiempo real y contrastado contra una pequea muestra de proyectos reales de similares caractersticas.

El modelo permite calcular la probabilidad P de terminar el proyecto en un tiempo menor o igual a un valor dado k en funcin de la eficiencia de la organizacin (EF), la complejidad del sistema a desarrollar (CX) y la volatilidad de los requisitos (VR).

Ecuacin II-3

Este modelo es el nico que conocemos que permite realizar una estimacin del ries-go estructurada, repetible e independiente del juicio experto.

En el corto plazo la eficiencia de la organizacin es constante y la volatilidad de los requisitos evoluciona a lo largo del ciclo de vida e incluso puede usarse como un indicador de la marcha del proyecto [NOG00]. Los elementos sobre los cuales se puede negociar son la complejidad y el tiempo.

Este modelo es til tanto para determinar la probabilidad de terminar en un tiempo determinado, bajo ciertas condiciones, como para determinar el tiempo necesario para al-canzar una probabilidad dada de cumplir con l.

En el apartado de mtricas discutiremos la forma de medir la eficiencia y la comple-jidad propuestas por Nogueira.

Nogueira propone 4 modelos aplicables bajo distintas circunstancias. Estos modelos sern presentados en el apartado de estimacin.

II.B.6 ESTADO DE LA PRCTICA

Las metodologas de gestin del riesgo han avanzado enormemente desde los tiem-pos iniciales. Sin embargo (1) no esta ampliamente extendido su uso especialmente a pro-yectos medianos y chicos; (2) no hay una cultura generalizada de riesgo; (3) si la hubiera no dispondramos de los expertos necesarios; (4) estas metodologas no generan elementos significativos para los usuarios finales que permitan integrarlos activamente al proceso; (5) para proyectos medianos y chicos los costos pueden ser muy grandes; (6) se apoyan en jui-cio experto, prcticas recomendadas y heursticas y, excepcionalmente, algunas mtricas cuya significacin no queda muy clara debido a que no estn bien definidos los estndares bajo los que se tomaron, se adquieren manualmente y con categorizaciones subjetivas, se usan para evaluar el personal o corresponden a metodologas y/o tecnologas obsoletas o diferentes a las actualmente en uso; (7) por tratarse de un proceso no estructurado diferen-tes expertos pueden arribar a conclusiones significativamente diferentes partiendo del mismo escenario [NOG00, DAV01, CHA03, MOL03b, MOL04a, MOL04c, MOL04d, JOR00a, JOR00b, JOR00c, JOR04f, JOR05b].

En Uruguay no se encuentra extendido el uso de metodologas. Latorres, Salvetto et al [LAT03] informan que un 50% de las organizaciones de desarrollo de software - en Uruguay - dispone de personal destinado al aseguramiento de la calidad, pero slo el 26% indica la cantidad de personal asignado para esa tarea. Slo el 4% usa un proceso definido para el desarrollo de software. El 20% cuenta con alguna certificacin en calidad en la em-presa pero solo el 4% cuenta con certificaciones especficas del proceso de desarrollo de

( ) ( , , , )CX kP t k f EF VR =



software y el 24% de los profesionales no tiene formacin en modelos de procesos de desa-rrollo. Esto se debe a que las empresas han preferido invertir en la capacitacin en herra-mientas tecnolgicas y no en modelos de gestin.

II.B.7 CONCLUSIONES SOBRE GESTIN DEL RIESGO

Si bien el avance ha sido importante, (1) hemos estado usando tcnicas inadecuadas, (2) la gestin del riesgo ha sido muy burocrtica, (3) con la intencin de simplificar su aprendizaje y aplicacin, las tcnicas que usamos son demasiado estndar y no toman en cuenta las peculiares caractersticas individuales de los riesgos de cada proyecto, (4) la ges-tin no siempre es transparente y comprensible para el usuario y genera desconfianza y (5) la academia ha sido demasiado terica y los consultores, por el contrario, han aplicado sis-temticamente las tcnicas sin cuestionarlas [KON02].

El software est jugando un rol cada vez ms importante en los negocios. Para ser exitosas en un ambiente hipercompetitivo, las empresas de software deben tomar riesgos. Para acompaar este movimiento es necesario profundizar las investigaciones en busca de mtodos que tomen en cuenta tanto riesgos como oportunidades [NOG00, BOE02, KON02] y sustituir mtodos susceptibles de ser influenciados por los participantes por otros mejores, ms econmicos y sencillos [NOG00, KON02]. Los mtodos de gestin del riesgo deben enfatizar la comunicacin y la comprensibilidad de sus resultados [NOG00, KON02]. Los investigadores deben producir resultados ms prcticos y los consultores ac-tualizar sus conocimientos [KON02].

El software se ha introducido en prcticamente toda actividad humana y debe dar r-pida respuesta a los cambios solicitados a ritmo cada vez ms intenso por la sociedad. Ello plantea la necesidad de gestionar tanto proyectos de gran tamao y riesgo, como pequeos proyectos con un ciclo de vida corto. No se dispone de los expertos [IDR03] que - con las prcticas tradicionales - seran necesarios para gestionar todos estos proyectos - y, espe-cialmente en los proyectos pequeos (que conjuntamente representan una importante por-cin del mercado), los tiempos no son suficientes para embarcarse en un largo proceso de evaluacin de riesgo y factibilidad. Posiblemente los terminamos antes de concluir su pla-nificacin con las estrategias tradicionales.

Muchos viejos mtodos merecen ser abandonados y sustituidos por nuevos, ms ade-cuados a las prcticas actuales y ms rentables [KON02].

La gestin del riesgo debe apoyarse cada vez ms en modelos formales. La IS no po-see el grado de formalizacin necesario para un enfoque probabilista extensivo del riesgo como la fsica o la ingeniera aeroespacial, sin embargo algunos aspectos pueden ser abor-dados ms formalmente sin recurrir al juicio experto. Esto ya fue logrado para sistemas de tiempo real por Nogueira [NOG00] estimando la probabilidad de desarrollar un sistema en un tiempo dado sin recurrir al juicio experto.

II.C MTRICAS DE SOFTWARE

Tradicionalmente las mtricas de software han sido usadas con dos objetivos centra-les [ZUS91]:

(1) estimacin de costo y recursos (2) estimacin y control de la calidad. Nuestro inters se focaliza en el primer punto, especficamente en la estimacin de

tiempo y esfuerzo. El segundo se encuentra fuera del alcance de este trabajo. Se trata de un tema extenso en el que ha habido una intensa actividad de investiga-

cin desde el comienzo de la ingeniera de software hasta nuestros das. Sin embargo, no se



ha alcanzado consenso en relacin a conceptos bsicos como formas tiles, tempranas, re-petibles e independientes del juicio experto, de medir la complejidad por ejemplo.

Esta falta de acuerdo contribuye a explicar la publicacin de ms de 1600 artculos y 50 libros sobre el tema casi tanto como sobre el resto de los temas de la ingeniera de software [ZUSb].

Nos restringiremos a considerar los aspectos que se relacionan ms directamente con nuestra investigacin. Estos son teora de medicin, medicin de tamao, complejidad, eficiencia, volatilidad de requisitos, tiempo y esfuerzo.

Nos interesamos especialmente por los aspectos de la teora de medicin que se rela-cionan con la prctica y el diseo de investigaciones y experimentos a la luz del estado ac-tual de madurez de la ingeniera de software.

II.C.1 TEORA DE MEDICIN

La medicin es el proceso por el cul se asignan nmeros o smbolos a atributos de entidades en el mundo real de forma de describirlos de acuerdo a reglas definidas [FEN97].

La medicin es un elemento central de nuestra capacidad de entender y extraer con-clusiones sobre los fenmenos del mundo real. Sin embargo, no debemos olvidar que con-ceptos fcilmente mensurables hoy por cualquier persona como el tiempo, la temperatura y la velocidad en algn momento de la historia no lo fueron. La ingeniera del software se encuentra en su infancia y debemos resistir la tentacin de un enfoque formal como el de las ciencias fsicas que se encuentran en un nivel de formalizacin mucho mayor, esto pue-de ser un objetivo de largo plazo si es que alguna vez se alcanza [BRI95b].

Parafraseando a Tukey, la "ciencia no es matemticas" y no estamos buscando la perfeccin y pruebas absolutas; slo la evidencia de que nuestras teoras se acercan a la realidad tanto como sea posible. La otra alternativa, es decir, rechazar las teoras aproximadas, tendra consecuencias catastrficas en la mayora de las ciencias, y en particular, en la ingeniera de software. Lo que no es aceptable desde una perspectiva matemtica estricta puede ser evidencia aceptable e incluso nece-saria desde una perspectiva de ingeniera o experimental. [BRI95b] Los sistemas fsicos cumplen modelos que descansan sobre bases matemticas bien

establecidas y entendidas. Estos modelos pueden ser utilizados para predecir el comporta-miento del sistema y las mediciones pueden ser usadas para compararlos y entenderlos so-bre la base de conceptos universalmente aceptados.

No ocurre lo mismo con el software que no est restringido por leyes fsicas y que es el resultado de actividades e interacciones humanas.

Uno de los mayores problemas de la medicin en ingeniera de software es el escep-ticismo respecto del uso de valores numricos debido a que no se tiene una interpretacin satisfactoria de ellos y hace falta una semntica para estos valores. La simple asignacin de nmeros a hiptesis sin conocimiento de la evidencia emprica de estos nmeros es un error [ZUSa]. Pero que significado tienen los nmeros? Realmente ninguno. Se necesitan criterios relativos a las propiedades de los nmeros.

Seguidamente se presentan (II.C.1.1) definiciones y propiedades bsicas de las m-tricas segn Briand, Khaled, Morasca et al [BRI95b], (II.C.1.2) un comentario sobre un enfoque ms formal debido a Zuse [ZUS91] y (II.C.1.3) La Teora de Medicin y su Apli-cacin a la Ingeniera de Software Emprica

II.C.1.1 CONCEPTOS BSICOS

Para las escalas reales estn definidas las transformaciones admisibles en la forma que detalla la Tabla II-1.



Escala Transformaciones

Admisibles Nominal Es una clasificacin de los objetos las nicas trans-

formaciones posibles son aquellas que preservan el hecho de que los objetos son diferentes, esto es co-rrespondencias uno a uno

Cualquier g de uno a uno

Ordinal Es un ordenamiento de los objetos de acuerdo a algn criterio de ordenacin

G una funcin es-trictamente cre-

ciente Intervalo Las diferencias entre valores son significativas, pero

no los valores de la medida en si mismos. Por ejem-plo la temperatura medida en diferentes escalas

g(x)=ax+b

Relacin, proporcin

Existe un valor cero y los cocientes entre valores son significativos

g(x)=ax

Absoluta Las transformaciones no son significativas. Ejemplo conteo de objetos.

g(x)=x

Tabla II-1 Escalas y Transformaciones Admisibles

Las escalas anteriores, que de alguna forma representan niveles de medida estn or-denadas en orden creciente de potencia, en particular las escalas ms potentes (intervalo, proporcin y absoluta) proporcionan mayor informacin y resultan ms tiles.

Las afirmaciones pueden ser especficas de una escala o libres de escala. Por ejemplo el peso del objeto a es el doble que el b. En cambio el peso del objeto a en Kg. es el doble que el del b en Kg. es una afirmacin dependiente de la escala.

Una condicin necesaria para la significacin de las afirmaciones es que estas sean libres de escala [MIC86].

COMPLEJIDAD Y TAMAO

La teora existente en el campo de la medicin de sistemas de software es limitada. Especialmente los conceptos de complejidad y tamao son manejados informalmente y, frecuentemente, se encuentran sujetos a interpretacin. Este es el resultado de hablar del mismo concepto bajo diferentes rtulos.

Los problemas relativos a estos conceptos provienen de dos fuentes que guardan una estrecha relacin:

(1) frecuentemente se considera complejidad y tamao como intercambiables (2) no hay un conjunto de propiedades para el tamao o complejidad que tengan una

aceptacin universal como por ejemplo las propiedades de la distancia Para superar esa situacin es importante definir un conjunto mnimo de propiedades

que debera tener cada una de estas mtricas. Tratndose de conceptos diferentes, no es sorprendente que las propiedades que esperamos de sus mtricas tambin lo sean. Desea-mos obtener definiciones formales de tamao, longitud y complejidad tan independientes como sea posible de cualquier abstraccin de un producto.

No perderemos generalidad si representamos un sistema como un conjunto de mdu-los y sus relaciones.

PROPIEDADES DE LAS MEDIDAS DE CONCEPTOS BSICOS

Definicin II-8 Tamao El tamao de un sistema S es una funcin Tamao(S) que se caracteriza por (1) ser

no negativo; (2) tener valor nulo si el sistema es vaco y (3) ser aditivo para mdulos dis-juntos. Esta ltima propiedad permite calcular el tamao de un mdulo partiendo del cono-



cimiento del de sus mdulos disjuntos. Por lo tanto, el agregado de mdulos a un sistema no disminuir su tamao.

El tamao de un sistema obtenido de la fusin de mdulos no puede ser mayor que la suma del tamao de estos.

Las propiedades 1 a 3 se cumplen cuando aplicamos la transformacin admisible de escala de proporcin. Por lo tanto nuestra concepcin intuitiva de tamao y la definicin de medidas de tamao en una escala de proporcin no son contradictorias.

Ejemplos de mtricas que cumplen con las propiedades de tamao: LOC, nme-ro de sentencias, nmero de mdulos, nmero de procedimientos, nmero de operadores, nmero de operandos, nmero de operadores nicos, nmero de operandos nicos. Longitud

El concepto de tamao puede ser interpretado de diferentes formas, dependiendo del objetivo con el cual se est midiendo. Con respecto a los objetos fsicos, el peso y volumen satisfacen las propiedades de tamao. En el caso especial en que los objetos sean unidi-mensionales o que nuestro inters radique en medirlos slo desde el punto de vista de una de sus dimensiones, entonces tamao y longitud son coincidentes.

Sin embargo, para determinadas aplicaciones nos interesan mtricas con otras pro-piedades, por ejemplo si quisiramos determinar si disponemos de espa

departamento de lenguajes y sistemas …oa.upm.es/367/1/pedro_salvetto_leon.pdf · los modelos de...

Documents