Resnmen

El presente trabajose enmarca,dentrodel campo de la medici6n del software, en el dmbitode la especificaci6n de requisitos-La mayor parte de la investigaci6n realizadaen esta parcelade la calidad se centraen el estudio de atributosestructurales, que Casisiempre se evalOanen lases finales del desarrollo, descuidandootrasperspectivasdel modelado de sistemas. Por otraparte, son muy 650 8505 los estudios existentes sobre la interre2aci6nde diferentesm6todos y aspectos de medida y sobre la formalizaci6nde dichoproceso cuando se realiza al cornienzodel ciclo de Vida.En este artfculose analizael papel que juegan las mediciones iniciales en la deterrninaci6ny predicci6n de las caracteristicasde calidad del software y se proponeun rnarcode referenciaque permite forrnalizary automatizarel proceso de medici6n y gestionarla calidad considerando diferentesperspectives de modelado. Es un hecho ampliamenteaceptadoQuelas primeras etapasdel desarrollode softwareson cruciales en la consecuci6n de productos de calidad dentrode los }finites de tiempo y coste establecidos para un proyecto. En este contexto, la medici6n del software esni adquiriendocada vez mayor importancia,debido a la necesidad de obtenerdatos objetivos que contribuyana mejorarla calidad.

Muchos investigadores banproducidomodelos de

caracteristicasde calidad del softwareque pueden ser dtiles para discutir,planifxcary obtenerindices de calidad de los productos de software-Los modelos de calidad rfuiisrecientes(CMM [291, SPICE [ 33 ] [ 35 ]), estan orientadosa la mejora de procesos mediante la definici6n de princiPiosy practices que conducen a mejores productos de software y la deterrninaci6nde la rnadurezde la capacidaden funci6n del grado de cumplimiento de esos principios-Sin embargo, dichosmodelos no sirven de referenciapara eva2uarla calidad de2 softwareproducidoa lo largo del ciclo de Vidaya que, desafortunadamenteo,rganizacionesque cumplen los requisitos CMM no estanproduciendo software de calidad [11]. Otrosmodelos incluyen m6tricasparaevaluar de forma cuantitativael grado de calidad de diferentesatributosdel producto(FCM, GQM-..)[ 25 ] [ 3 ]. Aunque la medici6n deberiapoderse aplicara productos de cualquiernivel, no siempre Se pueden realizer medidas de las caracterfsticasde calidad de las especificaciones debido a la ausenciade m6tricas especificas o a la indeterrninaci6nde las mismas.

El desarrollode metodos de medida en el dmbito de los requisitosdel software esta centrado fundamentalmenteen la medici6n del tamahoy la funcionalidaddel software.

Caracteriisticasde la ERS Problernas de medld6n Abstracci6n Dificultad de medici6n directa de los atributosde calidad Evoluci6n Necesidad de reflejar los cambios y asegurarla consistencia Transformaci6n Evaluaci6n de la trazabilidad Diferentes perspectives de Gesti6n conjunta de mnltiples mode2ado notaciones de mode/ado

Tabla 1. Caracteristicasde las ERS

La dificultaden la medici6n de la ERS

(Especificaci6nde Requisitos del Software) se debe fundamentalmentea algunascaracteristicas inherentesa las propias especificaciones (Tabla I).

El problems principal radicaen el alto nine}de

abstracci6nen el que se encuentran,lo que hace muy dificil definir y medir de forma directay objetivaatributosde calidad. A esta dificultad habrfaque a6adirla derivadadel hecho de que los requisitosevolucionan a medida que progresael desarrollo, esa inestabilidad e incluso volatilidad de los requisitos requiere un proceso sister)[:uiticode obtenci6n y almacenamiento de los datos, en el Que Seasegure la consistencia de las cambios en 108 resultados obtenidos y que permita realizar estudios comparativos sobre dicha evoluci6n. Gtro tipo de evoluci6n sufrida por los requisitos, que repercute igualmente en la dificultad de medici6n es la trasformaci6n que sufren los modelos al ir descendiendo en el nivel de abstracci6n (los modelos de anlisis se transforman en modelos de diseho, etc.), esto conlleva la necesidad de examiner los enlaces de trazabilidad, con lo Que entrarfan enjuego, no s6lo elementos de modelado del nine} de amIilisissino tambi6n de nine} de diseBo. For otra parte, el uso de diferentes m6todos de especificaci6n con notaciones diferentes, o el uso de m6todos y lenguajes actuates que permiten el model&do de los requisitos del sistema desde multiples perspectivas, exige la definici6n y aplicaci6n de diferentes m6tricas especificas para cada notaci6n, si se desea realizer nna valoraci6n completa de la calidad de dicflas especificacianes. En este trabajo se propone una arquitectura para la gesti6n de la calidad de la ERS que contribuye a so}ventar los problernas comentados anteriormente. Dicha arquitectura permite:

Gestionar conjuntarnente la calidad de diferentes perspectivas de modelado Forrnular directamente objetivos de calidad y planes de medida Proporcionar Unabase para la automatizaci6n de las medidas Mantener registros de informaci6n hist6rica Proporcionar soporte para estudios emplricos y construcci6n de modelos predictivos

Trabajos relacionados

La mayoria de los trabajos relacionados con la medici6n en el nivel de la especificaci6n de reQuisitos Se ban centrado fundamentalmente en el desarrollo de metricas para determinat el tarn&Boy la fnncionalidad del software. Butte las de mayor difusi6n se encuentran las metricas de puntos de funci6n [LI,m6tricas Bang [13} o las puntos objeto [SJ.

La medici6n de atributos de calidad de las especificaciones ha sido objeto de algnnos trabajos que van desde la medici6n de especificaciones formates [ 34 ] hasta la aplicaci6n de m6tricas para evaluar la calidad de especificaciones expresadas inforrnalmente en lenguaje natural. En este dldmo dmbito pueden utilizarse algunas metricas de calidad de la documentaci6n como las m6tricas de facilidad de comprensi6n del texto contenido en los documentos [ 23 ] o m6tricas de estrnctura y organizaci6n en documentos convencionales (2] y con hipertexto [ 15 ] [ 32 ]. Otras t6cnicas, como las propuestas por Davis y colaboradores [ 12 ] o el uso de listas de comprobaci6n [ 8 ] (14], realizan la valoraci6n de 2osatributos de calidad de la especificaci6n mediante m6tricas que requieren informaci6n procedente de revisiones t6cnicas, inspecciones, Walkthrough, o auditorias encaminadas a determiner el cumplirniento de los estar1dares,directrices, espacific&clonesy procedimientos. Los resultados obtenidos en este tipo de evaluaciones tienen un alto componente subjetivo y son claramente dependientes de las personas Que los realizan aun fijando previamente criterios objetivos.

La creciente adopci6n de la tecnologia de orientaci6n a objetos en el desarrollo de software ha dado Ingar a la aparici6n de nuevas m6trices especificas para este tipo de sistemas. Como mds representativas se pueden citar las m6tricas de disebo {9},m6tricas orientadas a clases [24}. m6tricas orientadas a operaciones [ 10 ] o las m6tricas para prnebas [ 4 ]. Recientemente Se ban propuesto metricas para la evaluaci6n de la ca2idad a partir de modelos praducidos en etapas iniciales del ciclo de Vida, coma son las m6tricas de calidad y complejidad en modelos OMT [ 16 ] o las metricas de calidad de los diagramas de clases en UM:L [ 17 ] mediante las cuales se eval la complejidad introducida por las jerarquias de generalizaci6n en los diagramas de clases obtenidos en las etapas de amilisis y discho. Asimismo ban surgido intentos de realizar evaluaciones de la calidad a partir de modelos dindmicos, tal es el caso del trabajo de Poels en el que se realiza la medici6n de modelos conceptuales basados en eventos [ 31 ].

Del anaZisisde la bibliografia resehada se puede concluir que las m6tricas de calidad para sisternas orientados a objetos Se caracterizan por estar centradas principalmente en el disedo y rruiS concretamente en el modelado estructural o estatico, liminiindosednicamente a evaluar la complejidad, reusabilidad, acoplamiento o cohesi6n, sin tenet en cuenta otros atribntos de calidad que deben exhibir las especificaciones de requisitos del software.

For otra parte, la necesidad de medir diferentes aspectos del software y la proliferaci6n de m6tricas surgidas debido a la creciente importancia que esta adquiriendo la medici6n estd contribuyendo a crear confusi6n sobre las relaciones entre tales medidas, asf como sobre su forrna y dmbito de aplicaci6n. Este hecho ha conducido la bdsqueda de nuevos caminos en la investigaci6n que se orientan hacia la propuestade modelos y marcos de referencia ("framewors")que permitanla organizaci6nde las medidas y la clasificaci6n de las entidadesde software a trav6sde un conjunto de dimensiones que Se usan paraidentificarsistemas, modelos, atributosy objetos susceptibles de medir [ 30 ] [ 7 ].

Medidas basadas en modelos

La medici6n efectiva del software y la interpretaci6n significativa de los datos depende del reconocimiento de la dualidad esencial del proceso de medida- La medici6n implica la definici6n de dos modelos: . El contexto empirico del mundo real, en el que Ilene Ingar la medici6n Un modelo num6rico que incorpora aspectos basados en la medici6n y bien definidos del modelo empfrico [ 28 ]. La teorfa de la medici6n implica la definici6n de interrelaciones formales entre los dos modelos. El proceso completo de medici6n Semuestra en la figura 1.

Moc!eI,o , emp

Ico

Medlda ~

Moc!elo, ~~nu.rulerlco ~ j Comprensi6n/ ~refinamiento Rosult

do emplnco

InterPretacl6n |Matemdticas/ , estadistica

,.,~ Resul.tad. o numerlco Figura 1. Modelos implicados en el proceso de medida

Las interrelacionesesenciales entrelos modelos

num6rico y empirico subyacentes en el proceso de medida requiere un marco de unificaci6n,o un metamodelo, pararazonar sobredichos modelos y Sus interrelaciones.La figura 2 ilustraunajerarquia gen6rica de modelos. Cualquiermodelo empirico de medida reJacionadocon el software Se puede considerarconstruidoa partirde fragmentosde producto y/o de proceso (submodelos) i,j,k. El modelo num6ricoformal correspondienteSe represents por elmodelo y los fragmentosdel modelo. Si se tiene que razonarsobre la efectividad y evoluci6n de los modelos de medida, Se puede definir un metamodelo para construirde forma razonada y modificar los modelos de medida empiricos y Burn6FicosS.in embargo,esto requiere un meta-metamodelopara definirla sintaxis y la semdnticadel metamodelo(por ejemplo, grafo y teoria de conjuntos).Unajerarquiade cuatro niveles similar es la base del formatoesnindarde intercambiode datos de CASE para el "ime'rworking"de herramientasCASE [191. Los modelos son necesarios, entreotrascosas, para minimizarla complejidady relatividadinherentes al concepto "calidaddel software",manejar diferentesperspectivasde modelado, gestionarla enoluci6n y asegurarla consistencia de los cambios.Trasladandolas ideas anterioresal mbito de la especificaci6n de requisitosse puede construiruna arquitecturade gesti6n de calidad que sirva de marcopara conseguir los objetivos que Se ban apuntadoen la introducci6n.

Marco de referencia para la ges66n de calidad

En este apartadose propone un patr6nde

arquitecturade gesti6n de calidad de la especificaci6n de requisitosque separay enlaza los aspectosreferentes a diferentesperspectivas de modelado.

La definici6nde m6trices en el arnbitode la ERS es claramentedependientedel m6todo, lenguaje o notaci6n de modelado que Se utilice en la especificaci6n por lo que puede hacerseuso de metamodelos paradefinir dichasm6tricasy establecerrelaciones entreellas (por ejemplo establecimientode conexiones entrela perspectiva estructural,din;irnicay funcional en la especificaci6n de requisitos de sistemas orientados a objetos). Ademas, dichosmodelos pueden servir de base para la aplicaci6nautor0uiticdae dichas m6tricas,mediantela combinaci6nherrarnientas autormiticasde modelado con un repositorio en el que Se almacene y gestione informaci6nde 'B" ,-~~~ ' -~ diferentesniveles de instanciaci6n(figura3). Un repositoriode estas caracterfsticasperrnitea su vez mantenerun registrohist6ricode los resultados obtenidos en el proceso de medida Quepuede servir de referenciapara la realizaci6nde estudios comparativossobre la validez de las m6tricaso la repercusi6nde deterrninadoscambios y para la construcci6nde modelos predictivos.

El primeraspecto Quehay Queconsiderares la

transformaci6ndel concepto abstractode calidad en una serie de objetivos concretos de calidad que Se corresponderancon las aspiraciones de los diferentesgruposde "Stakeholders".Parafijar dichos objetivos Se puede haceruso de modelos de calidad descritosen la bibliograffa.Podriarnos adapterel enfoque GQM [ 3 ] con el fin de enlazar los objetivosconceptualescon t6cnicas especificas de medici6n.

For otraparte,hay quetener en cuentaque la consecuci6n de los objetivos de calidadconlleva la realizaci6n de medidas de muy diversa naturaleza, la mayorfade las cuales no pueden realizarse directamentesobre atributosconcretos, sino que requierentecnicas complejas demedici6n. Estos problernasSe agravancuando se intents evaluarla calidad de las especificaciones de requisitosdebido a las caracteristicasinherentesa la mismasQue dificultanla definici6n y aplicaci6n de m6tricas, como se coment6 en el apartadode introducci6n.

El disefio y aplicaci6n de t6cnicas de valoraci6ne

incluso predicci6nde la calidad Se puede simplificary sistematizarmedianteun repositorio que almacenemetadatos sobre las especificaciones y su evoluci6n~El principal objetino de este enfoque consisteen definirun esquema de metabase de datosQuepueda capturary enlazar todos los aspectos relevantesde la Bastionde calidad.

SeguidarnenteSe clasiflcan algunas de las dimensionesrelevantesde calidad de la especiflcaci6n de requisitosy Se dan ejemplos de tipos de medidas Quepodrfanayudara establecerla calidad de un componenteparticularcon respecto a una particulardimensi6n de la calidad [ 22 ]. Esta estructurabdsics puede ser capturadaforrnalmente en una extensi6n del enfoque GQM e implementaday usadaen una metabase de datos. La satisfacci6nde los atributosde calidad Quese muestranen la tabla 2 conducen a la consecuci6n de las dimensionesde calidad establecidas en la norrnaISO 9126 {211(fiabilidad, funcionalidad, eficiencia, portabilidad,facilidad de uso y facilidad de mantenimiento),la mayoriade las cuales 5610 pueden evaluarseen fases pr6ximas a la implementaci6n.For ejemplo, las dimensionesde correcci6ny complecci6n conducen a mejorarla funcionalidaddel sistenla y dimensiones como trazabilidady legibilidad repercutenen la facilidad de uso y de rnantenimiento~

La sisternatizaci6ndelproceso cornienzacon una

adaptaci6nde la propuestade formalizaci6n de la gesti6n de calidadpara datos de Jarkey colaboradcres[ 22 ] basada en un analisis cualitativo de las relacionesentrelos factores de calidad (ej. Objetivo-subobjetivo,objetivosignificado...). Los stakeholderspueden realizarla evaluaci6n subjetivade Suspropios objetivos y de su importanciarelativa.Dichas evaluaciones,junto con las calculadas,se usan como medidas de calidad en el modelo de arquitectura.Esto facilita una simple integraci6ndel modelo de calidady arquitectura.Este enfoque se usa ampliamenteen la ingenieriaindustrialbajo la etiquetade "Qua/ity Function Deployment" La arquitectura propuesta se basa en el estdar ISO Information Resources Dictionary System (IRDS) [2O}que propone la organizaci6n de la inforrnaci6n en cuatro niveles de instanciaci6n (figura 4); nive/ de z.nstanciasy escenarios (contiene objetos Queno pueden tener instancias: datos, estados, resultados de las mediciones...), nz.ve/de modelos (clases Quedefinen las propiedades de los objetos del nivel de instancias y las reglas de manipulaci6n de los mismos), nive/ de lenguajes de modelado (metaclases Que definen la estructura de las clases del nivel del modelo) y nivel de meta metamodelo (meta metaclases con instancias en el nivel anterior. Es posible la definici6n demtiltiples lenguajes de modelado mediante la apropiada instanciaci6n). Esas cuatro capas Se agrupan en tres pares de niveles entrelazados: entorno de use, entorno de modelado conceptual y entorno de z.ngenieriade mados [ 27 ].

La gesti6n conjunta de todos los niveles del repositorio cornpartido hace posible soportar la coevoluci6n requerida de los modelos, metarnodelos e incluso meta metamodelos (mode)Os M2) Quepermiten realizar abstracciones de los lenguajes de modelado, y por tanto, definir metainformaci6n sobre m6tricas adecuadas a las notaciones que soportan dichos lenguajes. Los lenguajes de modelado existentes, nuevos o "extendidos, asi como la definici6n de m6tricas especificas pueden ser instanciados del modelo M2, que puede estar tambi6n sujeto a cambios. La implementaci6n de la arquitectura IRDS mediante un repositorio gestionado por un sistema de gesti6n de metabase de datos (SGMBD) [ 26 ] proporciona soporte para metamodelos orientados a la medici6n. Combinando dicha arquitectura con modelos como GQM se pueden crear modelos Que guian y proporciona soporte autonuitico al usuario en el proceso de gesti6n de la calidad. Dichos modelos facilitan el establecirniento y gesti6n de 105 prograrnasde medida,la elecci6n de m6tricasy metodos de andlisis,la utilizaci6n constructivade experienciaspasadas,la definici6n de planesde medida y la estructuraci6nde informes. Pueden tambi6nproporcionarsoportepara definiry gestionarestudiosempiricos paraconstruir modelos predictivos (estimaci6n).Debido a Quese pueden capturertodos los aspectos del proceso de medida, esta arquitecturafacilita el empaquetarnientoy utilizaci6n de experiencias capturadasduranteel uso de la herramientajunto con un conjunto de softwareconvencional. La figura 3 muestra un esquemade la forma de implementaci6nde la arquitectura propuesta.Conclusiones Con este trabajose hapretendido,en primerlugar, suscitarel inter6spor la medici6n en las etapas iniciales del desarrollode software, ya Quedichas etapasson decisinasen la consecuci6n de la calidad de los sistemas. Granpartede la investigaci6nrealizadaen este campo se centraen el estudio de atributosestructurales,descuidando los aspectosdinmico y funcional de las especificaciones. Aqui se presenta,adem un marco de referenciaque permitegestionar conjuntamentey de forma sistemdticadiferentes perspectivasde la calidad de los requisitos.Dicho marco se basa en la arquitecturaIRDS Que contemplala definici6n de modelos en diferentes niveles de instanciaci6n.El uso de tales modelos proporcionaun contexto parala definici6n de objetivos, reutilizaci6nde objetos y experiencias, selecci6n de los procesos de medida mas adecuados, evaluaci6ny comparaci6nde resultados y predicci6n.Ennuestrocaso, podriamosconcluir Queel enfoque propuestoproporciona:Un marco paradefinirmodelos de calidad y objetivos especificos del proyecto, un mecanismo para evaluarla calidad en las primerasfases del ciclo de vida, soportepara el registroy uso provechosode experiencias pasadasy unmedio paragestionarla evoluci6n y la consistencia de los cambios

References

I. Albrecht , A.J. , "Measuringapplicationdevelopment" . Proc" of IBM Applications DevelopmentJoint SHARB/GUIDE Symposium Monterey, CA, pp 83 - 92 , 1979 .

2- Arthur , J.D. y Stevens, KT. "Assessing the adequacyof documentationthrough documentquality indicators" . Proceedings of the IEEE Conference of SoftwareMaintenance ,pp. 4049 , 1989 .

3. Basili , V.R. y Rombach, H.D. , "The TAME Project: Towards Improvement-Oriented Software Environments" , IEEE Transaction on Software Engineering , 14 ( 6 ), 758 - 73 1988.

4. Binder , R. , "Testing Object-Oriented Systems" , AmericanProgrammer , 7 ( 4 ), 22 - 29 , 1994 .

5. Boehrn B.W. , Kaspar , J.R. y otros "Characteristicsof Software Quality" , TRW Series of Software Technology , 1978 .

6. Boehrn B.W. , Clark , B. , Horowitz , E. et al., "Cost Models for future life cycle processes: COCOMO 2.0" , Annals of Software Engineering 1 ( 1 ), pp 1 - 24 , 1995 .

7. Briand , L"C. , Daly , J.W. y Wast, ~J.K. "A unified framework for coupling measurement in objectoriented system" , IEEE Transaction on Software Engineering , 25 ( 1 ), 1999 .

8. Brykczynskkj , B. , "A survey of software inspection checklist , ACM SoftwareEngineering Notes, 24(I) , pp 82 - 89 , 1999 .

9. Chidamber ,S.R. y Remoter, C.F. , "A Metrics Suite for Object-GrientedDesign" , IEEE Transactions of SoftwareEngineering , 20 ( 6 ), 476493 , 1994 .

10. Churcher . N.I. and Shepperd M.J. , Towards Conceptual Frameworkfor Object-OrientedMetrics" , ACM Software Engineering Notes 20 ( 2 ), 67 - 76 , 1995 .

II.Cook , A , D. , "Confusing Process and Product: Why the Qualityis not ThereYet" , CrossTalk,July, 1999 .

12. Davis , A. et al., "Identifying and MeasuringQuality in a Software Requirements Specification" Proceedings of the First International Software Metrics Symposiurn Baltimore, May 21-22 , pp. 141 - 252 , 1993 .

13. DeMarco , T., "Controlling Software Projects" , YourdonPress , 1982 .

14- Farbey . B., "SoftwareQuality metrics:considerations about requirementsand requirements specification" , Informationand SoftwareTechnology . 32 ( l ), pp 60 64 , 1990 .

15. French , J.C. , Knight , J.C" y Powell, A.L , Applying hipertext structures to software documentation" , InformationProcessing and Management" , 33 ( 2 ), pp 219 - 231 , 1997 .

16. Genero , M. , Manse , M.E. Piattini , M. y Garcia F.J. "Assessing the quality and the Complexity of OMT Models" 2nd European Software Measurements Conference-FESMA99, Amsterdam Netherlands ,pp 99 - 109 , 1999 .

17. Genero , M. , Piattini , M y Calero C. "Una propuesta para medir la calidad de los diagramasde clases en UML",IDEAS'2OOOC,ancuu , Mexico, pp 373 - 384 , 2000 .

18. Cub , T. " Principles of software engineering management" , Addison-Wesley , 1988 .

19- Imber , M. "CASE"44tt Interchangeformatstandars" , Information and Software Technology, Nov~ 2991 , pp. 647 - 655

20.150/IEC 10027, "Information Technology Information Resource Dictionary System (IRDS) Framework"I,SO /IEC internationalStandardedition, 1990 -

21.150/IEC 9126, "Software product evaluation Qualitycharacteristicsand guidelines for their use " , 1991 .

22. Jarke , M-, Jeusfeld , M.A. , Quix , C. y Vassiliadis, P. "Architectureand quality in data warehouses: and Extended Repository Approach" , Information System 24 ( 3 ). pp 229 - 253 , 1999 ~

23. Lehner , F. , "Quality control in software documentation: Measurement of text comprehensibility' , Information and Management , 25 , pp 133 - 146 , 1993 .

24. Lorenz , M. and Kidd , J. , "Object_orientedSoftware Metrics" , PrenticeHall 1994 .

25. McCall , J.A. , Richards , P.K. and Walters , G.F. "Factorsin softwarequality" , RADC TR-77-369, US Rome Air Development CenterReports NTIS AD/A049 014 015 , 055 , 1977 .

26. Moreno . M.N. , Polo , M.J. , Miguel, LA. y Garcia, F.J. " Urnsistema de meta-base de datos basado en UML e integrado en un sistema de gesti6n de bases de datos distribuidas."En Jornadasde Ingenien .adel Softwarey bases de datos, Caceres, Espafja 1999 .

27. Nissen , H.W. , andJarke, M. , "Repositorysupport for multi-perspective requirements engineering" . Informadon System Vol. 24 , No. 2 , pp 131 - 158 1999.

28. Offen , R. J. y Jeffery, R. , "Establishing software measurementsprograms" , IEEE Software , 14 ( 2 ), pp 45 - 53 , 1997 .

29. Paulk , M. Curtis , B. , Chrissis , M , and Weber , C. " Capability Maturity Model for Software: Version 1.1" Technical Report SEI-93-TR..24 , Software Engineering 2nstitute , Carnegie Mellon University, Pittsburgh, Pennsylvania USA , 1993 .

30. Poels , G. , "Towardsa size measurement framework for objectoriented especifications" . H Coombes, M. MOORvan Huysduynen, and B . Peelers (eds.), Proceedings of the Ist European Software MeasurementConference (I:;ESMA'98) ,Antwerp, pp. 379 - 388 , 1998 .

31. Peels , G. , "On the measurements of event-based objectoriented conceptualmodels" . 4th International ECOOP Workshop on Quantitative Approaches in Object Oriented Software Engineering , Cannes, France, 2000 .

32. Roth , T. , Aiken , P. y Hobbs, S. , "Hypermediasupport for software developmemt: a retrospective assessment" , Hypermedia 6 ( 3 ), pp 149 - 173 , 1994 .

33. Rout , T.P- " Software process improvement and practice",I(I) . pp 57 - 6fi , 1995 .

34. Samson , W.B. , Nevin , D.G. Y Dugard p.I. , "Predictive software metrics based on a formal }990.

35. SPICE , "SPICE Improvement and htt J" /w.su.edu.au/s cument Suite, Soe Process Capahili determination" , ice/ , 1999 .