MARCO DE REFERENCIA PARA LA GESTION DE LA CAL/DAD DE LAS

ESPECIFICACIONES DE REQUISITOS

Maria N. Moreno Garcfa*, Francisco J. Garcia Pefialvo, M. Jos Polo Martin, VivianL6pez Batista y Anglica Gonzez Arrieta

Universidad de Salamanca. Departamento de Informtics y Automatics,Te16fOno: 34-923-294653, Fax: 34-923-294514, *e-mail: mmg@~usa]-es

ResnmenEl presente trabajo se enmarca, dentro del campode la medici6n del software, en el dmbito de laespecificaci6n de requisitos- La mayor parte de lainvestigaci6n realizada en esta parcela de la calidadse centra en el estudio de atributos estructurales,que Casi siempre se evalOan en lases finales deldesarrollo, descuidando otras perspectivas delmodelado de sistemas. Por otra parte, son muy650 8505 los estudios existentes sobre lainterre2aci6n de diferentes m6todos y aspectos demedida y sobre la formalizaci6n de dicho procesocuando se realiza al cornienzo del ciclo de Vida. Eneste artfculo se analiza el papel que juegan lasmediciones iniciales en la deterrninaci6n ypredicci6n de las caracteristicas de calidad delsoftware y se propone un rnarco de referencia quepermite forrnalizar y automatizar el proceso demedici6n y gestionar la calidad considerandodiferentes perspectives de modelado.

Introducd6n

Es un hecho ampliamente aceptado Que lasprimeras etapas del desarrollo de software soncruciales en la consecuci6n de productos de calidaddentro de los }finites de tiempo y coste establecidospara un proyecto. En este contexto, la medici6n delsoftware esni adquiriendo cada vez mayorimportancia, debido a la necesidad de obtener datosobjetivos que contribuyan a mejorar la calidad.Muchos investigadores ban producido modelos decaracteristicas de calidad del software que puedenser dtiles para discutir, planifxcar y obtener indicesde calidad de los productos de software- Losmodelos de calidad rfuiis recientes (CMM [291,SPICE [33] [35]), estan orientados a la mejora deprocesos mediante la definici6n de princiPios ypractices que conducen a mejores productos desoftware y la deterrninaci6n de la rnadurez de la

capacidad en funci6n del grado de cumplimientode esos principios- Sin embargo, dichos modelosno sirven de referencia para eva2uar la calidad de2software producido a lo largo del ciclo de Vida yaque, desafortunadamente, organizaciones quecumplen los requisitos CMM no estan produciendosoftware de calidad [11]. Otros modelos incluyenm6tricas para evaluar de forma cuantitativa elgrado de calidad de diferentes atributos delproducto (FCM, GQM-..) [25] [3]. Aunque lamedici6n deberia poderse aplicar a productos decualquier nivel, no siempre Se pueden realizermedidas de las caracterfsticas de calidad de lasespecificaciones debido a la ausencia de m6tricasespecificas o a la indeterrninaci6n de las mismas.El desarrollo de metodos de medida en el dmbitode los requisitos del software esta centradofundamentalmente en la medici6n del tamaho y lafuncionalidad del software.

Caracteriisticas de la ERS Problernas de medld6nAbstracci6n Dificultad de medici6n directa de

los atributos de calidadEvoluci6n Necesidad de reflejar los cambios

y asegurar la consistenciaTransformaci6n Evaluaci6n de la trazabilidadDiferentes perspectives demode2ado

Gesti6n conjunta de mnltiplesnotaciones de mode/ado

Tabla 1. Caracteristicas de las ERS

La dificultad en la medici6n de la ERS(Especificaci6n de Requisitos del Software) sedebe fundamentalmente a algunas caracteristicasinherentes a las propias especificaciones (Tabla I).El problems principal radica en el alto nine} deabstracci6n en el que se encuentran, lo que hacemuy dificil definir y medir de forma directa yobjetiva atributos de calidad. A esta dificultadhabrfa que a6adir la derivada del hecho de que losrequisitos evolucionan a medida que progresa el

QuaTIC 2001 / 207

desarrollo, esa inestabilidad e incluso volatilidadde los requisitos requiere un proceso sister)[:uitico deobtenci6n y almacenamiento de los datos, en el QueSe asegure la consistencia de las cambios en 108resultados obtenidos y que permita realizarestudios comparativos sobre dicha evoluci6n. Gtrotipo de evoluci6n sufrida por los requisitos, querepercute igualmente en la dificultad de medici6nes la trasformaci6n que sufren los modelos al irdescendiendo en el nivel de abstracci6n (losmodelos de anlisis se transforman en modelos dediseho, etc.), esto conlleva la necesidad deexaminer los enlaces de trazabilidad, con lo Queentrarfan en juego, no s6lo elementos de modeladodel nine} de amIilisis sino tambi6n de nine} dediseBo. For otra parte, el uso de diferentes m6todosde especificaci6n con notaciones diferentes, o eluso de m6todos y lenguajes actuates que permitenel model&do de los requisitos del sistema desdemultiples perspectivas, exige la definici6n yaplicaci6n de diferentes m6tricas especificas paracada notaci6n, si se desea realizer nna valoraci6ncompleta de la calidad de dicflas especificacianes.En este trabajo se propone una arquitectura para lagesti6n de la calidad de la ERS que contribuye aso}ventar los problernas comentados anteriormente.Dicha arquitectura permite:

Gestionar conjuntarnente la calidad dediferentes perspectivas de modeladoForrnular directamente objetivos de calidady planes de medidaProporcionar Una base para laautomatizaci6n de las medidasMantener registros de informaci6n hist6ricaProporcionar soporte para estudiosemplricos y construcci6n de modelospredictivos

Trabajos relacionados

La mayoria de los trabajos relacionados con lamedici6n en el nivel de la especificaci6n dereQuisitos Se ban centrado fundamentalmente en eldesarrollo de metricas para determinat el tarn&Bo yla fnncionalidad del software. Butte las de mayordifusi6n se encuentran las metricas de puntos defunci6n [LI, m6tricas Bang [13} o las puntosobjeto [SJ.La medici6n de atributos de calidad de lasespecificaciones ha sido objeto de algnnos trabajosque van desde la medici6n de especificacionesformates [34] hasta la aplicaci6n de m6tricas paraevaluar la calidad de especificaciones expresadasinforrnalmente en lenguaje natural. En este dldmodmbito pueden utilizarse algunas metricas decalidad de la documentaci6n como las m6tricas de

facilidad de comprensi6n del texto contenido en losdocumentos [23] o m6tricas de estrnctura yorganizaci6n en documentos convencionales (2] ycon hipertexto [15] [32]. Otras t6cnicas, como laspropuestas por Davis y colaboradores [12] o el usode listas de comprobaci6n [8] (14], realizan lavaloraci6n de 2os atributos de calidad de laespecificaci6n mediante m6tricas que requiereninformaci6n procedente de revisiones t6cnicas,inspecciones, Walkthrough, o auditoriasencaminadas a determiner el cumplirniento de losestar1dares, directrices, espacific&clones yprocedimientos. Los resultados obtenidos en estetipo de evaluaciones tienen un alto componentesubjetivo y son claramente dependientes de laspersonas Que los realizan aun fijando previamentecriterios objetivos.La creciente adopci6n de la tecnologia deorientaci6n a objetos en el desarrollo de softwareha dado Ingar a la aparici6n de nuevas m6tricesespecificas para este tipo de sistemas. Como mdsrepresentativas se pueden citar las m6tricas dedisebo {9}, m6tricas orientadas a clases [24}.m6tricas orientadas a operaciones [10] o lasm6tricas para prnebas [4]. Recientemente Se banpropuesto metricas para la evaluaci6n de la ca2idada partir de modelos praducidos en etapas inicialesdel ciclo de Vida, coma son las m6tricas de calidady complejidad en modelos OMT [16] o las metricasde calidad de los diagramas de clases en UM:L [17]mediante las cuales se eval la complejidadintroducida por las jerarquias de generalizaci6n enlos diagramas de clases obtenidos en las etapas deamilisis y discho. Asimismo ban surgido intentosde realizar evaluaciones de la calidad a partir demodelos dindmicos, tal es el caso del trabajo dePoels en el que se realiza la medici6n de modelosconceptuales basados en eventos [31].Del anaZisis de la bibliografia resehada se puedeconcluir que las m6tricas de calidad para sisternasorientados a objetos Se caracterizan por estarcentradas principalmente en el disedo y rruiSconcretamente en el modelado estructural oestatico, liminiindose dnicamente a evaluar lacomplejidad, reusabilidad, acoplamiento ocohesi6n, sin tenet en cuenta otros atribntos decalidad que deben exhibir las especificaciones derequisitos del software.For otra parte, la necesidad de medir diferentesaspectos del software y la proliferaci6n de m6tricassurgidas debido a la creciente importancia que estaadquiriendo la medici6n estd contribuyendo a crearconfusi6n sobre las relaciones entre tales medidas,asf como sobre su forrna y dmbito de aplicaci6n.Este hecho ha conducido la bdsqueda de nuevoscaminos en la investigaci6n que se orientan hacia

la propuesta de modelos y marcos de referencia("framewors") que permitan la organizaci6n de lasmedidas y la clasificaci6n de las entidades desoftware a trav6s de un conjunto de dimensionesque Se usan para identificar sistemas, modelos,atributos y objetos susceptibles de medir [30] [7].

Medidas basadas en modelos

La medici6n efectiva del software y lainterpretaci6n significativa de los datos dependedel reconocimiento de la dualidad esencial delproceso de medida- La medici6n implica ladefinici6n de dos modelos:

. El contexto empirico del mundo real, en elque Ilene Ingar la medici6n Un modelonum6rico que incorpora aspectos basadosen la medici6n y bien definidos del modeloempfrico [28]. La teorfa de la medici6n

implica la definici6n de interrelaciones formalesentre los dos modelos. El proceso completo demedici6n Se muestra en la figura 1.

Moc!eI,o Medlda ~ Moc!elo,, emp Ico ~ ~nu.rulerlco ~

j Comprensi6n/ |Matemdticas/~refinamiento , estadistica

,., ~Rosult do InterPretacl6n Resul.tad. oemplnco numerlco

Figura 1. Modelos implicados en el proceso demedida

Las interrelaciones esenciales entre los modelosnum6rico y empirico subyacentes en el proceso demedida requiere un marco de unificaci6n, o unmetamodelo, para razonar sobre dichos modelos ySus interrelaciones. La figura 2 ilustra una jerarquiagen6rica de modelos. Cualquier modelo empiricode medida reJacionado con el software Se puedeconsiderar construido a partir de fragmentos deproducto y/o de proceso (submodelos) i,j,k. Elmodelo num6rico formal correspondiente Serepresents por el modelo y los fragmentos delmodelo. Si se tiene que razonar sobre la efectividady evoluci6n de los modelos de medida, Se puededefinir un metamodelo para construir de formarazonada y modificar los modelos de medidaempiricos y Burn6Ficos. Sin embargo, esto requiere

un meta-metamodelo para definir la sintaxis y lasemdntica del metamodelo (por ejemplo, grafo yteoria de conjuntos). Una jerarquia de cuatroniveles similar es la base del formato esnindar deintercambio de datos de CASE para el"ime'rworking" de herramientas CASE [191.

Los modelos son necesarios, entre otras cosas, paraminimizar la complejidad y relatividad inherentesal concepto "calidad del software", manejardiferentes perspectivas de modelado, gestionar laenoluci6n y asegurar la consistencia de loscambios. Trasladando las ideas anteriores al mbitode la especificaci6n de requisitos se puedeconstruir una arquitectura de gesti6n de calidad quesirva de marco para conseguir los objetivos que Seban apuntado en la introducci6n.

Marco de referencia para la ges66n decalidad

En este apartado se propone un patr6n dearquitectura de gesti6n de calidad de laespecificaci6n de requisitos que separa y enlaza losaspectos referentes a diferentes perspectivas demodelado.La definici6n de m6trices en el arnbito de la ERSes claramente dependiente del m6todo, lenguaje onotaci6n de modelado que Se utilice en laespecificaci6n por lo que puede hacerse uso demetamodelos para definir dichas m6tricas yestablecer relaciones entre ellas (por ejemploestablecimiento de conexiones entre la perspectivaestructural, din;irnica y funcional en laespecificaci6n de requisitos de sistemas orientadosa objetos). Ademas, dichos modelos pueden servirde base para la aplicaci6n autor0uitica de dichasm6tricas, mediante la combinaci6n herrarnientasautormiticas de modelado con un repositorio en elque Se almacene y gestione informaci6n de

QuaTIC 2001 / 209

ISO [ROS (Information Resource Dictionary System)

incluso predicci6n de la calidad Se puedesimplificar y sistematizar mediante un repositorioque almacene metadatos sobre las especificacionesy su evoluci6n~ El principal objetino de esteenfoque consiste en definir un esquema demetabase de datos Que pueda capturar y enlazartodos los aspectos relevantes de la Bastion decalidad.Seguidarnente Se clasiflcan algunas de lasdimensiones relevantes de calidad de laespeciflcaci6n de requisitos y Se dan ejemplos detipos de medidas Que podrfan ayudar a establecer lacalidad de un componente particular con respecto auna particular dimensi6n de la calidad [22]. Estaestructura bdsics puede ser capturada forrnalmenteen una extensi6n del enfoque GQM eimplementada y usada en una metabase de datos.La satisfacci6n de los atributos de calidad Que semuestran en la tabla 2 conducen a la consecuci6nde las dimensiones de calidad establecidas en lanorrna ISO 9126 {211(fiabilidad, funcionalidad,eficiencia, portabilidad, facilidad de uso y facilidadde mantenimiento), la mayoria de las cuales 5610

pueden evaluarse en fases pr6ximas a laimplementaci6n. For ejemplo, las dimensiones decorrecci6n y complecci6n conducen a mejorar lafuncionalidad del sistenla y dimensiones comotrazabilidad y legibilidad repercuten en la facilidadde uso y de rnantenimiento~La sisternatizaci6n delproceso cornienza con unaadaptaci6n de la propuesta de formalizaci6n de lagesti6n de calidad para datos de Jarke ycolaboradcres [22] basada en un analisis cualitativode las relaciones entre los factores de calidad (ej.Objetivo-subobjetivo, objetivosignificado...). Losstakeholders pueden realizar la evaluaci6nsubjetiva de Sus propios objetivos y de suimportancia relativa. Dichas evaluaciones, juntocon las calculadas, se usan como medidas decalidad en el modelo de arquitectura. Esto facilitauna simple integraci6n del modelo de calidad yarquitectura. Este enfoque se usa ampliamente en

'B" Figure 4. Estructura de referencia ,-~~~

' -~

diferentes niveles de instanciaci6n (figura 3). Unrepositorio de estas caracterfsticas perrnite a su vezmantener un registro hist6rico de los resultadosobtenidos en el proceso de medida Que puede servirde referencia para la realizaci6n de estudioscomparativos sobre la validez de las m6tricas o larepercusi6n de deterrninados cambios y para laconstrucci6n de modelos predictivos.

Figure 3. Arquitectura de gesti6n de calidad

El primer aspecto Que hay Que considerar es latransformaci6n del concepto abstracto de calidaden una serie de objetivos concretos de calidad queSe corresponderan con las aspiraciones de losdiferentes grupos de "Stakeholders". Para fijardichos objetivos Se puede hacer uso de modelos decalidad descritos en la bibliograffa. Podriarnosadapter el enfoque GQM [3] con el fin de enlazarlos objetivos conceptuales con t6cnicas especificasde medici6n.For otra parte, hay que tener en cuenta que laconsecuci6n de los objetivos de calidad conlleva larealizaci6n de medidas de muy diversa naturaleza,la mayorfa de las cuales no pueden realizarsedirectamente sobre atributos concretos, sino querequieren tecnicas complejas de medici6n. Estosproblernas Se agravan cuando se intents evaluar lacalidad de las especificaciones de requisitos debidoa las caracteristicas inherentes a la mismas Quedificultan la definici6n y aplicaci6n de m6tricas,como se coment6 en el apartado de introducci6n.El disefio y aplicaci6n de t6cnicas de valoraci6n e

210 / QuaTIC'2001

la ingenieria industrial bajo la etiqueta de "Qua/ityFunction Deployment"

Tabla 2. Dimensiones de la calidad de las ERS

La arquitectura propuesta se basa en el estdarISO Information Resources Dictionary System(IRDS) [2O}que propone la organizaci6n de lainforrnaci6n en cuatro niveles de instanciaci6n(figura 4); nive/ de z.nstancias y escenarios(contiene objetos Que no pueden tener instancias:datos, estados, resultados de las mediciones...),nz.ve/ de modelos (clases Que definen laspropiedades de los objetos del nivel de instancias ylas reglas de manipulaci6n de los mismos), nive/ delenguajes de modelado (metaclases Que definen laestructura de las clases del nivel del modelo) ynivel de meta metamodelo (meta metaclases coninstancias en el nivel anterior. Es posible ladefinici6n de mtiltiples lenguajes de modeladomediante la apropiada instanciaci6n). Esas cuatrocapas Se agrupan en tres pares de nivelesentrelazados: entorno de use, entorno demodelado conceptual y entorno de z.ngenieria demados [27].La gesti6n conjunta de todos los niveles delrepositorio cornpartido hace posible soportar lacoevoluci6n requerida de los modelos,metarnodelos e incluso meta metamodelos(mode)Os M2) Que permiten realizar abstraccionesde los lenguajes de modelado, y por tanto, definirmetainformaci6n sobre m6tricas adecuadas a lasnotaciones que soportan dichos lenguajes. Loslenguajes de modelado existentes, nuevos o "-extendidos, asi como la definici6n de m6tricasespecificas pueden ser instanciados del modeloM2, que puede estar tambi6n sujeto a cambios.La implementaci6n de la arquitectura IRDSmediante un repositorio gestionado por un sistemade gesti6n de metabase de datos (SGMBD) [26]proporciona soporte para metamodelos orientadosa la medici6n. Combinando dicha arquitectura conmodelos como GQM se pueden crear modelos Queguian y proporciona soporte autonuitico al usuarioen el proceso de gesti6n de la calidad. Dichosmodelos facilitan el establecirniento y gesti6n de

105 prograrnas de medida, la elecci6n de m6tricas yme todos de andlisis, la utilizaci6n constructiva deexperiencias pasadas, la definici6n de planes demedida y la estructuraci6n de informes. Puedentambi6n proporcionar soporte para definir ygestionar estudios empiricos para construirmodelos predictivos (estimaci6n). Debido a Que sepueden capturer todos los aspectos del proceso demedida, esta arquitectura facilita elempaquetarniento y utilizaci6n de experienciascapturadas durante el uso de la herramienta juntocon un conjunto de software convencional. Lafigura 3 muestra un esquema de la forma deimplementaci6n de la arquitecturapropuesta.Conclusiones

Con este trabajo se ha pretendido, en primer lugar,suscitar el inter6s por la medici6n en las etapasiniciales del desarrollo de software, ya Que dichasetapas son decisinas en la consecuci6n de lacalidad de los sistemas. Gran parte de lainvestigaci6n realizada en este campo se centra enel estudio de atributos estructurales, descuidandolos aspectos dinmico y funcional de lasespecificaciones. Aqui se presenta, adem unmarco de referencia que permite gestionarconjuntamente y de forma sistemdtica diferentesperspectivas de la calidad de los requisitos. Dichomarco se basa en la arquitectura IRDS Quecontempla la definici6n de modelos en diferentesniveles de instanciaci6n. El uso de tales modelosproporciona un contexto para la definici6n deobjetivos, reutilizaci6n de objetos y experiencias,selecci6n de los procesos de medida masadecuados, evaluaci6n y comparaci6n de resultadosy predicci6n. En nuestro caso, podriamos concluirQue el enfoque propuesto proporciona: Un marcopara definir modelos de calidad y objetivosespecificos del proyecto, un mecanismo paraevaluar la calidad en las primeras fases del ciclo devida, soporte para el registro y uso provechoso deexperiencias pasadas y un medio para gestionar laevoluci6n y la consistencia de los cambios

Dimemi6n MedidasCorrecci6n Nl:irnero de conffictos con modelos del

mundo realComplecci6n Nivel de cobertura nmr]ero de reglas de

negocios representadasMinimalidad Ndrnero de representaciones redundantesTmzabilidad Se registran los requisitos y Sus cambios?

Le _Qibilidad Calidad de la docurnentaci6nEvoluci6n ;,,Se docurnenta la evoluci6n def modelo?

QuaTlC`2001 I 211

BibBogra6a

I. Albrecht, A.J., "Measuring application development".Proc" of IBM Applications DevelopmentJointSHARB/GUIDE Symposium Monterey, CA, pp 83-92, 1979.

2- Arthur, J.D. y Stevens, KT. "Assessing theadequacy of documentation through document qualityindicators". Proceedings of the IEEE Conference ofSoftware Maintenance, pp. 40 49, 1989.

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

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

5. Boehrn B.W., Kaspar,J.R. y otros "Characteristics ofSoftware Quality", TRW Series of SoftwareTechnology, 1978.

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

7. Briand, L"C., Daly, J.W. y Wast, ~J.K. "A unifiedframework for coupling measurement in object-oriented system", IEEE Transaction on SoftwareEngineering, 25 (1), 1999.

8. Brykczynskkj , B., "A survey of software inspectionchecklist, ACM Software Engineering Notes, 24(I),pp 82-89, 1999.

9. Chidamber, S.R. y Remoter, C.F., "A Metrics Suitefor Object-Griented Design" ,IEEE Transactions ofSoftware Engineering, 20(6), 476493, 1994.

10.Churcher. N.I. and Shepperd M.J., �TowardsConceptual Framework for Object-Oriented Metrics",ACM Software Engineering Notes 20 (2), 67-76,1995.

II.Cook, A,D., "Confusing Process and Product: Whythe Quality is not There Yet", CrossTalk, July, 1999.

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

13.DeMarco, T., "Controlling Software Projects",Yourdon Press, 1982.

14- Farbey. B., "Software Quality metrics: considerationsabout requirements and requirements specification",Information and Software Technology. 32 (l), pp 6064, 1990.

15.French, J.C., Knight, J.C" y Powell, A.L, �Applyinghipertext structures to software documentation",Information Processing and Management", 33 (2), pp219-231, 1997.

16.Genero, M., Manse, M.E. Piattini, M. y Garcia F.J."Assessing the quality and the Complexity of OMTModels" 2nd European Software MeasurementsConference-FESMA 99, Amsterdam Netherlands, pp99-109, 1999.

17.Genero, M., Piattini, M y Calero C. "Una propuestapara medir la calidad de los diagramas de clases en

UML", IDEAS'2OOO, Cancuu, Mexico, pp 373-384,2000.

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

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

20.150/IEC 10027, "Information TechnologyInformation Resource Dictionary System (IRDS)Framework", ISO/IEC international Standard edition,1990-

21.150/IEC 9126, "Software product evaluationQuality characteristics and guidelines for their use ",1991.

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

23.Lehner, F., "Quality control in softwaredocumentation: Measurement of textcomprehensibility', Information and Management,25, pp 133-146, 1993.

24.Lorenz, M. and Kidd, J., "Object_oriented SoftwareMetrics", Prentice Hall 1994.

25.McCall, J.A., Richards, P.K. and Walters, G.F."Factors in software quality", RADC TR-77-369, USRome Air Development Center Reports NTIS AD/A-049 014 015, 055, 1977.

26.Moreno. M.N., Polo, M.J., Miguel, LA. y Garcia,F.J. "Urn sistema de meta-base de datos basado enUML e integrado en un sistema de gesti6n de basesde datos distribuidas." En Jornadas de Ingenien.a delSoftware y bases de datos, Caceres, Espafja 1999.

27.Nissen, H.W., and Jarke, M., "Repository support formulti-perspective requirements engineering".Informadon System Vol. 24, No. 2, pp 131-1581999.

28.Offen, R.J. y Jeffery, R., "Establishing softwaremeasurements programs", IEEE Software, 14 (2), pp45-53, 1997.

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

30.Poels, G., "Towards a size measurement frameworkfor objectoriented especifications". H Coombes, M.MOOR van Huysduynen, and B. Peelers (eds.),Proceedings of the Ist European SoftwareMeasurement Conference (I:;ESMA'98), Antwerp,pp. 379-388, 1998.

31.Peels, G., "On the measurements of event-basedobjectoriented conceptual models". 4th InternationalECOOP Workshop on Quantitative Approaches inObject Oriented Software Engineering, Cannes,France, 2000.

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

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

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

212 / QuaTIC'2OOI

specification", Software Engineering Journal, 5(1),

}990.35.SPICE, "SPICE cument Suite, Soe Process

Improvement and Capahili determination",htt J" /w.su.edu.au/s ice/ , 1999.

QuaTIC"2OOI / 213