=Paper=
{{Paper
|id=Vol-1284/paper25
|storemode=property
|title=Marco de Referencia para la Gestión de la Calidad de las Especificaciones de Requisitos
|pdfUrl=https://ceur-ws.org/Vol-1284/paper25.pdf
|volume=Vol-1284
|dblpUrl=https://dblp.org/rec/conf/quatic/GarciaPMBA01
}}
==Marco de Referencia para la Gestión de la Calidad de las Especificaciones de Requisitos==
https://ceur-ws.org/Vol-1284/paper25.pdf
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, Vivian
L6pez 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
Resnmen capacidaden funci6n del grado de cumplimiento
El presente trabajose enmarca,dentro del campo de esos principios-Sin embargo, dichos modelos
de la medici6n del software, en el dmbito de la no sirven de referencia para eva2uarla calidad de2
especificaci6n de requisitos-La mayor parte de la software producidoa lo largo del ciclo de Vidaya
investigaci6n realizada en esta parcela de la calidad que, desafortunadamente,organizacionesque
se centra en el estudio de atributosestructurales, cumplen los requisitos CMM no estan produciendo
que Casisiempre se evalOanen lases finales del software de calidad [11]. Otrosmodelos incluyen
desarrollo, descuidando otras perspectivasdel m6tricasparaevaluar de forma cuantitativael
modelado de sistemas. Por otraparte, son muy grado de calidad de diferentes atributosdel
650 8505 los estudios existentes sobre la producto(FCM, GQM-..) [25] [3]. Aunque la
interre2aci6nde diferentesm6todos y aspectos de medici6n deberia poderse aplicara productos de
medida y sobre la formalizaci6nde dicho proceso cualquiernivel, no siempre Se pueden realizer
cuando se realiza al cornienzo del ciclo de Vida.En medidas de las caracterfsticasde calidad de las
este artfculose analiza el papel que juegan las especificaciones debido a la ausencia de m6tricas
mediciones iniciales en la deterrninaci6ny especificas o a la indeterrninaci6nde las mismas.
predicci6n de las caracteristicasde calidad del El desarrollode metodos de medida en el dmbito
software y se propone un rnarcode referenciaque de los requisitos del software esta centrado
permite forrnalizary automatizarel proceso de fundamentalmenteen la medici6n del tamaho y la
medici6n y gestionar la calidad considerando funcionalidaddel software.
diferentesperspectives de modelado.
Caracteriisticasde la ERS Problernas de medld6n
Abstracci6n Dificultad de medici6n directa de
Introducd6n los atributosde calidad
Evoluci6n Necesidad de reflejar los cambios
Es un hecho ampliamenteaceptado Quelas y asegurarla consistencia
Transformaci6n Evaluaci6n de la trazabilidad
primeras etapas del desarrollode software son
Diferentes perspectives de Gesti6n conjunta de mnltiples
cruciales en la consecuci6n de productos de calidad mode2ado notaciones de mode/ado
dentro de los }finites de tiempo y coste establecidos
para un proyecto. En este contexto, la medici6n del
software esni adquiriendocada vez mayor Tabla 1. Caracteristicasde las ERS
importancia,debido a la necesidad de obtenerdatos
objetivos que contribuyana mejorarla calidad. La dificultaden la medici6n de la ERS
Muchos investigadores banproducidomodelos de (Especificaci6n de Requisitos del Software) se
caracteristicasde calidad del software que pueden debe fundamentalmentea algunascaracteristicas
ser dtiles para discutir,planifxcary obtenerindices inherentesa las propias especificaciones (Tabla I).
de calidad de los productos de software-Los El problems principal radica en el alto nine} de
modelos de calidad rfuiisrecientes(CMM [291, abstracci6nen el que se encuentran,lo que hace
SPICE [33] [35]), estan orientadosa la mejora de muy dificil definir y medir de forma directay
procesos mediante la definici6n de princiPios y objetiva atributosde calidad. A esta dificultad
practices que conducen a mejores productos de habrfaque a6adirla derivadadel hecho de que los
software y la deterrninaci6nde la rnadurezde la requisitos evolucionan a medida que progresael
QuaTIC2001 / 207
desarrollo, esa inestabilidad e incluso volatilidad facilidad de comprensi6n del texto contenido en los
de los requisitos requiere un proceso sister)[:uiticode documentos [23] o m6tricas de estrnctura y
obtenci6n y almacenamiento de los datos, en el Que organizaci6n en documentos convencionales (2] y
Seasegure la consistencia de las cambios en 108 con hipertexto [15] [32]. Otras t6cnicas, como las
resultados obtenidos y que permita realizar propuestas por Davis y colaboradores [12] o el uso
estudios comparativos sobre dicha evoluci6n. Gtro de listas de comprobaci6n [8] (14], realizan la
tipo de evoluci6n sufrida por los requisitos, que valoraci6n de 2osatributos de calidad de la
repercute igualmente en la dificultad de medici6n especificaci6n mediante m6tricas que requieren
es la trasformaci6n que sufren los modelos al ir informaci6n procedente de revisiones t6cnicas,
descendiendo en el nivel de abstracci6n (los inspecciones, Walkthrough, o auditorias
modelos de anlisis se transforman en modelos de encaminadas a determiner el cumplirniento de los
diseho, etc.), esto conlleva la necesidad de estar1dares,directrices, espacific&clonesy
examiner los enlaces de trazabilidad, con lo Que procedimientos. Los resultados obtenidos en este
entrarfan en juego, no s6lo elementos de modelado tipo de evaluaciones tienen un alto componente
del nine} de amIilisissino tambi6n de nine} de subjetivo y son claramente dependientes de las
diseBo. For otra parte, el uso de diferentes m6todos personas Que los realizan aun fijando previamente
de especificaci6n con notaciones diferentes, o el criterios objetivos.
uso de m6todos y lenguajes actuates que permiten La creciente adopci6n de la tecnologia de
el model&do de los requisitos del sistema desde orientaci6n a objetos en el desarrollo de software
multiples perspectivas, exige la definici6n y ha dado Ingar a la aparici6n de nuevas m6trices
aplicaci6n de diferentes m6tricas especificas para especificas para este tipo de sistemas. Como mds
cada notaci6n, si se desea realizer nna valoraci6n representativas se pueden citar las m6tricas de
completa de la calidad de dicflas especificacianes. disebo {9},m6tricas orientadas a clases [24}.
En este trabajo se propone una arquitectura para la m6tricas orientadas a operaciones [10] o las
gesti6n de la calidad de la ERS que contribuye a m6tricas para prnebas [4]. Recientemente Se ban
so}ventar los problernas comentados anteriormente. propuesto metricas para la evaluaci6n de la ca2idad
Dicha arquitectura permite: a partir de modelos praducidos en etapas iniciales
del ciclo de Vida, coma son las m6tricas de calidad
Gestionar conjuntarnente la calidad de y complejidad en modelos OMT [16] o las metricas
diferentes perspectivas de modelado de calidad de los diagramas de clases en UM:L [17]
Forrnular directamente objetivos de calidad mediante las cuales se eval la complejidad
y planes de medida introducida por las jerarquias de generalizaci6n en
Proporcionar Una base para la los diagramas de clases obtenidos en las etapas de
automatizaci6n de las medidas amilisis y discho. Asimismo ban surgido intentos
Mantener registros de informaci6n hist6rica de realizar evaluaciones de la calidad a partir de
Proporcionar soporte para estudios modelos dindmicos, tal es el caso del trabajo de
emplricos y construcci6n de modelos Poels en el que se realiza la medici6n de modelos
predictivos conceptuales basados en eventos [31].
Del anaZisisde la bibliografia resehada se puede
Trabajos relacionados
concluir que las m6tricas de calidad para sisternas
orientados a objetos Se caracterizan por estar
La mayoria de los trabajos relacionados con la centradas principalmente en el disedo y rruiS
medici6n en el nivel de la especificaci6n de concretamente en el modelado estructural o
reQuisitos Se ban centrado fundamentalmente en el estatico, liminiindosednicamente a evaluar la
desarrollo de metricas para determinat el tarn&Boy complejidad, reusabilidad, acoplamiento o
la fnncionalidad del software. Butte las de mayor cohesi6n, sin tenet en cuenta otros atribntos de
difusi6n se encuentran las metricas de puntos de calidad que deben exhibir las especificaciones de
funci6n [LI, m6tricas Bang [13} o las puntos requisitos del software.
objeto [SJ. For otra parte, la necesidad de medir diferentes
La medici6n de atributos de calidad de las aspectos del software y la proliferaci6n de m6tricas
especificaciones ha sido objeto de algnnos trabajos surgidas debido a la creciente importancia que esta
que van desde la medici6n de especificaciones adquiriendo la medici6n estd contribuyendo a crear
formates [34] hasta la aplicaci6n de m6tricas para confusi6n sobre las relaciones entre tales medidas,
evaluar la calidad de especificaciones expresadas asf como sobre su forrna y dmbito de aplicaci6n.
inforrnalmente en lenguaje natural. En este dldmo Este hecho ha conducido la bdsqueda de nuevos
dmbito pueden utilizarse algunas metricas de caminos en la investigaci6n que se orientan hacia
calidad de la documentaci6n como las m6tricas de
la propuestade modelos y marcos de referencia un meta-metamodelopara definirla sintaxis y la
("framewors")que permitanla organizaci6nde las semdnticadel metamodelo (por ejemplo, grafo y
medidas y la clasificaci6n de las entidades de teoria de conjuntos). Unajerarquiade cuatro
software a trav6s de un conjunto de dimensiones niveles similar es la base del formato esnindarde
que Se usan paraidentificar sistemas, modelos, intercambiode datos de CASE para el
atributosy objetos susceptibles de medir [30] [7]. "ime'rworking"de herramientasCASE [191.
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.
Los modelos son necesarios, entre otras cosas, para
minimizar la complejidady relatividad inherentes
al concepto "calidad del software",manejar
Moc!eI,o Medlda ~ Moc!elo, diferentes perspectivasde modelado, gestionar la
, emp Ico ~~nu.rulerlco ~ enoluci6n y asegurarla consistencia de los
cambios. Trasladandolas ideas anteriores al mbito
de la especificaci6n de requisitos se puede
j Comprensi6n/ |Matemdticas/ construiruna arquitecturade gesti6n de calidad que
~refinamiento , estadistica
sirva de marco para conseguir los objetivos que Se
,.,~ ban apuntadoen la introducci6n.
Rosult do InterPretacl6n Resul.tad. o
emplnco numerlco Marco de referencia para la ges66n de
calidad
Figura 1. Modelos implicados en el proceso de En este apartadose propone un patr6nde
medida arquitecturade gesti6n de calidad de la
especificaci6n de requisitos que separa y enlaza los
Las interrelacionesesenciales entrelos modelos aspectos referentes a diferentesperspectivas de
num6rico y empirico subyacentes en el proceso de modelado.
medida requiere un marco de unificaci6n,o un La definici6n de m6trices en el arnbito de la ERS
metamodelo, pararazonar sobre dichos modelos y es claramentedependiente del m6todo, lenguaje o
Sus interrelaciones.La figura 2 ilustraunajerarquia notaci6n de modelado que Se utilice en la
gen6rica de modelos. Cualquiermodelo empirico especificaci6n por lo que puede hacerse uso de
de medida reJacionadocon el software Se puede metamodelos paradefinir dichas m6tricas y
considerar construido a partirde fragmentos de establecerrelaciones entre ellas (por ejemplo
producto y/o de proceso (submodelos) i,j,k. El establecimientode conexiones entre la perspectiva
modelo num6ricoformal correspondienteSe estructural,din;irnicay funcional en la
represents por el modelo y los fragmentos del especificaci6n de requisitos de sistemas orientados
modelo. Si se tiene que razonarsobre la efectividad a objetos). Ademas, dichos modelos pueden servir
y evoluci6n de los modelos de medida, Se puede de base para la aplicaci6n autor0uiticade dichas
definir un metamodelo para construirde forma m6tricas,mediante la combinaci6n herrarnientas
razonada y modificar los modelos de medida autormiticasde modelado con un repositorio en el
empiricos y Burn6Ficos.Sin embargo, esto requiere que Se almacene y gestione informaci6n de
QuaTIC 2001 / 209
'B" Figure 4. Estructurade referencia ISO [ROS (Information Resource Dictionary System)
,-~~~
incluso predicci6nde la calidad Se puede
simplificary sistematizarmediante un repositorio
que almacenemetadatos sobre las especificaciones
y su evoluci6n~El principal objetino de este
' -~ enfoque consiste en definirun esquema de
metabase de datosQuepueda capturary enlazar
todos los aspectos relevantes de la Bastionde
calidad.
diferentesniveles de instanciaci6n(figura 3). Un SeguidarnenteSe clasiflcan algunas de las
repositorio de estas caracterfsticasperrnitea su vez dimensiones relevantes de calidad de la
mantenerun registro hist6rico de los resultados especiflcaci6n de requisitos y Se dan ejemplos de
obtenidos en el proceso de medida Quepuede servir tipos de medidas Quepodrfan ayudar a establecerla
de referenciapara la realizaci6n de estudios calidad de un componente particularcon respecto a
comparativossobre la validez de las m6tricas o la una particulardimensi6n de la calidad [22]. Esta
repercusi6nde deterrninadoscambios y para la estructurabdsics puede ser capturadaforrnalmente
construcci6n de modelos predictivos. en una extensi6n del enfoque GQM e
implementaday usadaen una metabase de datos.
La satisfacci6n de los atributosde calidad Quese
Figure 3. Arquitectura de gesti6n de calidad muestran en la tabla 2 conducen a la consecuci6n
de las dimensiones de calidad establecidas en la
El primeraspecto Quehay Queconsiderares la norrnaISO 9126 {211(fiabilidad, funcionalidad,
transformaci6ndel concepto abstractode calidad eficiencia, portabilidad,facilidad de uso y facilidad
en una serie de objetivos concretos de calidad que de mantenimiento),la mayoria de las cuales 5610
Se corresponderancon las aspiraciones de los pueden evaluarseen fases pr6ximas a la
diferentesgrupos de "Stakeholders".Parafijar implementaci6n.For ejemplo, las dimensiones de
dichos objetivos Se puede haceruso de modelos de correcci6ny complecci6n conducen a mejorarla
calidad descritosen la bibliograffa.Podriarnos funcionalidaddel sistenla y dimensiones como
adapterel enfoque GQM [3] con el fin de enlazar trazabilidady legibilidad repercuten en la facilidad
los objetivos conceptuales con t6cnicas especificas de uso y de rnantenimiento~
de medici6n. La sisternatizaci6ndelproceso cornienza con una
For otraparte, hay que tener en cuenta que la adaptaci6nde la propuestade formalizaci6n de la
consecuci6n de los objetivos de calidadconlleva la gesti6n de calidadpara datos de Jarke y
realizaci6n de medidas de muy diversa naturaleza, colaboradcres[22] basada en un analisis cualitativo
la mayorfade las cuales no pueden realizarse de las relacionesentre los factores de calidad (ej.
directamentesobre atributosconcretos, sino que Objetivo-subobjetivo,objetivosignificado...). Los
requierentecnicas complejas demedici6n. Estos stakeholderspueden realizarla evaluaci6n
problernasSe agravancuando se intents evaluar la subjetivade Suspropios objetivos y de su
calidad de las especificaciones de requisitos debido importanciarelativa. Dichas evaluaciones, junto
a las caracteristicasinherentesa la mismas Que con las calculadas,se usan como medidas de
dificultanla definici6n y aplicaci6n de m6tricas, calidad en el modelo de arquitectura.Esto facilita
como se coment6 en el apartadode introducci6n. una simple integraci6n del modelo de calidady
El disefio y aplicaci6n de t6cnicas de valoraci6ne arquitectura.Este enfoque se usa ampliamente en
210 / QuaTIC'2001
la ingenieriaindustrial bajo la etiqueta de "Qua/ity 105 prograrnasde medida, la elecci6n de m6tricasy
Function Deployment" metodos de andlisis,la utilizaci6n constructivade
experienciaspasadas, la definici6n de planes de
Dimemi6n Medidas medida y la estructuraci6nde informes. Pueden
Correcci6n Nl:irnerode conffictos con modelos del tambi6n proporcionarsoporte para definiry
mundo real gestionar estudios empiricos paraconstruir
Complecci6n Nivel de cobertura nmr]erode reglas de modelos predictivos (estimaci6n).Debido a Quese
negocios representadas pueden capturertodos los aspectos del proceso de
Minimalidad Ndrnerode representacionesredundantes medida, esta arquitecturafacilita el
Tmzabilidad Se registran los requisitos y Suscambios? empaquetarnientoy utilizaci6n de experiencias
Le _Qibilidad Calidad de la docurnentaci6n capturadasduranteel uso de la herramientajunto
Evoluci6n ;,,Sedocurnentala evoluci6n def modelo? con un conjunto de software convencional. La
figura 3 muestra un esquema de la forma de
Tabla 2. Dimensiones de la calidad de las ERS implementaci6n de la arquitectura
propuesta.Conclusiones
La arquitectura propuesta se basa en el estdar
ISO Information Resources Dictionary System Con este trabajo se ha pretendido, en primerlugar,
(IRDS) [2O}que propone la organizaci6n de la suscitar el inter6spor la medici6n en las etapas
inforrnaci6n en cuatro niveles de instanciaci6n iniciales del desarrollo de software, ya Quedichas
(figura 4); nive/ de z.nstanciasy escenarios etapas son decisinas en la consecuci6n de la
(contiene objetos Que no pueden tener instancias: calidad de los sistemas. Granpartede la
datos, estados, resultados de las mediciones...), investigaci6n realizada en este campo se centraen
nz.ve/de modelos (clases Que definen las el estudio de atributosestructurales,descuidando
propiedades de los objetos del nivel de instancias y los aspectos dinmico y funcional de las
las reglas de manipulaci6n de los mismos), nive/ de especificaciones. Aqui se presenta,adem un
lenguajes de modelado (metaclases Que definen la marco de referenciaque permite gestionar
estructura de las clases del nivel del modelo) y conjuntamentey de forma sistemdticadiferentes
nivel de meta metamodelo (meta metaclases con perspectivasde la calidad de los requisitos. Dicho
instancias en el nivel anterior. Es posible la marco se basa en la arquitecturaIRDS Que
definici6n de mtiltiples lenguajes de modelado contempla la definici6n de modelos en diferentes
mediante la apropiada instanciaci6n). Esas cuatro niveles de instanciaci6n.El uso de tales modelos
capas Se agrupan en tres pares de niveles proporcionaun contexto parala definici6n de
entrelazados: entorno de use, entorno de objetivos, reutilizaci6nde objetos y experiencias,
modelado conceptual y entorno de z.ngenieriade selecci6n de los procesos de medida mas
mados [27]. adecuados, evaluaci6n y comparaci6n de resultados
La gesti6n conjunta de todos los niveles del y predicci6n. En nuestro caso, podriamos concluir
repositorio cornpartido hace posible soportar la Queel enfoque propuestoproporciona:Un marco
coevoluci6n requerida de los modelos, paradefinirmodelos de calidad y objetivos
metarnodelos e incluso meta metamodelos especificos del proyecto, un mecanismo para
(mode)Os M2) Que permiten realizar abstracciones evaluarla calidad en las primerasfases del ciclo de
de los lenguajes de modelado, y por tanto, definir vida, soporte para el registro y uso provechoso de
metainformaci6n sobre m6tricas adecuadas a las experiencias pasadasy unmedio paragestionar la
notaciones que soportan dichos lenguajes. Los evoluci6n y la consistencia de los cambios
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
QuaTlC`2001 I 211
BibBogra6a UML", IDEAS'2OOO,Cancuu, Mexico, pp 373-384,
2000.
I. Albrecht, A.J., "Measuringapplicationdevelopment". 18.Cub, T. "Principles of software engineering
management",Addison-Wesley, 1988.
Proc" of IBM Applications DevelopmentJoint
SHARB/GUIDE Symposium Monterey, CA, pp 83- 19-Imber, M. "CASE"44tt Interchange format standars",
92, 1979. Information and Software Technology, Nov~ 2991,
pp. 647-655
2- Arthur, J.D. y Stevens, KT. "Assessing the
adequacyof documentationthrough documentquality 20.150/IEC 10027, "Information Technology
indicators". Proceedings of the IEEE Conference of Information Resource Dictionary System (IRDS)
Software Maintenance,pp. 4049, 1989. Framework",ISO/IEC internationalStandardedition,
1990-
3. Basili, V.R. y Rombach,H.D., "The TAME Project:
21.150/IEC 9126, "Software product evaluation
Towards Improvement-Oriented Software
Environments", IEEE Transaction on Software Qualitycharacteristicsand guidelines for their use ",
1991.
Engineering,14(6), 758-73 1988.
4. Binder, R., "Testing Object-Oriented Systems", 22.Jarke, M-, Jeusfeld, M.A., Quix, C. y Vassiliadis, P.
AmericanProgrammer,7(4), 22-29, 1994. "Architectureand quality in data warehouses: and
5. Boehrn B.W., Kaspar,J.R. y otros "Characteristicsof Extended Repository Approach", Information
Software Quality", TRW Series of Software System 24(3). pp 229-253, 1999~
Technology, 1978. 23.Lehner, F., "Quality control in software
6. Boehrn B.W., Clark, B., Horowitz, E. et al., "Cost documentation: Measurement of text
comprehensibility', Information and Management,
Models for future life cycle processes: COCOMO
25, pp 133-146, 1993.
2.0", Annals of Software Engineering 1(1), pp 1-24,
1995. 24.Lorenz, M. and Kidd, J., "Object_orientedSoftware
7. Briand, L"C., Daly, J.W. y Wast, ~J.K. "A unified Metrics",PrenticeHall 1994.
framework for coupling measurement in object- 25.McCall, J.A., Richards, P.K. and Walters, G.F.
oriented system", IEEE Transaction on Software "Factorsin softwarequality", RADC TR-77-369, US
Engineering,25 (1), 1999. Rome Air Development Center Reports NTIS AD/A-
049 014 015, 055, 1977.
8. Brykczynskkj, B., "A survey of software inspection
checklist, ACM Software Engineering Notes, 24(I), 26.Moreno. M.N., Polo, M.J., Miguel, LA. y Garcia,
pp 82-89, 1999. F.J. "Urnsistema de meta-base de datos basado en
9. Chidamber,S.R. y Remoter, C.F., "A Metrics Suite UML e integrado en un sistema de gesti6n de bases
de datos distribuidas."En Jornadas de Ingenien.a del
for Object-Griented Design" ,IEEE Transactions of
SoftwareEngineering, 20(6), 476493, 1994. Softwarey bases de datos, Caceres, Espafja 1999.
10.Churcher. N.I. and Shepperd M.J., Towards 27.Nissen, H.W., and Jarke, M., "Repositorysupport for
multi-perspective requirements engineering".
Conceptual Frameworkfor Object-OrientedMetrics",
ACM Software Engineering Notes 20 (2), 67-76, Informadon System Vol. 24, No. 2, pp 131-158
1999.
1995.
II.Cook, A,D., "Confusing Process and Product: Why 28.Offen, R.J. y Jeffery, R., "Establishing software
the Qualityis not ThereYet", CrossTalk,July, 1999. measurements programs",IEEE Software, 14 (2), pp
12.Davis, A. et al., "Identifying and Measuring Quality 45-53, 1997.
in a Software Requirements Specification" 29.Paulk, M. Curtis, B., Chrissis, M , and Weber, C.
Proceedings of the First International Software "Capability Maturity Model for Software: Version
Metrics Symposiurn Baltimore, May 21-22, pp. 141- 1.1" Technical Report SEI-93-TR..24, Software
252, 1993. Engineering 2nstitute, Carnegie Mellon University,
13.DeMarco, T., "Controlling Software Projects", Pittsburgh,Pennsylvania USA, 1993.
Yourdon Press, 1982. 30.Poels, G., "Towardsa size measurement framework
14-Farbey. B., "Software Quality metrics: considerations for objectoriented especifications". H Coombes, M.
about requirements and requirements specification", MOORvan Huysduynen, and B. Peelers (eds.),
Informationand Software Technology. 32 (l), pp 60 Proceedings of the Ist European Software
64, 1990. MeasurementConference (I:;ESMA'98),Antwerp,
pp. 379-388, 1998.
15.French, J.C., Knight, J.C"y Powell, A.L, Applying
hipertext structures to software documentation", 31.Peels, G., "On the measurements of event-based
InformationProcessing and Management",33 (2), pp objectoriented conceptual models". 4th International
219-231, 1997. ECOOP Workshop on Quantitative Approaches in
16.Genero, M., Manse, M.E. Piattini, M. y Garcia F.J. Object Oriented Software Engineering, Cannes,
France,2000.
"Assessing the quality and the Complexity of OMT
Models" 2nd European Software Measurements 32.Roth, T., Aiken, P. y Hobbs, S., "Hypermediasupport
Conference-FESMA 99, Amsterdam Netherlands,pp for software developmemt: a retrospective
99-109, 1999. assessment",Hypermedia 6 (3), pp 149-173, 1994.
17.Genero, M., Piattini, M y Calero C. "Una propuesta 33.Rout, T.P- "Software process improvement and
para medir la calidad de los diagramas de clases en 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
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