P. 1
Calidad en Sistemas Informaticos

Calidad en Sistemas Informaticos

|Views: 6.613|Likes:
Publicado porangie_villa_2

More info:

Published by: angie_villa_2 on Jun 05, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/14/2015

pdf

text

original

alidad I

alidad de istemas I for aile s
Mario G. Piattini Velthuis Felix O. Garda Rubio Ismael Caballero Munoz-Reja

Alfaomega

Datos catalograficos Piattini, Mario; Garcia, FelLx y Caballero, Ismael Calidad de Sistemas Informaticos Primera Edici6n Alfaomega Grupo Editor, S.A. de Formato: 17 x 23 cm Calidad de Sistemas Infol'maticos yiario G. Piattini Velthuis. Felix O. Garcia Rubio, Ismael Caballero Munoz-Reja ISBN: 84-7897-734-1, cdici6n original public ada por RA-MA Editorial, Madrid, Espana Derechos reser\'ados © RA-MA Editorial Primcra edici6n: Alfaomcga Grupo Editor, Mexico, mayo 2007
© 2007 Alfaomega Grupo Editor, S.A. de C.V. Pit~igoras 1139. Col. Del Valle. 03100. yiexico D.F.

c.v., Mexico
Paginas: 416

ISBN: 978-970-15-1267-8

ylicrnbro de la Camara Nacional de la Industria Editorial Mexicana Registro No. 2317 pag. Web: http://www.alfaomega.com.mx E-mail: libl.el.iapitagol.as@alfaomega.com.mx ISBN: 978-970·15·1267·8 Del'echos I'esenados: La infoI111aci6n contenida en est a obra tiene un fin exclusi\'amente didactico y, por 10 tanto, no esta pre\'isto su apro\'echamiento a nivel profesional 0 industrial. Las indicaciones tecnicas y programas incluidos, han sido elaborados con gran cuidado por el autor y reproducidos bajo estrictas nOI1l1as de control. .-\LF.-\O?\IEGA GRUPO EDITOR, S.A. de c.v. no sera juridicamente responsable por: en'ores u omisiones; daii.os y perjuicios que se pudieran atribuir a1 uso de la inf0l111aci6n comprendida en este libro. ni por la utilizaci6n indebida que pudiera darsele. Edici6n autOJizada para \'enta en Mexico y todo el continente americano. Impl'eso en Mexico. Printed in Mexico.

Empresas del grupo:
;\lexico: Alfaomega Grupo Editor. S.A. de C. V. - Pitagoras 1139. Col. Del Valle. Mexico. D.E Tel.: (52-55) 5089-7740 - Fax: (52-55) 5575-2420/2490. Sin costo: 01-800-020-4396 E-mail: \.entas1@Alfaomega.com.mx Colombia: .-\Ifaom"ga Colombiana S ..-\. - Canera 15 No. 64 A 29 Fax: (57-1 ) 6068648 - E-mail: scliente@alfaornega.com.co PBX (57-I) 2100[22

c.P. 03100.

Chile: Alfaomega Grupo Editor. S.A. - Dr. Manuel Barros BorgoDo 21 Pro\'idencia. Santiago. Chile Tel.: (56-2) 235-4248 - Fax: (56-2) 235-5786 - E-mail: agechile@a[faomega.cl Argentina: Alfaomega Grupo Editor Argentino. S.A. - Paraguay 1307 P.B. "II". Capital Federal. Buenos Aires. c.P. [057 - Tel.: (54- [[) 4811-7183 /8352, E-mail: agea@fibertel.com.ar

A Emilio del Peso, IIlla de las personas con mayor calidad hllmana y pro/esional que he tellido la sllerte de conocer.

Mario Piattini

A mis padres, Felix y Tina, y a mis hermanas. Alayte y Miriam. por Sll siempre incolldicional apoyo y por la alegria y los (lI1imos qlle me transmiten cada dia.

Felix Garcia

A inlllQ y a mis padres, por rada Sll apoyo, Sll paciencia, Sl/ comprension y Sli cariiio.

Ismael Caballero

INDICE
AUTORES ......................................................................................................................... XV PROLOGO ..................................................................................................................... XVII PREFACIO ..................................................................................................................... XIX

P ARTEI: INTRODUCCION A LA CALIDAD ..................................... 1
CAPITULO 1. CONCEPTO DE CALIDAD ................................................................... 3 1. DEFINICION DE CALIDAD ........................................................................................... 3 2. EVOLUCION HISTORICA DE LA CALIDAD ............................................................. 9 3. CONCEPTOS RELACIONADOS CON LA CALIDAD ............................................. 12 3.1. Conceptos relacionados con la gesti6n de la calidad ........................................ 13 3.2. Conceptos relacionados con la docul11entaci6n de la calidad ........................... 14 4. LECTURAS RECOMENDADAS .................................................................................. 14 5. SITIOS WEB RECOMENDADOS ................................................................................ 15 6. EJERCICIOS ........................................................ ~ ........................................................... 15 CAPITULO 2. TECNICAS Y HERRAlVIIENTAS DE CALIDAD ............................ 17 1. INTRODUCCION ........................................................................................................... 17 2. HERRAMIENTAS BAsICAS DE CALIDAD .............................................................. 18 2.1. Diagran1a de flujo ............................................................................................... 18 2.2. Diagrat11a causa-efecto ....................................................................................... 19 2.3. Diagran1a de Pareto ............................................................................................ 21 2.4. Hoja de chequeo 0 de c0l11probaci6n ................................................................. 22 2.5. Grafo 0 Diagral11a de control ............................................................................. 23 2.5.1. Tipos de diagral11a de control... ............................................................ 24

VIII

CAUDAD DE SISTElvLA.S INFO~'vL-\ TICOS

2.6. Histogran1a .......................................................................................................... 28 2.7. Diagrama de Dispersion 0 de Correlacion ........................................................ 29 3. HERRAMIENTAS DE GESTION ................................................................................. 30 3.1. Diagralna de afinidad ......................................................................................... 30 3.2. Diagrmna de relaciones ...................................................................................... 31 3.3. Diagrama de matriz 0 matricial... ....................................................................... 32 3.4. MatJiz de amilisis de datos ................................................................................. 33 3.5. Diagrama de redes de actividad 0 de flechas .................................................... 33 3.6. Diagrmna de arbol .............................................................................................. 33 3.7. Diagrama de proceso de decisiones ................................................................... 33 4. HERRAMIENTAS DE CREATIVIDAD ...................................................................... 34 5. HERRAMIENTAS ESTADISTICAS ............................................................................ 35 5.1. Control estadfstico del proceso .......................................................................... 35 5.1.1. indices de Capacidad Cp, P p, CPK Y PpK ............................................... 36 5.1.2. indices de Capacidad CPU, PPU, CPL, PPL ...................................... 37 5.2. Diseiio de expeIilnentos ..................................................................................... 37 6. HERRAMIENTAS DE DISENO .................................................................................... 38 6.1. QFD (Quality Function Deployment) ............................................................... 38 6.2. M1FE (Analisis Modal de Fallos y Efectos) .................................................... 39 7. HERRAMIENTAS DE MEDICION .............................................................................. 43 7.1. COQ (coste de la calidad) ................................................................................. .43 7.2. Benchmarking ..................................................................................................... 43 7.3. Encuestas ............................................................................................................. 44 8. NIVELES DE MADUREZ .............................................................................................. 45 9. LECTURAS RECOMENDADAS .................................................................................. 46 10. SITIOS WEB RECOTvIENDADOS ............................................................................. .46 11. EJERCICIOS .................................................................................................................. 46 CAPITULO 3. MODELOS Y NORMAS DE CALIDAD ............................................ 49

1. INTRODUCCION ........................................................................................................... 49 2. GESTION DE LA CAUDAD TOTAL .................. ,...................................................... .49 3. NORMAS ISO 9000 ........................................................................................................ 50 3.1. ISO y el proceso de norrnalizacion .................................................................... 50 3.2. Norrnas sobre calidad ......................................................................................... 53 3.3. Nonna ISO 9001 ................................................................................................. 56 3.3.1. Sistema de gestion de la calidad .......................................................... 58 3.3.2. Responsabilidad de la direccion ........................................................... 58 3.3.3. Gestion de los recursos ......................................................................... 58 3.3.4. Realizacion del producto ...................................................................... 59 3.3.5. Medicion, analisis y mejora ................................................................. 61 4. MODELO EFQM ............................................................................................................. 62 4.1. Vision general ..................................................................................................... 62

~

RA-MA

iNDlCE

IX

4.2. Critelios del modelo ........................................................................................... 63 4.2.1. Liderazgo .............................................................................................. 63 4.2.2. Politic a y estrategia ............................................................................... 64 4.2.3. Personas ................................................................................................ 64 4.2.4. Alianzas y recursos ............................................................................... 65 4.2.5. Procesos ................................................................................................ 65 4.2.6. Clientes .................................................................................................. 66 4.2.7. Resultados en las personas ................................................................... 66 4.2.8. Resultados en la sociedad ..................................................................... 66 4.2.9. Resultados clave de desempefio ........................................................... 66 5. CAF: MARCO COMUN DE EVALUACION .............................................................. 66 6. SEIS-SIGI\1A .................................................................................................................... 67 7. PREMIOS ......................................................................................................................... 68 8. LECTURAS RECOMENDADAS .................................................................................. 70 9. SITIOS \VEB RECOMEl\TJ)ADOS ................................................................................ 70 10. EJERCICIOS .................................................................................................................. 71

PARTE II: CALIDAD DE SISTEMAS INFORl'1A. TICOS ............... 73
CAPITULO 4. CALIDAD DE SISTEMAS DE INFORiVIACION ............................. 75
1. 2. 3. 4. 5. 6. SITUACION DE LA CAUDAD DE SI... ...................................................................... 75 IMPORT Al'-JCIA DE LA CAUDAD EN LOS SI ......................................................... 76 COMPONENTES DE LA CAUDAD ........................................................................... 77 LECTURAS RECOMENDADAS .................................................................................. 79 SITIOS \VEB RECOMENTIADOS ................................................................................ 79 EJERCICIOS ..................................................................................................................... 79

CAPITULO 5: CALIDAD DE PRODUCTO SOFTWARE ........................................ 81
1. MODELOS CLAsICOS .......................................: .......................................................... 81 2. NORMAS ISO 25000 ...................................................................................................... 83 2.1. Aspectos de la calidad de un producto software ............................................... 84 2.2. Modelo de calidad interna y externa .................................................................. 85 2.2.1. Funcionalidad ....................................................................................... 85 2.2.2. Fiabilidad .............................................................................................. 86 2.2.3. Usabilidad ............................................................................................. 86 2.2.4. Eficiencia .............................................................................................. 87 2.2.5. Mantenibilidad ...................................................................................... 87 2.2.6. Portabilidad ........................................................................................... 88

.. 100 3...............................................3..... 108 3..... Modelo de calidad en uso ................................... 121 4..... 95 CAPiTULO 6.................. 139 6......................................3................................................................................................ 2................................ 92 EJERCICIOS ............... EL PROCESO SOFTWARE ..............................................2.........7....... Productividad .......3......... 91 LECTURAS RECOMENDADAS .... 88 2........... 88 2.............1...................................... 107 3.................3..3.........3................................................3................. Clasificaci6n de los PSEE ............ Elementos del Proceso Software ..........304.........3. 103 3..................... 5....... Modelado de procesos: Diagramas de Gantt y Diagramas PERT .....................................8............. 136 5............. Seguridad de uso ....10.......................2.................................... 89 2... SPADE ................................ INTRODUCCION ....................................... SPEM ..................... 130 4.......................... Clasificaci6n de los Lenguajes de Modelado de Procesos (LMP) ................. 4............ 89 204........... 116 3.........................3.... 109 3................ 6............... 112 3.............. Arquitectura de Sistemas de Infonnaci6n Integrados (ARIS) . PROMENADE ......................................................... 97 1.......2...................3...................................................................1................ EJERCICIOS .. 106 3.........................................9............. Core Plan Representation (CPR) .. Evaluaci6n de un producto software ..........1.........................2............ IO2 3...................... 89 TRABAJOS BASAD OS EN LAS NORMA ISO 9126 E ISO 14598 ............ 126 4...............3.................. Ejemplos de PSEE .......................... SMSDM .... GESTION DE LOS PROCESOS SOFTWARE ...................... Serendipity ................. 140 ..................... Modelo del Proceso Unificado ....................3................... APEL ...........3..........................................................3 A.X CAUDAD DE SISTEMAS 1N1'ORl'viATICOS © RA-ivL"'- 3....... 114 3........................................... ENTORl"\JOS DE INGENIERlA DEL SOFTWARE ORIENTADOS AL PROCESO ...................... 97 2..........................6............................ 112 3.................................................................................... LECTURAS RECOMENDADAS ............................ 110 3.............3...................................2........................................................................................ 111 3...............................................................3............................................................... 128 4................... SPEARMINT .. 126 4...........................3........................................ 104 3.............3............ 92 PARTE III: CALIDAD DEL PROCESO SOFTWARE ....................................................... Definici6n de Proceso de la Workflow Management Coalition .....................................1...............1........................................................................................................ 88 2...................... Metamodelos de proceso software ................... 130 4..... 110 3...................... EL MODELADO DE LOS PROCESOS SOFTWARE ..........................3...................................... Lenguaje de Especificaci6n de Procesos (PSL) ...................................... 132 4............................. Satisfacci6n ......................................3..................................5.......3..................11......3..... F0n11ato de Intercambio de Procesos ....................................................... 92 SITIOS WEB RECOMENDADOS ...........3.............. Efectividad .................. Introducci6n y Caracteristicas ...........................

........ 142 2... 156 3..................................................................................3........................... MODELOS IBEROAtY1ERICANOS DE MADUREZ Y EV ALUACION .. Procesos organizacionales ... SCAMPI (Standard CMrvn Appraisal Method for Process Improvement) ................ EJERCICIOS ......... EL ESTANDARISO/IEC 15504 .........................1......................... 177 5.........3.................................................................................................................... 162 3.............. 148 3...............4..................................7.................................................1........................................................ 188 6. SCE (Software Capability Evaluation) .................................................... LECTURAS RECOMENDADAS ......................................... 153 2................................ Procesos de soporte ......3..................2............4....................... 191 7................. 190 6.... 164 3................. 152 CAPiTULO 8: EVALUACION Y MEJORA DE PROCESOS ...........6..... 144 2..... 188 6..... 141 1................... Procesos principales .................... Modelos de Procesos para la Industria del Software (MoProSoft) .......... CBA-IPI ( CMM -Based Appraisal for lntemal Process Improvement) ............5. 167 3...................................................... PROCESOS DEL CICLO DE VIDA DE SISTEMAS ............. IDEAL .....................................................................................2...... 150 4.. Proceso de adaptacion .....................................................................3............... Representacion continua .......1.................. SITIOS WEB RECOMENDADOS .................... 158 3................. 146 2................................................................................... Mejora de procesos para fomentar la competitividad de la pequefia y mediana industria del software de Iberoamerica (COMPETISOFT) ............................................... People Capability Maturity Model (People-CMrvI) ............1............................... 158 3............................................................................................................................................. CONCEPTO DE CICLO DE VIDA ...................................... 153 I........ PROCESOS DEL CICLO DE VIDA SOFTWARE ...................................2........................... 181 5.................... MODELOS DE PROCESO DE CICLO DE VIDA ...... LECTURAS RECOMENDADAS ............................................................................... 141 2..............2............................................. TSP (Team Software Process) ........................ 193 8.................... 171 3..... CMM ....................................................... 151 5.......... 174 4....... 152 6....... EJERCICIOS ................ 161 3.............. PANOMMICA GENERAL ............................................... PSP (Personal Software Process) ................................... LA NORMA ISO 90003 .. Representacion por etapas .......... 183 5................... 195 ..................................... CIvIMI Y SCAMPI ............................................................................. 185 5........................................G: R/\-MA iNDICE XI CAPiTULO 7................... 194 9......... 142 2................................................ 186 6. SITIOS WEB RECOMENDADOS ........... Model0 de Referencia para melhOlia de processo de software (MR mps) .......................................... EL MODELO DE MADUREZ DE LA CAPACIDAD (CMM) Y LOS METODOS MAs REPRESENTA TIVOS DE EV ALUACION Y MEJORA ASOCIADOS .............................................................................

......................... HERRAMlENT AS DE MEDIClON SOFTWARE ............4.. 234 3..............................................1............ MEDICI ON DE SISTEMAS DE INFORMACION ................................. 215 2................... 211 2..2............2......... 261 ............... EJERCIClOS ....................... Medicion del Proceso ............................. CALIDAD DE LA LNFORl\1ACION ................................... IEEE Std 1061-1998...... ISO/lEC 15939 ......5. Medicion del Producto .....\llACION ...................... INTRODUCCION ........................ 250 4...2... 228 2................................................................. 209 2.......................................................................... Goal Question Metric (GQM) .....:........... Practical Software Measurement (PSM) ....................... Metricas de codigo fuente ........................... Metodologia para M6tIicas de Calidad del Sofhvare .............................................. Puntos funcion .........................................................).......RE ................. 23 7 3. Proceso de creacion de M6tricas ......................................4.... 259 1.................................vleasllrement ..........................................2................4........2............................... LECTURAS RECOMENDADAS ....... 205 2............................1......................................2.............................................................................2................... CAUDAD DE LOS MODELOS DE DATOS .. __ _ 2............ 220 2...............3...... MetIicas para sistemas 00 .............................................................. 256 6................. DE INFORJ..........................3..................................................................2............ 256 7............................................................ 217 2.......3........................... 238 3......6................. 223 2.. 236 3................................ E' 0 rcaClon d e GQM ........ 256 CAPITULO 10...... INTRODUCCION ............................................................................................................3....................XII CAUDAD DE SISTEMAS INFO~\L-\TICOS PARTE IV: OTROS ASPECTOS DE CALIDAD DE SISTEMAS .. 231 2...1............................................... IYIETRICAS SOFT\V....... Plantilla para la definicion de indicadores ............... 197 CAPITULO 9....................................................................................... 214 2.......................................................3...................... 240 3......... Planificacion ....................... 243 3.... Interpretacion ..............3......................................................................... 229 2.......................................3.................. Goal Question Indicator Metric (GQ(I)M) y Goal-Driml Softv...... Medicion del Proyecto .......................1............................. Teona de la Medicion del Software .......................................................................... 242 3.................................................. La medicion en los modelos de madurez y metodos de evaluacion y rnejora ............ 259 2... SITIOS \VEB RECOMENDADOS .........._......................................................................................... ESTANDARES Y METODOLOGIAS DE MEDICION ...are .......3.......................... 199 1.............................................................. MetI'icas de complejidad .................................................................................. 221 7 7 ....3....................1.. 241 3...1.........................2...... 255 5................ Definicion ......... Terminologia de la Medicion de Software .. 202 1..........Jernp 1 de ap l' " 777 _......3....A................................................ 200 1............................ Recopilacion de datos ..................... 199 1....................................

... Batll1l...........7......7....2.........................................A..........3...........4.....3.... Pasos en el marco de Eppler .................. EVAMECAL: Metodologia de Evaluaci6n y Mejora del PGI ............................ 279 CALID. 286 4... 292 .2................................ P' 4..................4........................................................................................................................... ("M"ISler y...................5.. 319 1...... 311 LECTURAS RECOMENDADAS ...................4................................). 290 4..................................1... 2...... 7.................2....................... Metodologia TQdM (English.. 274 2......................... Metodologia de Evaluaci6n AIMQ ........................ 319 1.....................................1.........3...............2........................ La Gesti6n del Conocimiento y los procesos del cicio de vida del sofuvare ...................1............... 271 2..... 301 4...................................... CALDEAy EVAMECAL ............................................... 308 4...............2................. Metodologia para la medici611 de la calidad de los datos ................................5...3...2..... 269 2............ 265 2................. 284 EV ALUACION Y MEJORA DE LA CAUDAD DE LA INFORMACION ....................... Elementos del marco y criterios de calidad . Calidad de los Modelos Conceptuales ................ Bases de Datos Relacionales ...... Necesidades de gesti6n del conocimiento en organizaciones de software ...............6.....................5. 273 2..... 261 2.. 303 4..............2............................. Implantaci6n de la Gesti6n del Conocimiel1to .......................................1..... 273 2...lOyecto Da Q' ............................................ 319 1..........1......................... 323 1........ 326 ........ Propuesta de Moody y Shanks .......................5............ [lilodelos de Gesti6n de Conocimiento en Ingenieria del SofuYare ....... 279 2...............................2............D DE DATOS ............. Marco de Trabajo de Eppler (2003) ....................... 100/ )..... Modelo SEKS .1........... 321 1...1.......... 278 2.........6........................................ 6..... Propuesta de Shanks y Darke ......................... Propuesta de Schuette y Rotthowe ... GESTION DEL CONOCIMIENTO ...................2..........2.1............... Propuesta del Grupo Alm'cos ............................................1..... 289 4........................7. 268 2.. 1999) ...................... 316 EJERCICIOS ........................2.............2... MetJicas a nivel de EstJ·ella ......6.......1...................................................... 324 1............... 281 3........6.... Propuesta de Lindland et al .......................................................................................3........................... 4......................... 274 2. CALDEA: Modelo de Madurez de calidad de infonnaci6n basado en Niveles de Madurez ................................. 315 SnIOS WEB RECOMENDADOS ........1.....................................1.........1........................2...........................................2. _ 4 ................................ Metodologia TDQM .... 300 4.............................h\D1CE XIII 3...........1................................. 322 1. 262 2.................... '97 UIl1CIS .................................... Metricas a nivel de Tabla ... Tecnicas y henamientas para la Gesti6n del Conocimiento .. Modelo de Dyba (2003) .............. INGENIERIA DEL SOFTWARE Y GESTION DEL CONOCIMIENTO ..... Metricas a nivel de Esquema ............. IP-MAP: Representaci6n del Producto de Info1l11aci6n ..... 5............ 316 CAPITULO 11............... _ _ ...............................2.......... Calidad de los Modelos L6gicos ............ 325 1.................. 299 4.................7...................2.......... 298 4.......2........ 291 4... Propuesta de Kesh .. Bases de datos l11ultidimensionales ...1..1...................... Ejemplo de Aplicaci6n de CALDEA ................ ....................

.............................1..... 332 3...........2.................................................................................... Comparativa entre las estrategias empiricas .................................................................................. Factoria de experiencia .................2.................................................................3.. 326 2......................................................1.. Encuestas ................................... EJERCICIOS ................................................................2..................... 339 3........................... 353 3........................................................ 355 4..... 357 6............. 357 ACRONIlVI0S . Ejemplo: detenninaci6n de la eficacia del Pair Designing para la compartici6n y difusi6n de conocimiento .. Base 0 repositorio de experiencia ..............................................XIV CAUDAD DE SISTEMAS Il'iFO&'v!ATICOS © RA-ivlA 2............................... 359 BIBLIOGRAFIA ..3................................... 363 iNDICE ALF ABETICO .............2......2.......1..... Experirnentos ........................................................................................................................................... Fases de un caso de estudio ....... Replicaci6n de los experimentos ...1....................................... 349 3.............................. Definici6n y aplicaciones ..... 328 2........................................ 346 3...1............................................................................................................... 332 3... 331 3................................................................................................................................................ 347 3... LECTURAS RECOMENDADAS ......... 387 ...............................................................1................ 326 2..4.. 347 3............ QIP (Paradigma de mejora de la calidad) ................. Diseiio de casos de estudio ....... 356 5...................3.....1.. Casos de estudio ..................... SITIOS WEB RECOMENDADOS .............2............ Descripci6n del proceso experimentaL ................ FACTORiA DE EXPERlENCIA Y PARADIGMA DE MEJORA DE LA CALIDAD (QIP) .......... 329 3..............2.........................................................................................................................................................3. FAMILIAS DE ESTUDIOS .................................. 338 3.......................................................

Socio fundador de la empresa Cronos Iberica en la que ha sido Director de los Departamentos de Desarrollo y Metodologias.AUTORES MARIO GERARDO PIATTINI VELTHUIS Doctor y Licenciado en Informatica por la Universidad Politecnica de Madrid. Ministerio de Administr·aciones Publicas. Auditoria y SegUlidad de Sistemas de Infol111aci6n. asi como numerosas comunicaciones en congresos intemacionales y nacionales sobre Ingenieria y Calidad del Software. asi como Patr·ono de la Fundaci6n insula Barataria par. entre las que destacan: Ministerio de Industria y Energia.! el fomento de la sociedad de la infon11aci6n y del conocimiento en Castilla-Ia Mancha y Miembro del Consejo Editorial de Universia. Unisys. Bases de Datos. donde dirige el grupo de investigaci6n Alar·cos. Es autor de varios libros. Tambien es Director del Centro Mixto de Investigaci6n y Desarrollo de Software UCLM-Soluziona (Ciudad Real). Licenciado en Psicologia por la Universidad Nacional de Educaci6n a Distancia. CISA (Certified Information System Auditor) y CISM (Certified Information System Manager) por la ISACA. rCM. Oracle. etc. Hewlett-Packard. Siemens-Nixdorf. un centenar de articulos. Master en Auditoria InfonnMica (CEJ\TEI).net. Especialista en la Aplicaci6n de Tecnologias de la Infonnaci6n en la Gesti6n Empresarial (CEPADE-UPM). especializado en Calidad de Sistemas de Infol111aci6n. asi como de Formaci6n e I + D. . Diplomado en Calidad por la Asociaci6n Espanola para la Calidad. Ha sido profesor asociado en la Universidad Complutense y en la Universidad Carlos III de Madrid. Ha trabajado como consultor para numerosos organismos y empresas. Actualmente es Catedratico de Universidad de Lenguajes y Sistemas lnfonnaticos en la Escuela Superior de InfonnMica de la Universidad de Castilla-La Mancha. Atos-Ods.

bases de datos e ingenieria del software. Ha publicado diversos articulos sobre cali dad de datos y de infon11aci6n en revistas. Actualmente es Profesor Asociado a tiempo parcial en la Escuela Superior de lnfonncitica de Ciudad Real. la medici6n. Ha sido profesor de F0l111aci6n Profesional en la rama de Sistemas Infonnciticos. Sus temas de investigaci6n incluyen la calidad de los procesos software. Colabora con el Grupo Alarcos des de 1999. libros y congresos nacionales e intemacionales.X:VI CAUDAD DE SISTE:VIAS INFORMATICOS FELIX OSCAR GARCIA RUBIO Doctor por la Universidad de Castilla-La Mancha. labor que compagina con las umciones de Ingeniero Software que tiene asignada en la Unidad de I+D de Soluziona Software Factory de Ciudad Real. Ingeniero en Infonmitica e lngeniero Tecnico en Infol111atica por la UCLM. Profesor asociado en la Escuela Superior de Infonmitica de Ciudad Real. Es miembro del gmpo de investigaci6n Alarcos especializado en sistemas de il1fonnaci611. Sobre estos temas ha sido autor de varios capitulos de libro y numerosos articulos en revistas y conferencias nacionales e intemacionales. en la que tambien obtuvo los titulos de lngeniero en lnfonmitica e lngeniero Tecnico en lnfonmitica de Gesti6n. los metodos agiles y los procesos de negocio. . donde desanolla su investigaci6n en el campo de la gesti6n de la calidad de los datos y de la infon11aci6n. ISlVlAEL CABALLERO MuNOZ-REJA Doctor en Infonnatica.

De un enfoque centrado en el control de la cali dad y la detecci6n de disconforrnidades en los productos. 10 que es nonnal teniendo en cuenta la relativa juventud y la naturaleza tan peculiar del sofuvare..PROLOGO * & Hemos asistido en los ultimos afios a un avance espectacular de la denominada Sociedad de la Infonnaci6n. etc. . que aportan tecnicas y herramientas para lograr productos y servicios de gran fiabilidad que puedan satisfacer las necesidades de los usuarios. Varios paises han venido invirtiendo grandes cantidades de recursos con el fm de potenciar la industria del sofuvare tanto para atender la demanda intema como para convertir el sofuvare en uno de los sectores estrategicos de crecimiento. la dependencia de nuestra sociedad y economia de los sistemas infonmiticos para su funcionamiento e inc1uso supervivencia se ha ido haciendo cada vez lTIllS mayor. se ha pasado a estudiar la mejora de los procesos de creaci6n y desarrollo de sistemas infonnaticos as! como la certificaci6n de los mismos. sin embargo. mucha labor por hacer si comparamos la situaci6n de la calidad en el sofuvare con la de otros sectores como el autom6vil. han madurado considerablemente en estos ultimos afios. En paralelo a este avance. La Ingenielia y la Calidad del Sofuvare. la industria qu!mica. As!. se han instal ado fabricas de sofuvare en muchas regiones. Queda. se han creado centros de estudio y de investigaci6n y otras estructuras con el fm de disponer del personal cualificado y de las tecnicas y herramientas adecuadas para la construcci6n de sofuvare de calidad.

Madrid a 2 de junio de 2006 Victor M. A este respecto quelTia destacar la labor llevada a cabo por A. Creo que el material del libro puede resultar lItil para que tanto los estudiantes como los profesionales puedan construir y gestionar productos y servicios de mayor calidad. En efecto. Izquierdo Loyola Subdirector General de Empresas de la Sociedad de la Inf0l111aci6n Presidente del Comite Tecnico de Norn1alizaci6n 71 de AENOR . entre las que destacan INES (Iniciativa Espai'iola de Sofuvare y Servicios) entre cuyos objetivos esta precisamente la investigaci6n e innovaci6n en los temas relacionados con la calidad de los productos y servicios software. ISO 12207. Por otra pmte. hom610gas a las europeas. Esta demanda se preve crezca exponencialmente a medida que la socied2.. relativa a la creaci6n y seguimiento de diferentes estandares relacionaclos con los procesos del ciclo de vida del sottware y los sistemas de infol111aci6n. especialmente por el CT0i71. es de gran imponancia en la sociedad globalizada que actualmente vivimos. ]a calidad de datos 0 la gesti6n del conocimiento que complementan las areas mas tradicionales de esta materia. ofreciendo una panoramica bastante completa sobre los estandares relacionados con la calidad de los productos y procesos sofuvare. la calidad.XVlIl CAUDAD DE SISTD[AS En el caso de Espai'ia.r"'OR. Este libro presenta los principales conceptos relacionados con la calidad del sofuvare. Creemos que estas iniciativas ofrecen una I11UY buena oportunidad para que la industria espai'iola del sofuvare de un salto significativo en los aspectos relacionados con la calidad y responda adecuadamente a los retos que suponen la creaci6n de diferentes "e-servicios" que demanda la sociedad actual. que existan estandares reconocidos internacionalmente que pel111itan a las empresas cOOl'dinar sus esfuerzos. la Secretaria de Estado de T elecomunicaciones y para la Sociedad de la Infol111aci6n del Ministerio de Industria. 0tro aspecro que cabe res altar es la gran cantidad de recursos que se han destinado a la creaci6n de modelos y estandares relacionados con la cali dad del sofuvare. contlibuyendo de esta manera a la consolidaci6n de la Sociedad de la Inf0I111aci6n. Ademas trata aspectos muy impOltantes como son Ia medici6n d.d del conocimiento alcance la mayor parte de la poblaci6n. se fomenta la creaci6n de Platafol111aS Tecnol6gicas Espai'iolas. Turismo y Comercio en el marco del Plan Avanza 2006-2010 promueve la mejora de la calidad del software mediante ayudas a las empresas para la obtenci6n de certificaciones basadas en los plincipales modelos y n0l111aS de calidad como CMML ISO 15504. y reutilizar las "mejores practicas" de desanollo y gesti6n del sofuvare. ISO 90003.

.PREFACIO Soda puede IOrcer el cUlilino de fa \'erdo(/. facilidad de mantenimiento. flexibilidad. portabilidad. como el ace ire sob!'e el agzl([. por 10 tanto. su supervivenciadepel1del1 de los sistemas info1111aticos para su buen funcionamiento. cada vez mas. cOlTeccion. El Quiiole La calidad de los sistemas infonmiticos Se he! cOlwertido hoy en dia en uno de los principales objetivos estrategicos de las organizaciones debido a que. los procesos mas importantes de las organizaciones -y. ya que puede ser sinonimo de eficiencia. Como los requisitos dependenin de las diferentes partes interesadas (stakeholders). etc. Seglll1 la nonna ISO 9000 la calidad es el "grado en el qUe un conjunto de caracteristicas inherentes cumple con los requisitos".1' siempre (me/un sobre Iii lIlel1lira y lo/eillU de indusrria.1' la calidad pOl'qlle es{(/s adelga::an y no quiebrail. Cerml1les. confiabilidad. integridad. seguridad. facilidad de uso. la calidad es un concepto multidimensional.

CONTENtDO La obra consta de once capitulos. Dar a conocer los diferentes estandares relacionados con la calidad del software. proporcionando una panorarnica actuaI y completa sobre la problematica asociada a la calidad de los sistemas informaticos. Tratar aspectos muy importantes para conseguir sistemas de infonnacion de calidad como pueden ser la medici6n. una ventaja competitiva. haciendo cronica la denorninada "crisis del software". por 10 que se ofrece una vision amplia sobre diferentes factores que se deben tener en consideracion para la construccion de software de calidad. de la sociedad ha crecido mucho mas deprisa que la capacidad de la industria para producir software de calidad.xx CAUDAD DE SISTEMAS INFORlvlATICOS © Ri\-tvLA. la cali dad de la infonnacion 0 la gestion del conocirniento. o o o A 10 largo de esta obra se ha combinado el rigor cientifico con la experiencia practica. Exponer los aspectos mas significativos relacionados con la calidad de productos y procesos software. El primer capitulo introduce el concepto de calidad partiendo de las defmiciones mas comunes hasta su interpretacion por parte de los principales gurus y estandares intemacionales. En este libro se persiguen los siguientes objetivos: o Presentar de forma clara los conceptos fundamentales relacionados con la calidad de los sistemas informaticos. en general. que pasa a conveltirse en una "filosofia". La demanda de software por parte de las organizaciones y. dada la importancia que ha adquirido la calidad en la ingenieria de sistemas y en la ingerueria del software. que afecta a toda la organizacion. . La presente obra reline diferentes aspectos de calidad relacionados con los sistemas infonnaticos. agrupados en cuatro partes. En los ultimos afios se han publicado diversos estudios y estandares en los que se exponen los principios que se deben seguir para la mejora de la cali dad de productos y procesos. En la evolucion expelimentada por la calidad de los sistemas infonmiticos se ha pas ado de un tratamiento centrado fundamentalmente en la inspeccion y deteccion de errores en los programas. La primera parte ofrece una vision general de los conceptos. a una aproximacion mas sistematica. Todo ello ha influido de forma significativa en el papel que actualmente tiene la calidad en las organizaciones. tecrucas y nonnas de calidad. una cultura. 1.

pasando por las herramientas basicas de calidad. los plincipales modelos y nom1as relacionados con la medicion. nuestro proposito al presentar este libro ha sido dirigimos a una audiencia mucho mas amplia que comprende: . En el capitulo 3 se exponen las aproximaciones mas importantes a la calidad. en el capitulo 9 se presentan los conceptos relativos a la medicion del software. dedicando una gran parte a la explicacion de las normas de la familia ISO 9000. La parte II consta de dos capitulos. ORIENTACION A lOS lECTORES Aunque un conocimiento en profundidad de la gestion de la calidad de los sistemas de infom1acion puede estar reservado a expertos en la materia. nonnas intemacionales. y las metricas mas utilizadas. pasando por el modelo EFQM y hasta seis-sigma (sixsigma). el capitulo 11 se centra en la gestion del conocinliento y su importancia para conseguir sistemas de infonnacion·de calidad. en el capitulo 4 se presenta una vision holistic a de la calidad de los sistemas de informacion. asi como algunos de los problemas de calidad que presentan los mismos. metodos de evaluacion. Por ultimo. Asi.~ RA. asi como un modelo de madurez y un metodo de evaluacion relacionados con la calidad de la infonnacion. que pemliten tener una idea general de los procesos software. especialmente el ISO 12207. las estadisticas 0 las de gestion. En el capitulo 8 se presenta las plincipales propuestas relativas a la evaluacion y mejora de procesos: modelos de madurez.-i'vLA. En el capitulo 10 se proponen conceptos relativos a la cali dad de la infonnacion. entre otras. etc. basandose en las principales normas intemacionales. En el sexto capitulo. A continuacion. desde la gestion de la calidad total. se incluye la bibliografia y los acronimos utilizados en el texto. EI capitulo 5 explora las diferentes caracteristicas y subcaracteristicas de calidad de un producto software asi como el proceso de evaluacion. EI capitulo 7 resume los principales modelos de procesos de ciclo de vida. PREFACIO XXI El capitulo 2 resume las principales tecnicas utilizadas para la gestion de la cali dad. con el que inicia la parte III relativa a la cali dad de proceso software. se discuten los principales elementos del proceso software y los lenguajes de modelado propuestos hasta la fecha. La cuarta y liltima parte dellibro aborda otros aspectos de la cali dad de los sistemas de infonnacion. 2.

el estudio de esta obra puede realizarse de maneras muy distintas dependiendo de la finalidad y conocimientos previos del lector. OTRAS OBRAS RELACIONADAS Queremos destacar que existen algunos libros public ados tambien por la editorial RA-MA que complementan la vision de la presente obra: €I Medicion para la gestion en la lngenierfa del Sofhmre. l y Fel11andez. 3. F. Piattini. Calvo-Mazano. l y Fel11andez. Calidad ell el desarrollo y mantellimiento del soj'hmre. L. (ISBN 84-7897-544-6). 2000. quieran abordarla de fOl1na mas sistematica. (ISBN 84-7897-587-X). €I Debido a la diversidad de la audiencia. 2004. Cervera. M. Participantes en seminarios 0 cursos monognificos sobre calidad de sistemas de informacion 0 calidad de software. verificacion y validacion."XII C. 2003. Dolado. que aborda el desalTollo y mantenil11iento de software. M. que ofrece una panoramic a actual sobre diferentes investigaciones realizadas por grupos destacados en calidad y mejora de procesos y productos. lA. que recopila diferentes trabajos relacionados con la gestion cuantitativa de los proyectos y la calidad del software. Directivos que tengan entre mantenimiento de sistemas.. Amilisis y Diseiio de Aplicaciones lnforlllaticas de Gestioll. Una perspectiva de lngenierfa del Sofhmre.-\UDAD DE SISTE:vIAS INFOR\lATICOS ©RA-i\lA €I Alumnos de Escuelas y Facultades de Infonmitica. (ISBN 84-7897-403-2). que tengan interes en adquirir unos conocimientos sobre las tecnicas y metodologias mas utilizadas para asegurar la calidad de los sistemas de infol1nacion. €I €I . Analistas 0 consultores que. Profesionales infonmiticos que esten trabajando en el area del desalTollo de Sistemas de Infol1nacion. etc. sus responsabilidades el desalTollo y €I €I €I €I Usuarios avanzados. asi como diferentes aspectos relacionados con la calidad: pruebas.. y Garcia. Piattini.X. allll teniendo conocimientos de la materia. L (eds).

a los alumnos de la asignahlra Calidad de Sistemas de li!/ormacion de la Escuela Superior de Infonnatica de Ciudad Real. asi como a los asistentes a los diferentes seminmios y conferencias que hemos organizado sobre diferentes aspectos de la calidad de los sistemas infonnaticos en estos liltimos quince afios. . que se encarg6 de la filmaci6n del libro. Sus sugerencias. Mario G. comentmios y ctiticas nos han pennitido depurar el material que presentamos en esta obra y planteamos que podtia resultar lltil disponer de un libro que ayudara a la gesti6n de la calidad de los SI. Tambien deseamos dar las gracias a D. AGRADECIMIENTOS Queniamos expresar nuestro agradecimiento.PREFACIO 4. Oscar Garcia Rubio /smael Caballero ivll11loz-Reja Ciudad Real. especialmente a don Jose Luis Ramirez. Tambien queremos agradecer a la empresa Alvadalejo S. Piattini Velthllis FelL>.L. por su continuo apoyo y colaboraci6n. y a la editorial RA-MA. Victor Izquierdo Loyola por haber aceptado escribir la presentaci6n de esta obra. agosto de 2006. en plimer lugar.

.

Tecnicas y Herramientas de CaUdad 3. Modelos y Normas de CaUdad .Introduccion a fa Cafidad 1. Concepto de Calidad 2.

" Walt Disnel' 1. DEFINICION DE CAUDAD La calidad se ha convertido hoy en dia en uno de los principales objetivos estrategicos para las organizaciones debido a que. Propiedad 0 conjunto de propiedades inlJerentes a algo. Buena calidad. Y si alga es 10 sl!ficientemente bueno.CAPiTULO 1 CONCEPTO DE CALIDAD "No me preocupa si alga es cam a barato. Caracler. Segill1 el Diccionario de la Real Academia Espanola de la Lengua (DRAE. su supervivencia depende de la calidad de los productos y servicios que ponen a disposicion de los usuarios y clientes y de la satisfaccion de estos. 2. Condicion 0 requisito que se pone en un contrato. la calidad es (en sus cuatro primeras acepciones): 1. 2006). cada vez mas. genio. S610 si es buena.la "excelencia"). qlle permitenjllzgar Sll valor. Aunque coloquialmente podria parecer mas adecuada la segunda definicion a la hora de evaluar la calidad de un producto 0 un servicio (ya que se pretende -en sentido absoluto. En efecto. entonces el pllblico pagara par ella. 4. indole. se intenta detenninar las propiedades inherentes a una cosa . sliperioridad 0 excelencia. las organizaciones estan interesadas en la primera y tercera acepci6n de calidad. 3.

". ya que dependera del punto de vista utilizado. (Taguchi y Wu. Genichi Taguchi: "La calidad es la perdida que un producto causa a la sociedad desplles de ser entregada . «Calidad de vida» es lin cliche pOl'que cada oyente aSlime que la persona que habla entiende exactamente 10 que para 131 signtjica la frase.A.. ingenieros. La otra tiene que vel' con 10 qlle pensamos. fabricacion y mantenimiento por medio de las cuales el prodllcto y servicio en lISO cllmplil'a las e. Esta es precisamente la razon pOl' la que debemos definir caUdad como «conjormidad COil los requisitos» si queremos gestionarla". calidad de proceso. 1979). Anlland V. (Feigenbaum. Histolicamente. W. calidad del sistema. «mala calidad» y la expresion «calidad de vida ". calidad de division. los diferentes gurus de esta area han dado diversas definiciones de calidad (Hoyer y Hoyer. ademas de las perdidas callsadas pOl' Sll fill1cion intrinseca". pero esto sera relativo. las organizaciones deberan asegurar los requisitos que se fijan en los contratos. que nos pennita conseguir que sea mejor que las otras. 1986). Como uno intelpreta el temzino "calidad" es importante. calidad de informacion.A. 1979). ingenieria. (Ishikawa. @ @ @ @ @ .. QlIe es calidad? La calidad solo se puede dl?:jinir en terminos del agente". Crosby: "La prim era sllposicion erronea es que calidad significa bondad. (Crosby. 1931)... directivos y ejeclltivos-. Intelpretado restringidamente. 1983). (.I"TICOS ©RA-M. Philip B. sentimos 0 creemos como resllltado de la realidad objetiva. etc. calidad de objeti1'os. 1985). calidad de la elllpresa. hljo.. brillo 0 peso..4 CAUDAD DE SISTEMASIN"FOR. calidad del personal -inclll)'endo trabajadores..'vL. 2001): @ W. Kaoru Ishikawa: ''Debemos enfati::ar la orientacion al cliente . Por otra parte. En otras palabras hay lin [ado subjetivo de la calidad" (Shewhart. calidad de servicio. Feigenbaum: "La caUdad de prodllcto 0 servicio puede ser definida como las caracteristicas to tales compllestas de producto y senJicio de marketing.. Edwards Deming: "La dtficliitad de delinir calidad es traducir las necesidadesfilturas delllsllario en caracteristicas lIledibles. La palabra «calidad» se utiliza para significar el valor relativo de las cosas enfrases como «bllena caUdad». (Deming. de manera que un prodllcto plleda ser diseiiado y producido para dar satisfaccion al llsuario al precio qlle paga. Shewhart: "Existen dos aspectos de la calidad EI primero tiene que vel' con la cOl1sideracion de la calidad de IIna cosa como una realidad objetiva independiente de la existencia del hombre.xpectativas del cliente". calidad signtfica calidad de trabajo. calidad signtjica €alidad de prodllcto. Intelpretado ampliamente.

Es conveniente estandarizar en una corta definici6n la palabra calidad como adecuacion at uso". Parte del Proceso de Mejora de la Calidad.. Los dos significados que dominan el uso de la palabra son: 1. Tener forrnaci6n supervisada. Dar a todos los empleados las herrarnientas adecuadas para hacer bien el trabaio. S. Pane del Proceso de Control de la Calidad. Ser constantes en el I JrlRAt'i CROSBY FElGEl\1JAUM prop6sito de mejorar el producto 0 servicio. Proporcionar sopone a la gesti6n. BM7. Rechazar la aceptaci6n de defectos 3. La cali dad consiste en las caracteristicas del producto que satisfacen las necesidades de los clientes y les proporcionan por tanto satisfacci6n con el producto. productividacL tiempos de ciclo. 4. Mantener un sistema de eliminaci6n de causas de error. 8. DE1VflNG 1. 5. con el objetivo de llegar a ser competitivos. En vez de ello. Utilizar un sistenm de acciones correctivas. Establecer una filosofia de mejora continua y pemmnente. I. Acabar con la practica de hacer negocios sobre la base del precio. Equipo de mejora de lacalidad. capacidad de fabricaci6n y desarrollar los objetivos del proceso y de la calidad). Comprender que la calidad es una etica. Proceso de Planificaci6n de la Calidad (considerar las necesidades del cliente. (Jman. Establecer la tendencia a tener un iinico proveedor para cualquier articulo. interpretar valores actuales vs. Jman: "La palabra calidad tiene multiple significados. Suprimir la dependencia de la inspecci6n para lograr la cali dad.LlDAD 5 Q Joseph M. RM5. control de medici6n. seguridad de uso. Calidad consiste en ausencia de deficiencias . 2. Proceso de Control de la Calidad (induye control de parametros de proceso. EI papel de los metodos estadisticos se encuentra cubieno por el Proceso de Control de la Calidad. Eliminar la necesidad de la inspecci6n en masa. entomo. Parte del Proceso de Mejora de la Calidad. Parte del Proceso de Mejora de la Calidad. estandares de desempeiio.. minimizar el costo total. Estandares). 2. BMS. Adoptar una nueva filosofia. reducci6n de costes). Tener conciencia de la calidad. Hacer mejoras de manera continua y para siempre. 5. 7. 4 1. 10. La calidad es una fomm de gesti6n. Instituir metodos de formaci6n modemos en el trabaio. 2. con una relaci6n a largo plazo.. 1988). 6. 6. Mantener un sistema de mejora continua. de manera que cada uno pueda trabajar con eficacia para la ora anizaci6n. 2.!::': RA-MA CAPiTlJLO 1: CONCEPTO DE CA. de pemmnecer en el negocio y de proporcionar puestos de trabaio. Pane del Proceso de Control de la Calidad. Parte del Proceso de . Fijar objetivos de calidad. . diseiio. Encontrar problemas. Desechar el miedo.VJejora de la Calidad (considera mejora de proceso y de producto. incorporando la cali dad dentro del producto en primer lugar. de lealtad v confianza.

B\!10. 1. Calidad y coste s. B\!9.'n una suma no una ditCr~ncia. 1-+. de \kjura ('1. Tabla l.. \!antener equil'os de mcjora. 2002) En la tabla 1. 13. Calidad es cl camino m{ls cfic[~z en costes y menos intensi\'o en capital hilcia Ia producti\·idad. 3. animar a los ditcrentes departamentos a trabajar conjuntamente en Ia resolucion dc problemas. loot In\'olucrar a tedo d personal de Iu organizacilH1 en la luella por conseguir la transt~1nllacion. -+.6 CAUDAD DE SISTE~lAS 10:FORM. Juran ("La Trifagfa . I-Iacer los 13 pasos otm \'C2. l~. Presente en su libra Tora! QlIa/i~l' Comro! (aunquc no sc cite cxp1icitamente en los principios ni en los bcnchmarks I. Eliminar las barreras entre departamentos.: Tencr ronl1aci(~n la Calidad.\TICOS CROSBY FEIGE7'lBAF\I 9. BM. II. Tener planes de illcdici6n de la calidad. Punc del Proccs~) de rcconocimicnto.1. B\12.9. Comparacion de Filosofias de Calidad de los Cuatro Gurus (Mouradian.1 se resumen y se comparan las principales ideas sobre la calidad de los cuatro gurus del siglo XX: Deming C14 puntas para fa gestion''j. Eliminar est{mdares de trabajo que cspccitican cuotas nurn~ricas. Pane del Proeesa de \ !cjora de la Calidad. Eliminar los objcti\'os y cs16gancs que cxigcn nuc\'os ni\'clcs de producti\·idad. Ca1idad e5 10 que las clicntcs diccn que cs B\!3. Parte del Proceso de \ !cjora de In Calidad. \!antener compromisa de 1a direccion. Calidad sc itnplcmenta con un sistema total concctilco con los c1 iclltes y proyccdorcs. Tener un prograllla 12. Estimar el coste de 1a calidad. Calidad es csencial para 1a innovacion desde la conccpcic\n del discno hasta 1a utilizacicin par parte del cliente. Parte del Proceso de \!cjom de la CaIidad. 5upcl\'isada. Reconocer que el coste y ]a calidad son complementarios. ~. utilizar m~todos cstadisticos para mcjorar 1a l'roducti\idad y calidad de lQnna contmua. Esta es turea de todos. B\!6.J. 3. Tener un progruma de cero ddcct('ls. Estab1eeer que Ia calidad es un proceso que abarca toda Ia organizncion. Impbntar un prl)g:ran1u \'igoroso de cducacion y auto-mcjora.ntir~(' l)rgullosos de $U trabaio. posters 10. B~! 1. . . Conseguir imp1icacion indi\'idual y de equipo (Ia calidad es tmbajo de todost I1tlI110ricos. 12. 10. Eliminar todas las batTeras que impiJan a los trabajadorcs s-(. Cali dad e innoyacion son mutuamente dependiemes.J. sin proporcionar metodos de mejora especiticos. 7. Parte del Proc~so de \!cjora dc 1a Ca1id. 2. CtiIizar consejos de calidad.1d. Lograr dias en los qu~c sea posible encontrar cero defectos. Estabkccr control de configuracion sobre los objcti\os de calidad.

sujeta a restricciones (p. 2000a).. es posible considerarIa como un concepto multidimensional (referida a muchas cualidades)..(. Crosby ("14 pasos para fa ca!idad") y Feigenbaum (.mAD Figura 1. ej . Ademas la cali dad sllele ser transparente cuando esta presente pero resulta facilmente reconocible cuando esta ausente (por ejemplo. Asi se puede ver que la calidad no se trata de un concepto absoluto: el consumidor la juzga con to do relatiyismo en un producto. Por otro lado.4 principios de gestion y 10 djrectrices para fa ap!icacion de estos prillcipios").icio es deficiente). La calidad puede verse desd£ muchos puntos de vista A este respecto merece la pena recordar las cinco "j'istas" de la calidad que sefiala Garvin (1984): . Incluso. es multidimensional (vease la figura 1. ej . OPORTI. plazos de entrega). RA-\L-\ CAPiTULO I: COKCEPTO DE CALID. Asi pues.1. cuando el producto falla 0 el sel'. se puede considerar que no es ni total mente subjeti\'3. Cada fila ilustra la idea de cada uno con respecto al mismo critelio. la calidad no es absoluta. la calidad se define como "el grado en ef que UII cOlljunto de caracteristicas illherelltes clllnpfe COil los requisitos" (ISO..1)..-\D 7 de Juran sobre como gestiol/ar la ca!idad"). (pOl'que ciertos aspectos pueden medirse) ni total mente objetiva (ya que existen cualidades cuya evaluacion solo puede ser subjetiva). 2003). En general (Piattini et al.. 0tra definicion interesante de calidad es la proporcionada por ISO 8402: "Col!illl1tO de propiedades 0 caracteristicas de WI prodllcto 0 serdcio qlle Ie cOI?jieren aptitud para satislacer 1I11ClS necesidades expresadas 0 implicitas ". depende del presupuesto disponible) y ligada a compromisos aceptables (p. en las principales n0l111aS intemacionales.:".

Los origenes de la calidad . etc. medirlos y establecer objetivos a alcanzar. Vista basada en valor: la calidad depende de la cantidad que el cliente este dispuesto a pagar. la del producto es "des de dentro". Vista de fabricante: la calidad es confonnidad con las especificaciones. Se trata de una vista centrada en el proceso.-MA o Vista trascendental: la calidad es algo que se reconoce pero no se define. Por 10 que se puede cuantificar las caracteIisticas de los productos. en el proceso de fablicaci6n. Por 10 que se puede concebir la calidad como un ideal al que se intenta llegar.2): Calidad Necesaria Figura 1. Vista del producto: que considera que la calidad esta unida a las caracteIisticas inherentes del producto. Vista de usuario: la calidad es adecuacion al proposito. Esta concepcion de la calidad expande su alcance para exal11inar la cali dad durante la produccion y despues de la entrega del producto.8 CALlDAD DE SISTE?v!AS INFORM.TICOS ©RA. Esta vista no resulta demasiado util para la gesti6n de la calidad y es amlloga a la segunda acepci6n del DRAE (2005). en la comprensi6n. aunque no 10 conseguimos debido a deficiencias en la tecnologia. ya que se centra en la l11edida de los atIibutos internos de los productos. Mientras que las vistas del usuario y fabricante se tienen "des de fuera". o o o o Hay que tener en cuenta adel11as que la calidad puede tener varios oIigenes (vease figura 1.2.\.

EVOLUCION HiSTORICA DE LA CAUDAD La preocupacion por la calidad es tan antigua como la humanidad. Es. Se potencia con la mejora de las habilidades personales y tecnicas de los participantes en lill proceso. 2. capacidad y peso. Todo 10 que este fuera de dicha coincidencia sera motivo de derroche. ya que en el fondo muchos problemas de la calidad pueden tener su origen en falsas expectativas por parte del cliente sobre las caracteristicas de un producto 0 servicio. Se potencia con la elaboracion de una especificacion que sirva de buena referencia a los participantes en un proceso. como sefiala Juran (1995). En el imperio egipcio se han llegado a encontrar. y ver su grado de coincidencia con la calidad realizada. gracias a su habilidad en la ejecucion de una tarea. ya en el siglo XI antes de Cristo en China se fijo un sistema para controlar el desarrollo de productos artesanales con dos depariamentos encargados de la calidad de los productos: uno de fommlar y ejecutar estandares y el otro para supervision y prueba. De todas maneras. La calidad programada: la que se ha pretendido obtener. metrologiadimensionaL tutorialm. (!) (!) La gestion de la calidad pretendeni conseguir que estos tres circulos coincidan 10 mas posible. La calidad necesaria: la que el cliente exige con mayor 0 menor grado de concrecion 0.org cienci. Mouradian (2002) sefiala que Kheops (rey del Antiguo Egipto alrededor del 2680 AC. hUll .egiDtoIOf. por tanto. al menos.l'll1atcmaticas unidades.:dicionantiguedad. Se potencia con una adecuada obtencion de infonnacion de la idea de cali dad de los clientes.:. Como sefiala Juran (1995). Ejemplos de calidad y de medicion se pueden encontrar tambien en otras civilizaciones como la babilonia (de la que se tiene ! Para mas infomlaci6n se recomienda leer http: \\\vw. en un docwnento de disefio 0 en un plano. la que se Ie ha encomendado conseguir al responsable de ejecutar el trabajo. las primeras especificaciones de calidad escritas en papiros egipcios de mas de 3500 afios de antigiiedad.. de hecho los restos arqueologicos dan fe de la mejora que experimentaron las herramientas que el hombre plimitivo desarrollo con el fin de cazar animales y crear lugares donde habitar.I11etalunivers.) fue el que establecio el "cubit'" (codo)! como la distancia que iba desde su coda hasta la punta de su de do corazon. de gasto superfluo 0 de insatisfaccion. consideramos que tambien resulta fundamental tener en cuenta la "calidad esperada" por el cliente.ia.9RA-1vV\ CAPiTULO I: CONCEPTO DE CAUDAD 9 (!) La calidad reatizada: la que es capaz de obtener la persona que realiza el trabajo. que no siempre coincide con la necesaria. Es la que aparece descrita en una especificacion.com are. la que Ie gustaria recibir.htm 0 httD:· w\\w. Incluso se promulgarop decretos para prohibir la venta de productos de calidad inferior y se presto tambien atencion a la medicion de longitud.

Surgen las ±abricas que pe1111iten un aumento de la productividad. impelios en los que la estandarizacion juega tambien un importante pape!.A Shew'hart. Precisamente. Shewhart propUgI10 la utilizacion de tecnicas estadisticas y control de procesos (la "plimera ola" del control estadistico de la calidad. Se supervisan los productos resultantes de la cadena de produccion y nace el control de calidad (pasa 0 no pasa). los trabajadores no se encuentran en estado de autocontrol pOl'que no tienen contacto con e1 cliente. Durante la Edad Media y el Renacimiento. a mediados del siglo XVIII se inicia en InglatelTa la reyolucion industrial que se expande al resto de Europa y otras partes del mundo. y a quien se Ie puede considerar como el padre del modemo aseguramiento de la cali dad. los artesanos son los que realizan toda la secuencia de tareas para la creacion de un producto y que el comprador es el responsable del "aseguramiento" de la calidad. Crece tambien la necesidad de estandarizacion de las piezas: en este sentido Mouradian (2002) sefiala a Jean-Baptiste de Gribeauyal como el primer inventor que introdujo el concepto de intercambiabilidad en 1767 para la fablicacion de artilleria fi·ancesa. que subraya la impoltancia de los metodos de control estadistico del proceso para reducir la variabilidad del proceso.. Taylor en e1 que se separa claramente la planificacion de la ejecucion (taylorismo). Se crea e1 Departamento de Aseguramiento de Calidad del que fOl1no parte W. gIiega. etc. Este autor destaca tambien excelentes sistemas de gestion de la calidad como el del "Arsenal de la Repziblica Veneciana" durante los siglos XII al XVIII. para atender las rec1amaciones de los clientes que instalaban teh~fonos (inwntado en 1876). dando como resultado una mayor produccion mas asequible y un aumento de la demanda. y en la que destacan la gI'an cantidad de maquinas inventadas. se conviltio en el texto basi co en las empresas sobre calidad en Japon y en EElJU. Hacer. La gestion y el concepto de "calidad moderna" surgen en 1924 en los Bel! Telephone Laboratories. seglll1 Juran (1995»).c. Se crearon los departamentos de inspeccion.W. Actuar). Juran (1995) destaca que en este momento historico. Shewhart introduce el grafo de controL el desanollo del muestreo estadistico (Tague. Verificar.). inspeccionando y probando el producto en los mercados. . Esta situacion se agudizara alm mas C011 la adopcion del sistema de produccion cientifica de F.10 CAUDAD DE SISTEtvLA.S IN"FOIUviA. etc. Cobran impOltancia los artesanos que se familiarizan con los materiales utilizados y reciben un entrenamiento especifico durante su aprendizaje. y que implantan la produccion en mas a en la que las tareas se dividen entre yarios trabajadores de la fabrica. organizandose una jerarquia de categorias (maestro. El libro de Shewhart (1931).TICOS ·&>RA-MA constancia de una garantia de calidad que data del 429 A. Por otro lado. 2005) y es el creador de1modelo PHV A (Planificar. aprendiz. 10 que tuvo a la postre un efecto negativo sobre la cali dad. se aumento la produccion. romana. la creacion de pueblos y ciudades incremento la division del trabajo y el desanollo de habilidades especializadas. pero se tel1nino dafiando las relaciones personales.) y los gremios con el fin de administrar los monopolios y transmitir la experiencia y conocimientos.

R.A. Por otra parte. En los ai'ios sesenta cuatro aspectos desafiaron la adecuaci6n de la calidad en EEUU: €I EI incremento del consumismo EI incremento de demandas judiciales sobre calidad EI incremento de la regulaci6n gubemamental sobre la calidad La revoluci6njaponesa de la calidad €I €I €I . Crosby que impuls6 impOltantes programas de mejora de la calidad desde el Quality College. adaptando las tab las desalTolladas en Bell System.estancos. En los ai'ios cincuenta otros dos gUrLlS tambien influyeron notablemente en la difusi6n de las ideas sobre calidad: Anmnd Feigenbaum. y la fonnaci6n junto con la necesidad de dar importancia a la cali dad se limita al departamento de calidad.(. por 10 cual la calidad de los pocos que quedaron descendi6 considerablemente. Juran y Deming colaboraron con las fuerzas annadas nOlteamer1canas. Edwards Deming tambien trabaj6 con Shewhart hacia 1920 y luego en el departamento de agricultura norteamericano en el que impuls6 la utilizaci6n del Disefio de Experimentos (DOE) propuesto por Fisher. Juran (1995) sei'iala n'es contribuciones impOltantes que llevadan a modificar notablemente esta situaci6n: los cursos de fOl111aci6n organizados porIa Ch'i! COllllllllllicatiolls Section de las fuerzas de ocupaci6n nOlteamericana. Joseph Juran fue uno de los asistentes a estos cursos y posterionnente trabajaria sobre control estadistico. que public6 el libro Total Quality Control en 1951 y Philip B. Durante la Segunda GuelTa Mundial. al desafio de cambial' su reputaci6n de productos de mala calidad. W. como sefiala Juran (1995) la producci6n se lleva a cabo por departamentos . cuya misi6n se cenn'aba en separar los buenos productos de los malos al final de la secuencia de producci6n. porque los fabr1cantes dieron pl10l1dad a la producci6n de gr'andes VOlL1l11eneS para conseguir cuota de mercado. En estas empresas.. Durante estos ai'ios se crearon en muchas empresas norteamericanas y europeas los departamentos de calidad. -?vlA CAPiTULO 1: CONCEPTO DE CAUDAD 11 Shewhart se dedic6 a impartir una serie de cursos durante los afios 1920 aplicando algunas de las tecnicas citadas. que hicieron un gran uso de la inspecci6n por l11uestreo. las conferencias de Deming sobre conn'ol estadistico de la calidad y las conferencias de Juran sobre gesti6n de la cali dad. los japoneses despues de la Segunda GuelTa Mundial se enfrentaron. entre on'os muchos problemas. Por su parte. en 10 que Juran (1995) denol11ina la "segunda ola" del control estadistico del proceso. Al acabar la guelTa se produjo una gran escasez de productos. La industria japonesa aplicando estos principios ganada gr'andes cuotas de mercado a nivel intemacional con productos muy competitivos.

mejora de la calidad. fOn11aclOn. mejora de la cali dad proyecto por proyecto. AsL se tratan los tenninos requisito.-ill DE SISTEMAS INFOR:'vL. el significado de "ca1idad" cambia desde un enfoque centrado solo en el producto a Lm enfoque de gesti6n organizacional. p1anificacion estrategica de la calidad. 3. En estos anos se empezaron a usar 1a familia de nonnas ISO 9000 en Europa y se desalTollan toda una pletora de premios sobre la calidad (como el Malcom Baldrige :\'acional Quality Award de 1987). entendido como "necesidad a expectativa establecida. Este autor sel'iala como en los ochenta se reemplaza el taylorismo por el enriquecimiento del puesto de trabajo transfiriendo a la mana de obra decisiones y acciones previamente asignadas a los directivos. implicacion de 1a alta direccion. 2000a) se ac1aran diferentes tenninos relacionados con la calidad. por tanto. medicion. equipos de trabajo autodirigidos. de significar cumplir las especificaciones del producto a satisfacer todas las necesidades y expectativas del c1iente. Tambien se define la capacidad de una organizacion. SegllI1 Juran (1995) si el sig10 x. La calidad se extiende a la empresa en su conjunto y pasa a tener la maxima prioridad. En los 70 hubo una crisis de cali dad en estos paises que se supero en los ochenta con exho11aciones a preocuparse por la calidad. como la aptitud para realizar un producto que cumple los requisitos para el mismo. mientras que tanto las empresas norteamericanas como europeas no se habian tomado en serio el tema ya que pnicticamente se vendi a 10 que se producia. sistema 0 proceso. reingenieria de procesos de negocio. autoinspeccion. En los noventa se desalTolla aim mas los temas de calidad y aparecen nuevos enfoques. Se hace enfasis en el autocontrol. extension de los trabajos. En definitiva.\TICOS Durante los 60 y 70 varios productos japoneses aumentaron su cuota de mercado a nivel intemacional.'( fue e1 Siglo de la Productividad. . benchmarking. etc. el siglo XXI sera conocido como el Siglo de la Calidad. la percepcion del c1iente (que puede ser extemo 0 intemo) sobre el grado en que se han cumplido sus requisitos. aumenta continuamente su eXlgencla sobre los productos y servicios que compra. 1995). y la "tercera ola" de control estadistico del proceso (Juran. como Seis-Sigma. generalmente implicita 1I abligataric/' y satisfaccion del cliente. CONCEPTOS RELACIONADOS CON LA CAUDAD En la nonna UNE-EN ISO 9000:2000 Sistemas de gestion de la calidad. es decir. en el momenta en que el c1iente tiene mayores posibilidades de eleccion y que.12 CAUD. FUlldol7lentas y mcabularia (ISO.

Reparacion: accion tomada sobre un producto no confonne para convertirlo en aceptable para su utilizacion prevista. Defecto: incumpliIniento de un requisito asociado a un uso previsto especificado. Sistema de gestion de la calidad: sistema de gesti6n para dirigir y controlar una organizaci6n con respecto a la calidad. Correccion: accion tomada para elimmar una no confonnidad detectada. 0 e Accion Preventiva: aCClOn tomada para elin1inar la causa de una no confonnidad potencial u otra situaci6n potencialmente indeseable.-ivV\ CAPiTULO 1: CONCEPTO DE CAUDAD 13 3. como aceptaci6n del producto 0 servicio: e e e Conformidad: cumplirniento de un requisito. e e e e e Tambien son muy importantes los tenninos relativos a la confonnidad. Una correccion puede ser por ejemplo un reproceso (acci6n tomada sobre un producto no confonne para que cumpla con los requisitos) 0 una reclasificacion (variac ion de la c1ase de un producto no confonne. e e e . Conceptos relacionados con la gestion de la caUdad En esta nom1a se definen otros conceptos relacionados con la gesti6n de la cali dad: e Politica de la calidad: intenciones glob ales y orientaci6n de una organizaci6n relativas a la calidad tal como se expresan fonnalmente por la alta direcci6n. Control de la calidad: parte de la gesti6n de la calidad orientada al cumplirniento de los requisitos de la calidad. de tal fonna que sea confonne con requisitos que difieren de los irUciales). Mejora de la calidad: parte de la gesti6n de la calidad orientada a aumentar la capacidad de clill1plir con los requisitos de la calidad. Accion Correctiva: accion tomada 'para eliminar la causa de una no confonnidad detectada u otra situaci6n indeseable.gRA. No Conformidad: incumplirniento de un requisito.1. Planificacion de la calidad: parte de la gestion de la calidad enfocada al establecimiento de los objetivos de la cali dad y a la especificaci6n de los procesos operativos necesarios y de los recursos relacionados para cumplir los objetivos de la calidad. Aseguramiento de la calidad: parte de la gesti6n de la cali dad orientada a proporcionar confianza en que se cumplinin los requisitos de la cali dad.

. acerca del sistema de gestion de la calidad de la organizacion. interna y externamente. uno de los mayores gunis de la calidad.14 CAUDAl) DE SISTEMAS I]\iFORlvLATICOS ©RA-MA o Desecho: accion tomada sobre un producto no confonne para impedir su uso inicialmente previsto. LECTURAS RECOMENDADAS o Juran. Procedimientos documentados. recopila la historia de la calidad en diferentes paises y epocas. Proporcionar evidencias objetivas. Sin embargo. Planes de la calidad: documentos que describen como se aplica el sistema de gestion de la calidad a un producto. Evaluar la eficacia y la adecuacion continua del sistema de gestion de la calidad. Milwaukee. J.M. instrucciones de trabajo y pIanos documentos que proporcionan infonnacion sobre como efectuar las actividades y los procesos de manera coherente.2. En la nonna ISO 9000 se distingue entre: o Manuales de la calidad: documentos que proporcionan infonnacion coherente. Registros: documentos que proporcionan evidencia objetiva de las actividades realizadas 0 resultados obtenidos. Especificaciones: documentos que establecen requisitos. adolece del defecto de no tratar los logros de calidad en el mundo iberoamericano. GUlas: documentos que establecen recomendaciones 0 sugerencias. (ed. ASQC Quality Press. A History of Managing for Quality. 3.) (1995). que seglin la nonna contribuye a: o o o o o Lograr la confonnidad con los requisitos del cliente y la mejora de la calidad. La repetibilidad y la trazabilidad. proyecto 0 contrato especifico. o o o o e 4. Conceptos relacionados con la documentaci6n de la cali dad Otros conceptos importantes son los relativos a la documentacion. Proveer la fonnacion apropiada. centrandose en los grandes imperios antiguos y en el desarrollo industrial europeo y norteamericano. Este libro editado por Juran.

SITIOS WEB RECOMENDADOS e http://\vww.aec. (. 3. Explore los sistemas de calidad existentes en los imperios Inca y Azteca. e e e 6. http://w\vw. Es posible acceder a una colecci6n interesante de artfculos escritos por sus miembros.-ivLA.com/Web del Instituto Juran donde se puede encontrar informaci6n sobre la actividad de esta organizaci6n basada en las ideas de Juran. ISO (2000a). entre ellas Quality Progress (sobre diferentes aspectos de la calidad en general) y Software Quality Journal (especializado en calidad de software).com/Web de Philip Crosby y asociados. http://\v\vw. pero facilmente de reconocer en su ausencia".philipcrosbv.o RA. Lanhan. seglin Gillies la cali dad es "tr-ansparente cuando esta presente. UNE-EN ISO 9000:2000 Sistemas de gesti6n de la calidad.asq. Se muestra la actividad empresarial de esta organizaci6n. En este libro se repasa la historia de la calidad desde los origenes de las civilizaciones hasta el siglo XXI. Philip Crosby.es La Asociaci6n Espanola para la Calidad es la mas importante a nivel nacional y tiene varias secciones dedicadas a aspectos especificos de la calidad. De las definiciones de cali dad dadas por los gurus y nonnas intemacionales.Quienes las desarro llaban? 2. imposible de medir y facil de reconocer". e 5. e CAPiTULO I: CONCEPTO DE CALIDAD 15 Mouradian. (. .Que funciones 0 roles existian relacionados con la calidad? (. EJERCICIOS 1. entre ellos. Compare estas afirmaciones con las defmiciones de calidad citadas en este capitulo. Y cualla "vista de usuario"? Comente estas dos apreciaciones sobre la calidad: Kitchenham afmna que "la calidad es dificil de definir.org La American Society for Quality es una de las asociaciones mas importantes a nivel intemacional y posee un catalogo de libros relacionados con la gesti6n de cali dad. The Quality Revolution: A Histol) of the Quality Movement. AENOR. Ademas edita varias revistas sobre calidad. http://w\vw. University Press of America.Cmll considera que refleja mejor la "vista de fabric ante" en tenninologia de Garvin (1985)? (. Esta norma intemacional presenta los principales conceptos basicos relacionados con la calidad y establece una tenninologia aceptada en todos los paises iberoamericanos.juran. (2002). Adelmls edita la revista "Calidad". G. Flilldamentos y vocabulario.

para ello puede ser conveniente revisar la norma ISO 10013: Directrices para desarrollar Manuales de la Cali dad. Estudie la evoluci6n de la calidad en las industrias automovilistica.Que diferencia hay entre una "acci6n correctiva" y una "correcci6n"? Ponga ejemplos de ambas. Resuma la historia de la calidad en su pais desde 1960 hasta la actualidad. Explique que actividades de la gesti6n de la calidad podrian considerarse de "control de la cali dad" y cuMes de "asegurarniento de la calidad". implantaci6n de prernios. senalando sus principales hitos: creaci6n de una asociaci6n nacional. farrnaceutica. 6. ConsuIte. 10. 9. y de la ASQ (American Society for Quality). la norma ISO 10005: Gesti6n de la Calidad . . (. difusi6n de normas. Describa la organizaci6n de la AEC (Asociaci6n Espanola de la Calidad). 5. 8. si 10 estirna conveniente. Especifique un metodo para desarrollar un Plan de Calidad. 7. Especifique el contenido que deberia tener un Manual de la Calidad. aeronautica y rnilitar. etc.Directrices para Planes de la Calidad.16 CAUDAD DE SISTEMAS IN'FOfu'vlATICOS ©RA-ivlA 4.

en este libro se ha optado por la propuesta por Okes (2002) para presentar las mas importantes. pronto desclibriremos 10 poco zitiles que somas para Illlestra comunidad ala hora de Gliadir valor a las lecciones que vamos aprendiendo " Dr. INTRODUCCION Las herramientas de calidad son tecnicas y metodos mas 0 menos justificados que ayudan a obtener informacion para mejorar un escenario de calidad. Toda 1.CAPITULO 2 TECNICAS Y HERRAMIENTAS DE CALIDAD §* *'7 & "Si no lIsamos las herramientas de calidad. Frank K. Esa c1asificacion pennite agrupar las herrarnientas en las siguientes categorias. Aunque son muchas las c1asificaciones que se pueden encontrar. CiI herramientas basicas herramientas de gestion herramientas de creatividad herrarnientas estadisticas herrarnientas de disefio herrarnientas de medicion CiI CiI CiI CiI CiI .

Se pueden emplear los siguientes elementos: secuencias de acciones. tiempo empleado en cada uno de los pasos y medidas del proceso. servicios 0 materiales que entran 0 salen del proceso.1.18 CAUDAD DE SISTEMAS INl'OR. 2.1. Identificar y definir las actividades que deben ser desan·olladas y el orden en el que deben hacerlo. personas implicadas.cvlATICOS @RA-lvlA. En los siguientes apartados se expondran los fundamentos de cada una de ellas. finalizando con una reflexion sobre los modelos de madurez y el uso de las herramientas. 2. HERRAMIENTAS BAslCAS DE CAUDAD 2. Simbolos tipicos us ados en los Diagramas de Flujo Para desarrollar un diagrama de flujo se recomienda seguir estos pasos: 1. Definir el proceso que debe ser representado. . Se pueden usar cuando se pretende describir como se desarrolla un proceso.1: alrnac. interne [~ / dato. I Figura 2. Alguno de los simbolos que se puede utilizar son los representados en la figura 2. Representar las actividades como cajas y la transicion entre actividades como flechas de manera que sea posible hacer una traza de este desarrollo. Diagrama de flujo Los diagramas de flujos tienen como objetivo descomponer los pasos de un proceso en una secuencia. 3. 0 cuando pretende establecerse una comunicacion entre personas relacionadas con el proyecto.

. "Maquinas". Para elaborar un diagrama de causa / efecto como el de la figura 2. A medida que el anal isis vaya teniendo niveles mas profundos.sirven para el problema? 2.. Identificar Calidad Dlme"'o. Ejecutar el Plan de Mediciones 3.fedio Ambiente" y "Merodos". r I I 1. Ie Uegaran ou"as secundarias con posibles subcausas relacionadas con dichos focos. facilita y potencia el u"abajo en grupo.CAPiTULO 2: TECNICAS Y HERRA1\1IENTAS DE CAUDAD 19 4.:. combinada con ou"as de identificacion de problemas como la tormenta de ideas. "Materiales". Realizar un plan de mediciones Figura 2.2.3 se puede seguir este procedimiento (Can-etero et al.. y mostrar todas las posibles causas de un problema especifico (efecto).2 representa un ejemplo de diagrama de flujo. explorar. Identificar Metricas para esas dimensiones N~----------~ 5.2. 1999): . A estas flechas. a donde llegaran las otras fechas provenientes de los posibles focos de los problemas que generan el efecto que se esta estudiando. Los focos plincipales suelen enunciarse como las 5 0 6 M: "j\1ano de Obm". de -. las subdivisiones iran ampliandose. Su representacion consiste en un rectangulo situado a la derecha del esquema donde se indica el efecto que se quiere analizar.r _ __ .. "j\. Ejemplo de Diagrama de Flujo 2.0btener Conclusiones 4. La figura 2. Diagrama causamefecto Tambien llamado diagrama de espina de pescado (por su forma) 0 diagram a de Ishikawa (por su creador). Se dibuja una flecha de entrada (a modo de columna vertebral del pescado) a este rectangulo. Es una hen-amienta que. Revisar el diagrama de flujo con otras personas implicadas en el proceso para llegar a un consenso sobre su validez. "Medidas".. el diagrama causa-efecto es una helTarnienta que se utiliza para identificar.

IDAD DE SISTEM.A. Dibujar el diagrama de la espina de pescado. . identificar la causa raiz que permita obtener conclusiones en la resoluci6n del problema. 4.TICOS ©RA-MA Medidas Materiales Personal Exactitud Compilador Programadores Tiempo SGBDR Analistas -ilJ. Identificar de 3 a 6 espinas mayores que puedan ser las causas del problema / efecto principal. y as! sucesivamente. 3. Elaborar un enunciado claro del efecto (problema) que se ha detectado. Ejemplo de diagram a causa/efecto 1. 2.3. Dibujar las espinas mayores como flechas inclinadas dirigidas a la flecha principal. Identificar causas de tercer nivel para cada causa de segundo nivel.S INFORt\tA. 7. 8. ."J. Observando los resultados.> Fallos en los Sistemas Informaticos Ratones Sueldos bajos Inferencia Impresoras Presion Procesamiento Orden adores Medio Ambiente Metodos Maquinas Figura 2. colocando el efecto (problema) en un cuadro en ellado derecho. Identificar causas de segundo nivel para cada causa de primer nivel.20 C. 5. 6. Identificar causas de primer nivel relacionadas con cada espina mayor.

5. 7. Reunir los datos y efechlar el calculo de porcentaje de las frecuencias de apmici6n. Identificar el problema a analizar. Luego se divide el eje horizontal en un numero de intervalos igual al l1l1mero de items clasificados. Dibujar dos ejes verticales y un eje hOlizontal. Diagrama de Pareto Es una hen-amienta utilizada para establecer lma jerarquia de los problemas 0 las causas que los generan. dando una idea clara y cuantificada del orden en que deben ser abordados estos problemas o causas. a partir de una representacion gnifica de los datos obtenidos. se traza una linea horizontal a partir del eje vertical derecho. Escribir cualquier informacion necesaria sobre el diagrama (titulo. Construir un grafico de ban-as con el mism0 ancho y sin dejar espacio entt'e ellas: este grMico esta bas ado en las cantidades y porcentajes de cada uno de los items colocandolas de mayor a menor y de izquierda a derecha Dibujar la curva de frecuencias acumuladas. Establece que "al eliminar el 20% de las callsas que generan lin problema en lIna sitllacion resalveria 1111 80% de elias. mientras que el 80% de las cal/sas restantes resllelven el 20% de los problemas restalltes".) y sobre los datos (periodo de tiempo.) 2. EI nombre de Pareto fue dado a esta heiTamienta por Juran en honor del economista italiano Wilfredo Pareto que definio la regIa 80/20 para explicar la disttibucion de las riquezas. Una vez en esta disposicion.-\PITULO 2: TECNICAS Y HERRAlv!lEJ\TAS DE CAUDAD 21 2. Ordenar los datos en orden decreciente de frecuencia. Para elaborar un diagrama de Pareto hay que seguir los siguientes pasos: 1. Para detenninar las causas de mayor incidencia en un problema. 6. unidades. 4. 9. fvIarcar el eje vertical izquierdo con la cantidad de causas acumuladas y el derecho con una escala de 0% hasta 100%. 3. decidiendo los datos y la fom1a de clasificarlos y definiendo ei metodo a utilizar en la recopilacion de datos. departamento implicado.s RA-ivV\ C. l1umero total de datos. 8. etc. seleccionando los problemas 0 variables que se van a investigar.3. calcular las frecuencias acumuladas para cada causa. etc. desde el punto don de se indica el 80% hasta su . Disei'iar una hoja de recopilacion de datos para que gum'dar datos sobre las causas a investigar y el nlunero de veces que aparecen.

indicando quien. Para ello establece los l11ecanismos necesarios para reunir y clasificar los datos recabados seglll1 detenllinadas categolias. etc.. distribucion de variaciones de variables de los articulos. Los items comprendidos entre esta linea veltical y el eje izquierdo (de cantidades acumuladas) constituyen las causas cuya eliminacion resuelve el 80% del problema. Chequeo 0 Cotejo sirve para identificar y analizar tanto los problemas como sus causas. Lista de Velificacion.4.. por un lado. Para ello es preciso. Hoja de chequeo 0 de comprobacion La Hoja de Recopilacion de Datos tambien llamada Hoja de Registro.. Ejemplo de diagrama de Pareto 2. las causas identificadas como A. Figura 2. en la que se almacenan'll1 los datos: por otro... . c1asificacion de articulos defectuosos.4.. Diagrama de Pareto -- . mediante la anot~cion y registro de sus fi'ecuencias para cada uno de los contextos posibles: verificacion (inspeccion.. definir una estnlchlra.. . Desde este punto trazar una linea veltical hacia el eje horizontal.4.-MA interseccion con la curva acumulada. localizacion de defectos en las piezas. como y cuando hacer la planificacion y la caphlra..21 CALIDAD DE SISTEMAS INFOfu'vlATICOS ©RA. Asi en el ejemplo mostrado en la figura 2. -- -=< -- -- - -- . chequeo 0 tare as de mantenil11iento).. G y F representan ese 20% de las causas que alTeglalian el 80% de los problemas. especificar el procedil11iento de recopilacion y analisis de dichos datos. - -- -- -- - 2-.

LCS Y LCI para un diagrama de control I Es posible detinir Llna serie de tests que demuestran estadisticamente que el proceso esta bajo control. chequeo 0 tareas de mantenimiento. etc. inspeccion. Grafo Diagrama de control Son representaciones gnlficas utilizadas para detem1inar desde un punto de vista estadistico si un proceso esta 0 no bajo controL esto es.5. 0 I) I) 2.5). . longitud. Los graficos de control sil-ven para representar una caracteristica de cali dad medida o calculada a partir de muesh'as del producto que son tomadas a 10 largo de un espacio de tiempo. Consta de una linea central (que suele ponerse en tomo a la media muestral ~l) y dos limites de control superior (LCS) e inferior (LCI) que se basan en conceptos y resultados estadisticos l (vease figura 2. si hay variabilidad en el proceso y descubrir a que obedece esta variabilidad. La variabilidad es cualquier desviaci6n que el producto 0 servicio final puede tener respecto a la especificacion de los usuarios y que puede ser deb ida a cualquiera de los elementos. De localizaci6n de defectos en las piezas.Ll LCI Figura 2.£ RA-ivl"'- CAPiTULO 2: TECNICAS Y HERR.-\lVlIENTAS DE CAUDAD De modo general las hojas de recopilaci6n de datos se pueden c1asificar seglin el tipo de datos en: o I) De velificaci6n. aunque todos los puntos es«~n entre los dos limites. De dishibuci6n de variaciones de variables de los articulos (peso. De c1asificaci6n de articulos defectuosos.). volumen.5. LCS . calidad.

24 CALIDAD DE SISTEvl!\S INFOIUvi~TIeos @RA-MA En el gnifico se dibujan los datos correspondientes al proceso. 2. Decidir el tipo de gnlfico de control por vatiable que deb a utilizarse. puede decirse que el proceso esta bajo control. 3. Los pasos que hay que dar para elaborar un diagrama de control pOl' variable son los siguientes: 1. Detenninar el indicador de calidad que mejor describa la situacion de calidad a controlar. Se utiliza cuando el tamai'io de las muestras es inferior a 10 (vease figura 2.5.1. se pueden crear distintos tipos de grafos de control por variables.1.7). Gnificos de Control por Variables Se utilizan como indicadores de calidad algunos parametros estadisticos asociados a los valores medidos en las muestras de los productos tomados a intervalos regulares de tiempo.1. Analizar el grafico y actuar sobre el proceso en funcion del resultado obtenido. Representar el gnifico con una helTamienta software adecuada. Como minimo se recomienda tomar unos veinticinco valores. @ @ . media. 4.6). 5. 2.tudiar. S 0 de desviaciones tipicas (cr): pennite estudiar como varian las desviaciones tipicas de los valores muestrales estudiados. Si todos los puntos estan entre estos dos limites. TIPOS DE DIAGRANIA DE CONTROL Existen dos familias de graficos de control: por variables y por atributos. 2. 6. R 0 Recorrido: pennite esmdiar como varian los rangos de los valores muestrales estudiados. En funcion de como esten agrupados los datos de las muestras y de los estadisticos que se quieran es. Ca1cular los panimetros estadisticos necesarios (tamafio de la muestra. Tomar valores del indicador de muestras a intervalos regulares de tiempo. Estos tipos son 16S siguientes: @ X-Barra 0 de Medias: pennite estudiar como varian las medias de las muestras estudiadas (vease figura 2.5. recorrido y limites de control). Se utiliza cuando el nllmero de muestras es superior a 10.

16 i8 20 22 24 Figura 2. (I) E 260 co 240 220 LQ=210.5 3G'O co Q.5 o 2: .I X=275 i5. 12 14 Sample . 4 6 8 10 12 14 Sample 16 18 20 .l L 280 c Q.5 200 .6.7. 6 8 10 . 22 lCL=:O 24 Figura 2.£ RA-MA CAPiTULO 2: TECNICAS Y HERRAJvlIENTAS DE CAUDAD 25 Grafico XBarra de Fallos de Sistema de Informacion 340 320 UCL=339. 2 4 . Ejemplo de Grafico de Control de Medias Gr6fico It de Fallos de Sistema de Informacion 200 R=88. Ejemplo de Grafico de Control de Recorrido .

. entonces la distribuci6n seria sesgada. .:===..::=:::. Grafico XBarra-R de Fallos de Sistema de Informacion 350~-------------------------------------------------' UCL=33'i/5 2M~-.:=:::.__.1.8. .. Es interesante siempre comparar la media de los rangos con la variaci6n pen-nitida (vease figura 2. __. .__.:===..===.O \ /1'. eX-Barra! Rode Medias-Recorridos: son la representaci6n conjunta de un gritfico X-Ban-a con uno R. Dichas muestras no tienen por que . v--J+-<\. .__. por 10 que para elaborar un diagrama de Control por Atributos se sigue un procedimientC1 similar al descrito para los graficos de control por variables. Se supone que si la variable estudiada sigue una distribuci6n nonnal.8).__.::=:::..__.2 14 1$ 1S 20 sample lCL=21O.:===.. / /~ ~/~\J\ / '-J / 8 10 12 14 5ample UCL=ZCJZ.S Il'iFORMATICOS © RA-ivlA.26 CAUDAD DE SISTEiVlA.5 200 1-========================. 16 18 20 ~ 2+ ---" L:::::. Ejemplo de Griifico de Control de Medias/Recorrido 2. entonces X-Ban-a y R son independientes. -__..:===...J L~L=O 22 Figura 2.::=:::. Si se presentan gritficos paralelos. . -__.5. Gnificos de Control por Atributos El contexto estadistico en el que se desan-ollan esta regido por los mismos principios que los graficos de control por variables.=-. -__. Tipo p 0 de Proporcion de Unidades No Conformes: es un grafico de control que pennite representar la proporci6n de unidades no confonnes de cada muestra respecto del tiempo.2. J 10 1. Es posible hacer la siguiente clasificaci6n atendiendo a 10 que se pretende estudiar: ® Numero de productos defectuosos: se pretende evaluar si el proceso esta 0 no bajo control atendiendo al numero de productos defectuosos que genera. Es posible encontrar los dos siguientes tipos de diagramas: a.__..::=::.::==.

11 muestra un ejemplo de este tipo en la que el proceso no esta bajo control.9 muestra un ejemplo de un gnifico de control por atributos de la proporci6n del numero de defectos. En funci6n de la profundidad del estudio se pueden encontrar los siguientes tipos de diagramas de control de esta clase: c.6 ::: 0. La figura 2.3 0. Al realizar la inspecci6n de un atributo se clasifican las unidades en conformes 0 no confonnes (np). Se pretende detenninar si el proceso esta bajo control.1 P=0. La figura 2. e Numero de Defectos por Producto.7397 0.2 0. Tipo Code numero de no conformidades: pennite representar el numero de defectos 0 de no confonnidades de todas las unidades producidas con respecto al tiempo. .CAPiTULO 2: TECNICAS Y HERRA. Grafico P de Datos Invalid os 0.0 2 4 6 . Ejemplo de Diagrama de Control por Atributos tipo p b. 8 10 12 14 lCL=O 18 8<3mple Tests perfbrmed with unequal sample sizes Figura 2. Pennite analizar tanto el mimero de unidades no conformes como la posible existencia de causas especiales. estudiando el numero de defectos que tiene cada producto. La figura 2.'vllENTAS DE CAUDAD 27 ser del mismo tamafto. Tipo np 0 de Numero de Unidades no conformes respecto del tiempo: es un gnifico de control que pennite representar el numero de unidades no conformes de la muestra respecto del tiempo.:: 13 o Q.4 is: 0. EI tamafto de las muestras puede variar en cada inspecci6n.10 muestra un ejemplo de un tipo de gnifico de control por atributos de unidades no confonnes. Para ella se contara el numero de defectos c que tiene cada muestra.5 o :.2692 0. 0.9.8~------------------------------------------' lJCL=O.

0 CJ "E. El histograma puede ser usado para: CD Obtener una comunicaci6n clara y efectiva de la variabilidad del sistema.5 01 E 10.5 UCL=21. 12. pero se realiza calculado la media del numero de unidades no conformes de una muestra.LA.99 20.''m. Graficos NP de Datos Invalidos 22.28 CALIDAD DE SISTE!vL~S IN"FORt\. CD CD CD . Se trata de un instrumento de sintesis muy potente que permite apreciar la tendencia de un fen6meno.10.0 : : Alr' .. Histograma EI histograma 0 diagrama de distribucion de Jrecuencias es una representaci6n gnifica por medio de barras verticales.5 ~ III 5 15.61 1 3 6 ffi ill v ~ Sample Figura 2. Tipo U 0 Numero Medio de No Conformidades: este tipo de diagrama deriva del anterior. Comparar la valiabilidad con los lirnites de especificaci6n.0 17. Diagrama de Control por Atributos tipo np (generado con Minitab) 2. Identificar anormalidades examinando las formas del grafico.TICOS ©RA-MA d. \ 1 1 1 V~ 9 U (~ ~ 1 '¥aT\ 1 ~ LCL=5. Mostrar el resultado de un cambio en el sistema.6. que ilustra la frecuencia con la que ocurren eventos relacionados entre sf.

11. Estos pares de puntos se dibujan en un diagrama en el plano como una nube. . En caso de haber relaci6n.7.96 LCL=O 2 4 5 8 10 12 Sample 14 15 18 20 Figura 2.l'v!lENTAS DE CAUDAD 29 Grafico C de Datos Invalidos 12 10 UCL=1l. etc.12. distorsionado. e "y" el valor del factor que se considera influido (consecuencia). cortado. se espera que esta relaci6n sea lineaL aunque otras funciones polin6micas son posibles.GRA-MA CAPiTULO 2: TECNICAS Y HERRA. Visualizando ambos graficos se puede apreciar distintos tipos de histograma seglin su fonna: nonnal. Diagrama de Dispersion 0 de Correlaci6n Tambien llamada Diagrama de Correlaci6n: esta heITamienta sirve para estudiar una posible relaci6n entre dos vaIiables objeto de estudio de un control de calidad. Nonnalmente. Diagrama de Control pOl' Atributos tipo c Adjunto al histograma es recomendable realizar un grMico denominado poligono de frecuencias trazado sobre las marcas de clase de las barras del histograma. bimodaL de dientes rotos 0 de peine. (estas clases ficticias tienen una frecuencia cero). Un ejemplo de histograma es el mostrado en la tigura 2. hasta la marca de clase posterior a la ultima. 2. Los datos serall en la fonna (x. Se fOlma uniendo los pumos fonnados por la intersecci6n de la marca de clase 0 punto medio. La observaci6n de esta nube pem1itira detenninar si hay 0 no relaci6n entre ellas. con la fi:ecuencia absoluta 0 con la relativa desde la marca de clase antelior a la primera clase. Para ella es preciso reunir datos de sucesos oClm-idos don de participan los dos factores que se pretende detem1inar si tienen 0 no relaci6n.y) donde "x" representa el valor que se pretende detenninar si influye (causa). se espera poder expresarla como una funci6n matematica y f(x).

!vL~ TlCOS © RA. Si r > 0. entonces no hay correlaci6n entre los dos factores estudiados. HERRAMIENTAS DE GESTION 3. Fue creado por Kawakita en los atlOS sesenta. que indicara la fuerza de la relaci6n. positiva. Cuanto mas cerca este r de 1 6 -1 mas fuelte es la relaci6n entre los dos factores. . y fueltemente negativa.-IvL>\ 120 iOJ - 5J 20 i70 168 iSJ 208 210 Figura 2. la magnitud de la consecuencia decrece. entonces a medida que la magnitud de la causa crece.13 muestra las diferentes relaciones que pueden darse: correlaci6n fueltemente positiva. Si r<O. Diagrama de afinidad Los diagramas de afinidad sil"Ven para organizar un gran nlunero de ideas en categorias relacionadas. la magnitud de la consecuencia tambien.12. y si esta es positiva 0 negativa: iii Si r es cero. 0 afines (Tague 2005).1. iii iii iii 3. Como resultado del amilisis se obtendra un coeficiente de correlaci6n r. negativa. entonces a medida que la magnitud de la causa crece.30 CAUDAD DE SISTEMAS I]\iFOR. Ejemplo de Histograma La figura 2. Las ideas suelen venir de sesiones de trabajo 0 de sesiones de Tonnentas de Ideas. no correlaci6n.

Registrar todas las ideas y conceptos que sUljan en el glUpO de trabajo. Esta herramienta ayuda a un gmpo de trabajo a identificar los enlaces naturales entre diferentes aspectos de una situaci6n compleja.2. 2.13. Los pasos que hay que dar para elaborar un diagrama de relaci6n son los siguientes: 1. en funci6n del grado de Q 0 0° v 0 0 0 C 0 0 0 0 y Q 0 0 o 0 °0 0 C 0 00 0 No Correlacion 0 y 0 0 0 0 0 0 c 0 Correlacion Negativa 0 x 0 x 0 0 0 y o 0 0 0 c 0 00 Correlacion Positiva y o o c o 0 0 0 c (.::" 0 0 0 00 C 0 c Correlacion Compleja y 0 0 0 0 00 0 0 00 00 0 00 Correlacion Fuertemente Positiva Figura 2.CAPiTULO 2: TECNICAS Y HERRAMIENTAS DE CAlIDAD 31 Para elaborar un diagrama de afinidad. 3. Diagrama de relaciones Es una herramienta utilizada para identificar las causas mas significativas de un problema y representar graficamente los vinculos que puedan existir entre los factores relacionados con ese problema. Crear categolias generales para esas ideas basandose en criterios de afinidad. Tipos de diagramas de correlacion 3. Los diferentes elementos del diagrama se relacionan entre SI con flechas. se recomienda seguir estos pasos: 1. . Asignar cada idea afinidad. 0 0 o o 0 00 0 0 0 C 0 X 0 0 0 . 0 concepto a dichas categorias. Identificar todas las causas posibles de un problema.

14.15 representa un ejemplo de diagrama mahicial.. se l11arca en la intersecci6n de los factores.. La figura 2. Proponer una causa como la mis probable Estudiar la relaci6n entre esta primera causa y el resto de las causas. Es posible que haya diferentes niveles de relaci6n. 5 3 Figura 2. A c D B Figura 2.3.. Repetir la iteraci6n hasta encontrar la causa que mas relaciones tenga.. Para ella hay que colocar los factores sobre las filas y colunmas de una l11atliz.COi'iiE:'<IDOS -4 S£GI3RIDAD -:c. sefialando con flechas las relaciones que vayan surgiendo. Ejemplo de Diagrama Matricial . Es posible indicar el grado 0 intensidad de la relaci6n existente. V£LOCIDAD VEWCIDAD . Descartar en cada iteraci6n las causas no seleccionadas. . Se suele utilizar para definir la relaci6n enh·e los distintos factores que intervienen directa 0 indirectal11ente en un proceso de mejora de calidad. La figura 2.32 CAUDAD DE SISTElvL~S n'iFOIUvlA. ~ I I I I S£GGRIDAD ! I I I .15.14 muestra un ejemplo de diagrama de relaci6n. pennite representar grafical11ente la relaci6n existente entre varios factores. Diagrama de matriz 0 matricial Al igual que oh·as henamientas de las citadas hasta ahora.TICOS ©RA-lvL~ 2. 4. 3. 5. Ejemplo de Diagrama de Relacion 3.COl'T£NIDOS 3 . Si existe relaci6n.

Diagrama de arbol Se utiliza para representar jenirquicamente los diferentes niveles de complejidad de un detenninado proceso 0 producto. Tienen un principio y un final. La figura 2. holgura. que relaciona dos grupos de elementos entre sl. Hamada L-Shape. Como las flechas indican caminos. . 3. partiendo de un primer nivel generico que se va descomponiendo en niveles de mayor detalle hasta alcanzar un nivel basico 0 autodescriptivo. Diagrama de redes de actividad 0 de flechas Figura 2. Diagrama de redes de actividad Son una herramienta de planificaci6n que se emplea para representar gnificamente y de forma estructurada la secuenciaci6n de actividades que hay que desarrollar en un plan de mejora de calidad siguiendo un orden cronol6gico. 3. Se sue Ie utilizar para implantar planes de actuaci6n de cierta complejidad.7.6. Diagrama de proceso de decisiones Define un plan de actuaci6n de cara a resolver un problema detenllinado.4.16 muestra un ejemplo de este tipo de diagrama. 3. Matriz de anal isis de datos Algunos autores como Tague (2005) identifican esta herramienta como un sUbtipo de la anterior.ivIIENTAS DE CAUDAD 33 3. La infonnaci6n que se debe mostrar es la duraci6n de cada tarea.s RA-ivL\ CAPiTULO 2: TECNICAS Y HERRA.5. con 10 que es posible estimar eminto tiempo se va a necesitar para desarrollar el mencionado plan. es posible identificar caminos criticos en la realizaci6n del plan. 0 incluso relaciona los elementos dentro del mismo grupo.16. dependencias entre actividades.

Se tiene que planificar una agenda para facilitar la asistencia e todos los miembros. Se pretende obtener el mayor numero de ideas 0 soluciones en el menor tiempo posible. Esrudia la viabilidad de cada plan de contingencia. Los problemas resultantes poddan mosh·arse como un cuarto nivel.-MA Para elaborar un diagrama de este tipo. 5. Es una herramienta de trabajo en grupo basada en la creatividad de los componentes del grupo de trabajo. Estos planes se pueden mostrar en un quinto nivel. Existen dos modos de realizacion de esta tecnica: EI Modo estructurado: todos los miembros del grupo se yen forzados a participar. 3. Para cada problema potencial. aquellas que mejor se adaptan a los objetivos del problema. las actividades pl1ncipales para conseguirlas y en el tercero. Se crea un ambiente mas relajado pero se corre el peligro de que haya personas que no participen y por tanto no se conozcan sus ideas. Revisar todas las listas de problemas potenciales y eliminar aquellos que sean improbables 0 cuyas consecuencias pudieran llegar a ser poco significativas. teniendo en el primer nivel el objetivo del plan. identificar planes 0 acciones de contingencia que mitiguen los efectos de esos problemas. Para cada tarea del tercer nivel identificar que es 10 que podria salir mal. una lista de tareas para cada una de esas actividades. Modo Iibre: los miembros del grupo van aportando ideas seglll1 se Ie van a ocun1endo sin seguir ningUn ru1110 preestablecido. . siguiendo un hImo riguroso . seleccionando poste1101111ente las mas indicadas. 2. Obtener 0 desarrollar un diagrama de arbol con el plan propuesto. se deberia seguir este procedimiento: 1. 4. HERRAMIENTAS DE CREATIVIDAD Aunque existen herramientas de creatividad como los mapas concephtales. Para ella es necesar10 que el equipo de trabajo conozca dichos objetivos. aqui se presentani solo la tonl1enta de ideas como la mas utilizada.34 CAUDAD DE SISTEMAS INrORJvLA. etc. es decir. mar·cando con una "X" los impracticables y con una "0" los que Sl poddan llegarse a dar. EI Las fases de una tonl1enta de idea son: EI Definicion y comunicacion del asunto a tratar a todos y cada uno de los miembros del gmpo.. el usa de analoglas. 4.TICOS @RA. en el segundo.

Cuando se mantiene estable a 10 largo del tiempo se dice que esta bajo control. b. Los pariicipantes van apOliando ideas en alguno de los modos expuestos anterionnente y el moderador 0 director de la reuni6n las va a anotando en alglin lugar visible por todos los pariicipantes. b. c. Control estadistico del proceso Se entiende por capacidad de un proceso el grado de aptitud que tiene para cumplir con las especificaciones tecnicas deseadas. Para determinar si un proceso es 0 no capaz. indices cenrt·ados con respecto a los limites indices descentrados con respecto a. d. se dice que es capaz. Se considera un indice de Capacidad como la relaci6n entre la variaci6n natural del proceso y el nivel de variaci6n especificada. todos los miembros deben seleccionar aquellas dimensiones que mejor se adapten al objetivo de la medici6n. se pueden utilizar las siguientes herTamientas: e e e e Histogramas Graficos de Control Graficos de Probabilidad Estudios de indices de capacidad Este apartado se centrara en los estudios de los indices de capacidad. Cuando la capacidad de un proceso es alta. HERRAMIENTAS ESTADisTICAS 5. A corto plazo 0 intragrupo (Capacidad Potencial) A largo plazo 0 intragrupo e intergrztpo (Capacidad Global) . Se pueden hacer dos clasificaciones: e Respecto a su posici6n: a.CAPiTULO 2: TECNICAS Y HERRAMIENTAS DE CAUDAD 35 e Exposicion de ideas.1. descartando las peores. e 5. Seleccion de ideas.los limites pero contenidos en ellos S610 con limite superior S610 con limite inferior e Respecto a su a1cance temporal a. Cuando ya no haya mas ideas.

~ > IJSL ~::~~E>e. LSL 1710$0. se defme el indice de capacidad de proceso como: C p = LS-LI 6u CPK = A1in{ LS ...!YLA.2.23 0.' h"{lERGRllPO PPU PPL Figura 2..L ::1S.:2 := U~!.-liIun.18. } 3u 3u 10 Para afinnar que un proceso es capaz Cp y/o CPK deben ser mayor 0 igual que 1.33. Ejemplo de Estudio de Capacidad de Proceso (generado con Minitab) . Tet::.36 CAUDAD DE SISTEMAS INFOR.. ll 1775.90 Exp.=: l$l :i~':.bility 5"rnpl-= S.31) 0.. Cpm *" 1740 1750 1780 1800 1820 1840 1960 <. p~r"'1 V'!ithin P. que garantiza que el 99.:. iNDICES DE CAPACIDAD C p. 15313 StD.i r= U.: ::..:. P p. 293308:9 28 .-\GRD'. ambos deben valer como minima 1.1. En caso de ser necesario estudiar los dos.. Estudio de Capacidad del Proceso " Deteccion de fall os en el Sistema de Informacion" L5l Prv-:~ss USl LSL D.rtlp.:r.: 0.J .JIOOOO --Within - - Over311 Cp CPL I 0.33 E~p.PO E.: ppr'il =: LSL 1E>Ui4J$(' ppr·.an:.2r.! 377003.-.·' 3':1£2£9.! 413333 . habra que aplicar acciones con'ectoras. CC?~~ Overall Ca~'!!biSty Pp 0.)S7 ppr'..l-....·SSS!G7 ~·pr..b:.. C PK Y PPK Sean LS Y LI los limites de tolerancia exigidos en las especificaciones.tr'. Definicion de los tipos de indices de capacidad 5.a.J j.3? 02~ PPl PPU P~k 0. En otro caso.a:t. Tot~1 2::S1S'~J'Je: PPM PPf. (j:2~: <::pl..LI .:vi)\IHhirl) StD.1.32 * Potential (Vnthin) Cap.17.33.v(O'~·\:r~!f) CPLI QJ.TICOS ©RA-MA CORToPL4Z0 ' (h"i"IRAGRl1J>O) LARwPtAZO (h'i-m. (J<[o:n:ll Po:rTorm..994% de los productos fabricados 0 servicios prestados por el proceso centrado esta dentro de las especificaciones. PPhl Tot.C1C)OCI 1825./-=d P-=tfQtrnamo: PPM .!~ ""-=::tl) N 18(t2)~S 149 1:..01) Figura 2.j..n~.

-MA CAPiTULO 2: TECNICAS Y HERRA. Revisar las decisiones anteriores. Identificar las causas posibles de variacion. bien superior (CPU y PPU). PPL). 3.QRA. 2. Esquematizar los pasos del analisis estadistico. 7. 5. Se ca1culan: CPU = L530- CPL = jl-LI 30- 5. cuantificarla (Vilar. 2006). Especificar el modelo (lineal. etc. PPU. bien inferior (CPL.2. Design of Experiments) tiene como objetivo averiguar si unos deterrninados factores influyen en una 0 varias variables de interes para la calidad. Especificar medidas y procedirniento experimental.2. INDICES DE CAPACIDAD CPU.). PPL Se utilizan cuando el proceso solo tiene un limite de especificacion. 6. Elegir el disefio experimental adecuado. Las etapas de las que consta un DOE pueden resumirse en: 1. .1. y si se demostrara dicha influencia. y que por tanto habra que aplicar correcciones 5. DOE. Deterrninar el tamafio muestral.MIENTAS DE CAUDAD 37 En la figura 2. ni a largo ni a corto plazo. Ejecutar un experimento piloto. CPL. Defmir los objetivos del experimento.18 se muestra un ejemplo donde mediante la observacion de los indices de capacidad potencial y global puede deducirse que el proceso no es capaz. 4. 8. 9. Diseno de experimentos El Disefio de Experimentos (DDE.

2. donde se relacionan las necesidaaes del c1iente con las caracteristicas del producto 0 servicio a disefiar. HERRAMIENTAS DE DISENO 6. Fase de Identificacion y Amilisis de Necesidades. donde se van a relacionar las caracteristicas y requisitos de los componentes analizados y ponderados en la mahiz anterior con las especificaciones del proceso de fabricaci6n 0 prestaci6n del servicio. manteniendo y mejorando la calidad. se analizan y se interpretan por los miembros del grupo de u'abajo y finalmente se relacionan con las caracteristicas del producto que deben sintonizar con los requisitos de los c1ientes. componentes subsistemas mas significativos del proceso. A partir de este punto comienza el desarrollo del QFD. delimitandolo en el tiempo. Estas personas deben tener experiencia demostrable y pertenecer a los distintos departamentos implicados en el proyecto. 0 c. La principal ventaja de esta tecnica es la reducci6n del tiempo del disefio y la disminuci6n de los costes.1. definiendo tanto el objetivo del proyecto como los miembros del equipo que deben trabajar en el. 1999): 1. Tambien es necesario revisar el objetivo del proyecto para adaptarlo a los recursos de la empresa.. 3. lv!atriz de desp/iegue de componentes. En esta fase es donde se recopilanlos requisitos del c1iente. cuyo objetivo es que los requisitos del c1iente lleguen a estar completamente contenidos en las espcificaciones tecnicas del producto 0 servicio. . Fase de Organizacion: donde se delimitani el alcance del proyecto. b. Fase de Definicion. En esta fase se realiza la programaci6n temporal del proceso. Para ella se suelen utilizar cuatro tipos de matrices importantes: a. lv!atriz de planificacion del producto 0 servicio ("casa de la calidad'). Para realizar un proyecto usando QFD se deberian seguir estos pasos (Carretero et al. y planificando temporalmente la duraci6n y las precedencias de cada una de sus tareas. Matriz de planificacion del proceso.38 CAUDAD DE SISTEivL<\S INrORo'viATICOS 6. siendo su finalidad definir las especificaciones 0 caracteristicas de las piezas. QFD (Quality Function Deployment) El Diagrama de Despliegue de la Funci6n de Calidad (Quality Function Deployment) es una tecnica utilizada para planificar nuevos productos y servicios 0 realizar mejoras en los existentes a partir de metodos mauiciales.

de su frecuencia de aparici6n y de 10 facil que sea detectar esos fallos.2. mejorar y establecer ill1 contexto de aseguramiento continuo de la calidad y aumentar la fiabilidad de los productos. Los fallos se priorizan de acuerdo a la gravedad de sus consecuencias. . Analizar los Resultados 11. Para completar esta fase. jvlatri::. Iterar el Proceso 6. la programaci6n y los puntos de control del proceso de producci6n. En la fase de identificaci6n y analisis de necesidades es donde tiene lugar la planificaci6n critica. habria que realizar las siguientes actividades: 1. Seleccionar un Producto/Servicio Importante a Mejorar Obtener la Voz del Cliente Identificar las Necesidades del Cliente Organizar las Necesidades del Cliente 5.~ RA.-ivlA CAPiTULO 2: TECNICAS Y' HERRAMIENTAS DE CAUDAD 39 d. que va a recopilar la relaci6n entr'e las especificaciones del diseno (registradas en la matriz de planificaci6n del proceso) y la normas de producci6n. 3. Establecer los Parametr·os de Diseno Generar la Matriz de Relaciones Obtener la Evaluaci6n de Desempeno del C1iente Correlacionar los Parametros de Diseno 10. Priorizar las Necesidades del Cliente 6. 9. AMFE (Analisis Modal de Fallos y Efectos) AMFE (Failure Modes and Effects Anafysis-FiViEA) es un proceso sistematico. centr'andose principalmente en las definiciones del producto 0 servicio. estableciendo el procedimiento. planificado y participativo que se aplica cuando se disenan nuevos productos 0 procesos 0 cuando se rea1izan modificaciones importantes para evaluar 0 detectar fallos y causas que se originan antes de que lleguen al c1iente. Este proceso perrnite reducir costes y tiempos. 8. 4. as!. habria que trabajar sobre cada una de las matrices de la figura 2. 7.19. de pfantficacion de fa prodllccion. 2.

. 1999) .J (j .40 CAUDAD DE SISTEivLA.s c.1 muestra la infonnaci6n basica que se necesita manejar para realizar un AMFE.. Estructura de la Matriz "Casa de la Calidad" (Carretero et aI. Consta de los siguientes campos: Tabla 2. Docurnentaci6n basica del AMFE (Carretero et at. 1999) La tabla 2...>. Clz ~Gl 0 3> oS: 0:3: "en W w EVALUACION Ponderaci6n de Requisitos Figura 2.1.19.Sl we "Ill > enu U « u 0 inO ~~ _ N 0'" wZO MATRIZ DE RELACIONES u::. > "t:I" "'.S IN1'ORr'vlATICOS ©RA-MA ~ CARACTERisTICAS DEL PRODUCTO La voz dellngeniero I- z ::i U w w .J..

o o 0 • Mada de Falla: es la forma en la que el elemento estudiado puede dejar de cumplir las especificaciones para las que fue disenado. aunque no este observado par el cliente. deficiencias en el diseno del producto. Si se presentan varias funcionalidades. ya que pueden dar lugar a distintos modos de faUo. Habria que describir a que areas puede afectar el faUo: si a seguridad. Indice de Deteccion (D): es el val~r que mide la probabilidad de que la causa y el faUo Ueguen al cliente. en este apartado deben completarse todos los datos correspondientes a las diferencias de funcionamiento observadas. medio ambiente. salud. o • Evaluacion de la Prioridad: que comprende los siguientes conceptos: o Controles preventivos: hay que reflejar los resultados de los controles preventivos previamente realizados a la aparicion del faUo. deficiencia en los materiales usados. servicio o proceso. . funcionamiento correcto. Este indice de gravedad esta tabulado y es funcion creciente de estos factores: insatisfaccion del cliente. Indice de Prioridad de Riesgo (JPR): mide cuales son los fallos cuyas probabilidad de riesgo es mayor. para estudiar si es el resultado de un accidente fortuito 0 bien es por causa de alglin tipo de desgaste. Se obtiene calculando el producto de los tres indices anteriores: IPR= F·G-D. Fallo: se refiere al incumplimiento de uno 0 varios requisitos especificaciones del elemento. Causa de Falla: hay que describir las anomalias de las que se tiene sospecha que han podido producir el faUo: variaciones en los parametros de manipulacion optima. degradacion en las prestaciones. es decir.CA.. etc. Jndice de Frecuencia (F): pennite asignar una probabilidad de que ocurra lma causa potencial del modo de faUo. se separanin adecuadamente. o o o o . la probabilidad de que los indices de deteccion no funcionen. coste de reparacion. Esto pennite identificar los fallos en los que se deben concentrar principalmente la atencion para empezar a aplicar ah! las acciones correctoras oportunas. uso indebido por parte del cliente.. Ejecta de Falla: en el caso de que se produzca el faUo. Jndice de Gravedad (G): sirve para estimar el nivel de consecuencias sentidas por el cliente.PiTULO 2: TECN1CAS Y HERRAt\1IENiAS DE CAUDAD 41 • Funcion y/o Proceso: describe la funcion del elemento analizado.

4. calidad. identificando el producto. Elaborar y rellenar toda la documentacion relativa a la evaluaci6n de PriOlidad para cada uno de los modos de los fallos potenciales objeto del estudio: esto implica rellenar todos los campos de la tabla 2. y una vez pas ada la fecha de aplicacion. as! como los modos de fallos potenciales. de gravedad y de deteccion y se calcula de nuevo el IPR.1. fiabilidad. se sei'ialan los nuevos valores de los indices de frecuencia. 5. En funcion de los valores de IPR. Responsabilidad y plazo: sirve para anotar la persona 0 area que se hara cargo de la ejecucion de las acciones conectoras indicadas anterionnente en los plazos previstos. Otras fimciones que deberian ser capaces de desanollar son las de disefio. Deteccion e IPR. Estil11ar el alcance y los lil11ites de aplicacion del Ai\1FE. compras (y suministros). pruebas. FOl1nar un equipo multifuncional con conocimiento amplio y diverso sobre los productos. servicios. 2005): 1. estil11arJas acciones conectoras. las causas y las posibles consecuencias. En funcion de este indice. Tras esta fecha. producci6n. volver a calcular los conespondientes indices para comprobar la validez de las acciones conectoras ejecutadas. 3. proceso 0 servicio a estudiar. mantenimiento. procesos y necesidades de los usuarios.S INFOIUvLATICOS © RA-ivLA. e Acciones Correctoras: para detem1inar las acciones conectoras es conveniente seguir cada fallo. "Redllcir la probabilidad de acurrencia". "Alilnentar la probabilidad de deteccion". Frecuencia. Lo que aCaITea calcular los conespondientes indices de Gravedad. . Resultados: tras adoptar las conespondientes acciones conectoras se refleja la fecha de aplicacion. las acciones que se pueden asociar se puede clasificar en "Eliminar la causa dellalla". Ejecutar las acciones conectoras. "Redllcir la gravedad del lalla". 2. ventas (y atencion al cliente) y servicios a clientes. identificar los responsables y estimar el plazo.42 CAUDAD DE SISTEivLA. e e El procedimiento general para desaITollar cualquier tipo de AMFE podria ser el siguiente (Tague. por 10 que se debe tener en cuenta el valor del indice de Prioridad de Riesgo.

el COQ es un proceso uti liz ado para identificar problemas potenciales. HERRAMIENTAS DE MEDICION 7. Obtener 0 dibujar un diagrama de flujo detallado del proceso. 4. Fonnar un equipo muldisciplinar que afronte finnemente el estudio que se va a desalTollar. Cuestionarse las razones de que haya tanto muchas como pocas actividades marcadas que inClllTan en costes de cali dad. 0 a los procesos de la organizaci6n. Para cada actividad marcada estimar el coste que puede implicar los fallos procedentes de una deficiente calidad y el coste que puede suponer implementar acciones bien cOlTectoras. COQ (coste de la caUdad) Tambien llamado Analisis de Costes de Pobre Calidad. b. 5. y cuantificar los costes en los que habria que incurrir por no hacer las cosas bien desde el plincipio. . Para realizar un analisis COQ se recomienda seguir estos pasos: I. 3. 7. de manera que se pueden incorporar aquellas que no se desalTollan 0 mejorar las que se desalTollan a la propia organizaci6n. Las fases para desalTollar un benchmarking es el siguiente: 1.: RA-lvLA CAPiTULO 2: TECNICAS Y HERRAMIENTAS DE CAUDAD 43 7. Identificar todas las fases y actividades del proceso y marcar aquellas que inculTan en costes de calidad: inspecci6n. Proponer aquellas acciones COlTectoras cuya viabilidad sea posible. Planificar: a.1. Estimar la viabilidad de las acciones COlTectoras.2. Definir los objetivos del estudio.1. Benchmarking Tague (2005) define benchmarking como un proceso estructurado que pennite comparar las mejores practicas de las organizaciones.. Hay que elegir aquellos que sean criticos para el exito organizacional. bien preventivas para elTadicar/evitar esos problemas. reparaci6n y control de danos. 2.

2. tanto los numeric os como los descriptivos. Adaptar: a. Encuestas Estan destinadas a detenninar la naturaleza de los procesos. c. b.S lNTORlvLA. DetenniI1ar las diferencias en las pnicticas que provo can dichas brechas. Recopilar Datos: a. Identificar los profesionales de la organizacion que podrian desanollas las mejores pnicticas. . b.3. i\nalizar: a. Existen dos modalidades: e Intenogacion directa: los trabajadores del verbalmente al encuestado y anota sus respuestas. Implementar y monitOlizar dichos planes. usando cuestionarios.44 CAUDAD DE SISTENLA. 4. Recopilar los datos directamente de los profesionales de la organizacion. Desanollar planes de accion para conseguir esos objetivos. conocimiento intenogan e Intenogacion indirecta: se prop one un cuestionario escrito.. d. Estudiar los propios procesos de la organizaclOn: es preciso conocer como nmcionan las cosas intemamente para hacer un buen trabajo en la comparacion. DesaITollar objetivos para los procesos de la organizacion.TICOS . 3. entrevistas telefonicas y/o visitas.:g RA-ivlA c. 7. c. Hay que recoger tanto las descripciones de los procesos como los datos numericos. Detenninar las brechas entre las medidas de rendiIniento de los procesos de la propia organizacion con los de las ou-as organizaciones. Comparar los datos recolectados.

seguridad.. No hay mejora de calidad ni medidas del coste de la calidad ni muchas inspecciones.. Auditorias Coste de Cali dad Control Estadistico de Proceso Encuestas clientes FMEA! Dis.:n. Certidumbre (certainty). alineamiento e integraci6n.: c".. No hay mejora continua fonn~l Departamento de Calidad es responsable Costes de cali dad intemos altos.. TT~ C'. existiendo un departamento de calidad que reporta a la direcci6n. Sabiduria (wisdom).J . obsesi6n por el cliente y "despertar espiritual" (spiritual mvakening). Despertar (mvakening). . Bajo Medio Alto No existe sistema de calidad fonnal 0 no se usa.. La direcci6n comprende la importancia de la calidad y participa en el programa de calidad. madurez y sistema de c1ase mundial. Cada departamento acepta su papel en sistemas de gestion de cali dad. Los departamentos y procesos monitorizan desempefio y meiora diaria.RIPClo..2. Iluminacion (enlightenment)..'\i. NIVELES DE MADUREZ Varios autores han sefialado que las organizaciones pueden presentar diferentes niveles en la gesti6n de la calidad.. Benchmarking Herramientas de gestion Encuestas a empleados QFD Tabla 2." Reclamaciones y costes de fallos son altos. La direcci6n no invierte tiempo ni dinero en la cali dad. por 10 que el personal apaga fuegos constantemente sin investigar las causas de los problemas. Exp.. haciendo enfasis en la prevencion de defectos. 2002) .•.nE lVlADli"REZ . etc. Herramientas y niveles de madurez (Oakes. II II II II En el mismo sentido. estin integrados y dirigidos por la estrategia de la organizacion. los extemos bajos. Toda la organizacion esta involucrada en la mejora continua. Asi.>.. Silverman (1999) distingue los niveles de: aseguramiento de la calidad. mientras que Westcott (2001) los denomina: disfuncional. se pone enfasis en la valoraci6n pero no en la prevenci6n. La direcci6n no entiende la calidad. despertar. Proyectos de mejora con empleados Los sistemas de gestion de calidad. Crosby (1979) distingue los siguientes cinco niveles: II Incertidumbre (uncertain!)). por ejemplo. ' . finanzas. resoluci6n de problemas. N~'EL. "".CAPiTULO 2: TECNICAS Y HERRA1\UENTAS DE CAUDAD 45 8.. " to'. desarrollo. La direcci6n soporta la mejora de la calidad.• \ DES<. ..

Quality Press. Statistical Process Control for Software Process Improvement. (1999). COQ se utiliza antes que el benchmarking. Este libro es la "caja de helTamientas" de calidad propuesta por la American Society for Quality. Ingelmo. 9.onrilearn-about-qualitv/qualitv-tools. A D. e 11. Ed. http://www. A Y Carleton. ya que un proceso debe estar en condici6n estable antes de estudiarlo. Presenta muchos conceptos de calidad a 10 largo de los cuarenta y ocho capitulos de sus dos volumenes. Blanton.org Se trata de la web del QFD Institute que reline una amplia cantidad de material sobre QFD. Sanchez. lA.r Segunda Edici6n. Addison Wesley. se puede encontrar un cierto orden de prelaci6n a la hora de utilizar las helTamientas. Sanchez-Infantes.htmILa American Society for Quality mantiene un cataIogo de Libros muy interesante sobre todas las helTamientas de calidad que se han presentado en este capitulo. N. Okes (2002) presenta la propuesta que se refleja en la tabla 2. Editorial Editex.qfdi. P. Se trata de un muy buen libro de introducci6n a la cali dad en general. Tague. Measuring the Software Process. Tome un proceso concreto de su organizaci6n y utilizando un diagrama de flujo representelo adecuadamente. LECTURAS RECOMENDADAS e CalTetero.asq. lA. (1999). Ademas.. e e e 10. Calidad. EJERCICIOS l. por ejemplo: SPC se tiene que utilizar antes que DOE. W. A. SITIOS WEB RECOMENDADOS e http://\v\vw. A (2001) Manual de Calidad. Milwaukee.R. McGraw-Hill. EI Manual de Cali dad es uno de los libros considerados como c1asicos desde su plimera edici6n. mientras que benchmarking utiliza datos externos. Florae. (2005) The Quality Toolbo. Juran. lM. . Sanchez-Infantes.TICOS ©RA-MA Las helTamientas que una organizaci6n puede utilizar varianin seglin el nivel de madurez de calidad que presente. Es sin duda uno de los mejores libros a la hora de aplicar las tecnicas de control estadistico del proceso al software. ya que COQ utiliza datos internos. P.2.46 CAUDAD DE SISTEMAS IN"FORJvLA...

4. Analizar. las acciones de mejora que pennitirian disminuir la variabilidad de un proceso. las posibles causas que producen los fallos del disefio del software de un sistema de infonnaci6n.G R. y las causas sobre las que acrua cada acci6n de mejora.. elaborar un diagrama causa/efecto. ..-MA CAPiTULO 2: TECNICAS Y HERR.LIDAD 47 2. Pareto.A. representar los diferentes graficos de control (como histograma. 3. Investigue las interpretaciones estadisticas de cada uno de los tests aplicables a los graficos X-BanaJR 0 X-BalTa/So Investigue la interpretaci6n estadistica de los distintos coeficientes definidos para el estudio de capacidad de procesos. En el proceso de puesta en marcha de un sistema de infonnaci6n. jerarquizar los posibles problemas usando las helTamientas estudiadas que se consideren mas adecuadas. . Realizar un estudio sobre la insatisfacci6n de los c1ientes con un producto software. 5. Preparar un cuestionario que inc1uya los datos necesarios para llevar a cabo un estudio sobre los defectos de los datos en una base de datos atendiendo a tres variables distintas: exactitud de los datos. fiabilidad de la fuente que los proporciona y precisi6n de los datos. indique algunas de las cusas de variabilidad.Au\1IENTAS DE CA. 6. mediante un diagrama de Ishikawa. 7. desalTollando las siguientes actividades: para la identificaci6n y analisis de los posibles problemas usar una tonnenta de ideas. ).

La Gesti6n de la Calidad Total concibe la organizaci6n como un conjunto de procesos que se pueden gestionar siguiendo el ciclo "Planificar-Hacer. Check. 2. En este capitulo se resumira muy brevemente todas estas nonnas dedicando. pel'O que es «bueno». como es 16gico. mayor atenci6n a las nonnas ISO 9000 debido a su gran difusi6n. GESTION DE LA CAUDAD TOT. se implementan los procesos correctamente desde el principio y se intenta erradicar los defectos en todo tipo de tareas. el modelo EFQM y. y se han aprobado divers as nonnas.CAPiTULO 3 MODELOS Y NORMAS DE CALIDAD %H EI «buen gusto» como nonna eqllivale a lIna amonestacion para que neguemos nuestro sincero gusto y 10 sustituyamos por otro que no es elnuestro. Do. varias de las cuales han sido aplicadas en las organizaciones. Act) que fue desarrollado iniciahnente hacia 1920 por Walter . Dentro de las diferentes propuestas destacan la Gesti6n de la Calidad Total.Verificar-Actuar" (pDCA: Plan.AL La Gesti6n de la Calidad Total (en sus siglas inglesas TQM. INTRODUCCION Desde mediados del siglo pasado hasta la actualidad se han propuesto diferentes modelos para la gesti6n de calidad. mas recientemente SeisSigma. Total Quality Management). Para ella se impregna la "cultura de calidad" en todos los aspectos de la organizaci6n. representa una "actitud" 0 "filosofia" por la cual la organizaci6n pretende ofrecer a sus clientes productos y servicios que satisfagan completamente sus necesidades. Ortega y Gasset 1.

e informat· sobre los resultados. ISO Y el proceso de normalizaci6n La International Organization for Standarization (ISO http://w\Vw. y popularizado luego por W. NORMAS ISO 9000 3. e e e La gesti6n de la calidad total se basa ademas en otros principios (Hyde. por 10 que se conoce "Cicio de Deming": e Planificar. Verificar. implementar los procesos. Edwards Deming. 1993) que persiguen la mejora continua de los procesos. Hacer.iso. Actuar.-S INl'ORl'viATICOS ~RA-tvL"- Shewhart. establecer los objetivos y procesos necesarios para conseguir resultados de acuerdo con los requisitos del c1iente y las politicas de la organizaci6n. tomar acciones para mejorar continuatnente el desempeiio de los procesos. Martin. realizar el seguirniento y la medici6n de los procesos y los productos respecto a las politicas.com) naci6 en 1947 con el objetivo de facilitar la coordinaci6n internacional de las normas . incorporando el conocimiento y la experiencia de los trabajadores: e e e e Comprorniso de la alta gesti6n con todos los empleados Reducci6n de los ciclos de desarrollo Producci6n "just in time" Reducci6n de costes de productos y servicios Implicaci6n y enriquecirniento ("empOlvennent") Reconocirniento y celebraci6n Propuesta de objetivos cuantificados y benchmarking Toma de decisiones basadas en hechos del puesto de trabajo del personal II e e II 3.1..50 CAUDAD DE SISTEtvL. 1992. los objetivos y los requisitos para el producto.

que posee diferentes gmpos de trabajo (v ease tabla 3. que se encuentra dividido en varios subcomites. En algunas areas. representados a traves de su organismo nacional de nonnalizaci6n (vease la figura 3. que sue len subdividirse en Sub comites (SC) y estos. ANSI (American National Standards Institute) por EEUU 0 AENOR (Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n) por Espana. Estructura de ISO Los trabajos de elaboraci6n de nonnas estan encomendados a los Comites Tecnicos (TC). en el campo de las tecnologias de la infonnaci6n fonna junto con la International Electrotechnical Commission (lEC) el Joint Technical Committee I UTC1). ISO colabora con otras organizaciones. EEUU FRANCIA ANSI AFNOR ESPANA GRAN BRETANA JTCI SC27 Figura 3. entre ellos el SC7 de Ingenieria del Software y Sistemas. por ejemplo.CAPiTULO 3: MODElOS Y NORMAS DE CAUDAD 51 tecnicas en los diferentes campos de la industria. Pueden ser miembros de ISO todos aquellos paises del mundo que 10 deseen.1). . a su vez. en Orupos de Trabajo (WO) para desarrollar temas especificos.1): pOl' ejemplo.1.

. seguridad de uso. 2 4 6 7 I 9 10 12 19 20 21 22 -.... pero a costa de alargar demasiado el tiempo necesario para aprobar una nonna. I . por 10 que rernitimos al lector a http://www.jtc1-sc7..TICOS . ··.. ya que empieza con la decision del TC de incluir la elaboracion de una nueva nonna en su programa de trabajo. " • •••••• . .. . entrega.. seguridad de acceso. hasta su publicacion definitiva..1.. \ . \G~L'Fi) .:\:BAJol.. evoluci6n del producto software y servicio relacionado Medici6n del tamafio funcional Lenguajes de modelado. '-. A nivel europeo. que se remite para aprobacion defmitiva..••. sobre to do en areas como las TIC que evolucionan con mucha rapidez.. puede ser bastante largo.A.. t·· ·TR.. Si los paises aprueban el DIS.52 CAUDAD DE SISTEl'v1AS INt'ORM. se prepara un Proyecto de Nonna Intemacional Final (FDIS.. ©RA-l'vL-\ ..I . International Standard) aprobada en la fuse anterior. Posterionnente. pnicticas y aplicaci6n de evaluaci6n de procesos en la adquisici6n.··•··. metadatos y marco ODP. Committee Draft) a todos los paises miembros para recabar sus comentarios....•. colaboraci6n con OMG..) ?' I I I 24 Documentaci6n de sistemas software Herramientas y entomos CASE Evaluaci6n de productos software y metricas para productos y procesos software Gesti6n del Ciclo de Vida Aseguramiento de sistemas y software (gesti6n de riesgos. .. Grupos de trabajo del SC7 El proceso de elaboracion de una nonna intemacional.>?G •. Worldng Draft) hasta a1canzar el suficiente consenso para elevar el docmnento a la consideracion del TC.. Draft of Intel71ational Standard) que se remite nuevamente a los paises miembros. ITU-T y otras organizaciones (como IEEE) SWEBOK (Cuerpo de Conocimiento de la Ingenieria del Software) Proceso de gesti6n de activos software Vocabulario consolidado de Ingenieria de Sistemas y de Software Gesti6n de Calidad de Sistemas Ciclos de vida del software para pequefias empresas Tabla 3. operaci6n. . A continuacion el WG elabora diferentes Bon'adores de Trabajo (WD. Final Draft of International Standard). desarrollo. •·.onr/ para una informaci6n actualizada sobre los rnismos.. el comite remite un Bon'adm' de Comite (CD. Por ultimo. se edita y publica la Nonna Internacional (IS. se elabora un Proyecto de NOl7na Intel71acional (DIS... ) Metodos. i\~~o x• .. I:. otros organismos como el 1 EI nfunero y distribuci6n tanto de los subcomites como de los grupos de trabajos dentro de un subcomite suele ir variando segtin los temas que se van abordando.". Todo este proceso hace que la nonna pueda contar con el suficiente consenso por parte de los paises.'. Una vez analizados los comentalios recibidos. > y> .•. . . En Espana las nonnas intemacionales son traducidas y publicadas por AENOR como nonnas UNE (Una Nonna Espai"1ola)..

l:. Sistemas de gestion de la calidad. Como su titulo indica.~ R. UNE-EN ISO 9004. Directrices para la mejora del desempefio.2. siguiendo una "jerarqztia de fa calidad'.<1ODELOS Y NOR. La nonna ISO 9001 especifica los requisitos para un sistema de gesti6n de la cali dad que pueden utilizarse para su aplicaci6n interna pOI' las organizaciones.t'vLA. la familia de nonnas ISO 9000 esta compuesta de cuatro nonnas: (i) U1\TE-EN ISO 9000. (i) (i) (i) Ademas. CAPiTULO 3: J>. Se centra en la eficacia del sistema de gesti6n de la calidad para dar cumplimiento a los requisitos del cliente. persiguiendo la mejora continua del desempefio. Normas sobre calidad La primera publicaci6n de las nonnas ISO 9000 se realiz6 en 1987 y cumpliendo el proto colo de ISO. La nOlma ISO 9004 se recomienda como una guia para aqueUas organizaciones cuya alta direcci6n desee ir mas alla de los requisitos de la nonna ISO 9001. para certificaci6n 0 con fines contractuales. Actualmente.2 se representa las diferencias entre ambas nonnas segll11 Cianfrani et al. Requisitos.S DE CAUDAD 53 CEN/CENELEC (Comite Europeo de Nonnalizaci6n) internacionales como nonnas EN (European Nann). Sin embargo. publican las nonnas 3. asi como de su eficacia. especialmente para la mejora continua del desempefio y de la eficiencia glob ales de la organizaci6n. Sistemas de gestion de la calidad. Esta nonna proporciona directrices basicas para la realizaci6n de una auditoria conjunta de ISO 9001 e ISO 14001.A. no tiene la intenci6n de que sea utilizada con fines contractuales 0 de certificaci6n. . que se reflejan en la tabla 3. (2002). Directrices para la auditoria de sistemas de gestion de la calidad y/o medioambiental. fueron revisadas en 1994 y por ultima vez en el afio 2000. Sistemas de gestion de la calidad. En la figura 3. Fundamentos y vocabulario.¥LA. existen otras nonnas relacionadas con 1a familia de las nonnas ISO 9000. esta nonna describe los fundamentos de los sistemas de gesti6n de la calidad y especifica su tenninologia (vease capitulo 1).JNE-EN ISO 19011. que obliga a que todas las nonnas sean revisadas pOl' los menos cada cinco afios. UNE-EN ISO 9001. La nonna ISO 9004 proporciona orientaci6n sobre un rango mas amplio de objetivos de un sistema de gesti6n de la calidad que la Nonna ISO 9001.2.

Directrices para la Calidad en la Gesti6n de Proyectos Sistemas de Gestion de la Calidad ...Requisitos para los procesos y eqllipamientos de medicion Directrices para la Docllmentacion del Sistema de Gestion de la Calidad Directrices para la Gestion de la Economia de la Cali dad Gesti6n de la Calidad .Satisfacci6n del cliente . OBJETIVO .54 CAlIDAD DE SISTEMAS L'lFORc\1ATICOS ©RA-MA 9004 Excelencia en eI desempeiio Ventaja competitiva MINThlIZAR usn DERECURSOS Eficiencia Eficacia Figura 3.. Jerarquia de la calidad segun Cianfrani et al.Directrices para la Gesti6n de la Configuracion Sistel~as de Gesti6n de la Medici6n . (2002) NOR'l-l.A.Directrices para gestionar reclamaciones en las organizaciones Sistemas de Gestion de la Calidad .. ISO 10002 ISO 10005 ISO 10006 ISO 10007 ISO 10012 ISO!TR 10013 ISO:TR 10014 ISO 10015 ISO!TR 1001 7 ISO 10019 I Gestion de la calidad ..2. Otras normas relacionadas con la calidad La familia de normas ISO 9000 se bas a en ocho plincipios de gesti6n de la calidad que pueden ser utilizados por la direcci6n con el fin de conducir a la organizaci6n hacia una mejora en el desempeiio (ISO. 2000a): .Directrices para Planes de la Calidad Sistemas de Gestion de la Calidad .DE C-\LIDAD I .Directrices para la Fonnaci6n Directrices sobre Tecnicas Estadisticas para la nonna ISO 900 I Directrices para la seleccion de consultores de sistemas de gesti6n de la calidad y la utilizacion de sus servicios Tabla 3.2.

es la esencia de una organizaci6n y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organizaci6n.3. contribuye a la eficacia y eficiencia de una organizaci6n en ellogro de sus objetivos. Enfoque bas ado en hechos para la torrta de decision: las decisiones eficaces se basan en el analisis de los datos y la infOlmaci6n. @ @ @ @ @ @ @ .Jv!AS DE CAUDAD 55 @ Enfoque al cliente: las organizaciones dependen de sus clientes y por 10 tanto deberian comprender las necesidades actuales y futuras de los c1ientes. Una ventaja del enfoque bas ado en procesos es el control continuo que proporciona sobre los vinculos entre los procesos individuales dentro del sistema de procesos. Enfoque basado en procesos: esta familia de n01111as promueve la adopci6n de un enfoque basado en procesos cuando se desalTolla. a todos los niveles. Liderazgo: los lideres establecen la unidad de prop6sito y la 01ientaci6n de la organizaci6n. asi como sobre su combinaci6n e interacci6n. ilustra que los c1ientes juegan un papel significativo para definir los requisitos como elementos de entrada. entender y gestionar los procesos intelTelacionados como un sistema. satisfacer los requisitos de los mismos y esforzarse en exceder sus expectativas. Relaciones mutuamente beneficiosas con el proveedor: una organizaci6n y sus proveedores son interdependientes. Participacion del personal: el personal. implementa y mejora un sistema de gesti6n de la calidad. El modelo de sistema de gesti6n de la calidad basado en procesos. Mejora continua: la mejora continua del desempei'io global de la organizaci6n deberia ser un objetivo pennanente de esta. en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organizaci6n.12 RA-IvlA CAPiTULO 3: ?\10DELOS Y NOR. y una relaci6n l11utuamente beneficiosa aumenta la capacidad de ambos para crear valor. El seguimiento de la satisfacci6ndel c1iente requiere la evaluaci6n de la infOlmaci6n relativa a la percepci6n del cliente acerca de si la organizaci6n ha cumplido sus requisitos. Deberian crear y mantener un ambiente inte111o. que se muestra en la figura 3. Enfoque de sistema para la gestion: identificar.

56 CALIDAJ) DE SISTE:tvL.- MEJORA CONTINUA DEL SISTEMA DE GESTION DE LA CAUDAD C informacion +---- L E RESPONSABILlD. 2000a) 3.. cuyo nllcleo 10 constituyen los apartados del 4 al 8 inclusive. incluidos los procesos para la mejora continua del sistema y el aseguramiento de la confonnidad con los requisitos del cliente y los reglamentatios aplicables. En la figura 3.TICOS ©RA-:tvL. . cuando una organizaci6n: e Necesita demostrar su capacidad para proporClOnar de fonna coherente productos que satisfagan los requisitos del cliente y los reglamentarios aplicables. 'u C L GESTION DE RECURSOS MEDICION.4 se muestra el contenido de la n01111a ISO 9001(ISO. Enfoque de procesos segun la norma ISO 9000 (ISO. ANALISIS Y MEJORA N T E r--R-E-AL-IZA--C-I-O-N-' DELPRODUCTO ~ -info E N T S requisitos E S Figura 3. e Todos los requisitos de esta nonna intel11acional son generic os y se pretende que sean aplicables a todas las organizaciones sin importar su tipo. tamafio y producto suminish'ado.. 2000b) especifica los requisitos para un sistema de gesti6n de la cali dad.-S IN"FORJvfA. Aspira a aumentar la satisfacci6n del cliente a traves de la aplicaci6n eficaz del sistema. 2000b)..AD DE LA DIRECCION b .3.3. Norma ISO 9001 Esta norma intel11acional (ISO.

CAPiTULO 3: MODELOS Y NORMAS DE CALIDAD 57 PORTADA ANTECEDENTES DECLARACION PROLOGO PROLOGO DE LA VERSION EN ESPANOL o INTRODUCCION 1 OBJETO Y CAMPO DE APLICACION 2 NORMAS PARA CONSULTA 3 TERMINOS Y DEFINICIONES 4 SISTEMA DE GESTION DE LA CALI DAD 5 RESPONSABILIDAD DE LA DIRECCION 6 GESTION DE LOS RECURSOS 7 REALIZACION DEL PRODUCTO 8 MEDICION. ANALISIS Y MEJORA ANEXO A (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS ISO 9001:2000 E ISO 14001:1996 ANEXO B (Informativo) CORRESPONDENCIA ENTRE LAS NORMAS ISO 9001:2000 E ISO 9001:1994 • BIBLIOGRAFiA ANEXO ZA (Normativo) REFERENCIAS NORMATIVAS A PUBLICACIONES INTERNACIONALES CON SUS CORRESPONDIENTES PUBLICACIONES EUROPEAS Figura 3. Contenido de la norma ISO 9001 (ISO. 2000b) .4.

e f) implementar las acciones necesarias para alcanzar los resliltados planificados y la mejora continua de estos procesos. RESPONSABILIDAD DE LA DIRECCION En cuanto a la responsabilidad de la direcci6n (apartado 5). Planificaci6n.3.\LA. Autoridad y Comunicaci6n.3. 3. y Revisi6n par la direcci6n. c) los procedimientos documentados reqlleridos en esta norma internacional. de gesti6n de los recursos. c) determinar los criterios y metodos necesarios para asegllrarse de qlle tanto la operacion como el control de estos procesos sean ejicaces.2.3. Enfoque al c1iente. la medicion y el amilisis de estos procesos.1. d) los docllmentos necesitados por la Olganizacion para asegurarse de la ejicaz planificacion. " 3. Politica de la calidad. y e) los registros reqlleridos por esta norma internacional. GESTION DE LOS RECURSOS El apartado 6.58 CAUDAD DE SISTENV\S INFOR. " . b) un manllal de la calidad. y b) allmentar la satisfaccion del cliente mediante el cumplimiento de SliS reqllisitos. b) determinar la secuencia e interaccion de estos procesos. TICOS © RA-NL-\ 3. la norma trata varios aspectos relativos a: Compromiso de la direcci6n.. d) asegllrarse de la disponibilidad de recursos e informacion necesarios para apoyar la operacion y el seguimiento de estos procesos. la n0l111a sefiala que: "La organizacion debe: identificar los procesos necesarios para el sistema de gestion de la calidady Sll aplicacion a trm'es de la organizacion. Responsabilidad. operacion y control de sus procesos. sefiala como: "La Olganizacion debe determinar y proporcionar los reClfrsos necesarios para: a) implementar y mantener ef sistema de gestion de fa calidad y mejorar continuamente su ejicacia. " a) Ademas h·ata sobre los requisitos de la documentaci6n. inuicando que: "La doclimentacion del sistema de gestion de la calidad debe incluir: a) declaraciones documentadas de IIna politica de la calidad y de objetivos de la calidad.3. SISTEMA DE GESTION DE LA CALIDAD En cuanto al sistema de gesti6n de la calidad (apartado 4). e) realizar el seguimiento.

REALIZACION DEL PRODUCTO En el apartado 7 de la nonna ISO 9001 se tratan diversos aspectos relacionados con la realizaci6n del producto: 3.1. c) las actividades requeridas de ver[fzcaci6n. 3.-ivL"- CAPiTULO 3: MODELOS Y NORt\L. Procesos relacionados con el cliente En cuanto a los procesos relacionados con el cliente la nonna sefiala que: "La organizacion debe determinar: a) los requisitos especificados por el cliente. infraestructura (edificios. ClIando sea conocido. equipo para los procesos. 3. 10 siguiente: a) los objetivos de la calidady los requisitos para el producto.3. doclimentos y de proporcionar recursos especifzcos para el producto. seguimiento. y servicios de apoyo.Durante la planificaci6n de la realizacion del producto.4. y detenninar e implementar disposiciones eficaces para la comunicaci6n con los clientes. La planificpcion de la realizaci6n del producto debe ser coherente con los requisitos de los oo'os procesos del sistema de gesti6n de la calidad -y que.2.3. tales como transporte y comunicaci6n) y ambiente de trabajo. c) los requisitos legales y reglamentarios relacionados con el producto. b) la necesidad de establecer procesos. Ademas. espacio de trabajo y servicios asociados.. inspecci6n y ensayo/prueba especifzcas para el producto asi como los criterios para la aceptacion del mismo.\': R/\. incll~vendo los requisitos para las actividades de eno'ega y las posteriores a la misma. validaci6n. Planificacion de la realizacion del producto La nonna especifica que "La organizaci6n debe planificar y desarrollar los procesos necesarios para la realizacion del producto. cuando sea apropiado.-S DE CAUDAD 59 Tratandose diferentes aspectos relativos a los recursos humanos.4.. la organizaci6n debe revisar los requisitos relacionados con el producto.4. La nom1a sefiala ademas que la elaboraci6n de planes de calidad puede servir para definir la manera en que los requisitos del sistema de gesti6n de la cali dad cumpliran un contrato especifico 0 con cada producto. . d) los regiso'os que sean necesarios para proporcionar evidencia de que los procesos de realizaci6n y el producto resliltante cumplen los requisitos ".3. la organizacion debe determinar. b) los requisitos no establecidos por el cliente pero necesarios para el lIS0 especificado 0 para elliso previsto. y d) clIalqllier requisito adicional determinado porIa organizaci6n".

deben proporcionarse los resultados del disefio y desarrollo de tal manera que perrnitan la verificaci6n respecto a los elementos de entrada. Compras En cuanto al proceso de compras la nonna establece que: "La organizacion debe asegurarse de que el prodllcto adqllirido eumple los requisitos de compra especijicados. Produccion y prestacion del servicio En este epigrafe se aborda el control de la producci6n y de la prestaci6n del servicio.4. Ademas. Disefio y desarrollo La nonna tambien aborda el disefio y desarrollo.4.4. deben realizarse revisiones sistematicas del disefio y desarrollo. y que deben aprobarse antes de su liberaci6n. la validaci6n de los procesos de la prodJ. manipulacion. asi como la preservaci6n del producto (que debe inc1uir la identificaci6n.4.3.60 CALIDAD DE SISTEivIAS INFOfu'vLA. la propiedad del c1iente ("fa organizacion debe euidar fos bienes que son propiedad del cliente miennm esten bajo el conn'of de fa organizacion 0 esten siendo lItilizados por fa misma"). almacenamiento y protecci6n).3. manteniendo los registros correspondientes.4. la nonna establece que "la organizacion debe eva/uar y seleccionar los proveedores en fill1cion de su capacidad para suministrar productos de aeuerdo con los requisitos de la organizacion" y que "la organizacion debe establecer e implementar la inspeccion u on'as actividades necesarias para asegurarse de que ef producto comp'ado cumple los requisitos de compra especijicados n.3. proceso 0 sistema". EI tipo y alcance del control aplicado al proveedor y al producto adquirido debe depender del impacto del produeto adquirido en la posterior realizacion del producto 0 sobre el producto final n.3.6.lcci6n y de la prestacion del servicio.TICOS © RA-ivIA 3. La nonna sefiala que: debe planificarse y controlarse el disefio y desarrollo del producto. embalaje. deben deterrninarse los elementos de entrada relacionados con los requisitos del producto y mantenerse registros. 3.5. Control de los dispositivos de seguimiento y de medicion A este respecto la nonna sefiala que: "La organizacion debe detenninar ef seguimiento y la medicion a realizar.3. 3. . la identificaci6n y trazabilidad. la verificaci6n y la validaci6n de acuerdo con 10 planificado. entendidos como "el conjunto de procesos que transforma los requisitos en caracteristicas especijicadas 0 en la espec[ficacion de un prodlictO. y los dispositivos de medicion y seguimiento necesarios para proporcionar la evidencia de fa confonnidad del producto con los reqllisitos detenninados n. 3. Tambien deben identificarse y mantenerse registros de los cambios del disefio y desarrollo.

1).!\1AS DE CAUDAD 61 3. y el alcance de Sll utilizacion n. Si la organizaci6n va al c1iente y Ie pregunta cuestiones deliberadas 0 hace observaciones directas del comportamiento del c1iente. e La nOl1na establece que: "la organizacion debe Ilemr a cabo a illtermlos plantfieados allditorias intemas para determinar si tl sistema de gestion de la caUdad: es C01?/orme eon las disposiciones planificadas (vease 7. eon los requisitos de esta nonna illtenzacional y con los reqllisitos del sistema de gestion de la calidad establecidos por la organizacion. e) mejorar continuamente la ejieacia del sistema de gestion de la caUdad. Pasivas. Se pueden c1asificar en: Encuestas. En la nonna se establece que deberia realizarse un seguimiento y medici6n de la satisfacci6n del c1iente. y Entrevistas personales. amilisis y mejora necesarios para a) demostrar la eonformidad del producto. que se pueden c1asificar en: e e Receptivas. en las que el c1iente acude a la organizaci6n con devoluciones 0 quejas.-MA CAPiTULO 3: MODELOS Y NOR. del analisis de datos (que deben ser "apropiados para demostrar la idoneidady la eficacia del sistema de gestioll de .0RA.3. Devoluciones. ANA. Indirectas. en las que se utilizan fuentes secundarias y que pueden ser: Infonnes del cliente. b) asegllrarse de la conformidad del sistema de gestion de la caUdad. medicion.LISIS Y MEJORA En el apartado 8 la norma ISO 9000 establece que: "La orgallizacion debe planifzear e implementar los proeesos de seguimiento. Se pueden dividir en: Quejas. MEDICION. (2002). Medios de noticias. b) se ha il71plementado y se mantiene de manera ejicaz n. Gmpos de discusi6n con participaci6n de c1ientes ("customerfoells group "). Puntuaciones del proveedor. Seglin Saunders et al. las diversas fuentes de infonnaci6n sobre la satisfacci6n del c1iente se pueden clasificar en: e Activas. As! como del conu'ol del producto no confol1ne (que debe estar definido en un procedimiento documentado).5. a) Tambien u'ata sobre el seguimiento y medici6n de los procesos (a los que la organizaci6n debe aplicar metodos que demuesu'en su capacidad para alcanzar los resultados planificados) y del producto. Amilisis competitivo. Esto debe comprender la detemlinacion de los metodos aplicables. incluyendo las teenieas estadisticas.

clientes. personas y sociedad. como las acciones cOlTectivas y preventivas. y procesos ". 4. I> I> I> I> Este modelo se basa en nueve criterios. MODELO EFQM 4. El modelo EFQM se basa en una serie de principios: I> Orientacion a los resultados Orientaci6n al c1iente Liderazgo y coherencia en los objetivos Gestion pOI' procesos y hechos I> I> I> . estmctura para sistemas de gestion de la organizacion. se puede utilizar como: I> hel1'amienta para autoevaluacion. que ~e !leva a cabo por medio de personas. POI' ultimo en la nOl1l1a se aborda la mejora. guia para identificar las areas de mejora. alian:::as). En estos temas se profundizan en la nonna ISO 9004. y cuatro "resultados" -que se ocupan de los que la organizacion consigue.S INFORMATICOS © RA-ivlA. se cOl1siguen mediante el liderazgo que guia la politica y estrategia. base para un vocabulario comun y una manera de pens aI'.(vease figura 3. Vision general El modelo EFQM.62 CAUDAD DE SISTEivlA. fonna de comparacion (benchmark) con otras organizaciones.1. la calidad y para evaluar donde puede realizarse la mejora continua de la eficacia del sistema de gestion de la calidad".3. que propugna un enfoque de auto-evaluacion para evaluar la madurez del sistema de gestion de la calidad para cada apartado de la nonna en una escala que flucrua de 1 (sin un sistema fOl1l1al) hasta 5 (la mejor clase de desempefio). tanto la mejora continua. recursos.5). que fue creado como marco para evaluar las organizaciones con el fin de conceder el European Quality A. cinco "agentes facilitadores" -que abarcan 10 que hace una organizacion-. vease la tabla 3.-ward. Segim el modelo EFQM "los resultados excelentes respecto al desempeiio.

1. vision. del modelo EFQM.~ RA-lvLA. CAPiTULO 3: ". Gestioll del Conocimiento y Gestion de Recursos Humanos. IVlodelo EFQM En el ano 2003 se complemento este modelo con un conjunto de mar'cos (frame'l'Orks) con el fin de atender las necesidades de las orgallizaciones de concentrar sus mejoras en segmentos especificos de su sistema de calidad: Responsabilidad Social Corporativa. valores y principios eticos y acruan como modelo de referencia de una cultura de excelencia.2.mDELOS Y NORl\LA. Criterios del modelo A continuacion se resumen los principales criterios.2. LIDERAZGO Los subcriterios para los lideres excelentes se basan en que estos: e DesalTollan la mision.S DE CAUDAD 63 e e e e DesarTollo e implicacion de las personas Aprendizaje. Gestion de Riesgos. Se implican personalmente para garantizar el desalTollo. e . implantacion y mejora continua del sistema de gestion de la organizacion.5. innovacion y mejora continuos DesarTollo de alianzas Responsabilidad social " uj Personas (9%) y Estragegia (8%) Alianza y " "vV~V Resultados en v) las Personas en los Clientes en la Sociedad (6%) Resultados Clave de Desempeiio (10%) liderazgo (10%) Procesos (10%) Recursos (9%) Figura 3. 4. con sus respectivos subcriterios. 4. Innovacion.

'. Proceso de mejora ampliamente integrado. PERSONAS En este cliterio se evallmn: o Planificaci6n. • o La politic a y estrategia se comunica y despliega mediante un esquema de procesos clave. el aprendi:z.3.TIeos ©RA-MA • • • < Interacruan con clientes. etapa temprana de mejoras sistematicas. POLiTICA Y ESTRATEGIA Los subcritelios de este criterio son: • La politica y estrategia se basan en las necesidades y expectativas achmles y ftlhlras de los grupos de interes. la investigaci6n. Aproximaci6n sistematica basada en el proceso. Niv¢ldeJ)eSempeiio "'. resultados pobres 0 resultados impredecibles Aproximaci6n sistematica basada en el problema 0 la prevenci6n. revisan y achlalizan. proveedores y representantes de la sociedad. Definen e impulsan el cambio en la organizaci6n. .TfORIvLA.aje y las actividades extemas.) Tabla 3. . gesti6n y mejora de los recursos humanos. • " 1 2 Aproximaci6n reactiva 3 Aproximaci6n del sistema fonnal estable 4 5 Enfasis en la mejora continua Desempeno de "meja/' ell Sli clase" No hay una aproximaci6n sistematica evidente.1AS j]\. minimos datos disponibles sobre el resultado de la mejora.3.2. " Orientacion\.2. La politica y estrategia se desarrollan. buenos resultados y tendencia mantenida de mejora. datos disponibles sobre la confonnidad con los objetivos y existencia de tendencias de mejora Proceso de mejora en uso. Resultados demostrados de "mejor en su c\ase" por medio de estudios comparativos (benclllllOrkim.2. La politica y estrategia se basan en la infonnaci6n de los il1dicadores de desempefio. Refuerzan una cultura de excelencia entre el personal de la organizaci6n. 4. Niveles de Madurez del Sistema de Gestion de la calidad 4. " Sin aproximaci6n fonnal ". sin resultados.64 CAUDAD DE SISTEl>.

Gestion de la tecnologia. ALIANZAS Y RECURSOS Respecto a este criterio hay que tener en cuenta que las organizaciones excelentes planifican y gestionan las alianzas extemas. CAPiTULO 3: MODELOS Y NORIvLA.S DE CAUDAD 65 • Identificacion.2. Implicacion y asuncion de responsabilidades por parte de las personas de la organizacion.2. • • • 4.5. reconocimiento y atencion a las personas de la organizacion. pOl' 10 que se detenrunan en el modelo los siguientes subcriterios: • • • • • Gestion de las alianzas extemas. sus proveedores y recursos intemos en apoyo de su politic a y estrategia y del eficaz ftmcionamiento de sus procesos. Gestion de los recursos economicos y financieros. de los productos y servicios. equipos y materiales.4. 4.idRA-MA. distribucion y servicio de atencion. • • . PROCESOS En cuanto a los procesos se evalua: • • • Disefio y gestion sistematica de los mismos. Gestion de la infonnacion y del conocimiento. Produccion. Gestion y mejora de las relaciones con los c1ientes. Recompensa. desanollo y mantenimiento del conocimiento y la capacidad de las personas de la organizacion. Gestion de los edificios. Existencia de un dialogo entre las personas y la organizacion. Introduccion de mejoras mediante innovacion. Disefio y desanollo de productos y servicios basandose en las necesidades y expectativas de los c1ientes.

2. RESULTADOS CLAVE DE DESEMPENO Las Organizaciones Excelentes miden de manera exhaustiva y a1canzan resultados sobresalientes con respecto a los elementos clave de su politica y estrategia. Identificar las caracteristicas comunes de las organizaciones del sector pllblico .8. 4. Servir como helTamienta para los administradores Pllblicos que de seen mejorar el rendimiento de su organizaci6n. Facilitar el benclunarking entre las organizaciones del sector publico. 4.2.2. RESULTADOS EN LA SOCIEDAD De fonna amlloga a la anterior se evaluan los resultados en la sociedad. con el que es compatible. . . EI CAF se considera un modelo "ligero". el CAF tiene cuatro prop6sitos principales: I. por los que se definen los mismos dos tipos de subcriterios que para los clientes.6. 2. RESULTADOS EN LAS PERSONAS Las organizaciones excelentes tambien rniden de manera exhaustiva y a1canzan resultados sobresalientes con respecto a las personas que las integran. 5. para 10 que se tiene en cuenta tanto los resultados clave del desempefi. Se podria considerar un primer paso para avanzar en la gesti6n de la calidad.o de la organizaci6n.66 CAUDAD DE SISTEMAS INFOIUvL-\TICOS @RA-MA 4. CLIENTES Las organizaciones excelentes miden de manera exhaustiva y a1cat1Zan resultados sobresalientes con respecto a sus clientes.2. Como se senala en MAP (2003). CAF: MARCO COMON DE EVALUACION Los ministerios responsables de Administraci6n Pliblica de la Uni6n Em'opea han elaborado el Marco COmlll1 de Evaluaci6n (CAF. Common Assessment Frall1eH'ork) tomando como base el modelo EFQM. que podria ser complementado facilmente con modelos mas amplios como el EFQM.9. Hacer de "puente" entre los diferentes modelos que se usan en la gesti6n de calidad. adecuado para obtener una primera valoraci6n de c6mo acrua una organizaci6n. 3.7. 4.o de la organizaci6n como los indicadores clave del desempefi. por 10 que el modelo establece dos subcriterios basados en medidas de percepci6n y en indicadores de rendimiento 4.

que incluye: detenninar que medir. que responden al acr6nimo DMAIC y que constan de varios pasos (Tayntor.4 defectos por cada mill6n. y documentar el proceso actual. Controlar el proceso mejorado asegurando que los cambios se mantienen. Un proceso que esta en nivel de seis sigmas produce s610 3. identificar las salidas clave.i': Ri\-ivV\ CAPiTULO 3: MODELOS Y NORMAS DE CAUDAD 67 6. establecer un esquema del proyecto. 10 que lleva consigo: obtener la aprobaci6n para los cambios propuestos. el desalTollo de la estrategia de • • • • . detenninando las causas de la variaci6n. mediante el establecimiento de metricas clave. y llevar a cabo comparaciones (benchmark) con Hderes del proceso. llevar a cabo las mediciones. fonnar un equipo. 2003): • Definir el problema e identificar 10 que es importante: consiste en definir el problema. detenninando que mejoras tendrian el mayor impacto para satisfacer los requisitos del cliente. identificar los clientes. como es sabido. Se puede considerar como una filosofia de gesti6n que agrupa varias tecnicas con el fin de conseguir procesos casi perfectos. Medir el proceso actual. detenninar la capacidad del proceso. e implementar los cambios aprobados. finalizar el plan de implementaci6n. Mejorar el proceso implantando las soluciones. Analizar 10 que esta mal y las soluciones potenciales. desalTollar el plan del proyecto. Seglll1 Tayntor (2003) se basa en los siguientes presupuestos: • • • • • Prevenir defectos Reducir la vmiaci6n Centrarse en el cliente Tomar decisiones basadas en hechos Alentar el trabajo en gmpo EI proceso seis sigma se descompone en cinco fases. desalTollando un mapa de procesos y evaluando los riesgos asociados al proceso revisado. calcular el nivel sigma actual. realizando una tonnenta de ideas para la mejora de procesos. identificar y priOlizar los requisitos de los clientes. ya que sigma. SEIS~SIGMA Seis-Sigma (Six-Sigma) tiene su origen en la estadistica. es el simbolo de la desviaci6n estandar.

1a responsabilidad social. el centrarse en resultados y la creacion de valor. con el fin de premiar a las empresas que demostrasen un gran progreso en el area de la calidad. Analisis y Gestion del Conocimiento. PREMIOS Existen multitud de prellllos relacionados con la calidad. a continuacion presentamos los mas irnportantes: II Premio Deming: se creo en 1951 a raiz de las conferencias de Deming en Japon. 2005). European Quality Award.FUNDIBEQ. El premio se basa en el modelo EFQM. la valoracion de los empleados y los socios. es W10 de los Programas de Cooperacion de la Cwnbre Iberoamericana de Jefes de Estado y de Gobiemo y 10 gestiona la Fundacion Iberoamericana de la Calidad .68 CAUDAD DE SISTEMAS INFO MiA. Enfoque al Cliente y Mercado. el centrarse en el futuro. Estos criterios se basan en una serie de conceptos y valores fundamentales como son: elliderazgo visionario. Medicion. es gestionado por la ruSE (Japanese Union 0/ Scientists and Engineers) y se considera el premio indushial mas importante de Japon. la excelencia dirigida al cliente. Malcom Baldrige National Quality Award.TICOS ©RA-MA control. y la medici on y comunicacion de las mejoras. Planificacion Estrategica. se creo en 1987. Enfoque a los Recursos Humanos. Los Malcom Baldrige Criteria/or Peljonnance Excellence defmen un conjunto de practicas de gestion de alto desempeiio en las categorias siguientes (vease figura 3. se creo eJl 1991 pOI' la European FOWldation for Quality Management (EFQM). la gestion basada en hechos. en colaboracion con la Comision Europea y la European Organization for Quality. la implementacion del plan de control. tras el fallecimiento del secretario de comercio del mismo nombre. accionistas. El objetivo de una organizacion que adopta esta filosofia es continuar la mejora de sus procesos solo si los resultados son irnportantes para satisfacer los requisitos de los clientes. y otras partes involucradas. el aprendizaje personal y organizacional. 7. la gestion para la irmovacion. Se otorga a las organizaciones que han destacado por sus resultados exitosos.6): Liderazgo. f!Uto II II II . la agilidad. y una perspectiva sistemica (Baldrige. y se da a la organizacion que demuesh-a que su aproximacion a la gestion de cali dad total ha hecho una irnpOltante conhibucion a la satisfaccion de las expectativas de los clientes. Gestion de Procesos y Resultados de la empresa. Premio Iberoamericano de la Calidad. la celebracion y comunicacion de los exitos. empleados.

Shewhart Medal (a la persona que haya realizado la contribuci6n mas detacable a la ciencia y tecnicas del control de la calidad).~RA-rvL\ CAPITULO 3: MODELOS Y NORJ"L\S DE CAUDAD 69 de una excelente calidad de su gesti6n.6. y potencial en el campo de la calidad").:. Jack Lancaster (a la persona en reconocimiento de su dedicaci6n y contribuciones destacables en la fratemidad intemacional de los profesionales de la calidad). . / ./ 4. Feigenbaum Award (a la persona que muestre "caracteristicas sobresalientes de liderazgo. Edwards Medal (a la persona que demuestre el liderazgo mas destacado en la aplicaci6n de metodos de control de cali dad modema). RelacionesyRetos """ -( 2. PerfilOrganizacional: Entorno.i . de acuerdo al Modelo Iberoamericano de Excelencia en la Gesti6n.----!!-~ :<f ~ 7. 2005) tl) Premios de la ASQ. Eugene L. Criterios para la Excelencia en el desempefio (Baldrige.. Entre los que cabe destacar: Brumbaugh Award (al articulo publicado el ano anterior que ha hecho la contribuci6n mas importante al desarrollo de aplicaci6n industrial de control de calidad). Juran . Recursos Humanos ~~¢==:) .n Figura 3. Ishikmva Medal (a la persona 0 equipo que haya mostrado un liderazgo en la mejora de los aspectos humanos de la calidad).Matiidas. Deming Medal (a la persona que ha combinado con exito la aplicaci6n del pensamiento estadistico y la gesti6n para conseguir la calidad de productos y servicios). Planlficacion Estrategica 5. Resultados de " "'-. Grant Award (a la persona que haya demostrado un liderazgo destacado en el desarrollo y presentaci6n de un programa educacional en control de calidad). profesionalidad.s y GBStl6. . Freund-Marquardt Medal (a las personas que hayan tenido puestos de responsabilidad en el establecimiento de estandares centrados en los sistemas de gesti6n de las organizaciones). Negocios ~ /.Analls. E.

Este libro profundiza en algunos aspectos de la nonna ISO 9000. Excelencia TUlistica.com Este sitio ofrece bastante infonnaci6n sobre las cuestiones relacionadas con la filosofia Six Sigma http://W\v. (2002). y Gesti6n de la Marca Renombrada) 0 a la Competitividad Empresalial. ISO 9001:2000 cOlllentada. SITIOS WEB RECOMENDADOS Cl wW\v. y West. (1992). practicando los principios clave de la calidad)". en su decima edici6n abarcaban: Calidad Indushial. Intemacionalizaci6n. en la medida en que reconoce una actuaci6n de conjunto comprensiva de los factores de competitividad contemplados en las diferentes modalidades de los Premios anteriores). (2003). CRC Press. lE.B. Premio a la Calidad en la Administracion General del Estado. Cl Premios Principe Felipe. Improving SoJnvare Quality . @ . CA. Este libro se presenta la aplicaci6n de la filosofia "Seis Sigma" al desalTollo de software Cl e 9. Estos Premios pueden ser a la Excelencia Empresarial. e 8. EEUU./edal (al lider organizacional que muestre un desempeno distinguido en un papel sostenido. Sociedad de la Infom1aci6n y Tecnologias de la Infonnaci6n y lasComunicaciones. lJ.org Este es el portal de la EFQM. Comercio y Turismo. Arthur presenta la utilizaci6n de los principios de calidad total y de sus helTamientas asociadas para la mejora de la calidad del software. Arthur. pOl' ejemplo. convocados por el Ministelio de Indushia. C.isixsigma. lL. Tsiakals. Florida. Wiley. Six Sigma Jor software development. que es una fundaci6n sin animo de lucro creada en 1989 y que ofrece infonnaci6n y fonnaci6n para las orgamzaclones interesadas en alcanzar la "excelencia" en sus mercados y negoclOS.efqm. en dos modalidades: Pequenas y Medianas Empresas (PYME) y Grandes Empresas (este premio tiene un rango superior al de los delmis. Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n. Diseno..TICOS ©RA-MA ji. es convocado por el Ministerio de Adminish'aciones Pllblicas. LECTURAS RECOMENDADAS e Cianfrani. Tayntor.An Insider's Guide to TQM Nueva York. (asi. tienen como objetivo "el reconocimiento Pllblico de las empresas radicadas en Espaiia que hayan realizado lin importante esJuerzo pOl' mejo/'Qr su cOlllpetitividad a fl-m'es de los principales Jactores que la dejznen". Energias Renovables y Eficiencia Energetica. contemplando varias categorias. Madrid.70 CAUDAD DE SISTEMAS INFOR?vLA. y esta basado en el Modelo EFQM de Excelencia en su adaptaci6n a la Administraci6n Pllblica.

gov. Vease http://\v"\vw. que de como resultado: Entrega de valor con mejora continua a los estudiantes y personas involucradas.nist.org/redibexlpremios. Analice las ponencias de las dos ultimas ediciones identificando los elementos de gesti6n de calidad que reciben mas atenci6n por parte de los responsables de las administraciones publicas europeas. Sugerencia: acceda a http://andes.Que opina sobre estos clitelios? (. mejora de la eficiencia y capacidades organizacionales en su conjunto.fundibeq. En caso de trabajar en una Universidad publica. . 4.quality. aprendizaje personal y organizacional.quality. connibuci6n a la calidad de la fonnaci6n. cuyas actas puede encontrar en http://www.Cree que existe alguna relaci6n entre estos cliterios y el aprendizaje activo centrado en el alumno? 2. Examine la organizaci6n a la que la han concedido el premio este ano en funci6n de los principios de calidad establecidos por los gurus (tabla 1 del tema 1). (. estudie los Educational Criteria for Pelformance Excellence que estim disponibles en: http://www.nllCAF/ConferenceActivities. Encuentre los diferentes prelnios a la calidad que se cone eden en su pais 0 paises del entomo y compare los clitelios de estos premios respecto a los del Malcom Baldlige National Quality Award y a los delmodelo EFQM.html. estos clitelios se disefiaron para ayudar a las organizaciones a utilizar un enfoque integrado en la gesti6n del desempefio organizacional. Bianualmente se celebran los "European CAF events". 3.CAPiTULO 3: ivl0DELOS Y NOR:'vL-\S DE CAUDAD 10. EJERCICIOS 1. Analice las diferentes categorias utilizadas a la hora de conceder el Malcom Baldrige National Quality Award.nist.gov Segtin Baldrige (200Sb).eipa. privada 0 "corporativa".

CaUdad de Sistemas de Informacion 5.CaUdad de Sistemas In(ormaticos 4. CaUdad de Producto Software .

etc. El resto 10 hace pero consumiendo muchos m<ls recursos 0 con menos funcionalidades de las previstas (vease figura 4. el aeroespacial (desastres como los del Ariane 5.C. por ejemplo. A pesar de ella debemos congratulamos ya que se ha pasado del 16% en 1994 a128% en el ano 2000. 10 que indica que se va progresando en este sentido.idad aceptable. mientras que casi una cuarta parte no llegan a finalizar nunca.<\PITULO 4 CALIDAD DE SISTEMAS DE INFORMACION "La calidad de fa vida esta detenninada por SllS actividades" Arist6tefes 1.1). Jorgensen y Molokken-Ostvold (2006) revisan la estimaci6n de un 189% de retraso en la entrega para los proyectos infonnMicos que senalaba el infonne . Recientemente. se senala que s6lo el 28% de los proyectos infonnMicos finalizan en el tiempo estimado. SITUACION DE LA CAUDAD DE SI Desde hace varios anos se viene insistiendo en la "crisis" de la Ingenieria del Software y en los desastres que los fallos de software pueden llegar a causar en las organizaciones. con los recursos planificados y con una ca4. En NIST (2002) se repasan las perdidas econonucas (de varios centenares de millones de d6lares) y en vidas humanas debido a los fallos del software en diferentes sectores como. 2001). algunos aviones comerciales. las sondas de la misi6n a Marte. En el ultimo infonne (Standish. A este respecto cabe destacar los infonnes "CHAOS" del Standish Group que peri6dicamente "fotografian" la situaci6n del sector.).

etc. Terninados Con Exito 28% Terninados Gal ceficiencias 49% Terninados Gal Fracaso 23% Figura 4. 10 que enfatiza almmas la impOltancia de la calidad.-ivL\ CHAOS de 1994. IMPORTANCIA DE LA CAUDAD EN LOS SI Seglm Card (1995) la indushia del software ha expelimentado una selie de modas: durante los setenta la productividad era la preocupjlcion de moda. que requieren diferentes eSh'ategias de negoclo: e Capacidad. la capacidad de ofrecer un producto es 10 mas importante ya que los primeros c1ientes estan dispuestos a aceptar menos calidad de 10 habitual si existen pocos proveedores capaces de ofi'ecer el producto.) que tienen que hacer reflexionar a los lectores sobre la impOltancia que los sistemas de infol111acion tienen para el funcionamiento de la sociedad actual (que presenta una dependencia cada vez mayor de estos). as! como casos famosos (Arnbulancias de Londres. teniendo en cuenta los dos factores que detenninan el mercado: la cantidad de consumidores y de proveedores (vease figura 4.76 CAUDAD DE SISTEivV\S INFO~\l'\ TICOS £) RA. .2). y en los noventa por el "time-fa-market" y el desanollo rapido. Estos dos factores definen cuah'o mercados. Este autor seiiala que las organizaciones deberian considerar la importancia del time-ta-market para su exito. 2.1. 2001) En la maYOlia de libros sobre Ingenieria del Software 0 Cali dad del Software se pueden encontrar estudios parecidos. por 10 que deberia cuestionarse. Aeropuerto de Denver. sustituida en los ochenta por la calidad. Finalizacion de Proyectos (Standish. en opinion de estos autores. si la industria del software ha mejorado desde entonces tanto como parece seglin los liltimos estudios. as! como para el bienestar de las personas. Cuando se inicia un mercado.

En Wilkin y Castleman (2003) se describe un instrumento multidimensional (denominado QUALIT) capaz de medir la calidad de los sistemas de infol1naci6n entregados. Calidad. En los mercados maduros la calidad es el detel1ninante principal del exito. Mercados segun la cantidad de consumidores/proveedores (Card. en el que se diferencia entre la calidad del sistema (entendida como juicio global sobre el grado en que los componentes tecnicos del mismo proporcionan la calidad . • Time-to-market. En un mercado en el que pocos proveedores compiten por muchos consumidores. 10 111<lS imp0l1ante sent poner el producto 10 antes posible en elmercado.S DE INFORMACION 77 c o N S U M I D . as! que la unica estrategia posible para el proveedor es conseguir la calidad solicitada al menor coste posible. ya que sera dificil conseguir el coste mas bajo.~ RA-ivLA. el consumidor es quien dicta la cali dad que desea. En un mercado con muchos proveedores pero pocos consumidores. 1995) • Coste.\1 U C H 0 S Time to Market CaUdad o R P E S 0 C 0 S Capacidad Coste pocos iv!UCHOS PROVEEDORES Figura 4. COMPONENTES DE LA CAUDAD La calidad de un sistema infol1natico puede descomponerse en diferentes factores que contribuyen a la misma. • 3. CAPiTULO 4: CAUDAD DE SISTE1vLA..2.

3. fiabilidad y seguridad. usabilidad. Figura 4. por ejemplo. Dimensiones de calidad de SI. Por otra parte. calidad del servicio (proporcionado por el departamento de SI y el personal de soporte). integracion. as! como la propia calidad de este. calidad de la infonnacion propocionada a los stakeholders (excluyendo manuales de usuario y pantallas de ayuda). Para cada uno de estos componentes los autores han identificado varias dimensiones. para la calidad del sistema se consideran: funcionalidad. Basandonos en este trabajo. A su vez en la calidad del sistema de infonnacion podremos distinguir: e e e e e Calidad de la infraestructura Cali dad de la gesti6n Calidad del servicio Calidad del personal Cali dad de la infonnacion . as!. Stylianou y Kumar (2000) proponen una "vision holistica" de la calidad de los sistemas de infonnacion. en la figura 4. en la que se consideren diferentes dimensiones. basada en Stylianou y Kumar (2000) La cali dad de una empresa u organizacion depended de la cali dad de los procesos de negocio sopOliados por el sistema de infonnacion.3 proponemos diferentes dimensiones de la calidad de un sistema de infonnaci6n.78 CAUDAD DE SISTEMAS INFORMATICOS ©RA-MA de la infonnacion y servicio requerido por los stakeholders).

DesalTollo Rapido de Aplicaciones (RAD) Orientaci6n a objetos HelTamientas CASE Metodos agiles . Artech House. tanto de proceso como de producto. En este libro Robert Glass presenta 55 hechos y 10 falacias que hay que conocer y tener en cuenta a la hora de desalTollar sistemas de infonnaci6n. (2003). SITIOS WEB RECOMENDADOS II http://catless. Achieving Software Quality through Teamwork. En este libro podemos encontrar algunas claves sobre la "calidad del personal". asi como calidad de la infonnaci6n.ACION 79 I) Cali dad del software En los siguientes capitulos nos centraremos en los dos ultimos aspectos: calidad del software. 10 mejor es conocer los "hechos" y las "falacias" de la Ingenieda del Software. Evans. Boston. II 6. c. ya que su autora proporciona una visi6n general de la cultura de equipo necesaria para desalTollar software de calidad.ncl.com/. b. d. I) 5. AddisonWesley. es un contrapunto interesante a las definiciones mas academic as de este concepto.CAPiTULO 4: CAUDAD DE SISTE}'1AS DE INFORM. (2004).ac.uk/Risks En esta direcci6n se puede encontrar el "Forum On Risks To The Public In Computers And Related Systems" del Committee on Computers and Public Polic)' de ACM. Facts and Fallacies of Software Engineering. EJERCICIOS 1. http://w"\vw. Boston. moderado pOI' Peter Neumann y que estudia los peligros de la falta de cali dad de los sistemas de info1l11aci6n. R. El sitio web de la revista Sticky Minds dedicado a las pruebas y a la calidad del software.L.stickvminds. 4. Analice en que cuadrante del marco propuesto pOl' Card (1995) se situadan las siguientes tecnicas: a. I. LECTURAS RECOMENDADAS I) Glass. presenta muchas definiciones de Calidad del Software dadas por profesionales. Con el fin de evitar los fallos en los proyectos software. que son los que mas atenci6n han recibido en los ultimos ailos.

. Analizar la evolucion experimentada por este concepto durante este periodo de tiempo. 67(4). Lleve a cabo una revision sistematica. L. V. "SERVQUAL: a multi-item scale for measuring consumer perceptions of service quality".misq. pp. Zeitharni y L. Berry (1998). Vol.S IN'FOIUvlA.JJS Quaterly (w\V\v.TICOS © RA-tvL'\.. A.80 CAUDAD DE SISTEtvL'\. 4. 2. Joumal of Retailing. utilizando el metodo propuesto en Kitchenham (2004) de los articulos que tratan el concepto de Calidad de Sistemas de Informacion aparecidos en la revista A. 420-450) ala calidad del servicio en un sistema de informacion. Estime. Indique de que manera se puede adaptar el modelo SERVQUAL (Parasuraman. consultando las fuentes bibliognificas que considere oportuno.om:) en los ultimos 10 anos. A. 3. el coste total debido a la baja calidad del software en el que puede haber incurrido su pais o comunidad.

en el que la calidad de un producto software se descompone en once caracteristicas 0 factores de calidad agrupados en tres categorias (vease figura 5. esta lista es una de las muchas .1 puede encontrarse una comparativa entre los distintos modelos donde se muestran los factores observados por cada uno de los autores en sus correspondientes trabajos.CAPITVL05 CALIDAD DE PRODUCTO SOFTWARE "Lo que ahoga a algllien no es caerse al rio. En la tabla 5. Rendimiento y Capacidad del software. MODElOS CLAslCOS Historicamente se han desarrollado para evaluar la calidad de los productos software diferentes modelos que pretenden seguir las directrices de cali dad de otros tipos de productos: descomponer la calidad en una categoria de caracteristicas mas sencillas que facilita su estudio (Galin. A finales de los afios ochenta.. fueron propuestos dos modelos altemativos a los de McCall basados igualmente en la identificacion de factores: el modelo de factores de Evans y Marciniak (1987) y el modelo de factores de Deutsch y Willis (1988). 2004). Otro modelo considerado como clasico es el reconocido como FURPS. acronimo compuesto por las iniciales en ingles de las categorias Funcionalidad. Revision de producto y transicion de producto. 1977).1): Operacion de producto. Uno de los modelos clasicos mas utilizados desde su creacion. es el desarrollado por McCall (McCall et al. incluso con vigencia en nuestros dias. Facilidad de uso. sino mantenerse sllmergido ell el" Palilo Coelho 1. Fiabilidad.

/ .o./ ./ ./ . Modelo de calidad de McCall (1976). de acceso Integridad de datos Eficiencia de almacenam./ ... ./ .jn~g:c./ .1./ I ./ ..1. l\:h:RCINIAl( ./ ./ ./ ./ . EVA'1SY ../ I. Eficiencia de ejecucion Complecion Trazabilidad Consistencia Precision Tolerancia a errores Concision Autodescriptividad Simplicidad Modularidad Instrumentacion Capacidad de ampliacion Vision de usuario Operacion d producto Fiabilidad Revision de~ Facilidad de producto mantenimiento Facilidad de P Flexibilida rueba Transicion d~ Capacidad de producto reutilizacion ~~:~~~~i~li!! Transportabilidat!7'"::::7C:::::::::=::~~~~ Generalidad I Indep./ ./ . I . 2004) ./ ./ . Vision de la direc!<..r!../ ./ I I I I . (1981) .~a Figura 5./ ../ .m~~I~~~1on Seguridad (integrida Eficiencia Comunicatividad Volumen y tasa de ElS Datos comunes Control y audit.!ro""I./ .la".82 CAUDAD DE SISTEMAS ll\'FORt'vIATICOS ©RA-MA adaptaciones y/o complementaciones del modelo de McCall que cada organizaclon ha ideado para sus propios trabajos. ./ .!. FACIOR CALIDAD SOFT\VARE Correccion Fiabilidad Eficiencia Integridad Usabilidad Mantenibilidad Flexibilidad Testeabilidad Portabilidad Reusabilidad Interoperabilidad Verificabilidad Expandibilidad Seguridad de Uso Manejabilidad Capacidad de supervivencia MCCALL (1916) ./ . DHJISCHyWILLrs(1988) I ./ ./ ./ ./ .~eo~~t.!.~~.!c~i=o~n~~~~~====='V~i~s~io~n~de~l~d~e:s~a!./ ./ ./ Tabla 5..r Facilidad de uso~cr:. maquina Interoperabilida'lf'----------.d"./ . como la dada por Grady y Caswell (1987) para Hewlett Packard./ . Comparacion entre modelos de calidad de producto software (Galin../ ./ ./ ./ .

'W20T. externa y en uso. @ @ .Division de Gestion qe Calidad. 2. extern a y en uso) y guias practicas para su aplicacion.~~?.. CAPiTULO 5: C. ISOJIEC 2501n . todos estos modelos requieren identificar metric as para esas caracteristicas de cali dad que penni tan medir cuantitativamente como de bueno es un software atendiendo a esos criterios.Dhision de Medici6n de Calidad. ISOJIEC 2502n . 1999.Evaluacion de un producto software).(y':1?#J!z '%' f~~~i~Y.~l.!. Tecnologia de la Infonnacion -Calidad de un producto software) y 14598 (ISO.2.r?!{~ ifi!3"&·'£'} . La nonna de este apartado presenta un modele de cali dad detallada incluyendo caracteristicas para calidad interna. El capitulo 9 de este libro pretende cubrir este aspecto.~'hi/'.ALIDAD DE PRODUCTO SOFTWARE 83 En cualquier caso.2) y que sustituye y amplia las actuales nOlmas ISO 9126 (ISO. Organizacion de la familia de normas ISO 25000 @ ISOJIEC 2500n .Division de Modelo de Calidad. 1991./. definiciones de medidas de calidad (interna. NORMAS ISO 25000 El SC7 de ISO esta desarrollando la familia de nonnas ISO 25000 (ISO 2005a-n) conocida con el nombre de SQuaRE (Software product Quality Requirements and Evaluation) que se organiza en cinco apartados (vease figura 5. Estas nonnas incluyen un modele de referencia de la medicion de la calidad del producto. tenninos y definiciones comunes referenciados por todas las oh"as nonnas de la serie SQUARE.. Las nonnas que fonnan este apartado definen todos los modelos.? '.i&4~ Figura 5.f:RA-MA.t. Tecnologia de la Infonnacion. i i Modelo de Calidad 2501 n : Requisitos de Calidad 2503n I I Gesti6n de Calidad 2500n j Evaluaci6n de Calidad 2504n Medici6n de Calidad 2502n t.

+-----------~ CaUdad interna Figura 5. Estas nonnas ayudan a especificar requisitos de calidad que pueden ser utilizados en el proceso de elicitaci6n de requisitos de calidad del producto software a desaITollar 0 como entrada del proceso de evaluaci6n. ISOIlEC 2504n -Division de Evaluacion de Calidad. las diferentes nonnas de la familia ISO 25000 alin no se han tenninado de elaborar.Division de Requisitos de Calidad.1.3. e ISOIlEC 2503n .-ivLA. e En el momento de redactar este libro. Aspectos de la calidad de un producto software En la cali dad de un producto sofhvare.3): calidad intema: medible a paItir de las caracteristicas . por 10 que a continuaci6n se explican las nonnas ISO 9126 e ISO 14598. se sue len distinguir tres aspectos diferentes (ver figura 5. as! como en las metric as asociadas en las diferentes etapas del cicio de vida del software. Perspectivas de calidad segun la norma ISO 9126 2.84 CALIDAD DE SISTEi\1AS INFORIvL~TICOS © RA. recomendaciones y guias para la evaluaci6n de productos software. Necesidades de calidad del usuario +---------- ~ Cali dad en uso Uso y retroalimentaci6n I Contribuye a especificar t Indica ~ Requisitos de caUdad externa +-----------~ I Calidad extern a Validaci6n I Contribuye a especificar i Indica ~ Requisitos de caUdad interna Verificaci6n I . ya que probablemente los conceptos basicos se mantengan con pocos cambios significativos en las nuevas nonnas. Este apartado incluye nonnas que proporcionan requisitos.

que se resume a continuaci6n (ISO. como el c6digo fuente. medible en el comportamiento del producto. Siguiendo la filosofia de los modelos clasicos de calidad de un producto software.4.Q RA-tvL-\ CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 85 intlinsecas. Ista caracteristica se subdivide a su vez en: o Adecuacion. como en una pmeba. Modelo de calidad interna y externa II modelo de calidad para calidad intema y extema categoliza los atributos de calidad software en seis caracteristicas (funcionalidad. mantenibilidad y portabilidad).4). que se subdividen a su vez en subcaracteristicas (figura 5.2. extema.1. Capacidad del producto sofuvare para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados. FUNCIONALIDAD Capacidad del producto software para proporcionar funciones que satisfacen necesidades declaradas e implicitas cuando se usa bajo condiciones especificadas.2. lVIodelo para la caUdad extern a e intern a (ISO. la nom1a ISO 9126 descompone la calidadjerarquicamente en una serie de caracteristicas y subcaracteristicas que pueden usarse como una lista de comprobaci6n de aspectos relacionados con la calidad. eficiencia. fiabilidad. . 2. 2001). 2001) 2. 0 en uso: medible durante la utilizaci6n efectiva por parte del usuario en un contexto determinado. Adecuaci6n Exactitud Interoperabilidad Seguridad de : Capacidad de ser entendldo Capacidad de ser aprendldo Capacidad de ser operado Capecidad de atraccion Cumplimiento de la usabilidad Capacidad de ser analizado Capacidad de ser cambiado Capacidad de ser probado Cump!imiento de la mantenibi!idad rv1adurez Tolerancla a rallos Capacidad de recuperac16n Cump!imiento de la fiabiHdad aeceSD Cumphmiento de la funclonalidad Comportamiento temporal Utilizacion de recursos Cumplimiento de la eficiencia Adaptabilidad Instalabilidact Coexistencia Capacidad de ser reemplazado Cumplimiento de Ja portabilidad Figura 5. usabilidad. Calidad externa e interna .

Tolerancia a fallos. aprendido. Capacidad del producto software para adherirse a normas.!\1A. convenciones 0 regulaciones relacionadas con la fiabilidad.2. Cumplimiento de la fiabilidad. Capacidad para ser aprendido. Capacidad del producto software que perrnite al usuario aprender sobre su aplicacion. Capacidad del software para mantener un nivel especificado de prestaciones en caso de fallos software 0 de infringir sus interfaces especificados. Cumplimiento funcional. USABILIDAD Capacidad del producto software para ser entendido. Capacidad del producto software que permite al usuario entender si el software es adecuado y como puede ser usado para unas tareas 0 condiciones de uso particulares. iii iii 2. con el grado necesario de precision. iii iii 2. al tiempo que no se deniega el acceso a las personas 0 sistemas autorizados. convenciones 0 regulaciones en leyes y prescripciones sirnilares relacionadas con funcionalidad. FIABILIDAD Capacidad del producto software para mantener un nivel especificado de prestaciones cuando se usa bajo condiciones especificadas.3. Seguridad de acceso. Capacidad del producto software para proporcionar los resultados efectos correctos 0 acordados. Capacidad de recuperacion. Capacidad del producto software para interactuar con uno o mas sistemas especificados. Capacidad del producto software para reestablecer un nivel de prestaciones especificado y de recuperar los datos directamente afectados en caso de fallo. Capacidad del producto software para adherirse a normas.TICOS ©RA-MA iii Exactitud. Esta caracteristica se subdivide a su vez en: • iii Madurez.86 CAUDAD DE SISTEMAS INFOR.2. cuando se usa bajo condiciones especificadas.2. 0 iii Interoperabilidad. Capacidad del producto software para proteger informacion y datos de manera que las personas 0 sistemas no autorizados no puedan leerlos 0 modificarlos. Esta caracteristica se subdivide a su vez en: • Capacidad para ser entendido. usado y ser atractivo para el usuario. • . Capacidad del producto software para evitar fallar como resultado de fallos en el software.

relativas a la cantidad de recursos usados. • • 2. Cumplimiento de la usabilidad.4. Esta caracteristica se subdivide a su vez en: • Comportamiento temporal. Cumplimiento de la mantenibilidad. bajo condiciones determinadas.2. tiempos de proceso y potencia apropiados. Capacidad del producto software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su funci6n bajo condiciones determinadas. guias de estilo 0 regulaciones relacionadas con la usabilidad.5. MANTENmILIDAD Capacidad del producto software para ser modificado. • • • • . Capacidad del producto software para adherirse a nonnas 0 convenciones relacionadas con la eficiencia. Capacidad del producto software para adherirse a nonnas 0 convenciones relacionadas con la mantenibilidad. 2. Cumplimiento de la eficiencia. EFICIENCIA Capacidad del producto software para proporcionar prestaciones apropiadas. Estabilidad. mejoras 0 adaptaci6n del software a cambios en el entomo. 0 para identificar las partes que han de ser modificadas. Capacidad para ser cambiado. Capacidad de atracci6n. convenciones. Las modificaciones podrian incluir correcciones. Capacidad para ser probado. Utilizaci6n de recursos. Capacidad del producto software que pennite que el software modificado sea validado.£lRA-MA CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 87 • • • Capacidad para ser operado. Capacidad del producto software para evitar efectos inesperados debidos a modificaciones del software. Es la capacidad del producto software para serle diagnostic ad as deficiencias 0 causas de los fallos en el software. y requisitos y especificaciones funcionales.2. bajo condiciones determinadas. Capacidad del producto software para ser atractivo al usuario. Capacidad del producto software para proporcionar tiempos de respuesta. Capacidad del producto software para adherirse a nonnas. Capacidad del producto software que pennite al usuario operarlo y controlarlo. Capacidad del producto software que pennite que una detenninada modificaci6n sea implementada. Esta caracteristica se subdivide a su vez en: • Capacidad para ser analizado.

La calidad en uso contempla las siguientes caracteristicas: 2.6. Instalabilidad. Capacidad del producto software para ser usado en lugar de otro producto software.88 CAUDAD DE SISTE?vLA. Cumplimiento de la portabilidad. para el nusmo prop6sito. Capacidad para ser reemplazado. EFECTIVIDAD Capacidad del producto software para pennitir a los usuarios alcanzar objetivos especificados con exactitud y compleci6n. segllridad y satisfacci6n (figura 5.3. .2. PRODUCTIVIDAD Capacidad del producto software para pennitir a los usuarios gastar una cantidad adecuada de recursos con relaci6n a la efectividad alcanzada. Capacidad del producto software para ser instalado en un entomo especificado.2.1. sin aplicar acciones 0 mecanismos distintos de aquellos proporcionados para este proposito por el propio software considerado. G G G • 2. 2. Capacidad del producto software para ser adaptado a diferentes entomos especificados. prodllctividad.S fNrO~'vL'\TICOS © RA-?viA. Capacidad del producto software para adhelirse a nonnas 0 convenciones relacionadas con la portabilidad. 2. Coexistencia. Capacidad del producto software para coexlstlr con otro software independiente. Esta caracteristica se subdivide a su vez en: G Adaptabilidad. en contex:tos de lIS0 especificados". Modelo de calidad en uso La nonna ISO 9126 entiende por calidad en uso "fa capacidad def prodllcto sofMare para pennitir a detenninados lIsliarios alcanzal' objetivos espectficados con efectividad. en el mismo entomo.3. compartiendo recursos comunes. en un contexto de uso especificado. PORTABILIDAD Capacidad del producto software para ser transferido de un entomo a otro.3. en un entomo comun. en un contexto de uso especificado.5).

cuyo valor medido se sima en una escala.6 (ISO. Modelo para la calidad en uso (ISO.4. 1999) se resunie este proceso. Evaluaci6n de un producto software La nonna ISO 14598 da una vision general del proceso de evaluacion de un producto software. al negocio.3. La division de la esc ala en cuatro categorias lirnitadas por el nivel actual de un producto existente 0 altemativo.5. SATISFACCION Capacidad del producto software para satisfacer a los usuarios en un contexto de uso especificado. La escala ha de dividirse en rangos que cOlTesponden a diferentes niveles de satisfaccion de los requisitos. explicando en sus diferentes partes como aplicar el proceso en diferentes circunstancias. Por ejemplo: G La division de la escala en dos categorias: satisfactOlio e insatisfactOlio. 2005) 2.3. el peor caso y el nivel proyectado. Esta nonna se apoya en la ISO 9126 ya que los aspectos cuantificables pueden medirse cuantitativamente usando metricas de calidad. 2. 2. SEGURIDAD DE usa Capacidad del producto software para alcanzar niveles aceptables del riesgo de hacer dana a personas.4. EI nivel proyectado es 10 que se considera alcanzable con los recursos disponibles.~ RA-ivLA CAPiTIJLO 5: CAUDAD DE PRODUCTO SOFTWARE 89 Calidad de Uso Figura 5. a las propiedades 0 al medio ambiente en un contexto de uso especificado. El nivel actual se declar·a con el fin de controlar que el nuevo sistema no suponga un deterioro en relacion a la situacion actual. al software. El peor caso es la frontera G . En la figura 5.3.

7. Establecer Propos ito de fa Evaluaci6n Establecer Requisitosl~I-_ _ _-4 de Evaluaci6n Identificar los tipos de producto(s) Especificar el modelo de caUdad 9126·1 Caracteristicas de Calidad 9126·2 Metricas Extemas 9126-3 Metricas Intemas 14598-6 Modulos de Evaluaci6n Establecer niveles para las metricas Establecer criterios de valoracion Producir Plan de Evaluaci6n Tomar medidas Valorar Resultados Figura 5. 1999) niyel PlaneadO~ - Excede los requisitos val~~ medido -=- Rango objetiyo satistbctorio niyel actua~ - .S INFOR.-- - - niveles de puntuaciOn escala de nii!dicion Figura 5. Minimanii!nte aceptabt~ insatistbctorio lnaceptabt~ - el casu peo. Proceso de evaluacion de un producto software (ISO.\V\ TICOS ©RA-MA para aceptacion de! usuario por si acaso e! producto no cubre e! nive! proyectado (figura 5.90 CAUDAD DE SISTEtvL">. Rangos de una esc ala de medida (ISO..7). 1999) .6.

<:: RA. En este apartado citamos algunos de los mas relevantes: €I SQUID (Boegh. 3. Adaptan la nom1a ISO 9126 a los componentes COTS. et 01.8): €I €I €I €I O. Amplian las subcaracteristicas y atIibutos propuestos por la nonna ISO 9126 llegando a identificar 124 atIibutos de calidad para los componentes software. (2005).-MA CAPiTULO 5: CAUDAD DE PRODUCTO SOFTWARE 91 3. 1999). planificacion. €I . QUINT2 (Niessink. (2003) refinan el modelo de cali dad de la ISO 9126 para arquitecturas software. 1. desanollan una metodologia que conduce a la constmccion de modelos de cali dad especificos de dominio en tenninos del estandar ISO 9126. Esta metodologia consta de siete pasos (figura 5.. llegando a proponer divers as medidas para los atIibutos de calidad. y que han aplicado a paquetes software COTS (commercial off-the-shelj).. 2002) amplia el modelo de la ISO 9126 para evaluar la calidad de arquitecturas software. Losavio et 01. 6. 5. Moraga et 01. Definir el dominio Detenninar subcaracteristicas de calidad Definir unajerarquia de subcaracteristicas Descomponer subcaracteristicas en atIibutos Descomponer atIibutos derivados (aquellos que no sean medibles directamente) en atIibutos basicos Establecer relaciones entI'e entidades de calidad (por ejemplo. TRABAJOS BASADOS EN LAS NORMAS ISO 9126 E ISO 14598 Existen multitud de trabajos basados en las nonnas ISO 9126 e ISO 14598 que puede ser de interes a la hora de plantearse la evaluacion de productos software. y Botella et. 4. pennite la especificacion. aumentar la subcaracteristica de seguridad lleva consigo que aumente la madurez de un producto) Detenninar metIicas para los atIibutos. La calidad queda definida como un comportamiento operacional de los productos requeridos por sus usuarios. 2. €I Simlo y Belchior (2003). Bertoa et 01. evaluacion y control de la calidad de software a tI'aves de los procesos de desanollo. al (2003). Ofrece un metodo y una henamienta de soporte que reciben el nombre de SQUID. Franch y Carvallo (2003).. (2005) proponen un modelo de calidad para portlets basada en la adaptacion de ISO 9126 asi como en algunos de los trabajos anterionnente citados. 1.

fiabilidad..'vrA. 2003) 4.TICOS ©RA-l\IA Paso 1 Paso 3 Paso 4 Paso 5 Establecer Relaciones entre entidades de calidad Paso 6 Datarminar ivletricas para los atributos Figura 5.92 CAUDAD DE SISTEMAS Il\1fOR. Compare las caracteIisticas y subcaracteIisticas de calidad del modelo de McCall y de1l110delo propuesto en la nonna ISO 9126. EJERCICIOS 1.O 25000 Y el modelo CMMI. (. En esta recopilacion se abordan diversos aspectos de la calidad relativa a los sistemas sofuvare basados en componentes. funcionalidad.cmille parece m1s completo?. Component-Based Sofnvare Quality: jvfethods and Techniques. (.encuentra gran sil11ilitud entre ambos? Como sefiala Kan (2003). y Vallecillo. A. . mientras 2.cmu. desel11pei'io. documentacion!infOlmacion. usabilidad. M. A. y servicio). (eds.) (2003). Splinger Verlag LNCS 2693. Metodologia para la construccion de modelos de calidad especificos de dominio (Franch y Carvallo. Piattini. SITIOS WEB RECOMENDADOS • http://v{v{w.8.a cmiles la non11a ISO 9126?. instalabilidad. del 6. (. LECTURAS RECOMENDADAS • Cechich. l11antenibilidad.a que elementos de la calidad Ie concede 111<1S importancia McCall? y (. los panimetros de satisfaccion del c1iente que monitol1za IBM son: capacidad.sei.edulsemaipresentations/zubrow/esepg/ Presentacion Sofnvare Engineering Institllte sobre IS. 5.

Por ejemplo. las diferentes interacciones que pueden darse entre las subcaracteristicas del modelo de calidad de la ISO 9126. CAPiTULO 5: CAUDAD DE PRODUCTO SOmVARE 93 que Hewlett-Packard utiliza: funcionalidad. Analice. Proponga a continuaci6n diferentes fonnas de medir las caracteristicas propuestas. una mayor funcionalidad podria influir en una men or facilidad de prueba. Y su trazabilidad respecto a las nonnas ISO 9126 e ISO 14598. 3. 1995). compare estos panimetros con las caracteristicas de la nonna ISO 9126. Accediendo al portal de ISO (wlvw. Simao y Belchior (2003) 0 Bertoa et al.iso. l11odificado 0 descartado para este tipo de software. 6. Desanolle un proceso de analisis y selecci6n para sistemas de infonnaci6n geognifica (SIG) teniendo en cuenta las caracteristicas distintivas de este tipo de sistemas. Compare las diferentes propuestas existentes sobre modelos de calidad para componentes (p..ej. Tomando como base el proceso de selecci6n propuesto por la nonna ISO 14598.GRA-?vLA. desempeiio y servicio. 5. Compare elmodelo definido con la nonna ISO 14102 (ISO. adaptando si fuera necesario el modelo de calidad de la ISO 9126. 7.ch) investigue cual es la situaci6n actual de las nOlmas de la familia ISO 25000. utilizando una matriz. (2005)) analizando que caracteristicas y subcaracteristicas de la nonna ISO 9126 se han adoptado tal cual. 4. . usabilidad. defina un proceso de selecci6n para henamientas de amllisis y diseiio Olientado a objetos. fiabilidad.

CaUdad del Proceso Software 6. EI Proceso Software 7. Modelos de Proceso de CicIo de Vida 8. Evaluacion y Mejora de Procesos .

finnacion se basa en que existe una cOlTelacion directa entre la calidad del proceso y la calidad del producto obtenido (Fuggeta. 2002). Sin embargo. modelos de desalTollo y helTamientas. por ejemplo. por 10 que surge la denominada ingenieria del software basada en el proceso (Wang y King. evolutivo y en espiral (Piattini et 01. Estos modelos del ciclo de vida ayudan a los ingenieros y a los gestores a comprender mejor el proceso software. y a detenninar el orden de las actividades necesarias en la vida de un producto software. INTRODUCCION Tradicionalmente la Ingenieria del Software se ha centrado en metodologias y lenguajes de programacion. se hacia necesario incluir detenninadas areas que hoy en dia son criticas para la ingenieria del software. como las infraestructuras de gestion y organizacion. el estudio de los procesos de produccion de software ha llevado al desalTollo de varios ciclos de vida en la ingenieria del software como. y teniendo en cuenta la creciente complejidad de los sistemas. Tal como se destaca en numerosos estudios.CAPiTULO 6 EL PROCESO SOFTWARE "Los Procesos Software tall/bien son Software" Leon Osten veil 1. una organizacion no puede garantizar la entrega de productos de calidad centrando sus programas de calidad unicamente en el producto (Satpathy y Harrison. 2000). actualmente la calidad de cualquier producto no puede ser asegurada simplemente inspeccionando el producto por sl mismo 0 desalTollando controles de calidad estadisticos.. 2003). Esta 'l. Durante las tres ultimas decadas. los modelos cascada. 2000) y en consecuencia. .

mantener software y los productos de trabajo asociados (planes de proyecto. procedimientos. ya que en much as ocasiones son tratados en la bibliografia como conceptos equivalentes. El ciclo de vida software define los principios y las directrices de acuerdo a las cuales se deben llevar a cabo estas etapas.tVlATICOS Sin embargo. Respecto al proceso software.98 CAUDAD DE SISTEivL~S !1\1fOR. 2001). "Proceso 0 conjlli1fO de procesos usados por una organizacion 0 proyecto. 1995). monitorizar. fa explotacion y el mantenimiento de lin producto de software. practicas y transformaciones que la gente lisa para desarrollar). soporta y mejora el desarrollo. tecnologias. 1998). cuando. y cubre todos los elementos necesarios (tecnologias. gestionar. estructuras organizacionales. las actividades y las tareas invoilicradas en el desarrollo. 1995). EI EI El proceso software es un proceso con una natmaleza especial. para plantficar. EI EI "Conjunto coherente de politicas. desarrollar. Un proceso define quien esta haciendo que. empaquetar y mantener un producto software" (Fuggeta. 2000). ISO.. Por ejemplo. detenninada por las siguientes caracteristicas (Demiame et al.. En este contexto los ciclos de vida aportan un marco de referencia para los procesos de desarrollo y mantenimiento del software (vease Capitulo 7). 1999).) relacionados con las actividades involucradas en la vida de un producto software. gestiona. procedimientos y artefactos que son necesarios para concebir. en la literatura podemos encontrar divers as definiciones: EI "Conjunto de actividades. diseiio de doclllnentos. personal. abarcando la vida del sistema desde fa definicion de los reqllisitos hasta la finalizacion de Sll lISO" (ISO. etc.EI Es complejo.. ejecutar. el ciclo de vida en cascada sugiere que antes de comenzar una nueva fase se deben haber finalizado los entregables de la fase anterior. controlar y mejorar SliS actividades software relacionadas" (ISO. 2002b). mide. 1995. es muy importante establecer claramente la diferencia entre proceso software y ciclo de vida. Un proceso se define como un conjunto de actividades interrelacionadas que transfommn entradas en salidas (ISO. artefactos. Iluitodos. desarrollar y mantener sistemas software" (Acuna et af. "Conjunto parcialmente ordenado de actividades lie vadas a cabo para gestionar. . Un ciclo de vida software es "un marco de referencia que contiene los procesos. "Ef proceso soff1vare define como se organiza. independientemente de las tecnicas y lI1etodos usados" (Demiame et al. y como a1canzar un detenninado objetivo. EI proceso software es un concepto mas amplio. pruebas y manuafes de uSliario) " (SEI. codigo. bas ado en el de ciclo de vida. 1999): .

relacionado con la construccion y mantenimiento del producto software. se podrian establecer en las siguientes categorias (Fuggetta. planificar y controlar los recursos necesarios (personas. Tampoco es un proceso de ingenieria "pura". c1iente. 1990. calendarios y calidad no pueden ser planificados de forma suficientemente fiable. el diseno y la produccion no estan claramente diferenciados. Proceso de Gestion. en el que debido a la gran cantidad y diversidad de elementos relacionados. ya que se desconocen las abstracciones adecuadas. tiempo. que constituyen Hneas guia sobre como se deben hacer las cosas: uso de la tecnologia y realizacion de las actividades. depende en gran medida de demasiada gente. que puede ser usada posterionnente para mejorar el proceso y por tanto. tecnologia. el proceso software es un campo de estudio amplio y complejo en el mundo de la ingenieria del software. No es (completamente) un proceso creativo. Demiame et al. Metodos y Tecnicas de Desarrollo Software. y el exito depende de la implicacion del usuario y de la coordinacion de muchos roles (ventas. Al igual que los procesos de fabricacion. mejorar la calidad del producto software. etc. e Por 10 tanto. Esta bas ado en descublimientos que dependen de la comunicacion. los costes del cambio del software no suelen reconocerse.-MA CAPiTULO 6: EL PROCESO SOFTWARE 99 • No es un proceso de produccion tipico. Este control genera infonnacion sobre el proceso de produccion. los procesos software cons tan de dos subprocesos interrelacionados (McLeod. y los presupuestos. 2000): e Tecnologia de Desarrollo Software. en fonna de herrarnientas. infraestmcturas y entomos. coordinacion y cooperacion dentro de marcos de trabajo predefinidos: los entregables generan nuevos requisitos.. • e e La necesidad de participacion humana de forma creativa y la ausencia de acciones repetitivas hacen que ni el desarrollo ni el mantenimiento del software sean procesos de fabricacion. etc. 1999): e Proceso de Produccion. y cada uno tiene peculiaridades que 10 distingue de los delmis. II . se ve muy detenninado por circunstancias impredecibles. ya que esta dirigido por excepciones.) para poder llevar a cabo y poder controlar el proceso de produccion. ya que algunas partes pueden ser descritas en detalle y algunos procedimientos son impuestos previamente.kRA. pero existen algunas similitudes entre ambos tipos de procesos que son lltiles para comprender los procesos software con una perspectiva mas amplia. relacionado con el soporte tecnologico.). desarrollo tecnico. que es el encargado de estimar.

a la necesidad de introducir este tipo de entomos poco a poco. pmtiendo de un modelado descriptivo de los procesos que ayude a su entendimiento y comunicacion. muy pocas propuestas de PSEE han sido aplicadas de fonna pnictica en la indusnia.-\-MA e Comportamiento Organizacional. es necesario modelar los procesos. para llevar a cabo de una fonna eficiente la mejora del proceso es necesario tener en cuenta los siguientes aspectos: e Definicion del Proceso. para posterionnente afiadir los detalles necesmios para proporcionar sopOlte a su ejecucion. representar los elementos de interes que intervienen. muy cambiantes ante la gran competitividad de las empresas hoy en dia. relacionado con la gestion de proyectos. Tal y como se ha comentado las razones son variadas. Controlar y Mejorar el Proceso. Para ello. 1999). relacionado con los recursos humanos. La definicion del proceso es la primera responsabilidad clave que hay que asumir para poder realizar una gestion efectiva de los mismos. constituye un paso fundamental para la . Process-centered Software Engineering Environment). EI modelado de los procesos software.1. E:. Medir. es decir. por 10 tanto.tos son los objetivos de la Gestion del Proceso Sofuvare (Florac y Carleton. Para aplicar esta gestion de fonna efectiva es necesario asumir cuatro responsabilidades clave: Definir. Sin embargo y a pesar de que el tema de los procesos software no se ha establecido alm como una disciplina que se ensefie y practique universalmente por la indusnia del software es de esperar que en el fhturo las tecnologias de sopOlte a los procesos software maduren y sean adoptadas por las organizaciones. A pesar de su importancia y de los avances en la investigacion en estos temas. e La integracion de las tecnologias de produccion y de gestion en un entomo de trabajo constituye la esencia de la Tecnologia del Proceso Software y como resultado se han desanollado los denominados Entornos de Ingenieria del Software orientados al Proceso (PSEE. 2. desde la ligidez de muchas de las propuestas que ha dificultado su aplicacion indusnial en mercados diniunicos. (2) que esten basados en una COlTecta definicion y (3) que sean mejorados en funcion de los objetivos de negocio.100 CAUDAD DE SISTEMAS IN'FORMATICOS ©R. GESTION DE LOS PROCESOS SOFTWARE Los requisitos de calidad mas significativos de los procesos software son: (1) que produzcan los resultados esperados. debido a que el producto software final debe cumplir con unos plazos y costes detenninados y debe satisfacer las necesidades del cliente al que va destinado. Los procesos software son llevados a cabo por equipos de personas que tienen que estar coordinados y deben gestionarse desde una eficiente estructura organizacional. De acuerdo a estas responsabilidades. Economia y Marketing. Estas responsabilidades y sus relaciones se representan en la figura 6.

1. Existe una importante cOlTelaci6n entre la medici6n y la mejora de los procesos software. Para ello. se han desalTollado en las dos llltimas decadas los denominados "En 10177 os de lngenieria del Sofnmre orientados a Procesos" (PSEE). En este sentido. Medicion y Mejora.t RA-iviA cAPinJLO 6: EL PROCESO SOFTIVARE 10 1 comprensi6n y mejora continua de los procesos de una organizaci6n (Arbaoui et aI.. Los proyectos software de una empresa se llevan a cabo de acuerdo a los modelos de procesos definidos. de los procesos cOlTespondientes) para garantizar que se obtienen los resultados esperados. Dada la importancia de estos aspectos. mientras G . que son los sistemas software que ayudan en el modelado de los procesos software utilizando un determinado lenguaje y en su posterior automatizaci6n por medio de Sll reificaci6n (enactment). La medici6n del software es tratada en el capitulo 9. Etapas Clave de la Gestion del Proceso Software G Ejecucion y Control del Proceso. es conveniente disponer de un marco de trabajo efectivo que facilite la identificaci611 de las entidades relevantes candidatas a ser medidas. 2003). Mejorar el Proceso Controlar el Proceso Figura 6. Para ello. Con los resultados de la medici6n de los procesos es posible disponer de una infomlaci6n objetiva que pennita planificar. cuyo objetivo es detectar los aspectos que se pueden mejorar. es importante poder controlar en todo momento la ejecuci6n de estos proyectos (yen consecuencia. identificar y llevar a cabo de una manera eficiel1te las acciones de mejora necesarias. Antes de poder mejorar un proceso es necesario llevar a cabo una evaluaci6n. se estudian con mucho mayor detalle a 10 largo del libro.

proporcionando orientaciones. Provision para el soporte auto matico a la ejecucion. 10 que requiere un entorno de desan'ollo efectivo del software. los procesos de diferentes proyectos tienden a seguir patrones comunes. como representacion del pJ. Soporte y control de la gestion del proceso.102 CAUDAD DE SISTEivl-\S INFOJUvlA TICOS © RA-ivl-\ que los modelos y estandares de evaluacion y mejora de procesos se tratan en el capitulo 8. En una empresa 0 en un dominio de aplicacion. si es ejecutable. bien porIa existencia de estandares utilizados. instrucciones y material de referencia al usuario. Un modelo. A continuacion se presentan las caractedsticas del model ado y ejecucion de los procesos software. EL MODELADO DE LOS PROCESOS SOFTWARE Uno de los aspectos basicos y fundamentales para la tecnologia de soporte a los procesos software es disponer de modelos de procesos que representen fielmente la fonna de hacer las cosas de las organizaciones. POl' 10 tanto se hace necesario intentar capturar estos aspectos comunes en una representacion de proceso. destacando los siguientes (Curtis et af. Los objetivos y beneficios que motivan la introduccion de modelos de procesos son varios. compilacion de metricas y aseguramiento de la integridad del proceso. II) G . 3. G G Provision para la automatizacion orientada al rendimiento del proceso. uno de los grandes objetivos de la tecnologia de procesos es lograr que la representacion de procesos pueda ser us ada para gestionar los procesos aChmles de desalTollo y mantenimiento del software. 1992): G Facilidad de entendimiento y comunicacion. para 10 cual es necesario automatizar ciertas partes del proceso.. Un modelo de procesos puede ser analizado. Soporte a la mejora del proceso.. En los modelos de procesos se puede describir de una fonna precisa los diferentes aspectos relacionados con los procesos software. Como primer paso. dar soporte al trabajo en grupo. que consiste en la descripcion de un proceso expresandolo en un lenguaje de modelado de procesos adecuado (Finkelstein et af. bien porque las "mejores practicas" son reconocidas fonnalmente. 10 que requiere que un modelo de procesos contenga suficiente informacion para su representacion. la tecnologia de procesos introduce la no cion de modelo de procesos.oceso que es. POI' 10 tanto. 1994). la cual describe estas caractedsticas comunes y fomenta la homogeneidad y la unificacion de criterios. de fonna que con diferentes modelos se puedan expresar las diferentes vistas de un proceso. puede ser usado para la fonnacion del personal. validado y simulado.

reglas. En este campo. mientras que los desarrolladores se relacionan indirectamente a una actividad por medio de sus roles. es decir. reglas y politicas.9RA.anlientas estan fuertemente unidas a las actividades en las que son usadas..). etc. Roles y Directivas. jefes de proyecto. Las actividades se encargan de generar 0 modificar un conjunto dado de artefactos. y procedimientos) que gobieman las actividades. y por 10 tanto deberian ser estructuradas. una actividad es un concepto con un cOl11ponente funcional fuerte ya que acarrea entradas. 3. En el siguiente apartado se presentan diversos lenguajes 0 metamodelos para la definici6n y representaci6n de modelos de procesos. Un recurso es un activo que una actividad necesita para llevarse a cabo. los diferentes elementos relacionados con un proceso software. que pueden ser usados para manejar el proceso). Producto. que tienen como objetivo representar de una fonna precisa y no ambigua. Elementos del Proceso Software En general. salidas. las herral11ientas de desarrollo (los agentes computerizados que tradicionalmente han sido usados en desarrollo del software como editores especializados y herramientas para la gesti6n. entregados y mantenidos en un proyecto es 10 que se denomina producto. Una actividad es una operaci6n at6mica 0 compuesta. El caracter de la organizaci6n impacta en el proceso indirectamente por medio de roles. etc. 1999) y que son comunes a los diferentes modelos de procesos (v ease figura 6.1. hay dos recursos de principal importancia: por un lado los desarrolladores (los agentes humanos en el proceso). conocidos como "Lenguajes de Modelado de Procesos" (LMP). obligaciones y tareas (por ejemplo disenadores.-MA CAPITULO 6: EL PROCESO SOFTWARE l03 En la literatura se pueden encontrar diversos lenguajes y fonnalismos de modelado. editores de diagral11as. y resultados intennedios. las hen. Las directivas nonnalmente vienen en manuales.) y las herramientas de prop6sito general (como hojas de ca1culo. A continuaci6n se describen los diferentes elementos relacionados con el modelado de procesos. y por otro. El conjunto de artefactos a ser desarrollados. el conjunto de responsabilidades. Ademas. 0 un paso de un proceso. incorporan e implementan procedimientos. y tambien directal11ente por medio de directivas (politicas. para 10 cual se abordan en primer lugar los diferentes conceptos comunes relacionados con el proceso software. Recurso. revisores. compiladores.2): <> Actividad. Norma1l11ente. etc. se puede identificar una serie de conceptos basicos relacionados con los procesos software (Demiame et al. <> <> <> .

La infonnaci6n de un modelo de procesos se puede estmcturar bajo diferentes puntos de vista (Curtis et al. Informativo. 0 e e e Los diferentes lenguajes de model ado de procesos. Los procesos pueden ser modelados en diferentes niveles de abstracci6n y con diferentes objetivos. Elementos Basicos de un Modelo de Procesos 3. que representa las entidades de infonnaci6n de salida manipuladas pOl' un proceso..104 CAUDAD DE SISTEivlAS Il'iFORJvIATICOS ©RA-MA Herramienta Actividad Producto Recurso Organizacion D D Figura 6. 1992): e Funcional.2. Compol"tamental. incluyendo su estmctura y sus relaciones. Organizacional. que representa cuando y bajo que condiciones se implementan los elementos del proceso. Clasificacion de los Lenguajes de Modelado de Procesos (LMP) Existen diferentes critelios para la clasificaci6n de los lenguajes de model ado de procesos. proporcionan la notaci6n necesaria para representar los procesos software y dicha representaci6n puede incluir las .2. que representa d6nde y pOl' que persona de la organizaci6n son implementados los elementos del proceso. que representa que elementos del proceso se estan implementando y que flujos de infonnaci6n son impprtantes para los elementos basicos del proceso.

CAPiTULO 6: EL PROCESO SOFTWARE 105 clases de infonnacion comentadas anterionnente. Otra posible clasificacion de los lenguajes de model ado es la establecida por McChesney (1995) seg(ill la cuallos procesos se pueden clasificar en: • Descriptivos. en la que se incluyen a los LMP que proporcionan soporte lll1icamente a aspectos de entendimiento y comunicacion y no a los aspectos de ejecucion. o Existen oU'as clasificaciones de lenguajes de modelado. cuyo objetivo es proporcionar un modelo cualitativo e infonnal. PDL) y Lenguajes de Implementacion de Procesos. Se distinguen dos tipos de modelos descliptivos : o o Informales. 1999).. como la que proporciona Ambriola et al. que pueden ser estandares. Ejemplo de este proceso es el "Proceso Unificado de Desanollo" (Jacobson et al. Formales. (1997). que estan relacionados con la evaluacion. que proporcionan una representacion de los procesos software adecuada para su simulacion a alto niveL que n0l111almente sirve de • . metodologias orientadas a objetos. que realizan actividades relacionadas con la asistencia. metodologias y metodos centrados en la gestion. Automaticos. Simulados (Simulated). En la tabla 6.. • Prescriptivos. desanollo. metodologias de ingenieria del conocimiento. ciclo de vida del software y procesos de soporte al ciclo de vida. soporte. distinguiendose entre LMP: • No ejecutable (Noll-enactable). PSL). tienen como objetivo definir los medios necesmios 0 recomendados para la ejecucion de un proceso. mejora y prediccion de procesos. Zamli y Lee (2001) proponen otra clasificacion mas generica y menos centrada en los PSEE que la anterior. en funcion de los aspectos en los que se centran. Ademas este tipo de modelos se puede clasificar en: orientado a actividades u orientado a personas. en la que se distinguen tres categorias en funcion del nivel de abstraccion: Lenguajes de Especificacion de. Procesos (Process Specification Languages. gestion y tecnicas de produccion de software asistida por ordenador. cuyo objetivo es desclibir un proceso que se esta llevando a cabo en una organizacion. PIL). y los aspectos de informacion que capturan (Acuna et al. evaluacion. (Process Implementation Languages.1 se resume un buen l1Lllnero de las propuestas de modelado de proceso existentes. Se clasifican en: o l'vfanuales. Ejemplos de este tipo de modelos son: metodologias tradicionales estmcturadas. Lenguajes de Disefio de Procesos (Process Design Languages. estandares de ciclos de vida como ISO 12207. 2001).

1999) Lenguajes Fllncionales Lengu~es Fonna1es (Curtis et a/. incluyendo l110delado de dependencias de actores (. Ii> Ejecutable (Enactable). 1991) Redes de Precedencia. Infonnativo COl11portal11ental Compoliamental.• 1994) Diagral11as de Transiciones de Estados y Redes de Pea. 1998): (Raffo y Kellner. incluyendo Diagramas de Flujo de Datos (Frailey. (Deiters y Gruhn. 3. pero no proporciona detalle suficiente para la guia y control de ejecuci6n de los procesos. 1991): (Harel y Politi. 1995). 1995) Eventos y Disparadores Control de Flujo (Finkelstein et a/. que se tratan ll~as adelante cuando se aborden estos ento1110S. Diagral11as de Estado (Kellner y Hansen. ! 992): (Huff.!\LA.Vlodelado de Datos. 1991) y tecnicas de amllisis y disello estructurado (McGo\\"an y Bohner. incluyendo diagramas entidadinterrelacion. 1994) Mode1ado Cllantitativo (Abdel-Hamid y {vladnick. Organizacional I Tabla 6. 1993) Lengu~es y Aproximaciones de [nteligencia Artificial. En la bibliografia tambien podemos encontrar una gran diversidad de lenguajes de 111odelado que han sido propuestos en relaci6n con Ento111os de IngenieIia del Software Orientados al Proceso (PSEE).106 CAUDAD DE SISTEMAS INFOR.. para poder gestionar los procesos software de una organizaci6n es 111UY importante poder definir los 111is1110S de una fO!111a sistematica y I Es un modele explicito de los constmctores y reglas necesarias para constuir modelos especificos de un detenninado dominio de interes. incluyendo las reglas y las pre'post condiciones (Ban!houti et a/ . 1990): (Bandinelli et a/. LE~G(:AJE BASE PERsPEcnvAS DE L'iFORMACION Lenguaje de Programacion Procedural (Ramanathan y SarkaL 1988) Amilisis y Diseiio de Sistemas. . Lenguajes de model ado de procesos y perspectivas de informacion A continuaci6n se descIiben de fonna general una selie de lenguajes representatiyos de 111odelado de proceso expresados en fonna de metamodelos de procesos.3. 1994) Funcional Comportamental Infonnativa Funcional Organizacional Infonnativa Funcional Comportal11ental COl11portal11ental Funcional Comportamental Organizaciona1 Funciona1 Infolmativo Omanizacional..1. Metamodelos 1 de proceso software Como se ha explicado anterionnente. que penniten que el modelo de procesos pueda ser ejecutado para guiar activamente e inc1uso controlar un proceso software. 1996) .TICOS C9 RA-ivLi\ ayuda para el disei'io de los procesos. datos estmcturados y declaraciones de re1acion (Penedo y Shu. 1989): (Kellner. 1991) ivlodelado de Objetos (Engels y Groenewegen..{u y Mylopoulos.

En la figura 6. Diagrama de Gantt EI metamodelo que representa el diagrama de Gantt es bastante simple y en eI s610 estan incluidos los conceptos de Actividad e Instante de Tiempo (TimePoint). En funci6n de los aspectos del proceso a representar sera necesario incluir unos constructores u oh·os y por ella en la literatura se puede enconh·ar una gran diversidad de lenguajes para el model ado de los procesos software.3. Estuclio Preliminar 2 Ana!lsis de Requisttos " Diseno (ociifiulci6n PruebEls 4 5 Figura 6. MODELADO DE PROCESOS: DIAGRAMAS DE GANTT Y DIAGRAMAS PERT Los diagramas de Gantt fueron creados por Hemy Gantt en el aii.1.3 se presenta un sencillo ejemplo de diagrama de Gantt. A::tividad 1 1 Dia / \ Jlctjvidad 2 2Dias Jlctjvidad 3 Jlctjvidad 4 ----+ 4Dias 3Dias Figura 6. Diagrama PERT . Representan las diferentes actividades de un proceso como ban·as sobre un calendatio aportando una representaci6n visual de las actividades.o 1917.PiTlJLO 6: EL PROCESO SOFTWARE 107 precisa para su posterior ejecuci6n efectiva.4. su duraci6n y su planificaci6n. Ello supone la existencia de diversos fOl1nalismos para modelar los procesos existiendo un alto grade de heterogeneidad.3. A continuaci6n se describen de f0l111a general diferentes propuestas de modelado de procesos.(': RA-MA CA. 3.

como la identificaci6n de caminos criticos. que representa la relaci6n entre dos entidades y puede ser de varios tipos. una tarea. surge debido a la necesidad de diversas organizaciones (MIT.V!AS I1\FO~'vl'\Tleos Los diagramas PERT (Program Evaluation and Review Techniqlle) representan grMicamente los procesos mediante un grafo dirigido en el que se incluyen las tareas. pero a su vez penniten un analisis mas complejo del proceso. ya que definen el minimo numero de constmctores necesarios. FORMATO DE INTERCAMBIO DE PROCESOS EI fonnato de intercambio de procesos (Process Interchange Format.-\UDAD DE SISTE. etc. Estos lenguajes de procesos presentados son claros ejemplos de modos de representaci6n simple.5.5 se representa en UrvIL la jerarquia de entidades que componen elmetamodelo PIF. En la figura 6. como por ejemplo un proceso. la entidad Relacion (Relation). su duraci6n y sus relaciones de precedencia.) de compartir sus modelos de procesos. de acuerdo al metamodelo PIF son: la entidad Actividad (Actidty) que se define como "cualquier cosa que OCUlTe en el tiempo". 0 incluso un evento. PIF) (Lee et af. Son mas dificiles de leer que un diagrama de Gantt.3. 1998). Dicha especificaci6n fue propuesta originalmente en 1993 y desde entonces ha evolucionado y mejorado.. Entidades del Metamodelo PIF Los principales elementos. En la figura 6.4 se muestra un ejemplo de un diagrama PERT. DEC. Stanford. 3. EI concepto de proceso en PIF es "1111 conjzmto de acth'idades COil ciertas relaciolles entre sf y con objetos ell detenninados Instal/tes de Tiempo". que enlaza una actividad con los objetos (Objects) que .108 C.2. como por ejemplo la relaci6n creates. Entity Activity Object TimePoint Relation Decision Agent Creates Modifies Before Uses Performs Activity Status Successor Figura 6.

CAPiTulO 6: El PROCESO SOFT\VARE 109 produce. y finalmente la entidad Objeto (Object). helTamientas y agentes. Algunas de estas especificaciones se pueden expresar en el ..3. Esta base minima es extendida mediante modulos de extension. LENGUAJE DE ESPECIFICACION DE PROCESOS (PSL) El lenguaje de especificacion de procesos (Process Spectfication Language. son: actividad (activity). como artefactos. El nuc1eo del lenguaje tambien inc1uye el concepto oCUlTencia_de_actividad (activio·_oclirrence). PSL define un proceso como "un conjunto de actividades en las que patticipan algunos objetos en un instante de tiempo detem1inado". a pattir de los cuales se derivan la mayoria de los elementos de los modelos de procesos. 1998) define una ontologia estimdar y un fOl1nato para el intercambio de especificaciones de procesos de fabricacion.6 se representa en UML el mic1eo del metamodelo PSL. objeto (object) e instante de tiempo (timepoint). los instantes de tiempo (timepoillts) que pueden ser una hora precisa. PSL) (Schlenoff et al.3. En PSL los tres constmctores plincipales. como por ejel11plo extensiones para el ordenamiento temporal sobre instantes de tiempo. En la figura 6. El lenguaje PSL define de una fonna muy precisa y no ambigua modelos de procesos mediante axiomas 0 definiciones usando KIF (KnOfl"/edge Interchange Format). begin Object end Timepoint at participatesjn in begin end Activity Figura 6.6. Nlicleo del Metamodelo PSL En el nllcleo del metamodelo PSL se define la base minima necesaria para la representacion de modelos de procesos. que representa todas aquellas entidades implicadas en un proceso. 0 un punto del tiempo en el que puede ocurrir un evento. 3.

vare comercializado por Rational Software. En la realizacion de una accion un actor puede utilizar cieltos recursos. define como deberia documentarse cada componente del proceso. Guia (Guidance). UPM) (Kruchten. como artefactos (arttfacts) . Para dar soporte a la ejecucion del proceso se ha aiiadido el concepto de Modelo del Mundo (WorldModel). 3.3. define los principales conceptos del proceso. Unisys. defme los elementos basicos. La base del metamodelo CPR es la definicion de planes. etc.3. Este metamodelo de procesos se ha usado para definir el "Proceso Unificado de Rational". Un plan de ejecucion se esuuctura como un plan de diseiio pero se usa para regisu"ar los resultados de la ejecucion del plan de diseiio. define mecamsmos de empaquetamiento. en el que se definen los mecanismos de nombrado Elementos Basicos (Basic Elements). El actor de una accion puede ser el recurso de otra accion. Estructura del Proceso (Process Structure). 1999) es una propuesta conjunta de organizaciones como IBM. El metamodelo UPM inc1uye seis paquetes que son: o o Nombres (names). 1998) es un metamodelo patrocinado por la agenda DARPA (Defense Advanced Research Project Agency) y se concentra en la planificacion (especificacion de un conjunto de acciones para dar sopolte a un conjunto de metas u objetivos) y la planificacion (especificacion de las cantidades de recursos usadas a 10 largo del tiempo y el tiempo en que dichas acciones tendran lugar). A pattir del metamodelo CPR es posible modelar el diseiio de un plan.7 se representa en UML el metamodelo CPR.\"Ork items). un modelo de procesos de ingenieria del soft. Componentes del Proceso (Process Components). pero otras necesitan de mecamsmos mas potentes como OCL (Object Constraint Language). En la figura 6. .5. roles (roles). CORE PLAN REPRESENTATION (CPR) CPR (Pease.TICOS @RA-MA metamodelo. o o II> 3. 0 productos de trabajo (. MODELO DEL PROCESO UNIFICADO El modelo del proceso unificado (Unified Process Model. Un plan (plan) es un conjunto de acciones (actions) necesarias para satisfacer detenninados objetivos.110 CALIDAD DE SISTEMAS INrORl'vLA. que son refinados en otros paquetes.4. Rational. pero no es posible almacenar la informacion sobre como este plan esta siendo llevado a cabo en la realidad.

r

RA-ivLI\

CAPiTULO 6: EL PROCESO SOFTWARE

III

Pia n

Actio n TimeSpec

Objective

E va lu a tio n C rite ria

Acto r

Resource

Figura 6.7. Metamodelo CPR

3.3.6. DEFINICION DE PROCESO DE LA WORKFLOW MANAGEMENT COALITION
La coa1ici6n para 1a gesti6n de flujo de trabajo (Wor~flow Management Coalition) es una organizaci6n de vendedores, usuarios, ana1istas y gmpos de investigaci6n cuyo objetivo es promover e1 uso de sistemas de flujo de trabajo. Esta coa1ici6n ha propuesto un mode10 de flujos de trabajo de referencia (WfMC, 1998) en e1 que se define un metamode10 de procesos que esta mas orientado en 1a defmici6n de aspectos de ejecuci6n frente a los aspectos de analisis. En 1a figura 6.8 se representa e1 metamode10 de procesos propuesto por 1a WfMC.
Workflow Process Definition

Workflow Relevant Data

Workflow Process Activity

may use may use

/
may involve from

Workflow Application Declaration
is performed by mayuse

to

Workflow Participant Specification
.--~--------

Transition Infotmation

-------------

Figura 6.8. Metamodelo de Definicion de Proceso de la Wfl\;lC

112

CA.UDAD DE SISTEi\1AS INFORIvLA.TICOS

:Q

RA-IvLA.

De acuerdo a la WfMC el proceso se divide en Actividades del Proceso de Flujo de Trabajo (Wor~floH' Process Activities), que pueden ser at6micas 0 podrian estar compuestas por otros subprocesos. Estas actividades se planifican mediante Infonnacion de Transicion (Transition b?lormation) sobre Datos Relevantes del Flujo de Trabajo (Worliflmr Relevant Data). LasaCtividades son realizadas por alguien 0 algo definido por una Especificacion de Participante del Flujo de Trabajo (WorJ...j7mr Participant Specification) y pueden invocar Declaraciones de Aplicacion de Flujo de Trabajo (WorkfloH' Aplication Declaration). Los datos relevantes del flujo de trabajo dan cobertura a un subconjunto de datos del dominio de aplicacion que son necesarios para especificar condiciones de h'ansicion 0 precondiciones y poscondiciones de actividad.

3.3.7. ARQUITECTURA DE SISTEMAS DE INFORMACION

INTEGRADOS (ARIS)
El metamodelo Arquitectura de Sistemas de lnfonnacion lntegrados (Architecture of Integrated b?/o17nation Systems, ARIS) (Scheer, 1998), tiene como objetivo dar soporte al modelado, analisis y reingenieria de procesos de negocio. De acuerdo a ARIS, un proceso es un conjunto de Funciones (jzlIlctions) cuyo objetivo es satisfacer Metas Corporativas (cOlporate goals). Una funcion produce Salidas (outputs) y procesa Objetos de Infonnacion (bifonnation Objects) tales como eventos y mensajes. El trabajo es realizado por Unidades Organizacionales (Organizational Units) que incluyen maquinas, computadores y recursos humanos.

3.3.8. SPEARMINT
SPEARMINT (Becker-Komstaedt et al., 2003) es una herramienta desarrollada por el Fraunhofer lESE (Institute .lor Experimental Sojhrare Engineering) (vease w\vw.fraunhofer.de) para describir procesos software. SPEARMINT sopolia la captura, documentacion, mantenimiento y amilisis de los modelos de procesos software. El metamodelo (figura 6.9) en el que se basa la herramienta es 10 suficientemente expresivo para el modelado descriptivo de los procesos. Como se puede observar en la figura 6.9,·las clases que constituyen elmkleo del metamodelo son: "Entity", "Activity", "Arti/act", "Role", "Resollrce", y "Toof'. Las asociaciones mas destacadas son: "contains", "consumes", "modifies", "produces", entre actividades y aliefactos: "involves" enh'e los roles y actividades, "lIses" entre recursos y actividades, y 'precedes" entre estados, clase absh'acta de la que heredan las actividades y las bifurcaciones de control (clase JoinSplitState). Las clases "ProdlictFlmrGraph" y "ControIFlo,rGraph" y sus asociaciones son especificas para elmodelado visual. En base a este metamodelo, la herramienta proporciona una notacion grafica similar a UML para la definicion de modelos de procesos. Ademas, de dar sopOlie al modelado, SPEARMINT proporciona capacidades para el analisis y pel111ite generar guias (Electronic Process Guide, EPG) y manuales de ayuda al entendimiento del proceso.

[;RA.-MA

CAPiTULO 6: EL PROCESO SOFTWARE

113

Figura 6.9. Metamodelo de la herramienta SPEARl'VIINT (Becker-Kornstaedt et al., 2003)

En la actualidad, las funcionalidades de SPEARMINT han sido integradas en la herramienta VINCENT (vease http://\'l\\w.iese.fhg.de/Speannint EPGO. que constituye un nuevo entomo tecno16gico desan'ollado por el tranhoufer lESE para la gesti6n del proceso software y en el que se inc1uye un repositolio con infonl1aci6n sobre: los modelos de procesos: los elementos necesarios para dar soporte a aspectos de rendimiento del proceso (plantillas, listas de comprobaci6n, etc.): y sobre los productos de trabajo producidos durante el desanollo de los proyectos. Un ejemplo de definici6n de un modelo de procesos con la helTamienta es mostrado en la figura 6.10.

114

CAUDAD DE SISTE~lAS I]\iFORIviATICOS

@R/\-MA

::>::':U

,'"isn:?!::,;",

:

[ill -----------Ii> ~

, ,
I
I , I

I

Designer

~

I

Figura 6.10. Definicion de una vista de un modelo de procesos con SPEARMINT (Becker-Kornstaedt et aI., 2003)

3.3.9. PROMENADE
PROMENADE (Franch y RibO, 1999; 2003) es un lenguaje para la modelizacion de procesos software que utiliza UML para describir sus constmctores, mediante la generacion de un profile. En la figura 6.11 se representan la extension que PROMENADE realiza sobre el metamodelo de UML para el modelado de procesos software.
Model (UML)

MetaDocument

I !

MetaRole

I SPMetamod

ModelElement (UML)

Trigger

Figura 6.11. Elementos basicos de PROMENADE (Franch y Ribo, 1999)

£' RA-iviA

CAPiTULO 6: EL PROCESO SOFTWARE

115

Como se puede observar en la figura 6.11, las clases que componen el nucleo de PROMENADE son:
e

lvfetaDocument, 1\1etaTask, MetaRole, que son consideradas como especializaciones del constructor Clase de UML. Estas tres clases son los constructores cuyas instancias caracterizan un modelo de procesos software.

e

La clase SPMetamod (Software Process Metamodel) es una subclase del constructor UML Model. Las clases Precedence y Trigger son constmctores utilizados para modelar los aspectos dimimicos de los modelos de procesos. nuevos constructores definidos en

e

Las relaciones basicas entre los PROMENADE se ilustran en la figura 6.l2.

imports-modeJs

\
has-as-maintask-cJass

\

/
/ /0 ..•
I
~

/

Imported Mod

maintaskMod 0 .. * \

1.'
model otherCI

0.. 1

dI
1

SPMeiamod

I

Class(UML)

I

1 has-as-other-cJass

mOd~/
has-as-task-CJa/,
maintaskcl 1 subtasksCI .
....---;
/

D <> 1Cl.",

model

model "'" ", 1 has-as-roJes-cJass

'"

"

''-.,

" has-as-dc cument-cJass
doesCI

1.:
iasksCI

0.:

I

"'.

1.. '
.'-.,"',

rolesCI

MetaTask

1.:

I
i
I
I

I

MetaRole

supertaskCI

·......~ask

0.. 1
has-as-subtasks-cJass

·'·... 1 '.

I I
!

MetaDoeument

I I I

has-as~~rameters

""

1

.

I

'.

parameters ",....

. ..

doc

consists-of
"

1.,* ......

1.:

I

Parameter (UML)

I

Figura 6.12. Asociaciones basic as de PROMENADE (Franch y RihO, 1999)

Este lenguaje da soporte al modelado de los procesos software estableciendo dos vistas fundamentales:

116

CAUDAD DE SISTEMAS INFORMATICOS

£RA-MA

€I

Parte estatica, que contiene la defmici6n de los elementos que fonnan parte de un modelo de procesos software. Las clases fundamentales de este modelo son: Tarea, Documento, Agente, Herramienta, Recurso, Rol y Comullicaciol1. Parte dinamica, que pennite establecer el comportamiento de los procesos software. Para ello se establecen dos tipos de constmcciones: el control proactivo, para establecer las precedencias temporales entre las tareas que llevan a cabo el proceso, y el control reactivo, para describir el comportamiento del proceso software especificando sus reacciones ante la oculTencia de eventos. El control pro activo utiliza relaciones de precedencia, definidas en el marco de UML como una clase especial de dependencia. El control reactivo se basa en reglas ECA (evento-condici6n-acci6n).

€I

PROMENADE adelmis sopolta la reutilizaci6n de modelos, para 10 cual se proporcionan los mecanismos de abstracci6n, que penniten desechar detalles de un modele; y adaptaci6n, para hacer que un modele sea mas especifico 0 preparado para ser reutilizado.

3.3.10. SPEM
SPEM (Software Process Engineering lvletamodef) es una especificacion de OMG (2002). SPEM describe un metamodelo generico para la descripcion de procesos software concretos. Esta basado en MOF y utiliza UML como notacion de modelado. Por tanto, se basa en los principios de orientacion a objetos. En esta propuesta no se da soporte a la ejecucion (enactment) de los procesos, es decir, la planificacion y ejecucion de proyectos usando un modele de proceso descrito con SPEM. Ademas del metamodelo, la especificacion SPEM tambien esta estructurada como un perfil UML (UiViL profile), es decir, una vatiante de UML que utiliza los mecanismos de extension de UML en una fOlma estandar para un proposito particular. Esto pelmite intercambiar definiciones de procesos, tanto con helTamientas basadas en MOF, como con las basadas en UML. Como metamodelo. SPEM constituye una plantilla para la creacion de modelos de procesos concretos, como podrian ser el "Proceso Unificado de DesalTollo de software de Rational" (RUP) y el modelo de evaluacion y mejora de procesos de ISO 15504. El modele conceptual de SPEM esta basado en la idea de que un proceso software consiste en la colaboracion enh'e entidades absh'actas y activas denominadas "roles de proceso" (process roles) que realizan operaciones denominadas "actividades" (actidties) sobre entidades tangibles denominadas "productos de h'abajo" ('l'Ork products). EI fundamento de los procesos software consiste en la interaccion 0 colaboracion de mllitipies roles mediante el intercambio de productos de trabajo y la ejecuci6n 0 disparo de ciertas actividades. El objetivo de un proceso es llevar un conjunto de productos de trabajo a un estado bien definido. En la figura 6.13 se representa en UML este modele conceptual basico.

~

RA-ivV\

CAPiTl'LO 6: EL PROCESO SOFTIVARE

117

Rol de Proceso

--=~~~~~0 . .*

Producto de Trabajo 0 ..* 0 ..* +salida

+entrada

usa

produce

0 ..* Actividad

0 ..*

Figura 6.13. Modelo conceptual basico de SPEM

SPEM especifica el conjunto minimo de elementos necesarios para describir cualquier proceso software concreto, sin incluir constmctores para areas 0 disciplinas especificas; de fonna que en SPEM se describe un metamodelo genelico. El objetivo fundamental de esta especificaci6n es tratar de homogeneizar la diversidad tennino16gica existente en los lenguajes de modelado de procesos software en los que los mismos conceptos se tratan con nombres diferentes. La especificaci6n SPEM esta compuesta por un conjunto de paquetes en los que se des crib en cada uno de sus elementos. Todos estos paquetes se construyen a partir del paquete SPElV!_Folllldatiol1, que es un subconjunto de UML 1.4 (OMG, 2001), y el paquete de extensiones de SPEM (SPElvI_Exlensions_Package), que aflade los constructores y la semantic a necesaria para la ingenieria del proceso software. El l1lkleo de la estructura de SPEM esta basado en la del metamodelo de UPM, estando f0l111ada por 5 paquetes: Elementos Basicos (Basic Elements), Dependencias (Dependences), Estructura del Proceso (Process Structllre). Componentes del Proceso (Process Componems). y Cicio de Vida del Proceso (Process L)/ecycle). Como se puede observar en la figura 6.14, en el paquete eSh1.1ctura del proceso se incluyen los principales elementos estmcturales a' paltir de los cuales se constmye la desclipci6n de un proceso. Los principales elementos de este paquete son: "Producto de Trabajo" (WorkProdllct) 0 artefacto, que es cualquier cosa que es producida, consumida 0 modificada por un proceso. Podria ser un fragmento de infonnaci6n, un documento, un modelo, c6digo fuente, etc; "Definici6n de Trabajo" (TVorkDe/inition) que es una clase no abstracta de operaci6n que desclibe el trabajo realizado en el proceso. Tiene entradas y salidas explicitas representadas mediante el constmctor "Parametro de Actividad" (ActivityParameter); "Actividad" (Acth'ity), que es la principal clase en la que se especializa Definici6n de Trabajo y desclibe una parte 0 partes de trabajo realizadas por un rol de proceso tales como las tareas, las operaciones y acciones que un detenninado rol realiza 0 asiste. Una actividad puede estar fonnada por un conjunto de elementos at6micos denominados "Pasos" (steps): Realizador del Proceso (ProcessPelfomer) que describe el

lIS

CAUDAD DE SISTEMAS INFOR.!'vlATICOS

@RA-MA

encargado de realizar lll1 conjunto de "Defilliciones de Trabajo" que componen un proceso y "Rol del Proceso" (ProcessRole) que es una subclase de Realizador del Proceso y desclibe las responsabilidades asociadas a los "Productos de Trabajo" junto con los roles que realizan y asisten en actividades especificas,

ModelElement
(from Core)

Classifier
(from Core)

WorkProductKind Parameter
(from Cora)

v:';ird

Parame!erOirectionKind

Operation
(from Core)

0.:

ActivityParameter
nas\·:ctf.PerA:1Jl a::t :
Bc:)~ean

WorkProduct

-,uoVio" 0 .. '

WorkDefinition
0 .. ' 0 .. '
-parer,tWOtk

+perform:.

ProcessPerformer

{ordered}

0 .. "

Activity . .
.... sep

Step

ActionState
(from ActivitjGr<l;)hs)

0 .. 1

ProcessRole
+asSs.ant

-:es;::):':sloleRcle

0 .. "

Figura 6.14. SPEM: Paquete Estructura del Proceso

SPEM no dispone de notaci6n gnifica propia, pero al ser un metamodelo basado en los constructores de U1vlL y al estar definido como profile UML, es posible utilizar notaci6n UML para representar modelos de procesos, para 10 cual se deben definir los estereotipos e iconos asociados de los constructores propios de SPENt Los principales diagramas UML que pueden ser utilizados para representar las distintas vistas de un proceso software son los siguientes:
o

Diagramas de Clases, En el contexte del modelado del proceso software los diagramas de clases pueden utilizarse para representar: herencia, dependencias, asociaciones simples, comentarios para asociar elementos de modele a guias (mediante una uri por ejemplo), relaciones entre realizadores del proceso 0 rol del proceso y productos de trabajo y la estmctura, descomposici6n y dependencias entre productos de trabajo, Sin embargo, los diagramas de clases para modelar

plantillas." ---= Manual de Usuario Figura 6. Ejemplo de Dependencias entre productos de Trabajo y Roles de Proceso representadas mediante un diagrama de clases . agregaciones simples. Producto //'~.16 se muestra un ejemplo en el que mediante un diagrama de clases se ilustra la relaci6n enh'e productos de trabajo y roles del proceso: Figura 6. En la figura 6.RA-NLt\ CAPITULO 6: EL PROCESO SOFTWARE procesos no pueden incluir interfaces.15 se muestra un ejemplo de diagrama de clases para representar dependencias entre productos de trabajo.16.d :C6digo de los Componentes :Base de Datos Fisica /" ~. asociaciones cualificadas y asociaciones n-mias. Ejemplo de Dependencias entre productos de Trabajo representadas con un diagram a de clases En la figura 6.15.

18.17.-:e:-i'.-\-MA e Diagramas de Paquetes..::4em~rt.17 se muestra un ejempio de representaci6n de un proceso y sus discipiinas asociadas.120 CAUDAD DE SISTD. En ia figma 6. Ejemplo de un Diagrama de Casos de Uso para representar Actividades y los Roles de Proceso asociados . paquetes de proceso y discipiinas. Ejemplo de un Proceso y sus "Disciplina~" asociadas representado con un Diagrama de Paquetes UML Realizar MOdelos Sfstema Arquttecto clel Sistema Realizar Modelns Usuario Figura 6.line::>::> ?rtP.L-\S INFOR.<oas Figura 6. <~Oisciplin~':>:=­ !l7.)n o:<Clzci.'vlATICOS :9 R. Los diagramas de paquetes penniten ia representaci6n de: procesos.. componentes de procesos..

2004. por ejemplo. incluyendo sus h'es aspectos principales: el proceso a seguir.f RA. En la tlgura 6. Diagramas de Transicion de Estados. Los diagramas de casos de uso se pueden utilizar para representar la relaci6n entre los Roles del Proceso y las Definiciones de Trabajo. Ejemplo de Diagrama de Transicion de Estados para representar la Actividad "Revisar los Modelos de Usuario" (i) Diagramas de Actividad.18 se muestra un ejemplo de utilizaci6n de los diagramas de casos de uso para representar las actividades de una definici6n de trabajo y los roles que asisten en su realizaci6n.3. Standards Australia. SMSDM El metamodelo SMSDM (Standard jvletamodel for Sojhrare De\'eloplIIent Methodologies) (Henderson-Sellers y Gonzalez-Perez. los estados y transiciones que representan el comportamiento de un detenninado producto de trabajo. Cuando se utiliza este tipo de diagrama para modelado de procesos el paralelismo y anidamiento estan pemlitidos. G G Initial State Revisar el Trabajo realizado en el Proceso y las Definiciones de Clases Revisar los Modelos de l!lterfaz deUsuario /"" <Step> Realizar If.19. En la figura 6.19 se representa el compOltamiento de una actividad mediante un diagrama de transici6n de estados en el que se especifican los pasos que componen la actividad y su flujo de control. 3. Los diagramas de secuencia se pueden utilizar para ilustrar la interacci6n entre instancias de elementos de SPEM. asi como los productos utilizados por dichas actividades y los roles responsables. Diagramas de Secuencia. como. los productos uti liz ados y generados y las personas implicadas. 2004) establece un marco de trabajo para la definici6n y extensi6n de metodologias de desalTollo de sofuvare.20 se muesh'a un ejemplo de diagrama de actividad.11. En la figura 6. Se utilizan para representar el comportamiento de elementos de modelado SPEM.lejorar eJ Prototipo Final State Figura 6. Los diagramas de actividad representan en el contexto del model ado de procesos la secuenciaci6n de las actividades del proceso. Este metamodelo esta basado principalmente en los metamodelos: SPEM y OPF (OPEN Process FrameH'ork) para los COnShlJctores directamente relacionados con el . pero no se pueden utilizar indicadores de historia y declaraciones de sefiales.-ivV\ CAPiTlJLO 6: EL PROCESO SOFTWARE 121 G Diagramas de Casos de Uso.

AYD.40i \ I DT-AYD. que pem1iten representar en el mismo modelo los elementos de metamodelado y sus instancias (elementos concretos de una metodologia). sino ademls se inc1uyen las guias necesarias para instanciar el metamodelo en fonna de proyectos. Integran los aspectos del proceso y del modelado en un unico metamodelo para la definici6n de metodologias.D DE SISTEMAS INFOR\I. OOSPICE para la evaluaci6n de la capacidad de procesos y LiveNet para sistemas de trabajo colaborativo basado en computador (CompllterSupported Collaborative Work. Diseiio de fa Arqulteclura de MOdulos del Sistema Generacion de A Especfficaciones l J . CSCW). SMSDM combina los anteriores metamodelos para dar soporte no ll11icamente al modelado del proceso en si.DT-AlJD.'\ TIeos &: RA-MA modelado de procesos software.122 C\UD. Ello se debe a que no s610 se proporciona un metamodelo. Ejemplo de Diagrama de Actividad Las plincipales caracteristicas del metanlodelo SMSDM se pueden resumir en las siguientes: @ Facilita la instanciaci6n del metamodelo en fonna proyectos. sino tambien a los productos y a la evaluaci6n de la capacidad tanto en el contexto del desalTollo de software como de sistemas CSCW. Mienu'as que propuestas como SPEM U @ . como OCUlTe en muchas oU'as propuestas.3tJ) 'i \ \ :Cuallernos !IeCarya :Cat4logo Detan~do de Req1iiSltos Figura 6. Para ello se utilizan "pOl rertypes" .DT.AYD. Proyaeto Apflcaciones Antiguas \ ------------r----- Inicio Bahoraeion del Modelo de Datoll(p.10l I'.\ Espeemeaeion del Plan de P[!mbas Fin (P. DT.-'l.20.20) \ 'i \ iP. de Construccioll (P.

debe ser considerada a nivel de metamodelo. Los roles son l11odelados mediante las clases ProducelKind y Producer que son los responsables (nonnalmente humanos) para llevar a cabo ciertas acciones. y se muestran ademas sus atributos y relaciones. las clases ivlodelUflitKind y Model Un it representan los bloques basicos de conshuccion de productos de trabajo y ModelUnitUsageKind y su c1ase asociada a nivel de modelo Model Unit Usage representan usos especificos de una detenninada unidad de modelo (modelunit) en un producto de h"abajo. En el nivel mas alto de abstraccion SMSDM define las clases lvlethodologyElement y ProjectElemellt para representar los elementos a nivel de metodologia y a nivel de proyecto. ya que representan elementos de distintos niveles de abstraccion. estandares como UML descliben los aspectos de modelado. El metamodelo SMSDM ha sido definido utilizando tres tipos de instrumentos complementalios: €I Definiciones de cada concepto en lenguaje natural.21 entre las subclases de estos elementos existe una relacion basada en p01\"ert)pes (representada mediante un pequeno circulo que parte del elemento de metamodelado y conecta con una linea discontinua el elemento a nivel de modelo). Las clases ActiollKind y Action representan el acto especifico de utilizar un detenninado producto de trabajo por algunos tipos de unidades de trabajo (workunits). Por otro lado. . Por otro lado los artefactos obtenidos 0 utilizados son modelados mediante las clases FVorkProdllctKind y WorkProdlict. que representa un conjunto interrelacionado de model unit kinds que pueden utilizarse para conshuir ciertos modelkinds. Esta es una dimension muy significativa que puede afectar a las metodologias definidas. y por tanto. €I El metamodelo incluye constructores especificos para modelar la cap acid ad de los procesos definidos.21 se representan en UML las clases que constituyen el micleo de SMSDM. Finalmente. la c1ase recurso se especializa en: Language. Los aspectos temporales del proceso son representados con las clases StageKilld y Stage. Cada concepto de SMSDM es relacionado con conceptos equivalentes 0 similares en otras propuestas y enfoques. respectivamente. Guideline (reglas y directivas sobre el uso apropiado de un detenninado elemento de una metodologia). Como se puede apreciar en la figura 6. Diagramas de Clases UML. Constraint (una condicion relacionada a la ejecucion de una accion) y Outcome (un resultado visible del rendimiento de un detenninado producto de trabajo). nonnalmente graficos. los aspectos de trabajo mediante las clases WorkUnitKind y vVorkUnit que representan operaciones cohesivas realizadas durante un proyecto. Notation (un conjunto de artefactos. que pueden utilizarse para representar productos de h'abajo). mas reglas de usa.CAPiTULO 6: EL PROCESO SOFTWARE OOSPICE descliben los aspectos de proceso de las metodologias. €I €I En la figura 6. en los que los conceptos son representados como clases. Equivalencias con otras propuestas.

. su nivel minimo de capacidad al que puede ser realizado (lvlinCapabilityLet'el) y los resultados esperados (outcomes)."". como L[f'eCycleKind. que representa una etapa de larga duraci6n realizada con un detem1inado enfoque y nivel de abstracci6n denu'o de un proyecto.l:. A su vez.S~r. 0 PhaseKind. StageKind y sus respectivos subtipos.21 se representa la parte del l11etal110delo SMSDM donde se l11uestran las relaciones entre las clases basicas dell11etamodelo WorkUnit y Stage: • On !ModeIUnitUsase-Kind' !..~ . 2004) Como se puede apreciar en la figura 6.a. La unidad rmis simple de trabajo es la tarea (TaskKilld) que utiliza detenninadas tecnicas (TeclllliqZleKind) para conseguir sus objetivos. un cOI~unto cohesivo pero heterogeneo de tare as que persiguen una serie. .. H'orkUnitKind es especializado en Wor~1lo-\\'Kind.!~S:.21. los aspectos de proceso son modelados mediante la inclusion de las clases WorkUllitKind. TlCOS 3RA-MA En la figura 6.de objetivos.124 CAUDAD DE SISTEMAS INFOIUvlA.21. Nlicleo de SMSDM (Henderson-Sellers y Gonzalez-Perez. que representa el proceso seguido en un proyecto. en relacion a StageKind se distinguen dos tip os de etapas: con duraci6n (Stage."0 I Notatio-o Figura 6.~:.gh:.\'ithDurationKind) y sin duracion 0 instantanea (instantaneolisStageKind). StageWithDZlrationKind es especializada en distintos constructores mas concretos.. WorkUnitKind tambien se caracteriza pOI' su prop6sito (purpose). POI' su parte.

I I I I I I I I I I I T. ' 0. ...'-' .' I •Con!oxt 0.Contexl :. 0..: CornpOfliHl! 0..k -I US05 ~ I __. o :::r 2...~ I ICumpmWI11 . 201M) .Con!m(j ~~. '" r tT1 SL_ 0: .22. Figura 6.' . I . RCpl'cscntaci{H1 dc los Aspcctos dc Proccso con SMSIlM (Hcndcrson-Scllcrs y Gonzalcz-Pcrcz._____ "tJ 6 n (f) m ::q o o (f) ~ v.___ L~_ 0' I I I I n 0' I ~ .{lil ~ ? .. I I I I _.

::lUGO I Figura 6. . 2004) y esta siendo sometido a votaci6n para su aprobaci6n como estandar ISO.-SU::.j_ _ _-j------------j+Creat<):lDate +Lasl:hangeDaie 1.TICOS .. en el que los modelos que representan los aspectos del proceso son ejecutados y controlados con la ayuda de un entomo tecnol6gico denominado Entomo de Ingenieria del Software Orientados al Proceso (PSEE). Leo Ostelweil imparti6 una charla invitada en la conferencia intemacional leSE (International COI?j"erence on Sofhmre Engineering) cuyo tihtlo fue "Sofhmre processes are sofhvare too" (Osterweil.' ... 1--____.----. +Effact ActsUpcr » +Su~lec: WorkProductKind 1.) RA-MA La relaci6n entre proceso y producto es representada mediante la clase ActionKind que es siempre realizada en el contexto de una detemlinada tarea y que se lleva a cabo sobre un detenninado producto de trabajo (WorkProdllctKind). Esta relaci6n se muestra en la figura 6. 1987).. -Cause Performs.. Introducci6n y Caracteristicas La Tecnologia de Procesos Software ha expel. ENTORNOS DE INGENIERiA DEL SOFTWARE ORIENTADOS AL PROCESO 4.: +Status -C.23.1. Este trabajo fue el inicio de una nueva fonna de abordar los procesos software.jC:: Performs.1. 4.VIAS INFORM. .23. WorkProduct ~Erkc! A:rsUpcn '" .A. Relaci6n entre Proceso y Producto en SMSMD (Henderson-Sellers y Gonzalez-Perez.mentado un intenso trabajo investigador desde que.126 CAUDAD DE SISTE.. a finales de los afios 80. ' ..... 2004) AChtalmente el metamodelo SMSDM ha sido aceptado como estindar en Australia (Standards Australia..

como pueden ser editores. 1998): (i) Un Interprete del Modelo de Procesos. un PSEE esta controlado por un motor de procesos. etc. desanollar y mantener un producto software. guiando a las personas participantes y velificando que se satisfacen las restricciones especificadas en e1 mode10 (como por ejemp10 e1 orden de ejecucion de cieltas actividades). El motor de procesos esta constiruido por los siguientes elementos (Cugola y Ghezzi. Los modelos asociados a un PSEE especifican como las personas deb en interachIar y trabajar. La linea discontinua desde el motor de procesos a la capa de comunicacion indica que el motor de procesos controla el PSEE esencialmente controlando el flujo de infol111acion entre el repositorio y los espacios de trabajo.24 se resumen los componentes esenciales de este modelo de referencia. compi1adores. junto con la definicion del producto e infol111acion relevante sobre el estado del proceso. Un Entorno de Interaccion del Usuario. henamientas de gestion de proyectos. El modelo es almacenado en un repositorio. etc. De acuerdo a este modelo de referencia. Un PSEE tambien tiene que tener la capacidad para compartir datos con el exterior mediante canales de importacioniexportacion. y tambien como y cmindo las helTamientas utilizadas en el proceso deben ser utilizadas y/o activadas autolmiticamente. que per111itan el intercambio de productos y modelos en un fOl1nato de comunicacion reconocible. documentacion. Un Repositodo. ejecutables. constihlido por las henamientas que uti1izan los usuarios.L-\ C-\piTULO 6: EL PROCESO SOFTWARE 127 Los PSEE dan soporte a los procesos de ingenielia. .RA. 1999). casos de prueba. Estas henamientas son contro1adas por e1 interprete. que las utiliza para recibir realimentacion de los usuarios y darles soporte durante e1 proceso. que son conjuntos de recursos infol1naticos que los desarTolladores utilizan cuando desempel'ian un detel1ninado rol en cierta actividad 0 tarea. Almacena los artefactos producidos durante el proceso y que son gestionados pOl' el entol110. Un elemento clave del ent0l110 10 constiruye el motor del proceso (process engine) que es el encargado de guiar y ayudar a las personas a la hora de llevar a cabo las distintas actividades del proceso. En la figura 6. a traves de un mode10 de procesos explicito definido mediante un LMP adecuado. y entre los usuarios y sus espacios de trabajos. existen otro nivel de memoria importante fOl1nado por los espacios de trabajo. (i) (i) Basado en los elementos anteriores se ha desanollado un modelo de referencia y una propuesta arquitechlral para ent0l110S PSEE en general (Fugetta et at. como pueden ser archivos de codigo fuente. cuyo objetivo es controlar el flujo de infol111acion entre los desanolladores de acuerdo al modelo de procesos. Tambien se incluye toda la infol111acion del estado achlal del proceso que esta siendo ejecutado. infol1nes. entre unos espacios de trabajo y otros. ejecuta el modelo controlando las henamientas usadas durante e1 proceso. Ademas del repositorio. usados para concebir. gestiona la infol111acion que es persistente en e1 ent0l110.-i'. y automatiza la ejecucion de las actividades que no requieren intervencion humana. agendas. diseilar..

128 CAlID. Basados en Aut6matas Extendidos.24.. como es el caso de APPLIA (Heimbigner et aI. 1993) es un ejemplo de este tipo. Arquitectura Funcional de un PSEE . Clasificaci6n de los PSEE En primer lugar cabe destacar que to do PSEE esta caractelizado por el LMP que utiliza. Usuarios ~ Usuarios A Producto. Multiparadigma. acciones y postcondiciones. Ejemplos representativos de estos lenguajes son ManJel and Merlin. SPADE (Bandinelli et al. en el que su esnuctura Plincipal esta basada en Redes de Peni. Basados en Reglas. Capa de Comunicaci6n ~ .AJ) DE SISTEMAS INFORJvlA TICOS © RI\-JvV\ 4. Ejemplos de estos lenguajes son Leu y Process Weaver que estan basados en Redes de Peni.. Estas reglas tienen asociados roles encargados de realizarlas y recursos necesarios como por ejemplo hen·amientas. 1990) que es una extension de Ada. que combinan dos 0 mas paradigmas para describir los distintos aspectos de un proceso software. como Diagramas de Estados 0 Redes de Petri. 'f A " Espacio de Trabajo Canales de importacion y exportacion Espaciode Trabajo Vf Figura 6.2. ~ " . proporciona un modelo de datos orientado a objetos para describir atiefactos y utiliza un lenguaje operacional para describir las acciones asociadas a las n'ansiciones definidas.amaci6n. j. Como se ha descrito en el apartado anterior. 1998): Lenguaje Basado en la Progr.. los LMPs utilizados pueden adoptar alguno de los siguientes cuatro enfoques (Cugola y Ghezzi. existe una gran multitud de LMPs y. caracterizados por el uso de reglas de produccion para describir los procesos software en los cuales las actividades se des crib en mediante reglas f0l111adas por precondiciones. Modelo de Procesos y Repositorio de Procesos ~ " . <ill Motor de Procesos J. en el contexto de los PSEE. <ill . fonnalismos que fueron extendidos para proporcionar una notacion mas expresiva de los procesos software. consistentes en extender lenguajes de programacion existentes introduciendo conceptos relacionados con el proceso software.

APS (Balzer y Narayanaswamy. quedando en un plano 'meramente investigador a nivel de prototipos. 1996): III Rol Pasivo.. aspecto especialmente cdtico hoy en dia en el que el mercado es muy dinamico y altamente competitivo (Demiame y Oquendo. 1993). El usuario guia el proceso y el PSEE opera en respuesta a las peticiones del usuario. 1988). Oz (Ben-Shad y Kaiser. 1990). 1991). 1988).. MELMAC (Deiters y Gmhn. 1989). la gran mayoda no ha tenido la aceptacion industrial esperada.. Slll III III III intervencion de los Un mismo PSEE puede adoptar distintas fom1as de soporte al usuario. como por ejemplo adoptar el enfoque de automatizacion para actividades que no requieren la intervencion de los usuarios y el de obligacion para el resto. PCTE (Boudier et al.RA-MA CAPiTULO 6: EL PROCESO SOFTWi\RE 129 Otro de los aspectos clave de los PSEE es el tipo de soporte que ofrecen a los usuarios. 1994). 1999): Adele (Belkhatir et al. Automatizacion. Ell0 Oligino PSEE muy dgidos que se adaptaban mal a la naturaleza de las organizaciones. En las ultimas dos decadas se han propuesto una gran diversidad de PSEE. Una de las causas mas sigr1ificativas ha sido el enfasis que los PSEE han dado a la descripcion de modelos de procesos como modelos nonnativos cuyo seguimiento debia ser estricto.. (Cugola y Ghezzi. Una comparativa de muchos de estos entomos es proporcionada por Arbahoui et al. SynerVision (HewlettIPackard Company. 1994).S (Warboys. Guia Activa. y ProcessWeaver (F emstrom. . 1994). recordandoles en todo momento que actividades debedan realizar. OIKOS (Montangero y Ambriola. Tambien es posible clasificar los PSEE en funcion de la fonna de controlar y guiar el proceso. Arcadia (Taylor et aI. GOODSTEP (Emmerich et al. 1998).. distinguiendose entre cuatro posibles tipos (Bandinelli et aI. la repercusion industrial de estos entomos ha sido minima. (2002). El PSEE ejecuta las actividades usuarios.. 1999). Merlin (Junkermann et al. HFSP (Katayama. 1990). Sin embargo. en los que el entomo inicia y controla las operaciones realizadas por las personas y Reactivos en los que el entomo queda subordinado a los usuarios. SPADE (Bandinelli et aI. Solo algunos entomos han sido comercializados como es el caso de IPSE 2. A pesar de los gr·andes avances en la investigacion de los PSEE.. El PSEE guia el proceso y pregunta al usuario cuando es necesario. 1993). Obligacion. entre los que se pueden destacar los siguientes (Hanison et al. En este caso se distingue entre PSEE Proactivos. 1993).. (Demiame et al.. 1990). Marvel (Kaiser et aI. 1993). 1993). El PSEE fuerza a los usuarios a actuar tal y como se ha especificado en elmodelo de procesos. Los usuarios son libres para decidir y realizar las acciones sugeridas por el entomo... 1994). EPOS (Comadi et aI.

Todo ella ha OIiginado una importante reflexion en la comunidad investigadora siendo algunos requisitos y retos importantes para el futuro los siguientes (Arbaoui et aI. interoperabilidad y componibilidad de procesos y la federacion de fragmentos de proceso.-\-MA 2004). Ejemplos de PSEE En este apartado se ilustran las caracteristicas de los PSEE mediante la presentacion de algunos ejemplos representativos de la bibliografia. cooperacion y negociacion entre los usuarios realizadores con sus diferentes roles.. muchas de las propuestas incluyen LMP muy complejos y poco intuitivos que ha dificultado su uso por los profesionales que prefieren lenguajes mas intuitivos y que les facilite su comunicacion y entendimiento del proceso (Fugetta. Por otro lado. En este caso deben tenerse en cuenta las consecuencias en los procesos que estan en curso y en los que ya han sobrepasado el punto de cambio en el modelo. que es un LMP basado en una extension de Redes de Petri a alto nivel. y su impacto debe ser gestionado. Un aspecto clave son las interacciones de los humanos con el PSEE. heterogeneidad. el motor de reificacion del PSEE debe ser capaz de continuar apoyando y asistiendo durante la realizacion del proceso.-\D DE SISTEMAS !l\FOR. Si la ordenacion de las actividades puede ser elaborada y modificada dinamicamente. 2002): e EI PSEE debe dar soporte dimimico a la ordenacion de actividades. Tambien implica que el PSEE debe ser capaz de dar sop0I1e a la comunicacion. Cada actividad puede incluir interacciones con usumios/helTamientas y . e e 4. En SLANG un proceso se descIibe como una jerarquia de actividades. EI PSEE debe dar soporte a la distribucion de procesos software. EI PSEE debe dar sop0I1e a la evolucion de procesos software: tanto evolucion "ot/~!ine" como "all-line".. Los PSEE tambien deben dar sop0I1e a la evolucion privada: el cambio sera local a la instancia de modelo de proceso que se esta ejecutando. disefio y ejecucion (enactment) de los procesos software. Las desviaciones del proceso respecto del modelo deben ser sop0I1adas y negociadas.\IATICOS £. 10 cual comprende la modulmidad. 4.1.. coordinacion. 1993.. R. El PML y el PSEE (como sopol1e del PML) deberian pel1nitir cierta flexibilidad que les pel1nita ser tltiles dentro de la estrategia adoptada pOl' una compai'iia.3. 2000). Para el modelado de los procesos utiliza el f0l111alismo SLANG (SPADE Language). que puede ir desde un estlicto y disciplinado proceso "dirigido por el plan" hasta un proceso completamente libre don de "la desviacion es la n0l111a".3. 1995: 1996) es un PSEE disefiado en la Universidad Politecnica de Milan que proporciona soporte al anaJisis. SPADE El ent0l110 SPADE (Bandinelli et aI. sin impactar ni en elmodelo reificado ni en el modelo en si mismo.130 CALlD.

Cada lugar tiene un nombre y un tipo y se compOlta como un repositorio que ll11icamente contiene tokens de su tipo 0 cualquiera de sus sUbtipos. arcos (acs) y transiciones (transitions). ProcessActivities. en cuyo caso se establece en tiempo de ejecuci6n y puede valiar en el tiempo. Un modelo de procesos en SLANG esta compuesto basicamente por los siguientes elementos: e ProcessT)pes. "Run Tests" tiene dos transiciones simples de entrada y salida. Existe un interfaz de la actividad "Run Tests". Los lugares pueden cambiar sus contenidos como consecuencia de transiciones de disparo (fire transitions). respectivamente "Start Test'" y "End Test". mientras que los datos del proceso se representan como tokens. Un caso particular son los lugares de inteliaz de usuario. cada vez con un detenninado caso de prueba (ready test cases). Cuando se han ejecutado todas las pruebas la actividad tennina. en las que la acci6n es la invocaci6n de una rutina ejecutable (ejemplo un fichero ejecutable en UNIX).-MA acceso a datos del proceso. La invocaci6n de helTamientas en SLANG se modela mediante "h'ansiciones negras" (black transitions). EI compOltamiento dinamico de una transici6n se desclibe mediante las reglas de disparo. Cuando se dispara la transici6n se ejecuta la acci6n asociada y los tokens de entrada pasan a los lugares de salida. Aparte del tipo nOlTnal de arco. Las actividades y estados de actividad en SLANG son representados como redes de Petli. EI peso indica el numero de tokens que fluyen tras el disparo de una h·ansici6n. que se representan mediante circulos dobles y son lugares que pueden cambiar sus contenidos como consecuencia de la intervenci6n humana. Los resultados de cada ejecuci6n se comparan con los resultados esperados y el resultado de la comparaci6n se afiade a los resultados de prueba acumulados. que es invocada por la actividad "Test jVfodule Collection".. La condici6n de guarda es un predicado sobre los tokens que peltenecen a los lugares de la transici6n de enh'ada y se usa para decidir si se dispara la transici6n. En SLANG todos los datos del proceso son caracterizados como tipos y organizados en jerarquias de herencia. Los arcos en la red pueden llevar asociados pesos (por defecto el valor es 1). dos lugares de entrada (""Executable Module" y "Ready Test Cases") y un lugar de salida ("Final Test Results "). es un conjunto de definiciones de actividad. La ejecuci6n se lleva a cabo de fonna asincrona.\"' R:\. Las transiciones representan eventos cuya oculTencia sup one una cantidad de tiempo despreciable y llevan asociadas una condici6n de guarda y una acci6n. SLANG establece dos tipos especiales para mejorar la entendibilidad: 8 . Se utilizan para transferir eventos extemos causados por humanos. El elemento raiz es el tipo ProcessData. del que heredan el resto de tipos. Una definici6n de actividad es una red de Petri a alto nivel donde se incluyen lugares (places). que es un conjunto de definiciones de tipos organizadas de fonna jerarquica de acuerdo a un estilo 00. En la parte derecha de la figura se ilustra una posible implementaci6n para la actividad en la que se representa como un m6dulo ejecutable (executable module) que es ejecutado repetidamente. Este peso puede ser definido de fonna estcitica 0 dinamica sefialada mediante un caracter "*. denominadas.

EI entomo SPADE proporciona soporte multiusuario y pennite el paralelismo entre actividades.iace). Systemes. mediante la asociaci6n de cada actividad conCUlTente con diferentes motores de proceso (instancias del intel-prete SLANG) que pueden estar distribuidos en una red de estaciones de trabajo. Los objetivos fundamentales que persigue se basan en dar soporte ala: I. e e En SPADE. se crea un nuevo servidor de mensajes que se conecta al SCI y el usuario interactlla con un intelfaz de control que Ie pennite ejecutar helTamientas y configurar su propia instancia FUSE a traves de la cual va participar en la ejecucion del proceso de acuerdo a sus responsabilidades. Interoperabilidad entre PSEE heterogeneos. Este entomo de interacci6n esta basado en DEC (Digital Equipment Corporation) FUSE (Friend(v Unified Software Environment).25): e EI Entorno de Interaccion de Usuario. para 10 cual ofrece una serie de servicios que pueden ser invocados a traves de intelfaces de programaci6n que definen protocolos para facilitar la cooperaci6n entre hen·amientas.. que facilita la integraci6n entre helTamientas. 2003) capaces de gestionar procesos complejos y distribuidos. Un Filtro.2. para conectar arcos a transiciones y overwrite para conectar transiciones a lugares. 1998: 2003) es un PSEE desan'ollado en el Laboratoire Logiciels.3. Estublier et al. 4. Reseallx. que constituye el subsistema de comunicaci6n y pem1ite conectar los motores de proceso con las instancias de DEC FUSE. que gestiona la interacci6n entre los usuarios y las helTamientas. Las helTamientas son integradas en el entomo y su invocaci6n es descrita en el modelo de procesos. En resumen. EI Entorno de Ejecucion del Proceso. 1998. de acuerdo a su arquitectura. Los datos del proceso (incluyendo los propios modelos) son almacenados en un repositorio gestionado por un SGBD Olientado a objetos. SPADE esta tambien constituido por un entomo de interacci6n del usuario.132 CAUDAD DE SISTEMAS INFORJvlA-TICOS '9 RA-ivl~ read-on(l'. pel111itiendo al disefiador del proceso construir una "federacion" de PSEE (Estublier et aI. APEL APEL (Dami et al. cuando un usuario se conecta al sistema.. . que contiene los motores de proceso (instancias de intel-pretes SLANG) y el repositorio. la arquitectura de SPADE esta constituida pOl' tres elementos fundamentales (vease figura 6. denominado SCI (SPADE Communication Intel. con el fin de hacer frente a situaciones imprevistas durante la ejecuci6n. 2. fonnado pOI' instancias de DEC FUSE.. en Francia. Evolucion del Proceso.

en la que cada PSEE compm1e una representacion COI11Lll1 del estado del proceso global de f0111m que la interaccion entre PSEE es implicita (no se realizan nunca llamadas directas entre PSEE). Cada PSEE de la federacion puede l110dificar su estado local 0 cambial el estado COmlll1 como resultado de variaciones en su estado local. en la que cada PSEE es una entidad autonoma que encapsula solo la parte del proceso del que es responsable.25. BBDD Entomo de Ejecucion del Proceso (Process Enactment Environment PEE) Figura 6.o RA-:VLA. APEL adopta una arquitectura mixta basada en dos arquitecturas basicas: arquitectura basada en controL en la que las interacciones entre los PSEE se produce mediante llamadas a rutinas de proceso. CAPiTULO 6: EL PROCESO SOFTWARE 133 Entomo de Interaccion del Usuario Servidor de Mensajes Usuario 1 FUSE Servidor de Mensajes Usuario n FUSE Filtro Interfaz de Comunicaci6n SPADE 8 Cliente 02 C!lente 02 8 00 Clients 02 Servidor 02 . Arquitectura de SPADE Para dar soporte a la federacion de PSEE existentes. En esta arquitectura existe un supervisor de PSEE que gestiona el modelo de procesos COl11lll1 a todos los PSEE y en el que se expresa el orden relativo de ejecucion de los subprocesos que tienen que llevarse a cabo por otros PSEE: arquitectura basada en estados. .

Motor Comun del Proceso. 1998): III Metamodelo Comun.26. destinada a usuarios finales del proceso y para desclipciones del proceso a alto nivel y textual.. esos eventos en peticiones a otros servidores de proceso.. Tambien se encarga de garantizar la consistencia en la federaci6n. III III III Un conjunto de servicios que varian desde serVlClOS de interfaz de usuano a servicios de control.26. que captura y gestiona todos los eventos (tal y como se han definido en el modelo de procesos 'tomllIl). que en tiempo de ejecuci6n contiene el modelo de procesos y la reificaci6n de todas las entidades creadas por el proceso en ejecuci6n. Modelo de Procesos Comun. Modelo de Interoperabilidad. Servidor de Eventos. Como se puede apreciar en la figura 6.134 CAUDAD DE SISTE'. Su intelfaz pennite a los componentes crear cualquier entidad y cambiar de fonna arbitraria el proceso actual. Para dar soporte a la interoperabilidad entre distintos PSEE la arquitechlra basic a de APEL ha evolucionado para incorporar los siguientes elementos adicionales (Eshlblier et al. asi como el modelo. Un estado comun. Un compilador de la representaci6n textual a un fonnalismo ejecutable. APEL tiene dos fonnas de representaci6n del proceso: gnifica. que recibe peticiones de los motores de proceso en fonna de evento y transfonna si es necesario. la arquitectura consiste basicamente en: III Un editor gnifico para capturar y modelar procesos. Este es el aspecto basico que da soporte a la evoluci6n del proceso en APEL. para facilitar el intercambio de infonnaci6n y entendimiento de los distintos PSEE de la federaci6n.IAS lNFOR{>'IATICOS QRA-'. 1998) se ilustra en la figura 6. que mantiene el estado actual del proceso en ejecuci6n y de las entidades creadas durante la ejecuci6n. Servidor del Proceso.IA La arquitectura basica del ent0l110 APEL (Dami et ai. para usuarios avanzados y henamientas. Un traductor de la representaci6n grafica en textual. que en funci6n de los eventos que recibe del servidor de eventos se encarga de la ejecuci6n del modelo de procesos comllIl asegurando que se cumple la semantica del proceso del servidor del proceso. III III III III III .

Estos elementos pueden tener estados. que representa las actividades y las reglas que pem1iten su ejecuci6n y ordenaci6n en el tiempo. El flujo de datos. un flujo de datos conecta la salida de una actividad a la enu'ada de otra actividad y representa un estado de datos intennedio dentro de un proceso. muestra c6mo los productos fluyen a traves de las actividades que los producen. En APEL. u'ansfonnan 0 consumen. Arquitectura Basica de APEL El entomo APEL recibe su nombre del lenguaje de modelado utilizado: Abstract Process Engine Langllage. La noci6n de estado y evento constituyen el nllcleo de los aspectos dinamicos del metamodelo APEL. Describe los aspectos relacionados con la secuenciaci6n de las operaciones y la interacci6n entre operaciones concurrentes. De este modo. producto y agente. Los conceptos basicos del fom1alismo APEL para elmodelado de los aspectos estaticos son: actividad. que vaIian como consecuencia de transiciones que se disparan debido a la ocurrencia de eventos.26.CAPiTULO 6: EL PROCESO SOFTWARE 135 Campiladorl Interprete _ _ _ _ _ _ _-'-_ _ _ _ __ _ ______v_ Motor del Proceso Saporte en Tiempo de Ejecuc!6n Metodos Built-In jyietoaos de Usu8no Herramlentas de Usuario Servicios de Ejecuci6n Modelo Principal Figura 6. los ~spectos dinamicos del proceso son descIitos mediante: e El flujo de control. e .

1998) En la figura 6. SERENDIPITY Serendipity (Grundy y Hosking. que es una extension del lengIlaje VPL (Swenson. as! como una extension que pen11ite modelar los eventos que intervienen en la ejecucion del proceso. COlllroi:flolr 5D Figura 6.27 se muestra un ejemplo en el que se pueden apreciar como se representan gnificamente en APEL las actividades. Como lenguaje de modelado Serendipity usa EVPL (£). que preserva la .136 CAUDAD DE SISTEMAS INFO&vlA TlCOS @ RA. CSeW) en los PSEE. Representacion en APEL de flujos de control. SD). que son definidos para un producto.27. Para ello. 1994). flujos de datos y diagram as de estados (Dami et al. 1998) lOonstituye un ejemplo muy representativo de la influencia e importancia de los entomos de soporte al trabajo colaborativo (Computer-Supported Cooperative Work. e Diagramas de Estados (State Diagrams.-ivLA. proporciona un nuevo lenguaje gnlfico de modelado de procesos que pen11ite tanto el modelado descriptivo de procesos indicando el trabajo a realizar.3.. flujos de datos y control y diagramas de estados. agente 0 actividad y representan la evolucion de dichos elementos en el tiempo as! como los eventos y condiciones que producen los cambios de estado. 4.3.:tended Visual Planning Language). Este PSEE integra el modelado de procesos y el soporte al trabajo cooperativo para dar sopOIte a gI'andes sistemas de naturaleza colaborativa.

es necesario especificar por ejemplo . with e~ ~:® rR d"'. [EJ t"lk. desde modelos de procesos de trabajo genericos y reutilizables... . aliefactos y henamientas y conexiones de "uso" entre etapas del proceso y representaciones de roles artefactos y henamientas.••• Figura 6.t.::. (U) .. .- :'if"" 'J'.:3 : t". d~s: igfl chtln9~S: "~d.2 : cod~:C:!r (... © d~$i9n~:c X ~ I=:J F\. . cAPIn.- :IJ!. 2003) Los elementos de EVPL descritos hasta el momenta solo penniten la descripcion estcitica de un modelo de procesos en los que linicamente se incluyen flujos de "ejecucion" entre actividades... representaciones para elementos relevantes del modelo como los roles.::r ch~c}~ cn..•..!) rR t1~d"...."dif i". Sin embargo..r) ..28. De este modo EVPL puede ser utilizado para modelar.. Ejemplo de EVPL (Grundy y Hosking.J)H~ '''It"... para mejorar la entendibilidad y las referencias entre modelos. .. Algunas novedades que incorpora EVPL son: identificadores de proceso.. ....:>dif i"..1l".."''.dit. ~. (U) ~ .28 muestra un ejemplo de un modelo de procesos representado con EVPL. hasta planes de trabajo concretos para lill proyecto en particular... ) ml ... sus dependencias temporales y los roles y henamientas necesarios....-\RE 137 nocion de "planes de trabajo" (H'ork plans) pero afiade capacidades especificas para dar soporte al modelado de procesos genericos. La figura 6..J.u i Id". 1 : d<i'::~ ign~X' ~ {. m 1:modell -roles @ miW ml .f) •.JLo 6: EL PROCESO SOFTIV..~ (. r orm:f. ml .~ RA·YLA.tln9~s ~.. .ign u. que representa la definicion del subproceso "modificaciones del disefio" en el que se muestran las actividades (stages) a realizar.. (A) fI.~s: i9n~:J.

asi como reglas y restricciones de los modelos. Una vez definido el modelo de procesos en Serendipity.29.~¢~. artefactos.-:.~~"....~ .. basados fundamentalmente en los conceptos de "filtros" y "acciones".~:. Para ella EVPL incorpora constructores especificos. Un modelo de procesos es ejecutado mediante la selecci6n de la etapa del proceso a ejecutar a traves del interfaz de usuario del entomo. En la figura 6. -. el entomo envia un evento de ejecuci6n (enactment) a la etapa del proceso a ejecutar.213/1996 11:4'5:49 jOM £ini~f'.. 2003) . Las etapas que aparecen sombreadas son aquellas que estan en ejecuci6n (sin haber finalizado alm).~. que a su vez envia eventos de enactment a todas sus etapas conectadas.. De la misma fonna los flujos de eventos que han activado alguna etapa tambien aparecen destacados en el modelo. Cuando se ha completado el trabajo asociado a dicha etapa del proceso 0 un subproceso se producen eventos de finalizaci6n iniciandose la ejecuci6n (en funci6n del tipo de conexi6n) de las siguientes etapas.~~~~~:.. se debe indicar la etapa de comienzo. dependencias entre etapas del proceso que pertenecen a distintos modelos.i'th " :1::: dc..29 se muestra un modelo de procesos que esta siendo ejecutado.~. mientras que la etapa actual sobre la que el usuatio esta trabajando es destacada en negrita.ew i) (Rdd l Delete 1 ( Redo Conte!!t ) ( Undo 1 l Cancel J Figura 6..:top fi:tin ~fl OO:@ Ii O.''::"::9-1:.ed this :.:.. este puede ser ejecutado por los usuarios para un detenninado proyecto en cualquier momento. que reciben eventos de etapas del proceso. roles u otros filtros y acciones.. 22/3/1996 11: 45: IS j cb.. eventos de modificaci6n de artefactos y de invocaci6n de herramientas.t:::tge with" . Ejemplo de Modelo en Ejecucion (Grundy y Hosking. herramientas. : . Una vez iniciada la ejecuci6n por el usuario..d this :.: .:~~ ~~~~:~dt~~~/~:~:~.!'< igrl "I _ 2..138 CAUDAD DE SISTEMAS IN"FORIvlA TIeos ©RA-MA. l>'t::lrt.i::: ii...~. El usuario tambien debe especificar el motivo de la ejecuci6n y si la etapa del proceso tiene defmidos submodelos de procesos. La intelfaz del entomo facilita al usuatio seleccionar cualquier etapa a ejecutar y visualizar una lista de las etapas que ha ejecutado. Los procesos en ejecuci6n pueden ser modificados en cualquier momento con el fin de extender y mejorar la propia especificaci6n del proceso.

o Derniame J. (2000). evaluando de fonna critica los logros obtenidos y las direcciones en las que se deben enfocar los trabajos futuros. A. 4. Los usuarios pueden exportar su alternativa al espacio de trabajo compartido de forma que los usuarios pueden mezclar dos 0 mas altemativas para producir una nueva versi6n.~ RA-tvL~ CAPiTULO 6: EL PROCESO somvARE 139 Para dar soporte al trabajo colaborativo en Serendipity.. Wastell D. vol. semisincrona y asincrona. y mas concretamente en los Entomos de Ingenieria del Software Olientados al Proceso y los Lenguajes de Modelado de Procesos que Ie dan soporte. cada usuario tiene una versi6n alternativa del modelo de procesos la cual modifican independientemente de otros usuarios. o o Proceedings of the European Workshop on Sofnvare Process Technology (EWSPT). que proporcionan facilidades de edici6n de notas. LECTURAS RECOMENDADAS o Cugola. pp. las vistas de los modelos de procesos pueden ser compartidas entre los desarrolladores de forma sincrona. Springer Verlag. Serendipity ha sido integrado con pequenas herramientas CSCW. mensajeria.unitlier. 101-123.infonnatik.e. Sofnmre process . conversaci6n y comunicaci6n en general entre las personas que interacruan con el entomo. Sofnvare Process: A roadmap. Lecture Notes in Computer Science. Sofnmre processes: a retrospective and a path to the jiltllre. Methodology and Technology. y Ghezzi. En la forma de edici6n asincrona. Kaba A. Este workshop fue iniciado en el ano 1991 bajo la denominaci6n "Workshop . LNCS N°1500. Proceedings of the 22th International Conference on Sofuvare Engineering. January 1999. G. En la forma de trabajo semi-sincrona. 2534. identificando sus puntos fuertes y debiles. Para facilitar el trabajo colaborativo. La edici6n sincrona usa la metMora del espacio de trabajo compartido en el que todos los usuarios comparten los mismos datos y las vistas de estos datos son editadas sincronamente usando un enfoque "10 que tll ves es 10 que yo veo". Este articulo presenta de fonna general la historia en la investigaci6n del proceso sofuvare. Sofnvare Process: Principles. Fuggetta.de/~ley/db/conflewspt/ El workshop constituye la referencia europea mis importante en la investigaci6n en tecnologias de proceso Sofuvare. Este articulo presenta las caracteristicas de los principales enfoques que se han seguido en la investigaci6n de los procesos software a 10 largo de la his tori a. los cambios hechos por un usuario son enviados a otros usuarios de interes mediante dialogos y vistas de forma que estos usuarios puedan elegir si incorporar esos cambios en sus modelos. http://w\vw. Este libro proporciona al lector una panoramica completa del campo de los procesos software enfocada en las tecnologias de proceso software. Limerick (Ireland). 5. asi como los aspectos a mejorar que pennitan seguir avanzando en el futuro.Improvement and practice. 1998. pp.. e. (eds) (1999).

5. Septiembre-Octubre 2004. b. y Canfora. . Realizar una busqueda bibliografica para analizar la influencia que tienen los sistemas de h'abajo cooperativo basado en computador (CSCW) en los Entornos de Ingenieria del Software Orientados al Proceso. EJERCICIOS 1. " Revista NOVATICA.140 CAUDAD DE SISTEvU\S fNFORc\l'\ TICOS Europeo sobre Modelado de Procesos Software". SPEM (Software Process Engineering Metamodel). (.map. incluyendo un ejemplo de aplicaci6n.csi.es/csi/metrica3D utilizando los siguientes Lenguajes de Modelado de Procesos: a. (eds). Diagrama de Gantt. 6. y en particular de los Sistemas Gestores de Flujos de Trabajo en los Procesos Software.\vw.html. Realizar un ejemplo en el que se aplique uno de los Entornos de Ingenieria del Software Orientado al Proceso analizados en este capitulo para un caso particular de Proceso Software.Que lenguaje de los utilizados anterionnente proporciona mayor expresividad para representar dicho proceso? 2. G. Representar el proceso de METRICA 3 "Planificaci6n de Sistemas de Informaci6n" (vease http://w. Ntllnero 171.onv'issues/2004/5/upQ:rade-vol-V -5 . 4. Este numero especial de la Revista NovaticalUpgrade presenta una monografia sobre la tecnologia de los procesos software. Ruiz. (. nombre que fue cambiado en el ano 1992 por el actual. 3. c. F. MOl1ografia sobre Teenologia de Proeeso Sofhrare.Cuai ha sido ia evoiuci6n en ia tecnoiogias de procesos software hasta nuestros dias? (veanse lecturas recomendadas). Diagramas de Actividad UML. En http://w\vw. Versi6n en ingles UPGRADE: The European Journal for Informatics Professional. Analizar la influencia de la tecnologia de los Procesos de Negocio.upgrade-cepis.

A 10 largo de la historia se han propuesto diferentes paradigmas 0 ciclos de vida para el software: desde el ciclo en cascada.Software ltfe-cycle processes" (Proceso del ciclo de vida sofuvare) (ISO. tanto IEEE como ISOIlEC han publicado normas tituladas. abarcando la vida del sistema desde la definicion de los requisitos hasta la Jlnalizacion de Sll lISO". e "Information technology . 2002a.CAPITULO 7 MODELOS DE PROCESO DE CICLO DE VIDA . Por otro . la explotacion y el mantenimiento de un prodllcto de softlvare. y en el que se definan los procesos. 1995. ISO. hasta los mas recientes ciclos de vida orientados al objeto. "IEEE Standard for Developing Software Ltfe C. Una vida illlitil es lIna mllerte prematura " Goethe 1. La nonna ISO 12207 entiende por modelo de ciclo de vida "lin marco de referencia que contiene los procesos. las actividades y las tareas a desarrollar. 1995a. CONCEPTO DE CICLO DE VIDA Uno de los problemas IU:is importantes en cualquier depaItamento de sistemas de informacion es definir un marco de referencia comun que pueda ser empleado por todas las personas que participan en el desaITollo de los sistemas. como el ciclo de vida fuente • (Piattini et aI.vcle Processes" (Estandar IEEE para el Desarrollo de Procesos del Ciclo de Vida del Sofuvare) (IEEE. las actividades y las tareas involucradas en el desarrollo.. pasando por el modelo en espiral de Boelun. 2004e).. 2003). 1998c). Las organizaciones profesionales y los organismos intemacionales se han venido ocupando del ciclo de vida del sofuvare. respectivamente.

supervision del proveedor y aceptacion del cliente. las actividades que se pueden realizar durante el cicio de vida del software se agrupan en procesos principales. PROCESOS DEL CICLO DE VIDA SOFTWARE En la nonna ISO 12207.de este proceso es obtener el producto 0 servicio que satisface la necesidad expresada por el cliente. 2. seleccion de proveedor. por tanto. vease figura 7.1. A continuacion se resumen los principales estandares relacionados con los ciclos de vida propuestos por las nonnas ISO 12207 y 15288. procesos de soporte y procesos generales (de la organizacion). ni prescribe como realizar ninguna de las actividades. destacando que un modelo de cicio de vida es "un marco de procesos y actividades relativas af cicio de vida que actlia tambibl como una referencia comzin para fa cOlllllnicacion y ef entendimiento".\TICOS lado. gestion del software 0 metodo de ingenieria. Este proceso proporciona un producto cliente que satisface los requisitos acordados. Los procesos plincipales son: e Proceso de adquisicion. toda la vida del sistema. la explotacion 0 el mantenimiento del software durante su cicio de vida. Procesos principales Los procesos principales son aquellos que son titiles a las personas que inician 0 realizan el desarrollo. El propos ito . se resumen a continuacion sus principales subprocesos: . que es un subconjunto del anterior y que empieza en el amilisis y finaliza con la entrega del sistema al usuario. El cicio de vida abarca. A veces tambien se habla de "cicio de desarrollo". la nonna ISO 15288 (ISO. comenzando con su concepcion y finalizando cuando ya no se utiliza. 2. Debido al interes que tiene este proceso. El proposito de este proceso es transfonnar un conjunto de requisitos en un producto 0 sistema bas ado en sofuvare que satisface las necesidades planteadas por el cliente.1. 2003) define cicio de vida de los sistemas como "fa evofllcion en ef tiempo de lin sistema de inten?s desde su concepcion hasta su retirada". 0 e serv·icio al e Proceso de desarrollo.142 CAUDAD DE SISTEMAS INFOIUvl. Hay que destacar que la nonna no fomenta 0 especifica ningtin modelo concreto de cicio de vida. as! como un proceso que pennite adaptar el cicio de vida a cada caso concreto. Este proceso consta de cuatro subprocesos: preparacion de la adquisicion. Proceso de suministro.

Disefio del software. euyo objetivo es identificar que requisitos del sistema que deben ser ubicados en los elementos del mismo... REUTIUZACION INGENIERiA DE DOMINIO PROCESOS DE SOPORTE DOCUMENT ACION GESTION DE LA CONFIGURACION ASEGURAMIENTO DE CAUDAD VERIFICACION VAUDACION REVISION CONJUNT A AUDITORiA GEST.. EXPLOT ACION MANTENIMIENTO PROCESOS ORGANIZACIONALES GESTION INFRAESTRUCTURA MEJORA RECURS OS HUMANOS GESTION DE ACTIVOS GEST...... cuyo objetivo es produeir unidades de software ejecutable que reflejen apropiadamente el disefio del software. as! como establecer una linea de configuraci6n (baseline) que sirva como base para definir los productos de trabajo necesarios.(. o o o o o . RA. cuyo objetivo es recopilar. RESOLUe. Analisis de requisitos del sistema. cuyo objetivo es tranSf0l111ar los requisitos definidos por los participantes 0 implicaClos (stakeholders) en un conjunto de requisitos tecnicos del sistema deseado que guianln el disefio del sistema. Procesos del cicio de vida software segun ISO 12207 o Elicitacion de requisitos.1.. EV ALUACION DE PRODUCTO GEST. procesar y seguir la traza de las necesidades y requisitos del cliente a 10 largo del ciclo de vida del producto 0 servicio. PROG. Construccion del software. Analisis de los requisitos del software...-lvLA CAPITULO 7: MODELOS DE PROCESO DE CICLO DE VIDA 143 PROCESOS PRINCIPALES ADQUISICION SUMINISTRO DESARROLLO .. PROBLEMAS USABIUDAD . euyo objetivo es estableeer los requisitos de los elementos de software del sistema. Disefio arquitectonico del sistema.. PETICIONES DE CAMBIO PROCESODE ADAPTACION Figura 7. cuyo objetivo es proporcionar un disefio para el software que implemente los requisitos y pueda ser velifieado respecto a los mismos.

2. cuyo objetivo es asegurar que la implementaci6n de todos los requisitos del sistema se prueba para la confonnidad y que el sistema esta listo para entregar. Este proceso incluye la modificaci6n de un sistema 0 producto sofuvare despues de la entrega para cOl1'egir los fallos. que demuestra que se satisfacen los requisitos funcionales y no funcionales sobre una platafonna equivalente 0 completa. Instalacion del software. €I . cuyo objetivo es integrar los elementos del sistema (incluyendo elementos sofuvare. Esta modificaci6n 0 la retirada de los productos existentes debe hacerse preservando la integridad de las operaciones organizacionales. elementos hardware. Procesos de soporte Estos procesos sirven de apoyo al resto y se aplican en cualquier punto del ciclo de vida. cuyo objetivo es confinnar que el producto sofuvare integrado satisface los requisitos defmidos. Este proceso incluye la operaci6n del producto software en su entomo final y proporcionar soporte a los clientes del mismo. Integracion del sistema. Proceso de mantenimiento. operaciones manuales.ATICOS :&:RA-MA €I Integracion del software. Prueba del software. cuyo objetivo es combinar las unidades de software produciendo elementos de software integrados. €I €I €I €I €I €I 2. cuyo objetivo es instalar el producto sofuvare que satisface los requisitos acordados en el entomo objetivo. Los procesos de soporte son los siguientes: €I Proceso de documentacion. consistentes con el disefio software. Este proceso sirve para establecer y mantener la integridad de todos los productos de trabajo de un proceso 0 proyecto y hacerlos disponibles para las partes involucradas. y otros sistemas) para producir un sistema completo que satisfaga el disefio del sistema y las expectativas de los clientes expresadas en los requisitos del sistema. Consta de dos subprocesos: usa operacional y soporte al cliente. Este proceso sirve para desaITollar y mantener la infonnaci6n sofuvare registrada producida por un proceso. Proceso de operacion. Proceso de gestion de la configuracion.144 CALIDAD DE SISTEMAS INrORM. Prueba del sistema. 0 adaptarlo a un entomo modificado. mejorar el renditniento u otros atributos.

Proceso de revision conjunta. Proceso de gestion de la resolucion de problemas.~ RA. Se desarrolJa una estrategia para lJevar a cabo el aseguramiento de la cali dad Se ·produce y mantiene evidencia del aseguramiento de la calidad Se identifican y registran los problemas y/o no confonnidades con los requisitos acordados . e e e e e e . procesos y actividades de los estandares. Este proceso sirve para confinnar que todos los productos de trabajo y/o servicios software de un proceso 0 proyecto reflejan de fonna apropiada los requisitos especificados.-MA CA. Este proceso pennite asegurar que todos los problemas descubiertos se identifican. Proceso de evaluacion de productos. la mejora de la productividad y calidad del trabajo. la mejora de las condiciones de trabajo de las personas y la reducci6n de la probabilidad de rechazo del sistema por parte del usuario. Resultados del proceso de aseguramiento de la caUdad segun ISO 12207 e Proceso de verificacion. Este proceso pemlite detenninar. Proceso de usabilidad.1 se reflejan los resultados de este proceso segllI1 el estandar ISO 12207. Este proceso pennite asegurar. Este proceso sirve para confinnar que se cumplen los requisitos para el uso pretendido del producto de trabajo software. gestionan y controlan hasta su resoluci6n. mediante el examen y la medici6n sistem<iticos. analizan. Proceso de auditoria. Proceso de validacion. --7 --7 --7 --7 Se veri fica el cumplimiento por parte de los productos. Este proceso sirve para mantener un entendimiento COmllI1 entre las diferentes partes involucradas sobre el progreso respecto de los objetivos del acuerdo y 10 que debe hacerse para ayudar a asegurar el desan·ollo de un producto que satisface a las partes involucradas.1. que un producto satisface las necesidades implicitas y explicitas de los usuarios de ese producto. de fonna independiente.piTlJLO 7: MODE LOS DE PROCESO DE CICLO DE VIDA 145 e Proceso de aseguramiento de la calidad. En la tabla 7. Este proceso asegura que los productos de trabajo y los procesos cumplen las previsiones y planes predefinidos. Estas revisiones conjuntas se dan a 10 largo de toda la vida del proyecto tanto a nivel de gesti6n del proyecto como a nivel tecnico. procedimientos y requisitos aplicables Tabla 7. la confonnidad de los productos y procesos seleccionados con los requisitos. planes y acuerdos. Este proceso pennite asegurar que se consideran los intereses y necesidades de las partes involucradas con el fin de pennitir la optimizaci6n del sopOlte y de la fonnaci6n.

se resumen a continuaci6n sus principales subprocesos: Alineamiento organizacional. monitOlizar. establecer. e Proceso de gestion.2 se reflejan los resultados de este proceso seglin el estandar ISO 12207. con el fin de asegmar que estos satisfacen los requisitos de los c1ientes. analizar y controlar los riesgos de fonna continua.146 CALlDAD DE SISTElvt\S Il'lFORl\1A. Gestion de proyectos. Se llevan a cabo nonnalmente a nivel organizativo. cuyo objetivo es identificar. cOOl·dinar y monitOlizar las actividades. Gestion organizacional. Este proceso sirve para asegmar la aplicaci6n consistente de practicas para la organizaci6n y los proyectos. e e o o o o . sean consistentes con los objetivos de negocio. Este proceso persigue organizar.3. Estas practicas son inherentes a la gesti6n de una organizaci6n pero deben concebirse para ser instanciadas para cada uno de los proyectos. Gestion de riesgos. cuyo objetivo es conseguir la satisfacci6n de los c1ientes. tanto a nivel organizacional como tecnico. dmante la realizaci6n de los procesos necesarios para proporcionar productos y servicios sofuvare. fuera del ambito de proyectos y contratos especificos. monitorizando la calidad de los prod~ctos y servicios. gestionar. cuyo objetivo es asegmar que los procesos software necesarios para la organizaci6n para proporcionar productos y servicios software. Procesos organizacionales Se emplean para establecer. Gestion de calidad. a nivel organizacional y de proyecto. Medicion. tareas y recmsos necesarios para que un proyecto produzca un producto y/o servicio en el contexte de los requisitos y reshicciones del proyecto. cuyo objetivo es establecer y llevar a cabo las practicas de gesti6n del sofuvare que sean consistentes con los objetivos de negocio de la organizaci6n. para sopOliar la gesti6n eficaz de los procesos y demosh·ar de fonna objetiva la calidad de los productos.TICOS ©RA-MA e Proceso de gestion de las peticiones de cambio. cuyo objetivo es identificar. Debido al interes que tiene este proceso para la gesti6n de la calidad. sometidas a seguimiento y controladas. El prop6sito de este proceso es asegurar que las peticiones de cambio son gestionadas. En la tabla 7. cuyo objetivo es recopilar y analizar datos relacionados con los productos desanollados y los procesos implementados en la organizaci6n y sus proyectos. 2. implementar y mejorar la organizaci6n consiguiendo ser mas efectiva. y controlar el inicio y el desempefio de cualquier proceso para conseguir sus objetivos de negocio de la organizaci6n.

Proceso de mejora. Se compone de u'es subprocesos: establecimiento de procesos.2. Este proceso sirve para planificar. FOl1nacion y Gestion del Conocimiento. y se confim1a el desempefio. Este proceso pennite mantener una infraestructura fiable y estable necesaria para soportar el desempeiio de los o1:ros procesos. Resultados del proceso de gestion de calidad segun ISO 12207 e Proceso de infraestructura. estandares y facilidades para el desanollo. El estado actual de los procesos podria detel1ninarse mediante el proceso de valoracion. Esta infraestructura puede incluir hardware. gestores de activos. infonnes de satisfaccion del cliente. conu'olar y monitorizar el programa de reutilizacion de una organizacion y explotar de fonna sistematica las oportunidades de reutilizacion. consistente con las necesidades de la empresa. de las actividades de control y aseguramiento de la calidad identificadas Se monitoriza el desempefio real respecto a los objetivos de calidad Se toman las acciones oportunas cuando no se logran los objetivos de cali dad -7 -7 -7 -7 -7 Tabla 7. Este proceso sirve para proporcionar a la organizacion los recursos humanos adecuados y mantener su competencia. software. operacion 0 mantenimiento. Proceso de gestion del programa de reutilizacion. henamientas. ingenieros del dominio. Proceso de recursos humanos. Este proceso sirve para gestionar la vida de los activos reutilizables desde su concepcion hasta su retirada. Este proceso sirve para mejorar de fonna continua la efectividad y eficiencia a u'aves de los procesos utilizados y mantenidos de fomm alineada con las necesidades de negocio. Las partes afectadas podrian incluir a los adminisu'adores del programa de medicion. metodos. establecer. Las fuentes de infom1acion que pueden proporcionar las entradas para el cambio son: resultados de valoracion de procesos. valoracion de procesos y mejora de procesos. auditorias. Este proceso incluye tres subprocesos: Gestion de Recursos Humanos. Proceso de gestion de activos. e e e e . eficiencialefectividad organizacional. tecnicas. encargados de operacion y encargados de mantenimiento.~ RA-ivlA CAPiTULO 7: MODElOS DE PROCESO DE CIClO DE VIDA 147 -7 Se establecen objetivos de cali dad basados en requisitos de calidad implicitos y explicitos definidos por el c1iente Se desarrolla una estrategia global para conseguir los objetivos definidos Se establece un sistema de gesti6n de calidad para implementar dicha estrategia Se realiza. desanolladores. coste de la calidad. gestionar.

4. entre otros. las variaciones en las politicas y procedirnientos de la organizacion. arquitecturas de dominio y activos para el dominio. 2. los metodos y estrategias de adquisicion. Estos datos tienen que dar soporte a las siguientes acciones: . e Proceso de ingenieria de dominio.TICOS :g RA-ivL-'I.. explotar 0 mantener un sistema (vease figura 7.2). / METODOS ENTORNO MATRIZ DE RESPONSABILIDADES CREDENCIALES (ISO 9001. influencian la fonna de adquirir.A.2.1 DES r-- ~ /" MANUAL DE CAUDAD I PROCEOIMIEI'HOS Figura 7. desalTollar. el tamano y complejidad de los proyectos. Como se sabe. Este proceso sirve para desalTollar y mantener modelos de dominio. ) CAPACIDAD DE LA ORGANlZACION AOQ sm. Proceso de adaptacion Este proceso sirve para realizar la adaptacion basic a de la nonna ISO 12207 con respecto a los proyectos de software.. los requisitos de sistema y los metodos de desaITollo. OTRAS ENTRADAS MODELOS Y METODOS ESTANDAR DE PROCESOS DE CICLO DE VIDA DEL SOFTWARE ISO/IEC TIEMPO I-- b\ CASCADA DINERO D I REQUISITOS I LEY SEGURIDAD I SEGURIDAD FislCA APLlCACfON ADAPTACfON EVALUACION PRUEBAS ETC.. Ejemp\o de aplicacion de la norma ISO 12207 En el estandar IEEE (1998d) se dan recomendaciones sobre como registrar datos del cicio de vida resultantes de los procesos del cicio de vida del estandar IEEE (1998c)..148 CAlIDAD DE SISTEMAS INFORM.. .

lODElOS DE PROCESO DE CIClO DE VIDA 149 e Describir y registrar infoDnacion sobre el producto software durante su ciclo de vida. Objetivos del proceso de aseguramiento de la calidad segun IEEE (1998a) Estos datos del ciclo de vida deben ser no ambiguos. y critelios y fundamentos para las dccisiones clave. Identificar estandares. En la tabla 7. consistentes. tJ'azables.(. Proporcionar historia sobre los cambios de los datos. . Comunicar informacion sobre el sistema. datos de configuracion. e e e ~ ~ ~ ~ ~ ~ Tabla 7. producto proyecto a quien 10 necesite. datos de prueba. Dar soporte a la usabilidad y mantenibilidad de un producto software. analisis de causas raices. Debetian tener contenido relativo a datos de requisitos. estado de las acciones con-ectivas. caracteristicas de calidad del producto y datos de medici ones de proceso. fODnacion) para un producto software. 0 e e e serVlClO software y e Proporcionar la historia de 10 sucedido durante el desan-ollo y mantenimiento para dar soporte a la gestion y mejora de procesos.'RA-MA CAPiTULO 7: ). instalacion. planificar y programar las actividades de aseguramiento de la cali dad para el proceso 0 producto. Asistir la planificacion logistica (replicacion. distJibucion. modificables. datos de usuatio. datos de gestion y datos de calidad. protegidos. completos. procedimientos y herramientas para llevar a cabo las actividades de aseguramiento de la cali dad y su adaptaci6n al proyecto. velificables.3. con-ectos y adecuados.4 se presenta el contenido del plan de asegurat11iento de calidad de software. Identificar. Realizar las actividades identificadas de aseguramiento de la calidad en consonancia con los planes. Aplicar los sistemas de gesti6n de cali dad organizacionales ai proyecto. Estos ultimos abarcan planes y procedimientos de calidad. seguros y privados. Identificar los recursos y las responsabilidades para la realizaci6n de las actividades de aseguramiento de la calidad. procedimientos y programaciones releYantes. Definir y controlar los procesos del ciclo de vida. Proporcionar evidencia de los procesos que se han seguido. metodologias. presentables (recuperables y visibles). datos de disefio. Establecer y garantizar la independencia de los responsables de llevar a cabo las actividades de aseguramiento de la calidad.

valorar los logros actuales y el progreso respecto a los planes y controlar la ejecuci6n del proyecto hasta su culminaci6n. Se dan guias especificas sobre el contenido de los planes de adquisici6n. descripciones de disefio de bases de datos. Estandares de calidad. que incIuyen los procesos de adquisici6n y suministro. Procesos empresariales. metodologias.5 se resumen las actividades que presenta este proceso). descripci6n de arquitectura software. infonnes. de mantenimiento. programaciones y responsabilidades para dirigir las actividades de aseguramiento de cali dad.4. Auditorias y Resoluci6n de Problemas. Ell Ell . Recursos. Actividades y tareas seleccionadas a partir de los procesos de soporte. Procesos de proyecto. en la tabla 7. co\ecci6n. servicios e implementaciones de los procesos del ciclo de vida clIInplen los objetivos de calidad de fa empresa)' logran la satisfaccion del cliente". peticiones. Validaci6n. etc. clasificaci6n y disposici6n de los registros de calidad. Procedimientos para la identificaci6n. PROCESOS DEL CICLO DE VIDA DE SISTEMAS De fonna amlloga a la nonna ISO 12207 para el software. Dentro de este apartado encontramos los procesos de planificaci6n de proyectos. ---? ---? ---? Tabla 7. en la nonna ISO 15288 se presentan los principales procesos del cicIo de vida de los sistemas agrupados en cuatro categorias: Ell Procesos de acuerdo. Contenido del plan para el aseguramiento de la calidad En el estandar se dan guias para el contenido de las descripciones. planes. gesti6n de recursos (para proporcionar recursos a los proyectos). gesti6n de los procesos del cicIo de vida de sistemas (cuyo objetivo es asegurar que se encuentran disponibles para ser utilizados por la organizaci6n procesos efectivos de cicIo de vida del sistema). que incIuyen: el proceso de gesti6n del entomo empresarial (cuyo objetivo es definir y mantener las polfticas y procedimientos necesarios para las actividades de la organizaci6n). gesti6n de la inversi6n (cuyo objetivo es iniciar y mantener suficientes y adecuados proyectos con el fin de conseguir los objetivos de la organizaci6n). que se utilizan para establecer y hacer evolucionar planes de proyecto. 3. tales como Verificaci6n. planes del proceso de desarrollo.ISO CAUDAD DE SISTEMAS IN"FORMATICOS ©RA-NL~ ---? ---? Infonnaci6n de un plan generico para el aseguramiento de la calidad del software. gesti6n de la calidad (la nonna establece que el prop6sito del proceso de gesti6n de cali dad es "asegurar que los prodllctos. procedimientos. registros. especificaciones. procedimientos y herramientas para llevar a cabo las tareas de aseguramiento de la calidad (0 las referencias correspondientes de la organizaci6n en su documentaci6n oficial. etc. Revisiones Conjuntas. peticiones de modificaci6n.

Institute of Electrical and Electronics EngineerslElectronic Industries Alliance. e e Este gmpo de estandares IEEE proporcionan la implementacion industrial de la nonna ISO/IEe 12207.1-1997.0-1996. Industry Implementation of International Standard ISOIIEC 12207: 1995. LECTURAS RECOMENDADAS e IEEEIEIA 12207. control de proyectos. 4. utilizacion. operacion. sefiala en el anexo B que las "etapas" (stages) se pueden utilizar para constmir marcos conceptuales en los que los procesos del cicio de vida del sistema se utilicen para modelar ciclos de vida. 01-Mar-1998. irnplernentacion. y retirada.Software Life Cycle Processes. transicion. Al igual que la nonna ISO 12207 tarnbien la 15288 prop one un proceso de adaptacion de estos procesos a las necesidades concretas de una organizacion. describiendo el proposito y las salidas de seis etapas: concepcion. desanollo. Standardfor Information Technology . -+ -+ -+ -+ -+ -+ Establecer politicas. gestion de riesgos.Software Life Cycle Processes . Institute of Electrical and Electronics EngineerslElectronic Industries Alliance. Actividades del Proceso de Gestion de la Calidad (ISO.Software Life Cycle Processes .f:RA-lvL\ CAPiTULO 7: lvlODELOS DE PROCESO DE CIClO DE VIDA 151 evaluacion de proyectos.2-1997. validacion. Implementation of ISOIIEC 12207:1995 Standard for Iriformation Technology . verificacion. Industl). estandares y procedimientos de gesti6n de la calidad Establecer objetivos de gesti6n de la calidad de la organizaci6n basados en la estrategia empresarial para la satisfacci6n del cliente Definir las responsabilidades y autoridades para implementar la gesti6n de la cali dad Evaluar e informar sobre la satisfacci6n del cliente Llevar a cabo revisiones peri6dicas de planes de calidad de proyectos Monitorizar el estado de las mejorar de calidad de los productos y servicios Tabla 7. 01-May-1997. disefio arquitectonico.5. integracion. soporte. Standardfor Information Technology . rnantenirniento y retirada. IEEEIEIA 12207. torna de decisiones. que incluyen el proceso de definicion de requisitos de las partes irnplicadas en el producto. gestion de configuracion y gestion de infonnacion. 01-Apr-1998 IEEEIEIA 12207.Implementation Considerations. 2003) e Procesos tecnicos. Institute of Electrical and Electr'onics EngineerslElectr'onic Industries Alliance. El docurnento 12207.Life Cycle Data. Adernas. analisis de requisitos.0-1996 (el estandar base) consiste . produccion.

incose. Establezca el tipo de participacion de los diferentes "stakeholders" (jefes de proyecto.comJ Sitio web con infonnacion actualizada y completa sobre la norma ISO 12207 y sus estandares y propuestas relacionadas.l2207. analistas.2.. EJERCICIOS 1. http://w\vw. ISO 12207 e IEEE 12207. Especifique cuales de los procesos de cicIo de vida software que aparecen en la nonna ISO 12207 son mas aplicables para pequefias y medianas empresas de desarTollo de software. http://\v\vw. con algunas influencias adicionales. 4. Los otros dos documentos contienen recomendaciones adicionales delivadas de MIL-STD-498 y de los estandares de ingenieria de IEEE. etc . Lleve a cabo un estudio comparativo entre los estandares IEEE 1074. IEEE 12207. 3.ieee.on!l Sitio \veb que proporciona infonnacion adicional sobre los procesos del cicIo de vida de sistemas.0.15 J CAUDAD DE SISTEMAS INFO~vlATICOS © RA-1vL-\ basicamente en el texto del estandar ISO 12207 junto con anexos explicativos. ) en cada uno de los procesos de cicIo d~ vida.onz Sitio web de la organizacion IEEE. 5. e e 6. .1. 2. SITIOS WEB RECOMENDADOS e http://\v\vw. IEEE 12207. responsables de cali dad. Analice las diferencias entre el proceso de soporte de la ISO 12207 "Aseguramiento de la Cali dad" y la n0l111a ISO 90003 (vease capitulo 8). programadores.

CAPITULO 8 EVALUACION Y MEJORA DE PROCESOS * "Sin 1111 continllo progreso y crecimiento. Ante esta situaci6n. integracion. con el proceso. La evaluaci6n y mejora de los procesos software pel1niten juzgar y decidir sobre la calidad de los procesos que estan sujetos a analisis. 0 bien para mejorar los procesos. es decir. los modelos de evaluaci6n y mejora de procesos y su estandarizaci6n han adquirido un papel muy impOltan!e para la identificaci6n. medici on y optimizacion de las buenas practicas existentes para el desarrollo y mantenimiento del software. Como resultado de los esfuerzos de la comunidad cientifica. con el objetivo de poder establecer una estrategia para su mejora. tal y como se ha comentado en el capitulo 6. se han propuesto toda una serie de modelos y estandares para promover la aplicaci6n de este proceso en las organizaciones. logro y exito no tienen ningzln signijicado " Benjamin Franklin 1. palabras tales como mejora. La evaluaci6n de los procesos software se hace principalmente por dos motivos: bien para detel1ninar la capacidad de ill1 proveedor de cara a su contrataci6n. Todo ella ha motivado en gran medida que las organizaciones dedicadas al desarrollo y mantenimiento del software se preocupen cada vez mas de la mejora de sus procesos. dado que. la cali dad final del producto software esta muy directamente relacionada con la fOlma en que se desarrolla y mantiene. La aparicion en el mercado de estas propuestas esta ofreciendo a las empresas y departamentos de desarrollo infol1natico la posibilidad de adaptarse a una nueva fOlma de trabajo caracterizada principalmente por buscar la satisfaccion de los . PANORAMICA GENERAL Hoy en dia la calidad del software no puede garantizarse imicamente centrando los programas de cali dad en el producto.

estandares como el EIA Interim Standard (IS) 632 para procesos de ingenielia de sistemas. que han sido resumidos en el capitulo anterior. Sin embargo.org/guagmire) I!l 0 el ISO 15288 para la ingenielia de sistemas. como I!l . en los ultimos alios estamos asistiendo a una gran proliferaci6n propuestas para la evaluaci6n y mejora de los procesos.. 0 los estandares militares como el MIL-STD-498 (desanollo y documentaci6n de software).154 CAUDAD DE SISTE.. como el ISOIlEe 12207 I!l Estandares y guias.1. En SelTad y Lake (1998) destaca la gran cantidad de marcos que pueden convertir este campo en "Zlna cirinaga fa qZle se empalltallen los esfiterzos de mejora de procesos si ZIlla organizaci6n 110 cllidadosa". que establecen 10 que deb eli a hacerse en una situaci6n contractual.VV\S INFORMA TICOS © clientes y disponer de una mejor visibilidad y control de la calidad de los procesos y de los productos finales.. La cienaga de los estandares y modelos de referencia de la madurez. ) ~~ ( MOPROSOFT ) ( ISO 15939 ) ~ (SsEl ~ • ( Baldrige) (IeEel ~ ---l> Sus:i:Uye a . evaluaci6n y mejora de procesos (adaptado. Modelos de procesos del cicIo de vida.1): de se en es ( People CMM ~ ~ ~ ( Bootstrap) ( MPSB.. Para ello conviene distinguir (vease figura 8. como las nonnas ISO. Modelos de rnejora y rnetodos de valoracion interna. que establecen un camino a seguir describiendo las caractelisticas de los buenos procesos.de http://\Hyw.software. UsaReferen:::ia Figura 8. Basado en < ISOIIEC 15288 ) .

umassd. 1996) SEI SE-GvIM Capability Maturity Model for Systems Engineering (SEI.sei.edulcmmi! h!!Q:i.pdf http://\\\\w. evaluaci6n y mejora de procesos software propuestos en la literatura.sei. 2000a.\ \\" .002. 1995) SEI P-CMM People Capability Maturity Model (Curtis etal. etc).A.softex.cmu. 1998) ISO/IEC 15504 (ISO.uk!mil 498/ w\v\v.1 se muestra un resumen de modelos representativos de referencia para la madurez..1 %20DocumentoBase.sei. 1994) Tickit (Tickit Project Office. (Sheard y Lake.C RA. 1992) Trillium (Trillium Team. implementa y mejora un sistema de gesti6n de la calidad.sei.tr. que promueve la adopci6n de un enfoque basado en procesos cuando se desalTolla.html h!!Q://\vww. MODELO BOOTSTRAP (Kuvaja et al. De entre todas estas iniciativas cabe destacar la influencia que tuYO CMM en la mejora del software.\\"\\·2..cmu.lania. etc.ssc-cmm.ie i essiscoQe i sm5/aQQroaclv boot-2.html httQ:ii\\\\w. y.sei.edu!Qublications'document s!96..\\\\\\". \\\\\v. 2004a-e) ISO/1EC 90003 (ISO/IEe.cmu. 1997) SEI Personal Software Process (PSP) (Humphrey.demon. 2004f) MIL STD-498 MOPROSOFT (Oktaba et al.cse.html h!!Q:!/w\\w. 2001) SEI IDEAL Model (Gremba y Myers. En la tabla 8.edu/tsQiQsQ.org h!!Q:!1\\".millcrosstalklI997/04/de veloQment.org h!!Q:/I\v\\\\".mxJbibliotecaimanualesimoprosoft! V%20 1. 1995) {JRL . 2004) SEI GvIMI.-MA CAPiTULO 8: EYAlUACION Y MEJORA DE PROCESOS 155 CMM/CMMI y sus modelos asociados (PSP.stsc. as! como el estandar ISO 15504 y la reciente nonna ISO 90003. .html I I Tabla 8.cmu.cmu.hill. 1997) Systems Security Engineering Capability Maturity Model (SSE-CMMl (Departtnent of Defense U.br/ httQ://\\ \Vw .html http://\\\\w.cmu.edu/Qublications!document SiO l. 1994) EIA 632.iso..httnl h!!Q:.edu/tsQ!tsQ.edwcmm-Qi http://\\\\w.reQorts/O I hbOO I. 1999) SEI SW-CMM Capability l'vlaturity Model SM for Software (SEI. Trillium para telecol11unicaciones.\\\\\\".edulideallideal.1.org http:!.sei.reQorts!96.sei. en la aChtalidad.html http://v\\\\\".af.cmu.edulcmnvse-cmm. 2003) Mps BPR (Weber y Rocha..cmu.sei.Qogner.asQ http://\\\\w. su sucesor CMMI.hunl httD:/!\\\\\\". I h!!Q:/!www.2002) SCAtvIPI (Standard CMrvfI Appraisal Method for Process Improvement) (SEL 200 I) SEI Software Capability Evaluation (SCE) (Bymes y Philips.html htm:!1\\\\w. TSP.iso.dcu. 1994) (April Y Coallier.org/ htt12: !v. 1995) SEI Team Software Process (TSP) (Humphrey. Resumen de los Modelos de Madurez y Metodos de Evaluaci6n y Mejora del Sofnvare (ultimo acceso de enlaces web en agosto de 2006) .sei.Capability Maturity Model Integration (SEI.co.edulcmnVcmm..eia.org http://\v\\\\"... Processes for Engineering a System. 2000b) Software Development Capability Evaluation (SDCE) (AFMC.edulswI1i1BeIICanadaitrilli um-htmlltrillium.tickit.S.cmu. Bootstrap.

Tuffley et at. 2002. 2000. arquitecturas (Burke. 2005.. datos (Mullins. 2000. 2002). como sefiala en su reciente estudio Mekelburg (2005). Calvo-Manzano. 2005). Identifica todos los aspectos que deberian ser tratados y es independiente de . 2000). Tambien merecen especial atenci6n las propuestas de modelos de evaluaci6n y mejora adaptados a pequefias y median as empresas. M. desalTollo. senicios e-Government (Windley. Tambien se resumen dos propuestas de modelos iberoamericanos de madurez de procesos. seguridad (Department of Defense U. Gartner. de los paises en los que se proponen. 2004. ingenieria de requisitos (Somerville y Ransom. Software Capability Evaluation (SCE) 0 el SDCE de las Fuerzas Annadas de EEUU. que especifican el examen de los procesos de una organizaci6n por alguien extemo (segunda 0 tercera parte) con el fin de comparar las fortalezas y debilidades de los contratistas para poder minimizar el riesgo de la compra.. LA NORMA ISO 90003 La nonna ISOIIEC 90003 (ISO.. Batista y Figueiredo. 2004. DoC. 2003). olltsourcing (Raffoul. Siguiendo esta "filosofia" tambien se han propuesto otros muchos modelos de madurez especificos: para pruebas (Olsen y Staal. gestion de proyectos (Ibbs y Hwak. usabilidad (Earthy. PMI. que han sido tratados en el capitulo 3. en su mayoria Pymes. European Quality Award.. 2002: Luftman. 2. operaci6n y mantenimiento de software y sus servicios relacionados. 2001.. 2000b) a la adquisici6n. 1999). tal y como atestiguan divers as investigaciones (vease. 1997: Bevans. 2003). 2000). Para este tipo de empresas el problema de muchos de los modelos tradicionales es que. desarrollo distribuido (Ramasubbu et al. por ejemplo. 2002). las organizaciones. mantenimiento (April et al. por ejemplo. 2003: Schekkennan. Premios a la calidad. 2004£) proporciona la guia necesaria en las organizaciones para la aplicacion de la ISO 9001 (ISO. 2000: Hareton y Terence.. 1998). 2005). 1994). al haber sido concebidos para grandes empresas.mrd. Crawford. 2002. etc.S. mas que procesos de fonna independiente como. 2004). OMB.. 2005). inc1uso las gI'andes. suministro. su adaptaci6n a las Pymes es dificil y costosa. 2004. McBride et al. 2002). En este capitulo se presentan de fonna resumida una serie de modelos representativos propuestos en la bibliografia para la mejora de calidad en las organizaciones y sus metodos de evaluaci6n y mejora asociados. reutilizaci6n (Topaloglu. adaptados a las especiales caracteristicas de las empresas. 2003. 2002): open-source (Widdows y Duijnhomver. proveedores de servicios de tecnologias de la informacion (Niessink et al. 1998. NASCIO.A. Ademas. como el Malcolm Baldrige Nacional Quality A.156 CAUDAD DE SISTEMAS IN"FOR.vlATICOS o o Metodos de seleccion de contratistas. Por ejemplo. tienden a adoptar gIupos de procesos relacionados como un cOl~unto. en elmodelo CMMI. Krause. Van del' Raadt et al.

implementar y mantener un sistema de gestion de la calidad software y mejorar continuamente su eficacia de acuerdo con los siguientes requisitos generales: ® Identificar los procesos necesarios para el sistema de gestion de la calidad y su aplicaci6n a traves de la organizaci6n. La nonna ISO 9001.CAPiTULO 8: EVALUACION Y MEJORA DE PROCESOS 157 la tecnologia. Implementar las acciones necesarias para a1canzar planificados y la mejora continua de estos procesos. Determinar la secuencia e interaccion de estos procesos. El estandar ISO 90003 surge debido a que la gestion de la calidad que prop one ISO 9001 aun siendo un buen marco de partida. por ejemplo. especifica los requisitos para un sistema de gestion de la calidad cuando una organizacion necesita demostrar su capacidad de proporcionar de f0l111a coherente productos que satisfagan los requisitos del cliente y aspira a aumentar su satisfaccion a traves de la aplicacion eficaz del sistema. Determinar los criterios y metodos necesados para asegurarse de que tanto la operaci6n como el control de estos procesos sean eficaces. que deberia basarse en un modelo de cicIo de vida. La organizacion deberia tambien detinir la secuencia e interacci6n de los procesos en: los modelos de ciclos de vida del desanollo de software. En este punto la organizaci6n deberia identificar tambien los procesos de desanollo. Las directrices proporcionadas en esta nonna intemacional no estan enfocadas a ser utilizadas como criterios de evaluacion en la certificaci6nJregistTO del sistema de gesti6n de la calidad. Asegurarse de la disponihilidad de recursos e informacion necesarios para apoyar la operaci6n y el seguimiento de es'tos procesos. la planificaci6n de la calidad y el desan'ollo. modelos de ciclo de vida. los resultados ® ® ® ® ® . documentar. la medicion y el analisis de estos procesos. Realizar el seguimiento. procesos de desanollo y estmcturas organizacionales. incluyendo los procesos para la mejora continua del sistema. es excesivamente general y se queda corta para abordar proyectos de disefio e implantacion de sistemas de gestion de la calidad mas especializados. incremental y en espiral (evolutivos). y el aseguramiento de la confOlmidad con los requisitos y de acuerdo a las reglamentaciones existentes. Seglll1 la nOlma ISO 90003 la organizaci6n debe establecer. operaci6n y mantenimiento de software. modelos en cascada.

el Instituto de Ingenieria del Software (SEI. e A la hora de establecer la madmez de los procesos de una organizaci6n en CMM se establecen cinco niveles de capacidad. Es un modelo con la finalidad de: e Evaluar la madurez de los procesos de desanollo de software dentro de una organizaci6n.2. Proponer un plan de mejora de los procesos de desalTollo de software de acuerdo a una serie de niveles. medir y controlar. Cada area clave de proceso 0 KPA (Ke. que a su vez se organizan en una selie de caracteristicas comunes (COllllllon features). Ke./hmre Engineering institute) de la Universidad de Camegie Mellon se ha centrado en proporcionar la base necesaria para mejorar el desaITollo del software considerando a las tareas de desanollo del software como una selie de procesos que se pueden definir. EI modelo de referencia CMM establece una serie de areas clave (hasta un total de dieciocho) agrupadas en los distintos niveles de madurez.i58 CAUDAD DE SISTEMAS INFORMATICOS 3. So.'· Process Area) se desclibe en funci6n de una serie de practicas clave (KPs.1. .O DE MAQUREZ DE LA CAPACIDAD (CMM) Y LOS METODOS MAS REPRESENTATIVOS DE EVAlUACION Y MEJORA ASOCIADOS 3. Las caracteristicas de cada nivel de madmez se resumen en la tabla 8.. 1995) es el modelo propuesto por el SEI como referencia para detenninar la capacidad de los procesos software de una organizaci6n. CMM Desde la decada de los alios 80. CMM (SEI. Para que una organizaci6n pueda estar en un detel111inado nivel de madurez debe satisfacer los cliterios de evaluaci6n asociados con las areas clave que pertenecen a ese nivel y a los niveles anteriores. que definen una esc ala ordinal para representar la evoluci6n del proceso software desde un nivel inicial ca6tico (procesos ad hoc cuyos resultados no son predecibles) hasta un estado de mejora continua (maduro). CMM proporciona a las organizaciones de software el modelo de referencia necesaIio como sopolie para el control de sus procesos de desanollo y mantenimiento y para facilitar su evoluci6n hacia una cultma de la Ingenieria del Software y de excelencia en la gesti6n.'· Practices). Como resultado se han obtenido modelos de referencia de la capacidad de los procesos y modelos de evaluaci6n de dicha capacidad. EL MODEJ. Las relaciones entre estos conceptos del modelo CMM se ilustran en la figura 8.2.

La produeti\'idad y la ealidad se miden y registran para cada proyecto de la organizacion. Los procesos son mediblcs 0 euantiticables. La planiticacion se basa en proyeetos similares. EI proceso de software cs eambiantc e irregular. • • • • EI rendimiento depende de la capacidad individual de los miel11bros del grupo. estandarizados. Se estableeen programas de fonnaci6n del personal de desarrollo y mantenimiento. Los grupos abandonan f<ieilmente los planes y se centran en la codificacion y pruebas. documentados e institucionalizados. Los procesos se mejoran continuamente. Productividad y calidad media. Riesgo medio. Riesgo m. Riesgo minimo. I:\IClAL Los planes. • Productividad y calidad alta. Niveles de Capacidad de CMM . Tabla 8. se crea una base euantitativa para la evaluaeion y estimacion en proyeetos futuros. Productividad y calidad escasa. Se incorporan nuevas tecnologias y metodos para mejorar los procesos. Riesgo alto. estimaciones y calidad son il11predeeibles.iximo REPETIBLE Productividad y calidad baja. mejordmiento y difusion del proceso de Ingenieria de Software. Los procesos de ingenieria y gestion son estables y se integran en uno solo. Los proeesos de software son estables y repetibles. Riesgo nulo. La organizacion estableee politic as de gerencia de proyectos v procesos. Los procesos son de!inidos. GESTlO:\ADO Se fijan metas cuantitativas de la ealidad del software. OPTl:\lIZADO La organizacion busca lograr el ni\'e1l11aximo de eapaeidad. • La organizacion mantiene un grupo dedicado a la definicion. funciones y responsabilidades.RA-MA CAPiTuLO 8: EVALL'ACION Y N!EJORA. EI proceso se enmarca en un sistema de gerencia de proyeetos basado en experieneias pasadas. • Mediante el uso de metricas de software. • • • Existen estandares detinidos y exigidos. Productividad y calidad total. DUl:\IDO Existe un entendimiento comun de los procesos. DE PROCESOS 159 NIYEL CARACTERiSTIC\S RESULTADOS • • Auseneia de gestion de proyeetos.2.

TICOS ©RA-MA » Areas Clave del Proceso (KPAs) Grupo de Acthidades que satisfacen un conjllnto de objetivos Pn3cticas Clave Actividades e infraestructura que contribuyen en su mayoria a la implementaci6n de un al'ea clave de proceso Figura 8. Q . Las metas se us an para cOl11probar si efectivamente se implementa adecuadamente un area clave de proceso detenninada. Cada nivel de madurez. Estructura de CMM como modelo de referencia para la evaluacion Como se puede observar en la figura 8. Ejemplos de areas clave son la gesti6n de configuraci6n y planificaci6n del proyecto del segundo nivel de madurez.2. Mediante la evaluaci6n de las caracteristicas comunes se puede averiguar si la il11plel11entaci6n de un area clave de proceso se ha realizado de fOlma que sea efectiva. que descliben de fonna general que se debe hacer para dar soporte a un area clave de proceso. Cada area clave de proceso se organiza en una selie de caracteristicas comunes que representan los atIibutos que debe tener el proceso. CMM proporciona la estructura necesaria para poder aplicar de fonna sistematica un proceso de evaluaci6n al estar claramente definido cada nivel de madurez en base a: Q Areas clave del proceso. excepto el nivel inicial se descompone en diterentes areas clave del proceso. 0 la prevenci6n de defectos y gesti6n de cambio del proceso. Cada area clave contiene un conjunto de objetivos 0 metas.2. cOlTespondientes al nivel quinto de madurez. repetible y duradera. Caracteristicas Comunes.S r"iFORlvlA.160 CAUDAD DE SISTE!vlA.

estos no se incluyen en el alcance de la evaluacion proporcionada por SCE. Por este motivo y con el fin de proporcionar el medio necesario para realizar evaluaciones basadas en CMM y para poder comparar los resultados de evaluacion se creo el marco de trabajo CAF (Ci"\. y en particular. DE PROCESOS 161 (i) Pnicticas Clave. centrados en aspectos de gestion de proyectos como su planificaci6n y seguimiento: y los procesos de ingenieria. SeE (Software Capability Evaluation) SCE (Bymes y Philips. revisiones por pares.3.GRA. Para poder conocer el nivel de madurez de una organizacion es necesario realizar la evaluacion de sus procesos software. Aunque en el modelo CMM se consideran los procesos de produccion tecnica. SCE usa el modelo de madurez de capacidad (CMM) como modelo de referencia.fM Appraisal Framework). Por otra parte.2. tal y como se puede observar en la figura 8. ingenieria del producto. Las principales areas de aplicacion de SCE son: la seleccion del suministrador. .-MA CAPiTULO 8: EVALUACIOl\ Y YIEJORA. !levar a cabo la evaluacion e infol1nar sobre los resultados de la evaluacion. A continuacion se resumen todos ellos. se centra en conjuntos de procesos (0 10 que en CMM se considera como areas clave de procesos) que se pueden agrupar en tres categorias: procesos organizacionales. 3. Los dos principales metodos de evaluaci6n basados en CMM son SCE (Sofhrare Capability Evaluation) y CBA-IPI (CMM-Based Appraisal for Internal Process Jmpro1·ement). que identifica los requisitos y caracteristicas necesarias en un metodo de evaluacion basado en CMM para mejorar la consistencia y la fiabilidad de los diferentes metodos de evaluacion y sus resultados. bas ado en CMM. 1996) es el metodo desarTollado para evaluar los procesos software de una organizacion con el objetivo de detel1ninar su capacidad. 10 constituye elmodelo IDEAL. etc. el marco de mejora de procesos del SEI. la monitorizacion del proceso y la evaluacion interna. Constituyen los ejemplos de que se debe hacer para satisfacer los objetivos de un area clave de proceso sin entrar en detalle de como hacerlo. La capacidad de un proceso se refiere al rango de los resultados esperados que se pueden obtener aillevar a cabo un proceso detel1ninado. que contienen un conjunto de areas clave que se centran sobre la gestion organizacional de los procesos software: los procesos de gestion de proyectos. Las principales caracteristicas y responsables de estas actividades se resumen en la tabla 8. que incluyen aspectos de desarTollo del producto como la gestion de requisitos.3. El proceso de evaluacion definido en SCE esta compuesto basicamente por las siguientes actividades: planificar y preparar la evaluacion. El objetivo de la evaluacion de SCE es el proceso software.

iAS IMORMATICOS ·tJ RA-MA Ejemplos .3.-\LIDAD DE SISTE0.Gestion de Requisitos Operaciones de Desarrollo Ejemplos . el equipo de evaluaci6n SCE lleva a cabo una planificaci6n en la que basicamente identifica las areas de proceso a evaluar para realizar un proceso de evaluaci6n basado en rigurosas revisiones de documentaci6n y entrevistas en el que. 3.3. con el fin de establecer y dar pliOlidad a planes de mejora software y para facilitar que la organizaci6n se centre en la mejora de los aspectos que Ie resulten mas beneficiosos en funci6n de su nivel de madurez y sus objetivos de negocio.Gestion de la Configuraci6n .Aseguramiento de la CaUdad Soporte a Ia Construcci6n Operacional del Producto Ejemplos . El metodo consiste en la evaluaci6n de la capacidad del proceso software de una organizaci6n a traves de un grupo de profesionales adecuadamente entrenados que trabajan como un equipo para aveliguar y valorar las distintas areas clave del proceso de CMM que se encuentran en el alcance de la evaluaci6n. se establecen las debilidades y fortalezas de la evaluaci6n para finalmente realizar los infol1nes adecuados en funci6n de los resultados obtenidos. CBA·IPI (CMM-Based Appraisal for Internal Process Improvement) CBA-IPI (Dunaway y Masters.Revisiones par pares -Ingenieria del Producto .Metodologias de Diseno -C6digo Soporte para Procesos de Toma de Decisiones y Comunicaci6n t Soporte para Procesos de Comunicaci6n y Tecnicos t t Procesos Tecnicos Evaluado por SeE No Evaluado por seE Figura 8. Los datos necesarios para la .3. 2001) es un metodo que facilita a una organizaci6n conocer la capacidad de sus procesos software mediante la identificaci6n de las fortalezas y debilidades y la relaci6n de estas fortalezas y debilidades en base al modelo CMM.162 C.Seguimiento del Proyecto . mediante un proceso de analisis.Planificaci6n del Proyecto .Metodo!ogias de Amllisis de Requisitos .Entornos de ingenieria . Procesos Evaluados por SeE Como se puede apreciar en la tabla 8.

EI Equipo SCE: • REALIZAR LA EVALLACID:-'- Inwstiga cada tema planitlcado en el sitio de desarrollo" Conduce actividades de recopilacion de datos mediante la rcalizacion de cntrcvistas. EI Equipo SCE: • !:-'-FORi\lAR LOS RES(JLTADOS DE LA EVALLAClD:-'- Presenta y entrega los resultados al patrocinador y a la organizacion. habilitar y animar a una organizacion a la mejora del proceso software.\:" RA-M. DE PROCESOS 163 valoracion se obtienen a par1ir de datos obtenidos de cuestionarios.ALV. debiles y las aeti\'idades de mejora" Resultado: Datos del Proceso consolidados y se deteffilinan los resultados.quedas. Prepara los temas especitlcos para la c\'aluacion.3. Fases y Actividades de la evaluacion SeE Los dos plincipales objetivos de CBA IPI son: It Dar sop0l1e. Consolida la infoffilacion recogida y valida las observacioncs. Produce un infoffile final para el patrocinador. EI Equipo SCE: • • Selecciona los proyectos a evaluar. revisiones de documento.0 ACTIVlDADES Y RESULTADOS La Organizacion Patrocinadora: • • Deteffilina los atributos deseados del producto Detennina la eapacidad del proceso mas apropiada para alcanzar los objetivos de negocio (ia capacidad objeti\"o del proceso) • Sclecciona y lonna al equipo de la evaluacion (SCE) Resultado: se definen los objeti\"os y los requisitos de la evuluacion EI Equipo SCE: PL~"IFICAR y REALIZAR LA PREPARACID:-'PARA LA EV. presentaciones y ent:revistas con gestores. • Realiza recomendaciones para el uso de los resultados. Tabla 8. Resultado: se detlne el alcance de la evaluacion y se complctan las preparaciones a alto niwl para c\"aluar a la organizacion de desarrollo. jefes de proyecto y agentes software.KID:-'- Identifica las areas en las que la organizacion careee de experiencia (indicando un riesgo potencial) • Deline el alcance de la cvaluacion. • Analizar los datos Resultado: se completan las preparaciones detalladas para cvaluar un sitio de desarrollo. FASE seE v 3. .-\ CAPiTULO 8: EVAWACIOl\ Y :VIEJORA. • Deteffilina los puntos fuertcs. revisiones de documentos y presentaciones. Resultado: sc deterrninan y doeumentan los resultados de la e\'aluacion Datos del Proceso consolidados y se deterrninan las biJ.

mientras que SCE suele orientarse mas a la seleccion de suministradores.4.1 para proporcionarle un a1cance mas amplio.4 se l11uestra la estruchlra de este modelo. En la tabla 8. Ii> Proporcionar una vision exacta de las fortalezas y debilidades de los procesos software aChlales de la organizacion. 3. 1996: Gremba y l'vlyers. el alcance de una evaluacion es relativo a las necesidades del patrocinador. usando CMM como modelo de referencia y para identificar las areas clave del proceso que es necesario mejorar. ya sea para la mejora de los procesos de la propia organizacion evaluadora (CBA-IPI) 0 para mejora en la organizacion evaluada (SCE). se considera que CBA IPI es un metodo para la valoracion (assessment) de la capacidad para mejora de procesos. conduccion y generacion de infol1nes). Este modelo £lIe concebido originalmente como un cicIo de vida para la mejora de procesos software basado en el modelo CMM y posterionnente el l110delo IDEAL £lIe revisado en la version 1. La diferencia fundamental entre la valoracion y la evaluacion es que la primera consiste en un proceso que una organizacion hace para sl misma. que es la persona 0 grupo de personas responsables de decidir si se hace la evaluacion de la organizacion con la que se pretende hacer negocios.TICOS -f' RA. IDEAL EI marco de mejora de procesos del SEr 10 constihlye el modelo IDEAL (McFee ley.164 CAUDAD DE SISTEMAS IKFOfu'vLA. En realidad. En contraste. 1997) en el que se define un marco de ciclo de vida para la mejora de procesos.-:VL-I. mientras la segunda es un proceso en el que un grupo extemo llega a una organizacion y examina la capacidad de sus procesos para tomar decisiones respecto de posibles negocios 0 tratos £llhlroS. . Las actividades y a1cance del proceso de evaluacion del metodo CBA-IPI son basicamente los mismos que en el metodo SCE (planificacion. CBA-IPI es muy similar a SCE con la diferencia fundamental de que CBA IPI es una evaluacion centrada en la mejora de procesos. aunque tambien se puede usar para la evaluacion intema de procesos. De acuerdo a la tel111inologia usada en los modelos de evaluacion basados en CMM. IDEAL constihlye un enfoque usable y entendible para la mejora continua estableciendo los pasos necesarios que se deb en seguir para llevar a cabo un programa de mejora y proporcionando un enfoque ingenieril y disciplinado.4 se representan las diferencias entre un proceso de valoracion y un proceso de evaluacion. Los resultados de la evaluacion de los metodos comentados anteri0l111ente se pueden utilizar en el contexto de la mejora de procesos software. EI a1cance de una \-aloracion es relativo a las necesidades de la organizacion y objetivos de negocio del patrocinadoL que es usualmente el gestor senior de la organizacion evaluada. En la figura 8. mientras que SCE es un metodo de evaluacion (emillation) con el fin de seleccionar suministradores 0 para medir el progreso de las mejoras.

CAPiTULO 8: EVAlUACION Y MEJOR:\ DE PROCESOS l65 I I.4.4. El modelo IDEAL (McFeeley.lejora Iniciacion Diagnostico Figura 8.4. se decide la aprobacion del . gestion de riesgos y medici ones de la mejora intema Selecci6n y monitorizaci6n de suministradores Los desarrolladores 10 usan para medir el progreso de la mejora Los resultados se hacen saber al patrocinador Los miembros de la organizacion podrian no estar en un equipo Tabla 8. Los miembros de la organizacion deben [onnar un equipo Se aplica a necesidades especificas del Se aplica a la organizacion. 1996) Como se puede observar en la figura 8. COi\It1NICACION DE REsULtADOS EQL1PO Se usan en la organizaci6n evaluada I ALCANCE USODELOS RESULTADOS I I Colaborativo. los roles y responsabilidades que hay que asul11ir y se asignan los recursos necesarios. no a patrocinador proyectos individuales 0 contratos I Como entradas al plan de mejora Como entrada a la seleccion de suministrador. OBJETIVO V ALOR-\CION (ASSESSMEi\"T) Mejora de Procesos EVALUAtl(~N (E\'ALUATION) . cada una de las cuales esta fom1ada pOl' una serie de actividades: til Iniciacion. e1l110delo IDEAL esta cOl11puesto por cinco fases. Diferencias entre Valoracion y Evaluacion Aprendizaje Estimu!o .. que constituye el punto de paItida. en el cual se establece la infi'aestructura. Adermls. En esta fase se elabora el plan de mejora de procesos que proporciona la guia necesaria para completar el inicio y llevar a cabo las fases de diagnostico y establecimiento. para fa f.

Estos objetivos son refinados en la fase posterior de establecil11iento. durante la cual se priorizan los aspectos que la organizacion ha decidido l11ejorar. en la que se lleva a cabo el trabajo preliminar necesaJio para realizar las fases posteliores. En esta fase se inicia el plan de accion de la mejora de acuerdo con la vision de la organizacion. se desanollan y ejecutan lcs planes necesarios para su implantacion. se establecen dos cOl11ponentes fundal11entales: un gmpo directivo de la gestion (Management Steering Group. se establecen los recursos necesarios y se establecen los objetivos generales de la l11ejora a partir de las necesidades de negocio de la organizacion. Tambien durante esta fase se crean plantillas de acciones tactic as que los gl1lpOS de trabajo tecnico deben cOl11pletar y llevar a cabo. Durante la fase de inicio tal11bien se realizan planes para cOl11unicar el cOl11ienzo de la iniciativa de mejora y se sugiere la necesidad de realizar evaluaciones para detenninar la preparacion de la organizacion a la hora de llevar a cabo una iniciativa de mejora de procesos. aspectos clave a los que se enfrenta la organizacion y los objetivos a largo plazo. en la que se crean y se llevan a cabo las acciones destinadas a l11ejorar las areas identificadas en las fases previas. Actuacion. MSG) y un gmpo de procesos de ingenieria del software (sofhmre engineering process group. Respecto a la infraestmctura. El plan de accion desaJTollado debe guiar las actividades de mejora de acuerdo a los aspectos detectados para la l11ejora ordenados seglll1 su priOlidad y segtll1 las recol11endaciones de la fase de dia·gnostico. EI EI .166 CAUDAD DE SISTEMAS INrORMATICOS programa de l11ejora. Se realizan actividades de valoracion para establecer una linea base del estado actual de la organizacion. Una vez completada exitosamente la pl1leba de nuevos procesos y tras detenninar su adecuacion para ser adoptados en la organizacion. Se desauollan planes para ejecutar las acciones de l11ejora y para evaluar 0 probar los procesos nueyos 0 mejorados. EI Diagnostico. el plan de negocio estrategico. SEPG). Establecimiento. se desanollan las estrategias necesaJias para obtener las soluciones de mejora y se cOl11pleta el bon'ador del plan de mejora definido en las fases anteliores. IFVG). entregandose sus resultados y recomendaciones en las acciones del plan de l11ejora. Ello conlleva adel11as la definicion de las l11ehicas necesmias para el conh'ol del progreso y se preparan los recursos y se proporciona la fonnacion necesalia a los gl1lpOS de trabajo tecnico (Technical 'Working Groups. las lecciones aprendidas de esfuerzos de l11ejora realizados en el pasado. En esta fase tal11bien se desanollan objetivos l11edibles a partir de los objetivos generales fijados en la fase de inicio y que son incluidos en el plan de l11ejora.

. el enfoque y la medicion cuantitativa del proceso.control del proceso a nivel individual. la prevencion de defectos. ayudando a crear personal capacitado y disciplinado en su trabajo. etc. Una vez alcanzada esta fase. las revisiones e inspecciones. gestionando la calidad del producto y aplicando la realimentacion obtenida para mejorar sus procesos de trabajo individuales.) y los metodos empleados por los TWG en sus actividades de desanollo de la solucion..!EJORA.5. mientras que CMM se centra en mejorar la capacidad de la organizacion. es necesario implantar buenas pnicticas en el desanollo software. etc.CAPITULO 8: EVALUACION Y . DE PROCESOS 167 & Aprendizaje. Una respuesta adecuada a cada una de estas preguntas es fundamental para plantear el siguiente ciclo delmodelo IDEAL. como por ejemplo sobre el rendimiento de la infraestmctura (equipos de trabajo MSG. Estos artefactos son afiadidos a la base de datos del proceso. Al igual que en CMM. Con tal fin se desanollo el metodo PSP (Humphrey. PSP se basa sobre los principios de mejora del proceso. 3. PSP se centra en la mejora de los ingenieros software aplicando la gestion y. midiendo. los metodos y la infraestmctura utilizada en el programa de mejora. se han desanollado las soluciones. incorporando de fonna efectiva. Con PSP los ingenieros desanollan software usando un enfoque disciplinado y estmcturado. 10 que pennite su coneccion y ajuste de cara a thturas mejoras. TWG. realizando un seguimiento de su trabajo. eficaz y a bajo costa aspectos tales como la planificacion y seguimiento de proyectos. se han aprendido importantes lecciones del proceso y se han tomado mediciones sobre el rendimiento y la consecucion de los objetivos marcados. 1997). el proceso de ingenieria del producto. la evaluacion de calidad. SEPG. sin embargo. PSP (Personal Software Process) En el contexto del modelo CMM y a la hora de facilitar la aplicacion de los procesos de evaluacion y mejora en una organizacion. siguiendo un proceso definido y planificando. La infonnacion reunida pennite realizar una evaluacion sobre la estrategia. Entre los beneficios que PSP ofrece a los mgemeros software destacan los siguientes: . Esta plincipalmente bas ado en CMM y pennite implementar las practicas de ingenieria del software descritas en dicho modelo a nivel individual. que constituye una fuente de infonnacion muy relevante para el personal implicado en la proxima iteracion por las fases del modelo. cuyo objetivo es tratar de hacer mcls efectiva la siguiente iteracion por el modelo IDEAL cuando sea necesaria. EI Proceso de Software Personal (PSP) apoya a las empresas que estan llevando a cabo 0 tienen planeado implementar un plan de mejora de procesos basados en un modelo como CMM. Es necesario plantear algunas preguntas.

. Gestion Personal del Proyecto Linea Base del Proceso Personal I. Para alcanzar un nivel se deben cumplir los requisitos establecidos en los niveles previos. Niveles de Proceso de PSP Q La Linea Base del Proceso Personal (PSPO y PSPO.' ••. Detennina los pasos que los ingenieros deben seguir para mejorar la calidad del producto. tiempos y defectos.:~(.168 CAUDAD DE SISTErvt\S INFORJvV\TICOS Q Proporciona una selie de principios al ingeniero para llevar a cabo un proceso personal disciplinado. i.> •. Establece bancos de pruebas para medir la mejora del proceso personal.· Desarrollo Ciciico EI Proceso Personal Ciclico ...- Medidas Sase del Estandar de Codificacion Proceso Actual Mejora del Proceso Tamaiio Medici6n PSP 0. Q Q Q Q Estos resultados son obtenidos haciendo que los partlclpantes recopilan datos especificos relacionados con el proceso y el producto y estableciendo la linea base que proporcione a los ingenieros con un contexto para mejorar el proceso. que proporciona una introduccion al PSP y establece la base inicial a partir del histolico de datos de tamai'io.1 Figura 8. Estimacion TamaRo Informe Pruebas PSP 1.1 Plantillas de Disefio Gestion Personal de la Calidad r·<.. Detennina el impacto que los cambios del proceso tienen sobre el rendimiento del ingeniero. A este nivel los lI1gemeros escriben tres .i'·?'·.:.~. 1m1s los nuevos impuestos en dicho nive!. En la figura 8. /.5 se muestran los siete procesos que constituyen PSP agrupados por niveles..5...' .:~:.l)."i>. . .. ".1 Planificaci6n de Tareas Planificaci6n de Calendario . Estos niveles son: <'{'t~~~:t:'cg. Asiste a los ingenieros en la realizacion de planes precisos.:t Revision Disefio Revision Codigo PSP 2. :"::1'" . •.

Pasos de la Linea Base PSP Las tres medidas base de PSP son: tiempo de desalTollo. T.CAPfTCLO 8: EVALUACION Y MEJORA DE PROCESOS 169 programas y se les pennite usar sus metodos actuales. ByC I 16 I Tabla 8.o. Planificar Diseiiar Codificar I Compilar Probar Postmortem 5 6 Planificar el trabajo y documentar el plan Diseiiar el programa Implementar el diseiio Compilar el programa y corregir y registrar los defeetos encontrados Realizar las pruebas del programa y cOITegir y registrar los defeetos encontrados Registrar los tiempos reales de tamaii.1). Las estimaciones de tamai'io y esfuerzo se realizan usando el metodo PROBE (Proxy-Based Estimating).l. defectos y tamafio. y los transfonnan a lineas de c6digo (LOC). DELTA 1315:05 7:58 8:47 7:. EI proceso de medicion en PSP se introduce desde las tres primeras asignaciones del proceso en los niveles PSPO y PSPO..J.5: PASO FASE I DESCRIPCIO"l I :: 3 . con el que los ingenieros usan el tamai'io relativo del Proxy.J.5. Todas las delmis medidas en PSP son derivadas de las anteliores..TERRliP.+9 9:15 8:45 10:29 8:59 9:46 10:10 4:51 3 2 .5 y 8. como por ejemplo objetos. . pero dentro del marco de trabajo compuesto por los siguientes seis pasos representados en la tabla 8. procedimientos. puntos funci6n. I FASE ! COME2"TARIOS Planificar Diseiiar Codifiear Compilar Probar Postmol1em 100 70 31 I I 9:47 4:33 I l' -.. En las tab las 8.. Se se introducen metodos para la estimacion del esfuerzo y planificacion y seguimiento de calendario.6 y se muestran ejemplos de los fonnularios que se utilizan para el registro de tiempos y defectos: FORiVIU4\RIO DE REGISTRO DE TfDIPOS FECHA CmUDZO I I t FI"i TlEMPO {.6. Formulario Ge Regist"ro de Tiempos o Gestion Personal del Proyecto (PSP 1 Y PSP 1.I. tiempos y defeetos en el plan Tabla 8.) Llamada telefono Crear y revisar diseiio Codificar main y todas las nmeiones Compilar y enlazar Ejeeutar pruebas A. se centra en las tecnicas para la gestion del proyecto a nivel individual.J.

170

CAUDAD DE SISTEMAS INl'OR?vL~ TICOS

&;

M-Nt\

e

Gestio" Personal de la Calidad (PSP2 y PSP2.1), afiade metodos de gesti6n de la calidad a PSP tales como: revisiones personales de disefio y codigo, una notacion para el disefio, plantillas de disefio, tecnicas de verificacion y meuicas para gestionar la calidad del proceso y del producto. EI objetivo es enconu'ar y eliminar todos los defectos antes de llegar a la primera compilacion, para 10 cual se define una metrica de rendimiento de fin ida como el porcentaje de defectos inu-oducidos que fueron eliminados antes de la compilacion. Los nuevos pasos del proceso "revisal' el diseiio" y "revisal' el c6digo" son incIuidos en PSP2 para ayudar a los ingenieros a obtener un 100% en la meuica de rendimiento. Las revisiones son realizadas por el ingeniero sobre su propio disefio y codigo, y son revisiones esuucturadas, diligidas pOl' datos y son guiadas por listas de comprobacion derivadas de los datos histOlicos de los defectos introducidos por el ingeniero.
FOlUluLARIO DE REGISTRO DE DEFECTOS Il"TRODlJCIDO ELIMll"ADO TIE:VJPO· TIPO .CORRECCION ... Ei"; EN 22 C6digo I COMPIL I I 20 I

..

FECRA
13/5/05

N"
1

I
I
i i

I

I I I
I

I

I I I
I

DEFECTO CORREGIDO

Descripci6n
...

.

Error de sintaxis en sentencia SCGI?l

TIPO
20

I hrRODUCIDO
Er,\,

13/5/05

2

I
j

I

C6digo

DEFECTO EUlIcUNADO TlEMPO CORRECCION CORREGIDO EN [8 COMPIL I I

I
I

Descripci6n
I

Error de dec1araci6n de funci6n

....
13/5/05

I
I

TIPO
20

I L\TRODuCIDO EN
I
C6digo

3-6

TlEMPO i DEFECTO EUMINADO CORREGIDO El" CORRECCIOl" 1 I I COMPIL I Faltaba:

Descripci6n

Tabla 8.7. Formulario de Registro de Defectos
e

Proceso Personal Ciclico (PSP3), que resuelve la necesidad de escalar PSP de manera eficiente a proyectos de n1ayor tamafio sin saclificar la cali dad 0 la productividad. En este nivel los ingenieros deben aprender a alcanzar la productividad m<ls alta en un detenninado rango de tamafio. POl' debajo de este rango la productividad tiende a disminuir debido a costes generales. Por encima de este range la productividad tambien tiende a disminuir pOl'que se ha alcanzado el limite de escalabilidad del proceso. PSP3 soluciona este limite introduciendo una estrategia de desalTollo cicIico en la que los programas grandes se descomponen en paries que luego son integradas. Esta esu-ategia asegura que los ingenieros u-abajan en sus niveles mc1ximos de productividad y calidad con solo costes incrementales. no exponenciales, en grandes proyectos. Respecto a los niveles anteliores se introducen dos nuevos fonnularios: un res limen de ciclo para resumir el tamafio, tiempo de desalTollo y defectos en cada cicIo; y un registro de segllimiento de

!; RA-ivlA

CAPiTULO 8: EVALUACION Y iv[ElORA DE PROCESOS

171

problemas, para documentar los aspectos que pueden afectar a los ciclos futuros 0 completados. Usando PSP3 los ingenieros descomponen su proyecto en series de ciclos PSP2.1, y luego integran y prueban las salidas de cada cicio. Teniendo en cuenta que los programas que se producen con PSP2.1 son de alta calidad, los costes de integracion y pruebas se minimizan.

3.6. TSP (Team Software Process)
EI Proceso de Software de Equipo (TSP) (Humphrey, 2000a; 2000b) ayuda a conformar equipos para el desalTollo de software de calidad. TSP proporciona ill1 marco de trabajo, que se constnlye sobre la base de PSP, con fases de desalTollo bien definidas, en las que los productos de software se generan en varios ciclos. Ademas, se establecen medidas estandares para la calidad del producto y para el desempeilo de los equipos y de los desalTolladores y se aplican evaluaciones por rol y del equipo, fomentando una disciplina en el proceso y proporcionando una guia para resolver los problemas del trabajo en equipo. TSP es un proceso que los equipos utilizan para planificar su trabajo, ejecutar sus planes y mejorar de forma continua sus procesos de desarTollo software. EI proceso TSP se define a traves de una serie de guiones en los que se descliben todos los aspectos de planificacion de proyectos y desalTollo de productos. En este proceso se incluyen las definiciones de los roles del equipo, las mehicas definidas, y el proceso poshnortem. TSP se considera como una instancia del nivel 5 de CMM, definida para equipos. EI origen de TSP se debe a las limitaciones que PSP tenia en el ambito industrial (McAndrews, 2001). PSP ha tenido un gran exito en entomos academicos y de hecho los datos obtenidos de los almTIl10s que han aplicado PSP han sido muy consistentes. Este hecho creo una evidencia muy significativa sobre los beneficios que los ingenieros obtendrian al usar PSP: les pennitiria tener el control de su proceso personal mediante la mejora de sus habilidades de estimacion y la reduccion de los defectos inh'oducidos en los productos sin afectar a su productividad. Sin embargo no quedaba claro como los ingenieros podrian aplicar estas habilidades en la pnictica dentro de las empresas. Como resultado no se aplico PSP de fonna efectiva en la indushia salvo en algunas empresas. Ademas, se descubrio en empresas fonnadas en PSP, que los gestores no proporcionaban el entomo necesario e incluso volvian a repetir las mismas practicas caoticas que utilizaban antes de aprender PSP. Como consecuencia, Humphrey desalTollo el Team Software Process como una respuesta operacional al problema de implementar PSP en equipos dentro de las organizaciones. PSP cubre solo las fases de desalTollo de software desde el disefio a las pruebas unitarias. Era necesario un proceso mas practico que cubriera tambien los requisitos, las pruebas de integracion, la documentacion y otras actividades tipicas en todo proyecto de desalTollo. Por otro lado, TSP debia incluir otros aspectos importantes como los roles de equipo, intelTelaciones dentro de la organizacion y la definicion de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organizacion.

172

CAUDAD DE SISTEMAS I?\FOR\LATICOS

TSP proporciona un proceso operacional definido para guiar a los ingenieros y gestores sobre los pasos necesarios en la construcci6n de equipos. Los procesos operacionales son procesos que definen de fonna precisa el trabajo a realizar y se consideran como guiones mas que como las desclipciones textuales muy extensas que aparecen en los libros de definici6n de los procesos de la organizaci6n. Estos guiones son disei'iados para facilitar su uso pOl' los miembros de equipo cuando estan realizando su trabajo. El proceso especifica los pasos necesarios para establecer un ent0l110 efectivo de trabajo en equipo. Sin una guia especifica los ingenieros tienden a saltarse pasos, 0 realizarlos en un orden poco productivo, 0 gastando tiempo pensando que hacer despues. TSP les proporciona los procesos operacionales necesarios para fOlmar equipos de ingenietia, establecer un ent0l110 de equipo efectivo y guiar a los equipos a la hora de realizar su trabajo.

TSP ~ para calldad de los productos
score coste

calsilcL::rio

Figura 8.6. Relacion entre PSP, TSP Y C:\<L\I/C\BH

En la figura 8.6. se muestra la relaci6n de TSP con PSP y el modelo CMM. CMM proporciona el marco de trabajo general de mejora necesario para un trabajo efectivo de ingenietia en una organizaci6n. PSP proporciona las disciplinas que los ingenieros software necesitan para usar de forma consistente un proceso definido, planificado y medible. TSP acopla los principios de los equipos de producto integrados con los metodos de PSP y CMM para producir equipos efectivos de trabajo. CMM y PSP proporcionan el contexto y las habilidades para una ingenietia efectiva mientras que TSP guia a los equipos a realizar realmente el trabajo necesario, de fonna que TSP se basa en la preparaci6n que se adquiere de PSP y CMM proporcionando ademas una guia explicita sobre c6mo realizar el trabajo.

C\PiTCLO 8: E\-ALCACIO;-'; Y :VIEJOR--\ DE PROCESOS

173

Antes de que los miembros puedan participar en un equipo TSP, deben conocer como realizar un trabajo disciplinado. Tal y como se muestra en la figura 8.7, es necesario que los ingenieros que usan TSP esten f0I111ados en PSP. La f0I111acion en PSP incluye el aprendizaje necesario para: realizar planes detallados, reunir y usar datos del proceso, desarTollar planes. usar los valores obtenidos (earned vallles) para realizar un seguimiento del proyecto, medir y gestionar la calidad del producto y definir y usar procesos operacionales. En TSP, la tar'ea de construir el equipo es un proceso de planificacion de cuatro dias denominado lanzamiento del equipo (team launch). En este proceso, todos los miembros del equipo desarTollan la estrategia. el proceso y el plan para hacer su proyecto. El lanzamiento del equipo esta compuesto por nueve reuniones, cada una de las cuales tiene un guion con las actividades a seguir descritas en detalle y que el entrenador (denominado "'alil/ch coach ") utiliza para guiar al equipo. Como resultado se obtiene un plan, en los que todos los miembros del equipo deberian haber participado y con el que deben estar comprometidos. Una vez completado este proceso inicial, el equipo sigue su proceso definido para hacer el trabajo necesario.

Construcci6n de Habilidades
Planes Personales
r-.lI~todos

Construcci6n de Equipos
Compromiso
Planes AgresivQs Propiedad de la Calidad Netas del Proyecto Detalle del Plan Roles del Equipo Recursos de! Equipo

Trabajo en Equipos
Prioridad de la Calidad Coste de la Cali dad
Seguir el Proceso

de Planifjcacion

Valor Obtenido (earned value) Datos del Proceso

Revisar el Estado
Revisar la Calidad Comunicacion

r·ledidas de Calidad
Proceso5 Definidos

Gestion del Cambia

Disciplinas de Ingenieria

Disciplinas de Equipo

Disciplinas de Gesti6n

Equipos Integrados de Productp

Figura 8.7. Formaci6n de Equipos en TSP (Humphrey, 2000b)

De acuerdo a TSP, los equip os S011 relanzados periodicamente. Ello se debe a que TSP sigue una estrategia de desarrollo iterativa y evolutiva, 10 que hace que los relanzamientos periodicos sean necesarios de fonna que cada fase 0 cicio pueda ser planificado de acuerdo al conocimiento obtenido en los ciclos previos. El relanzamiento tambien es necesario para actualizar los planes detallados de los ingenieros, que nonnalmente son precisos solo para unos pocos meses. En cada relanzamiento los equipos hacen un plan global y un plan detallado de los tres meses 0 cuatro meses posteriores.

174

CAUDAD DE SISTEMAS INt'ORt'vl.A. TICOS

© RA-lvLi\

Durante cada lanzamiento del equipo tambien se elabora el plan de calidad. Para gestionar la cali dad los equipos establecen metricas y objetivos de calidad asi como planes para alcanzar dichos objetivos y los medios para conocer el progreso y llevar a cabo acciones cOlTectivas cuando no se satisfacen los objetivos. TSP ensei'ia a los equipos como deben realizar este proceso de gestion de cali dad mediante guiones en los que se definen las metric as a usaI' como parte del proceso. Las metricas pueden ser de tamafio (pOl' ejemplo en miles de lineas de cOdigo, KLOC), tiempo (en minutos y horas), calidad (en fonna de defectos), rendimiento del proceso (% de defectos eliminados antes de una fase detem1inada) y densidad de defectos (defectosIKLOC) de los productos obtenidos. En TSP se establece como estas metricas son definidas, estimadas, recopiladas, presentadas y analizadas. Tambien se hace uso en el proceso de datos histolicos de los equipos, y de lineas guia sobre calidad y planificacion. Algunos ejemplos de expeliencias industriales en la aplicacion de TSP pueden ser consultados en (Humphrey, 2000a) y (McAndrews, 2001). Desde el punto de vista academico, Oktaba e IbargHengoitia (2002) demuestran al usaI' TSP como mater1al didactico de apoyo que se fomenta el aprendizaje a u'aves de la practica obteniendose importantes beneficios para los alumnos como: f0l111acion en el proceso de desalTollo incremental e iterativo: roles y responsabilidades bien definidos: incorporacion de las met11cas en el proceso de desarTOllo: uso de tecnicas de inspeccion y revision de los productos: insistencia en la estandar1zacion de la documentacion y del c6digo y analisis post-mortem.

3.7. People Capability Maturity Model (Peopie=CMM)
El modelo de madurez de capacidad de las personas (People Capability iv/aturity ,Hodel. People CMM) (CUltis et al., 2001) es un marco de trabajo que ayuda a las organizaciones a resolver de fonna exitosa los aspectos ctiticos relacionados con sus recursos humanos. Esta bas ado en las mejores practicas en campos como los recursos humanos. la gestion del conocimiento y el desalTollo organizacional para guiar a las organizaciones a la hora de mejorar sus procesos de gestion y desalTollo de sus empleados. People CMlv/ proporciona un pr:,ograma de desalTollo continuo de los empleados, establece pri0l1dades para acciones de mejora. integra el desalTollo de los empleados con la mejora de procesos y establece una cultura de excelencia. El modelo People CMM esta disefiado sobre la premisa de que las practicas de mejoras de los empleados no tendran exito al menos que el compOltamiento de la organizacion cambie para darles sopOlte. Es un modele basado en el proceso que asume que las practicas de los empleados son procesos estandares de la organizacion que pueden ser mejorados de fonna continua mediante los mismos metodos que se utilizan para OU·os procesos de negocio. People OHM consiste en cinco niveles de madurez a traves de los cuales las practicas y procesos de las fuerzas de trabajo van evolucionando. Estos niveles establecen las bases necesa11as para la mejora continua de las competencias individuales, el desalTollo de equipos efectivos, la motivacion en la mejora del rendimiento y el

CAPiTULO 8: EVALUACION Y MEJORt'.. DE PROCESOS

175

establecimiento de las fuerzas de trabajo que la organizacion necesita para llevar a cabo sus planes de negocio. Desde la perspectiva de People ClvIM, la madurez de la organizacion se deliva de las pnicticas de fuerzas de los empleados que son realizadas de forma rutinaria y el punto hasta el cual estas pnicticas han sido integradas dentro de un proceso institucionalizado para mejorar su capacidad. En una organizacion madura, los individuos responsables realizan pnicticas repetibles como requisitos ordinarios y esperados de acuerdo a su puesto de trabajo. A medida que una organizacion es mas madura, mayor capacidad tiene para atraer, desanollar y retener el talento que necesita para ejecutar sus negocios. En la figura 8.8 se muestran los niveles de madurez de People Cj\;IM y la naturaleza de las tranSf0l111aciones impuestas sobre las practicas del personal de la organizacion a la hora de alcanzar cada nivel.

Practicas de Mejora Continua Pr<3cticas Medidas y Autorizadas Practicas basad as en las competencias

Practicas Repetibles

Figura 8.8. NiYeles de i'Iadurez de People.-CMM (Curtis et a/., 2001)

Con la excepcion del nivel inicial, cada nivel de madurez en People CMM esta caractelizado por un conjunto de practicas intelTelacionadas entre si y relativas a areas critic as de gestion de fuerzas de trabajo. En el nivel inicial, las organizaciones tienen dificultades para retener a los individuos con talento y a pesar de su importancia. las practicas de los empleados son ad hoc e inconsistentes. En algunas areas no existen definidas practicas para los empleados y en las que existen, el personal no esta fonnado para llevarlas a cabo. E1 primer paso hacia 1a mejora de la capacidad de los empleados consiste en obtener directores que asuman las actividades de los empleados como responsabilidades de alta pliOlidad. Las practicas

176

CAUDAD DE SISTEMAS INFORM:\TICOS

implementadas en el niveI gestionado se cenh'an en la atencion del director sobre aspectos a nivel unitario como dotacion de personaL compromisos de coordinacion, proporcionar recursos, gestionar el rendimiento, tomar decisiones de compensacion, etc, Por 10 tanto, el nivel 2 de madurez se cenh'a en establecer pnicticas base dentro de las unidades que resuelva los problemas mas ilUl1ediatos y prepare a los directores para implementar pnicticas mas sofisticadas en niveles superiores, Las organizaciones que estan en nivel 2, se encuentran con que aunque esten realizando practicas basicas de los empleados, existe inconsistencia en como estas practicas son llevadas a cabo a traves de distintas unidades, con la consiguiente falta de sinergia en la organizacion. En el niveI definido, la organizacion construye un marco de h'abajo de competencias de los empleados a h'aves de toda la organizacion. Cada competencia de empleado es un elemento de la arquitectura y se descliben las interacciones entre estos elementos mediante dependencias entre los procesos basados en competencias, Esta arquitectura es de caracter esh'ategico y por 10 tanto debe evolucionar de acuerdo a la evolucion de las cOlldiciones de negocio y de la tecnologia, En el nivel definido la organizacion adapta sus empleados a las necesidades de negocio mediante el desanollo de competencias. Una vez definidas las competencias, la fon11acion y las practicas de desanollo pueden ser mas sistematicamente enfocadas en desmTollar el conocimiento y las habilidades necesmias. A este nivel las practicas de los empleados implementadas en el nivel 2 estim ahora estandarizadas y adaptadas para animar y recompensar el crecimiento de la organizacion en sus competencias de fuerzas de h'abajo, En el niveI predecibIe. la organizacion gestiona y explota la capacidad creada en el nivel antelior. En este punto, la organizacion es capaz de gestionar su capacidad y rendimiento de fon11a cuantitativa y ella Ie pelmite predecir su capacidad para realizar su trabajo. Denh'o de cada unidad 0 grupo de h'abajo, se mide el rendimiento a la hora de realizar los procesos basados en competencias que son criticos para los objetivos de negocio, Las medidas obtenidas son utilizadas para establecer las lineas base del rendimiento del proceso y valorar los procesos basados en competencias que requieran acciones de mejora, En el nivel optimizante, la organizaclon al completo se cenh'a en la mejora continua. La organizacion usa los resultados del nivel anterior para guiar las mejoras de este niveL Estas mejoras estan Olientadas a la capacidad de los individuos y grupos de trabajo, al rendimiento de los procesos basados en competencias y a las practicas y actividades de los empleados, Cada nivel de madurez, excepto el inicial, consiste en un grupo de entre h'es a siete areas de proceso, cada una de las cuales identifica un grupo de practicas relacionadas que cuando se realizan de fon11a colectiva obtienen un conjunto de objetivos considerados importantes para extender la capacidad de los empleados,

£ RA,-\IA

CAPiTULO 8: EVALUACIO:-': Y :VIEJORA DE PROCESOS

177

4. EL ESTANDAR ISO/lEe 15504
EI estimdar ISOiIEC 15504 (ISO, 2004a; 2004b; 2004c: 2004d: 2006) proporciona un marco de trabajo para la evaluacion de procesos sofhvare y establece los requisitos minimos para realizar una evaluacion que asegure la repetibilidad y consistencia de las valoraciones obtenidas, La evaluacion del proceso es aplicable en el contexto de una organizacion que acrua en su nombre 0 representando otra organizacion para: entender el estado de sus propios procesos con el fin de mejorarlos; detenninar la capacidad de los procesos de otra organizacion a a'aves de un contrato; detenllinar la capacidad de sus propios procesos ante un requisito 0 clase de requisitos en particular. La parte info1111ativa del estimdar proporciona la guia necesmia sobre como utilizar un proceso de evaluacion dentro de un programa de mejora 0 dentro de un tipo de proceso para la detenninacion de la capacidad, El estandar esta compuesto por cinco partes (que sustituyen las nueve partes de la wrslOn anterior de 1998), y de las cuales la quinta se encuentra actualmente en preparacion. EI contenido de cada una de estas partes se resume en la tabla 8.8.
PARTES DEL-\.;\OR'Y!A

ISOfIEC 15504
L Conceptos y Vocabulario
,

I
II

CO!'iTENIDO

Proporciona una introduccion general a los conceptos de la e\'aluacion de los procesos y un 2:10sario de tenninos relacionados, Establece los requisitos minimos necesarios para realizar una evaluacion que garantice la consistencia y repetibilidad de las valoraciones, Los Realizaeiol1de la requisitos ayudan a asegurar que la valoracion de salida es consistente y Evalu3cion proporciona la e\'idencia necesaria para corroborar los resultados y verificar su contonnidad con los requisitos, 3: Guia,paralaRealizacionde Proporciona una guia para interpretar los requisitos a la hora de realizar una Ia Evaluaci6n e\'aluacion, Identifica la E\'aluacion del proceso como una actividad que puede ser I realizada como parte de una iniciativa de mejora de procesos 0 como parte 4., Guia sobre eI de un enfoque de detenninacion de la capacidad, EI proposito de la mejora de los procesos es mejorar de fonna continua la eficiencia y efecti\'idad de Mejora de! proceso y ]a la organizacion, El objetivo de la detem1inacion de la capacidad es Detemlinaci6n dela Capacidad del Proceso identificar las fortalezas. debilidades y riesgos de los procesos seleccionados respecto a un reqhisito particular especificado a trm'es de los procesos utilizados y de su alineamiento con las necesidades de negocio, Contiene un ejemplo de un modele para realizar la evaluacion de los 5, UnEjemplo de iyfodelo de procesos basados en el modelo de referencia de procesos definido en el EvaIu3cionde Procesos(en estandar ISO/TEC 12207, Una evaluacion se !leva a cabo utilizando un modele de evaluacion de procesos relacionado con uno 0 mas model os de preparaciol1) referencia de rocesos,

I

I I

Tabla 8.8. Contenido de ISO/IEC 15504.

El objetivo de la evaluacion del proceso es conocer la capacidad de los procesos de una organizacion. Como resultado de una exitosa implementacion de la evaluacion de los procesos se detennina la infonnacion que caracteriza los procesos evaluados y el punto

Cada ahibuto define un aspecto particular de la capacidad del proceso y el conjunto de ahibutos constituye el perfil del proceso (Process Profile. etc.Generacion de Informes Roles y Responsabilidades .: =valua:. Modelo de Referencia del Proceso .Fectla .-MA hasta el ellal los proeesos realizan Sll prop6sito. que describe un conjunto de uno 0 mas procesos en tel1ninos de su propos ito y de los resultados esperados.Propos ito del Proceso . que define una escala ordinal de seis valores para representar la capacidad del proceso (figura 8. PA).16n utiilzadc .10) que varia desde los procesos que no son capaces de realizar su propos ito (nivel 0) a los procesos que optimizan su rendimiento de f0l111a continua (nivel 5).!a de VaJoracion Modelo de Evaluaci6n del Proceso Alcance Indicadores Correspondencia Interpretacion Entrada Inicial .9. Marco de Trabajo de Medici6n para la Capacidad del Proceso. en todo proceso de evaluaci6n se incluye una entrada inicial donde se establece el alcance. Los estandares ISO/IEC 12207: 1995 y ISO/lEC 15288 proporcionan modelos de referencia de procesos.Validacion de Datos • Valoraci6n Je los Atributos del Proceso . Otros elementos significativos del proceso de evaluacion son los siguientes: o Modelo de Referencia de Procesos..?rocesD d<.Planificaci6n .TICOS ©RA. . restricciones. El proposito describe los objetivos a alto nivel que se deberian realizar mientras y los resultados esperados des crib en los resultados que se deberian obtener tras una exitosa ejecucion de dichos procesos. Dentro del marco de trabajo cada medicion de la capacidad se basa en un conjunto de atlibutos del proceso (Process Attributes.178 CAUDAD DE SISTEMAS INFOR!\tA.Alcance .9 se mllesh-an las aetividades y las entradas y salidas del proceso de evaluaci6n de ISO 15504. En la figura 8.9. PP).!dcntificacl6n de la E'Iid2ncia .EsciJ.Recopilacion de Datos .:. Como se puede obselTar en la figura 8.Resultados del Proceso r-""""'11r----i - Marco de Trabajo de la Medici6n Nivelcs de Capacidad . Cada atributo se caracteriza por Sll valor.Entrada de !a Evaluaci6n . que indica el punto hasta el cual se realiza o . EI proceso de Eyaluacioll del Estalldar ISO 15504.Proposlto Salida ..Jdentidades de Competencla .s Proceso de Evaluaci6n .Dominic y Alcanc.Restriccion:.Atributos del Proceso . proposito.?3Irocinaoor Figura 8. la infol111acion sobre los recursos y las responsabilidades necesarias asi como las caracteristicas de las salidas a obtener.

la infonnaci6n sobre los productos y procesos mediante un conjunto de indicadores. de f0l111a que un modelo de evaluaci6n de procesos es confonne si: es adecuado de acuerdo al prop6sito de la evaluaci6n. durante la evaluaci6n. parcialmente conseguido (del 15 al 50% de realizaci6n).~·RA-iv1A CAPiTULO 8: EVALUACION Y ivfEJOR. Figura 8.A. En la parie 5 del estandar se muestra un ejemplo de modelo de referencia de evaluaci6n del proceso bas ado en el modelo de referencia de la ISO 12207. Un modelo de evaluaci6n del proceso esta relacionado con uno 0 mas l110delos de referencia . los modelos de evaluaci6n deben adhelirse a cielios requisitos. La combinaci6n del grado de realizaci6n de los atlibutos de proceso para un detenninado grupo de attibutos detennina el nivel de capacidad del proceso.una fonna fiable y repetible.10. Por ejemplo. el grado de realizaci6n de un atlibuto podria estar relacionado con la realizaci6n de otl·o atributo dentro de la dimensi6n de la capacidad. :\iveles de capacidad de Procesc en ISO/lEe 15504 €I Modelo de Evaluacion del Proceso. Los modelos de evaluaci6n se basan en las desClipciones de proceso incluidas en los modelos de referencia del proceso. DE PROCESOS 179 dicho atlibuto. sus elementos relevantes se cOITesponden con los procesos desclitos en el modelo de procesos de referencia y con los atlibutos de proceso desclitos en la segunda parte de ISO 15504. Los valores estan definidos de acuerdo a la siguiente escala: no conseguido (del 0 al 15% de realizaci6n). Aunque los atlibutos se definen de fonna que puedan ser puntuados de fonna independiente. Con el fin de asegurar que los resultados de la evaluaci6n son traducibles a un perfil de proceso de ISO 15504 de. ella no implica que no existan relaciones entl·e ellos. tiene un mecanismo fOlmal y velificable para expresar la infonnaci6n tomada. que proporciona el mecanismo mediante el cual se relacionan los modelos de evaluaci6n del proceso y el marco de trabajo de la medici6n. bastante conseguido (del 50 al 85% de realizaci6n) y completamente conseguido (mas de 85% de realizaci6n). constituye la base para obtener.

para COnfil111ar de f0l111a objetiva 1a evidencia de los datos obtenidos: asegurar que 1h evidencia es suficiente y representativa para cubrir el alcance y proposito de la evaluacion.180 CAUDAD DE SISTE\!AS I"-JFOR\Li. almacenamiento. que deben dar soporte a la reunion. Constituye la base para la obtencion de la evidencia necesaria para valorar la capacidad del proceso. Valoracion de los Atributos del Proceso. los recursos y e1 calendario asignado a las distintas actividades. como f0l111Ularios. Durante la evaluacion. Para ella puede ser necesario el uso de varias helTamientas que pueden ser "paper-based'. En una dimension. el conjunto de indicadores definidos en el modelo de evaluacion del proceso se debe usar para dar soporte a los asesores a la hora en puntuar los atJibutos del proceso con el fin de establecer la base para la repetibilidad en las diferentes evaluaciones. TICOS de procesos. asegurar que los datos son consistentes en su conjunto. la identidad y responsabi1idades de los participantes en la evaluacion. analisis. las actividades a realizar para \levar a cabo 1a evaluacion. EI proceso de evaluacion esta compuesto por las siguientes actividades: II Planiticacion. registro. analisis de los datos y una justificacion de las valoraciones realizadas. obtencion. EI modelo de evaluacion proporciona una vista bidimensional de la capacidad del proceso. Esta recopilacion debe realizarse de una f0l111a sistematica y debe contemplar la estrategia y las tecnicas necesarias para la seleccion. cuestionarios 0 listas de comprobacion. los criterios para velificar que se cump1en los requisitos del estandar y una desclipcion de las salidas planificadas de la eva1uacion. de f0l111a que se les asigna una puntuacion en base a los datos validados. y helTamientas software para casos en los que el volumen y complejidad de los datos es mayor. En la otra dimension el modelo de Evaluacion describe las capacidades que se relacionan con los niveles de capacidad del proceso y los atlibutos de proceso definidos en ISO 15504. El conjunto de puntuaciones de los atributos del proceso debe ser registrado en el perfil del proceso para la unidad organizacional definida. Se debe registJ'ar el proceso de toma de decisiones utilizado Ii) Ii) Ii) . Ii) Herramientas de Evaluacion. Validacion de los datos. recuperacion y presentaci6n de los datos de la evaluacion. se desclibe un conjunto de entidades del proceso relacionadas con los procesos del modelo de referencia. en e1 que se debe desarrollar un plan de 1a eva1uacion en e\ que a1 menos se deberia incluir: las entradas requeridas que estan especificadas en el estandar. en 1a que se deben obtener los datos requeridos para evaluar los procesos dentro del alcance de la eva1uacion e inf0l111acion adicional. Recopilacion de datos.

CMMi Y SCAMPI El exito y amplia aceptacion de CMM propicio la aparicion de modelos similares inc1uso en otras disciplinas ademas del software. Siendo susceptible a la inferencia de esfuerzos legales.0 de los modelos CMMI-SE/SW y CMMI-SESWiIPPD) consistian en integrar tres modelos de mejora de procesos especificos: software. El proyecto CMMI persigue objetivos tanto a corto como a largo plazo. Esta proliferacion de modelos ha facilitado la aparicion de conflictos en los objetivos y tecnicas de la mejora de procesos. Estableciendo reg las de construccion unifon11es. Incrementando la claridad y comprension.C\PiTUO 8: EVALF-\CIO. e Generacion de Informes. Esta integracion fue propuesta para reducir el coste de la mejora de procesos basados en modelos e implementados mediante varias disciplinas de la siguiente manera: e e e e Eliminando inconsistencias.-'. debido al considerable incremento en el entrenamiento requerido. Reduciendo duplicaciones.-\ DE PROCESOS lSI para derivar las puntuaciones y se debe mantener la trazabilidad entre las puntuaciones de los atlibutos y las evidencias utilizadas para detel111inar dichas puntuaciones. y a la confusion por parte de los que los aplican. • Proporcionando terminologia C01111111. Manteniendo componentes comunes. e e e e e . Y Y[EJOR. Proporcionando estilos consistentes. ingenieria de sistemas y desaITollo de procesos y productos integrados. en los que se presentan los resultados de la Evaluacion asi como el minimo de salidas de la evaluacion exigidas de acuerdo al estandar. Asegurando la consistencia con ISO 15504. CMMI constituye un solo modelo que cubre mLlltiples disciplinas y se creo con el objetivo de eliminar esas desventajas. CMMI-SE/SW/IPPD indica el modelo que afiade material para la integracion de procesos y desaITollos de procesos ell CMMI-SE/SW. de cm'!l de los modelos usar segLll1 sus necesidades especificas. Los objetivos iniciales (los cuales se llevaron a cabo en el 2000 con la publicacion de la version 1. 5. CMMI-SE/S\V especifica el 1110delo CMMI que contiene las disciplinas de ingenieria de sistemas y software.

MODELO FUENTE . CMMI selecciona solo los aspectos mas importantes de la mejora de procesos y entonces agrupa estos aspectos denu"o de "areas".9. hay que indicar que en este modelo se hace una distincion de los 111ismos en tres categorias principales. Cada area de procesos tiene enu"e uno y cuatro objetivos especificos. .. El CMM est! organizado para ayudar a la organizaciones de software a mejorar mediante una trayectoria evolutiva. En contraste.l82 CAUDAD DE SISTEivLA. e Material requerido. el cual indica que se ha conseguido un cielto grado del proyecto y un cielto control de los procesos.lE Software El CMM para software (SW-CMM) Modelo que describe los principios y pnicticas fundamentales de la madurez de procesos software. el equipo de desalTollo de CMMI creo un marco de trabajo automatizado y extensible y definio reglas para la posible inclusion de mas disciplinas dentro de este marco de trabajo.9.S Ij\IFORMATICOS fJRA-MA Los objetivos a largo plazo consisten en establecer la base necesaria para la posterior inclusion de otras disciplinas (tales como adquisicion y seguridad). esperado e infonnativo. Cuando un objetivo es unico en un area de procesos simple. DESCRfPCION MODELO FUE1'. creciendo con fines especificos. Los modelos en los que se basa CMMI son los que aparecen en la tabla 8... No to do 10 relacionado con procesos y mejora de procesos esta incluido en un modelo de mejora de procesos. desde un ambiente ca6tico hacia unos maduros y disciplinados procesos de software Integraci6n de todas las disciplinas de sistemas para que conozcan las necesidades tecnicas y de negocio de la fom1a Im1s efectiva Enfoque sistematico para el desarrollo del producto que incrementa la satisfacci6n del cliente mediante una colaboraci6n oportuna de las disciplinas necesarias a 10 largo del cicio de vida del producto Ingenieria de Sistemas Modelo de Capacidad de Ingenieria de Sistemas (ELMS 731) Desarrollo integrado de producto CM!v! (IPDCMNI) Proceso integrado de desarrollo de productos Tabla 8. Para facilitar ambos modelos de integracion actuales y fuhlroS.'. se Ie llama un objetivo especifico. Es esencial para el modelo y para la comprension de que es necesalio para la mejora de procesos y para hacer demosu"aciones de confonnidad con el modelo. un hecho notable. Como sus predecesores. Un objetivo representa un estado final deseable. Modelos de CMMI Un concepto fundamental de todos los modelos CMMI es el area de procesos. que por orden de importancia son: requerido. Desde el punto de vista de los contenidos del modelo CMMI. DISCIPLINADEL MODELO . cuando un objetivo puede aplicarse a todas las areas de procesos. EI lmico componente requelido del modelo CMMI es el "objetivo". se Ie llama un objetivo generico.

1. incluyendo de esta f0l111a la representaci6n de CMM y la representaci6n de ISO 15504: representaci6n por etapas y continuo. CAPiTULO 8: EV ALUACION Y MEJORA DE PROCESOS 183 La versi6n 1. la representaci6n por etapas se estmctura en t0l110 a niveles de madurez. 5. EI Otro aspecto impOliante y muy nove do so en el modelo CMMI. Esta representaci6n pennite evaluar los procesos de una organizaci6n para establecer la madurez global de la misma.Ri\. EI CMM para software es el ejemplo primordial de modelo por etapas.0 del modelo CMMI-SE/SWIIPPD abarca un total de cincuenta y cuatro (54) objetivos especificos. Cada area de procesos esta descrita en tenninos de practicas que contribuyen a satisfacer sus objetivos. que se van alcanzando en la medida que se cumplen en la organizaci6n las areas clave de proceso asociadas a cada nivel de madurez. denominadas "niveles de madurez". . EI progreso ocurre satisfaciendo los objetivos de todas las areas de proceso en un nivel de madurez detel111inado.11.-ivLA. Proporciona una guia lltil para mejorar los procesos. Material Inforrnativo. el material esperado se considera que juega un papel fundamental en la mejora de procesos. Sin embargo. Como se puede observar en la figura 8. Una pnictica representa el metodo "esperado" para el cumplimiento de un objetivo. es que usa dos tipos de representaciones de sus modelos. EI lmico componente esperado del modelo CMMI es la declaraci6n de una "Pnictica". No es un matelial esencial para el modelo.11 se muestra la estructura de la representaci6n por etapas. Es el mas extenso y constituye la mayoda del modelo. y ofrecer una mayor clmidad para la comprensi6n de los componentes requeridos y esperados. Representacion por eta pas Un modelo por etapas proporciona un marco predefinido para la mejora organizacional basada en el agrupamiento y ordenaci6n de procesos y en las relaciones organizacionales asociadas. Cada pnictica en el modelo CMMI esta destinada exactamente a un objetivo. podda no estar presente en una organizaci6n que use el modelo CMMI con exito. Las practicas describen la infi-aestmctura y actividades que mas contribuyen en la implementaci6n e institucionalizaci6n efectiva de las areas de procesos. EI tennino "por etapas" viene de la fonna en la que elmodelo describe este marco como una serie de "etapas". y en algunos casos. En la figura 8. EI Material esperado. Cada nivel de madurez tiene un conjunto de areas de procesos que indican en que aspectos debeda centrarse una organizaci6n para la mejora sus procesos.

Mejora Continua del Proceso (2 .A..umjnhtr~d{jr (lS.la del :-.Gl""'>lion lnlli.reas de Pieceso) Gesti6n \.11.11 Areas ce ProceSO) (01'1)) . <~reas Clan de Proceso agrupadas segun la representacion pOl' etapas (Philips. Representacion por etapas de CMMI En la representaclon por etapas las areas son agrupadas dentro los niveles de madurez que van del nivel2 al5 (figura 8.uam.12).\j.+ CAUDAD DE SISTEL-\S 10:FO~'vlATICOS Figura 8.12..18. (7 Areas ce Pro:eso) Figura 8. 2001) .rm.lIa'Clva (2 Areas de Proceso) \.

Se denominan continuos porque ninguna etapa discreta esta asociada con la madurez de la organizacion. RA-ivLA. las practicas de un area de procesos en un modelo continuo estin organizadas de fonna que dan sopOlte a la mejora y al crecimiento de procesos individuales. En la representacion continua. sino que 10 que se facilita es la evaluacion de procesos individuales. el concepto clave de CMMI 10 constituyenlas areas de proceso. En la figura 8. El modelo EIAllS 731 es un ejemplo de un modelo continuo. los modelos continuos tienen areas de procesos que contienen practicas.13. las areas de . Representacion Continua de CMMI Como se puede observar en la figura 8. Estas areas son las mismas en todas las representaciones de la arquitechlra de CMMI.2. son extemas a las areas de procesos individuales y son aplicables a todas las areas de procesos. A diferencia de los modelos por etapas.£:. CAPiTULO 8: EV ALUACION Y lv!EJORA DE PROCESOS 185 5. Elmodelo CMMI-SE/SW/IPPD tiene 24 areas de proceso que definen la dimension delmodelo.13. cada una de las cuales tiene una defmicion que es casi equivalente a la definicion de niveles de madurez en los modelos por etapas. pennitiendo que una organizacion pueda seleccionar un conjunto de sus procesos individuales para evaluarlos y conocer la madurez concreta de dichos procesos. Representacion Continua C a p 5 a c i d a d 4 3 2 1 o Proceso Figura 8. Las practicas generic as estan agrupadas bajo niveles de capacidad.13 se muestra la representacion continua de CMMI. La mayoria de las practicas asociadas con la mejora de procesos son genericas. Representacion continua Los modelos continuos proporcionan una guia menos especifica con respecto al orden en el cual deberia realizarse el proceso de mejora. Como los modelos por etapas. Desde el punto de vista de la evaluacion de los procesos. la representacion continua no se estmctura en tomo a niveles de madurez.

jn ~lill1ini . .. dt: Dt:(i~iont:" y Rt:~nlud6n .ti . SCAMPI incorpora las mejores pnicticas del dominio de evaluaci6n. . Gesti6n de Proyectos.S INr-GRJ"LA..Gl"':!ri6n til' Rl'qubitos _ Dt:~r:wr()110 de Requisitm .j inh:... Software Capability Evaluation (SCE) V3.:i\-'n:.)~ C':':.Inu(n :Jciun ~ Dhrribuciun _ ~oluciun Tecnica _ \'erificacillll _ Validacion del PrnCl'SO y Pruducto . \r:1J.! b Im.0 Method Description.AIl:ilbi<. Organi/aciollai .i. incluyendo tanto las evaluaciones intel11as (valoraciones) como la detenninaci6n de la capacidad extel11a.!. ."il 11ll:.i<. Eil Eil .o]udtln de Rie\go':! .(ll>t!.Gestiim Inft:grad:l de Proyt'ctu:.o Oq.. .O Organizaciollai .. SCAMPI es un metodo de evaluaci6n aplicable a un amplio rango de modelos de evaluaci6n.:.ldrlll Org:lOiJacioIl!li Rt:ndimicnto d Sumini<..Gc . 1L!(h'f Figura 8.2 Appraisal Method (EIA. ti{I[l Cuantirati\a dt: .'gunmlicnro de la CaUdad Ellfoqnc Proct:<.ani/":lcionai .ai y Rt:.Ge'llit'11l de Confi~ur. Areas Clave de Proceso agrupadas segiin la representacion continua (Philips. SCAMPI (Standard CMMI Appraisal Method for Process Improvement) Para la evaluaci6n basada en el modelo CMMI se usa el metodo SCAlVIPI (SEI.14.. Gt:~ti6n ..:\lonituriL:tciull ) Control dt: FOrlll:..l:~.Equipo .3. 2001)..:cto DciinidtlO ProCl':. SCAlYfPI es un metodo de evaluaci6n de c1ase A de acuerdo a la c1asificaci6n establecida en ARC.14): Gesti6n de procesos.!:. 1998).(Appraisal Requirements for Civflvil) y puede dar soporte a la conducci6n de evaluaciones basadas en ISOIlEC 15504.:..An:ilhl<.lntlt. ! - Gestion de Proyectos ! I . Ingenieria y Apoyo 0 Soporte. 2001) 5.Enh'nlc1 Org:lni..(j:>l:.:t:l ..PI:ll1il1C::lcifJIl dd ProYi.u. .tflluor .\(::i()n .\n:iJi:.:i\'.... Cl. y esta bas ado en las caracteristicas de anteriores metodos significativosde evaluaci6n como son: Eil CMM-Based Appraisal for Intel11al Process Improvement (CBA IPI) v 1.'gr.186 CAUDAl) DE SISTEivL1>.r:!-:i"'ln - Sd~~~ion y \!uniwrli'::.1 Electronic Industlies Alliance/Interim Standard (EIAlIS) 731.j Sunm1!~tr:hk'..Inh'~nlci6n del Producto . TICGS proceso se agrupan por las categorias (figura 8.rJd~l p:.n l::.\It"dicioll y . Jd Sum:ni .A.

etc. en la que se recaba la infom1acion necesaria para la evaluacion relacionando la infonnacion con el modelo de referencia. la seleccion y preparacion del equipo.10.. en el que se entregan y archivan los resultados de fom1a adecuada. Conducci6n de auditorias del proceso. " Mejora Interna del Proceso . en la que se incluyen el anaIisis de los requisitos de la evaluaci6n (objetivos.Las aplicaciones de evaluaci6n interna incluyen: . Enfoque sobre domini os especificos 0 lineas de productos. se documentan los datos transfonmindolos en registros que representen la implementacion de las practicas y las fortalezas y debilidades y se generan los resultados de la evaluacion en los que se calculan los niveles de capacidadlmadurez de los procesos en base a los datos tomados y la aplicacion de algOlitmos de calculo sobre esos datos. . alcance. Informe de resultados. se verifica y valida la infom1acion obtenida.. • • .1 O. restricciones.. el conocimiento de las actividades y procesos de la organizacion a evaluar y la preparacion de las estrategias de recopilacion de los datos. . Aplicaciones del metodo SCAMPI Al igual que los metodos de evaluacion CBAlIPI y SCE las principales fases de la evaluacion SCAMPI son: • Planificacion y preparacIOn de la evaluacion. Tabla 8. " " Selecci6n del Suministrador Monitorizaci6n del Proceso Los resultados se usan como factores discriminantes para la selecci6n de suministradores y para establecer los riesgos relacionados con el proceso de aceptaci6n de un contrato. Evaluar proyectos especificos. el desalTollo del plan de evaluacion. Constituyen un factor mas de selecci6n y constituyen la linea base para un posible posterior control de los procesos del suministrador seleccionado. Medir el progreso en la irnplernentaci6n de un prograrna de mejora. Se puede usar la evaluaci6n como mecanismo de control de los procesos del suministrador una vez que ha sido seleccionado. " " Medici6n del progreso de la mejora.. Realizacion de la evaluacion.)..La evaluaci6n interna de los procesos se aplica en las organizaciones para: " " Establecer una linea base de su nivel de capacidadJrnadurez. Preparaci6n para evaluaciones externas conducidas por el c1iente.1:RA-MA cAPinJLO 8: EVALUACION Y MEJORA DE PROCESOS 187 Las principales aplicaciones del metodo SCAMPI se resumen en la tabla 8. Establecer 0 actualizar un prograrna de rnejora del proceso. APLICAClON DESCRIPClON ..

C (definido). Y siete (7) niveles de madurez: A (en optimizaci6n). Modelo de Referencia para la mejora de proceso de software (MR pms) que como se puede ver en la figura 8.TICOS 6. 6. Mode/o de Referencia para me/horia de processo de software (MR mps) La empresa SOFTEX de Brasil.15. EI me to do de evaluaci6n se bas a en la nonna ISO 15504. parcialmente implementado. D (grandemente/largamente definido). bastante implementado. Este proyecto engloba dos modelos (Weber y Rocha. comprende niveles de madurez y un metodo de evaluaci6n. El Se contemplan los veintid6s (22) procesos de la nonna ISO 12207 (ISO. 2004): El Modelo de Negocio para la mejora de proceso de software (MN mps). Con esta mayor granularidad en los niveles se pretende facilitar una implementaci6n mas gradual. En la tabla 8. 2002). que puede ser personalizado para una empresa 0 de fonna cooperativa para un conjunto de empresas.1.188 CAUDAD DE SISTEwLo\. . y afinnaciones (resultantes de entrevistas). no implementado. F (gestionado).S INFO~\tA. y se basa en tres tipos de indicadores: directos (productos intennedios). A continuaci6n se des crib en brevemente algunos de los mas representativos. indirectos (documentos que indican que una actividad fue realizada). G (parcialmente gestionado). EI grado de il11plementaci6n de una practica se evallJa de acuerdo a cuatro niveles: totalmente il11plementado.11 se presentan las reglas para caracterizar el grado de implementaci6n de las practicas COnf0l111e a SPICE y CMMI. E (parcialmente definido). cOOl'dina un proyecto para la mejora del proceso software denominado (Proyecto mps Br). adecuada y en plazos mas cortos para las empresas pequei'ias y l11edianas de Brasil. B (cuantitativamente gestionado). que tiene como misi6n tranSf0l111ar Brasil en un centro de excelencia mundial en la producci6n y exportaci6n de software. Las empresas negocian con instituciones acreditadas para la implementaci6n (ICI) y con instituciones acreditadas para la evaluaci6n (ICA) de la mejora del proceso software. MODELOS IBEROAMERICANOS DE MADUREZ Y EVALUACION Se estan desanollando y utilizando diversos modelos de madurez en varios paises iberoamericanos.

11.. ALC.fEJOR.I----il\lll> Metodos de Evaluaci6n Guiade lmptementacion MPS Guia General Gufade MPS Eva!uacion MPS Instituciones Certificadas para la Implementacion de MPS ICll ICI2 ICln lnstituciones Certificadas para la Evaluacion de MPS ICAl ICA2 ICAn Empresa 1 Empresa n Figura 8.. Modelo de referencia para la mejora de proceso software (MR pms) GRADO DE . Un indicador directo no esta presente 0 es juzgado inadecuado Artefactos 0 afirmaciones sugieren que algunos aspectos de la pnictica estan implementados Cualquier situaci6n diferente de las de arriba >85%a 100% Largamente implementado > 50~o a 85% Parcialmente implementado No implementado · • · > 15%a 50% O%a 15% Tabla 8.-_ __ CMMI Modelo para la Mejora de los Procesos Software (MPS Sr) Niveles de Madurez -<!.t R.·GRADODE ".4c"lCE .A. DE PROCESOS 189 ISOIIEC 12207 ISOIIEC 15504 (SPICE) . Existe por 10 menos un indicaj:lor indirecto y!o atimmci6n para confimmr una implementaci6n. Reglas para caracterizar el grado de implementacion de las pnicticas en el MRmps . No nle observado nimrun defecto substancial en indicador directo esta presente y juzgado adecuado. y es juzgado •··.'\ PRACTrCA CARACTEruzAcroN .• • Totalmente implementado Un indicador adecuadamentc." Ii\fPLEYIEi'ilAclON DE L. dirccto esta presente • • • • • Existe por 10 menos un indicador yio afimmci6n para confimmr la impiementaci6n.A.-MA CAPITULO 8: EVALUACION Y i>.15. Fueron observados uno 0 mas defectos.

Los roles se asignan al personal de la organizacion de acuerdo a sus habilidades y capacitacion para desempefiarlos. a solicitud de la Secretatia de Economia. con las siguientes partes: e e e e Parte 1: Definicion de conceptos y productos Parte 2: Requisitos de Procesos (MoProSoft) Parte 3: Guia de implantacion de Procesos Parte 4: Directrices para la evaluacion (EvaIProSoft) El proposito de MoProSoft es fomentar la estandarizacion de su operacion a traves de la incorporacion de las mejores practicas en gestion e ingenietia de software.2.1.TICOS ©RA-M4 6. proporcionando a la indusuia de software en Mexico. 2005).!'vLA. Las principa1es caracteristicas de las categOlias de procesos de MoProSoft son: e La categoria de Alta Direccion contiene el proceso de Gestion de Negocio. Ademas se considera a1 C1iente y a1 Usuario como roles extemos a 1a organizacion. En MOPl:OSOft se c1asifican los roles en Grupo Directivo. as! como evaluar los resultados para poder proponer cambios que pennitan la l11ejora continua. En cada proceso estan definidos los roles responsables por la ejecucion de las practicas. no ser costoso en su adopcion y ser la base para alcanzar evaluaciones exitosas con otros 1110delos 0 n0l111as. Responsable de Proceso y OU·os roles involucrados.16): Alta Direccion.. Recientemente y basado en este modelo se publico la nonna mexican a NMX-059NYCE-2005 "Teenologia de la Iriformacion-Soft1l'are-Modelos de proeesos de evaluacion para desarrollo y mantenimiento del sofnvare". para 10 cua1 es necesario considerar las necesidades de los c1ientes.190 CAUDAD DE SISTEMAS INFOR. un 1110delo basado en las l11ejores practicas intemacionales con las siguientes caractetisticas: facil de entender. facil de aplicar. que en su gran maYOlia es pequefia y mediana. Modelos de Procesos para la Industria del Software (MoProSoft) Un grupo de expertos mexicanos dirigido por la profesora Hanna Oktaba de la Universidad Nacional Autonoma de Mexico. E1 propos ito de Gestion de Negocio es estab1ecer la razon de ser de 1a organizacion. ha desanollado un "Modelo de Procesos para la Industria de software (MoProSoft)" (Oktaba et al. sus objetivos y las condiciones para 10grarlos. Gestion y Operacion que reflejan la estrucUlra de una organizacion. tales como ISO 9000:2000 0 CMM V 1. . Ell11odelo de procesos (MoProSoft) tiene tres categotias de procesos (figura 8.

Servi::iQs e Inrraestru::tu:-a {from GestiOn) -_ . El prop6sito de la Gesti6n de Proyectos es asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organizaci6n. la industria de software representa una actividad econ6l11ica de suma il11portancia para todos los paises del mundo. ambiente de trabajo y proveedores.<<Su!:l?roceso» genes. y especialmente para los iberoal11ericanos. Bienes.ecifl::os (from O.£:. Categorias y Relaciones de Procesos del modelo MoProSoft e La categoria de Gestion esta integrada por los procesos de Gesti6n de Procesos. .rec6on ~ <<Cate!.eracion «Prcceso» Gestio. ya que ofrece Imiltiples nlentes de ingresos y empleo y se perfila como una de las oportunidades mas impOltantes en los paises en via de desalTollo. infraestructura.• » ~ O. en funci6n de los procesos requelidos identificados en el plan estrategico.'! de r~egodo (from Alta D:recckSn) «Proceso» Gesti6n de Procesos (from Gestion) «?roceso» «Proceso» G::stl:in de R=cursos {from Ge:stion) -1---.. La finalidad es apoyar el cumplimiento de los objetivos del plan estrategico de la organizaci6n..a» Alta !). El prop6sito de Gesti6n de Procesos es establecer los procesos de la organizaci6n.eraci6n) . Gestifln de Prayectos (frem Gestion) «Proceso» '. . asi como crear y mantener la base de conocimiento de la organizaci6n. La categoria de Operacion esta integrada por los procesos de Adl11inistr-aci6n de Proyectos Especificos y de Desanollo y Mantenil11iento de Software. El prop6sito de Gesti6n de Recursos es conseguir y dotar a la organizaci6n de los recursos humanos. ---~-- <<$utJProceso» <<$wbProceso» Desarool:o r'lenten:mento de Software Figura 8.... . e 6.dmn:stracf::in de Proyectos Es. Este ultimo esta constituido por los subprocesos de Recursos Humanos y Al11biente de Trabajo. planear.. Servicios e InfraestrlJctura y Conocil11iento de la Organizaci6n. Gesti6n de Proyectos y Gesti6n de Recursos. RA-ivV\ CA PiTIJLO 8: EVALUACION Y MElORA DE PROCESOS 191 <<Catecor..-... Asi como definir... Mejora de procesos para fomentar la competitividad de la pequena y mediana industria del software de Iberoamerica (COMPETISOFT) Como sabemos. _ ..3.16.---. e implantar las actividades de mejora en los mismos..

etc. manuales. y que se desarrolla siguiendo el metodo de investigacion en accion como muestra la figura 8. 2004). A principios de 2006 se ha iniciado el proyecto COMPETISOFT: mejora de procesos para fomentar la competitividad de la pequefia y mediana industria del software de Iberoamerica. un Modelo de Capacidades y un Metodo de Evaluacion aportara gr-andes .192 CAUDAD DE SISTEivlAS I)\iFORlvLA\TICOS © RA-ivLA. a su vez. Integracion en el Proyecto Competisoft Este proyecto pretende aglutinar las diferentes alternativas existentes (como las resumidas en los epfgrafes anteriores). modelos. centros publicos y organismos de estandarizacion de 13 paises de la region. aprovechando la sinergia y los conocimientos de los diferentes pafses para conseguir un marco metodologico de ambito verdaderamente iberoamericano. financiado por el Programa CYTED (Programa Iberoamericano de Ciencia y Tecnologia para el Desarrollo). en los paises iberoamericanos la industria de software es incipiente e inmadura (M&G. en el que participan universidades.stakeholders) v Resultados de la Investigacion Resultados de la aplicacion Propuestas empresas y organizaciones participantes en el prayecto (gropo eritico de referencia) Mejorade It:isProcesps Software de las PYMES iberomericimas (objeto itivestigado) Itados refinados Entregables (norm as. su crecimiento. El hecho de que los pafses iberoamericanos compartan un Modelo de Procesos. metodos.17. 10 que lleva consigo una falta de competitividad que dificulta. Desafortunadamente. • herramientas.17.) Grupos de I+D participantes en el proyecto (investigador) Figura 8. empresas. PYMES Iberamericanas (beneficiarios .

asi como incrementando el numero de empleados en el sector.interscience. 7.mil/crosstalkl.wilev. D. Disponible en http://w\vw3.and Practice. W. Revista Sojilmre Process: Improvement . R. Sojilmre Process Improvement. Revista CrossTalk: The Journal of Defense Sojilmre Engineering. LECTURAS RECOMENDADAS • Ahem. Este libro recopila lma serie de alticulos (tanto originales como publicados previamente) relevantes en el area de la evaluaci6n y mejora de los procesos software en los que describen diversos estandares y modelos representativos de evaluaci6n. November 2001. • • • • . WileyIEEE Computer Society Press. CrossTalk. El autor aprovecha su amplia experiencia en organizaciones como IBM y SEI para proporcionar al lector una guia para la mejora de los procesos software basada fundamentalmente en el entendimiento y la gesti6n adecuada de dichos procesos.. es una revista del ministerio de defensa de los Estados Unidos con el fin de promover la mejora de los procesos de ingenieria del software. Este libro constituye una referencia muy completa sobre el modelo CMMI.af. (eds) (2001). la compartici6n de herramientas de desarTollo. Disponible en: http://w>vw. Proporciona a los lectores los fundamentos y el valor de la mejora de procesos software y les orienta sobre c6mo llevar a cabo dichas mejoras utilizando el modelo CMMI./anaging the Sojhmre Process. (1989). R. j\. Este libro constituye una de las guias pnicticas 111<is importantes existentes en la bibliografia sobre la gesti6n de los procesos software desde sus diferentes puntos de vista. (2003). y Thayer.stsc. y Turner. Humplu'ey. Esto facilitani un aumento en la calidad y en la cantidad de software desarrollado en Iberoamerica. Addison-Wesley. Willey Interscience. R.com/cgi-binlihomeI15482. A. para 10 cual se incluyen trabajos representativos tanto de investigaci6n como de aplicaci6n practica. Septiembre 2003. Esta revista recopila trabajos de investigaci6n y expeliencia practica con el fin de promover la evaluaci6n y mejora de la calidad.. Addison-Wesley.GRA-MA CAPiTULO 8: EVALUACION Y MEJORA.hill.. Clouse. y el abaratamiento de los recursos fonnativos. DE PROCESOS 193 ventajas ya que facilitani la colaboraci6n entre empresas de diferentes paises. Hunter. aumentando las exportaciones y tambien el nLllnero de factorias de software instaladas en la regi6n. la movilidad de los profesionales infonmiticos. el reconocimiento de certificaciones. OVIlvD Distilled: A Practical Introduction to Integrated Process Improvement. se presentan guias para realizar las evaluaciones de acuerdo a dicho estandares asi como experiencias de aplicaci6n de la evaluaci6n y mejora de procesos en las empresas de software. tanto desde el punto de vista tecnico como de gesti6n. productividad y rendimiento de los procesos software.

EI Software Engineering Institute es el promotor del CMMI.de!mitacbeitel"!111uellem1!PSP Pagina de recursos del Proceso PSP elaborada por la Universidad de Karslruhe (Alemania).html Colecci6n de recursos de Proceso Software elaborada por la Universidad de Massachussets (Estados Unidos) en la que se incluyen marcos de u'abajo de procesos software. Incluye tanto articulos de indole academica como industrial.TICOS ©RA-MA II Proceedings de las conferencias intel11acionales: o European So/nmre Process Improvement COl?ference (EUROSPI).eurospi. estandares. materiales para la fonnaci6n. LNCS Springer.sqi. Esta conferencia intel11acional se cenu'a en metodos pnicticos para Ia mejora de los procesos software de la organizaci6n. asi como diferente infonnaci6n sobre su utilizaci6n. En http://\v\vw.cmu.ca/info. mejores practicas y esu'ategias para la mejora de procesos.au/spice/ Software Process Improvement and Capability dEtermination Website. http://www2. mantenida por una empresa consultora de Canada proporciona una colecci6n muy completa de enlaces a recursos sobre mejora de procesos software. independientemente de los modelos de evaluaci6n. International COl?ference on So/nvare Process Improvement (ICSPI). http://www. http://w\vw.edu. En este sitio web se pueden enconu'ar las llltimas versiones del modelo.ab. SITIOS WEB RECOMENDADOS II www.sei. Adermls se pueden encontrar todos sus modelos y propuestas relacionadas. etc.tantara.S Il'\"FORl\-LA.19. resultados de la investigaci6n. "indusuial track" en la que se presentan experiencias en la industIia de programas de evaluaci6n y mejora de procesos.edu Software Engineering Institute.netl. CiI CiI II II . La conferencia se divide en dos grandes sesiones: "research track" en la que se exponen articulos de investigaci6n fundamentalmente provenientes del ambito academico e.. o o 8. Product Focused So/nvare Process Improvement (PROFES).Q:ll.ipd.uni-karlsruhe. Esta lista. EuroSPI es una conferencia de ambito europeo que u'ata de promover el intercam-bio de experiencias y conocimiento sobre evaluaci6n y mejora de procesos softwa-re. http://\V\vw. El objetivo de esta conferencia intel11acional es proporcionar un foro a la indusuia y a la academia para la discusi6n sobre los llltimos resultados de la investigaci6n y la practica en las areas de mejora de productos y procesos software.edu/SWPI/SWPIpage. Call1egie-Mellon University.umassd. CAUDAD DE SISTElvL". fonnaci6n necesaria.htm Lista de Distribuci6n sobre Mejora de Procesos Software.

Aplicar el proceso de TSP para el desarrollo de dos pequeiios proyectos software rellenando la infonnacion de tiempos y defectos (vel' tablas 9. Realizar un estudio bibliognifico sobre la aplicacion de modelos de madurez en empresas que siguen metodologias agiles. CAPiTULO 8: EVALUACION Y MEJORA DE PROCESOS 195 9.7). Realizar una comparativa de los dos proyectos destacando los progresos obtenidos a nivel personal.e RA-ivlA. EJERCICIOS 1. DesatTolla la correspondencia entre el estandar ISO 9000 y los modelos CMMI y MoProSoft. 2. AnalizaI' la confonnidad de la nonna MOPROSOFT con el estandar ISO 15504.6 y 9. . 4. 3. 5. Definir una version del modelo CMMI pOl' etapas adaptada a las pequeiias y medianas empresas (PyMES).

Otros aspectos de Calidad de Sistelnas de In{Orlnaci6n

9. l\1edicion de Sistemas de Info:rmacion 10. CaUdad de la Info:rmacion
11. Gestion del Conocimiento

CAPITULO 9

MEDICION DE SISTEMAS DE INFORMACION
"No se puede contra/ar /0 que 110 se puede medir" Tom Delvfarco

1. INTRODUCCION
Una de las razones principales del incremento masivo en el interes por las metIicas software ha sido la percepcion de que son necesmias para la mejora de la calidad del proceso (Fenton, 2001). Para poder asegurar que un proceso 0 sus productos resultantes son de calidad 0 poder compararlos, es necesmio asignar val ores, descriptores, indicadores o alglll1 otro mecanismo mediante el cual se pueda llevar a cabo dicha comparacion. Para ello, es necesario llevar a cabo un proceso de medicion del software, que en general, persigue tres objetivos fundamentales: ayudamos a entender que OCUlTe durante el desalTollo y el mantenimiento, pel1nitimos contI·olar que es 10 que OCUlTe en los proyectos y poder mejorar los procesos y productos (Fenton y Pfl~eger, 1997). En efecto, las metIicas son un buen medio para entender, monitorizar, controlar, predecir y probar el desalTollo de software y los proyectos de mantenimiento (Briand et al., 1996) y pueden ser utilizadas por profesionales e investigadores para tomar mejores decisiones (Pfleeger, 1997). En este capitulo en primer lugar se presentan de fonna intI·oductOlia algunos fundamentos de la medicion del software, para 10 cual se analizan las apOliaciones de la teolia, la tenninologia y los aspectos 111<lS relevantes a considerar en el proceso de obtencion de metIicas. A continuacion se presentan los metodos y estindares mas

200

CAUDAD DE SISTEMAS INFOIUvL.\TICOS

:g RA-\IA

representativos de la medicion software, para finalmente analizar la medicion de los distintos tipos de entidades software (procesos, proyectos y productos).

1.1. Teoria de la Medici6n del Software
Uno de los campos mas influyente en los origenes de la disciplina de la medici6n del software ha sido la te0l1a de la medicion. La medicion es una actividad que aplicamos continuamente en nuestra vida cotidiana y nos pennite obtener infonnacion que nos guia en la toma de decisiones, seleccionar entre distintas altemativas la que mas ventajosa nos resulta 0 desechar una opcion por no adaptarse para nada a 10 que de ella esperabamos. Fenton y Pfleeger (1997) definen la medicion como: "el proceso de asignar Illimeros a simbolos a los atriblltas de las entidades del Illllndo real de forllla que se puedan describir de acuerdo a lInas reglas claramente definidas". De acuerdo a la anterior definicion, una entidad puede ser un objeto fisico, un evento que ocurre en un determinado momento de tiempo 0 una actividad que transCUlTe en un detenninado intervalo de tiempo, como por ejemplo: un programa, un hi to y la fase de pruebas de un proyecto software, respectivamente. Un atIibuto es una caracteristica de una entidad, como por ejemplo el tamafio del c6digo de un detenninado programa 0 el esfuerzo requerido para llevar a cabo una detenninada actividad. Por 10 tanto, en el campo de la medici6n es necesario especificar tanto las entidades como los atIibutos que se evalllan de dichas entidades. Algunos aspectos relevantes a considerar en el contexto de la te0l1a de la medicion aplicada a la medici6n del software son los siguientes (Fenton y Pfleeger. 1997):
e

Escala. Las escalas penniten establecer el tipo de representacion mas adecuado para un atributo de fom1a que se puedan comparar los valores de los mismos. Considerando que diferentes escalas pueden mediI' el mismo atI'ibuto, una cuesti6n importante a plantear es que esc ala es mas apropiada en cada caso. Para ello, en la te0l1a de la medicion aplicada al sofuvare destacan cinco tipos principales de escalas: o Escala Nominal. Es la esc ala mas bitsica, que sirna a las entidades en diferentes c1ases 0 categorias asignando al atI-ibuto un nombre. De este modo las c1ases se identifican lll1icamente mediante un nlunero 0 simbolo que no puede ser interpretado salvo como un mero identificador. Por ejemplo, distinguir de fonna nominal a los jugadores de un equipo de baloncesto pOl' su dorsal. EI jugador "30" no puede interpretarse como dos veces superior al jugador "15". Escala Ordinal. Con esta esc ala, los atributos pueden ser ordenados en rangos pero la distancia entI'e los mismos no es significativa. POl' ejemplo, las respuestas a una encuesta podrian ser: "O==totalmente en desacllerda", "1 == ni de acuerda ni ell desacllerdo", "2 == de aClierdo ".

o

CAPiTULO 9: \IEDICI00: DE SISTE\IAS DE 10:FOR-vIACI00:

20]

"3=nzllY de aClierdo", "4= tota/mente de aClierdo". En este caso cuanto mayor es el valor hay un mayor acuerdo con 10 planteado en la pregunta, pero la distancia entre los val ores 0 y 1 no tiene por que ser igual que entre los valores 2 y 3.
o

Escala de Intervalo. Este tipo de esc ala es como la ordinal pero con la diferencia de que la distancia entre los atlibutos S1 tiene sentido. Por ejemplo, si se mide la temperatura en grados cent1grados (DC), la distancia entre 30 y 40 es la misma que entre 60 y 70. Sin embargo, en esta escala las comparaciones de tipo ratio no tienen sentido, como por ejemplo: 80 DC no es el doble de calor que 40 DC (aunque el valor S1 es el doble). Escala de Ratio, que es la tmis (Itil en la medici6n del sofuvare. ya que preserva el orden, el tamai'io de los intervalos y tambien los ratios entre las entidades. Ademas, tiene un punto fijo de referencia: el cero. La esc ala debe comenzar en el 0 y se incrementa en pasos iguales. Ademas, con los valores de esta escala se pueden realizar las operaciones matematicas de suma, resta, multiplicaci6n y divisi6n. El peso es, por ejemplo, una variable de tipo ratio. Escala absoluta, que es utilizada 11l1icamente cuando s6lo hay una fonna posible de medir un atributo. En generaL los atributos evaluados mediante un metodo basado en con tar el numero de elementos son de este tipo de escala, como por ejemplo el n(1l11erO de defectos encontrados o el n(nnero de personas en un proyecto.

o

o

@

Clasificacion de Entidades. En medici6n del sofuvare se puede distinguir entre tres tipos de entidades:
o o o

Proceso, en el que se incluyen las medici ones relacionadas a las actividades del sofuvare. Pmduclo, que incluye los entregables y documentos resultantes de las actividades de los procesos. Recllrsos, que incluye los recursos necesarios para el desarrollo de los proyectos sofuvare tales como personal, sofuvare, hardware. etc.

@

Atributos intern os y extern os. Los atributos intemos son aquellos que pueden ser medidos de una entidad sin necesidad de evaluar el compOltamiento extemo de dicha entidad. Ejemplos de atributos intemos son: tamai'io y complejidad de c6digo fuente. que pueden ser evaluados sin necesidad de ejecutar el c6digo. Los atributos extemos son mediciones sobre c6mo una entidad est} relacionada con el entomo, como por ejemplo los atlibutos calidad y estabilidad de requisitos. en cuyo caso es necesario ejecutar el c6digo para obtenerlos. Estos atributos son mucho mas dificiles de evaluar que los atributos

202

CAUDAD DE SISTEMAS fl\;rO~'vLi. TICOS

intemos y la necesidad de disponer de mediciones de atributos intemos para obtener el valor de atributos extemos es bastante clara. Por ejemplo, para evaluar el atlibuto extemo cali dad del sofhvare es necesario conocer atlibutos intemos como por ejemplo el nlu11ero de fallos obtenidos en la actividad de pruebas.

Mediciones directas e indirectas. Otro de los aspectos a destacar de la teOlia de la medicion es la distincion que establece entre mediciones directas e indirectas. Una medici6n directa es la medicion de un atributo de una entidad sin estar otras entidades implicadas. Por ejemplo, el atIibuto tamafio de la entidad c6digo fnente puede ser me dido sin necesidad de evaluar ninglm atIibuto de otras entidades. Las mediciones indirectas requieren de otros atlibutos, como por ejemplo la medicion del atlibuto productividad, que requiere las mediciones tanto del tamafio como del esfuerzo y es obtenido media ante la division de ambos.

1.2. Terminologia de la Medici6n de Software
Dado que la medicion de software es una disciplina relativamente joven, no existe alm un consenso general sobre la definicion exacta de los conceptos y tenninologfa que maneja. A pesar de COI1tar con diversos estandares intemacionales que tratan de n0l111alizar estos temas (IEEE, 1998b; ISO. 1993; 1999: 2002a), se han detectado ciertas lagunas e inconsistencias en los tenninos que dichos estandares definen. como son por ejemplo los conceptos de medida. metrica, medici6n, indicador. etc. La situaci6n no es mucho mejor en los contextos academic;)s e industriales, donde las distintas propuestas de modelos de medicion de software tampoco han logrado consensuar una te!111inologia coherente y ampliamente aceptada entI'e toda la comunidad cientifica (Garcia et al.• 2005). Con el fin de contribuir a la an11onizacion de los diferentes estandares y propuestas de investigacion y de establecer una tenninologia consistente (en el sentido de consenso y libre de contradicciones) se ha desaITollado una ontologia de la medicion del software (Garcia et al.. 2005). En la figura 9.1 se muestra de fon11a grafica mediante un diagrama en UTvIL los conceptos de la ontologfa y sus relaciones. El objetivo de esta ontologia es establecer una guia de referencia que incluya los conceptos relacionados con la medicion del software. Para facilitar su comprension. la ontologia de la medici6n del software se divide en las siguientes sub-ontologias:

Caracterizacion y Objetivos de la Medicion Software, con los elementos sobre los que se puede aplicar un proceso de medicion y sus propiedades. Tambien se reflejan los objetivos que se persiguen con la medici6n del software.

<;;

R/\.-MA

CAPiTULO 9: ;-'!EDICION DE SISTEiv!AS DE INFOR.!'vIACIOl\

203

CiI

Accion de Medir, en la que se identifican los conceptos relacionados con la fOlma en la que se lleva a cabo la medici6n software.
Necesidad de Informacion
seCQrrea:::;r;:;e c:;n
{!:"~'" C"r~"'.=".:"c::n

y O!:>;e:;,es)

Tipo de Es::ala
\fr:;;mMt-t!\e::!s)

Modelo de Calidad

e,"af:ia

Concepto Medible :rc"'C"!'3~"''':'''Z':>'lyo::)e::,~)

C0dase

Escala

Unidad

de:;r;.:fopara

Categoria de Entidad
(!r::.", C:n::::,.=r;:,,:.C<1 y
C:;;<:'~>r-~l

:',,:-:2

Atributo

52

de::neparo

Metrica
{:rcmMeL"i:::as)

Entidad

s;;: rea";;:;; S::;:JriJ

Medici6n

MtHrica Dire eta
t:ror.:-.li!etn:as)

l't1etrica Indirects
{~m M~:n~as)

Indicador

s:;::;·Enidaj

(!:-C'" C"r":;,.<:',,z,,:,::n y C::j~~~CS)

:;eir:c::!DC"

Medida

Fcmna de Medir

Figura 9.1. Ontologia de la Medici6n del Software
CiI

Metricas. en la que se especifica la definici6n y caracteristicas basicas de las metricas software. Una mettica se define como una fonna de medir (metodo de medici6n, funci6n de caJculo 0 modelo de anaJisis) y una escala, definidas para realizar medici ones de uno 0 varios att·ibutos. Las metric as pueden ser de tres tipos en funci6n de su fonna de medir:
o

Metricas Directas cuya fonna de medir es un metodo de medici6n, es decir, se pueden realizar medici ones de dicha metric a sin depender de ninguna otra.

204

CALlD ..\D DE SISTEYL-,\S 10:FOR.\L.\TICOS

o

MHricas Indirectas, cuya f0l111a de medir es una fi.ll1cion de calculo, es decir, las mediciones de dicha l11etlica utilizan las l11edidas obtenidas en mediciones de ott'as l11etlicas directas 0 indirectas. Indicadores, cuya f011na de medir es un modelo de analisis, es decir. las mediciones de dicha mettica utilizan las l11edidas obtenidas en las medici ones de otras metlicas (directas, indirectas 0 indicadores) junto con cliterios de decision.

o

e

Formas de Medir. en la que se descliben las distintas f011nas de medir metticas software.

En la elaboracion y division de la ontologia de la medicion del software en subontologias, se han identificado y establecido los conceptos y aspectos mas relevantes relacionados con la medicion del software y las etapas fundal11entales componen dicho proceso. Todo proceso de medicion del software tiene como objetivo fundamental satisfacer necesidades de info11nacion. Un proceso de medicion no puede obtener resultados utiles si estos no satisfacen alguna necesidad de info11nacion detectada en la empresa en la que se lleva a cabo. A pattir de las necesidades de inf01111acion se deben identificar las entidades y los attibutos de dichas entidades que son candidatos a ser medidos. Esta patte significativa del proceso de medicion es la que se aborda en la subontologia de caracterizacion y objetivos. Una vez identificados los attibutos objeto de la medici on, se deben definir las metlicas necesatias. Para clatificar que elementos generales hay que considerar en la definicion de las metricas se ha definido la sub-ontologia de las mett·icas. en la que se identifican los principales tipos de metricas que se pueden definir. En la definicion general de una metrica se deben especificar aspectos como la unidad en la que se expresa. la escala a la que pertenece. el atributo 0 atributos para los que se define. etc. La definicion de las metricas se debe realizar a distintos niveles 0 alcances. ya que resultaria excesivamente complejo definir ae forma directa metric as a partir de las cuales se satisfagan las necesidades de inf01111acion. Por ello. es fundamental definir en primer lugar metric as que se aplican directamente sobre las caracteristicas de una entidad para evaluar un dete11ninado atlibuto. A pattir de estas metticas directas se pueden definir metric as indirectas y finalmente se podrian definir metricas con el objetivo de proporcionar infonnacion litil para la toma de decisiones, y por 10 tanto. mas cercanas a satisfacer las necesidades de infonnacion. Estos aspectos se tratan en la sub-ontologia de las fonnas de medir. en la que se identifican los metodos concretos para definir 0 calcular las metricas definidas en fimcion de su tipo. Finalmente se !leva a cabo el proceso de medicion propiamente dicho. a pattir de la definicion de las metricas y de la caracterizacion de los atributos de las entidades objeto

_':;-RA-\IA

O.PiTUO 9: \IEDICIO" DE SISTE\IA.S DE I:\FOR"L-\CIO~

205

de la medicion. mediante la realizacion de medici ones que como resultado obtienen medidas. Estos conceptos se tratan en la subontologia de la accion de medir. Una definicion y explicacion mis detaIl ada de los tel111inos de la ol1tologia puede consultarse en (Garcia et af.. 2005).

1.3. Proceso de creaci6n de Metricas
Desde los ai'ios setenta se han propuesto una gran cantidad de metlicas para capturar atlibutos de los procesos y productos software de una f0l111a cuantitativa (vease apartado 4.3 de este capitulo). Tradicionalmente estas metricas se han realizado confiando en el conocimiento de los expeltos, y si bien esta experiencia es impoltante, puede resultar 110 ser suficiente. En la actualidad muchas de las metric as propuestas han fracasado, siendo solo un as pocas las que han sobrevivido con ex ito la fase inicial de definicion y son usadas actualmente en la industria. Ello es debido a varios problemas (Briand et al., 1999):
e

Las meuicas no estan siempre definidas en un contexto en el que el objetivo de interes industrial que se pretende alcanzar mediante su utilizacion es explicito y queda bien definido. Por ejemplo: la reduccion del esfuerzo de desanollo 0 la reduccion de los fallos presentes en los productos software. En ocasiones. aunque el objetivo sea explicito, las hipotesis experimentales a menudo no estan hechas de fon11a explicita. por ejemplo ;,qlle se pretende dedllcir del analisis? (:reslilta creible el resultado? Las definiciones de metricas no siempre tienen en cuenta el ent0l110 0 el contexto en el cual seran aplicadas, por ejemplo ;,se puede IItilizar lIna llIetrica definida para lin entorno no orientado a objetos en un contexto orientado a objetos? A menudo, no es posible realizar una adecuada validacion teorica de las metricas porque el atributo que una metrica pretende cuantificar no esta bien definido, por ejemplo, la nocion de complejidad .

e

e

e

.

e

Un gran numero de metr'icas no han sido nunca objeto de validacion empiric a, por ejemplo ;,c6mo se sabe que lina metrica de tamalio predice mejor el esjiter::.o en lin elltorno de desarrollo?

Esta situacion ha conducido frecuentemente a cierto grado de ambigUedad e imprecision en las definicion, propiedades y suposiciones de las meuicas, haciendo que su uso sea dificil, la interpretacion peligrosa y que los resultados sean conu"adictorios en varios esuldios de validacion. Los problemas citados anteri0l111ente son propios de cualquier disciplina joven, y especialmente de aquellas que son intensamente humanas, como es el caso que se esta

. Metodo Alarcos para la Definicion de Metricas Software Todas estas caracteristicas no significan que no se pueda progresar en el campo de las meh1cas software. No se debe esperar.Experimentos ~. por ejemplo. por tanto. 2002). Objetivos . Validacion Empirica ~- . Metricas No Aceptadas Aceptacion Validacion Te6rica --. Los fenomenos estudiados en este campo implican un ntllnero de variables que dependen del comportamiento humano y no pueden ser controladas facilmente. -.2 y en la que las flechas continuas representan el flujo de las metric as y las discontinuas representan el flujo de infonnaci6n a 10 largo de todo el proceso.. Con este fin..206 CAUDAD DE SISTElvV\S INFORIvL-\TICOS ©RA-MA tratando. las leyes fisicas."' j Aplicacion Creaci6n Objetivos <I A r Metricas Aceptadas 4. Acreditacion y Requisitos r'''''m.. En esta etapa se pretende identificar los objetivos de la medici6n y las hip6tesis bajo las cuales se crean las meh1cas.2. Identificacion Objetivos ~ Reutilizaci6n Hipotesis i Metrica Retirada . pero para poder conseguir este prop6sito las meh1cas deb en ser definidas de una fonna metodol6gica y disciplinada. La propuesta del Grupo Alarcos consta de dos fases: fi!I Identificacion.la bibliografia diversos metodos para la definici6n de meh1cas software en los que se integran todos los aspectos que es necesario tener en cuenta en la validaci6n de las metricas. teniendo dicha definici6n una base s61ida con objetivos de medici6n claros y debiendo satisfacer las necesidades de la organizaci6n. se puede encontrar en."". como el metodo MMLC (lvIeaslire lvIode! Lt[e Cycle) (Cantone y DonzeIIi... Los objetivos .. encontrar leyes cuantitativas que sean validas y aplicables de modo general. 2000) y la propuesta del Grupo Alm'cos (Sen'ano et aI. Explicacion PSicologica Metricas Validas Figura 9. y que tengan la misma precisi6n y exactitud que. que se ilustra en la figura 9.

aplicacion y acreditacion. e Creacion. 1997. El proceso de creacion es aquel en el que a partir de los requisitos obtenidos en la etapa de identificacion se creara una metIica valida. Poels y Dedene. fallidas.fRA-MA CAPiTULO 9: MEDICION DE SISTEMAS DE INFORt'vlACION 207 indican 10 que se pretende conseguir con la utilizacion del proceso de medicion y representan la razon por la que se llevani el proceso de medicion (el "porque"). Es deseable que la definicion de las metIicas se realice de manera fonnal para evitar ambigtiedades. 1999). es decir. Basili y Rombach. cuyo o . Al final de la etapa de creacion. En la definicion se deben considerar objetivos claros. lista para ser aplicada en entornos reales. Zuse. Este proceso suele estar basado en la experiencia y el conocimiento de los expertos y puede utilizar mecanismos basados en Goal-Question-Meric (GQM: Basili and Weiss. Es el primer paso de esta fase que debe realizarse considerando las caractetisticas del producto que vamos a medir y la experiencia de los profesionales. comprobar si la idea intuitiva acerca. Van Solingen and Berghout. 1998. Como resultado de esta fase se deben obtener los requisitos que debe cumplir la metrica. hay dos tendencias principales en la validacion: los marcos basados en propiedades (que definen fonnalmente propiedades deseables de las metricas para un atributo software concreto) (Weyuker. El objetivo principal de la validacion teorica es demostrar que la metI·ica mide el atIibuto que pretende medir. las metricas se consideraran validas y aquellas que no sean validas. 1996) y los que se basan en la teotia de la medida (WhitInire. Como resultado de la realimentacion. como se observa en la figura 9.2. las metricas deb en ser redefinidas de acuerdo a las validaciones. 1984. El proceso de creacion de las metricas es evolutivo e iterativo y se subdivide en varias etapas intel111edias. Validacion teorica. 1988. Briand et al. Ademas la validacion teorica proporciona infOl1Uacion relacionada con las escalas de las metricas y asi se puede detenninar que tipo de operaciones matematicas y tests estadisticos aplicar a la hora de analizar los valores de las metricas en estudios empiricos. seran descartadas. Las etapas en las que se subdivide la creacion son: o Definicion. teoricas 0 empiricas.. es decir.del atributo que esta siendo medido se refleja en la metrica. 2000). Lamentablemente no existe un estandar para la validacion teorica a traves del cual obtener la infonnacion matematica de las metric as definidas. Ademas. 1988. los cuales senin utilizados en la etapa de creacion. realizar una definicion de la metrica Olientada al objetivo identificado en la fase anterior para evitar obtener una definicion de la metrica que no cumple con el objetivo deseado. identificando la infonnacion que se debe manejar para conseguir a1canzar los objetivos deseados. Las hipotesis son la f0l111a en la que se pretende llevar a cabo la medicion (el "como"). los objetivos seran utilizados en las etapas de aceptacion. sin embargo.

. Wohlin et al.208 CAUDAD DE SISTE\!AS fNFOR\l. En definitiva. Aplicacion. la intuici6n 0 la especulaci6n. EI objetivo de esta etapa es pro bar la utilidad pnictica de las metlicas propuestas. suele trabajar en el entOI11O final de aplicaci6n. (1999) Y Peny et al. II . Esto se consigue a u·aves de hip6tesis en el mundo reaL mas alla de la pura teoria. De esta manera. Asi pues. R:\-\L-\ objetivo es obtener la escala matem::itica a la que peltenece una metrica. (2000). en esta etapa se intenta averiguar si las metlicas "validas" que se consiguieron al final de la fase de creaci6n son aceptables en entOI11OS de aplicaci6n reales. Esta etapa se diferencia de los casos de eshldio en que en estos (lltimos se. EI saber general. es posible pasar a la etapa de aplicaci6n. proponen el usa de la psicologia cognitiva como una disciplina de referencia. 1983) pueden justificar la influencia de ciertas metricas en la comprensi6n de los sistemas. La validaci6n empiric a se utiliza para obtener infoI1naci6n objetiva sobre la utilidad de las meuicas propuestas ya que puede que una meu·ica sea COITecta des de un punto de vista f0l111aL pero no tener relevancia pnictica para un problema detenninado. Esta fase se lleva a cabo en paralelo con la fase de acreditaci6n. es necesario volver a la etapa de creaci6n. Explicacion psicologica. Algunos trabajos relevantes que proporcionan la guia necesmia para llevar a cabo estudios empilicos son los realizados por Robson (1993). no son fuentes fiables de conocimiento (Basili et al. que habra que comprobar con datos empiricos. teniendo en cuenta los objetivos obtenidos en la etapa de identificaci6n. Idealmente deberia usarse en proyectos piloto de manera que el fracaso de aceptaci6n de la meDica no suponga un fracaso en un proyecto impOltante. En esta etapa se utiliza la metrica ya aceptada en el entOI11O real. Si se consigue demosu·ar que la metric a sigue cumpliendo los objetivos. (2000) (vease capihllo II). o Validacion empirica. Algunos autores. o II Aceptacion. estadisticos y tests aplicables y especificar un marco general en el que las metlicas deb en ser definidas. el estudio empiIico resulta necesmio para comprobar y entender las implicaciones de las metricas de nuesu·os productos. las teorias como ACT (Adaptative Control of Thought) (Anderson. JUIista y Moreno (2001). Esta etapa debe ser realizada con proyectos no critic os y con riesgos conu·olados. 1999) por 10 que es necesmio realizar validaciones empilicas de las meuicas. Basili et al.\ TICOS i:':. Suele ser necesaria la existencia de una fase de pruebas en laboratOlio en la que se realice una experimentaci6n sistematica en entOI11OS reales y con usum10s reales para verificar si cumple los objetivos buscados dentro de un entOI11O de trabajo real. y si no es asi. y por tanto sus transfonnaciones admisibles. como Siau (1999). Idealmente es necesmio tener la capacidad de explicar la influencia de los valores de las meDic as desde un punto de vista psicol6gico.

partiendo de la base de que la medicion es un proceso que debe ser llevado a cabo en base a una selie de objetivos.• 2002). Esta liitima fase del proceso es una etapa dimlmica que persigue el aseguramiento de la metrica y la mejora continua de la misma. Ademas al utilizar la expeliencia de la utilizacion de la metrica descartada. 2002c) e IEEE Std 1061-1998 (IEEE. pasar de un entorno estmcturado a uno orientado a objetos) que la metrica no sea aplicable. En ocasiones el entO!11O puede variar tanto (por ejemplo.as existentes sobre la medicion de software es necesario analizar la relacion entre las mismas. DE SISTE\IAS DE INFOR\lACION 209 <I> Acreditacion. la medici on es un aspecto que se tiene muy en cuenta en los modelos de evaluacion como en ISO/IEC 15504. de manera que se puedan seguir cumpliendo los objetivos que se perseguian al principio del metodo. . una mejora de los procesos software. ESTANDARES Y METODOLOGiAS DE MEDICION Antes de poder aplicar planes de l11ejora en una organizacion es necesario partir de una base cuantitativa que pennita detenninar de una fonna objetiva los puntos fuertes y debiles de los procesos.C-\PiTULO 9: \IEDICIO:--. 2. la metrica deberia ser descartada y el conocimiento adguirido durante su tiempo de vida deberia realil11entarse a la etapa de identificacion de manera que podal110s crear una metric a adecuada para el nuevo entO!11O cumpliendo los objetivos perseguidos. En la figura 9. 0 como CMMI en el que se incluye un area clave de proceso en el nivel dos de madurez denol11inada "Medicion y Analisis··. Los plincipales aspectos a considerar en la relacion entre las diferentes propuestas son los siguientes: <I> PSM constiruye el documento base a pariir del que se ha elaborado el nuevo estandar ISO/IEC 15939 sobre la medicion del software. Como soporte al proceso de medicion se pueden destacar diversos marcos de trabajo como el mencionado GQM 0 PSM (Practical Sojhrare Measurement) (McGarry et al. Ante las distintas propuestas metodologic. as! como cielios estandares. 1998b). Para ella se ha seguido la cOl11parativa realizada por Jones (2003) con la que se llega a la conclusion de que existe un cada vez mayor esfuerzo por cOOl'dinar las distintas propuestas. Por ello. en el que se define un proceso de la medicion. en funcion de como evoluciona el ent0ll10 de aplicacion. entre los que destacan ISO 15939 (ISO. Las metricas software constihlyen la base necesaria para poder llevar a cabo un proceso de evaluacion y posterionnente. se tendran mas probabilidades de fO!111Ular hipotesis COITectas en la etapa de identificacion. EI objetivo de estos estandares y marcos de trabajo es proporcionar la referencia necesaria para poder llevar a cabo el proceso de medicion de una fonna efectiva y sistematica. en este caso. PSM proporciolla detalles adicionales respecto de las actividades y tareas de ISO 15939.3 se muestra la relacion existente entre algunas de las propuestas mas significativas relacionadas con la medicion del software.

el intento de coordinaci6n existente entre estos documentos de referencia significa que existe till conjunto de estandares de medici6n.3.. la nueva tenninologia de la 'medici6n ha sido coordinada con las revisiones en los estandares ISO/IEC 9126 (Calidad del Producto Software) e ISO/IEC 14598 (Evaluaci6n de Productos Software) con el objetivo de que todos los estandares que us en el dom. De la misma fOlma.. Practical SofwareMeasurement(PSM) ISO/IEG 15939. .inio de la medici6n esten basados en una misma tem1inologia . EI objetivo y los resultados del proceso de medici6n de ISO 15939 ha sido afiadido a la revisi6n del estandar ISO 12207 dentro de un nuevo proceso de soporte denominado Medici6n y a la nonna ISO 90003 (aplicaci6n de la nonl1a ISO 9001 :2000 al software).210 CAUDAD DE SISTEMAS INFOR. CMMI y los estandares ISO en el area de la Medicion de Software (adaptado de Jones. Por 10 tanto.. 2003) . Los conceptos del dominio de la medici6n de ISO 15939 han sido afiadidos al estandar ISO/IEC 15288 (Procesos de Cicio de Vida del Sistema). Coordinacion existente entre PSM. que tiende a ser . EI area Medici6n y Analisis de CMMI proporciona una metodologia para evaluar si un programa de medici6n de un proyecto es acorde con el estandar ISO 15939. Proceso de Medici6n de Software 15288 (conceptos de medicion) 9126 (terminologia coordinada) 14598 (terminologia coordinada) ISO 90003 (objetivos) Figura 9. por 10 que utiliza este estandar como referencia.!vIA TICOS :& RA-iV1A .

dirigidos por objetivos 0 necesidades de informacion que proporcionan la guia necesaria para la implementacion de la medicion de forma efectiva. A continuacion se desclibe como se aborda la medicion del software en los distintos 1110delos. Niveles Gestionado y Optimizante: la l11edicion se basa en la planificacion y gestion de las calidad de los procesos y productos de una fonna estadistica.~ RA-MA CAPiTULO 9: ~!EDICION DE SISTEMAS DE INFORt'v!ACION 211 cada vez mas consistente. proceso que cubre todos los procesos que establecen y dan soporte a la consecucion de los objetivos organizacionales de negocio. Nivel Definido: se dispone de un conjunto de l11etricas a nivel organizacional que facilita realizar valoraciones sobre los proyectos en su conjunto. Partiendo de la base de que "no hay actllalmente lin modelo 1I1liversalmente aceptado de medidas del proceso sofnrare 0 de la caUdad' el modelo insta a las organizaciones a identificar para cada Area Clave del Proceso. incluye en la dimension del proceso del l110delo de referencia (patte 2 de la n0l111a) el proceso de l11edicion. Los tipos de mediciones incluidos para cada nivel de madurez son: o Nivel Repetible: basado en disponer de un conjunto representativo de metlicas a nivel de gestion del proyecto. Los valores de estas l11etricas se utilizan en futuras estil11aciones de proyectos. cada organizacion especffica tiene la libeltad de seleccionar metricas concretas adecuadas para su entol110. y el uso de las metricas en la . La medici6n en los modelos de madurez y metodos de evaluaci6n y mejora La medicion juega un papel fundamental en las organizaciones que pretenden conseguir un alto grado de madurez en sus procesos. EI proceso de medicion se desclibe en el aspecto comun dell110delo denol11inado "Medici on y AnaIisis". la gestion de los datos (incluidos los datos historicos). Este hecho se demuestra observando el tratamiento y la importancia que los modelos y estandares de madurez y evaluacion y l11ejora dan al proceso de medicion: CD EI Modelo de Madurez de la Capacidad (CMlVI) asigna un impoltante rol a la medicion a la hora de detenninar el estado de los procesos software.1. Partiendo de un conjunto en el que los objetivos de la medicion son conocidos. A este nivel tambien se d~finen l11etlicas relacionadas con la calidad y funcionalidad de los productos. o o CD EI estandar ISO 15504. uno 0 mas conjuntos de medidas significativas que puedan proporcionar visibilidad en el rendimiento del proceso (llevado a cabo en fOl111a de proyectos). EI proceso de l11edicion supone la definicion de metricas. industria 0 cultura. estandares y metodos de evaluacion y mejora y se presentan los modelos y l11etodos mas representativos relacionados con el soporte a la medicion software. 2. dentro de la categoria de los procesos organizacionales.

A partir de estas practicas se establece un plan para la medici6n y el analisis con el que se pretende resolver cuestiones tales como: GPor que se mide? (: que se 1'(1 a medir? Gcomo se va a medir?. a la hora de establecer un proceso de medici6n efectivo en una organizaci6n es necesario conseguir dos objetivos fundamentales: G Alinear las acovidades de analisis de la medicion.212 CAUDAD DE SISTE:VIAS INFOR:'vL. especificar procedimientos de recopilaci6n y almacenamiento y especificar procedimientos de analisis. especificar medidas. establecen la necesidad de implementar el proceso de medici6n con el objetivo de controlar la calidad del producto. control y gesti6n del proyecto. La gesti6n usa metricas como entrada fundamental para la planificaci6n. etc. Da soporte al resto de areas de proceso proporcionando un marco de trabajo a las organizaciones a la hora de alinear los objetivos y necesidades de medici6n con un enfoque de medici6n bas ado en proporcionar resultados objetivos que sean lltiles para la toma de decisiones y acciones conectivas.4. 2003). G Como se puede observar en la figura 9. proporciona a la medici6n una gran importancia en la madurez de los procesos al incorporar una nueva area del proceso denominada "Medicion y Amllisis". cuyo a1cance es mucho mas amplio y mas explicito que el tratamiento de la medici6n en el modelo CMM. EI objetivo de esta area es desanollar y establecer una capacidad de medici6n que se pueda usar para dar soporte a las necesidades de informaci6n de la organizaci6n. En la figura 9. la capacidad del proceso y la satisfacci6n del cliente. Para conseguir este objetivo en CMMI se identifican las siguientes pnkticas: establecer los objetivos de la medici6n. todo ella orientado a la mejora continua del proceso. EI objetivo que se pre ten de es el de implementar metric as de proceso y de producto como soporte a la gesti6n efectiva y a la posibilidad de demostrar objetivamente la calidad de los productos. Proporcionar los resultados de la medicion. Este enfoque es consistente con las ideas de GQM y del estandar ISO 15939 (ISO/lEe 2002)..\ T1COS organizaClOn. Por 10 tanto. los principales procesos relacionados con esta area. y para tambien controlar la cali dad del producto. analizarlos. CMMI. almacenar los datos y resultados y comunicar los resultados. Las practicas asociadas con la consecuci6n de este objetivo son: reunir los datos de la medici6n.4 se representa mediante un diagrama de flujo de datos. con estas practicas se pretende establecer un buen proceso de recopilaci6n y G . y las relaciones de datos entre los mismos. La incorporaci6n de fonna explicita de esta nueva area de proceso en el modelo CMMI proporciona una gesti6n con el enfoque y la visibilidad que las organizaciones necesitan para guiar el uso de la medici6n en sus esfuerzos de mejora (Goldenson et al. G La familia de n0l111as ISO 9000:2000. 10 que implica una ampliaci6n a los conceptos incluidos en el modelo CMM.

medidas. Estabilizar el Rendimiento detenninar su habilidad para obtener Ia cali dad establecida de l'Ol1na de los SubProcesos cuantitativa y los objeti\'os de rendimiento del proceso. ~y. 10 que requiere la integracion de la medicion en los distintos procesos del trabajo de una organizacion. ya que estos deben proporcionarse a la persona adecuada para satisfacer sus necesidades de informacion.8. en un segundo paso.4.CAPiTL'LO 9: \lEDICIOl\' DE SlSTE\lAS DE E\FORMACIOl\' 213 comunicacion de los resultados. implementar el proceso de medicion y analisis. Establecer y mantcner objetiyos cuantitati\'os sobre Ia ealidad y -f. Tabla 9.1. PRACTIC\ I OBJETIVO 2.2. Alinear las Actividades de Analisis de la Medici6n Peesonal de Me dici6n 4 t. 5. basados sobre las necesidades de los clientes y Cuantitativos para el Proceso los objetiYos de negocio. Area Clave ":\Iedici6n y Analisis" de CMMI Por 10 tanto. Monitorizar y Controlar el ..l.v[onitorizar y controlar cl proceso respecto al plan para Ia realizacion del proceso y !leyar a cabo las aeciones cOITeeti\'as apropiadas. el plimer paso del proceso de medicion es el de identificar los objetivos de la medicion para.-\segurar Ia \ lejora Asegurar Ia mejora continua del proceso en Ia consecucion de objetiyos Continua del Proceso de negocio relevantes dc Ia organizaeion. Proporcionar los resultados de Ja Medici6n Figura 9. c 3.Estabiecer Objetiyos rendimiento del proceso.2 Recopilar Infol1naeion de infol111acion de Ia mcjora deri\ada de Ia planiticacion y realizaeion del :v[ejora proceso para dar soporte a su uso nlturo y a Ia mejora dc los proeesos de Ia organizacion. . Estabilizar el rendimiento de uno 0 milS subprocesos del proccso para -f. resultados de Ia medicion. . Proceso I Reunir productos de trabajo. Practicas Genericas de CM:\II relacionados con la medici6n .1.

define. orientada a un objetivo. preguntas. en la que se relll}enios datos reales de la medicion. Definicion.1 (Goldenson et aI. siendo soportados por una helTamienta integrada de medici on. GQM define un objetivo. metric as e hipotesis). caracteriza y planifica un proyecto para la aplicacion de la medicion obteniendose como resultado un plan de proyecto. Interpretacion. 2. 4. . En definitiva. refina este objetivo en preguntas y define metricas que intentan dar informacion para responder a estas preguntas. poder definir de fonna precisa modelos concretos de medida que. EI proceso se ilustra en la figura 9. a partir de las cuales se puede evaluar el logro del objetivo planteado. en la que se procesan los datos recopilados respecto a las metric as definidas en fonna de resultados de medicion.214 CAUDAD DE SISTEivlAS INFOR. Recopilacion de Datos. 2003). Elmetodo GQM se lleva a cabo en las siguientes fases (van Solingen y Berghout 1999): 1. es muy importante para una organizacion que quiera implantar un proceso efectivo de medicion. 3. siempre. pennitan una automatizacion adecuada y necesaria para la evaluacion de los procesos. para 10 cual se incluyen aspectos de fonnacion. durante la cual se selecciona. que estan principalmente basados en entrevistas eSh1. EI principio basico que subyace tras el metodo GQM es que la medicion debe ser realizada.. y todas las preguntas. Durante la fase de definicion se elaboran los entregables. La fase de planificacion se lleva a cabo para satisfacer los requisitos basic os que penni tan que un programa de medicion GQM sea un exito. implicacion en la gestion y planificacion de proyectos. 2.1cturadas u otras tecnicas de adquisicion de conocimiento.5.2. durante la cual se define y documenta el programa de la medicion (objetivos. de acuerdo al marco de medicion de CMMI. Goal Question Metric (GQM) Elmetodo GQM fue originariamente definido por Basili y Weiss (1984) y extendido posteri0l111ente por Rombach (1990) como resultado de muchos afios de experiencia pnictica e investigacion academica. que proporcionan respuestas a las preguntas definidas. En la fase de definicion se identifica un objetivo. Planificacion.J'vlATICOS La importancia de la medicion en el modelo CMMI tambien se ve claramente reflejada en su incorporacion a varias pnicticas generic as tal y como se puede apreciar en la tabla 9.

rellenan y almacenan en una base de datos una serie de fonnularios en los que se obtienen todos los datos de las mediciones. Cuando se han cOl11pletado todas las actividades de la medicion. 1999) A continuacion se describen con mayor detalle las cuatro fases de GQM. Durante la fase de recopilacion de datos se definen.1. en que se incluyen los documentos. PLAl'TIFICACION Los objetivos principales de esta fase son la recopilacion de toda la infol1nacion necesaria para un inicio exitoso del proyecto de medicion. la l11edicion real puede COl11enzar. as! como la motivacion y preparacion de los miembros de la organizacion p"ara llevar a cabo el programa de medicion. y las respuestas son usadas de nuevo para ver si se han logrado los objetivos planteados.C.5. EI Proceso GQM (van So ligen y Berghout. El plan proporciona la base para el fomento y aceptacion del programa de medici on por paIte de la directiva. EI plan del proyecto constituye el principal entregable de esta fase. En much as ocasiones. calendarios y objetivos del progral11a de l11edicion. Las etapas que componen la fase de planificacion son: 1. por 10 que se requiere un equipo GQM que deberia tener las siguientes cualidades: ser independiente de los . que es una etapa fundamental ante la necesidad de garantizar la continuidad de los programas de medici on.-\PiTULO 9: ivlEDICION DE SISTEvlAS DE INFOIUvlACION 215 l11etlicas y expectativas (hipotesis) de las l11ediciones. as! como un plan de fonnacion de los desalTolladores implicados en el programa. cuando los plazos de entrega de los productos estim cerca se dedica menos atencion a las actividades del programa de medicion.2. 2. durante la fase de interpretacion. las mediciones son utilizadas para responder a las preguntas fonnuladas. Pregunta Metrica Plan del Proyecto Respuesta Medicion Definicion Interpretacion Datos Recopilados Planificacion Recopilacion de Datos Figura 9. Establecer el equipo GQM. Finall11ente. procedimientos.

ya que son ellos los que van a realizar las actividades de medicion. que da sopOlte a las actividades de medicion. . Una vez seleccionada un area adecuada. Como resultado se obtiene el plan del proyecto que deberia contener los siguientes elementos: a.mcion de los objetivos de negocio. que presenta de fOlma resumida (en 20 line as aproximadamente) el programa de medici on. "coach" que es experto en GQM e ingeniero de soporte (support engineer). El exito de un programa de medicion depende fundamental mente de la voluntad. tiempo. leyes. procesos y productos: y el conocimiento y experiencia previa en medici on que tienen las personas que van a participar en el proyecto. areas a mejorar identificadas tras una valoracion de procesos 0 areas de mejora de productos en base a objetivos de negocio de alto nivel. Esta seleccion debe realizarse en fi. y en especial en relacion a los costes. Reslimen de fa Gestion. respetar a los miembros del proyecto cuando llevan a cabo las tareas del proyecto y reconocer que son ellos los que llevan a cabo las acciones de medicion y mejora: tener una mentalidad de Olientacion a la mejora. riesgos y calidad. 3. incluso sobre si mismos: ser entusiastas para motivar a los miembros del proyecto. Seleccionar el proyecto de aplicacion y establecer un equipo del proyecto. que es el responsable de dar continuidad en to do momento del programa de medicion.216 C\UDAD DE SISTE\L-\S ["iFOR\L'\TICOS E RA-\IA equipos del proyecto y no tener especial interes en los resultados de la medicion: poseer suficiente conocimiento previo sobre los objetos de la medicion.lerzo para alinear los objetivos de la medicion con las ideas de mejora del equipo del proyecto. el equipo GQM deberia considerar todos los detalles. Las principales actividades del equipo de GQM son: planificar los programas de medicion en el contexto de los proyectos de desanollo: realizar las actividades de definicion de la medicion y desanollar los entregables QGM: comprobar los datos recogidos por el equipo del proyecto y los datos disponibles del proceso: preparar la interpretacion de los datos de la medicion e: infol111ar sobre el progreso del equipo de proyecto y de gestion y comunicar los resultados. el equipo GQM debe hacer un esfi. 4. actividad que se realiza una vez se ha establecido el equipo del proyecto y se han seleccionado las areas de mejora. como: los problemas que podIian oCUITir: influencias extel11as como las personas implicadas. Crear el plan del proyecto. en la que se seleccionan las posibles areas de mejora de los productos 0 procesos. Los roles del equipo GQM son: gestor (manager). J Seleccionar las areas de mejora. motivacion y entusiasmo de los miembros del equipo de proyecto. tecnologias. Para ello deben controlar y estimular continuamente la dedicacion del equipo del proyecto a las actividades de medici on. como podrian ser: problemas evidentes a los que se enfrenta la organizacion. Por ello.

en la que el equipo GQM debelia organizar sesiones frecuentes de fonnacion y promocion en las que se presenten de fOl1na clara los objetivos de medicion propuestos. proceso. EI proposito define cmil es la intencion del experimento. procedimientos de generacion de infol1nes de gestion asi como actividades de conh'ol de nesgos. El enfoque de la calidad es el efecto principal que se estudia en el experimento. f. que describe las eshl1cturas organizacionales. que contiene pliOlidades. que presenta el alcance del programa de medicion. Forlllacioll y promocion. Como resultado se obtiene una definicion f0l111al y bien estmcturada de los objetivos. para 10 cual se utilizan plantillas como la que se muesh'a en la tabla 9. Formacion y promocion. teolia. para 10 que se consideran los objetivos de mejora del plan del proyecto definidos en la fase anterior. 2. los beneficios del programa de medicion.Q RA-ylA CAPiTULO 9: :"lEDICIO?\. mehica. DE SISTEylAS DE IMOR. la cual puede ser producto. 5.2. asignaciones de recursos y amilisis coste-beneficio del programa de medicion. etc. de medicion y de amilisis. recurso. El objetivo es motivar y f0l111ar a los miembros del equipo del proyecto en la realizacion del programa de medicion. modelo. Definir los objetivos de la medicion. • I> . c. que incluye la planificacion temporaL entregables. Las etapas de la fase de definicion son: I. asi como la relacion entre los objetivos de la mejora y los objetivos del proyecto de desalTollo de software. que presenta el plan para la f0l111acion de los miembros del equipo del proyecto y la comunicacion de los resultados en la organizacion. el impacto del programa de medici on en las actividades diarias del equipo de proyecto y las experiencias en otros proyectos u organizaciones. donde los elementos de la plantilla son los siguientes: I> El objeto del estudio es la entidad que se estudia en el experimento. del proyecto y equipo GQM que son relevantes en el programa de medicion.2. d. Procesos de gestion.2. Organi:::acioll. DEFINICION En esta fase se incluyen las actividades necesarias para definir fOl1nalmente el programa de medicion y como resultado se obtienen los planes GQM. Introduccion. e. Calendario.vlACION 217 b.

Revisar 0 producir los modelos de proceso software. ELCO)l. Gque factores extern os pueden il?jluenciar las metricas J de que modo? Definir preguntas e hipotesis. Estos modelos de procesos deben dar soporte a la definicion de las mediciones. 0 mejorar el objeto el enfoque de caUdad del objeto en el que se centra la medici6n o perspectiva de las personas que miden el objeto el entorno en el que la medici6n tiene lugar Tabla 9.. Realizar entrevistas GQM. EI contexto es el "entomo" en el que se lleva a cabo el experimento. las respuestas esperadas son fOl1nuladas como hipotesis que son comparadas en la fase de interpretacion con los resultados reales de la medicion. 3.NTO DE\'1STADE E)I. controlar. Para cada pregunta. . de fODna que los miembros del equipo GQM puedan extraer de los miembros del equipo del proyecto toda la informacion relevante en relacion a los objetivos de la medicion.. DESDE EL P:L. en base. tales como: GCl/ales son las metricas para medir el objeto asociado a lin determinado objetivo. Con la respuesta a las pregllntas planteadas. se deberia poder concluir si se cumple un detel1ninado objetivo.TE. de acuerdo a los miembros del proyecto?. para asegurar que se han fODnulado las preguntas e hipotesis COlTectas.R e CON EL PROPOSlTO DE CON RESPECTO A .UO DE el ob. 1994) 2. Las hojas de abstraccion incluyen los aspectos basicos a considerar en las entrevistas GQM. EI contexto define brevemente el personal (sujetos) implicado y los artefactos software (objetos) que se utilizan en el expelimento.'I.. Revisar preguntas e hipotesis. 5. a los objetivos de la medicion de f0l111a que se de soporte a la interpretacion de los datos. .218 CAUDAD DE SISTEMAS INFOR.ieto de estudio bajo medici6n entender. Gcual es el conocimiento actual del miembro del proyecto respecto a estas metricas?. los modelos de procesos deb en ser definidos por el equipo GQM y aprobados por el equipo del proyecto. estos deben ser revisados y si es necesario mejorados. 4. Para ello se realizan entrevistas individuales en las que para facilitar la comunicacion se puede hacer uso de las hojas de abstraccion ("abstraction sheets "). ANALlZ.2. las preguntas constituyen un refinamiento de los objetivos a un nivel mas operacional.. De la misma f0l111a que los objetivos se definen a un alto nivel de abstraccion. PlantiIIa de Definicion de GQM (Basili et al. Si no existen. Si existen previamente en la organizacion.vL~TICOS e La perspectiva nos define el punto de vista desde el cual se van a interpretar los resultados del experimento.

!'vIACION 219 6.). Comprobar consistencia y completitud de las metric as.6. Interpretacion Objetivo .~RA-MA CAPiTULO 9: . as! como gn'ificos y tab las en relacion a los objetivos y preguntas planteadas. preguntas. ingeniero. EI plan de amilisis pretende basicamente describir como la infonnacion relevante de la medicion debe ser procesada con el fin de que pueda ser interpretada fikilmente por el equipo del proyecto. que deben adelmis ser aprobados por el equipo del proyecto antes de que comience la obtencion de los datos reales de las mediciones. Sirve como guia para la interpretacion de los datos y para el desalTollo del plan de medicion y amllisis. 9. Tambien se inc1uye el momento de tiempo en el que se debe tomar el valor de cada metlica directa y el medio (helTamienta 0 fonnulario) que la persona encargada debe usar. Producir el plan de amilisis. Definir las metricas. de fonna que la definicion de los objetivos preguntas y metricas sea consistentes y completa con respecto al objeto sujeto a medici on. Revisar los planes. gestor del proyecto. Producir el plan GQM. Para ello se presentan simulaciones de los resultados de las mehicas."!EDICION DE SISTEMAS DE INFOR. en el que se inc1uye la definicion f0l111al. II. que es un documento en el que se simula la interpretacion de los datos de acuerdo al plan GQM. 10. metlicas e hipotesis de un detenninado programa de medicion. 7. descripcion textual y todos los resultados 0 valores posibles de las metlicas directas asi como la persona responsable de recoger dichos valores (programador. Modelos Implicitos Preguntas Definicion Figura 9. Las metlicas deben proporcionar la infonnacion cuantitativa que pel111ita responder las preguntas planteadas de una fonna satisfactoria. 8. Producir el plan de medici6n. las metlicas son el refinamiento de las preguntas en mediciones de los productos 0 procesos. etc. Por 10 tanto. en el que se inc1uyen los objetivos. Fase de Definicion de GQM (Basili y Weis. 1984) .

presentacion y empaquetamiento de los datos de medicion. Este sistema constituye un elemento esencial del programa de medicion siendo su base un conjunto de hen-amientas generic as tales como hojas de calculo. c. aplicaciones de bases de datos y hen-amientas de presentacion. Las principales etapas que componen esta fase son: l. una vez se han completado todas las actividades de definicion. El principal objetivo es llegar a un acuerdo con el equipo del proyecto para el cOl11ienzo de la recogida de datos de la medicion y se instruye a sus miembros en los procedimientos de recogida de datos. Sesion de Inicio (Kick ofj). El sistema MSS esta fonnado por tres partes basicas: ~vstem. 2. b. estableciendo la base de metric as para el posterior establecimiento del sistema de soporte a la medicion. helTamientas estadisticas. Recogida de Datos. que incluye: a. la definicion de metricas con el metodo GQM se realiza mediante una aproximacion atTiba-abajo (figura 9. preferiblemente de f0l111a diaria. Construccion del sistema de soporte a la medicion (lvieaslirement Support MSS). durante la que todos los participantes en el programa de l11edicion deben estar presentes.2.3. El sistema MSS debe dar soporte a todas las actividades de medicion. durante la que se rellenan los fonnulatios y se entregan al equipo GQM de manera frecuente. Como resultado se obtienen una serie de fonnulatios cumplimentados y almacenados en una base de datos. El equipo GQM comprueba la consistencia y con-eccion y almacena los fonnularios.['A TICOS En resumen. procesamiento. RECOPILACION DE DATOS Esta fase se inicia. Esta actividad suele llevarse a cabo por dos personas como maximo (una al menos es preferible que sea un ingeniero senior) durante uno 0 dos dias y el principal objetivo es evitar en'ores y detectar posibles mejoras a realizar en los procedimientos. Periodo de Entrenamiento (Hold Trial).6) en tres niveles: el nivel conceptual en el que se definen los objetivos (goal). el nivel operacional en el que se definen las preguntas (question) y el nivel cuantitativo en el que se definen las metricas (metric). almacenamiento.220 CAUDAD DE SISTD!AS IMOR". . 2. en las que se incluyen la obtencion. helTal11ientas 0 fOl11mlarios. Formacion y arranque de la obtencion de datos. hen-amientas y fonnulatios. Este periodo de pmeba es llevado a cabo antes de comenzar la toma real de datos y durante el mismo se definen y prueban los procedimientos de recogida de datos asi como las hen-amientas y fonnularios.

Hojas de Analisis M55. que son los distintos tipos de presentaci6n de los datos obtenidos respecto a diferentes niveles de abstracci6n. Durante estas reuniones se deben debatir los resultados de la medici6n y se suelen celebrar cada seis u ocho semanas con una duraci6n tipica de una hora y media ados horas. Para ella se centran en: evaluar puntos de acci6n de sesiones previas: analizar e interpretar los datos recogidos en la medici6n respecto a los objetivos y preguntas del plan GQM y obtener conclusiones y traducir estas conclusiones en acciones concretas.-. conclusiones y puntos de acci6n relevantes formulados. capa de datos procesados y capa de gn'ificos y diagramas. material adicional. Cada hoja de analisis debe incluir: la descripci6n del objetivo y todas las preguntas derivadas del mismo (como en el plan GQM). Las etapas incluidas en esta fase son: I. Para ella los miembros del equipo del proyecto deben adoptar un enfoque constructivo y dirigido por objetivos. como: hojas de analisis. etc. INTERPRETACION La fase de interpretaci6n utiliza los datos tomados en la medici6n para responder las preguntas planteadas y de esta fOll11a. que contiene los datos recabados. EI material de realimentaci6n deberia ser util para los miembros del equipo del proyecto durante estas sesiones. Durante estas reuniones el equipo del proyecto. 221 a.2.1\.-. como expertos en el objeto bajo medici6n. Al final de cada sesi6n de realimentaci6n el equipo GQM escribe un informe en el que se incluyen todas las observaciones. todos los datos necesmios para responder las preguntas planteadas de una fOll11a satisfactoria con respecto a los objetivos e hip6tesis. Sesiones de Realimentacion. c. b. Este infolll1e es distribuido a los miembros del equipo del proyecto. en la que los miembros del equipo GQM deberia preparar todo el material necesario. . DE SISTE\IAS DE IMOR\l:\CIO. 2."'. para identificar si se alcanzan 0 no los objetivos. Preparacion de las sesiones de realimentacion. Generacion de informes de interpretacion de los resultados de la medicion. que en orden ascendente son: capa de datos sin procesar. que son las transparencias de presentaci6n que son mantenidas de fOll11a que cualquier cambio de las hojas de analisis produzca su actualizaci6n inmediata. 2. Transparencias de Analisis ivJ55. deben analizar los resultados y obtener conclusiones y acciones a realizar. diapositivas de presentaci6n. 3.4. Base de Merricas lvf55. inteq)!'etaciones.-\1:\ C'.PiTCLO 9: \IEDICIO.

EJEMPLO DE APLICACION DE GQM Como ejemplo de definici6n de metric as utilizando el metodo GQM se va a describir la propuesta de metricas de Calero (2001) para evaluar la mantenibilidad de bases de datos relacionales. 2001) Para satisfacer el objetivo anterior se definen las siguientes preguntas: . I . Sin embargo.5.4.2.1 I I 1 BD Relacionales ase!Wrar la mantenibilidad los disefiadores de BD desarrollo y mantenimiento de BD 1 1 I 1 1 Tabla 9. EI factor fundamental del exito de un programa de medici6n es el logro de los objetivos planteados.222 CAUDAD DE SISTEMAS INFOIUvlA. Beneficios y Costes Potenciales de los Pl-ogramas GQM 2. El objetivo de acuerdo a GQM seria el que se muestra en la tabla 9.3 se muestran costes y beneficios asociados a los programas de medici6n. Ejemplo de Aplicacion de GQM (Calero. Amilisis de costes y beneficios de un programa de medicion. CON EL PRopoSnODE CON RESPECTOA DESDE ELPliNTODE VlSTA DE EXELCONTEXTO DE .4. Ac"iALlZAR. En la tabla 9.. es necesario incluir tambien en el infonne final un amilisis de costes/beneficios. TICOS :9RA-MA 4. COSrES BENEFICroS Tiempo empleado por el equipo GQM en preparar un programa de medici6n (salario y gastos generales) Tiempo empleado por el equipo del proyecto en reuniones Ventas adicionales derivadas de la mejora de cali dad Evitar decrecimiento en ventas debido a la mejora de cali dad Tiempo empleado por el equipo del proyecto en cumplimentar fonnularios Ahorro de tiempo y esfuerzo en el desarrollo de software debido a un mejor entendimiento de los procesos de desarrollo Ahorro de tiempo debido a una mejor gesti6n de los recurs os Tiempo empleado para desarrollar el MSS Compra de hardware y software adicional para dar soporte al programa de medici6n Tiempo empleado por el equipo GQM para procesar los datos de la medici6n y preparar las sesiones de realimentaci6n Evitar costes debido a una mejor gesti6n de recursos Tabla 9.3.

Ratio De Claves Ajenas De Una Tabla (RFK(T)). 2. definida como el porcentaje de atlibutos de la tabla T que son claves ajenas (ver figura 9.RA.-MA CAPiTULO 9: MEDICION DE SISTEMAS DE iii Pregunta 1.3.C6mo influye la complejidad entre tablas en la mantenibilidad de las bases de datos relacionales? iii Para responder a las preguntas planteadas se de fin en las siguientes metricas: iii Pregunta 1: o o o Numero De Atributos De Una Tabla (NA(T)). definida como el nlllnero total de tablas que hay en el esquema. y van Solingen y Berghout (2001) proporcionan oh'os ejemplos relevantes de aplicaci6n de GQM en la indushia. la l11ejora de sus procesos y los objetivos de sus proyectos. Lindstrom (2004). definida como el numero de atributos de una tabla T. . Metrica RFK(T) iii Pregunta 2: o o o Numero De Tablas (NT). Numero De Claves Ajenas (NFK). definida como el nlllnero total de claves ajenas que hay definidas en el. asegurando la relevancia y trazabilidad de los objetivos respecto a los datos obtenidos. GQ(I)M comparte much as similitudes con la metodologia antelionnente descrita GQM. Numero De Claves Ajenas (NFK(T)). Goal Question Indicator Metric (GQ(I)M) y Goal-Driven Software Measurement La l11etodologia GQ(I)M identifica y define mehicas software que dan soporte al negocio de la empresa.7. . (1998). definida como el nlllnero total de ahibutos que hay en el esquema. (. RFK (T) NFK (T) NA (T) Figura 9.C6mo il?fluye la complejidad de las tab las en la mantenibilidad de las bases de datos relacionales? Pregunta 2.7). Numero De Atributos (NA). definida como el numero de claves ajenas de una tabla T. esquema.. Fuggetta et al.

"que". Paso 1. Que se divide en los siguientes pasos (vease figura 9. V c""" Paso Q Paso EI Proceso v C"C"". 1998): Paso I Objetivos de Negocio Modelo Mental v )i>l. Identificacion de ObjetiYos en GQ(I)i\I (Park et at... el artefacto mas relevante de esta metodologfa es la "Plantilla de Indicadores". Entidades Enlidades "V~ Entidades y Pa~o Sub·Obielivos p 3 "v~ Atributos P'" Paso Atributos ? "V~ "v~ Atributos ? Objetivos de Medici6n 01 02 Figura 9. 1996: Zubrow... que es utilizada para definir de fonna precisa el "quien". Identijicar los objetivos de negocio. necesitare . . 1996) 1. En este primer paso se deben identificar los objetivos que dirigen los esfuerzos de la organizaci6n y puede iniciarse en cualquier nivel de la organizaci6n en el que se puedan establecer de fonna razonable dichos objetivos.8. La metodologia esta f0l111ada por diez pasos organizados en tome a h'es conjuntos generales de actividades (Park et aI.8): a.Que necesito saber? . asf como para documentar el alineamiento del mismo con los objetivos de la organizaci6n.. ''par que" y "como" de un indicador.224 CAUDAD DE SISTEMAS INFORNIATICOS salvo en el aspecto de que aiiade soporte explicito a los indicadores... EI proceso que sigue la metodologia GQ(I)M es el propuesto por el SEI en su enfoque "Goal-Driven Software Measurement" (Park et aI. Como resultado se obtiene una lista de objetivos ordenada seglll1 su prioridad. "cwindo". 2004). Por ello. "donde". Identificaci6n de ObjetiYos. Todo ella garantiza disponer de una colecci6n consistente de metricas a la hora de constmir un indicador y proporciona elementos adicionales para asegurar una interpretaci6n consistente del propio indicador (Goethelt y Siviy. Una vez identificados dichos objetivos es necesario priorizarlos..Que quiero lograr? Para hacer estc. <1 i. 1996)..

Paso 3.. que une el prop6sito y las perspectivas de los objetivos del negoclo con las posibilidades de c. Ello implica en este paso la traducci6n de los objetivos de negocio en declaraciones a nivel operacional. Una vez que se tiene una lista de preguntas es necesario identificar las entidades implicadas y sus atributos. Paso 4. En muchas ocasiones la descripci6n de los procesos de trabajo de la organizaci6n no es explicita y se encuentra m::is bien como un modelo mental en la misma. En este paso se traducen los objetiYos de negocio en objetivos de medici6n. Este paso es iterativo 10 que puede conducir al refinamiento de las cuestiones y subobjetivos a medida que se l11ejora el esbozo 0 esquema mental del proceso. Los objetivos son enlazados con el conocimiento obtenido de los procesos de negocio y estrategias de la organizaci6n.R. predecir 0 mejorar las actividades relacionadas con la consecuci6n de los objetivos. En todo caso es de gran relevancia identificar los productos de trabajo. el siguiente paso es comenzar a identificar 10 que a la organizaci6n Ie gustaria saber con el fin de entender.ar los objetivos de negocio. d. Para ello se fonnulan preguntas tales como "(:QlII? aetividades tengo que gestionar 0 reali::ar?" y se completan sentencias del tipo "Para !weer esto. Este paso cOl11ienza seleccionando las prt3guntas que se consideran relevantes y que sue len estar asociadas con los subobjetivos de mayor prioridad. Paso 5. Las preguntas relacionadas con los objetivos planteados son estmcturadas en fonna de entidades (productos de trabajo 0 actividades) y ahibutos (tamafio. Se obtienen analizando las similitudes y aspectos comunes de las preguntas planteadas sobre las entidades.. Una vez identificados los objetivos de negocio. neeesitare. actividades y otras entidades que puedan ofrecer oportunidades de mejora. Esto pennite establecer un conjunto bien definido de objetivos de negocio que son utilizados para el ananque del proceso GQ(I)M propial11ente dicho. La cuantificaci6n de estos atributos debe pel111itir obtener respuestas a las preguntas planteadas. Ello pem1ite identificar mas claramente la relaci6n entre los resultados obtenidos (respuestas a las preguntas) y los objetivos.". e. agrupando las mismas en funci6n de los aspectos que h'atan de resolver. En este paso se utilizan las preguntas para refinar el modelo mental del proceso y sus entidades y atributos asociados. esfuerzo 0 calidad) asociados con los procesos de la organizaci6n. Los subobjetivos proporcionan un refinamiento a nivel operacional de los objetivos generales. ldelltijicar los subobjetivos.-\-?v1:\ CAPiTLLO 9: \IEDICI00i DE SISTE\IAS DE 10iFORMACI00i 225 b. Identijicar 10 que se quiere co/weer 0 aprender. Paso 2.. FOl'lJIa/i. yalorar. Identijicar las entidades y atriblltos relacionados COil los sllbobjetivos. .

las tecnicas de "Valor Anadido" (earned vallie) 0 los diagramas de Gantt penniten construir buenos indicadores de este tipo. Otro aspecto impOltante para facilitar a las organizaciones entender claramente si han alcanzado sus objetivos es distinguir los tipos de indicadores que se pueden definir. EI proposito de la medici on puede ser: entender. En este sentido es muy uti 1 el uso de plantillas que faciliten la definicion de indicadores.1 se describe la plantilla de definicion de indicadores de la metodologia GQ(I)M. La perspectiva identifica qui en 0 quienes son los interesados en los resultados de la medicion.lisis de las salidas producidas por las tareas. Estos indicadores se utilizan para realizar el seguimiento del progreso en la ejecucion de las tareas definidas. A la hora de disenar un indicador hay que considerar aspectos tales como la frecuencia de toma de datos. el tiempo requerido para generar el indicador. la necesidad de datos historicos. el objetivo de medicion expresa los factores del entomo que es impOltante en tender por todos aqu~llos encargados del diseno y realizacion de las actividades de medicion y amilisis.3. Para estar bien estructurados los objetivos de medicion deben incluir: el objeto de interes (entidad). la perspectiva y una de scrip cion del entomo y restricciones. La infom1acion del contexto 0 entomo ayuda en la interpretacion de los resultados de la medicion. En este paso se identifican las preguntas e indicadores a partir de cada uno de los objetivos de medicion planteados. AdetTI<ls. Definicion de Indicadores. controlar.226 CAUDAD DE SISTENIAS INFOIUvL-I. Que se compone de: a. predecir. 2. planificar. • lndicadores de alllilisis. comparar. POI' ejemplo. Este tipo de indicadores es utilizado para ayudar en el an3. En el apattado 2. valorar 0 mejorar algll11 aspecto de calidad 0 productividad del objeto 0 entidad. Paso 6. etc.TIC OS medicion que existen en la organizacion de acuerdo a sus procesos de trabajo. Goethert y Saviy (2004) distinguen tres tipos de indicadores: • lndicadores de progreso. . el proposito. El cumplimiento de los val ores de este tipo de indicador significani que la ejecucion de las tare as se esta lievando a cabo con exito pero no garantiza la consecucion de los objetivos de negocio aunque un falio en este indicador puede significar un problema impottante para conseguir dichos objetivos. Los indicadores representan los productos obtenidos en las actividades de medicion y son utilizados por los directores de proyectos y profesionales como fuente de infonnacion de sopOlte para la toma de decisiones. Idelltijicar preguntas cllalltijicables y los illdicadol'es I'elacionados.

Objetivos de Medici6n 01 02 <& Objetivos :'\cgocio. PlantilIu de Definicion de Indicadorcs (Ji'I:. ('. Para facilitar una definicion no ambigua de las metric as el SEI ha propuesto una serie de marcos de tr·abajo de la medici on con listas de comprobacion para metricas que evalilan atributos como el tamafio. esfuerzo.(1 P:<!fl. 9. Goethert..\Ictricas Definfciones .. Identificar los elementos de datos.-'fEDICION DE SISTEMAS DE INFORJvL\CION 227 Un indicador que representa el nillnero y tipo de defectos detectado en cada fase del desarrollo es un ejemplo de este tipo de indicadores.::i.-MA CAPiTULO 9: . En esta etapa se identifican estos elementos 10 que significa que no es necesario aim que se definan las metricas.Informes de Problemas Figura 9. 1992). Una vez identificados los elementos de datos hay que definir las metricas necesarias que perrnitan obtener respuesta a las preguntas planteadas. Definir las metricas.EsfuerLo . Definicion de Indicadores en GQ(I)M (Adaptado de Goethert y Siviy. En la figura 9. V )( SLoe ..Que quiera suber 0 aprcndcr'! 13 14 lndicadorcs 1! . 1992. 2004 y Park et al. Paso 8. Florac. 1996) 3. Crear un plan de accion. Preguntas P1 P2 P2 Prcguntas Paso <\ . 9 se muestra el esquema general para la definicion de indicadores. b. consecucion de hitos y defectos (Park.SubObjcti\"os . Los indicadores reflejan los elementos de datos que son necesarios.\ledici6n Paso . MtHricas -e M1 » M2 M3 Paso Listas de Comprobaci6n Definicion de .R. tarea que se realiza en el siguiente paso. 1992. Paso 7. compuesto por los siguientes pasos: ./\.::l''::'~ »A 11 Indicadores 12 ~ . c. La definicion de las metricas es un paso clave para obtener una interpretacion adecuada de los datos recogidos y debe realizarse teniendo en mente el proposito del indicador o indicadores.

La plantilla de un indicador se utiliza para documentar de for111a precisa un indicador. Por ella para cada elemento de datos se debe detel111inar su estado respecto de si existe una explicita definicion de una metrica para dicho elemento de datos. Paso 10. fOl11mlarios 0 incluso fonl1acion para obtener los datos.IAS !?\FOR:VI. Tambien ayuda para asegurar la recopilacion consistente de las metricas necesarias para obtener el indicador asi como los criterios necesarios para la interpretacion de las metricas obtenidas. Para la definicion de un indicador la plantilla incluye los siguientes campos: e ObjetiYo del indicador: el objetivo 0 proposito del indicador. Una vez que se ha realizado el analisis necesario y se conocen los datos requeridos y las actividades de medicion a llevar a cabo para obtenerlos es el momenta de definir el plan en el que se incluyan las acciones concretas a llevar a cabo para satisfacer las necesidades de infor111acion planteadas. En este aspecto se considera si son necesarias nuevas helTamientas. sistemas de seguimiento de defectos. . Ahora es el momento de analizar la situacion actual en la organizacion con respecto a las necesidades de infonl1acion planteadas. si hay helTamientas de soporte. etc.TICOS a. de generacion de infonnes de esfuerzo. Es necesario identificar las fuentes de informacion existentes en 11 organizacion ya que los elementos de datos requeridos podrian encontrarse en una gran diversidad de fuentes que incluyen planes de proyectos. Del mismo modo. Para ella es impor1ante disponer de una plantilla para su definicion y de una guia que facilite la utilizacion de la misma. si hay fOl11mlarios y procedimientos para recoger y registrar los datos. Paso 9. 2. hay que hacer un amilisis de los datos que son necesarios y no estan disponibles en la organizacion en el que se valore la cantidad de esfherzo que requiere su obtencion. Identificar las acciolles a implementm: Hasta el momento ya se dispone de la definicion de los indicadores y metricas que pueden dar respuesta a las preguntas planteadas en funcion de los objetivos de negocio. PLAl~TILLA PARA LA DEFINICION DE INDICADORES La plantilla para la definicion de indicadores constituye el artetacto claw de la metodologia GQ(I)M. de gestion de configuracion. si se han detenninado los puntos en el proceso en el que se realizaran las medici ones y su frecuencia. En este paso tambien se deben pliorizar los datos respecto a los indicadores de los que dependen. Las organizaciones frectlentemente no obtienen los beneficios potenciales de un buen programa de medicion debido a las inconsistencias en la construccion e interpretacion de los indicadores deri\'ados de los datos de la medicion.1. etc.A.3.228 CAUDAD DE S!STE'. tal y como proponen Goethel1 y Siviy (2004). b. quien tomara dichos datos: como se analizaran. Preparar lIll plan de accion. asi como la fonna de obtenerlo y de interpretarlo y presentarlo COlTectamente.

(!) (!) (!) (!) (!) (!) (!) (!) Las organizaciones pueden adaptar la estructura de esta plantilla a sus entomos particulares ya que la plantilla propuesta par el SEI incluye los campos que se consideran COl11unes para la definicion de indicadores. . modelo de ciclo de vida. etc. Informacion de toma de datos: en la que se indica como.. Entradas: la lista y definiciones de las metricas requeridas para constmir el indicador. C-'. et al. Las practicas y principios que prop one se han llevado a cabo con exito en multitud de proyectos software. y todos aquellos datos que sean impOltantes para obtener y usar el indicador.. cuando. No se trata de una aproximacion general. quienes. 2.PiTlJLO 9: ~lEDICIOl\ DE SISTE~IAS DE Il\FOR?v1ACIOl\ 229 (!) Preguntas: la lista de preguntas que el usuario del indicador intenta responder con su definicion. 2002) se basa en la experiencia obtenida por docenas de organizaciones para saber cual es la mejor manera de il11plementar un programa de medida de software con garantias de exito. la descripcion de la audiencia de interes para la que se ha definido el indicador.RA-M. es decir. relll1en los elementos de datos requelidos en la construccion del indicador. con que frecuencia. Suposiciones: la lista de suposiciones sobre la organizaclon. Representacion Gnifica del indicador. Amilisis e Interpretacion de los resultados: infonnacion sobre como analizar e interpretar el indicador.4. Perspectiva 0 punto de vista. Algunos ejemplos de aplicacion de la plantilla de indicadores pueden consultarse en Goethert y Siviy (2004). recuperacion y segUlidad de los datos. sino que incluye !ineas guia para ajustar los marcos de trabajo de la medida y las practicas a la situacion de cada proyecto en cada orgallizacion.. Informacion de generacion de informes de datos: infonnacion sobre qui en es responsable para generar los infonnes de los datos. Practical Software Measurement (PSM) La l11etodologia PSM (Practical Sofhmre Measurement) (McGan). para quienes y la frecuencia de almacenamiento. Algoritmos: la descripcion del algoritmo usado para constmir el indicador a partir de las metticas definidas. sus procesos.-'.

y 10 que es m:ls importante.. Esta actividad inc1uye identificar que necesitan saber los beneficiarios de la medici6n (encargados de la toma de decisiones)... Planificacion de la Medicion. relacionar las necesidades de infonnaci6n con las entidades que pueden ser medidas y seleccionar y especificar meh"icas basadas en los proyectos y en los procesos organizacionales. Esta actividad implica establecer los recursos. fonnaci6n y henamientas necesarias para implementar un programa de medici6n de fonna efectiva.230 CAUDAD DE SISTEvlAS INFO~'vLA.. asegurar que hay una gesti6n que usa la infonnaci6n producida. Planificar el . proceso .10) que se divide en cuatro actividades principales: I. Realizar las mediciones Nuevas Tareas Acciones de Mejora Analisis de Resultados y de la Realizacion de la Medida Evaluaci6n ~ Ambito de PSM Figura 9.TICOS PSM prop one un Modelo de Procesos de Medida (figura 9. 4. 3. En esta actividad tanto el proceso de medici6n como las propias mehicas definidas deben evaluarse y mejorarse peri6dicamente segll11 sea necesano. Evaluacion de la Medida.. Realimentacion de los usuarios PROCESOS TECNICOS Y DE GESTION Objetivos y Tareas Analisis de Resultados Establecer y Mantener el compromiso de medici6n .. Modelo de Procesos de Medicion de PSM .. En esta actividad se definen las mehicas necesarias que proporcionen la visibilidad en los proyectos necesaria para satisfacer las necesidades de infom1aci6n. Plan de Medida . Establecimiento y mantenimiento del Compromiso. Realizacion de la Medicion.. Esta actividad implica reunir los datos de las mediciones. 2. realizar el amilisis y presentar los resultados para que la infonnaci6n pueda ser util para la toma de decisiones..10.

Para ella PSM incorpora un modelo de infonnacion de la medicion que relaciona las entidades que son medidas con las medidas definidas y en ultima instancia con las necesidades de infonnacion que se satisfacen.Producto de Informacion Figura 9. pues.': RA. .\. La relacion que establece un constr1. Y ambos se han convertido en la referencia para la industria proporcionando ademas un lenguaje COmlll1 que facilita la comunicacion en el ambito de la medicion software.fIi>. Este modelo incorpora una estructura denominada constructor de la medicion que describe como los atributos relevantes de los productos y procesos se cuantifican y se convierten en indicadores..11. Metodologia para Metricas de Calidad del Software Seglll1 este estandar (IEEE. IEEE Std 1061-1998. Relacion entre necesidades de informacion y atributos En definitiva. medidas derivadas e indicadores. PSM proporciona un metodo sistematico para la planificacion y realizacion del proceso de medicion y analisis.'vIACION 231 Un aspecto basico para disponer de programas de medicion efectivos es el hecho de disponer. 1998b) la calidad del software se puede considerar como el grado en el que el software posee una combinacion cIaramente definida y deseable de atIibutos de calidad. Constiulye la referencia en la que se basa el estandar intemacional ISOIIEC 15939. aunque sin que ella elimine la necesidad de un juicio humano en las evaluaciones de software. El proposito de las metIicas del software es hacer evaluaciones a traves del cicIo de vida del software para comprobar si los requisitos de calidad del software se estan cumpliendo.1ctor de la medicion entre 10 que se mide y la necesidad de infonnacion que se tiene (que se satisface con un producto de informacion) se representa en la figura 9.11. 2.. trata de definir la calidad del software para un sistema mediante una lista de atributos de calidad del software requeridos por el propio sistema. al final del proceso.-MA CAPiTULO 9: MEDICION DE SISTElvl""S DE INTOR. que son elementos que proporcionan la base necesaria para la toma de decisiones.. de infom1acion (itil para los encargados de la toma de decisiones.5..... Constructor de Medicion Medida Base Medida Derivada Atributo Indicador . Todo constructor de la medicion implica tr'es niveles de medida: medidas base. Este estandar..

Nonnalizar. Evaluar el nivel de calidad logr'ado frente a los requisitos establecidos. Establecer requisitos de calidad para un sistema en su inicio. I) Predecir el nivel de calidad que se lograra en el futuro. calibrar 0 validar una metrica.12 se muestra el marco de trabajo para las metl1cas de calidad de sofuvare. CaUdad del Software de un Sistema Factor \!etrica Figura 9. I) I) En la figura 9. implementar. analizar y validar el proceso y los productos de calidad del sofuvare. Es un marco disei'iado para ser flexible y aplicable a todos los sistemas. adaptandose a cada caso concreto sin cambiar los conceptos basicos. escalar. Esta metodologia consta de los pasos que se detaIl an a continuaci6n: . Establecer criterios de aceptaci6n y estandares.12. Detectar anomalias 0 I) I) I) I) problemas en el sistema.232 CAUDAD DE SISTE\L-\S I~FORlvL'\ TICOS EI uso de esta metodologia pennite a una organizaci6n: I) Lograr sus objetivos de cali dad. Evaluar la facilidad de cambio en el sistema durante la evoluci6n del producto. Marco de trabajo para metricas de calidad de software en IEEE 1061-1998 EI estandar IEEE 1061-1998 propone una metodologia con el fin de establecer los requisitos de calidad e identificar.

Interpretar los resultados. c. 2. d. Paso compuesto por: a. Uso de criterios de yalidaci6n. Requisitos adicionales. 4. Adquirir un compromiso con el conjunto de metlicas. d. b. b. Validacion de las iVIetricas de CaUdad del Software. Procedimiento de yalidaci6n. . b. Realizar un prototipo del proceso de medici6n. c. Identificacion de las iVIetricas de Calidad del Software. Analisis de los Resultados de las iVIetricas del Software. Para 10 cllal se realizan las siguientes acciones: a. Agrupar los datos y calcular los val ores de las metlicas. RA-'\IA (APiTCLO 9: \IE01(I00: DE SISTE:VIAS DE INFO~'vL-\(IO]\ 233 I. Definici6n de los procedimientos de la colecci6n de datos. Identificar la calidad del sofuvare. Propuesta de validaci6n de las metricas. Garantizar la confonnidad con los requisitos. Realizar un amllisis coste-beneficio. e. b. 3. Las acciones a realizar en este paso son: a. Aplicar el marco de trabajo de las metricas de calidad del software. c.{. c. Identificar los beneficios al aplicar las metIicas. Identificar los costes de la implementaci6n de las metlicas. Ajustar el conjunto de metlicas. d. f. Implementacion de las iVIetricas de Calidad del Software. Para ella es necesano: a. Hacer predicciones de la calidad del sofuvare.

234 CAUDAD DE SISTEMAS IN"FOR. Se recopilan. aplicar y mejorar de manera exitosa la medicion de software dentro de un proyecto general 0 de la eShl. Se identifica yio define un conjunto apropiado de medidas en funcion de las necesidades de infonnacion. Uso de critelios de validacion. Se usan productos de infonnacion para apoyar las decisiones y proporcionar una base objetiva para la comunicacion. d. Propuesta de validacion de las mehicas. Como resultado de esta implementacion: o Se establece y mantiene un acuerdo dentro de la organizacion a la hora de medir. Tambien proporciona las definiciones de los tenninos de uso comlll1 relativos a la medicion dentro de la indush-ia del software. definir.6. Para 10 cual se realizan las siguientes acciones: a.: 5. b. 2. 2002c) identifica las actividades y tare as necesarias para identificar. c. Validaci6n de las Metricas de Calidad del Software. o o o o o o o . De acuerdo a este estandar. Se eva III an el proceso de la medida y las propias medidas. seleccionar. para ayudar a una gestion efectiva de los procesos y demostrar objetivamente la calidad de los productos. Las mejoras se comunican al responsable del proceso de medicion. ISOIIEe 15939 Este estandar intemacional (ISO. Se identifican las actividades de la medici on.cvlA TICOS :£. Requisitos adicionales. el principal objetivo del proceso de medicion del software es reunir. almacenan y analizan los datos necesarios y se interpretan los resultados. Se identifican las necesidades de informacion de los procesos tecnicos y de gestion. Procedimiento de validacion.lctura de medicion de una empresa. analizar y proporcionar datos relativos a los productos desalTollados y a los procesos implementados dentro de una organizacion.

Son las actividades que indican principalmente la implicacion del usuario de la medicion. Las otras dos actividades proporcionan la base del nllcleo del proceso y realimentacion para el propio mkleo e involucran mas al propietario del proceso. para cada necesidad de infonnacion. Una tarea es un segmento de trabajo bien definido. Requerimientos de t. el nllcleo proporciona un producto de infonllacion que la satisfaga y este se comunica a la organizacion para que sirva como base en la toma de decisiones.13.~ RA-\1A CAPiTULO 9: \[EDICION DE SISTE. este estandar define las actividades y tareas necesmias para implementar un proceso de medicion de software.VIAS DE INFORl'vlACION 235 Tal y como ya se ha comentado. .cos y de Gest. Los Procesos Tecn.13. Una actividad es un conjunto de tareas relacionadas que contribuyen a alcanzar el objetivo y los resultados del proceso de medicion de software. Lo que este estandar no especifica es como realizar cada una de las tare as que componen cada actividad. El proceso de medicion de software propuesto en el estandar se compone de cuah'o actividades principales (figura 9.1edidas <I Base de experiencias de Medic<6n Productos Informativos }' Resultados de eva/uacian Ambito de ISO/lEG 15939 acc/ones de majora Figura 9.1edicion PROCESOS TECNICOS Y DE GESTION Necesfdades de Informacion Rea/imentacion de los usuarios Productos Informativos v Establecer y Mantener el compromiso de medici6n :: Compromiso Planificar el proceso Evaluaci6n p!anfr7cacfon <I Productos fnformativos y Resultados de f. aunque son una intelfaz extema impOIiante para las actividades de medicion que se incluyen en el estandar. i\Iodelo de Procesos de Medicion de Software (ISO/lEe 15939) Como se aprecia en la figura 9.on de una organizacion no se encuentran dentro del ambito de este estandar.13) que se suceden en un proceso iterativo pennitiendo una realimentacion y una mejora continua del proceso de medici on. Hay dos actividades que se consideran el nllcleo del proceso de medici on: Planificar y Realizar el Proceso de Medicion.

para el estudio de la medicion del software hay que estudiar las entidades que pueden ser objeto de medicion as! como los atributos caracteristicos de dichas entidades.5. tiempo. ACTIVlDAI) I TAREAS Establecer y Mantener el Compromiso de Medicion Planificar el Proceso de Medicion Realizar el Proceso de i\ledicion EYalllar la Medicion Aceptar los requisitos de la l11edicion Asignar recursos Obtener las caracteristicas de la organizacion Identificar las necesidades de infol111acion Seleccionar las medidas Definir los procedimientos de recoleccion de datos. . Con todo ello. especificando que 10 que se qui ere medir es el tamano de un programa (Morasca. METRiCAS SOFTWARE Tal y como se ha descrito en los apm1ados anteriores. analisis e infol111eS Detlnir los criterios de eyaluacion de los productos de infol1mcion y el proceso de medicion Reyisar.5. el objetivo de todo proceso de medicion es recopilar indicadores cuantitativos sobre entidades software. etc . ).. En este apartado se aporta una vision general sobre el campo de las metric as software. es decir. como por ejemplo medir un programa 0 medir el tamano. As! se incluyen las medidas que han resultado ser lltiles en la organizacion. Para realizar Ia medicion es necesmio identificar'tanto las entidades como los atributos a medir. Actividades y tareas en ISO/lEe 15939 3. evaluaciones anteriores de productos de infonnacion y evaluaciones de iteraciones anteriores del proceso de medicion. Las tareas para las diferentes actividades del proceso de medicion de acuerdo al estandar se muestran en la tabla 9. no se puede medir una entidad 0 un atributo de fonna aislada.236 CAUDAD DE SISTE"L\S 10iFOR~lATICOS La Base de Experiencia de Medicion pretende capturar productos de infonnacion de iteraciones anteriores del ciclo. aprobar y proporcionar recursos para las tareas de medicion Adquirir y utilizar tecnologias de apoyo Integrar los procedimientos Tomar los datos Analizar los datos y desanollar productos de infol111acion Comunicar los resultados Eyaluar los prodllctos de infol111acion y el proceso de medicion Identiticar las mejoras Eotenciales Tabla 9. sino que se tienen que medir de fonna conjunta. 2001). siendo una entidad software to do elemento software sobre el que se puede aplicar un proceso de medici6n y que estan caracterizadas por una serie de atributos (tamailo.

Medici6n del Proceso La medicion del proceso implica las medici ones de las actividades relacionadas con el software siendo algunos de sus atributos tipicos el esfuerzo. . CMM. Por 10 tanto. 237 De acuerdo a modelos de evaluacion y mejora como ISO 15504. bas ado en el estudio y control de la capacidad de los procesos. Metricas de Proceso Metricas de Producto Metricas de Producto Figura 9. basado en la gestion de proyectos. recoger y analizar metIicas sobre el proceso. A continuaci6n se da una vision general sobre las metlicas de estos tres tipos de entidades software.lEDICIO:--: DE SISTE\. Medicion del Producto. centrado en su calidad y aspectos tecnicos.CAPiTCLO 9: l-.-'. el proceso software constituye la base a partir de la cual se realiza el trabajo denh'o de una organizacion. el proyecto y recursos asociados as! como el producto software. Tipos de Entidades de :vIedici6n del Software 3. La relacion entre las metricas de proceso. para establecer un marco de medici6n denh'o de una organizacion es necesario definir.14. Dichos procesos se aplican en la practica en fonna de proyectos. 0 CMMI.lAS DE f:\:FORMACIO. Como se puede observar en dicha figura. Medicion del Proceso. a la hora de incrementar el nivel de madurez de una organizacion hay que establecer una base cuantitativa que de menor a mayor grado de madmez esta enfocada sobre: o o o Medicion del Proyecto.1. 1997). as! como en la gestion de los cambios en el proceso. proyecto y producto se muestra en la figura 9. Como resultado de la ejecucion de proyectos concretos se utilizan recursos y se obtienen productos.14. el coste y los defectos enconh'ados (Fenton y Pfleeger.

productos de trabajo entregados. Otro posible enfoque de l11edici6n del proceso es a nivel conceptual.238 CAUDAD DE SISTE?vlAS INFOIUv1A TICOS De acuerdo a Pressman (2002) las metric as del proceso de software se utilizan para prop6sitos estrategicos y en muchas propuestas. En este aspecto se pueden encontrar algunos estudios de para evaluar la mantenibilidad de los modelos de procesos software (Garcia. En relaci6n a las metricas de proceso. ya que es posible que la complejidad u oU'as caracteristicas de calidad del modelo puedan afectar a su ejecuci6n (enactment) y por consiguiente a la calidad de los productos finales obtenidos. 2005). En este senti do un area clave de investigaci6n es el control estadistico de procesos (Florac y Carleton. Los indicadores de proyecto penniten al administrador de software (Pressman. A medida que avanza un proyecto. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo de la ingenieria del software. las metric as de proyectos y los indicadores derivados de ellos son utilizados por un adminisu'ador de proyectos y por un equipo de software para adaptar el flujo de u'abajo del proyecto y las actividades tecnicas. defectos detectados e infol111ados por los usuarios finales. Canfora et al. la medici6n del proceso se realiza extrayendo las caracteristicas de tareas especificas de la ingenieria de software y obteniendo como resultados metlicas sobre los en'ores detectados antes de la entrega del software. las metric as del esfuerzo y del . el esfuerzo humano y tiempo consumido. y el tiempo de desarTollo del mismo. 2002): • • • • • Evaluar el estado del proyecto en curso. Detectar las areas de problemas antes de que se conviertan en "criticas". 1999). Ajustar el flujo y las tareas de u·abajo. Por ello. 2004. es decir.. el enfoque de medici6n del proceso se ha centrado en recopilar una selie de meuicas de todos los proyectos y durante un largo peliodo de tiempo con el objetivo es proporcionar indicadores que lleven a mejoras de los procesos software a lar'go plazo. en la bibliografia. 3. las mediciones del proyecto de software son tacticas. etc. Medici6n del Proyecto La medici6n del proyecto y sus recursos asociados constituye el elemento principal sobre el que se basa el estudio de las l11etlicas del proceso software. ajuste con la planificaci6n.2. Cuando se mide el proyecto el objetivo fundamental que se pretende es el de reducir el coste total del proyecto. Las metricas recopiladas de proyectos anteriores se utilizan como la base a partir de la cual se realizan las estimaciones del esfuerzo y del tiempo necesario para el proyecto actual. Realizar un seguimiento de los liesgos potenciales. El primer tipo de meuicas de proyectos software pueden ser obtenidas durante la fase de estimaci6n.

EI administrador de proyectos utiliza estos datos para supervisar y controlar el avance. quedando: Tamafio Producto = Indice de Productividad * Esfuerzo a * Tiempob. siendo a = 113 y b=4/3. "Tiempo" es la duracion del proyecto. hardware y software. estabilidad de la plataforma) y de proceso (dependiente de las herramientas y metodos us ados as! como del perfil del personal utilizado). En relacion a la estimacion de proyectos software existen model os como el de Putnam y Myers (1992) en el que se desarrollan una ecuacion basica del software expresada como: Producto = Productividad * Esfuerzo * Tiempo. complejidad algoritmica. Esto implica dividir una metlica de producto pOI' una metrica de proceso para obtener una metlica de recurso. y la salida como el numero de lineas de codigo. "Esfiterza" el esfuerzo total del personal del proyecto para desarrollar el producto. La anterior ecuacion fue posteriol1nente ajustada en base al aniilisis de resultados historicos de una gran base de datos de proyectos. etc.!': RA-MA CAPITULO 9: MEDICION DE SISTEMAS DE INFORivLA.. Al utilizar lineas de codigo como metlica de tammlo existen algunas dificultades sobre to do para comparar distintos proyectos en los que se utilizan otros lenguajes 0 entomos de programacion. complejidad de gestion. Una metlica muy utilizada es la productividad del personal. y esfuerzo y tiempo representan los mlos de esfuerzo y duracion de todas las fases del proyecto. Para la estimacion del tamai'io del software cabe destacar la metrica de "Punta FZlI1cion" (vease apartado 3. En general se considera la productividad como la division de la salida poria entrada. que son entre otros. las infi:aestructuras. y la "Prodllctividad' depende de divers os factores que se pueden clasificar en factores de producto (como su dificultad tecnica en funcion de aspectos como restricciones hardware. que se obtiene dividiendo el tamano pOl' el esfuerzo. complejidad logica. el personal implicado. el "Tamaiia" igual al numero de lineas de codigo fuente (nuevas y modificadas pero sin considerar espacios en blanco y comentarios). En Ingenieria del Software es habitual indicar la entl'ada como el esfuerzo en personas mes.4) mientras que para la estimacion de costes de un proyecto caben destacar los modelos COCOMO (COnstmctive COst MOdel) creado por Larry BoelU11 en 1981 y su posterior refinamiento en la version actualmente en vIgor COCOMO II. donde "Prodllcta" representa la funcionalidad expresada en tamano.3. Otro de los elementos clave a mediI' a nivel de proyectos son sus recursos. .CION 239 tiempo consumido se comparan con las estimaciones originales (y la planificacion del proyecto).

se recopilan las metricas tecnicas para evaluar la calidad del disei'io y para proporcionar indicadores que influirim en el enfoque a seguir para la generacion de codigo y para las pruebas.-\D DE SISTE\IAS I. Otros recursos relevantes a considerar son los equipos de trabajo y las hen-amientas (Fenton y Pfleeger. 3. ya que aunque los integrantes de un equipo puedan tener buena experiencia.)0 CALlD. La productividad de los miembros del equipo de trabajo depende de muchos factores. Autores como Fenton and Pfleeger (1997) sugieren utilizar otras metric as de productividad ya que la productividad del personal no considera la calidad del codigo obtenido. En general la experiencia individual se puede mediI' con escalas ordinales pero es importante considerar que la expeIiencia se actualiza con mucha frecuencia. . Tambien es impOltante considerar de fonna separada ia expeIiencia de los individuos y la experiencia del equipo. las helTamientas y los metodos utilizados. 1997). tiempo de entrega y la productividad del personal que las utilizo.-\-\L-\ La metric a anterior solo mide la productividad del personal durante la implementacion. A medida que el software va evolucionando desde la especificacion al disefio. Tal y como indica Pressman (2002). Por otro lado tambien se considera la experiencia como un factor importante de productividad. El uso de metricas para los proyectos tiene dos caracteristicas fundamentales (McDennid. que incluyen todos los aItefactos entregados 0 documentos que son productos durante el ciclo de vida del sofuvare.2. como par ejemplo la estructura del equipo. En relacion a las hen-amientas. aunque es dificil de medir. el equipo puede que no funcione bien y la productividad sea baja.\FOR:\L'\TICOS 1': R. Medici6n del Producto La medicion del producto software esta centrada en evaluar la calidad de los entregables. En la literatura existe una gran diversidad de propuestas relacionadas con la medici on del producto.3. es importante establecer su relacion con otras variables del proyecto como la eficacia de las hen-amientas en tel111inos de la calidad obtenida. 1991): estas metlicas se utilizan para minimizar la planificacion de desan-ollo guiando los ajustes necesarios que eviten retrasos y atemien problemas y riesgos potenciales. Los productos del software son las salidas del proceso de produccion del sofuvare. y se utilizan para evaluar la calidad de los productos en el momenta actual con el fin de poder mejorarlos. otras metric as de proyectos pueden ser obtenidas una vez que comienza el desaITOllo del producto propiamente dicho y en este aspecto es impOltante realizar un seguimiento de los en-ores detectados durante todas las tare as de ingenieria del software. A continuacion se resumen a modo de ejemplo algunas propuestas representativas de metIicas de producto. De hecho los modelos de estimacion consideran el uso de las hen-amientas a la hora de estimar el tamafio 0 coste de desan-ollo de software.

Otras metricas definidas para evaluar la longitud de un programa son: e Numero de sentencias de programacion. usando generadores de codigo n. declaraciones no ejecutables y directivas de compilacion. seglm el objetivo perseguido por la medicion sera importante contar las lineas de comentario como line as de codigo mientras que en otras ocasiones sera imprescindible no contar los comentarios como lineas de codigo. A par1ir de la metrica anterior se pueden definir otras metric as derivadas titiles. lVlETRICAS DE CODIGO FUENTE las metlicas de codigo fuente mas imp0l1antes son Lineas de Codigo y longitud Total. Se creo intentando paliar el problema de ambigiiedad de definicion de las lineas de codigo.lente. quedando (Fenton y Pfleeger.3. que puede dar una idea sobre e1 punto hasta e1 cual esta documentado e1 codigo. los comentarios. Por ejemplo. Presenta el mlsmo tipo de problemas de ambigiiedad que la metrica lOC. ya que esta definicion variara en n. Para facilitar 1a obtencion e interpretacion de la metric a lOC. 1993). pero no las lineas en blanco. . Tambien se debe considerar en la medici on la fon11a en la que el codigo ha sido producido (programando. Lines of Code). Por ello. En particular es necesario clarificar elementos como las lineas en blanco. a pesar de ser ampliamente conocida y utilizada. 1992) en las que se indica que como linea de cOdigo se debe considerar todo el codigo ejecutable. e SIZEl. Sin embargo.vIACIO:\ 2-11 3. modificado 0 conver1ido con traductores automiiticos). las declaraciones de datos y las lineas que contienen instrucciones separadas. 1997): Se define Longitud Total (L T) como la suma del Nlll11ero de Lineas de Codigo que no son comentarios (NClOC) mas e1 nlll11ero de lineas de codigo que son comentarios (ClOC).>\-\IA C>\PiTCLO 9: \IEDICIO:\ DE SISTE\IAS DE Ii\'FOR.(". Como se puede deducir esta metrica solo es aplicable a programas que utilicen este simbolo para separar un as sentencias de otras. Definida como el nll111ero de puntos y coma (li y Henry. En general se recomienda separar en la medicion de la longitud las lineas de codigo y los comentarios. para aplicar esta metrica es fundamental establecer claramente que elementos hay que considerar como linea de c6digo y como deben contarse.1. es la metrica mas popular a nivel de codigo de programa. R.mci6n de las necesidades 0 de la persona que la aplique. copiado 0 reutilizado sin realizar cambi@s. como 1a densidad de comentarios (ClOC/lOC). el problema de esta metric a ha sido la falta de consenso existente a la hora de definir que es una linea de codigo. Lineas de cOdigo (LOC. el SEI ha definido listas de comprobacion (Park.

el volumen minima potencial para un algOli. tiempo de desalTollo e incluso el nlunero esperado de fallos en el software. que es la suma de N1 y N2. Se basan en los tokens (unidades sintacticas elementales distinguibles pOl' el compilador) y que pueden ser divididos en operadores y operandos. siendo Longitud global del programa: N' = III .+2 CAUDAD DE SISTEMAS INFOIUvL.cas deli. y otr'as caracteristicas tales como esfuerzo de desalTollo. constitrlye un ejemplo de medici6n inadecuada.ca mas representativa para evaluar la longirud Halstead prop one la metli. La metrica V(G) esta basada en la teoria de grafos y mide el numero de caminos linealmente independientes de un programa.ca N.\ TICOS £: R. Del resto de metri. Entre las metricas de complejidad destacan las siguientes: e Complejidad Ciclomatica (V(G)). Esta metri. 2002): la longirud global del programa. Las metricas base definidas para estos elementos son: o Ill: el nllmero de operadores diferentes que aparecen en el programa o o o 112: el numero de operandos diferentes que aparecen en el programa N1: el nlllnero total de veces que aparece el operador N2: el nlunero total de veces que aparece el operando A partir de las metri.ca es. (~12) log2 Fenton y Pfleeger (1997) consideran que aunque la propuesta de Halstead ha tenido un gran imp acto en la medici6n software.vIA e Metricas de la Ciencia del Software (Soff1mre Science). nivel del lenguaje (una constante para un lenguaje dado).cas cabe destacar: e e Volumen de un programa: V = N .trno. log2 (11). el volumen real (nlllnero de bits requeridos para especificar un programa).\-.vadas que penni ten evaluar (Pressman. ademas de la primera metri.cas base Halstead define una seli. METRICAS DE COMPLEJIDAD . que puede representarse mediante un grafo de flujo de contro!' Esta metri. 3. para evaluar la complejidad de un programa.2.2.ca puede calcularse de la siguiente fonna: V(G)=A-N+2 . log2 (Ill) + ~l ~12' III +~12.3. Las metricas son la longitud de un programa. propuesta par McCabe (1976). el nivel del programa (una medida de la complejidad del software). Como metri.cas con definiciones confusas 10 que puede provocar diversas interpretaciones de las mismas. al proporcionar algunas metri. una de las mas estudiadas y utilizadas. Propuestas por Halstead (1977) para intentar independizar las metric as del lenguaje de programaci6n. el volumen de un programa y el esfuerzo de implementaci6n de un programa.ca conocida.e de metri.

sino tambien el nlllllero de estmcturas de datos del que el modulo i relme (concentracion) 0 actualiza (expansion) datos. o donde la longitud (i) es el numero de sentencias en lenguaje de programacion en el modulo i. o Conjunto de Metric as MOOSE.. [fan-in (i) + fan-out(i)]2. compuesto por las siguientes seis metricas propuestas por Chidamber y Kemerer (1994): o Metodos ponderados por clase (WMC.culares de este paradigma.+3 siendo A el numero de arcos del grafo y N el nlllllero de nodos. METRICAS PARA SISTEIVlAS 00 El software desan-ollado siguiendo el paradigma 00 difiere en importante medida del desanollado utilizando enfoques tr·adicionales. es posible definir la fonnula: . 3.. que esta basada en las dos metricas anteriores y creada tambien pOl' Henry y Kafura (1981) siendo su definicion: MHK = longitud (i) . . que mide la complejidad de una c1ase.~RA-MA C-\piTULO 9: MEDICION DE SISTEMAS DE INFO~'vlACION 2. .3. 'Weighted Methods per Class)... .. Si todos los metodos son igualmente complejos. o Fan-in (concentracion) y fan-out (expansion).3.. Complejidad de un modulo. Ambas metr-icas trabajan sobre la estr1.. Sea la c1ase C que tiene los metodos j'vh . Cn. Ello planteo la necesidad de definir nuevas metricas adaptadas a las caracteristicas parti. Propuestas por Henry y Kafura (1981). Henry y Kafhra amplian la definicion de concentracion y expansion no s610 como el nllmero de conexi ones de control del modulo (llamadas al modulo). Diversos estudios empiricos han encontrado una fuelte cone lac ion entre la metrica de McCabe y el numero de enores que existen en el codigo fuente. as! como el tiempo requelido para encontr'ar y conegir dichos enores. entonces WMC es igual al numero de metodos definidos en una c1ase. de las cuales se presentan a continuacion algtUlas propuestas representativas.1ctura de un modulo representada como un arbol 0 grafo de llamadas entre modulos_ Eljan-in de un modulo m es el numero de flujos que tenninan en m mientr'as que eljan-ollt es el numero de flujos que salen de m. Otr-a de las aplicaciones de esta metric a ha sido a nivel de pmebas del software ya que puede utilizarse para predecir la cantidad de esfuerzo necesario para probar un modulo 0 programa. A mayor valor de la metrica V(O) mayor complejidad del programa.. Ml1 siendo su complejidad respectiva cJ. McCabe indico tambien que un valor razonable de esta metrica para que un modulo fuera mantenible debia ser menor de diez.

RFC pOI' 10 tanto se ca1cula contando las oCLllTencias de llamadas a otras clases de una clase particular. Number of Children). asi como polimorfismo y su consecuente int1uencia sobre la cali dad del software y la productividad en el desalTollo. es decir. Las metI-icas MOOD se pueden utilizar en las fases de disei'io y se definieron para ser aplicadas a nivel de diagrama de clases (vease tabla 9. La metrica CBO indica para una clase el nlunero de otras clases con las que esta acoplada. Numero de Hijos (NOC. la cantidad de subclases que peltenecen a una clase. Falta de cohesion en los metodos (LCOM. o o o o e Metricas MOOD (Brito e Abreu y Cal·apuca.·Vv!A o Profundidad del l<\rbol de Herencia de una Clase. LCOM establece en que medida los metodos hacen referencia a atI·ibutos.24-1 CAUDAD DE SISTDIAS I"'FORYL~ TICOS £' R. herencia. Lorenz y Kidd (1994) propusieron un conjunto de metricas llamadas '"metricas de diseiio'·. COZlpiing Between O~jects). Un valor alto en LCOM implica falta de cohesion. Respuesta de una clase (RFC. Response For a Class). Se trata de la cuenta directa de los niveles de la jerarquia de herencia. considerando que en elnivel cero de la jerarquia se encuentra la clase raiz. es decir.6). por ejemplo cuando un metodo de un objeto utiliza un metodo de otro objeto. La metric a DIT mide el maximo nivel en la jerarquia de herencia. Depth ot" inheritance Tree). Acoplamiento entre Objetos (CBO. Se considera que un objeto esta acoplado a otro cuando actlJa sobre ese otro objeto. 1994). NOC es el nllmero de subclases subordinadas a una clase en la jerarquia. LCOM es una metrica de la cohesion de una clase en base al nllmero de atributos comunes usados por diferentes metodos. Se ca1cula como el nllmero de pares de umciones sin variables compartidas de instancia menos el numero de pares de umciones con valiables de instancia compartidas. de la posibilidad de hacer creado abstracciones elToneas. DIT se considera como una metric a del nlunero de clases antecesoras que una clase podIia potencialmente afectar. Seglll1 Chidamber y Kemerer (1994). Esta metIica se considera lltil para predecir el esfherzo necesario para el mantenimiento y las pruebas. escasa similitud entre los metodos siendo siempre deseable un alto grado de cohesion en los metodos de una clase. RFC indica el nlll11ero de metodos que pueden ser ejecutados potencialmente como respuesta a un mensaje recibido por un objeto de esa clase. y delnivel de pruebas requerido. Lack of Cohesion in Methods). EI objetivo de las metric as MOOD es medir los plincipales mecanismos del paradigma 00. Metricas de Lorenz y Kidd (1994). que se refieren a caracteristicas estaticas e . tales como encapsulamiento. NOC es un indicador del nivel de reutilizacion. debido a que cuanto mayor sea elnivel de profundidad de herencia de una clase mayor es el nl1l11ero de metodos y atributos que hereda de otras clases. (DIT. polimorfismo y paso de mensajes.

Metricas MOOD que se pueden aplicar a la fase de diseiio En resumen. PF es una medida del polimodismo y una medida indirecta de la asociacion dinamica en un sistema. Henderson-Sellers et af. EI Factor de Ocultamiento de los Atributos (. MODIFIABILITY::. cuantas lmis relaciones haya en el modelo. cantidad relativa de infoTInacion oculta.He/ed Hiding Factor) mide la proporcion entre los metodos ddinidos como protegidos 0 prh'ados y el nt1!nero total de J11i'!todos.6. si un caso tiene yarios objetivos (tipos para Saeki). Tambien existen otras propuestas especificas para casos de usa. (2004). AHF \IlF AIF PF Tabla 9.~ RA-\!A C\PiTCLO 9: \!EDICIO?\ DE SISTEMAS DE I0:FOR. (2004). como pOI' ejemplo las propuestas de Feldt (2000). EI Factor de Polimorfismo (Po~nIl0/7)hislll FaclOr) se define como el cociente entre el ntllnero actual de posibles diferentes situaciones de polimortismo. En la bibliogratla se pueden encontrar diversas propuestas de metricas para los distintos tipos de diagramas UML: . EI Factor de Herencia de los Metodos (Method inheritance Factor) se define como el cociente entre la suma de los metodos heredados en todas las clases del sistema considerado y el numero total de metodos existentes (tanto los detinidos localmente como los heredados) en todas las clases.7 se muestran aquellas metricas que pueden aplicarse a un disefio de alto nive!. €I Metricas para UML. MHF se propone como una medida de encapsulacion. Al igual que :vlIF. 111<1S dificil sera hacer cualquier cambio. se consideran las relaciones de inclusi6n y extensi6n y las relaciones de control y de dependencia de datos. es mas susceptible de cambiar que si tiene s610 un objetiyo. EI Factor de Herencia de los Atributos (Auribllle inheritance FaclOr) se define como el cociente entre In suma de los atributos heredados ell todas las clases del sistema considerado y d numero total de atlibutos existentes (tanto los detinidos localmente como los heredados) en todas las clases. AIF se considera como un medio para expresar la capacidad de reutilizacion en un sistema.c'vIACIOl\' 2. Simplificando la idea. metric as de herencia y metricas de caracteristicas intemas de las clases. Un estudio mas profundo sobre metricas para casos de uso y diagramas de casos de usa puede encontrarse en Genero et al. Otro factor que influye en la modificabilidad de los casos de usa es el tipo de caSG de uso. Para aproximar la modificabilidad. La intuici6n aconseja que. y cl nLlmero maximo de posibks situaciones distintas de polimortismo para la clase Ci. Estos autores clasificaron las metncas en: metricas de tamai'io. se definen las metric as NOD (Numero de Dependencias) y NUCT (NCul1ero de Tipos de Casos de Uso).+5 del disefio de un producto software. 1) que revelaba el grado de modificabi-lidad de un modele de casos de uso. En la tabla 9. El objetivo alcanzado por el autor consisti6 en un indicador (0::.-!. y por 10 tanto como una medida del nivel de reutilizacion.ltribwe Hiding FaclOr) se define como el cociente entre la suma de las invisibilidades de todos los atributos detinidos en todas las clases y el nt1!nero total de atributos definidos en el sistema considerado. MIF se define como una medida de herencia. AHF se definio como una medida de encapsulacion. (2002) y Bemardez et af. La invisibilidad de un atributo es el porcentaje del total de clases desde las cuales los atributos son im"isibles. i \IHF EI Factor de Ocultamiento de los Metodos (. NOMBRE I "" DEFINICIOr.

' N\IO N\II N\IA \IETRlC. EI Promedio de Parametros por Metodo se define asi: . Existen pocas propuestas de metricas especificas para diagramas de casos de uso."llll1ero dc Metodos Sobrecargados es el nl1111ero tOlal de l11i?todos sobrecargados por una subclase."llmero de variables de Clase es elnllll1erO total de variables a nivel de clase que tiene una clase.~llidamiellloEIILaJeranfzli'l ."llmero de ~'Ietodos Afiadidos es elnlllnero total de metodos que se detlnen en una subclase.\"i."l1111ero de Variables de Instancia es el nllll1erO total de variables a nivel de instancia que tiene una clase. considerando las \"ariables privadas y protegidas disponibles en una clase.\/elOdos SIX \IETRICAS DE CAR-\CTERisTIc.I. el nllll1ero de actores ( Na ) Y el nllll1ero de relaciones de inclusi6n Y extensi6n. EIl\llmero de \Ietodos Heredados es elnl1mero total de metodos que una clase hereda.\L.\/elodosSohrees('}"iloS * .-\s I"TER"AS DE LAS CLASES APP:\-I Esta metrica mide hasta que punto una subclase redetlne el comportamiento de una sllperclase.\"zimero Tola IDeP([nimel rosPod/clO do . \Ietricas de Lorenz y Kidd (1994) .7. TIeos s RA-\. Esta metrica se dctlnio para mediI' la cali dad del uso de la herencia. EI 0.-\S DE HERE"CIA DEFE\ICIO:-. EI 0.\"zimero TOlalDe. probablemente habra que cambiar otros casos de uso: aquellos que tengan una relaci6n con el caso de uso que se cambi6 originalmente. ya que examina la relacion de herencia entre subclases y superclases. TIPO i NmIBRE PI:\I NI:\I \IETRIC-\S DE TA:\IA:\O NIY NOI N\. Basandose en estas metricas tambien defini6 un indicador global de la complejidad del sistema. !lor ejemplo. EI Nl1111ero de ~letodos de Instancia es la suma de todos los metodos de una clase.L-\ o Casos de Uso. con el fin de obtener un indicador de modificabilidad. EIl\lunero de i\letodos de Clase es el nlllnero total de l11<?todos a niwl de c1ase. considerando tanto los metodos Pl1blicos como los protegidos y pri\"ados" EI 0. La idea basica de estas metlicas que es que si se necesita cambiar un caso de uso.\"zimero TOia IDe.DE SISTEvlAS INFOR.. EI 0.\IelOdos Tabla 9. Saeki (2003) se definen un conjunto de metricas para diagramas de casos de uso. Los metodos Pl1blicos son aquellos que estan disponibles como servicios para otras clases.\·zimerode. tales como: Marchesi (1998) que propuso un conjunto de metricas de complejidad para diagramas de casos de uso consistente en el nl1l11ero de casos de uso (N cc ). aquellos metodos que son globales a todas las instancias que tiene una clase. EI indice de Especializacion para cada c1ase se detlne asi: . I EI Nllll1ero de Metodos de Instancia Pl1blicos de una clase es el nllll1erO total de metodos Pl1blicos de instancias.·elde.

. ambas propuestas no han pasado mas alla de la definici6n. (2004) definieron un conjunto de metric as para la complejidad eShlJctural de diagramas de clase de UML debido al uso de relaciones de UML. 2002) tambien definieron l11etticas a nivel de clase para evaluar propiedades de diseno como la encapsulal11iento. En cualquier caso. Nllll1ero total de relaciones de agregacion dentro de un diagrama de clases (cada par todo-par1e de una relacion de agregacion). DeIT (1995) defini6 el nll111erO de estados y el nll111erO de trallsiciones como metric as que miden la cOl11plejidad de los diagramas de estados OMT (aunque tambien se pueden aplicar a lJTvIL).\IAxDIT .iximo de la metrica HAgg calculada para cad a clase del diagrama de clases. EI \'alor m. Genero et al. generalizaciones. Los autores suponen que estas metticas pueden ser buenos indicadores de las caractetisticas de mantenibilidad de un diagrama de clases de UML..\IClO. Estas metric as son utilizadas junto a otras para diagramas de clases. Profundidad del Arbol de Herencia) calculada para cada clase del diagrama de clases. (2002) propusieron dos metricas: totSta(c). tales como: asociaciones.-\PiTCLO 9: ? [EDICrO" DE SrSTE?v[AS DE IN~OltvL-\CrON 247 o Diagramas de Clases UML. Nllll1ero total de relaciones de dependencia.It-\-MA . para detenl1inar la complejidad total de un sistema 00. I :\'llll1ero total de jerarquias de agregacion (estructuras todo-par1e) dentro de un diagrama de clases. definieron un conjunto de . Con la hip6tesis de que el tamai'io y la complejidad estructural de los diagramas de estados de UML puede influenciar su facilidad de entendimiento (y por tanto su mantenibilidad). (2003). EI \'alor maximo de la metrica D1T (Depth olInheritallce Tree. dependencias y agregaciones (vease tabla 9. JUtric{[s para complejidad est1'1lctural de diagralllas de clases UJIL o Diagramas de Estados. (1999. Tabla 9. diagramas de casos de uso.. Bansiya et al. que representa el Illl111ero total de estados para una clase y totActioll(c) que cuenta el nll111ero total de acciones para una clase. C.8.. METRlCAS I I DEFJ. la c0l11posici6n y la herencia.\L-\xHAGG NllIl1CrO total de asociaciones. EI yalor de HAgg para una clase dentro de una jerarquia de agregacion es el camino J11:is largo desde la clase hasta las hojas. N llmero total de jerarquias de generalizacion dentro de un diagrama de clases. I :\'llmero total de relaciones de generalizacion dentro de un diagrama de clases (cada par padre-hijo de una relacion de generalizacion). el acoplal11iento.\ :\Assoc :\AGG I :\DEP :\GE:\ :\AGGH :\GE:\H . etc.8). Carbone et al. EI valor de D1T para una clase dentro de una jerarquia de generalizacion es el camino mas largo desde la clase hasta la raiz de la jerarquia. la cohesi6n. Un trabajo mas completo es el propuesto por Miranda et al.

Como resultado del trabajo de expelimentacion.+8 CAUDAD DE SISTE\lAS I). Ademas. (2004). considerando tambien los estados simples dentro de los estados compuestos: NCS. }\rExitA y NG son de tamafio. EI "c!zlll1king" implica el reconocimiento de un conjunto de infolll1acion de declaracion y ."FORyL\TICOS f R. y las metlicas NT y CC son de complejidad.2. NExitd. como el "chunking" y el "tracing". nll111ero total de acciones de salida.-\-\lA metric as para la complejidad estructural y el tamai'io de los diagramas de estados de UML Como metlicas de tamai'io se definieron: NEntr}A. NCS. NG y NT parecen estar altamente cOlTelacionadas con el tiempo de entendimiento de los diagramas de estados de UML o Expresiones OCL (O~iect Constraint Language). concluyeron que las metIicas NA NSS. es decir. Este modelo proporciona una teoria cognitiva general de la complejidad del sofuvare relacionada con el impacto de la estmctura sobre la comprension. nllmero total de estados. NC. concluyendo que las metricas NA NSS. quienes tomaron como hipotesis que las propiedades estructurales de una expresion OCL tienen un impOltante impacto en la complejidad cognitiva de los modeladores. su validacion tambien aplicando el marco de u'abajo DISTANCE (Poels y Dedene. las acciones que se realizan cada vez que se abandona un estado: NA. es decir. que se entra en un estado. las transiciones inicial y finaL las autotransiciones (los estados origen y destino son el mismo) y las transiciones intemas (transiciones denu'o de un estado que responden a un evento pero sin dejar el estado). nll111ero total de actividade? (do/activity). 2002) garantiza que las metricas puedan usarse como inSU1tmentos de medicion en esc ala de ratio. l1l1mero total de transiciones. NEntryA. Como metricas de complejidad estructural definieron: NT. (1992: 1994). nl1mero total de estados compuestos: NE. NE. l1l1mero total de eventos. CC (Nllmero Ciclomatico de McCabe). La lmica propuesta hasta la fecha de metricas para. NSS. considerando las transiciones comunes (los estados origen y destino son diferentes). Nllmero total de acciones de entrada. las acciones que se realizan cada vez . (1996). Su hipotesis fue cOlToborada empiricamente en cierta medida a traves de un experimento controlado y su replica. Estas tecnicas se aplican conCUlTente y sinergeticamente en resolucion de problemas y son parte del Modelo de Complejidad Cognitiva (CMM) definido por Cant et a/. nllmero total de condiciones de guarda. ya que cuando los desalTolladores tratan de comprender una expresion OCL (considerada en este estudio como una abstraccion mental simple: un "chunk") aplican tecnicas cognitivas. La validez teorica de las metricas propuestas se demostro a traves de la validacion siguiendo el marco de trabajo de Briand et a/. expresiones OCL es la realizada por Reynoso et a/. definido como INSS-NTI+2.

Reynoso et al.lpOS de conceptos de OCL (vease tabla 9.". etc.c R. Estas metricas tambien se validaron teoricamente usando el marco de Briand et al. DE SISTEMAS DE INFOR:vlACIO. 1\1NC Y NAN se validaron como metric as de acoplamiento basadas en la interaccion. SC[\'icios OCL relacionados con el propio lengllaje. literales. diferentes al tipo de la instancia contexmal. valores posttijos de by (~pre. l\avegacion y operacion de colecciones. Grupos detinidos de conceptos Oel de acuerdo a tecnicas cognitivas Aunque las expresiones OCL pueden anadirse a cualquier diagrama de UML. que cuenta el nlllnero total de atributos que son referidos a traves de las navegaciones de una expresi6n: Nztlllero de Clases Nm'egadas (NNC).-'. Conceptos OCL que penniten que una expresion uti lice propiedades que pertenezcan a otras clases 0 interfaces. etc.\. variables ddinidas a mm~s de restriccioncs «defInition».Vcn·egaciolles (X·LV). Tic'\'IC'I. Siempre que una clase asociacion se navegue. Tabla 9. Ademas. Mensajeria. estos antores han definido metric as relacionadas con estas tecnicas cognitivas. parametros cuyos tipos son clasificadores definidos en el diagrama de clases. Algunos ejemplos de metr1cas relacionadas con el "tracing" son (entre otras): Nlllnero de Relaciones Navegadas (NNR). Si una clase contiene una relacion reflexiva y una expresion la navega.lnrPLos DE CO. COG:-IITn'A ICAR~CTERfSTICAS CO:\W. I Conceptos OCL relacionados con Rcferencia a atributos 1I operadores de la instancia la instancia contextual y algllna de contextual..ES DEL GRDPO DE CO. etc. las metricas NNR. El "tracing" se ha observado como una actividad fundamental en la comprension del software. pOl' ejemplo usando propiedades diferentes de una clase 0 interfaz. hacia adelante 0 hacia atnis. la clase se considerara solo una vez en la metrica. agrupandolas en tres gr'andes grl. Si una relacion se navega dos veces. clases de asociacion 0 interfaces a las que navega una expresion. 249 extraccion. la clase se cuenta solo una vez. como una clase puede alcanzarse desde una clase/interfaz inicial navegando de fonna diferente (es decir.9. Por esa razon. para identificar los "chunks". esta relacion se cuenta solamente una vez. consideraremos la asociacion a la que la clase asociacion \'a unida: Nzilllero de Atriblilos referidos a tran?s de las . que cuenta el numero total de relaciones que se na\'egan en una expresion.-. (:200-1-) han comenzado la definicion de metricas para expresiones OCL que puedan usarse en un diagr'ama de clases de UML. (1996). La intuici6n dice que las metr1cas relacionadas con el "tracing" podrian tener mas influencia en la facilidad de entendimiento y la . siguiendo relaciones diferentes) debemos considerar esta situaci6n como un caso especial: Si una c1ase se usa en dos (0 mas) navegaciones diferentes. Expresiones condicionales It: \'ariables iterativas predetinidas. 'us propiedadcs.CEPTOS OCL RELACIO'\'ADOS CO'"' CADA GRUPO Tracing ChlllZkillg GI1IPO I Chzll1king Grupo 2 Ddiniciones de vmiables a tran~s de expresiones let.CEPTOS DCL E. Por ejemplo.-\-:'IA CAPiTULO 9: :'IEDICIO. que se recuerda como un "chunk". mientras que el "tracing" implica explorar.9). que cuenta el nltmero total de clases.\.

generada para el usuario U otro programa.250 CAUDAD DE SISTEMAS J}. 3. no se han tenido en cuenta (de momento) en el campo de la medici6n. casi ninguna para expresiones OCL. Sin embargo. los diagramas de actividad. Consultas externas (consuItas): combinaciones de entrada/salida en las que cada entrada genera una salid simple e inmediata. PUNTOS FUNCION La metric a de puntos funci6n fue definida por Albrecht (1979) con el fin de predecir el esfuerzo y el coste de desarrollo.. Pero este hecho debe comprobarse a traves de estudios empiricos. grafico. Archivos Iogicos internos (archivos): plincipales grupos 16gicos de datos de usuarios 0 de control que estan controlados completamente por el programa (una tabla de un SGBDR). iii iii iii .. Esta constituye una de las metric as mas conocidas y utilizadas de la literatura. borrar 0 cambiar datos. fonnulario. mensaje) que tenga un fonnato diferente 0 requiera un procesamiento diferente a otros tipos de salida.TfORJvlATICOS modificabilidad de las expresiones OeL. La f6nnula general para calcular los puntos funci6n es: PF = PFSA * FCT.4. a traves de la cual el' usuario u otro programa puede anadir. Para calcular los puntos funci6n sin ajustar es necesario contar el numero de elementos de cada uno de los siguientes tipos (que se pueden obtener a partir de la especificaci6n del sistema): iii Entradas Externas (entradas): cualquier entrada (pantalla.3. No hay ninguna prueba de su validaci6n empirica. Otros modelos UML. cuadro de dialogo. los autores planean realizar un experimento controlado para validar algunas de las metricas propuestas como indicadores de la facilidad de entendimiento y la modificabilidad de las expresiones OCL. los diagramas de clases UML han sido de los mas investigados desde el punto de vista de la medici6n. etc. En definitiva. En menor medida se han propuesto y validado metricas para diagramas de caso de uso de UML. diagramas de estados de UML y. como los diagramas de secuencia. que cubren aspectos dinamicos de los sistemas 00. Salidas extern as (salidas): cualquier salida (pantalla. Un punto de funci6n es una medida sintetica del tamano funcional de un sistema independiente de la tecnologia y lenguaje de programaci6n utilizado para desarrollarlo. infonne. control 0 mensaje) que tenga un fonnato lmico 0 un solo procesamiento. donde PFSA son los puntos ftmci6n sin ajustar y FCT es un factor de correcci6n tecnica.

MEDIA . Lista de palabras con errores ortograficos Archivo Interno: 1. Diccionario Figura 9. EI numero total selia 7.. ~ . Pesos de Complejidad de los PFSA .• ··El\'TRADASExTER'<AS .. l. 15 PFSA= "LPesoi* Elementoi i=l En la tabla 9." . SALIJ)~S R'ITERt"'AS .' CONSllLTAsEX"TERt. Archivo Externo: 1. .. ELEME"'TO .10.Cuantas palabras se lIevan procesadas? ---------- Usuario Comprobador Ortografico Salida: 1. . Intelfaces = 1. Documento que se ha de revisar Entrada: ---------- --------- 1.os 3 4 3 7 5 4 6 5 4 10 7 7 6 15 10 Tabla 9. Numero total de errores detectados 3. EI valor de PFSA se calcula como la suma de cada uno de los tipos de elementos ponderada por su complejidad (peso).15.'<AS I ARCHIVOS LOGICOS II'I'TIR"'OS ARCHIVOS DE L'<TERFAi R'X"rER". Archivos = 1.. Por ejemplo. Nombre del documento que se ha de revisar Consulta: 1... el IlLunero de elementos de cada tipo selia: Enh'adas 1... Salidas 3. . Numero total de palabras revisadas 2. • _ _ _ _ _ _ _CmWLEJIDAD . baja 0 media). Ejemplo de DFD de un Sistema de Comprobacion Ortognifica Cada uno de estos elementos se debe clasificar de acuerdo a su complejidad (alta. BAJA .10 se muestran los pesos a aplicar en funci6n de la complejidad de cada tipo de elemento.15. si el DFD del sistema es el de la figura 9..~ RA-MA CAPiTULO 9: MEDICION DE SISTEMAS DE INFORMACION 251 CI Archivos de interfaz externos (interfaces): cada uno de los grupos de datos 16gicos 0 infonnaci6n de control que entra 0 sale del programa. Consultas= 1.

6.11 ). 4. 7. Tabla 9. Complejidad de las Entradas EI valor del factor de cOlTecci6n tecnica depende de catorce (14) factores de complejidad que son valorados de fonna subjetiva asignimdoles un valor de cera (0) a cinco (5). algunas tecnicas incluyen tablas orientativas para cada tipo de nll1ciones de usuario. 0 si la aplicaci6n consiste en c6digo independiente ejecutandose en procesadores distintos y persiguiendo un fin comtll1. Estos factores son: 1. Tasas de transacciones nipidas: tendril una puntuaci6n de 5 si el volumen de transacciones es suficientemente alto como para requerir un esnlerzo de desalTo!lo especial para conseguir la productividad deseada.252 CAUDAD DE SISTE\!AS lPiFOR\L'\TICOS Para hacer menos subjetiva la valoraci6n de la complejidad. . y tendra una puntuaci6n de 5 si mas del 50 por ciento de las transacciones son interactivas. 5.11. Objetivos de rendimiento: tendnin una puntuaci6n de 0 si el rendimiento de la aplicaci6n no es relevante. ! 3. enviados 0 recibidos mediante alglll1 sistema de comunicaciones. Amigabilidad en el disefio: detemlina si las entradas de datos interactivas requieren que las transacciones de entrada se !leven a cabo sobre mtlltiples panta!las 0 variadas operaciones. la tabla de complejidad para las Entradas tiene en cuenta dos aspectos: nlunero de tipos de elementos de datos incluidos. Procesamiento distribuido: concemiente a si una aplicaci6n es monolitica y se ejecuta en un lmico procesador. Por ejemplo. Contiguracion de uso intensivo: indica si el sistema se va a implantar en un entomo operativo que sera utilizado de manera intensa. Comunicaciones de datos: concemiente a la transmisi6n de datos 0 infonnaci6n de control. Entrada de datos en linea: tendrii una puntuaci6n de 0 si son interactivas menos del 15 por ciento de las transacciones. 0 por el contrario la puntuaci6n sera 5 si es un factor critico. y nllll1ero de archivos 16gicos intemos referenciados (tabla 9.

14. medio 0 dificil. El valor de puntos funcion puede ser traducido a otras metric as como por ejemplo a LOC. Procesamiento complejo: se puntuara con 5 si se requieren gran cantidad de decisiones logicas. 10. complicados procedimientos matematicos 0 dificil manejo de excepclOnes. Adaptabilidad: una puntuacion maxima indicaria que e1 sistema se ha disei'iado para sopOliar mtlltiples instalaciones en diferentes entornos y organizaciones. La suma ponderada por complejidad de todos estos elementos pel111ite . Facilidad operacional: un valor de 5 indica que el sistema realiza pccas operaciones.s y especialmente dificultosas.LO 9: ~lEDIClOl\ DE SISTE1>!AS DE [l\FORMACION 253 8. 9. Cada pantalla 0 infol1ne se c1asifica como simple. 12. 0 de proteger los datos contra cambios accidentales.01 . Reusabilidad: indica si gran parte de la fUl1cionalidad del proyecto. siendo SUMA(GI) la suma de los grados de influencia de 14 factores que intluyen en la complejidad del proceso.'SUMA(GI). Otra metrica relevante relacionada con los puntos funcion es la de Objetos Funcion que es solo aplicable a sistemas 00. esta pens ada para un uso intensivo por otras aplicaciones. Facilidad de instalacion: un valor de 5 denota que la instalacion del sistema es tan importante que requiere un esfuerzo especial para desaIToliar el software necesmio para realizarla. infol111eS y componentes de tercera generacion que son 0 seran parte de la aplicacion. en cuyo caso se utilizan tab las de equivalencia en la que se tiene en cuenta el tipo de lenguaje de programacion.~ RA. Para calcular esta metric a en primer lugar se deben contar el nLlmero de pantallas. Versatilidad: detel111ina si la aplicacion se ha realizado para facilitar los cambios y para ser utilizada por el usuario. ya se tiene un indicador sobre el tamano del ·soft\vare en la fase de analisis. El valor del factor de cOlTeccion tecnica se obtiene: FeT = 0. 13. Actualizacion de datos en linea: tendni puntuacion maxIma si las actualizaciones en linea son obligatOli[. 11. que puede ser utilizado para realizar estimaciones de esfuerzo.65+0. Una vez que se conocen los puntos funciol). mientras que los componentes de tercera generacion se consideran todos con el mismo peso. quiza debido a la necesidad de realizar copias de seguridad.-MA cAPin..

A functional size measurement method".254 CAUDAD DE SISTE!'vL"'S INFORr\'LS. es decir. compra. asi como para sistemas software de tiempo real y sistemas hibridos de los anteriores. Los puntos objetos se utilizan en el modelo de estimacion de costes CO COMO II (Boehm et aI. etc. de pronostico. etc. como las encontradas en sistemas expertos). contabilidad. que a partir del modelo genelico produce un valor de tamafio funcional del modelo de acuerdo al siguiente plincipio "el tamai'io funcional del software es directamente proporcional al nlllnero de sus movimientos de datos". Los movimientos de datos pueden ser de cuah'o tipos: entrada. 2003) proporciona un metodo estandar para la medicion del tamafio funcional del software y a partir de esta propuesta se ha derivado el estandar ISO/IEC 19761 "Software Engineering . de autoaprendizaje. siendo OP el numero de puntos de objetos. 2000). Fase de Medicion. salida. domini os como la banca. . reglas y procedimientos a una detenninada pieza de codigo de acuerdo a tal y como dicha pieza es percibida desde la perspectiva de los requisitos funcionales del usumio. software de simulacion. Sin embargo este metodo aun no cubre piezas software que esten caractelizadas por aigOlih110S matematicos complejos u oh'as reglas.. TICOS obtener el numero de puntos de objetos simples. COSMIC-FFP puede ser empleado para aplicaciones de negocio software. El metodo COSMIP-FFP requiere la aplicacion de un conjunto de modelos.COSMIC-FFP . gestion de personal. Para calcular los puntos de objetos nuevos se tiene en cuenta un factor de reutilizacion r. Otros consorcios como el IF PUG (International Function Point User Group) proporcionan tambien un amplio sopOlte para la aplicacion de las mehicas relacionadas con los puntos funcion. Como resultado se obtiene una cantidad l1l11nelica que representa el tamafio funcional de dicho software. que representa el porcentaje de puntos de objetos reutilizados de otros proyectos.r) / 100.. EI proceso de COSMIP-FFP consiste en dos fases fundamentales: Fase de "Mapping". quedando la fonnula: NOP (New object points) = (OP) * (100 . La propuesta COSMIC-FFP (COSMIC. Tambien merece especial atencion la propuesta de Full Flincion Points (FFP) elaborada por el consorcio COSMIC (Common Software j\1easllrement international Consortium). en la que se reciben como entrada los requisitos funcionales del usuario y mediante la aplicacion de una serie de reglas y procedimientos dichos requisitos son expresados de acuerdo almodelo de software generico de COSMIC-FFP y la. distribucion 0 fabricacion. lecrura y escrirura.

la presentaci6n y el amilisis de los valores de las metlicas (Giles y Daich. Kingsbury y Dawood. posibilidad de exportar archivos a otras aplicaciones EI EI Dumke y Kompf (1997) clasifican las helTamientas de l11etlicas atendiendo al entomo 0 dominio en el que se utilizan. logrando una mayor exactitud en sus val ores Pel111itir central110S en el analisis de los resultados de la medici6n y no en la etapa de adquisici6n EI EI Una helTamienta de metlicas de software puede definirse como una helTamienta para el modelado y el calculo de componentes de desaITolIo de software.. El proceso de desaITolIo de software tambien incluye la preparaclOn de los componentes del software y del proceso de evaluaci6n. autol11atica y programable. es deciI'. Las ventajas de contar con una helTamienta que pennita automatizar tanto la adquisici6n y la presentaci6n como el analisis de los valores de las meu'icas son (Lavazza. HelTamientas para la Medici6n y Evaluaci6n de Software Asistidas por COl11putador. Existen varios estudios dedicados a la evaluaci6n y comparaci6n de herTamientas de metlicas (Giles y Daich. 1995). 2000): EI Posibilitar la obtenci6n de los valores de las meuicas sin mayor esfuerzo Minimizar los elTores en el ca1culo de las metlicas. Giles y Bal11ey. eficiente y ex acto es necesario contar con helTamientas que pennitan automatizar la adquisici6n. del producto 0 de los recursos (SMLab Project. para que las meuicas puedan ser evaluadas de un modo pnictico. 1995. 1995. Asi pues. HERRAMIENTAS DE MEDICION SOFTWARE El desalTolIo de un marco efectivo p&a la medici6n requiere un soporte metodo16gico. es necesario contar con hen'amientas que den sopOlte a la medici6n de software como un gmpo denu'o del conjunto de metricas. Giles y Daich (1995) distinguen las u'es principales tareas que deben realizar las herTamientas de l11euicas y las caracteristicas necesar~ias que deben implementar para que dichas tare as se puedan lIevar a cabo: EI Adquisicion de datos: manual. 1995). analisis ariunetico y analisis estadistico. Son las denominadas herTamientas CA1VIE (Computer Assisted Software Measurement and Evaluation). Daich et al. Es decir. 1995. recuperaci6n de los datos. 2000). 1995. Daich y Giles. Erickson y Steadman. . Analisis de las medici ones: almacenamiento de los datos. 1995. graficos.CAPiTULO 9: MEDICIO]\ DE SISTEMAS DE NFORMACION 255 4. semiautol11atica. Presentaci6n de los datos: tablas. 2002). bien sean del proceso. pero tambien es muy impOltante el aspecto tecno16gico (Lavazza.

uksma. . SITIOS WEB RECOMENDADOS (l) ·http:hvww. Asociacion Espanola de Metricas del Software http://w"\vw. previa consulta a un responsable de personal.ifplUI.upm. donde se hlVO que indicar este valor.\L'\ TICOS 5.cosmicon.nesma. b.org!english! Sitio Web de NEStvlA (Netherlands Software Metrics Users Association) http:!. Las metricas a utilizar podrian ser: a. Este simposio intel11acional constituye una de las conferencias mas importantes centradas en los aspectos de investigacion y practica en el campo de la medicion del software.fi. en concreto es necesario conocer el nivel de productividad de los programadores.co. Sitio de Measurement Intel11ational Consortium) COSMIC (Common Software (l) (l) http://W\\w. EJERCICIOS I. Representar mediante la ontologia de la medici on software el siguiente caso de estudio: supongamos una organizacion que lleva a cabo un proyecto de desaITollo de software. Proporciona un foro de debate para analiza!' y prom over el uso de la medicion software como medio para entender.\nnv. En un detenninado momenta el responsable del proyecto necesita saber si la productiyidad es adecuada.Orgj Sitio web delIFPUG (Intel11ational Funtion Point Users Group) http://ww.es!. lECTURAS RECOMENDADAS (l) Proceedings de IEEE A1ETRlCS Symposillm. 6. en unidades monetarias).isbsg. evaluar y modelar los fenomenos de la Ingenieria del Software. EI metodo de medicion es consultar el plan del proyecto. que se puede obtener contando las lineas utilizando como instrumento una heITamienta CASE. c.com/.aemes. del proyecto en comparacion con 10 habihlal en otros proyectos en la organizacion.256 CAUDAD DE SISTEMAS INFOR.uk! Metrics Association) Sitio de MARK II (United Kingdom Software (l) e (l) 7. EI responsable del proyecto anota cada dia las horas dedicadas por los programadores al proyecto. CHP (coste por hora-programador.onz/ Sitio de Intel11ational Software Benchmarking Standards Group http://w\v\\.v. HPD (horas-programador diarias). LCF (lineas de codigo fuente escritas).

1'30:s.!EDICI00. HPT (horas-programador totales). . Definir un conjunto de metric as para evaluar la facilidad de entendimiento de un diagrama de actividad UML aplicando el metodo GQM. LCFHlLCFHvm < 1'30 => PROD='alta'. y PROD del subconjunto de proyectos simi lares.. 0'70:s. Los critelios de decision establecidos son: 1. La primera dimension compara el valor de CLCF del proyecto con el valor medio historico (CLCFvm) para de!enninar si el coste de cada linea es mas alto 0 bajo de 10 nonna!. LCFH = LCF IHPT. I!. CTP (coste total actual del proyecto. v. en unidades I11onetarias). LCFH (LCFHvm) y CTP del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120% ). CLCF. f g. Los criterios de decision son bidimensionales.~ RA.FOR. Para ello se usa un modelo de awllisis basado en extraer de una base historica de proyectos de la organizacion los valores medios de LCF. DE SISTE?vlAS DE !0. PROD (productividad de los programadores). LCFH/LCFHvm => PROD='muy alta'. 1'10:S. 111. e.dias HPD ~ ~ LCFH (Iineas de codigo fuente por hora de programador). 2.yL-\CI01\ 257 d. 0'90:S. LCFH/LCFHvm < 1'10 => PROD='nonnar. De la base histolica de proyectos se obtienen los valores medios de LCF. h. CTP CHP '" HPT CLCF (coste por linea de codigo fuente). 3.-:'!A C\PiTULO 9: 0. LCFHlLCFHvm < 0'70 => PROD='muy baja'. HPT. etc. 1. De esta manera. 'nonnal a pesar de productividad baja'. CAR (carestia del proyecto). IV. que se puede obtener a partir de la siguiente fOIl11Ula: HPT = L. los val ores de CAR seran cualitativos del tipo: 'muy alta pOl' baja productividad'. La segunda dimension simplemente compara PROD con PRO Dvm para ayudar a decidir si la razon de ese coste alto (0 bajo) pOl' linea es 0 no debida a la baja (0 alta) productividad. Definir utilizando la plantilla GQ(I)M los indicadores del ejercicio 1. LCFHiLCFHvm < 0'90 => PROD='baja'. CLCF = LCF/CTP.

Analizar que tipos de metricas son aplicables en cada nivel de madurez del modelo CMMI. Realizar un estudio bibliognifico sobre la aplicaci6n de la medici6n en la industria de desarrollo de software.258 C:\UDAD DE SISTEMf\S Il'-IFOIUvlA. 5. .TIeos 4.

fonnaci6n que contienen las bases 0 los almacenes de datos l ya que se han convertido en la principal henamienta para la toma de decisiones. Sin embargo. 1999)e inc1uso legal -basta recordar el articulo 4 del Titulo II de la actual LOPD (Del Peso. y cualquier otro repositorio de datos. capitalizar el conocimiento como lin activo principal y. INTRODUCCION Actualmente las organizaciones pueden almacenar inmensas cantidades de datos obtenidas a un precio relativamente bajo.1). Ademas. incluyendo en este termino los almacenes de datos (datalmrehollse).CAPiTULO 10 CALIDAD DE LA INFORMACION "Los en'ores callsados par los datos il1adecllados SOil Illucho lllel10reS que los que se debel1 a la total allsel1cia de datos" Charles Babbage 1. tanto operacionales como estrategicas. gI'andes perdidas financieras (Loshin. Es esencial poder asegurar la calidad de la in. 2001) 0 insatisfacci6n de los trabajadores (English. 1996). Esta poluci6n puede llegar a tener graves consecuencias tanto desde el punto de vista tecnico -como en la implementaci6n de almacenes de datos-. "las empresas deben gestionar la informacion como lin prodllcto importante. estos datos quizas no proporcionen infonnaci6n (Gardner. 1998). 2000)-.. pOl'que en algunos casos adolecen de problemas de poluci6n. de esta manera. . datamarts. I A partir de ahora se hablara de bases de datos en general. La calidad de los datos y de la infonnaci6n viene detenninada tanto por la calidad de la bases de datos como por la calidad de la presentaci6n de los datos (vel' la figura 10. etc. sobrevivir y prosperaI' ell la ecol1olllia digital" (Huang et al. como organizacional -perdida de c1ientes (Redman. inconsistencia. 1999).

agrupamientos. sincronizacion. La calidad de los propios datos (los datos que estan almacenados ya en la base de datos) viene detel111inada plincipalmente por los procesos de extraccion. y a nivel fisico -ya que el disei'iador tiene que elegir las tab las fisicas. Este tipo de calidad debe ser considerada en la etapa de seleccion de productos dentro del ciclo de vida de la base de datos y posteri0l111ente asegurada durante la i1l1plantacion y ad1l1inistracion del SGBD. particiones de datos. li1l1piado. se deben considerar tres aspectos: la calidad del SGBD (Sistema Gestor de Base de Datos) -relacionaL orientado a objetos. los indices.. pred01l1inantemente relacional con algunas extensiones. objeto-relacional. Para asegurar la calidad del SGBD. que l11eJor representan la base de datos logica y que facilitan su funcionalidad-. agregacion y carga que deben tener en cuenta ciertos requisitos . se puede usar un estil11dar intemacional como el ISO 9126 (vease capitulo 5). la calidad del modelo de datos (tanto conceptuaL logico como fisico) y la cali dad de los propios datos contenidos en la base de datos. Modelo que puede existir a nivel conceptual -expresado en E/R 0 UML-: a nivel logico. multidimensional. 0 alguno de los estudios comparativos de productos existentes.'vlATICOS Calidad de la Informaci6n ~~ Cali dad de la Base de Datos Calidad de la Presentaci6n ~ ~ Calidad del SGBD Calidad del Modelo de Datos Calidad de los Datos I Calidad del Modelo Conceptual I Calidad del Modelo L6gico Calidad del Modelo Fisico Figura 10. CaUdad de fa informacion . es l11UY importante que los datos de la base de datos reflejen COlTectamente el mundo reaL pero es tambien muy importante que los datos puedan ser interpretados conectamente. etc.260 C\UDAD DE SISTE'vl-\S INFOR.1.r de fa base de datos De hecho. filtrado. Como es logico tambien la calidad del modelo de la base de datos tiene una gran influencia en la calidad de la infol111acion. En la calidad de una base de datos.que 10 sopOlia. XML etc.

Por ello. CaUdad de los modelos conceptuales Ai111 cuando el modelado conceptual representa solo una porcion del esfuerzo total de desarTOllo de un SL su impacto en el resultado final es probablemente mucho mayor que el de cualquier otra fase.~ RA. com. cstabilidad. conocimiento de Ia . la mayoria no son estnlchlradas. complecion sintactica. . cxprcsi\·idad. de los propios datos y de la infol111acion que gestionan las empresas. ( 1997) compiecion. Batini ct al. COlTcccion semantica. usan a menudo se solapan. el modelado conceptual se ha conveI1ido en una tarea clave en las primeras etapas del ciclo de vida de los SI.1) Y han propuesto una serie de transformaciones con el objetivo de mejorar la calidad de los mlsmos. mientras que la calidad del proceso esta relacionada con como se desarTollan los modelos concephlales (el proceso). Cuando se habla del modelado conceptual. Tabla 10. CAUDAD DE LOS MODELOS DE DATOS 2. ( 199. Boman et al. minimalidad.ual. ALTORES PROPIEDADES Complccioll. Propiedades "deseables" para el modelo conceptual de datos Aunque estas Iistas mejorar la calidad en el definiciones imprecisas.ccion conccp.-\lA C.+) . enfoque conceptual. compiecion conceptual.:mprcsa. com::ccion Reingl1lber \1. mientras que las cuestiones relacionadas con la calidad del proceso estan parcialmente tratadas en Moody ( 1998) Y Maier (2001 ). Este capihllo se centra enla calidad del producto. La calidad del producto esta relacionada con las caracteristicas del modelo concephlal (el producto). Facilidad de comprension. ( 1992) lcgibilidad. Com:. especificacion con las del de propiedades proveen un punto de partida i!til para entender y model ado concephlal. sintactica.1. Algunos antores han definido la calidad de los modelos concephlales como una lista de propiedades "deseables" que debe satisfacer el modelo de datos (vel' tabla 10.1. se mezclan caracteristicas de la metodo y del lenguaje de modelado. Y Gregory \ \". (:xt(:nsibilidad y nOl1nalidad.-\LIDAD DE LA r~FORMACI6!\ 261 de calidad de datos de los usuarios: asi como de los procedimientos y procesos de mejora de la c:tlidad de datos existentes en la organizacion. se presupone la existencia . se debe distinguir entre la calidad del producto y la calidad del proceso. En este capihIlo se mostrani como se puede analizar y eshldiar la calidad del modelo de datos.-\PiTCLO 10: C. auto(:xpiicacion.cciotl. 2.

Aunque estos marcos son relevantes en el senti do de que contribuyen a un mejor entendimiento sobre el h'atamiento de la calidad de los modelos conceptuales. Modelo (l\'I): conjunto de todas las sentencias expresadas explicita implicitamente.2): G Audiencia (A): union del conjunto de actores individuales. 1994). G . 2. 0 imposibles de Una estrategia mas adecuada para abordar la calidad es definir marcos de referencia que organicen y estmcturen los conceptos claves y caracteristicas en el modelado conceptual de datos. Dominio (D): conjunto de todas las sentencias que sedan COlTectas y relevantes acerca del problema. evitando as! los sesgos en el proceso de evaluacion de su calidad. se presento en Lindland et al. basado en la teoria semiotica. por 10 que es necesario contar con medidas que pennitan evaluar la calidad de los modelos conceptuales de datos de fonna cuantitativa y objetiva. A continuacion se resumen algunos de estos marcos de referencia para la mejora de la cali dad de datos del modele conceptual. Ademas. Resulta evidente que definir solo "propiedades deseables" no es suficiente para evaluar la calidad. se han publicado algunos marcos de referencia que penni ten abordar la calidad en el model ado conceptual de una manera mas sistematica.1. (1995) se ha extendido este marco con el fin de incorporar el concepto de acuerdo social de Pohl (1994). (1994) con el objetivo de paliar las deficiencias detectadas en los enfoques de listas de propiedades.1. al mismo tiempo que se separan los objetivos de cali dad de los medios para alcanzarlos y se utiliza lill fundamento mate matico en su descripcion. con 10 que se pueden identificar los siguientes elementos (vease figura 10. En Krogstie et al. 0 G G Lenguaje (L): conjunto de todas las sentencias que se pueden expresar de acuerdo al vocabulario y la gramatica de los "lenguajes de modelado" utilizados.262 CAUDAD DE SISTE:VIAS INFORc\L~ TICOS de disefio/implementacion. ya que diferentes personas pueden dar diferentes interpretaciones sobre el mismo concepto. el conjunto de actores sociales organizacionales y el conjunto de actores tecnicos que necesitan relacionarse con el esquema. carecen de medidas cuantitativas que pennitan evaluar la calidad de los modelos conceptuales de datos de fonna objetiva. PROPUESTA DE LINDLAND ET AL.. y se presentan objetivos poco realistas alcanzar (Lindland et af. Este marco.

t t PRAGj\lL~ CALIDAD TICA ) INTERPRETACION DE LA AUDIENCIA CALIDAD SOCIAL Figura 10. Calidad pragmatica: cuyo objetivo es que el modelo sea comprendido. se considerani que un modelo tiene una mayor calidad semfmtica cuanto mejor sea la conespondencia entre el modelo conceptual que se ha disenado y el dominio que pretendemos representar.. Krogstie et al.. Calidad semantica: (percibida). <I> <I> <I> . Calidad social: que persigue distintos tipos de acuerdo tanto en la interpretacion del modelo como respecto al conocimiento del dominio. Sin embargo. ya que para disenar el esquema se debe acudir al conocimiento que tiene el publico sobre el dominio y para verificarlo se debe emplear la interpretacion que el publico hace del modelo.<. es imposible establecer 0 verificar directamente esta conespondencia.:.:. Como es natural. MODELO <I> CALIDAD SEMANTICA DOMINIO CALI DAD SINTACTICA . Conocimiento de los participantes (K): union de los conjw1tos de sentencias de todos los actores sociales individuales. que comprende tanto la validez (10 expresado en el modelo es conecto y relevante para el problema) como la complecion (el modelo contiene todas las sentencias acerca del dominio que son conectas y relevantes ). En este marco se prop one distinguir varios tipos de calidad: <I> Calidad sintactica: que viene detenninada por la conespondencia entre el modelo y ellenguaje. (1995).2.. como senalan los autores de este marco. Marco para la calidad del modelado conceptual. y cuyo objetivo es la con'eccion sintactica.J-' - LENGUAJE CONOCIMIENTO DEL PARTICIPANTE t "" CALIDAD SEMANTICA PERCIBIDA .: Ri\-MA CAPiTULO 10: CAUDAD DE lA INFORlvL-\CION 263 <I> Interpretacion de la audiencia (I): conjunto de todas las sentencias de las que la audiencia piensa que consta el modelo.

2 muestra los objetivos .y los medios para alcanzarlos de acuerdo los conceptos de cali dad propuestos en los marcos de Lindland et at. que si bien unos son extensiones de otros...y Krogstie et at.I.2.\lisis punto \-ista Resolucion cont1icto Fusi6n de modelos contlicto I I I I I I Tabla 10. Objetiyos y medios de conseguir la calidad (Krogstie et aI. . (1995). (1994) . La tabla 10.xpr.tCTICA OBJETfVOS I i MEDIOS ACTIHDADES I PROPIEDADES :'IlODELO Sintaxis fOTInul Semantica fOTInal I COlTeccion sintactica Validez \-iable I Verif Sinl<\ctica Verif Consistencia SE\L-l.. persiguen el mismo objetivo. I I I I I I I I I i I I I I I I I I I Explicacion Entrenamiento Ejecucion Animacioll Simulacion I I I I Ejecutabilidad I SOCL-l.:L Acuerdo \-iable ~[odelado :\n.264 C-\UDAD DE SISTE:V!AS NFOR"L.si\-a Estetica PRAGXIATICA Comprension \-iablc .\'TJCA Insercion sentencias Complccion viable Moditicabilidad BOlTado sentencias Insercion sentencias I SE\lA?\'TICA PERCIBIDA BOlTado sentencias Entrenamiento I Inspeccion \-isualizacion Filtrado Presentacion diag_ Paratl-ascar ! I j I Economia . Tleos TIPOS DE CAUDAD SINT.. 1995). Este marco prop one ademas distintos medios para mejorar los diferentes tipos de calidad. que es en tender el concepto de la cali dad en el modelado conceptual basandose en conceptos semi6ticos.

(1998).. 0 utilizacion o Estrategia de mejora: tecnica para meJorar la cali dad de los esquemas conceptuales. Implicado (stakeholder): persona involucrada en la construccion del esquema. Elementos del Marco de Moody y Shanks (1994).3): METODODE EVALUACION STAKEHOLDER ~ FACTOR D E .II1----iii!ilt>ilO> CALIDAD l\rIODELO -.CAPITULO 10: CAUDAD DE LA I0:FO~'vlACI6N 265 2. 4. se prop on en los ocho factores de calidad que aparecen enla figura 10. Pretende ayudar a los disefiadores a la hora de elegir entre distintas altemativas de disefio y de poder acomodar las distintas visiones de los distintos implicados ("stakeholders") en el proceso de model ado de datos. Para Moody estos factores significan: . Peso: que sirve para definir la importancia relativa de los factores de calidad. con un enfoque mas practico que el antelior.1.4. o o Factor de Calidad: propiedad deseable de un esquema conceptual.3. Valores: representan la valoracion de un factor de calidad por alguno de los implicados. PROPUESTA DE MOODY Y SHA1~KS Otro marco..2. o o o En la revision de este marco (Moody et aI. Metodo de evaluacion: modo sistematico 'de evaluar factores de calidad.. 1998). Este marco presenta los siguientes elementos relacionados con el esquema (vease figura 10. fue presentado por Moody y Shanks (1994) y refinado en Moody et a1..-~r / VALORACION ESTRATEGIA DE MEJORA Figura 10..

. Implementabilidad: facilidad con la que el esquema puede ser implementado dentro de las restricciones de tiempo. Comprensibilidad: facilidad con la que el esquema puede ser entendido. Simplicidad: significa que el esquema contiene los minimos constructores posibles. Integridad: grado en el que las reglas del negocio que se aplican a los datos estc'm definidas en el esquema conceptual.4: algunos calculados de fOl1na objetiva (por ejemplo. Moody (1998) propone 25 mehicas c1asificadas seglll1 los factores de calidad de la figura 10. Factores de calidad. el nllll1ero de entidades .4.3. 9 9 e 9 e e e usuano usuano usuano usuano / / MODELO DECALIDAD I' V analista analista admin. por ejemplo. (:Vloody et aI. datos desan'ollador Figura 10. 1998). Correccion: se refiere a si el esquema cumple las reglas de las tecnicas de modelado utilizadas. Este marco se ha validado en varios casos pn'icticos.TICOS £iRA-MA 9 Complecion: capacidad delmodelo de tener toda la infol1naci6n necesmia para cumplir los requisitos del usuario. presupuesto y tecnologia del proyecto. aumentar la implementabilidad del esquema puede acalTear una disminuci6n de su flexibilidad y compleci6n. en los que tambien se ha estudiado la influencia que ejercen unos factores sobre otros. as!. Integracion: nivel de consistencia del esquema con el resto de los datos de la organizaci6n. Flexibilidad: facilidad con la que el esquema se puede adaptar a los cambios en los requisitos. como muestra la tabla 10.266 CAUDAD DE SISTEMAS INFORc'vLA.

.c1\\) N" de eont1ictos con el modelo de datos corporativo N° de conflictos con [os sistemas existentes \'aloraci6n de los representanleS de todas las areas de negocio \' a[oraci6n de riesgo tccnico Valoraci6n de riesgo de planificaci6n Estimaci6n del coste de desarrollo N" de elementos fisicos incluidos en e[ modele de datos Tabla 10. .".4). COMPRE\'iSIBILIDAD '. Interacciones positivas y negativas entre factores..(. METRICAS I:-.\IEi\TABrLID.ltos . .i . RA-?vL'\ CAPiTULO 10: CAUDAD DE LA INFOR3vlACION 267 del esquema)... <:::) I ~ ~ -9 Z . .....:: ~ Sln'iPL'(CID. z .0 de constructores (aN E b1\" . hIPLDIE:\TABILIDAD N° de elementos del modelo de datos que no corresponden con requisitos de usuario 1\0 de requisitos de usuario no representados en e[ modelo de datos N" de elementos de datos quc corresponden a requisitos de usuario pero ddinidos de fomla inexacta N" de inconsistencias con eI modelo de procesos 1\" de reglas del negocio que no se hac en eumplir por elmodelo de datos N° de restriceiones de integlidad incluidas en eI modelo de datos que no eorresponden a politieas del negocio N" de elementos en eI modelo que est.. mientras que otros resultan de la puntuaci6n subjetiva de los implicados en el disefio (vease tabla 10. iVIetricas para evaluar la calidad de modelos E/R (Moody. ..\fPLE.W I:\TEGRIDAD + Tabla 10.J ~ I Q u .l Ci5 ~ ~ r_ ::< '~ I. FACTOR DE CALIDAD CmIPLECIO:-.. "2 0 ::::: ~ "" == a g "- Q Q .... •• FlEXIBILJDAD COMPLEtION l.TEGRACI6:-." de \'iolaciones a Jas fortnas nortnales N" de instaneias de redundancia en cl modele N° de entidades N° de cntidades e interrelaciones ).::::: c. 1998) . .: ~ Q -::: ! :3 ~ == . .: 2: ~ I Q u :::..3..4.W . SnlPLICIDAD I:-.TEGRIDAD FLEXIBILIDAD CO:\IPRE:\SIBILIDAD CORRECCI6:-. .in sujetos a cambios en el futuro Costes estimados de los cambios Importancia estrati:gica de los cambios Yaloraci6n de los usuarios sobre la comprensibi[idad del modelo Capacidad de los usuarios de interpretar elmodelo correctamente Valoraei6n de los desarrolladores de aplieaciones sobre la eomprensibi[idad del modele N"'de \'iolaeiones de las convenciones de modelado de d.

Este marco integra do puede aplicarse en cualquier etapa del proceso de modelado conceptual. E\ALL\CIO" Figura 10. la cual pennite entender la relacion entre ambos marcos y como uno infonna al ot·o. y los conceptos disjuntos son incorporados al mismo.268 CA. PROPUESTA DE SHAl'\fKS Y DARKE Shanks y Darke (1997) han propuesto integrar el marco de Moody y Shanks (1994) con el de Lindland et af. En dicha figura se indican los conceptos referentes a la cali dad en el modelado de datos basados en la teoria. ___-"I YALORES ! h':-------B~ ~IETODO DE 'pun. (1994).". Los conceptos que estan basados tanto en la practica como en la teOlia se muestran en la parte central (sombreada con un color mas oscuro) de la figura 10. :Yletamodelo propuesto por Shanks y Darke (1997) Los conceptos comunes son integrados en este marco. ya que ambos se complementan (este liltimo des de un punto de vista 111<1S teorico. como se muestra en la figlira 10. mientras que el de Moody y Shanks se enfoca mas hacia la practica) y ademas comparten conceptos: los implicados (stakeholders) podrian asimilarse al pllblico. y tiene en cuenta el concepto de calidad tanto en el modelado del producto como en el proceso de modelado delmismo.1.s I"'FOR. los objetivos y las propiedades a los factores de calidad y el concepto de modelo es compatible en los dos marcos (vease figura 10.LIDAD DE SISTDIA.5. y ademas los conceptos que soportan la evaluacion de la calidad en la practica.5).5.5.. .3.\L~TlCOS 2.

Concisi6n: se refiere a que el modelo EIR no tenga redundancia. Para obtener un modelo EIR de buena calidad. detenninan el compOltamiento del sistema.ibutos sean conectamente asignados a las entidades.uctura y el contenido. Los modelos E/R estan fonnados por dos componentes ontol6gicos: la estructllra y el contenido.·e la es1:J.uctura y el contenido. una metodologia y metricas para evaluar la calidad del modelo E/R. Consistencia: se refiere a si el modelo no muestra contradicciones. Los componentes ontol6gicos. Entre los factores que influyen en la calidad de la es1:J.uctura. II II .1. que considera dos tipos de componentes: de compOltamiento y ontol6gicos. Validez: se refiere al cumplimiento de plincipios tecnicos de disefio. PROPUESTA DE KESH Kesh (1995) propuso el desanollo de un modelo. Rendil11iento (R): se refiere a un disefio eficiente del diagrama EIR. relaciones y atJ. La estructura se refiere a las entidades y sus relaciones y el contenido se refiere a los a1:J. y la eficiencia es el nlllnero de entidades.6 muestra el marco de referencia utilizado para evaluar la calidaJ. es necesario evaluar la calidad tanto del contenido como de la estructura.6.ibutos de una entidad.uctura del problema que se esta modelando.' 269 2. Precisi6n (P): se refiere a la exactitud con que el diagral11a EIR refleja el problema que se esta modelando.ibutos de las entidades. Compleci6n: se refiere a que todos los atlibutos que sean relevantes deb en ser incluidos. existe una fuerte relaci6n en1:J.LRA-MA CAPiTULO 10: CAUDAD DE LA INFOIUvIACI01'. la es1:J. conegido y extendido ante futuros requerirnientos. II II Como muestra la figura 10.ibutos con relaci6n al tipo de tarea que la base de datos representa. Validez: se refiere a que los a1:J.4. se refiere a S1 el disefio delmodelo EIR refleja la es1:J. se pueden citar: II Adecuaci6n al problema: la adecuaci6n de la eStlLlctura. II II II Y entre los facto res que influyen en la calidad del contenido. La figura 10. se tienen: II Cohesi6n: se refiere a la cercania que existe entre los atJ. Factores que influyen en la calidad del comportamiento: II Mantenibilidad (M): es la facilidad con que un diagrama E/R puede ser l110dificado.

1995) La tabla 10.6. . Una vez construido un modelo EIR se. Los disenadores y los usuarios tienen diferentes puntos de vista acerca de la usabilidad. Calcular el valor de cada componente ontol6gico en fomm individual.5 muestra como los factores ontol6gicos afectan a los factores de comportamiento. debe evaluar su calidad utilizando la siguiente metodologia: 1. Para componente de comportamiento combinar los valores de los componentes ontol6gicos que Ie son relevantes. Marco de Referenda para la evaluacion de la calidad (Kesh. Figura 10.270 CAUDAD DE SISTElvLA. 2. 3. por eso es conveniente subdividirla en usabilidad para el usuario CUU) y usabilidad para el disenador (UD). AderTI<ls Kesh (1995) prop one una metodologia y metricas para evaluar la calidad de los modelos EIR que detallamos a continuaci6n. Combinar los val ores de los componentes de comportamiento para calcular el valor global de la calidad.S ll\'FORt'vlATICOS ©RA-!v1A It Usabilidad: se refiere a si un diagrama EIR es conveniente y pnictico para su uso.

.. Si el valor de un componente ontol6gico esta por debajo de un cielto valor.\ClON 271 4. USABILIDAD 1·······USUAlUO . . Cohesi6n •. como muestra la tabla 10... 2.". Schuette y Rotthowe (1998) definen: .• I . Especialmente en proyectos donde intervienen muchos disefiadores tales reglas son absolutamente necesarias.•.•..... El hecho de resaltar la subjetividad enfatiza la • importancia del disefiador... Siguiendo ciertas reglas durante el proceso de modelado es posible construir modelos subjetivamente comparables. podria entender los modelos. quien no estuvo involucrado en el proceso de modelado.<'.·· i·... DliHENSIO:-''ES ..5. Concisi6n Compleci6n ....5.. Validez I Tabla 10. . debe ser investigado y su valor debe ser mejorado antes de seguir adelante..1. solo si conoce las reglas subyacentes del proceso de modelado...< .!"lTENF BILlDAD IJ>REbSIONIRENl)~nE~tO ..5.-MA CAPiTULO 10: CAUDAD DE LA INFORJvl.. Adelmis.~~u. un usuario del modelo.:. Como la subjetividad del modelado no puede ser eliminada completamente pero solo control ada. es necesario contar con reglas que tengan que ser seguidas en el proceso de modelado. :> : . PROPUESTA DE SCHUETTE Y ROTTHOWE La propuesta de Schuette y Rotthowe (1998) se basa en la suposici6n de que la postura subjetiva del modelador es un aspecto relevante para el resultado del model ado conceptual y por 10 tanto tal subjetividad debe ser manejada y comprendida.~"~w Validez Consistencia X X X X X X X X X X X X X X X I ... USABILlDtill·· DISEl'/ADOR·· ·j\h. teniendo en cuenta la influencia que tienen los factores ontol6gicos sobre los factores de comportamiento. Relaci6n entre los factores ontol6gicos y los de comportamiento Kesh (1995) ademas propone una medida para ca1cular el valor global de la calidad. El enfasis de la subjetividad en el proceso de modelado requiere medidas especificas para el manejo de la subjetividad para poder desan'ollar modelos subjetivamente comparables y probables.. Adecuaci6n al X problema "'.·RiI..

272 CAUDAD DE SISTE:VL.6. La calidad de los modelos se basa en recomendaciones para lograra un eficiente.6 muestra los objetivos de cada uno de los seis principios generales de GoM. comprensivo Y COlTecto disefio de los modelos de infom1aci6n. . la eficiencia econ6mica del model ado y medidas para mejorar la claridad delmodelo. ademas del esfuerzo de estandarizaci6n. EiI La idea de los autores al proponer una Guia de Modelado (GoM) es presentar un marco de principios que mejore la cali dad de los modelos de infom1aci6n reduciendo el slIbjetivislIlo en el proceso de modelado de la infonnaci6n.-S IKFOR.\rquitectura. que son los que fonnan la base de la Arquitectura GoM. PRINCIPIOS I . La arquitectura GoM.£ de los sistemas de infonnacion Comparabilidad a nivel de meta modelo Transfonnacion completa Traduccion consistente Comparabilidad a nivel del modelo I Principio del disel10 sistematico I I I I I Principio de comparabilidad Tabla 10.\Li. que es un marco estructural en el cual son ubicados cada uno de los componentes de esta guia.. OBJETlVOS 1 I Principio de adecuacion de la construccion I Principio de adecuacion dellenguaje Principio de la eficiencia economica Principio de claridad Consenso a cerca de la definicion de la definicion del problema Consenso a cerca de la representacion del modelo Consistencia intra-modelo Consistencia inter-modelo Minimalidad Correccion dellenguaje Adaptacion dellenguaje Poder Sel11<lntico Fonnalizacion Comprensibilidad dellenguaje Consenso La comprensibilidad y aplicacion dellenguaje Comparabilidad estructura sistematica Disefio jerarquico Disefio del esquema Filtrado Filtros metodicos Filtros de contenido Consistencia inter-modelo entre los modelos de la estructura y el comportamiento . tiene en cuenta la inteiTelaci6n entre el problema a ser modelado y su representaci6n. La tabla 10. TICOS EiI Una Guia de modelado (GoM) obtenida a partir de los problemas que surgen del proceso subjetivo de disefio de un sistema GoM contiene seis principios que pem1iten mejoran la calidad del model ado de la infonnaci6n. Principios de la Guia de Modelado (GoM) La Guia del Modelado.

Nllmero total de Atributos Compuestos en un modelo ER. propuestas por muy diferentes autores. 1997). etc. 2. . Ademas. aunque las bases de datos se han convertido en el corazon de los Sistemas de InfoTI11acion (SI) mas relevantes para el n.-'l.-MA CAPiTULO 10: C-'l.-'I. el (mico cliterio que se ha venido aplicando tradicionalmente es la teolia de la nonnalizacion para las bases de datos relacionales. Numero total de Relaciones Reflexivas que existen en un modelo ER.1..7). siguiendo la nocion de complejidad estructural 0 del producto de Henderson-Sellers (1996). tales como entidades/clases. existiendo centenares de metric as de software.lerzo de desarrollo (MacDonnell et al. teniendo en cuenta los atributos de las relaciones como los de las entidades. teniendo en cuenta solamente relaciones comunes. CaUdad de los modelos logicos A nivel logico. relaciones. 1994). Parece sorprendente que. Sin embargo. dificil y costosa.[ R. Nlllnero total de Atributos Multiyaluados en un modelo ER. POl' 10 tanto no es aconsejable definir una medida general para su complejidad (Fenton.mcionamiento de la sociedad.7.' NE NA NTIA NCA NMVA NN"R NM:NR I Nl:NR NBinaryR NN-AryR NIS AR NretR NRR Numero total de Entidades dentro de un modelo ER. En este nlunero se incluyen atributos simples. 1998).\jACrOl\' 273 2. Nlllnero total de Relaciones M:N en un modelo ER. l\Ietricas para modelos ER (Piattini et al. generalizaciones. Ello justifica la gran presencia de me1:Iicas orientadas a programas que podemos encon1:I'ar en la literatura. NOMBRE DEFE\l. Nlunero total de Atributos Derivados en una modelo ER. en muchos aspectos de un SI como el esn.. Numero total de Relaciones I:N (incluyendo tambien relaciones I: I) en un modelo ER. En este caso. el tamano y la naturaleza de los datos pueden influir. compuestos y multiyaluados. se considera una relaci6n por cada par padre-hijo. Numero total de Relaciones en una modelo ER. I Numero de Relaciones Redundantes en un modelo ER.6. PROPUESTA DEL GRUPO ALARCOS La complejidad de un modelo conceptual puede estar altamente influenciada pOl' los diferentes elementos que 10 componen. Numero total de Relaciones Binarias en un modelo ER. a1:Iibutos. (2001) han propuesto un conjunto de medidas para mediI' la complejidad estmctural de un modelo ER (vel' tabla 10. dentro de la relaci6n Es Un. Tabla 10.UD. su disei'io sigue siendo una tarea larga. 2001). Esta situacion puede ser explicada ya que hasta hace no demasiado tiempo. Nlunero total de Atributos en un modelo ER. las bases de datos jugaban un papel relativamente secundalio dentro de los sistemas de infonnacion siendo los programas los verdaderos protagonistas.2. en gran medida. Siguiendo este razonamiento Piattini et af. las metricas para bases de datos han sido descuidadas (Sneed y Foshag. Numero total de Relaciones Es_Un (generalizaci6nJespecializaci6n) que existen en un modelo I ER.CION . Nlllnero total de Relaciones N-arias (no binarias) en un modelo ER.D DE LA INFOR.

seglin Li y Cheng (1987) estan influenciados por la complejidad. activas. Para cada dimensi6n del modele multidimensional existe una tabla dimensional (por ejemplo. centraremos el estudio en las bases de datos relacionales. Por tanto.2. 2. las metricas de producto pueden ser divididas en intra-modulares e inter-modulares (Kitchenham y Linkman. 2000). tres de los factores que influyen en la mantenibilidad son la analizabilidad. la cambiabilidad y la facilidad de prueba. tiempo) que almacena la infonnaci6n acerca de estas dimensiones (Jarke et al. producto.9 se muestran los resultados obtenidos al aplicarla al ejemplo de la figura 10. . BASES DE DATOS MULTIDIMENSIONALES Un disefio multidimensional es un reflejo directo de la manera en que se yen los procesos de negocio. tanto inteilliodular como intramodular es en la que se ha centrado el trabajo del grupo Alarcos. en la tabla 10. 2. Concretamente. 1997). 1998). Como ejemplo de uso de estas metricas. Las medici ones se denorninan hechos 0 medidas. los cuales a su vez.1. En la complejidad del producto. Los parametros por los que un hecho puede ser visto se denominan dimensiones (Adamson y Venerable. a traves de 10 cual estaremos tambien rnidiendo la calidad de las mismas.2.274 CAUDAD DE SISTE1vLA-S INFOIUvL. factores cognitivos humanos y complejidad del producto.2. Henderson-Sellers (1996) divide la complejidad en tres: complejidad computacional.7 (Elmasri y Navathe. 0 inventario).. ventas. el objetivo fundamental fue disefiar metric as de producto (que capturen las caracteristicas especificas de los diferentes tipos de bases de datos) que nos pennitan medir la complejidad de las bases de datos. Estos disefios capturan las mediciones de importancia de un negocio y los parametros por los que se identifican estas mediciones.8.8 reswne las plincipales metric as para modelos relacionales.\TICOS :9 RA-1vLA- Seglin la ISO 9126. objeto-relacionales y multidimensionales (almacenes de datos). A su vez. Las medidas de interes es almacenan en la tabla de hechos (por ejemplo. complejidad psicol6gica y complejidad representacional. los cuales consisten en una tabla central y varias tablas de dimensi6n. Nonnalmente los modelos de datos multidimensionales se representan como esquemas en estrella en bases de datos relacionales. 1990). cuyo grafo relacional asociado se representa en la figura 10. BASES DE DATOS RELACIONALES La tabla 10. y para la psicol6gica define tres componentes: complejidad del problema.

Depth of the Referential Tree.)) definida como el porcentaje de atributos del esquema que son c1aves ajenas NFK RFK NA Tabla 10. NA.s. Number of Tables COS.8. NA(T). Cohesion of the Schema Definida como la profundidad maxima de todos los caminos referenciales del grafo que se forma. definida como la relacion entre el numero de tab las en tercera fom1a nonnal (0 superior) entre el numero total de tablas cs Ratio de Normalidad.~ (DRT(T.) i=l Profundidad del Arbol Referencial DRT. Resumen de Metricas para el Modelo Relacional .CAPiTULO 10: CAUDAD DE LA INFORJvlACION 275 . Nonnality Ratio NR= NT3NF NT Siendo NT31\Tf es el numero de tab las en 3NF definida como el numero total de atributos que hay en el esquema ST i=1 Numerode Atributos. tomando la tabla T como el nodo raiz del grafo y todas las tablas relacionadas con T mediante integridad referencial como el resto de nodos y siendo las relaciones de integridad referenciallos arcos del mismo definida como el porcentaje de atributos de la tabla T que son c1aves ajenas RFK (T) = N~K (T) iVA (T) definida como el numero total de tab las que hay en el esquema definida como la suma del numero de tablas al cuadrado que hay en cada componente no conexa del grafo del esquema.METRICA NOTACION I .\T Numero de Claves Ajenas definida como el numero total de claves ajenas que hay definidas en el esquema NFK = INFK(I. RFK(T). Number of Attributes NFK. Number of Foreign Keys NA = L: NA(I. definida como el numero de atributos de una tabla T definida como el numero de c1aves ajenas de una tabla T Numero de Atributos de una Tabla Numerode Claves Ajenas Profundidad del Arbol Referencial de una Tabla Ratio de Claves Ajenas de una Tabla Numero de Tablas. Ratio of Foreign Key = max. Number of Foreign Keys DRT(T).. cos = INTr. NR. Ratio ofForeign Key NT.) . siendo los nodos de este grafo las tab las del esquema y los arcos las relaciones de integridad referencial Cohesion del Esquema. Depth of the Referential Tree Definida como la profundidad maxima de todos los caminos referenciales del grafo que se fonna tomando las tablas del esquema como los nodos y las relaciones de integridad referencial como los arcos del mismo DRT Ratio de Claves Ajenas RFK. Number of Attributes NFK(T). .

l\O?vIBRE_DEPEPiD). FOREIG?\ KEY (NU\ID) REFERENCES DEPART. SEXO CHAR.I) NOT?\ULL. NU\IEROD INT NOT NULL. CONSTRAINT CLPDEPTO PRI\lARY KEY (NUMEROD). APELLIDO VARCHAR(I5) NOT NULL.'SSSUPER) REFERENCES E\IPLE. COPiSTRA.li\1 CLESCPERE\IP FOREIGN KEY C-.YIPLEADO (({SS). FOREIGN KEY (NU\IEROD) REFERENCES DEPARTAMENTO (PiU. Esquema del Ejemplo .VIEROD) ON DELETE CASCADE O?\ UPDATE CASCADE): CREATE TA. LUGARD). CONSTRAINT CLEGTEDEPTO FOREIGN KE'{ (NSSGTE) REFERENCES EMPLEADO(NSSJ ON DELETE SET DEF. ?\lI\1EROPR INT NOT l\ULL.OMBRED).--\DO(NSS) ON UPDATE CASCADE.--\UL T ON UPDATE CASCADE): CREATE TABLE LUGAR_DEPTS ( NU\IEROD INT NOT NULL. ND INT NOT MiLL.-\ TE TABLE DIPLEADO( NO\IBREP VARCHAR( 15) NOT NULL. PRl. NSS CHAR(9) NOT NeLL. S. FOREiGPi KEY (NSSE) REFEREPiCES EMPLE. RELACIOl\ VARCHAR(8). UNIQUE (NOMBREP). FOREIGN KE'{ (({U\IP) REFERENCES PROYECTO (({UMEROP)): CREATE T. INIC CHAR.IP PRl\IARY KEY (PiSS). ({UMP). CO'\STRAIl\T CLSDEPTO UNIQUEC". CO'\STRAJNT CLPP. l\U\1D I?\T NOT PiULL. DIRECCIOPi VARCH. FECHAEN DATE.-\L-\RIO DECIMAL(IO.-\DO (NSS)): Figura 10.-\BLE DEPE:\DIE:\TE ( NSSE CHAR(9) NOT l\UL NO\1BRE DEPEND VARCHAR(l5) 1\'OT l\UL.-\R(30).BLE PROYECTO ( NO\1BREPR V.YIEROD)): CREATE TABLE TR-\BAJA_E:\ ( PiOTNULL. NSSSUPER CHAR(9). LUGARPR VARCHAR(I5).Il\T CLEDEPTOE\IP FOREIGPi KEY (PiD) REFERENCES DEPARTA\IENTO CPiU'VIEROD) ON DELETE SET DEFAULT ON CPDA TE CASCADE): CRE. FOREIGN KEY (NSSE) REFERENCES E.-\\IENTO (({U. FECHAINICGTE DATE. SEXO CHAR. FECHAAl\ DATE.-\TE TABLE DEPARTAME:\TO NO\IBRED VARCHAR(l5) NOTl'\uLL. NSSE CHAR(9) NUMP Il\T l\OT1\'UL.2). PiSSGTE CHAR(9) NOT ?\ULL. LUGARD VARCHAR(l5) NOT NULL.7. ON DELETE SET NULL COPiSTRA. PRIMARY KEY (l\U\lEROPJ. PRll\IAR'{ KEY (NU?vIEROD. PRI\!:-\RY KEY (({SSE.--\RCHAR( 15) NOT NUL.276 CALIDAD DE SISTDL-\S INFOR\lATICOS CRE.vL-\RY KEY (i'iSSE. HORAS DECEvL-\L(3.

:I . Ejecuci6nProducci6n).:I 4 5 .9 se puede observar el ejemplo de un esquema multidimensional. Ingrediente.S. .) l/4 li2 114 2/3 :: . Grafo Relacional del Ejemplo I I Enla figura 10. .[ R/\-:vIA CAPiTULO 10: DE LA INFOR. 277 NA(f) E:'>IPLEADO DEPARTA:'>IE:-iTO LCGARES DEPTS PROYECTO TR-\BAJA E:-i DEPE:-iDlE:-iTE ESQCDIA l\TK(T) DRT(T) RFK(T) COS NR NA NFK DRT RFK 10 4 :: I I I 3 I /~ . en el que se tienen dos tab las de hechos (HechosProducci6n y Usolngrediente) y cinco tab las dimensionales (Producci6n.:I 3 2 I 5 1/5 36 I 8 8 5 217 Tabla 10.9. Momento. Valores de las distintas metricas para el ejemplo C Empleado Trabaja_En "" "" "'I" Departamento A1 t+ -+ Dependiente ~ii' Proyecto Lugares_Depts LL I .\L-\CIO". Instalaci6n. Figura 10.

METRfCA DESCRIPCION ]\iA(T) 0:FK(T) Nlimero de atribulos de una tabla Numero de claws ajenas de una tabla Tabla 10. . Nivel de Estrella y Nivel de Esquema Por ello. TICOS ©RA.J\LA.·1-.Gestorlnstalaci6n Estado CodEjecuci6nProducci6n CodProducci6n Codlnstalaci6n Momenta CodMomento CodMomento CantidadProduccion .IA Producci6n CodProducto NombreProducto Receta ConGas Oesnatado UnidadProduccion GestorProducci6n Instalaci6n Codlnstalacion Nombrelnstalacion Localizacionlnstalaci6n HechosProducci6n l~--/~ ----~-------. 1998) A la hora de definir metricas para modelos de datos de almacenes de datos se calculanln a tres niveles distintos: Nivel de Tabla.9. Ejemplo de un almacen de datos (Adamson y Venerable.1 L los valores obtenidos de esas metIicas para el esquema de la figura 10.2. 2001) 2.2.10 se pueden observar las metI-icas definidas a nivel de tabla y en la tabla 10. Metricas a niyel de tabla. Metricas a nivel de Tabla En la tabla 10.10.278 CAUDAD DE SISTEivV\S INFOR.11. se definen metIicas para estos tres niveles (Calero et al. I TABLAS Ejecucion Produccion Ingrediente Instalaeion Momento Produccion 7 0 5 5 0 6 Hechos Produce ion 5 4 Uso Ingredientes 7 5 (T) NA(T) NFK(T) 5 0 I 0 0 Tabla 10.9.1.'" 1-· Ingrediente Codlngrediente Nombrelngrediente Proveedor Forma UnidadMedida -- ~--- I Figura 10.Fecha NombreMes Usolngrediente NumeroMes Ano CodProduccion 1-Temporada Codlnstalaci6n CodEjecuci6nProduccion CodMomento Ejecuci6nProduccion Codlngrediente Temporada CodEjecuci6nProducci6n CosteTotal NombreProducci6n LineaProducci6n CapacidadMensualLineaProduccion UnidadMedidaCapacidad 1"-"-'. Valores de las metricas a niYel de tabla.

Las metricas se han validado mediante diversos experimentos (Serrano et ai. ?'\llll1ero de atlibutos de la tabla de hechos que son claves I RFK(S) ajenas Tabla 10. de la tabla de hechos de la estrella Nllll1ero de atributos de la estrella.12. en las que hemos obtenido que las metricas NFT (Nlnnero de tab las de hechos). Valores para las metricas a nivel de estrella. METRlCA DESCRlPCIO:-.TE I NA 28 35 NFK --+ 5 I I I RSA 23. I ?'\llll1ero de claves ajenas de una estrella Ratio de atributos de la estrella.12) para el esquema del ejemplo que se esta estudiando. NOT(S) NT(S) NAOT(S) NAFT(S) NA(S) ?\FK(S) RSA(S) Numero de tab las dimensionales de una estrella Nllmero de tab las de la estrella Numero de atributos de las tab las dimensionales de una estrella NLlll1ero de atributo. J I USOI:sGREDIE:-. i\-Ietrica a nivel de Estrella. e1emento principal de un a1macen de datos. I I I HECHOSPRODt:CCIO:-.12. Metricas a nivel de Estrella A continuaci6n se detail an.2. en 1a tabla 10. . 2004). 2. las metricas al nivel del esquema de a1macen de datos completo.2.9. En 1a tabla 10.13. NLullero de atributos de las tab las dimensionales di\-idido por el nlllllero de atributos de las tabla de hechos Ratio de clm-es ajenas.15 se puede observar los valores que obtienen las metricas del nivel de esquema para e1 esquema de 1a figura 10. En la tabla 10. 2002. Metricas a nivel de Esquema Por llltililO se presentan.14.5 287 NOT --+ 5 I I I NT 5 6 I I I NAOT 7' _J 28 I I I NAFT 5 7 RFK 4/28 5/35 Tabla 10.3.CAPiTULO 10: CAUDAD DE LA Il\'FORJvlACION 279 2.2.2.13 se puede observar los valores de las metricas de nivel de estrella (ver tabla 10.. e1 cual puede contener una 0 varias estrellas. NT (Nlrmero de tablas) y NFK (Nlnnero de c1aves ajenas) parecen ser buenos indicadores de la comp1ejidad de los almacenes de datos.2. en 1a tabla 10. METRIC-\. las metric as propuestas para e1 nive1 de estrella.

Nllll1ero de atributos que son claves ajenas Ratio de atributos de las tab las dimensionales compartidas. Numero de atributos de las tab las dimensionales RScA(Sc) dividido por el nllll1ero de atributos de las tablas de hechos RFK(Sc) Ratio de claws ajenas.\L. Cantidad de tablas dimensionales por cada tabla de hechos Ratio de anibutos del esquema.280 CAUDAD DE SISTE\lAS INFOR.) I I I I 2812 23140 I I NADT " I Tabla 10. NllIl1ero de atributos del RSDTA(Sc) esquema que son compartidos ! I ! I I Tabla 10. Cantidad de tablas dimensionales que NSDT(Sc) NT(Sc) NAFT(Sc) NADT(Sc) NASDT(Sc) NA(Sc) NFK(Sc) I I RSDT(Sc) estan relacionadas con mas de una estrella RT(Sc) Ratio de tablas.14.\TICOS r-----~~~~----. Metricas a nhel de Esquema METRIC\ VALOR METRICA I I I I I I VALOR I I I METRIC.". Ratio de de tablas dimensionales compartidas. Valores para las metric as a ninl de Esquema .15. I I VALOR I : NA NFK NDT NT 40 9 NAFT RFK NFT 12 RSDT RT RScA RSDTA 45 5.r------------------------~~==~~~~--------------------_J ~a NFT(Sc) NDT(Sc) ~~~ l Nlllnero de tab las de hechos del esquema I Numero de tab las de dimension del esquema Nllll1ero de tab las dimensionales compartidas por !11:)S de una estrella Numero de tab las del esquema Nllll1ero de atributos de las tab las de hechos del esquema NllIl1ero de atributos de las tablas de dimension del esquema Nllmero de atributos de las tab las de dimension compartidas Nllll1ero de atributos del esquema Nllll1ero de claves ajenas del esquema.~2 940 ') I I I 5 7 28 I I NSDT NASDT 4 -.

y metricas asociadas a esas dimensiones. Strong et al. 1999. Pero todos los autores estim de acuerdo en que la calidad de datos es un concepto multidimensional que comprende distintos aspectos seglm las necesidades de los consumidores de datos 0 de los diseiladores de sistemas. 2001). English ( 1999).\: R. Muchos aLltores como Redman (1996). Muchas de estas metodologias de eleccion de dimensiones de calidad de datos llevan aparejada la definicion de un conjunto de dimensiones por parte del autor que sirven como referencia para su aplicacion. 1996) 0 los tipos de investigacion realizadas (Huang et al. 1999). Redman (1996) explica un procedimiento mediante el cual es posible obtener las dimensiones de calidad de datos a partir de los requisitos de calidad de datos de los usuarios y de la cadena de intol111acion: se retmen los requisitos de cali dad de datos de los usuarios y se catalogan... 'Nand y Wang. identiticando adecuadamente las necesidades y preferencias de todos los usuarios para posteri0l111ente intentar compatibilizarlas.. (1997a) han explicado como identiticar estas dimensiones de calidad de datos e incluso como medir ciertos aspectos caracteristicos de calidad de datos en ciertas aplicaciones y entomos. se comprueba la validez de la dimension elegida. As! es posible encontrar un catalogo de dimensiones de calidad para entomos medicos (Kosar. Es posible llegar a necesitar un conjunto de varias dimensiones para detinir el estado de la cali dad de datos y de informacion en una detel111inado aplicacion (Huang et al. Estas a su \ez pueden dividirse en otras que complementen su significado (ISO. Por ttltimo. 1999: . 1994) 0 simplemente la f01111a en 1a que se usan los datos (English. Una estrategia habitual que se suele utilizar para detel1ninar el grado de cali dad de datos de una aplicacion es detinir un marco de trabajo para detel111inar las dimensiones de calidad de datos para un contexto.-\D DE L-\ INFOR)'L-'. 2001 a). CAUDAD DE DATOS Una vez que se ha eShldiado la cali dad de los modelos de datos y como medirlo. Por otro lado. como pueden ser el ciclo de vida de los datos (Redman. con 10 que son nlertemente dependientes del contexto (Eppler. Este proceso es iterativo hasta obtener un conjunto consistente de dimensiones de calidad de datos. La e\'aluacion de estos marcos rev-ela con demasiada tiecuencia que los marcos de referencia han sido definidos para un dominio.CION 281 3. En la literahlra se intenta definir este concepto en nmcion de unos deter111inados criterios. (1997b) proponen LIl10S procedimientos de identiticacion de dimensiones de calidad datos consistentes en aislar problemas frecuentes con los datos. teniendo en cuenta su detinicion y como afectan a los datos existentes. Las dimensiones de calidad de datos y de infol111acion son criterios racionales que representan los requisitos de los mediante los cuales es posible juzgar la cali dad de un dato. que puede ser generico 0 bien especia1izado en un area. Para empezar es necesario definir el concepto de calidad de los propios datos.-\-\!A CAPiTCLO 10: CALlD. 1999). EI problema radica en la diticultad para identiticar las dimensiones de calidad para cada uno de estos componentes. Strong et ai. Despues de haberlas catalogado se escriben de f0I111a que los disei'iadores puedan ar'iadirlas a las especiticaciones del sistema.. se atl-onta ahora el hecho de medir la calidad de los propios datos almacenados en la base de datos.

2003). Sea cual sea el metodo de elecci6n de las dimensiones. Shankaranarayan et af. 2002). 2004). (1997a). Credibilidad.. Representaci6n Consistente Tabla 10. Cantidad de Datos Interpretabilidad.\TICOS Davidson et af. En Wand y Wang (1996) se . donde se establece un conjunto de cuatro categolias de dimensiones de calidad. 2003)..UEGORIADt CAUDAD DE DATOS DIMENSlONES DE CALlDADDE DATOS. es posible que este esquema no satisfaga con-ectamente todas las necesidades de los usuarios (Eppler. (2002) esto es imposible debido al hecho de que la calidad de datos y de infomlaci6n depende fueltemente de los problemas particulares que las organizaciones tienen con sus datos y su infoTIl1aci6n. Dimensiones de Calidad de Datos de Strong et al. C. Oportunidad. Como se sabe. Valor Afiadido. de diseno. as! que la cali dad de los datos estara relacionada con el proceso de captura. la calidad de un producto depende del proceso mediante el cual se disena y produce el producto. 2002). Facilidad de entendimiento. sistemas cooperativos (Mecella et aI. el numero de las elegidas que fOTIl1aran este conjunto debe ser 6ptimo y minimo: optimo para que represente convenientemente la calidad de datos en la base de datos y minimo para evitar el gasto imlecesario de recursos y la complejidad computacional. para pequenos negocios (Leonowich-Graham y Willshire. 2004). No obstante un esquema que empieza a ser COmlll1mente utilizado para la elecci6n de las dimensiones de calidad de datos es el propuesto por Strong et af. para sistemas de apoyo a la decisi6n (Gendron y D'Onofrio. 2002.. Uno de los casos mas impOltantes es el rol de la persona que va a utilizar el recurso cuya dimensi6n de calidad de datos y de infoTInacion se pretende definir (Gialmocaro et aI.16: . para teolias evolucionista de la calidad de los datos (Liu y Chi. Otro de los problemas que se puede encontrar a la hora de definir el catalogo de dimensiones es la cantidad de factores que pueden afectar a dicha dimension. militares (Burzynski. Acceso Seguro Relevancia. Representaci6n Representacional Concisa. para la web (Eppler y Muezenmayer. pero como afiTInan Pipino et af. Intrinsecas Accesibilidad Contextual Exactitud.282 CAUDAD DE SISTEMAS IN1'ORIvL. 0 de utilizaci6n de los mismos..16. y los factores que condicionan la elecci6n de las climensiones. Reputaci6n Accesibilidad. 2003).. Objetividad. 2002) e incluso para "COIparate Hal/seliafding" (Madnick et af. 1998). y se podlia pretender desan-ollar un modele de referencia universal valido para cualquier situaci6n. 1999). Compleci6n. mostradas en la tabla 10. (1997) De todos modos.

(1999) se prop one considerar diferentes tipos de metric as conespondientes a esas componentes: subjetivas (basadas en el juicio de los usuarios de los datos). directivo de infonnatica. por un lado."" FUENTE DELADEI'1C:!ENCIA . objetivas independientes de la aplicaci6n (como la conecci6n) y objetivas dependientes de la aplicaci6n (especificas para un dominio detenrunado). Por tanto.17. Representacion impropia: Complecion Estados SI 2 ausentes Representacion impropia: No ambigtiedad Varios estados del MR3 mapeados al mismo estado SI Estados SI sin sentido y confusion: mapeo a Significacion estado sin senti do Correccion Confusion: mapeo a un estado incorrecto operacion Fallo en la operacion Fallo en el diseiio y fallo en la Fallo en el diseiio Fallo en el diseiio Tabla 10. Al igual que pasa con los miembros y 6rganos del cuerpo humano. las empresas tendran que. 2 SI = Sistema de Informacion MR = Mundo Real 3 .17. y su calidad se deteriora (On. Dado que la calidad tiene componentes objetivas y subjetivas (Pipino et aI. vease tabla 10. creadores y suministradores de datos. En Huang et al. La tabla 10. hay que tener en cuenta. desde un punto de vista practico.-MA CAPiTULO 10: CAUDAD DE LA INFORJ'v1ACION 283 analizan algunas de las causas de la mala calidad de los datos debida a deficiencias en disefio basandose en principios onto16gicos. mienh'as que por otro deberan implementar un proceso con el fin de evaluar la cali dad de la infom1aci6n de que disponen. DIMENSION CALIDADDE NATUR."-LEZ--\ DEL-\ DEEICIE1\iOA DATOS . disefiadores. 1998).GRA. que las mayores deficiencias en la calidad de los datos provienen de su no utilizaci6n. los datos que no se utilizan tenninan "atrofiandose". definir una politica de calidad que establezca las obligaciones de cada rol (en general. es necesario catalogar los requisitos de calidad de datos de los usuarios segun unas detenninadas dimensiones de calidad. De todos modos. operadores. 2002). Calidad de los datos y deficiencias del diseiio.18 muestra algunos ejemplos de dimensiones de calidad que pueden tener una medici6n objetiva y otras que pueden tener una medici6n subjetiva.) con el fin de asegurar la calidad de los datos en todas sus dimensiones. etc.

I Los datos son tacilmentt: comprensibles I I Los datos pueden ser considerados como creibles y verdaderos.1.\FO~\!''\ TICOS iZ R_-\-\!A DI"\<IE7\5107\ DEH7\ICI07\ :\ccesibilidad Cantidad apropiada de datos C omplecion Comprenslbilidad Credibilidad Disponibilidad temporal Facilidad de manipulacion InteIlxetabilidad Libres de en'or ObjetiYldad Releyancia I Los datos estan disponiblcs 0 bien son tacil y rapidamente recuperables.28-1 CALlD. Los datos son tacilmente aplicables y manipulables en diferentes tareas.-\D DE SISTE\HS I. que consiste en generar un valor numerico como resultado de un juicio de un detenninado valor del dato con respecto a la dimension elegida: posteriormente los resultados se gum-dan en el mi5mo almacen de datos. Algunas dimensiones de CaUdad de Datos (Pipino et at. de sus filCl1teS 0 comenidos.ls ' adeeuado para la wrea que se esta desaITollanclo. 2002) Dentro de este proceso resulta fundamental disponer de medidas 0 metricas que pem1itan analizar y mejorar la calidad en funcion de las dimensiones de calidad de datos identificadas. trata de identificar las dimensiones de calidad que mejor describen esos requisitos_ para despues obtener metricas a partir de ese conjunto de dimensiones: despues se realiza el proceso de medicion propiamente dicho. Todos los datos se represcman en cl mismo tonmno. Basada en las ideas propuestas por Orman et Cll. Los datos estan 10 suficientementc actualizados para la (area que se esta desaITollando. Los datos son COITectos y liables. I Reputacicin Seguriclad \'alor aiiadido Tabla 10. l 1994). Los datos estan altamcnte rdacionados en tennino. Los datos son lltilcs y aplicables en la tarea ue sc esta desaITollando. ' I I Los datos son complctos y suficientes para la (area que se eStil desaITollando. 3. Los datos estan representados en el idioma apropiado. Los datos cstan representados de una fonna compacta.. . esta metodologia propone una serie de pasos bien estructurados y definidos que. sin prejuicios y sin connotaciones. partiendo de los requisitos de ca1iclad de datos de los usuarios. que proponen almacenar informacion referente a la cali dad de los datos en la misma base de datos.is es el m. EI acceso a los datos esui restringido apropiadameme para garantizar su seguridad. I El volumen de datos es adecuado para la tarea que se esui realizando. es ofrecer al usuario un marco de trabajo para detenninar la cali dad de los datos de una base de datos atendiendo a la calidad de los datos propiamente dicho. que adem.18. EI objetivo fundamental de ]a metodologia que a continuacion se resume. para despues analizar los resultados. Metodoiogia para ia medici6n de la caUdad de los datos En este apartado se muestra una metodologia para medir la calidad de los datos guardados en un almacen de datos. La forma de gum-dar los datos depende fuertemente del modelo de datos elegido para el almacen de datos. Los datos son bcndiciosos y otj'ecen wntajas alusarlos. Los datos son imparciales. con una simbologia COITecta y adecuada y con la definicion apropiada.

alor del dato original. 1. Elegir el momento en el que debe hacerse la \aloracion de los datos.3. Para comparar un valor almacenado con el \'alor real. Fase 2: Creaci6n de una estructura de calidad. 1.3. Localizar los datos a valorar. se pueden presentar alguna de estas tres situaciones: . donde el objetivo es dotar al almacen de datos de una estructura para guar'dar los val ores que mas tarde se recopilaran para las medidas de calidad. Esta actividad se di\'ide en las siguientes subactividades: 1. 1.FOR\lACIO?\ 285 Las fases de la que consta la metodologia son las siguientes: Fase 1: Identificaci6n de los objetivos y de las medidas.( RA-\lA CAPiTCLO DE L\ I:-. Detinicion de criterios de calidad. Detenl1inar la cantidad de datos que deben ser \alorados.2.1.4. se necesita conocer la fuente de informacion para preguntarle por el \. Detenl1inar el objetivo de la medicion.3. Identificar las fuentes de los datos.1. Se pretende indicar ellugar ex acto don de logica y.3.4. Se trata de establecer criterios de valoracion para juzgar la bondad de un dato y de definir criterios de evaluaci6n para detenl1inar la bondad del conjunto de los datos. Se trata de detel111inar las razones por las que se qui ere medir el nivel de calidad de datos. 1. Se trata de definir ese momento para que la medici on de la calidad sea la apropiada. Localizar los datos en la base de datos.2.3. donde a partir de los requisitos de calidad de los usuarios se obtendrian una serie de productos de trabajo tras completar cada una de las siguientes actividades: 1. Se trataria de decidir si para detenninar la calidad de los datos hay que tomarlos todos 0 bastaria con tomar una muestra de ellos y luego extrapolar los resultados. En funcion del nllll1ero de veces que se haya analizado la calidad de los datos guardados en el almacen de datos. Es la fase de disefio.3. Es una fase de amilisis. Detenninar los panimetros e indicadores de cali dad. Puede oCUlTir que el estado de la calidad de los datos que es verdaderamente significativo se de en un momento detenllinado. A partir de los requisitos de los usuarios se identifican las dimensiones y metricas de calidad de datos mas significativos para acotar el problema de calidad de datos. 1.o fisicamente estan los datos a valorar. 1.

2. Una vez que el almacen de datos disponga de una estmctura para guar'dar las medidas de las dimensiones de cali dad. En cualquier caso estas medici ones se guardaran en el almacen de datos. pOI' 10 que se recomienda tener en cuenta todos esos cambios. Frecuentemente se piensa que la calidad del software es el pilar basico para que .1. con 10 que sera necesario disei'iarlo afiadiendole directamente los aspectos de calidad que se consideren mas adecuados.286 CAUDAD DE SISTE1>L4. Com') ejemplo de metrica de calidad de datos podria darse la siguiente el Numero de valores incolTectos para un atributo (1\TVI (A)). una parte de esa totalidad. Fase 4: Amllisis y Evaluacion de los valores de los atributos de calidad. EVALUACION Y MEJORA DE LA CAUDAD DE LA INFORMACION A medida que la Infol111atica se ha ido conviltiendo en una de las helTamientas mas importantes para las organizaciones. procediendo posteri0l111ente como mejor convenga: cOlTecci6n de los datos existentes 0 captura de nuevos datos.. esta fase consiste en reunir valores para dichas medidas en las dimensiones especificadas. En este rango de val ores podria estar 0 no el valor nulo. Que no haya ni siquiera almacen de datos. y Segllll elnllmero de datos con calidad y los criterios de evaluaci6n establecidos se juzgaran si esos datos tienen 0 no el grado de calidad deseado. Fase 3: Medicion de los atributos de calidad. se celtifican los datos como validos para la aplicaci6n. Que el almacen de datos ya cuente con estmctura de calidad debido a analisis realizados anteliol111ente. 2. el valor empresarial del software ha ido creciendo hasta conveltirse en uno de los activos mas impOltantes a nivel estrategico (Bobrowski et al. 1999).2.S lNFORJv1A TICOS 2. se someteran los valores individuales medidos en la fase anterior a los critelios de valoraci6n para detel111inar el grado de bondad de un dato. En funci6n de la cantidad de datos y del nivel de calidad exigido puede ser necesario mediI' los valores de todos los datos 0 seleccionar pOl' muestreo s6le. Que haya almacen de datos pero que no de soporte para los aspectos 0 dimensiones de cali dad. Puede llegar a ser necesario que para algunas dimensiones de calidad se deba conocer el valor del dato real y compararlo con el del dato almacenado.3. Si es as!. 4. En cualquiera de las circunstancias en las que haya que modificar el modelo del almacen de datos hay que tener presente que se pueden ver afectados todos los procesos que manejaban esos datos. En esta fase. entendiendo que un atIibuto es incolTecto cuando su valor no esta dentro del rango de valores de dominio definido para ese atributo. En caso contrario se desechan como invalidos. Lo que habra que hacer sera modificar el modelo para dar el citado soporte.

. 2003). para poder atender a un mayor numero de potenciales c1ientes.. 1996: Wand y Wang. 2000). 1996) y pOI' tanto pueden general' ciertos enores que impactaran negativamente en la eficiencia global de la organizaci6n (Burgess et al. no es gratis y se requieren muchos reCllrsos (Xu.. 2004) ya que datos e infol111aci6n constituyen un activo fhndamental para las decisiones tacticas. estrategicas u operativas (Ballou y Iayi.. 2003. 2003. y de extender esta preocupaci6n al resto de los trabajadores de la organizaci6n a fin de introducir cambios y lograr compromisos que puedan servir de base para la mejora de la calidad de los datos (Motha y Viktor. 1999. Esto se traduce numerosas veces en una obsesi6n pOI' reunir y almacenar datos. la mayor parte de las empresas yen en la tenencia de datos un medio indispensable para hacer frente a un mercado cada dia mas competitivo (Huang et al.C\PiTULO 10: C\UDAD DE LA INFO~'vlACI6N 287 los Sistemas de Infol111aci6n que utilizan Iecnologias de Infol111aci6n (II) sean 10 suficientemente eficientes como para asegurar la supervivencia de una organizaci6n. 1996. Redman. en el que la diferencia entre costes y necesidades de calidad queda intimamente vinculado pOI' el contexto de aplicaci6n y pOI' los requisitos de la organizaci6n (Bringel et al. 2003). Este hecho obliga a las organizaciones a tener que enfrentarse pas ado un tiempo a un grave problema de poluci6n de los datos: se dispone de demasiados datos. investigadores y profesionales de empresa se han venido preocupando en esta ultima dec ada pOI' esta . 1997a). 2001a... porque. deberian ser las organizaciones quienes tienen que descubrir las causas de la pobre calidad de sus datos e institucionalizar programas de mejora para solventarlos (Jin y EmbUlY. generalmente el aseguramiento de la calidad es un proceso complejo. cientificos. 2002: Hinrichs. Kim y Choi. almacenar y procesar para la producci6n de la infol111aci6n son tambien un factor basico para el desanollo de sus operaciones comerciales (Eppler. 2003: Redman. Asi. la mayoria de ell os probablemente inlltiles e improductivos. 2004). Las organizaciones estan empezando a darse cuenta de que una situaci6n de datos con una calidad insuficiente es inaceptable (Piattini et aI. Geltz et al. No obstante. Se sabe que el tratamiento de los problemas de cali dad de datos y la infol111aci6n es un as unto tan importante como dificil (Ballou et al. Ieniendo en cuenta que un nllIllero importante de organizaciones no tienen todavia las herramientas adecuadas para mantener un alto nivel de calidad de datos (Kim y Choi. 2000a) ya que las decisiones que pueden llegar a tomarse no seran mejores que los datos sobre los que estan tomadas (Redman. Se hace pOI' tanto imprescindible para el buen rrmcionamiento de los Sistemas de Infol111aci6n de las organizaciones abordar el tema de la calidad de los datos y de la infol111aci6n desde la gesti6n. mayores seran las ventajas que supondra tenerlos. 2004). Bovee et al. Idealmente. 2001). sus directivos piensan que cuanto mayor sea la cantidad de datos.. los equip os de gesti6n de calidad de datos y de infol111aci6n deben ser los encargados de empezar a pres tar atenci6n a este aspecto tan importante de las organizaciones que viene siendo descuidado desde hace mucho tiempo (Helfert y von Maur. no es trivial. muchas veces sin una planificaci6n previa. 1996).. 1999). 2000). En la actualidad. Pero el dia a dia de las instituciones esta demostrando que los datos que se necesitan recopilar. Strong et al.

.. la satisfaccion del personal. son demasiado dependientes del contexto y.. por 1 tanto. 2002). pero rara vez abarcan los dos a la vez... En los siguientes subapartados se \'an a mostrar algunos de los proyectos. software. Estudiando a los autores clasicos de calidad como Deming. . 1998) se pueda alcanzar cielto grado de eficiencia en e1 tratamiento de sus datos. a traves de un camino. Es necesario. mejorar la calidad de los datos y de la infoI111aciolf para conseguir asi mejorar la satisfaccion de los clientes y. hardware. 2003: Huang et 01 . 1995). se llega a la conclusion de que 1a clave para 1a mejora de la cali dad de los datos y de 1a infol111acion en las organizaciones debe hacerse a traves de dicha gestion de ca1idad (Liu y Chi. Es posible afiI111ar que estos marcos de trabajos son fueiteS bien desde un punto de vista 0 desde el otro. 2000). control y aseguramiento de la calidad y mejora de 1a ca1idad (Helfelt y von Maur.-\-\l. (200 l) 0 Gen<. esta preocupacion ha motivado muchas nuevas lineas de investigacion tratando diferentes asuntos de la cali dad de datos y de la infom1acion des de distintos puntos de vista (Eppler y Wittig. Esta gestion de la calidad incluye conceptos y actividades como politic as de calidad. 2001). 2003). 1999: Lee et al .-\ creciente impoltancia de la cali dad de la infol111acion. al mismo tiempo. datos e infol111acion). demasiado centrados en aspectos concretos de dichos contextos. en la mayoria de los casos. Muchos de estos esfberzos comienzan con la evaluacion/va10racion del estado actual de 1a calidad de los datos y de 1a infol111acion y continLtan con la optimizacion de los procedimientos. 2001: Olson.?studio d~ la cali dad de los propios datos y de la inlormaci6n. R. en e1 que teniendo conocimiento sobre 1a organizacion y sobre los "procesos de/cilwicacion de informacion" (\Vang. A pesar de que algunas investigaciones proporcionan varias medidas para la valoracion de la calidad de 1a infol111acion y metodologias para la valoracion (English. 2000: Wang et 01. entomos o iniciati\'as mas imp01tantes en la gestion de 1a calidad de los datos y de la infol1113cion. c ExistCll otros estudios ~nfocados a mejorar la calidad d~ los modelos conccptuales de datos como Calero ct (il.'\ TICGS i. Estas acti\'idades necesitan encuadrarse en un marco de trabajo que pel111ita evaluar y mejorar la calidad de 1a infol111acion de una f01111a integradora a traves de una gestion proactiva: coordinando y organizando todos los recursos (incluyendo humanos. estrategia de calidad. ninguna de ell as trata como optimizar la calidad de la infom1acion coordinando grupos de esfuerzos 0 compromisos que alcancen a las organizaciones completamente tanto de manera pragmatica como analitica (Eppler y Wittig. 1996: \Vang et al .\ FG R:Vl. y como demuestra Kreut=berg (2000) esta gestion va a tener un efecto positivo sobre 1a calidad de los datos y de 1a inf01111acion. 2002). Esta tesis csta oricntada al <. aim no ha sido definido un manual de buenas practicas y procedimientos que pel111ita a las organizaciones valorar 0 mejorar un deteI111inado grado de la calidad de sus datos de un modo integrador (Geltz et 01. p1anificacion de la cali dad.?ro (2002).288 CAUDAD DE SISTDIAS 1. 1999: Eppler.. 2004) que vaya mas alla de la definicion de las dimensiones de h cali dad de los datos (Xu. 2003: Redman. :\0 obstante. Juran 0 Crosby. 10 que hara mejorar la organizacion en su conjul1to.

1997).1. Estas metricas pueden calcularse a . etc. Finalmente. al estilo de CMM1. En un nivel inferior. Tambien se incluyen otros marcos de especial importancia como AIMQ (Lee et al.4. analizar y mejorar continuamente la calidad de la infol1naci6n..ntua. Wang (1998) establece como principio te6rico basico el ciclo de Deming adaptado '-. y como contribuci6n del Grupo Alat·cos a este campo. Para esta mejora continua. 2000) desalTollados dentro del ent0l110 de TDQM. segll11 los cuales los usuarios deben enjuiciar la calidad de los citados productos de infol1naci6n. desalTollado en la Universidad de la Sapienza de Roma (Missier y Batini. exactitud.\: R. 1998) desatTollado en el MIT como uno de los marcos mas ampliamente aceptados por la comunidad investigadora y por las empresas. que se repiten en un bucle celTado siguiendo el ciclo de Deming (Deming. tales como precision. y que supone la base de otros proyectos como DaQuincis. desalTollado por English (1999).httl»!web. G Medicion del Producto de Informacion. La metodologia TDQM consta de cuatro pasos principales. 4.!w\\w.mit.-\-'. Se identifican los principales productos de inf0l111aci6n cuya calidad de informaci6n es basica para las necesidades de los usuarios: tambien se identifican aquellos requisitos de calidad de informaci6t:. 1986) PlclI1ifical'-Hacer- Colllprobal'-Actllal' (Plan-Do-Check-.gr·-d\yqf) desatTollado en la Uni6n Europea (Jarke y Vassiliou. se deberian identificar los elementos basicos del producto de informacion y sus componentes.lA Se comenzani por TDQM (Wang.edwtdqm) es considerar la infol1naci6n como resultado de un proceso de producci6n: para mantener una alta calidad de los productos de inf0I111aci6n es necesario definir. la producci6n de informaci6n. 2002) 0 TQdM. La clave para medir reside en el desaJTollo de las metric as de cali dad que se obtienen a pattir de las dimensiones de calidad de datos.ece. Es impOitante resaltar la inclusi6n del marco de Eppler (2003) por ser el de mas reciente publicaci6n.cf. 2002) o IP-MAP (Shankaranarayan et al . se incluira un marco de evaluaci6n y mejora basado en modelos de madurez. En esta fase el objetivo es identificar las metric as de calidad de infOimaci6n mas eficientes para medir dicha cali dad y proceder a su medici6n. sino s610 en la calidad de almacenes de datos es el proyecto ESPRIT 22469 DWQ (http:..dbnet. Metodoiogia TDQM < El fundamento de este proyecto norteamericano soportado por el Massaclzllssets Institllte of'Technology (MIT . el producto de infOI111aci6n es conceptualizado en tel111inos de sus funcionalidades para los consumidores de informaci6n. medir.: I!J Definicion del Producto de Informacion. Otro de los marcos a tener en cuenta pero que no va a ser incluido pOl'que no se centra en la calidad de los datos y de la infol1naci6n. Las caracteristicas del producto de informaci6n deben ser definidas en dos niveles: c: C) En un nivel superior.

JiflS) Y que con el crecimiento de los almacenes de datos y el acceso directo a la infol111aci6n desde varias y diversas fuentes por gestores y usuarios se ha incrementado la necesidad de tener cuidado de la calidad de la infol111aci6n en las orgal11ZaClones. s6lo han podido desauollarse tecnjcas propietarias para medir. Mejora del Producto de Informacion. entonces puede comenzar la fase de mejora. Justifican su propuesta basandose en que a pesar de una decada de investigaci6n y experiencias. El equipo del Producto de infonnaci6n necesita identificar las areas claves para las mejoras.A. seglll1 sus autores. Sin la capacidad de valorar la calidad de su infol111aci6n las organizaciones no pueden detelminar 0 estimar el estado de su organizaci6n con respecto a la calidad de la infonnaci6n para monitOlizar su mejora. el reto de la investigaci6n consiste en desauollar un modelo global con un instrumento de medici6n de la calidad de infonnaci6n. pero las organizaciones deberian tener un banco de pruebas (benchmark) que pennita comparar sus esfuerzos con los de otras organizaciones. Parten del hecho de que la calidad de la infonnaci6n se ha conveltido en un factor critico para las organizaciones y en una area activa de investigaci6n en el campo de Gesti6n de Sistemas de Infonnaci6n (Management b?formation Systems . se POrn"a investigar las causas potenciales de los problemas de calidad de datos.. $ 4. pueden definirse reglas de negocio que necesiten ser observadas. Para ellos. A partir de los resultados de las metricas. partir de los propios datos almacenados en la base 0 almacen de datos. Cuyo plincipal objetivo es disefiar e implementar estrategias para mejorar la calidad de infonnaci6n de los productos de infol111aci6n sobre las causas encontradas en el paso anterior. como el alineamiento del flujo de la infol111aci6n y del flujo de trabajo con la infi"aestructura de la organizaci6n y el realineamiento de las caracteristicas de la infonnaci6n con las necesidades del negocio.290 CAUDAD DE SISTEMAS INFORIvL4 TlCOS © !{. Consiste en el desan"ollo de un amilisis diIigido por datos y por procesos para descubrir las causas de la pobre calidad de los datos en los productos de infonnaci6n seleccionados. Metodologia de Evaluaci6n AIMQ Fue propuesta por Lee et al. aunque a un nivel mas complejo. que proporciona. Una vez que la fase de analisis esta completa.2. Los metodos y helTamientas para desarTOllar esta tarea pueden ser simples como una inspecci6n visual 0 complejos como el cOlmol estadistico de proceso. $ Amilisis del Producto de Informacion. una base rigurosa y pragmatica para la valoraci6n de la calidad de la infolmaci6n. El reto the matelializado en una metodologia llamada Assessment and Improvement Methodology for Quality (AIMQ).-MA. (2002). analizar y mejorar la calidad de los datos en las organizaciones. Consta de tres elementos: .

Los autores proponen un mapa para los productos de infonnacion (IP-MAP) como un metodo para representar sistematicamente la produccion de los productos de infol111acion. (2000) y vinculado con el proyecto TDQM. Tercero. Este modele tiene cuatro cuadrantes. Segundo. la representacion del IP-MAP debeIia no solo ayudar a identificar a los propietaI10S de los procesos en cada una de las fases. La segunda tecnica mide las distancias entre las valoraciones de los diferentes implicados en un sistema de produccion de infol111acion. La primera tecnica compara la calidad de la infol111acion con los resultados de un banco de pruebas de mejores practicas de una organizacion. usando esta representacion. Primero. la representacion conceptual debeIia pel111itir a los gestores de productos de infonnacion cenh'arse en los problemas ocasionados en los cuellos de botella de los sistemas de produccion de infonnacion y estimar el tiempo para desan'ollar cada uno de los productos. dependiendo de si la infonnacion es considerada como un producto 0 como un servicio. Este instrumento puede ser aplicado para valorar la cali dad de la infonnacion en las organizaciones.{. basandose en los principios de mejora continua para los procesos implicados. Los autores se basan en que aunque ha habido intentos de desaITollar modelos para la produccion de sistemas de infol111acion. y de si las mejoras pueden ser valoradas como especificacion fonnal 0 como expectativas del c1iente El segundo componente es un cuestionario para medir la calidad de la infonnacion a traves de las dimensiones de cali dad que son consideradas impOltantes tanto para los consumidores como para los gestores. Varias de estas dimensiones juntas miden la calidad de la infonnacion para cada cuadrante del modele anterior. cieltos aspectos cIiticos de las fases del desanollo de un producto de inf0l111acion dentro del sistema de infol111acion todavia no han sido atendidos. IP-MAP: Representacion del Producto de Informacion Este ent0l110. R/\. considera la creacion de la infonnacion como si fuera un producto de inf0l111acion. El tercer componente de AIMQ consiste en dos tecnicas de analisis para interpretar las valoraciones obtenidos por los cuestiOnaI10s. Esta representacion ofrece distintas ventajas.. propuesto por Shankaranarayanan et at. Estas dos tecnicas ayudan a las organizaciones a enfocar los esfuerzos para mejorar la calidad de los datos. sino adel11i:'ls ayudar a . e e 4. Casi todos son incapaces de representar sistematicamente el proceso de produccion y tienen deficiencias en constructores para representar explicitamente los detalles de produccion. el gestor del producto de infonnacion debe ser capaz de visualizar las fases mis impOltantes en el proceso de produccion e identificar las fases cIiticas que afectan a su calidad.-MA CAPITULO 10: CAUDAD DE LA INFO~y[ACI6N 291 e Un modele de las medidas que son lltiles a los consumidores y a los gestores de infonnacion.3. que :oerviIia como base sobre la cual se pueden elegir las dimensiones de calidad.

Los objetivos de esta representacion son los siguientes: <I> Ofrecer un conjunto de construcciones que faciliten la representacion de los pasos implicados en la produccion del IP.4. ofrece una representaci6n que puede ser us ada para \alorar la calidad de un producto de informacion basada en las dimensiones de calidad de in1'o1111aci6n seleccionadas. disei'iar procedimiento para rectificar estos problemas asegurando as! una alta calidad del producto de informaci6n. y los procedimientos para la eyaluaci6n del producto de infon11aci6n. la representaciol1 pe1111itiria a los gestores de los productos de i11f01111acion entender las unidades organizacionales de negocio como los limites del sistema de info1111acion traspasados por los distintos procesos usados en la produccion del IP. La representacion pennite al modelador ex. Ademas pem1ite al modelador implementar la calidad de info1111aci6n en la fuente. Aqui el modelador. Finalmente. pennite la medida de la calidad del IP en las distintas fases del proceso de produccion usando las dimensiones de calidad apropiadas. Estas construcciones ayudan a modelar los distintos pasos del proceso de produccion y ayudan al modelador en su visualizacion. 1999) A continuacion se presenta un resumen de la metodologia TQdM (Toto! QlIality data MOllagcmcnrj recogida por LallY English en su libro Improving Data \Yarehouse and Business Quality (English.a111inar criticamente los pasos en el proceso de produccion.292 CAUDAD DE SISTE:-'L-\S I?--:FORYL'\ TICOS implementar la calidad en las fuentes de los datos. CUaIto. conYers ion y 0 ensamblaje de estos 0 nuevos elementos de datos. tiene por tanto como objetivo la creacion de una representacion sistematica para la captura de detalles asociados a la produccion de un producto de inf01111acion. Estos pasos incluyen la llegada de elementos de datos (materias primas). La representacion sirve como modelo conceptual para la produccion del producto de infon11acion. <I> <I> <I> La principal critica que se Ie ha impuesto a IP-NIAP es que no prop one ninguna metodologia de eyaluacion y mejora. la localizaci6n para el almacenamiento de estos datos.usuario puede localizar las Fuentes potenciales de problemas de calidad de informacion y 10 mas importante. El marco propuesto por IP-MAP. Finalmente. Pem1ite asignar las responsabilidades de asegurar la calidad del producto de infom1acion. los procesos impJicados en la creaci6n. 1999). sino un modelo que permite representar adecuadamente la construcci6n de un producto de informacion 4. . Metodologia TQdM (English.

Ii) TQd?vI busca conseguir estos objetivos integrando los principios y IIl1itodos de calidad en Ia cllltlira de Ia empresa. Valorar Ia calidad tecnica de la definicion de los datos. hay que analizar primero la calidad de la definicion de los datos y de la arquitectura de Ia informac. c " Valorar Ia satisfacci6n de los c1ientes con Ia calidad de Ia definici6n de datos. Valorar Ia calidad del disei'io de Ia base de datos y de la arquitechlra de Ia informacion. distribuyen 0 repa11en infol111aci6n y recuperan 0 presentan infolmacion a los productores de infoll11acion 0 a los trabajadores del conocimiento. Hay modos de medir el grado de satisfacci6n de los clientes con . Identificar a los implicados en la informacion. Existen medidas tecnicas de confoll11idad con las especificaciones y de disminucion de variabilidad con respecto a los productos desalTo[[ados. EI proceso de medida de Ia definici6n de datos y de Ia arquitechlra de Ia informaci6n es el predecesor de Ia medida de Ia calidad de la infoll11aci6n. No se puede medir Ia calidad de un producto sin saber que las especificaciones de los productos son tan exactas como deberia ser. actualizan y bOll'an datos.-\PiTCLO 10: C. Identificar los grupos de infoll11acion a valorar.\!ACrO" 293 TQdM se traduce en la mejora continua de dos categorias de procesos: Ii) Procesos de desalTo[[o de sistemas de infolmaci6n para definir informaci6n. y arquitectura de infol111aci6n y bases de datos.-\UD. EI proceso de medir la cali dad de la informaci6n es ana logo al de Ia medici6n de Ia calidad de un producto manufachlrado.( R.-\D DE LA ['\FOR. La gestion de Ia calidad de la infolmacion consta de cinco procesos de medida y de mejora de la calidad de la informacion y un proceso que abarca a toda Ia organizaci6n para crear un ent0l110 de calidad de informaci6n. Los procesos de valoracion y mejora de los procesos de calidad que constituyen Ia metodologia TQdM son: " Proceso 1: Valoracion de ia CaUdad de Definicion de Datos y de [a Arquitectura de ia Informacion.-\-'\L-\ C.6n. Procesos de manufacturaci6n y negocios que crean. Los pasos de este proceso son los siguientes: Identificar las medidas de calidad de definicion de datos. sistema de infol111acion. Proceso 2: Valoraci6n de Ia Calidad de Ia Informacion. A fin de medir la cali dad de la infol1naci6n en una base de datos 0 en la salida de un proceso. desalTo[[ando e implementando procesos de negocio.

lisis del valor de la infonnacion y de la cadena de coste. Los datos limpios quedan cOlTegidos.-MA respecto a sus expectativas sobre el producto. Calcular el valor de la infonnacion. Sirve para tomar los datos elToneos y cOlTegir sus deficiencias para llevarlos a un nivel adecuado de calidad.\L~ TICOS @RA. Sin embargo estos costes S1 que pueden ser analizados y medidos en tenninos de beneficios reducidos 0 de no ingresos. Identificar segmentos de clientes. Infonnar e interpretar adecuadamente la cali dad de infonnaciOn. . Se establecen los casos de negocio para la gestion de la infolmacion y para la mejora de la Calidad de Infonnacion. Detenninar los ficheros 0 los procesos a valorar. Uno de los mitos de la calidad de la infonnacion es que los costes producidos por una pobre calidad de infonnacion 0 por la falta de ella no pueden ser medidos. Este proceso consta de nueve pasos que toman como entrada las salidas de los procesos anteriores y produce distintas salidas. EI proceso de reingenieria y limpieza de la info1TI1acion es aqueI en que se mejoran los productos de infonnacion. Calcular los costes de la falta de cali dad de infonnacion. Los ocho pasos de este proceso son los siguientes: o o o o o o o o e Identificar los grupos de Infonnacion que deb en ser valorados. Establecer las medidas y los objetivos de la calidad de informacion. Los pasos de este proceso son los siguientes: o o o o o o Identificar medidas de desalTollo de negocio. Identificar las fuentes de validacion de datos para valorar su exactitud. Los datos que no pueden limpiarse deben desecharse 0 identificarse como no cOlTegidos. Identificar el valor de la info1TI1acion y la cadena de costes. EI proceso desalTollado en esta etapa describe como medir y cuantificar los costes debidos a la falta de infonnacion. Calcular los costes de infonnacion.294 CAUDAD DE SISTEMAS INFOR. Extraer muestras aleatorias de datos. Este proceso consta de seis pasos que toman como entrada resultados de los dos pasos anteriores y que producen un an3. Calcular el valor del tiempo de vjda del cliente. e Proceso 4: Reingenieria y Limpieza de Datos. Medir la calidad de la infonnacion. Proceso 3: Medida de los costes de la No CaUdad. Los pasos de este proceso son los siguientes: o Identificar las fuentes de datos.

Estandarizar Datos. Analizar los tipos de defectos de datos. o o . COlTegir y completar los datos. Calcular las derivaciones y resumen de los datos. para. culturales.lo que se requiere: o Comprender la cadena de valor de la infonnaci6n y el hecho de que cada empleado es independiente de los productos de infonnaci6n de otros empleados para desalTollar con exito sus objetivos. Actuar para estandarizar la mejora de la calidad de la infon11aci6n. Comprobar el impacto de las mejoras de la calidad de la infol111aci6n. Comparar y consolidar los datos. Sin un entomo de estas caractensticas. Perfilar COlTectamente quienes son los clientes de la infon11aci6n y que esperan de los productos de infonnaci6n. Proceso 5: Mejora de la calidad de los Procesos de Informacion. Auditar y controlar la extracci6n. Lo que se busca es que cada individuo de la organizaci6n sea responsable de sus propios productos y procesos de infol111aci6n. Fon11ar a todos los empleados en el campo de la calidad mediante cursos y haciendo que dispongan de toda la documentaci6n necesaria para saber en to do momenta c6mo deben hacer 10 que tienen que hacer. las iniciativas para dicha calidad de infon11aci6n no pasanl. Los pasos del Proceso seran los siguientes: o o o o o Seleccionar los procesos para la mejora de la calidad de la infonnaci6n. transfonnaci6n y carga de datos.~ R. DesalTollar un plan para la mejora de calidad de infonnaci6n.n de ser esfuerzos puntuales que no prosperaran hacia una cultura de calidad en el entomo empresarial a largo plazo que busca todo proceso de calidad.\-MA CAPiTULO 10: CAUDAD DE lA INFOIUvV\CION 295 o o o o o o o o II Extraer y analizar datos de fuentes. Representa los requisitos sistematicos. II Proceso 6: Establecimiento del entorno de calidad de informacion. Este proceso analogo al anterior se centra en mejorar la calidad de los procesos que usan datos de la organizaci6n para producir datos nuevos 0 para presentarios a los trabajadores del conocimiento para su posterior amilisis. de gesti6n para la creaci6n de lm entOl11O de calidad de infonnaci6n. Implementar las mejoras de la calidad de infonnaci6n. Transfonnar y mejorar los datos en los objetivos.

Desanollar una \aloracion de la calidad de la int0l111acion. o Ofrecer una iC1l111aci6n tonnal en £:esti6n de calidad de iniol111aci6n para los directivos. Los pasos de este proceso son los siguientes: o o c.:) Establecer mecanismos regulares de comunicacion. Es un proceso transversal que tiene raices en los cinco procesos anteriores. Diligir una valoraci6n del grado de satisfaccion de los clientes. s .296 CAUDAD DE SISTE\ !'-\S IMOR\ \. Deilnir los roles y la plantilla de calidad. Seleccionar un proyecto piloto. Calcular el \'alor del tiempo de vida del cliente. procesos y objetivos de calidad de datos. Dirigir un proyecto de mejora de iniol111aci6n. pequei'io y manejable. :Vlantener los procesos de mejora continua para la calidad de los datos. o o o o o Definir los problemas de negocio y medidas necesarias para resolverlos. como de los trab~adores de la empresa. o Deilnir principios. o o Cuantificar los costes de la no calidad en la info1111aci6n.\TICOS ~ RA-\lA o Ai'iadir a los objetivos de la empresa la satisfaccion tanto de los clientes. mision y objetivos. y entre ellos los que son mas importantes desde el punto de vista de la calidad de la infonnaci6n: los trabajadores del conocimiento. Dirigir una valoraci6n del grado de madurez de la gestion de la calidad de la infonnacion.. Analizar las batTeras sistemitticas. Detlnir una cadena de valor y desanollar un imentario de datos.. Identificar y enfatizar el rol de lider de calidad de infonnacion. Identificar otras transrormaciones de negocio. educaci6n e implicacion de los directivos . . iniciativas de mejora 0 recursos extel110s. Desanollar lazos de contlanza con los patrocinadores. Crear una vision.

Identificar los productos de infom1acion criticos. a las OIgani:::aciones a fI'Gves de COllllillicacionesfiables ". Realizar un anaIisis dirigido por procesos tie los productos de infonllacion.CAPiTULO 10: CAUDAD DE LA INFO~\LA. Analisis: Detem1inar como someter a los productos de infol111acion seleccionados al control de calidad. . denominados senoicios de iJ?fraestructllra. AnaIisis de los Requisitos de Calidad de Infom1acion.html) Parten de la base de que las teorias tradicionales de gestion de calidad de datos no dan soporte suficiente para la gestion de la infom1acion en estos tipos de sistemas. 1. qlle pllede ofj'ecer servicios sofhmre. Determinar el alcance del Proyecto.it/~dgI) es un desalTollo conjunto del Departamento de Infonmitica y Sistemas de la Universidad de "La Sapienza" de Roma.CI6N 297 4. Realizar un anaIisis dirigido por datos de los productos de Infolmacion. Missier y Batini (2002) muestran a traves de la coleccion de documentos del proyecto DaQuincis la justificacion de su trabajo.1.uniroma1.1. 2002) El proyecto DaQuincis (http://w\vw. 2. 1998) que esta fom1ado por los siguientes pasos: 1. en los cuales la infonnacion se produce y se consume de manera compleja por cada una de las organizaciones.5. Para ellos. Los entomos operacionales ofrecen diferentes oportunidades para la gestion de calidad. 1.2.dis. el objetivo es detenllinar una eSh"ategia y h"azar un plan para la gestion de calidad de infol1nacion. 1998) desatTOllan un marco homogeneo para la gestion de proyectos de calidad de infom1acion en entomos cooperativos. para cada uno de los elementos de datos recopilados en el a1cance..it/~dq/docs. Proyecto DaQuincis (Misier y Batini. los sistemas de infonllacion que son gestionados de fonna autonoma por diferentes organizaciones pueden cooperar en procesos de negocio distribuidos y que se ejecutan entre distintas organizaciones.uniromal. Este paso tiene como objetivo detenninar que Productos de Infonnacion estan dentro del a1cance del proyecto y por que. Las actividades de este paso son los siguientes: 2. Define el concepto de "adecllado para Sll IIS0 . 2. (http://w\v\v. Los autores proponen un marco basado en TDQM (Wang.3. Las actividades que hay que realizar son las siguientes: 1. Dados un entomo especifico y un conjunto de requisitos de calidad de datos. del Departamento de Electronica e Infonnacion del Politecnico de Milan y del Depattamento de Sistemas de Infomlacion y Comunicaciones de la Universidad de Milan Bicoca.2.dis. Para ella introducen el concepto de sistema de info1Tl1acion cooperativo (CIS) como "aquel sistemaformado por WI conjzmto de organizaciones que cooperan a trm'es de IIna infi"aestructllra softH'Gre de C0ll11lllicacion. Analisis de las oportunidades y planificacion eSh'ategica. por 10 que a pattir de la metodologia TDQM (Wang.

Planificacion del Proyecto tecnico. Monitorizaci6n de los niveles de calidad. 4. Un proceso intensivo en conocimiento podria definirse como "ulla sel'ie productim de actividades que implicCin tl'Clns/ol'llIacion de ia in/o/'lllClcion y l'eqlliel'en WI conocimiento projes iOllai especiaii::ado ". 5. El plan del proyecto detenninada el modo y frecuencia en el que deben monitOlizarse los niveles de calidad. Comprende las siguientes actividades: 4. Deberia habilitar un modo de analizar esos problemas con mas detalle y rigor y detem1inar sus CclUsas potenciales.6. Un sistema en operaci6n debe satisfacer este plan usando los procedimientos implementados. Los niveles de calidad exigidos por los requisitos de calidad de infOlmaci6n garantizan una serie de beneficios organizacionales. 4. 0 o o monitorizar las soluciones a los problemas de . Un analisis posterior basado en datos de monitorizacion analiticos. Valoracion de los niveles de Calidad de Informacion y seguimiento del proyecto. Ofrece un enlace desde el desanollo de esh'ategias de infom1aci6n regresando a las fases previas que han sido discutidas. 3. Para desanollar este marco se impuso una serie de condiciones que deberia satisfacer: o Deberfa ayudar a identificar los problemas de calidad de datos y de infonnaci6n de una fom1a mas sistematica y mas comprensiva.2. Eppler (2003) propone un marco que deberia ayudar a pensar mejor sobre los problemas y seleccionar la mejor soluci6n entre las distintas altemativas eSh'ategicas. Algunos de los elementos mas relevantes del entomo son los siguientes: requisitos tecnicos detenninados por el analisis de la estrategia y por los patrones de mejora de calidad. 4. Marco de Trabajo de Eppler (2003) EI marco propuesto pOI' Eppler (2003) se centra en los procesos intensivos en conocimiento (h'aducido de KnoH'iedge-intensil'e process). EI objetivo de esta actividad es encontrar un equilibrio entre costes y beneficios. Deberia ser lltil para evaluar calidad de infonnaci6n. Gesti6n de las operaciones del sistema.1. Debe tener en cuenta todos los requisitos tecnicos derivados de la planificacion estrategica. Implementacion del Plan y ejecucion. Define un plan para el proyecto tecnico que pennite implementar las estrategias propuestas. Gesti6n ordinaria a nivel de sistema.298 CAUDAD DE SISTDIAS INFO~'vL'\TICOS Analisis de costelbeneficio.

~ R. los que tienen el fondo gris oscuro son dimensiones relacionadas con el fon11ato de la infon11aci6n. I hFOlnIACIO:-. ~ I I CO'iv['ilE'iTE I OPORrr'iO f~ ~IL SEGll'll['iTO ACCESIBLE SEGrRA I 'IA'iT['ilBLE I I !'iTER ICHI I R \PlD \ :} " ~ [ '" -'.- '.\CIO:<o II I I CO:<OTEXTO II I I ACTIYACIO:-.' . Deberia servir tambien como un instrumento de fonnaci6n en el aprendizaje y aplicaci6n pnictica de los conceptos de calidad de infonnaci6n. ELEMENTOS DEL MARCO Y CRITERIOS DE CALIDAD Los elementos que Eppler propone para este marco son los siguientes (vease figura 10.. PRI:<OCIPI .TE I I CO'IPRE:-. sus respectivos autores proponen las dimensiones de calidad agrupadas en . LOCALlZACIO:"\ ApUCACIO:-. I II y YALID. 2003) Los recuadros con el fondo en gris claro son dimensiones de calidad relativas al contexto.10. e A continuaci6n se exponen los elementos que el citado marco debe poseer.A PROCESO Onnlll. Las flechas representan conflictos potenciales entre las dimensiones. RELEVA:-. los que tienen el fondo blanco son dimensiones relacionadas con el tiempo. 4. el producto de infonnaci6n..'\-yl. Marco de Referencia de Calidad de Informacion (Eppler.1.IPLICABLE hFOR'LICIO'i BLT'.·IDO I'iFRAESTRLCTL'RA FLIBLE CO:"\ClSA / "" I ~TE I/CORRECTO ACTCIL I} I '" ":0:~ -: "C. En la maYOlia de los marcos de cali dad de datos y de infon11aci6n propuestos en la literarura. .T1FICICle):"\ EUU:.-'.. IDE:-. e I.10): e Una estructura vertical con cuatro vistas 0 niveles de calidad de infonnaci6n que categOlizan los criterios cruciales de calidad de infonnaci6n para la comunidad destino del marco.6.. I hTEGILICIO:-.ICIO:-. Una estruchlra horizontal dividida en cuatro fases que representan el ciclo de vida de infol111aci6n desde el punto de vista de un usuario.SIVO EXACTO CLARO . el proceso de infol111aci6n y la infraestnlchlra. CAPiTULO 10: CAUDAD DE LA INFO~\HCI6l\' 299 e Deberia ofi-ecer medidas para disei'iar y gestionar soluciones sostenibles basadas en las conclusiones obtenidas a partir de un amllisis de las medidas tomadas en las dimensiones de calidad. ~ ~ ~ Figura 10.

rt:ft!l'. EVALL\CIO'i LOC\UZACIO'i '-\PLlCACIO'i o o o [DE'iTIFICACIO'i EJ~jl{iciall1it.1' R..'! a/cane.n con /0 Ohl.'ruccit..'l1riLjuecimi:.. es necesario que la infollnaci6n tenga las caracteristicas de comprensibilidad.. /. Estas pueden agmparse en dos bloques: calidad del contenido (que agmparia infol111aci6n relevante). directamente o tras un periodo de fonnaci6n adecuado..' fa jilt/nIt! ReCOf?tigurochJn dt! /a b~f. CicIo de utilizacion de la informacion (Eppler. La fase de 10calizaci6n contiene un conjunto de actividades que ayudan a adaptar la infol111aci6n al nuevo contexto de aplicaci6n.. reduciendola. mas que categOlias..2. . infonnaci6n buena (en el sentido de estar libre de fallos). En su marco..1 ilUcJ}"macicin L"rili:acit!n cOlic/ialla cit! fa h!/iJrnlachjn les Figura 10.lcic)!1 clL' conell/siones d il~t()f"mach)n. las caracteristicas.' la ! E.' hIJilt!n!r.11): o Para la fase de identificaci6n.: fa CO!1h!rsilm Lk{formalO de /11lt.!Uf. criterios 0 dimensiones de calidad que el autor ha identificado.. dr. Comparacicjn cull olras. y calidad de los medios (que agruparia proceso optimizado e infraestmctura fiable)...:'/1l'dt! Etrt!. 4. La fase de evaluaci6n consiste en un conjunto de actividades que ayudan juzgar mejor la bondad y la relevancia de la infonnaci6n identificada y de la fuente de la que proviene. que tiene los cuatro siguientes pasos (figura 10.300 CAUDAD DE SISTEMAS INFORMATICOS categorias./w. as! como los recursos cOlTespondientes.'ifJn la dc{/{alidad de L ". y fiabilidad de la infraestructura.'. son importante los siguientes criterios (vease figura 10. proceso optimizado. 0 cambiando su f0l111at.maci61I para id rt.:ducci6n dt.o original...>l1fo £I.. Estas cuatTo perspectivas son las que cOlTesponden a los Plincipios de gesti6n: inf0l111aci6n relevante. Eppler.'f1!O proh/ellIus. ampliill1dola.11): o La fase de identificaci6n consiste en localizar la fase donde la infol111aci6n y el dominio en el que se encuadra. P ASOS EN EL MARCO DE EPPLER El marco en sf consta de cuatro pasos.: d."i!JI1 y t.·ofllchJn cit} I la COl1sislt!!1cia.' . 10 que prop one son vistas 0 perspectivas de la calidad de la infonnaci6n.}nJlt. La estruchlra vertical del marco refleja una secuencia crono16gica 0 fases desde el punto de vista del usuatio. sea concisa.mcia dt! fa h?/hrmacic)n.ili::acj(jn de fa iJ~t(). 2003) En cada una de las fases.-.1L.:m:i()n crcdihilidad elt. 10 que Ie resta aplicabilidad. conveniente y accesible.11. La fase de aplicaci6n es en la que la infonnaci6n es puesta en usc...: El~jl/iciafJ1i'-'nl() dt! fa honda" .' portir dt.6.

<i> <i> <i> Como se sabe. como 10 define Wang (1998).7. Wang. consistente. un sistema de Informacion puede verse como un conjunto de procesos de Produccion Chorizontales") que son conh'olados por distintos procesos de gestion de calidad ("verticales"). 1993) y de infor111acion des de un punto de vista ingenieril. Para que pueda decirse que un producto de datos tiene cali dad. susceptible de hacer un seguimiento y mantenible. Debe proporcionar un esquema para analizar y resolver problemas de calidad de datos y de inf01111acion. con'ecta. ya que la cali dad de un proceso depende de su disefio y de su operacion (Dedeke. es importante que la infor111acion sea clara.". <i> 4. Un producto de datos. 1998). Debe proporcionar a la comunidad investigadora un mapa conceptual que pueda usarse para eshucturar varias teorias y fenomenos relacionados con la calidad de datos. 2001 b). El asunto fundamental de la cuestion pasa por modelar 0 definir ese proceso de produccion de infonnacion y como gestionar la calidad de los productos que genera. 1998). Huang et al. Finalmente. y de datos con materias primas. . es el resultado de un proceso de h'ansf01111acion (produtcion) de datos. cumpliera las condiciones que Eppler y Wittig (2000) imponen para un buen marco de h'abajo de calidad de datos y de la inf01111acion: <i> Debe proporcionar un conjunto sistematico y conciso de criter10s con los que se pueda evaluar los datos y la inf01111acion. actual. 1999. se exige que la infonnacion sea precisa.G R. aunque los datos tengan caracteristicas diferentes de las mater1as primas tradicionales (Ballou y Tayi. Una de las ideas basicas de esta propuesta es considerar la infor111acion como el valor afiadido a los datos que alguien obtiene cuando usa un producto de datos (Eppler. en el que los datos son considerados como la materia prima en el proceso de produccion (Ballou y Tayi. como han suger1do algunos autores de fonna implicita 0 explicita (como Bobrowski et al. 1999). 2003). Debe proporcionar las bases para la gestion de calidad de los datos y de la infonnacion y para una gestion proactiva.-MA CAPiTlJLO 10: CAUDAD DE LA E~FORIvlACI6?\ 301 • • Para la fase de evaluacion.. pennite aplicar los principios clasicos de gestion de calidad de productos ala gestion de calidad de los datos (Firth y Wang. oportuna y segura. CALDEA Y EVAMECAL Nos propusimos desaITOllar un marco de h'abajo para la evaluacion y mejora de la calidad de los datos y de la infonnacion que supliera las deficiencias de los presentados anteri01111ente y que ademas. Para la fase de localizacion. interactiva y nipida. debe satisfacer todos los requisitos del cliente (Crosby.. para la fase de aplicacion. 1996. Esta analogia de infol111acion con productos. se exige que la inf01111acion sea aplicable.

se han definido en el marco dos componentes principales: Ln Modelo de calidad basado en Gesti6n de Calidad de los datos y de la Informaci6n estructurado en 1\iveles de Yladurez. Aunque existen \arios marcos de trabajo para la e\aluaci6n y 1£1 mejora de los procesos so1"\\\are. Esta bip6tesis esta respa1dada por McLeod (1990) que explica que todo proceso software esta formado por dos subprocesos: uno de producci6n propiamente dicho y otro de gesti6n que incide en el de producci6n para controlarlo y que la ejecuci6n 0 no de alguna de las acti\idades del subproceso de gesti6n incide directamente en la calidad del producto de datos que se desarrolla. se podria !legar a pensar que una buena aproximaci6n a la gesti6n de la calidad de los datos y de la infol111aci6n en las organizaciones podria ser definir un Proceso Software de Gestion de Informacion (PGI). estandares.1' urlejilcl()S 'jue SOil necesarios para concebi/'. procedimielllos . desarrollul'. y teniendo en cuenta que la calidad de cualquier producto no puede ser asegurada simplemente inspeccionando el producto 0 realizando meros controles estadisticos. que recursos se usan y c6mo se gestiona 1a calidad tanto de los productos que se generan como de los recursos que se usan. Si se busca una analogia con la definici6n de Proceso Software dada par Fuggetta (2000)5. Para caela ACP. Para conseguir evaluar y mejorar la calidad de datos \' de infol111aci6n en una organizaci6n y teniendo el concepto de PGI como concepto mticulador de esta propuesta. Esto justifica la existencia de los procesos "velticales" de gesti6n de calidad que puede afectar a varios procesos "horizontales" de producci6n. en e1 que se detlniera quien esta haciendo que.3 .-\-?vlA 1979) 0 ser adecuado para su uso (Juran. llamado C-\LDEA. tareas v 'Proccso So/ilmre eS lIil COlljUll1O cohereille de po/ilicas.302 C. cuando. como Cv['vlI 0 ISOIEC 1:5:504. ills/a/ar .-\UDAD DE SISTEylAS I~FOR:VL'\TICOS :f. se proponen algunas hel1'amientas. donde se establecen distintas Areas Clave de Proeesos (ACP) con actividades de . Al estilo de las pnicticas de C\[M y Ci\[ivU pero utilizando la tenl1inologia de Metrica \'.caracter tanto tecnico como de gesti6n. 211 estilo de Cv1YII y ISOIEC 1:5504. 1988). y en aras de conseguir un marco de trabajo 10 mas universal 6 posible.. Es necesario articular alglll1 razonamiento para englobar y enlazar todas estas ideas y conceptos. eSll"/iCll!raS orgulli::aciolla/es. Esto habilita la evaluaci6n y mejora de la calidad de 121 informaci6n a tra\es de 1£1 e\'aluaci6n y la mejora de un proceso software encargado de la gesti6n de 1£1 informaci6n. teenicas.1' liIWilcner 1111 procillc/o sofhm/'e " . leci/%gias. ninguno de ellos se centra en 1£1 calidad de los datos y de 1£1 informaci6n. R.

1999): definir. 2004). Un nivel de madurez indica la capacidad de un proceso (Cue\as et al. conocida como EVAMECAL.1. 2004a-d.4>. La evaluQcion y mejora necesita un modelo de proceso (Humphrey.. Los siguientes subapartados describen los componentes del modelo propuesto. Para poder lle\ar a cabo de fOl11m efectiva la gestion de los procesos sofnvare de gestion de informacion es necesario asumir cuatro resjJonsabilidades claws (Florac y Carlenton. 1989) que encuentra en CALDEA. Integracion. 1996). aplicar EVAMECAL para evaluarlo segLll1 el modelo de referencia indicado por CALDEA y mejorarlo planificando la realizacion de acciones COlTectoras para satisfacer los objetivos de calidad de datos y de infol1nacion establecidos en CALDEA. medir. ·L11L. SCAMPI (SE1. la idea del marco puede resumirse como sigue: elegir un PGI de la organizQcion cuya cali dad de los datos y de la infol1mcion sea suceptible de mejora.CPL Cada una de las ACP debe contemplar las acti\'idades necesQrias para implementar los procesos de produccion de productos de informacion y las acti\'idades encaminadas a lograr 0 alcanzar un detenninado objetivo de calidad de datos y de informacion. Gestion Cuantitativa y . Se han definido los siguientes niveles de madurez para la gestion de la cali dad de los datos y de la info1111acion: Inicial. 2001) 0 la cuarta parte de ISO/IEC 15504 (ISO. porque parecia mas facil trabajar con secuencias de mejoras bien definidas (que abarcan desde los fundamentos basicos de la gestion de proyectos hasta los asuntos de gestion de la calidad de los datos) y ademas esto pe1111itia asegurar la primera condicion impuesta por Eppler y Wittig (2001) de ofrecer un conjunto conci50 de cliterios sistematicos para evaluar y meJorar la calidad de la infon11acion. del estilo de CBA-IPI (Dunaway. 4. el modelo de referencia que debe seguir un PGI para la mejora continua. CM\/ll reLIne estas actividades en grupos de actividades.dU CALDEA representa en el marco propuesto. 2002). Definicion. De esta manera cada organizacion puede usar 10 que sea mas apropiado para sus necesidades. controlar y mejorar el proceso. Se han asimilando estas responsabilidades clmes como referencias en la definicion del modelo de proceso de gestion de infol111acion pueden establecerse cinco niveles de madurez en la gestion de calid2d de datos y de infol1nacion. al estilo de los propuestos por CvlMI. En cada niwl es necesario obsenar una serie de acti\'idades fundamentales para el cumplimiento de los objeti\os de gestion.AD DE LA INFORt'vIACIOl\ 303 metIicas requelidas. que consiste en un conjunto de pasos que proporciona una base para la evaluacion y ejecucion de la mejora de la calidad de datos y de la infor111acion a traves de una gestion proactiva. III Una Metodologia de Evaluacion y Mejora de la Cali dad de infol111acion. Con estos dos componentes. Es interesante reseilar que se ha optado poria representacion en etapas de CMMI.~ RA-MA CWiTULO 10: CALID. Redondo.7. llamados Areas Claw de Proceso (.

Definido (2).. para que puedan recopilar todos los requisitos de calidad de datos y de la infonnacion. GEGCDI z. Las ACP de este nivel son las siguientes: e (GEGCDl) Gestion del Equipo de Aseguramiento de Calidad de la Informacion. Los cinco niveles de madurez en la gestion de calidad de datos y de la infonnacion de los que consta CALDEA son los siguientes (en la tabla 10. estandares y heITamientas que penIDtan convertir los productos de entrada en productos de salida. Inicial (1).. cada uno con sus ACP. no por imponer una serie de tecnicas y heITamientas que dilijan hacia el objetivo de la ACP. Estas ACP estan a su vez compuestas por actividades. Por tanto un PGI se dice que esta definido cuando se ha gestionado un proyecto para su definicion. 1a relacion entre ellos y el modo en que se han ido desan"ollando de acuerdo al plan previsto.19. Un PGI se dice que esta Definido 0 en e1 Nivel de Definicion cuando se ha planificado e1 proceso de gestion de infol111aci6n. Tambien es importante senalar que en cada nivel de madurez se puede ir modificando tanto elmodelo de procesos del PGI como elmodelo de datos. Areas claves de proceso de CALDEA 1.30-1 CAUDAD DE SISTEMAS INFORMA. 2. Para la realizacion de cada actividad. A fin de hacer el modelo 10 mas universal posible se ha optado por proponer.19 se muestran las ACP de cada uno de ellos): .. ~9 vv f-- \. identificando y defmiendo todos los elementos y componentes (tantos pasivos como activos). es decir puede estar en un estado ca6tico. es necesmio la eleccion de una serie de tecnicas. ~ ~ ~ g Q GIR GCI FS GE Tabla 10. Las iniciativas de gesti6n de calidad de datos y de infonnacion . Un PGI se dice que esta en elpivel inicial cuando no se ha gestionado ni coordinado ninglin esfuerzo con el fin de asegurar la calidad de los datos y de 1a informacion.TICOS Optimizante.

1997). ERU-CI y ERU-PGI.Q RA-MA CAPiTULO 10: CAUDAD DE lA INl'ORMACION 305 necesitan personas que puedan dar soporte a las actividades que se deben realizar. e e (FS) Gestion de Fuentes de Datos y Destinos de Producto de Informacion. Los requisitos de usuarios deben ser recopilados y documentados convenientemente. es necesario identificar y documentar las fuentes de datos y los objetivos de los datos de ERU-PGI para evitar problemas de redundancia y de fonnato de intercambio de los datos (Loshin. Estas personas deb en trabajar en concordancia con las ideas y las tendencias de la organizaci6n y deben estimular a la plantilla mostrando un compromiso con las politicas de calidad de infonnaci6n (Ballou y Tayi. 1993): los relacionados con el producto final de infoffilaci6n (ERU-PI). (GR) Gestion de Requisitos de Usuarios. Los datos us ados como matenas primas deben ser recopilados y almacenados en BD apropiadas 0 en almacenes de datos. Por las caractensticas de los datos. debiendo sopOliar los requisitos establecidos en ERU-PI. es mejor elaborar lill proyecto para la gesti6n de la adquisici6n. 2001). los relacionados con el PGI (ERU-PGI) y los relacionados con la Calidad de la Infonnaci6n (ERU-CI). Existen tecnicas y helTamientas que pueden ayudar a desalTollar cada documento (IEEE. En almacenes de datos se deben usaI' helTamientas como ETLs para unificar la selmintica y los fonnatos de datos (English. Y alguna mis especifica para aspectos concretos como. Esta ACP pennite incluir otras actividades como Aseguramiento de la Calidad de los Datos (Jar'ke y Vassiliou. En Ballou et al. Redman (2001) sefiala la necesidad de que los altos directivos se impliquen en las iniciativas de calidad de datos y de infoffilaci6n. 1999). Desarrollo 0 Adquisicion de Bases de Datos 0 Almacenes de Datos. Se deb en identificar tres clases de requisitos (Wang y Madnick. haciendo esfuerzos para satisfacer las ACPs del modelo de madurez. 1998). 1999). (1998) Y en Bouzeghoub y Kedad (2000) se discuten estos temas y sugiere fOffilas para tratar la infonnaci6n de multiples fuentes.. EI objetivo de esta ACP es crear un plan para coordinar y organizar los esfuerzos y redactar un documento. Este documento se puede realizar de acuerdo a IEEE ( 1987). IP-MAP (Shankaranarayanan et ai. Es necesano identificar a partir de las ERU-CI tanto las dimensiones de calidad de . Estos tres grupos de requisitos son el punto de partida para modelar el PGI. e e (GCl) Gestion de la Calidad de la Informacion en Componentes PGI. El uso de mehicas para medir la eficiencia del PGI pennite ayudar a mejorarlo. que bien podna ser utilizado para modelar el PGI. 2000). desalTollo 0 mantenimiento de un SGBD 0 un almacen de datos. que describa claramente una agenda de actividades y un presupuesto en recursos para optimizar el PGI. (ADN1) Gestion de Proyecto de Mantenimiento. Para asegurar mejor la calidad de la infoffi1aci6n. e (GP) Gestion de Proyecto para PGI.

TICOS &~-'\.. (GIR) Gestion del Impacto de la CaUdad de Informacion y de los Riesgos. 1976: Gilb y Graham .. no se prop one ninguna dimension como obligatoria. Para conseguir que nuestro marco sea 10 mas geneIico posible. clocumentar y transmitir a la base cle conocimientos de la organizacion. Una metodologia mas especifica que se puecle usar es. Se podria cliseii. Para obtener medidas mas fiables es interesante automatizar el proceso de medicion como sugiere Hinrinchs (2000). (1997b). 2002). 1993). T oclas las lecciones aprencliclas a traves cle la experiencia se cleben reunir. Se poclria usar las inspecciones de software (Fagan. 1999). Como guia. 2002). a fin de que pueda ser controlado bajo los panimetros propios del conte:\to (Florac y Carlenton. Es necesario cletenninar el impacto sobre la organizacion cle una pobre caliclacl cle la informacion en el PGI y acotar que riesgos se procluciran si se asume (English. 2001). Como ayuda en esta labor. ya que esto no es posible salvo para contextos concretos (Pipino et al. aclaptaclas a los aspectos cle caliclacl. 2002: Pipino et al.306 CAUDAD DE SISTEvlAS INFO~vLi. Un PGI se dice en e! ni\el de Integracion 0 que esta integra do. Un " '" . 1999). ! 999: Loshin. Getto (2002) propone una metoclologia que se puecle aclaptar a aspectos cle calidad de la inf0I11lacion para reunir y clocumentar toclos los nesgos. se puede utilizar una metodologia generic a como IEEE (1992) 0 GQM descrita en (yan Soligen y Berghout. e:\tenclicla al PGI. 3. Bouzeoghoub y Kedad (2000) 0 Calero y Piattini (2002) han propuesto metricas para la mejora de componentes especificos de un PGI..'os a !a \aliclacion \' a la Yerificacion 1986). 1999)..-r. Huang et al. Integrado (3). se hacen esfuerzos por ejecutar el proyecto seglll1 las politicas de calidad de datos de la organizacion.ar y reclactar un plan cle pruebas para coorclinar los esfuerzos relati. (GE) Gestion de la Estandarizacion de la CaUdad £Ie la Informacion.lA la infonllacion (como se prop one en ISO/IEC 9126 para el software) para cada uno de los componentes que se debe controlar (Hoxmaier.. (2001 ). respondiendo a1 111is1110 enfoque de bllsqueda de caliclad de datos y de la informacion que el resto de los recursos (English. 1999). cuando habiendose alcanzado el niYeI 2. clata testing propuesta pOl' Kiszkumo et uf. La idea de estar integrado responde a la necesidad de estar dentro de en un entomo determinado. suele utilizarse como estandar el cO!~unto de dimensiones de calidad de datos propuesto pOI' Strong et al. 2001.. Autores como Ballou y Tayi (1999). 2003: Kahn et al. como las metIicas que mejor se adapten a cada una de estas dimensiones (Eppler. la organizacion. Las ACP de este niYeI son las siguientes: ® 'alidacion y Yerii1cacion de del PGI y Productos de Tanto los productos de informacion como los componentes del PG! tienen que ser \erificados y validaclos para corregir clefectos y cliferencias con las ERUs.

que afectan a la organizacion. El Control Estadistico del Proceso (CEP) pueden aplicarse para detectar defectos de calidad de infol111acion e identificar sus causas.<. Como afi11na Ivleredith (2002). (5). Por tanto. . (GP. Un PGI se dice que esta en el nivel de gestion cuantitativo 0 que esta gestionado cuantitativamente cuando estando integrado en una cultura organizacional de cali dad de datos.2000). EI objetivo de esta ACP es conseguir metric as que se pueden usar para comprobar la conformidad de la especificaciones (Grimmer y Hinrinchs. Un PGI se dice que esta en el ni\el cuando.\I) Gestion de Planes de Medicion del PGI. Autores como English ( 1999) 0 Loshin (200!) prop on en el uso de diagramas de control como forma de representar los datos referentes al PGI.2002). Otra fOl1na de mostrar los resultados es el uso de diagramas de Ki\iat como propone Humphrey (2002). el objetivo principal de este niwl es obtener una confo11nidad cuantitatiya del rendimiento del PGI en un periodo de tiempo razonable que sea consistente con 10 reguerido en te11ninos de variac ion y estabilidad (Florae y Carleton.' RA-:'vlA CAPITULO 10: CAUDAD DE LA INFORMACION 307 ejemplo de proceso de estandarizacion podria ser el sexto proceso de TDQM (English.. 2001). Smith y Heights (2002) ofrecen un marco de trabajo para prevenir los defectos. Para este niwl se han definido las siguientes ACP: 4. Gestion Cuantitativa (4). Para este tiitimo nivel las ACP que se definen son las siguientes: c. Para conse-guir un aumento de fiabilidad y repetibilidad de las medidas. un plan para la medicion de la calidad del sofmare comienza con la decision de tomar medidas e implica elegir "que". cumpliendo as! con la tlltima de las actividades de gestion propuestas por Florac y Carienton (1999).ensiones de calidad de datos y de informacion recogidas de los componentes del PGI y del producto de informacion son utilizados para identificar TIlentes de defectos 0 la forma de optimizar el proceso completo. 5. los valores de las metricas I'eferentes a las dim. 200\: Loshin. Gestion para la Automatizacion de Planes de :Yledida. se desanollan esfuerzos para tomar medidas relacionadas con el y con sus componentes. Las conc\usiones obtenidas proporcionan una base para eliminar defectos detectados en los recursos afectados. 2002). Ii> (GPD) Amilisis Causal para la Gestion de Prevencion de Defectos. Ii> (GPO) Gestion de las Politic as de Calidad de la Informacion Organizativa. algunos de los pro-cedimientos de medidas y algoritmos (definidos en GQM) deben ser automatizados (Hinrinchs. como representar esas medidas y "a quien". "cU21ndo" y "como" medir.. Una forma de implementar todos los esfherzos mencionados anterio1111ente consiste en la definicion de politicas de cali dad de la info1111acion basadas en estandares previamente definidos. c.

Esto hace que los metodos de evaluacion y mejora de procesos software como CBA-IPl (Dunaway.308 CAUDAD DE SISTE\lAS f\FOR. actividad y componente. "No Satisfecho"}. 2001).. En el caso que nos ocupa.i. e e Para ca1cular estos estados se necesitan tres valores: .-\-\!A @ (GIDO) Gestion de la Innovacion y del Desarrollo de la Organizacion. estar en uno de estos estados: e Cada ACP puede estar en uno de estos estados: rCompietamente Satis/echo". la evaluaci6n y la mejora debe hacerse con respecto a un modelo de referencia. deban ser tenidas en cuenta a la hora de la elecci6n y definici6n de pasos. Cada actividad en las ACPs puede estar en uno de estos estados: {"Completamente Ejeclltado". "Parciaimente Ejeclltado". Similar al anterior ACP. ''Parciaimente Satisjecho". "Parcialmente Optimizado".\t. y dado que las citadas metodologias estan orientadas a la mejora continua.. 10 esta. Esto quiere decir que el resultado de la evaluacion sera un detel1ninado nivel de madurez (y otros valores numericos como se indicara posteriol1nente) y que la mejora debe hacerse bus cando incorporar las actividades de las cOITespondientes ACP propuestas para los niveles de cara a garantizar los objetivos de calidad definidos para cada una de ellas. 2004). Por OtTO lado. Son las bases para el concepto de mejora continua. TICOS :£ R. y al igual que OClUTe con las mencionadas metodologias para procesos software. "No Optimizado"}. los resultados se pueden usar para mejorar el PGI. EVAlVlECAL: METODOLOGiA DE EVALUACION Y lVIEJORA DELPGI Se pretende que EVAMECAL sea una metodologia orientada al PGl como una f0l111a de asegurar la cali dad del producto de inf0l111acion a traves del propio proceso de produccion y todo 10 relacionado con ese proceso de producci6n. los miembros del EGCDI deben usar EVAIvIECAL tomando como referencia para la evaluacion y la mejora el modelo de calidad bas ado en niveles de madurez definido por CALDEA.22): @ Cada Nivel de Madurez puede { "Consolidado . Antes de comenzar la presentaci6n de la metodologia es interesante explicar los tel1ninos en los que se va a llevar a cabo la evaluaci6n y la mejora para cada uno de los conceptos asociados al PGI: Nivel de madurez. 4. ACP.7.. la tercera y la cuarta patte de ISO/IEC 15504 (Redondo. 1996). EVAMECAL. "No Ejeclltado"} Cada componente puede estar en uno de estos estados: {"Compietamente Optimizado". "Satisfecho". "Optimizado". "Ejeclltado". .2. SCAtV1PI (SEl. "No Consolidado '/.. Los diferentes estados para cada elemento del marco pueden ser c1asificados como sigue (vease tambien tabla 10.

20 muesh·a los grados de criticidad para las ACP y las actividades del nivel de definicion.2.\"zl!llt!roCompont!ntt's VCI = _ _ I GradoCriticidadj '" VaioracionComponeJZte i j =i~. s. . Que representa una medici on de una de las dimensiones de calidad de datos y/o de info1111acion de cada uno de los componentes.12 es posible obtener un VCl. Formula para caIcular los estados de los componentes €I Grado de Criticidad (GCr) para cada uno de los componentes dentro de su grupo: as! es posible encontrar un Grado de Criticidad para cada ACP en los Niveles de r. Ese valor se mapea segill1 los rangos de valores definidos (compatibles con ISO/IEC 15504) en la tabla 10.lI1crocoll1!'ol1<!lIIcs NiveiCriticidad Figura 10. 4. Se calcula como la media ponderada de las calificaciones l1l1meriCaS obtenidas por cada uno de sus componentes en la evaluacion.21 muestra los mismos elementos para el resto de niveles.l2) . La tabla 10. y un Nivel de Madurez-VCI para el Nivel de Madurez (VCI-NM) puede ser definido como la media de todos los VCl -ACP para ese nivel y as! sucesivamente (vease figura 10. Valoracion de cada componente. Estos grados de criticidad pem1iten cuantificar la impOltancia de un elemento denh·o de un grupo de elementos. €I Con estos h·es valores y aplicando la for1llula dada en la figura 10.ladurez. Un VCI para una ACP (VCl-ACP) puede definirse como la media ponderada de todos los VCl-A para esa ACP.ticidad. Las valoraciones del PGI y los objetivos de mejora se establecen en . para cada Actividad de las ACP y para cada Componente en la Actiyidad..-l_----:-:--.-----::-_ _ _ _ _ _ _ _ _ _ __ Il~. el Valor de Calidad de Informacion para una Actividad (VCIA) podda ser definido con la media ponderada de los valores de dimension de calidad de datos de cada componente del PGI que pmticipe en dicha actividad teniendo en cuenta su grado de cri.22 para obtener el estado de cada uno de los componentes estudiados.e ha elaborado un cuestionario que pretende guiar las subsecuentes mediciones. La Metodologia La metodolog!a EVAMECAL establece los pasos que hay que dar para valorar y mejorar un PGl.12.1.10: CAUDAD DE LA "'rv""\l_~'L 309 €I Valor de Calidad de la Informacion (VCl) para cada elemento como un indicador del grado de calidad de datos y de la infOl1llacion. Se define un VCl para cada componente: de esta f01111a. Para los niveles de madurez.7. mienh·as que la tabla 10.

que pretende desaITollar soluciones para lograr los objetivos propuestos. Grados de Criticidad de ACP y Actiyidades del Niyel de Definicion El EVAlVIECAL-DO (ElVIC-D). I 40°" 30~o 30° 0 I I (ADM) Gesti6n de Proyecto de Mantenimiento. EV AIvlECAL puede resumirse como sigue: EI EVAlVIECAL-PLAt~ (ElVIC-P). Definicion de objetivos de mejora para los componentes del PGl en los mismos tenninos en los que se hizo la valoracion. ACP (GEGCDI) Gesti6n del Equipo de Aseguramiento de Calidad de Datos y de la Infonnaci6n.2.2. Consta de las siguientes actividades: EMC-D. (GP)Gesti6n de Proyectos PGI.l. Identificaci6n de las metlicas para I cada una de las dimensiones de cali dad 40"0 de datos y de infOl111aci6n. Ejecuci6n del Proyecto. Detem1inar la composici6n I 60% del EGCDI. I -+0° 0 I I I (GCl) Gesti6n de la Calidad de la Infonnaci6n en Componentes PGI. fase don de se analiza la situacion actual del PGl y se estable'cen los cOlTespondientes objetivos de mejora. Gc. Desarrollo 0 Adquisici6n de Bases de Datos 0 Almacen de Datos.!. Consta de las siguientes subactividades: . EMC-P.2. GC. 15% 60'io GP.20. Basado en el ciclo PDCA de Deming. Analisis de causas potencies y desan'ollo de un plan de mejora. Definici6n e implementaci6n de un proyecto para la implantaci6n del PGI. GEGCDI.I.1. Definici6n del PGI. Definir un entomo 40% operativo.DE SISTEMAS INFO~YLA.2. I I Tabla 10. 25% I AD1\·1. I GP. I GCR-I ACP 10% ACTIVtDADES ACP GEGCDI. Identitk3ci6n de las dimensiones 60° 0 de calidad de datos v de infonnaci6n. Valoracion del estado actual de la calidad de datos y de infol111acion del PGl en tenninos de VCl y niveles de madurez.2.l. Consta de las siguientes actividades: EMC-P.TIeos © RA-:'IA tenninos de niveles de madurez.

1. donde el objetivo es comprobar la eficiencia del plan de mejora ejecutado. bases de datos y administraci6n de almacenes de datos. Valoracion del PGI y de sus elementos tras el plan de mejora EMC-C.l. atencion tecnica.l. proyectos de planificaci6n de sistemas y migracion a importantes SGBD. Poseen un s6lido conocimiento y fOI1nacion en estandai'es de calidad de sofuvare e Ingenieria del Sofuvare. Los servicios que ofrece son consultoria. los dieciocho del Departamento de Sistemas son los que organizan los recursos que dan sopOlte infol111atico al resto de los departamentos. 4. Ejecucion del plan de mejoras.Amilisis detallado de las causas reales del problema. Consta de las siguientes subactividades: EMC-C. €I EVAIVIECAL-CHECK (EMC-C). 1. La principal actividad de la compania es desanollar sofuvare. La compania ha obtenido la certificaci6n ISO 9000.Q.3.AL se presentan a continuacion los resultados obtenidos cuando se aplic6 a un PGI de una organizaci6n con experiencia en gesti6n de infoI1naci6n.2.2. Con un total de ochenta y nueve empleados.MA CAPiTULO 10: CAUDAD DE lA INFORlvLACION 311 EMC-D. EMC-A. Estandarizar las lecciones aprendidas para evitar problemas similares en el futuro. €I EVAMECAL-ACT (EMC-A).2. EMC-C.l.l.1. R. Amilisis y comprension del problema EMC-D.1.7. . f0l111acion. EMC-D. Consta de las siguientes actividades: EMC-A.3. 1. ventas de licencias. 1. Consta de la siguiente actividad.3.A-. EMC-D2.Comparacion de los resultados con los obtenidos en la subactividad EMC-P. EV AMECAL fue aplicado siguiendo los pasos previamente descritos. desanollos a medidas. Comprobar la eficiencia del plan de mejora. Desanollo de un plan de mejoras. Obtener conclusiones a partir de los inf0l111es del plan de meJora. EMC-C. EJEMPLO DE APLiCACiON DE CALDEA Como ejemplo de utilizacion de CALDEA y EVAMEC. I .l. fase en la que se pretende estandarizar los conocimientos adquiridos en to do este proceso. Elaboracion de los infoI1nes peltinentes.

Estudio para la automatizaeion de los planes de medida. Implementacion de solueiones para la elimiriacion de las causas de los problemas. Analisis de los datos para la mejora organizacional.l. Disefio de soluciones para la eliminacion de las causas de los defectos.3.2. GAPM.0 Politicas Organizacionales.2. GPO. Estimacion impacto de la pobre calidad de datos y de infol1nacion GIR. Grados de Criticidad de Areas ClaYes de Proceso y ActiYidades del resto de niveles de CALDEA . Eleccion de Politicas Organizacionales de Calidad de Datos y de Infomlacion. Disei'io de propuestas para la mejora de la calidad de los datos y de la infonnaeion. Implementacion de soluciones para la obteneion de las mejoras.2. GPD. GPD.2. GIOO. GE. GPM. Eleccion de Estandares de Calidad de Datos Y de Infol1nacion..o VV.4.21.. 50% :~ a . Ejecucion del Plan de pruebas para la verifieaeion y la validacion. GIOO. 25% (GIR) Gestion del Impacto de la Pobre Calidad de Infol1nacion y de los Riesgos. Definicion de planes de contingencia para esos riesgos. 100°0 60°0 "" o£.2. 60°" 40% 60°" 40°0 0 30 " 30°0 40°0 (GPO) Gestion de las Politicas de Calidad de la Infol1nacion 25% I GPO. Revision y complecion de las ERU con la infomlacion expuestas en los estandares y las politicas. GPD. <> 50'io GAPi\l.2: Z ~ 0.2. Disel1.l.)-01 0 Z > (GE) Gestion de la Estandarizacion de la Calidad de la Infol1nacion. Creaeion de un infomle con las posibles mejoras. 40°0 60" 0 40°0 ~ i I (GAPM) Gestion de la Automatizacion de los Planes de Medida.3.I. 25°0 I I i ~5°o ! 25°0 l 25°0 25° () ~5°u 25°0 25° () Tabla 10.2. I (GIOO) Gestion de la Innovacion y del Desarrollo de la Organizacion. Implementacion de los aspectos de automatizacion de las metricas. GIR.I. Definicion de un plan de medida para cada una de las metricas. GIOO. I.ivL-\TICOS I ACP GCR-' ACP ACTlVlDADES ACP GCRAcnv (VV) \Oalidacion y Verificacion de Componentes de PGI y Productos de Informacion. Crear un infol1ne con los defectos encontrados.312 CAUDAD DE SISTE'vL-\S INFOR. Identificacion de los aspectos necesarios para cada una de las metricas. GE. '"" (GM) Gestion de los Planes de Medida. Disel1. -0 0 _) /0 . :~nalisis de la simacion para Ia detenninacion de causas de problemas.3. GIOO. ! I i i 70% GPM. 25~.l.0 de un Plan de pruebas para la veritlcacion y la validacion de los componentes del PGI Y del producto de infomlacion. VV.!.I.4. GE. 30 °10 I (GPD)Gestion de Prevencion de Defectos para el Analisis de Causas. ~g B Co.

0 unidades de Completamente Optimizado' Completamente Ejecutado No Satisfecho Satisfecho. detem1inando que recursos se van a usar y gestionando distintos aspectos de calidad de la fon11aci6n. Optimizado Ejecutado.CAPITULO 10: CAUDAD DE LA Il\'FOR. La organizaclOn utiliza para la gesti6n de estos temas una aplicaci6n llamada SINCRO. mateliales didacticos proporcionados. Uno de los empleados del Departamento de . os VCIS20 Hay poca 0 ninguna evidencia de la consecucion del estado para el elemento evaluado. instalaciones.22. Existen fon11ularios para recabar datos sobre cursos demandados y para las evaluaciones de la calidad de los ejercicios propuestos. Este proceso esta adecuadamente especificado y documentado en elmanual de calidad de la e:11presa. 86 S VCI s 100 Hay e\-idencia de una completa aproximacion y consecucicin del estado para el elemento evaluado_ No existen debilidades significativas en los componentes definidos. Estados de los componentes y rangos de valores segun IQV Entre todos los PGI de la organizaci6n. 61S VCI s85 Hay evidencia de aproximacicin y consecucion signiticativa del estado para el elemento evaluado. desalTollada intemamente.\lACION 313 NmmRE ESTADO R\NGOVCJ DESCRIPCloN No Optimizado No Ejecutado. el marco de trabajo se aplic6 al Proceso de Gesti6n de Fon11aci6n. 21 S VCI s 60 Hay evidencia de aproximacion y consecucion del estado para el elemento evaluado. Parcialmente Optimizado' Parcialmente Ejecutado. El principal objetivo del PGI estudiado es la gesti6n de los datos relativos a la fon11aci6n. Algunos aspectos de la consecucicin pueden scr impredecibles. eligiendo quien va a ser el fon11ador. asistencia y uso de recursos. consistente en satisfacer demandas intemas y extemas' para la fom1aci6n. EI rendimiento del proceso puede variar en algunas areas trabajo. y para la capacidad de los profesores. OS VCI -Ni'! S 90 91 S VCI -NM S 100 Rango de valores para el VCI definido para el Nivel de Madurez Tabla 10. que es responsabilidad del Departamento de Consultoria.

< .. Desarrollo 0 Adquisici6n de Bases de Datos 0 Datawarehouse. No Satisfecho Parcialmente Satisfecho Parcialmente Satisfecho No Satisfecho NoEJECuTADO NIVEL DE l'\TEGR.' '.. NIVEL DE lVlEJOR. Resultados obtenidos despues de aplicar EV AMECAL al PGI Gestion de Formacion . No Satisfecho No Satisfecho (ACGPD) Amilisis Causal para la Gesti6n de Prevenci6n de Defectos (GIDO) Gesti6n de la Innovaci6n y del Desarrollo de la Organizaci6n Tabla 10. No EJEctTrAl>O (GEAGI) Gesti6n del Equipo de Aseguramiento de Calidad de la No Satisfecho InfoTInaci6n." .. (GEC!) Gesti6n de la Estandarizaci6n de la Cali dad de la InfoTInaci6n (GPCIO) Gesti6n de las Politicas de Calidad de la Infonnaci6n No Satisfecho Organizativa."CION (VV) Validaci6n y Verificaci6n de Componentes de PGI y Productos de No Satisfecho Infonnaci6n (GR) Gesti6n del Impacto de la Pobre Calidad de InfoTInaci6n y de los No Satisfecho Riesgos..23 se muestran los plincipales resultados de las encuestas. En la tabla 10..' ' No Satisfecho No Satisfecho . TICOS Consultoria.FORIvL-\.. .. (GFDDPI) Gesti6n de Fuentes de Datos y DestiTIos de Producto de Infonnaci6n.23. Todas las preguntas de los infonnes se realizaron al Director del Departamento de ConsultOlia. NIVELnE DEFINICION ". No EJEcuTAl>O.... .. '.'..314 CAUDAD DE SISTEi-!AS I!'-. No EJECUTADO NIVEL DE GESTION CUANTITAmA (GM) Gesti6n de las Metricas del PGI (GAPM) Gesti6n para la Automatizaci6n de Planes de Medida . (GRU) Gesti6n de Requisitos de Usuarios. (GPMDABDD) Gesti6n de Proyecto de Mantenimiento. . (GCl) Gesti6n de la Calidad de la InfoTInaci6n en Componentes PGI. No Satisfecho . . . RESULTADOSDE LoslNFORMES ... es el responsable de transcribir datos de los forrnularios a la aplicacion y obtener la infonnacion que sera transmitida a la persona adecuada.

se propusieron las siguientes recomendaciones para satisfacer el nivel de definici6n de las ACPs: G Fonnar un Equipo de Aseguramiento de la Calidad de la Infonnaci6n que asuma la responsabilidad de gestionar el PGI. Wang. liiformation and database quality.T. C. M. LECTURAS RECOMENDADAS G English. Alanaging Iliformation Quality. Y. Upper Saddle River. Piattini. G G G G . Gestionar adecuadamente los requisitos de los usuarios. proponiendo un modelo muy interesante. Modificar la base de datos de calidad. Quality liiformation and Knowledge. Springer. 1999. 0 G G G G la Datawarehouse para dar soporte a infonnaci6n G Planificar un proyecto para el desarrollo del PGI.. y Calero..) (2005). L. Alemania 2003. EEUU. Lee. 1999. Referencia de obligada lectura que trata sobre el modelo TDQM propuesto por el MIT. Acorde con el grado de criticidad de cada ACPs. 5. (eds. A partir las ERU. (eds. Libro considerado como uno de los c1asicos del campo de calidad de datos y de infol111aci6n..P. K. Improving Data Warehouse and Business Iriformation Quality: klethods for reducing costs and increasing Profits. gestionar adecuadamente las dimensiones de calidad de la infonnaci6n para cada uno de los componentes del PGI. afronta c6mo tratar la calidad de los datos mediante una metodologia muy completa y exhaustiva que implica a la propia organizacion como "brazo annado" de las iniciativas de mejora. Genero. R. Se establecen los principios basicos de esta filosofia sobre la calidad de los datos.. Prentice Hall. M. Calero. especialmente de los diferentes modelos de UML. M. Kluwer Academic Publishers. Willey & Sons. el autor da su visi6n paIiicular sobre la gestion de la calidad de la infonnaci6n. Imperial College Press. todos los niveles estan en el estado "No ejecutado ". En esta recopilaci6n se abordan diversos aspectos de la calidad de los datos y de la infOlmaci6n. J.~ RA-:v!A CAPiTULO 10: CAUDAD DE LA rNFORMACION 315 Los resultados reflejan que ninguna de las ACPs que pertenecen al nivel 2 y a niveles supeliores pertenecen como mlnimo "Satisfecho ". En esta obra se resume el estado del arie sobre las metricas para modelos conceptm!les. Piattini.) (2002). Eppler. y Genero. En este libro. UK. Norwell. Identificar y definir tanto fuentes de datos como destino de los productos de infonnaci6n y los fonnatos de intercambio de datos. Metrics for Conceptual Models. Huang. M. C. M.

1998) propuestas para la evaluaci6n de modelos E/R.Que similihldes y que diferencias encuentra entre la propuesta de Kesh y la de Moody? Analice la aplicabilidad en la practica de ambas propuestas. Proponga. SITIOS WEB RECOMENDADOS e http://web.iqconference.UU).mit. organizado por el Sloan School of lvlanagement del MIT (Boston. Puede ser considerado como el proyecto matriz de much as de las investigaciones academicas sobre el tema.A. http://www. 1994) como las metricas (Moody.edu/tdqm/. EJERCICIOS 1. En este congreso confluyen los resultados de los desatTollos de investigaci6n de las universidades con las necesidades de las empresas en los proyectos de evaluaci6n y mejora de la cali dad de los datos y de la infol111aci6n.esla web del International C01?(erence on li!(ormation Quality (ICIQ). EE.Que metricas de bases de datos relacionales opina que pueden seguir siendo validas para bases de datos objeto-relacionales? c. coordinado por Richard Wang. 6. Que caracteristicas de la n01111a ISO 9126 cree que son aplicables a la hora de evaluar la calidad de un SGBD? Daniel Moody en los liitimos cinco anos ha llevado a cabo diferentes eshldios con el fin de validar tanto el marco (Moody y Shanks. 2. Analice los eshldio que pueda encontrar en la bibliografia y detelmine hasta que punto validan sus propuestas. .Que nuevas metricas podrian proponerse? Analice la variaci6n que sufi'en los valores de las metlicas propuestas para almacenes de datos cuando se utiliza un esquema en "copo de nieve" (snmtjlake) respecto al esquema en estrella. 4.Que metric as de las defmidas para sistemas Olientados a objetos pueden utilizarse para bases de datos objetorelacionales? c.C6mo podria demostrar que las metlicas propuestas pem1iten predecir la mantenibilidad de las bases de datos relacionales? c.onz. En este capihllo se han presentado algunas metricas para bases de datos relacionales pero no tienen en cuenta las restlicciones presentes en las mismas.316 CAUDAD DE SISTEMAS ll'iFORM.TICOS 6. c. c. es uno de los congresos mas antiguos y con mas solera de calidad de datos y de info11naci6n. 5. 3. c.esla web del proyecto TDQM. siguiendo el Metodo Alarcos para metlicas software presentado en el capihllo algunas metlicas para las restlicciones (clallsulas CHECK y ASSERTION) de bases de datos que sigan el estandar SQL. e 7.

Que dificultades presentan a la hora de calcular sus val ores'? Proponga alguna tecnica (0 extensi6n de las existentes) para reflejar requisitos de calidad en especificaciones de requisitos tanto textuales como gnificas. 9. Compare las dimensiones para calidad de datos propuestas por English (1999) con las de Pipino et al. calculando todos los VCl.-\-:-'lA CAPiTCLO 10: C. Analice hasta que punto la metodo10gia EV AMECAL es confo1111e a SCAMPI 13. 14. R. 8. (. Describa algllI1 Proceso de Gesti6n de Infonnaci6n (PGI) de su organizaci6n.MECAL. 10. (2002). Ana1ice hasta que punto el modelo CALDEA es COnf0I111e a las especificaciones de CMMl.C. (. 15. Ana1ice hasta que punto elmodelo CALDEA es conf0I111e a las especificaciones de la nonna ISO 15504.Que indicadores para la cali dad de datos Ie parecen m:1S relevantes'? (. Identifique dimensiones de ca1idad de datos y de infonnaci6n y las metricas cOITespondientes que puedan ser aplicadas al PGI que acaba de describir. Ap1ique EVA. 12. 11.en que nivel de madurez esta'? .-\UDAD DE LA I"FOR~!ACI6" 31 i 7.

.

Aprender de las expeliencias. incluso. . en ocasiones se vetifica que no se cumplen las promesas realizadas a los clientes.1. Estos autores afmnan que cuando un empleado se va de la organizacion. Empaquetar experiencias exitosas. Evaluar los exitos y fracasos. otras veces se "redescubren" experiencias cuya existencia se desconocfa. INGENIERIA DEL SOFTWARE Y GESTION DEL CONOCIMIENTO 1. Reutilizar expetiencias exitosas. con el se "pierde" la expetiencia que este ha ido adquilido a 10 largo del tiempo que ha estado trabajando (a veces. Necesidades de gestion del conocimiento en organizaciones de software Como seiialan Basili et al. ni se sabe que es 10 que se ha perdido).CAPITULO 11 GESTION DEL CONOCIMIENTO "lnvertir en conocimiento produce los nzejores bene/icios " Benjamin Franklin 1. y que el personal no se desarrolla adecuadamente por falta de conocimiento. simplemente por desconocimiento de las mismas. (2001) pnicticamente todas las organizaciones que desarrollan y mantienen sofuvare comparten las siguientes necesidades: • • • • • Comprender los procesos y productos.

2000) y que empiezan a adoptar arquitecturas de gestion de conocimiento como la que se muestra en la figura ILl (Lawton. La reutilizacion de experiencias./hmre. En este sentido hay que destacar que varias de las actividades de gestlon del conocimiento en general (como la reutilizacion . Existe ya bastante experiencia en organizaciones de todo tipo que demuestran como se puede gestionar el conocimiento (Davenpori y Pl1lsak.. la gestion de competencias. la gestion de documentacion.de activos. la gestion del conocimiento se da especificamente en las siguientes areas: e Gestion de configuracion y control de versiones.320 IMORlvL.en gran medida. RA~lvLA Esto es debido a que las organizaciones dedicadas al desalTollo del software rcquieren y generan grandes cantidades de conocimiento. Conocimiento del proceso. de dichos conocimientos. 2003). Decisiones de diseiio C'design rationale"). La mejora de los procesos de desalTollo del software. as! como tomar mejores decisiones". e . que indica la evolucion del software y puede servir para identificar experios (quien ha hecho determinados cambios). ya que los sistemas de este tipo crean indirectamente la memoria del proyecto. La reutilizacion de artefactos del proceso de desatTollo.\ TIeos 1. la gestion de conocimiento se puede considerar el nexo que une las actividades de produccion diatias con las iniciativas de mejora y los objetivos de negocio. la colaboracion 0 las redes de expelios) pueden resultar muy titiles para la Ingenieria del Software (Aul1lm et al. 2000. en las organizaciones software. Tiwana. En este sentido. ya que los procesos de desatTollo y mantenimiento de software dependen -adelmis de la creatividad de las personas y el funcionamiento de los equip os. Lindvall y Rus (2003) afil111an que la gestion del conocimiento pennite 'producir mejor so. COllOcimiento del proyecto. Adelmis. de diverso tipo: e Conocimiento del producto. de una '/or/lla mas rapida y economica.:. ya que facilita: e e e e La localizacion de Ulentes de conocimiento. Como puede observarse en esta figura. que es una aproximaclon que consiste en capturar explicitamente decisiones de diseilo para crear una memoria del prodllcto. 2001). e e La calidad del software y de los SI no puede ser mejorada si to do este conocimiento no se encuentra disponible 0 no se utiliza adecuadamente.

1.CAPiTCLO II: GESTIO. que contlibuye indirectamente a la memoria del producto.. fa informacion y las Izabilidades individuafes se recogen.Neb Figura 11. e Nive! de Aplicacion Inteligencia Competitiva Sistema de Majores Practicas Interfaces Portal de Conocimiento Servicios de Gest"lon de Conoclmiento Servicios de Descubrimiento Servicios de Co[aboraci6n Taxonomia Corporativa r.acion". Gestf6n de Documentos E!ectr6nicos Correo Electrcnico '. como resultado de la gesti6n del conocimiento: e Se establece y mantiene una infraestrLlctma para la compartici6n de la intonnaci6n comllI1 y de dominio a traves de la organizaci6n. Herramientas CASE y entornos de desarrollo de software.an y mejomn a 10 largo de la OIgani::. Servidores de Fichera y Servicios de ImernetfExtranet Informacion y ruent8 de Conocimiento. podrian llegar a transfonnarse en conocimiento 'positivo". Informe de problemas y trazabilidad de defectos. .2. cuyo prop6sito cs "asegumr que ef conocimiento. DEL CO~OCE\lIE~TO 321 e e Trazabilidad. 2001) 1. SegllIl esta nonna. pudiendose considerar fuentes de conocimiento "llegativo".1apa de Conocimiema Gesti6n de Contenidos RepoSltorio de Co nacimiento Inrraestructura Correo Electronico. los cuales. Arquitectura de gesti6n de conocimiento (Lawton. cOil/parten. relltili::.-. La gestion del conocimiento y los procesos del cicio de vida del software En la nOIma ISO 12207 aparece un subproceso rc1ativo a la gesti6n del conocimiento dentro del proceso organizacional de Recursos Humanos.

incluyendo la infraestmctura y la fonnaci6n para sopOliar los contribuidores y los usuarios de los activos de conocimiento de la organizaci6n. Aprendizaje asistido pOI' ordenador (e-Iearning). Sistemas de razonamiento basado en casos. o o o En el siguiente apartado se muestran tecnicas y herramientas utilizables para la realizaci6n de estas tareas. el esquema de clasificaci6n y los criterios para estos activos. EI director estableceni una red de expelios dentro de la organizaci6n y se asegurani que se mantiene actualizada. patrones y buenas pnicticas. 2000): o El director planificani los requisitos para gestionar los activos de conocimiento de l'l organizaci6n. o A continuaci6n se resumen las tareas relativas a la gesti6n del conocimiento (ISO. Modelos de predicci6n. La organizaci6n seleccionan't la estrategia de gesti6n del conocimiento apropiada. Portales e intranets de conocimiento. bibliotecas y repositOlios de conocimiento. Se llevani a cabo la gesti6n de configuraci6n de los activos de acuerdo con el proceso de gesti6n de configuraci6n. El director estableceni un mecanismo para soportar el intercambio de infonnaci6n entre expeltos y el flujo de la infonnaci6n de los expertos en los proyectos de la organizaci6n.322 CAUDAD DE SISTEMAS lNFORIvlATICOS @RA-MA o El conocimiento se encuentra disponible n'tpidamente y compartido por toda la organizaci6n. Sistemas de soporte a la toma de decisiones.3. Sistemas de gesti6n documental. . Lecciones aprendidas. 1. "Caliografia" de conocimiento. Tecnicas y herramientas para la Gesti6n del Conocimiento Se pueden destacar diferentes tecnicas y herramientas para la gesti6n del conocimiento: o o o o o o o o o Sistemas cooperativos y de trabajo en grupo (groupware).

Gestores de habilidades y sistemas de apoyo a la localizaci6n de expertos. 1. Deseado.~ RA-MA CAPiTULO 11: rcc--rrr. Cuestiones organizacionales.4. tales como falta de tiempo de los empleados. Estandares y nonnas de ISO. existen h'es factores importantes que posibilitan el proceso de implantaci6n de estrategias de gestion del conocimiento en las organizaciones de software: • La tecnologia disponible en la organizacion para los desarrolladores. 0 En Vizcaino y Piattini (2006) se profundiza y presentan ejemplos de estas diferentes tecnicas y henamientas. Implantacion de la Gestion del Conocimiento En la implantaci6n de estrategias de gesti6n de conocimientos. como la "Softlrare Process Improvement Netlvork. Centro de soporte de fabricantes. tales como fallos del proceso de estrategia e implementacion de gestion del conocimiento. IEEE. Flujos de conocimiento." (SPIN) los grupos de interes de IEEE 0 ACM. Comunidades de pnicticas. plantillas. y de trabajadores de conocimiento. GUlas para proyectos. etc. • . el no querer compartir 0 reutilizar el conocimiento. etc.. Proyectos cuyo objetivo es construir bases de conocimiento en ingenieda del software como CeBASE y ViSEK. como el Oracle Support Center. Elliderazgo que pretende impulsar la gestion de conocimiento en el desanollo de los productos y servicios software as! como en los procesos de trabajo. Lawton (2001) destaca los siguientes obstaculos: • Cuestiones tecnologicas: a veces no es posible integrar los diferentes sistemas para conseguir los niveles adecuados de acceso y distribucion de conocimiento.' DEL CONOCIMIENTO 323 • • • • • • • • • Tecnicas de descubrimiento de conocimiento ("Knowledge discovel)' "). etc. que Ie pennitira crear un repositolio de memoria organizacional accesible a toda la organizacion. • • Por otro lado. Cuestiones particulares de los h'abajadores de la organizacion. Redes extemas.

Experience Factory Group. etc. (I (I Ebert et al. (2003) sefiala que para garantizar el exito de un programa de gestion del conocimiento es obligatorio elegir el modelo de gestion del conocimiento adecuado. experiencias. ingenieria. y puede realizarse en: (I Soporte del proceso software. Para dar sopOlte a una gestion efectiva de conOClImento en el desalTollo de software. actividades.. que se refleja en la necesidad de crear un grupo dedicalio a la mejora de los procesos sofuyare -que se denomina de diferentes fonnas: SPEG (Sojhmre Process Engineering Group).1701\"). etc. modelos de mejora de procesos.-\UD/\D DE SISTEi--HS Ii'FORyL-\TIeos I:RA-MA (I La cultura organizacional que soporte la comparticion de conocimiento.. :\Iodelos de Gesti6n de Conocimiento y estrategias empresariales (Ebert et al. SPI (Sojhmre Process JllIpr01'elllent) group. los conceptos de gestion del cOllocimiento y el tipo de conocimiento (vease tabla 11. tecnologias e innovacion. El modelo de gestion del conocimiento se enlaza con la estrategia empresariaL la organizacion de la gestion del conocimiento. etc. se requiere el soporte tanto de la propia gestion como de los niveles tecnicos. entre los que destacan los propuestos por Dyba (2003) y Oliver et al. 1.{MLKION CO?\CEI'TOS TlPODE co:\ocnUE:i\TO Reducci6n de costes Especializaci6n Innovaci6n Productividad Cali dad Creatividad Compartir. (2003). la gestlon del conocimiento implica una impOltante iI1\-eI"S IOn.1. SopOlte al personaL adaptar una helTamienta de flujos de trabajo (1\·orl.1) ESTRATEGIA DIPRESARIAL MODELODE GESnO" ORG. modelado.e idealmente crear la funcion de "Chie/Knowledge Otficer". 2003) Ademls. Modelos de Gesti6n de Conocimiento en ingenieria del Software Existen muchos modelos de gestion del conocimiento en general. resultados de los procesos. disefio. . evitando redundancia Mcjores pnicticas Integraci6n y c0l11binaci6n de conocil11icnto Base de in!ollnaci6n Proccsos comunes Conocil11icnto dinul11ico Explicita Explicito Tacita I I Tabla 11. SopOlte del producto software.324 C.5. y en los tlltimos ai'ios han aparecido yarios especificos para la ingenieria del sofuvare.

Este modelo consta de cuatro elementos principales (vease figura 11. coordinacion y colaboracion. Este modelo trata de como los equipos de software adquieren y utili zan conocimiento en un entomo organizacional para l11ejorar sus procesos software._. que reflejan las condiciones que facilitan la creacion de conocimiento y la mejora de procesos software. Desempefio organizacionaL que agrupa los resultados de las actividades de mejora de la organizacion.2): e Contexto organizacionaL que describe el entomo general que impone restricciones y opOltunidades acerca de 10 que puede y no hacer la organizacion. Modelo dimimico de gestion del conocimiento (Dyba.2.. 2003) .5. CicIo de aprendizaje.1. que comprende el proceso dialectico que integra 1a experiencia local y los conceptos organizacionales. MEMORIAl . Factores facilitadores. Ii) e e Este autor define la creacion del conocimiento en Ingenieria del Software como el intercambio dimimico entre dos dialecticas: entre el conocimiento organizacional y el local: y entre la generacion y la interpretacion del conocimiento organizacional.: RA-MA CWiTULO 11: GESTIO!\' DEL CO?-:OCIMIE?-:TO 325 1.. En este modelo se integra las actividades de creacion del conocimiento junto con el "trabajo real" del desaITollo de software. I -I-. MODELO DE DYBA (2003) Dyba (2003) propone un modelo dimimico que se centra en las necesidades de comunicacion.ORGANIZACIONALI i /.f v INTERPRETACION CONOCIMIENTO o R G '\/ CONOCIMIENTO LOCAL A N I Z A o N C I A L Figura 11.._ :_i\ / FACTO RES \1-' ) \~ACILITADORES .

1.-. DE LOS DIPLEADOS PREOCUPACIO:-l POR LA :\IEDICIO:-l EXPLOTACIO:-l DEL CO.2. X I lVIEMORIA ORGA1'ljlZ. CONOe. Las dificultades mas importantes que sefialan la mayor parte de los autores son hacer tacito el conocimiento explicito y mantenerlo actualizado. basada en una infraestructura organizativa denominada 'factoria de experiencia".. Este modelo (vease figura 11. EXISTEi\TE EXPLOR-\CIO. (1995) presentan el paradigma de mejora de la cali dad (QIP. QIP (Paradigma de mejora de la calidad) Basili et al.TICOS ©R. XX X X X I X XX XX X XX XX XX X XX X X XX XX I Tabla 11.5.OC.-MA Ademas. Ademas. (2003) presentan el modelo SEKS (Software Engineering Knowledge-Sharing). en el desarrollo y mantenimiento de software podemos encontrar tanto conocimiento del dominio del problema como conocimiento del dominio de la soluci6n.3) reconoce la interacci6n entre los individuos y dentro de los equipos como producto de tres factores: motivaci6n para descubrir conocimiento. li~TERPRET. Relaciones entre los procesos de creacion de conocimiento y los factores facilitadores (Dyba.-'.-'. 2. DE :-IUEYO CO:-lOC. FACTORES FACILITADORES ORlE:-ITACIO:-l AL :-IEGOCIO I:\IPLICACIO:-l DE LOS LiDERES PARTICIPACIO. MODELO SEKS Por su parte. Dyba identifica seis factores facilitadores en la creaci6n de conocimiento de ingenieria del sofuvare y analizando las relaciones entre los procesos de creaci6n de conocimiento y otros factores facilitadores (vease tabla 11. Oliver et al. CONOe. 2003) 1. una cultura de apoyo y la experiencia previa. Quality Improvement Paradigm). LOCAL GENERACION CONOe.326 CAUDAD DE SISTE?vIAS INFORtvL-'.2.".2). que es una aproximaci6n a la medici6n y control de la calidad dirigida por objetivos. Asociados a estos factores se encuentran el deseo y la oportunidad de aprender. FACTO RIA DE EXPERIENCIA V PARADIGMA DE MEJORA DE LA CAUDAD (QIP) 2. .

3. EI proceso de mejora de la calidad. Fijaci6n de objetivos. ocwTe en seis pasos. que consta de los siguientes pasos: e e Caracterizaci6n. que es un proceso iterativo que a cada iteraci6n redefine y mejora las caracteristicas y los objetivos. 2003) EI objetivo de este paradigma es la adquisici6n de competencias bcisicas que sopOlien competencias estrategicas y la mejora de la calidad en el entomo de desarTollo -en lugar de en el de producci6n.mediante la reutilizaci6n del conocimiento y la expenencla.~ RA-MA CAPiTULO ii: GESTION DEL CONOClMIENTO 327 OPORTUNIDAD DE APRENDER CULTURA DE APOYO (NIVEL ORG. tecnicas y herramientas adecuadas al problema.. Elecci6n de procesos. agmpados en dos ciclos: I. sobre 10 que quiere conseguir para el siguiente producto y aprender acerca del negocio. Modelo SEKS (Oliver et al. e . CicIo de Aprendizaje Corporativo. metodos. E INDIVIDUAL) DES EO DE APRENDER MOTIVACION PARA DESCUBRIR CONOCIMIENTO COMPARTICION DELCONOCIMIENTO ENINGENIERIADEL SOFTWARE EXPERIENCIA PREVIA Figura 11. la empresa construye modelos del entomo actual.

o de coste y calidad. con el fin de capturar la experiencia. 2. infol111acion sobre el proceso. configuraciones base. y datos. Esta infol1nacion se utiliza para prevenir y solventar problemas. por un lado. en la que la reutilizacion de experiencia y el aprendizaje colectivo se convielien en una cuestion corporativa. La organizacion almacena y propaga el conocimiento. que comprende las siguientes actividades: e e e Se inicia con la ejecucion. La factoria de expeIiencias transfol1na estos elementos en unidades reutilizables y proporciona. Como se muestra en la figura 11. los productos. lecciones aprendidas. un "cicio de capitalizacion". a la organizacion de proyectos. registros de calidad. la realimentacion a la organizacion. 2. Factoria de experiencia La factoria de experiencia consiste en una organizacion basada en la capacidad. para aplicarJa a otros proyectos. datos de desanollo. Producir un repositolio de datos y modelos software que esten basados emp!ricamente en la pnictica diaria. Por otro. monitorizar y soportar el proyecto y realinear el proceso con los objetivos.4. durante la cual se analiza los resultados intel1nedios para ver si se satisfacen los objetivos. as! como los datos obtenidos durante el desanollo y la explotacion. acumularla y transferirla. henamientas. planes y modelos utilizados. la organizacion de proyectos proporciona a la factoria de experiencia caracteristicas del proyecto y entol11o.'\' TICOS DRAAIA e Ejecucion. infol1nacion sobre la utilizacion de recursos. y que proporciona infol1nacion analitica acerca del desempeflo del proyecto.!AS lMOR"!. La organizacion analiza los resultados para aprender de ellos.2. Los beneficios que aporta una factoria de experiencia a la organizacion son variados: e Establecer un proceso de mejora de software sus tent ado y controlado por datos cuantitativos. La factoria de experiencia proporciona "ellister de cOlllpetencias" denominados ''paqlletes de experiencias". existe un '"cicio de control" que es la realimentacion al proyecto durante la fase de ejecucion. Cicio de Aprendizaje de Proyecto. As!. Desanollar una organizacion de sopOlie intel110 que limite la sobrecarga y proporcione beneficios sustanciales de desempei'i. cabe destacar. e e . parametrizados de alguna fOI111a para adaptarse a las caracteristicas de los proyectos especificos.328 CAUDAD DE SISTE'.

(. e incorporar en los procesos nuevas tecnologias que hayan demostrado ser valiosas en contextos similares. 2. Disponer de metodologias que establezcan como se estructura la experiencia.: It/>''-\lA CAPiTULO II: GESTION DEL CONOCI?vlIE]\TO 329 '" Proporcionar un mecanismo para identificar. 0 el EPIK (Engineering Process JmprOl'ement and Kn01t1edge Sharing) de ICL. Factorla de Experiencia propuesta por el Prof.4. una base de experiencia debe: '" '" '" '" Contener el conocimiento relevante para la organizaci6n. valorar. Residir en un marco de aprendizaje bien concebido. procedimientos y reglas que establezcan gestiona la experiencia diariamente.3. Disponer de procesos. BasHi Ejemplos reales de factorias de experiencia son el SEL (Sofhmre Engineering Laboratory) del Goddard Space Flight Center de la NASA. el SEC (Sofhmre Experience Center) de DaimlerCluysler. '" ORGANIZACION DE PROYECTO DATOS EJECUCION DEL PROCESO I"""""" i-' PRODUCIDOS Modelo de ejecucion I I PLANIFICACION DEL PROCESO ~ I- EXPERIENCIA EMPAQUETADA Figura 11. C01110 se . Base 0 repositorio de experiencia Seglll1 Basili y Caldiera (1995). Incorporar y sopOltar la reutilizaci6n en el proceso de desan'ollo de software.

330 CAUDAD DE SISTE\e[AS rNFOR:'vLA.TICOS

© R.,\,,-NL-\

(I)

Estar automatizada 10 maximo posible.

Estos autores prop on en una serie de pasos para crear un sistema de gestion de expeliencia (SGE):
e

Caractelizar la organizacion e identificar los procesos y conocimientos actuales. Identificar los usuarios y definir roles de usuario. Desanollar casos de uso. Definir tipos de paquetes (taxonomias). Generar los atributos que describen los tipos de paquete. Definir valores aceptables para cada atributo. Definir un documento de requisitos para el SGE. Construir, integrar e instalar el SGE. Evaluar y hacer evolucionar el SGE.

e
(I)

e e
(I)

&

e e

De fonna parecida, en Althoff y Pfahl (2003) se presenta una metodologia ("DISER"- Design and Implementation on So./hmre Engineering Repositories) para construir y operar EBIS (Experience-Based li!/ormatioll Systems) que se resume en los siguientes pasos: 1. 2. 3. 4. 5. 6. 7. 8. 9. Desanollar una vision del EBIS. Fijar objetivos. Fijarareas. Definir escenarios de utilizaci6n y cumplimentaci6n. Modelar la ontologia de la experiencia. Implementar el EBIS. Poner en-linea el EBIS. Mantener el EBIS. Integrar el conocimiento existente y generar nuevo conocimiento

Hay que tener en cuenta diferentes aspectos de calidad a la hora de construir y gestionar un repositorio de experiencia (Schneider y von Hunnius, 2003):

1': RA.-MA

CAPiTULO 11: GESTION DEL CONOCI1\lIENTO

331

e e e

Guia al usuario, sobre todo para empezar reutilizando las expeJiencias. Usabilidad, ya que una pobre usabilidad puede alejar al usuario. Confol1nidad con el proceso, hacer un proceso mejorado centrado en el repositorio de expeliencias, siguiendo la estructura del proceso subyacente. Mecanismos de realimentaci6n, pOl' medio de diferentes canales (colTeo electr6nico, pizalTas electr6nicas, FAQ, contactos personales y telef6nicos, etc.). Mantenibilidad, para que las reestructuraciones sean faciles.

e

e

POl' 10 que respecta a las lecciones aprendidas, estos autores recomiendan:
e

Ser especifico, ya que si el contenido de la base de datos esta desordenado y no se guia al usuario se limita drasticamente los beneficios del repositorio. Agrupar varias expeliencias alrededor de una sola descripci6n de procesos. Intentar simplificar la estructura y el fOl1nato de pagina, mejorando la usabilidad. Facilitar la incorporaci6n de la realimentacion de los usuarios.

e e

e

3. FAMILIAS DE ESTUDIOS
Una de las fOl1nas mas imp0I1antes de obtener conocimiento relacionado con el desalTollo y mantenimiento del software es mediante la realizaci6n de familias de estudios. En este senti do. Basili et af. (2001) sefialan algunos criterios para la construccion de cuerpos de conocimiento en areas de IngenieJia del Software: I. Fijar hip6tesis de alto nivel que sean de in teres para la comunidad de IngenieIia del Software. Hipotesis detalladas escritas en un contexto que pennitan estudios empiricos bien definidos. Variables de contexto. sugelidas pOl' las hipotesis, que puedan modificarse para pel1nitir vmiaciones en el diseilo experimental. Una cantidad suficiente de infol1nacion para que el estudio pueda ser replicado. Una comunidad de investigadores que comprendan la experimentacion. la necesidad de replica y que esten dispuestos a colaborar y replicar.

2.

3.

4. 5.

Los estudios empiricos resultan necesarios para comprobar y entender las implicaciones relacionadas con la medicion de las entidades software. Esto se consigue a

332 C\UDAD DE SISTE\lAS INFOR?-.!..\TIeos

traveS de hipotesis en el mundo real, ll1l:lS alla de la pura teolia, que habra que comprobar con datos empiricos. Hay tres tipos principales de estrategias empiricas que pueden ser llevadas a cabo (Robson, 1993): experimentos, casos de estudio y encuestas. En los siguientes apartados se descliben con mayor detalle estas estrategias.

3.1. Experimentos
La ventaja de un experimento es que puede detenninar en que situaciones cielias afil111aciones son ciertas y puede proporcionar el contexto en el que cielios estandares, metodos y helTamientas son recomendables. Solo si el experimento se realiza adecuadamente, es posible obtener conclusiones acerca de las relaciones entre la causa y el efecto para la cual se fonnulan la hipotesis (Wohlin et al., 2000). Los expelimentos necesitan ser planificados cuidadosamente si se pre ten de que proporcionen resultados lltiles y significativos (Juristo y Moreno, 2001). Basili et al. (1999) comentan que la experimentacion en la ingenielia del software es necesaria. pero bastante dificil. Una razon de esta dificultad es la gra!1 cantidad de variables del contexto, 10 cual implica que para conseguir una comprension adecuada de los resultados de los experimentos, se necesita un mecanismo para explicar los estudios e incorporar los resultados.

3.1.1. DESCRIPCION DEL PROCESO EXPERIMENTAL
El proceso experimental consta de seis etapas principales (Wohlin et al .. 2000), como muestra la figura 11 .. En los siguientes apartados se resume cada una de estas etapas.

3.1.1.1. Definicion
EI proposito de la fase de definicion es definir los objetivos de un experimento. fOl11mlado a partir de un problema a resolver. Para recoger los objetivos de un expelimento se sigue la plantilla GQM de aCl~erdo con las sugerencias de Briand et al. (2002) y Lott y Rombach (1996) (ver tabla 9.2 en apartado 2.2.2 del capitulo 9).

3.1.1.2. Planificacion
Despues de la definicion del experimento tiene lugar la planificacion. La definicion detem1ina por que se va a realizar el experimento, mientras que la planiticacion establece como se llevara a cabo. Esta etapa se puede dividir en los siguientes seis pasos:

C RA-\L-\

CAPiTULO 11: GESTIO?\ DEL CO?\OCIMIENTO

333

Figura 11.5. Vision general del proceso experimental principales (WohHn et at., 2000)

1.

Seleccion del contexto. EI contexto del experill1ento queda caracterizado de acuerdo con cuatro dill1ensiones: '" '" '" '" Ojlline ,·s. On-line. Los experimentos pueden realizarse en proyectos reales (on-line) 0 bien en paralelo a los proyectos reales (off-line). EstZldiantes vs. Profesionales. Los experimentos pueden IIevarse a cabo con sujetos profesionales 0 estudiantes. Simlilacion 1"5. Problemas reales. EI experimento puede enfocarse en un problema real 0 en una simulacion. Espec(jico vs. Genera!. Los resultados del. expelill1ento pueden ser vcilidos en un contexte especifico 0 en el dominio general de la ingenieria del software.

2.

Formulacion de hipotesis. La definicion del experimento se fonnaliza por medio de hipotesis. Deben fonnularse dos hipotesis: una hipOtesis nula (Ho) y una hipotesis alternativa (HI). La comprobacion de las hipotesis entrafia diferentes tipos de liesgos: algunos tests estadisticos pueden rechazar una hipotesis verdadera ailll siendo cierta (elTores tipo I), mientras que otros tests no rechazan una hipotesis falsa ailll siendo falsa (elTores tipo II). EI tamafio de los elTores depende de diferentes factores. Un ejemplo es la capacidad del test estadistico para revelar un patron verdadero en una coleccion de datos, que se conoce como la potencia del test.

334 CAUDAD DE SISTEMAS INFOIUvLS, TICOS

©RA-MA

3.

Seleccion de variables. Antes de comenzar con el diseflo tenemos que elegir las variables dependiente e independiente que se van a considerar, junto con la fonna en que se van a medir y sus respectivas escalas de medici6n. Seleccion de sujetos. La selecci6n de sujetos 0 muestra de la poblaci6n que se utilizara en el experimento esta estrechamente relacionada con la generalizaci6n de los resultados del mismo. Para generalizar los resultados a la poblaci6n deseada, la selecci6n de sujetos debe ser representativa de esa poblacion. La muestra de la poblaci6n puede ser probabilistic a 0 no probabilistica. Ejemplos de tecnicas para obtener muestras de poblaci6n probabilisticas son el muestreo simple al azar, muestreo sistematico y muestreo estratificado al azar; y para obtener muestras no probabilisticas las tecnicas a utilizar son el muestreo por conveniencia y el muesh'eo por cuotas. EI tamaflo de la muestra tambien tiene influencia sobre la generalizaci6n de los resultados: cuanto mas grande es la muesh'a, men or sera el elTor de la generalizaci6n de los resultados. Disefio del experimento. El diseflo de un experimento describe como estan organizados los tests y c6mo se ejecutaran. Para diseflar el experimento, es necesario observar las hip6tesis y decidir que analisis estadisticos hay que ejecutar para rechazar la hip6tesis nula.

4.

5.

Cuando se disei1a un expe11mento se puede distinguir enh'e diseflos intra-sujetos (todos los sujetos realizan todos los tratamientos) y disei10s inter-sujetos (se seleccionan diferentes sujetos para cada tratamiento). Los primeros tienen la ventaja de garantizar el control de todas las variables debido a diferencias entre sujetos, 10 que podlia interferir en los resultados de la investigaci6n y, ademas, pennite reducir el esfuerzo de enconh'ar la misma infonnaci6n con un bajo nlunero de sujetos. Sin embargo, los diseflos intra-sujetos pueden presentar algunos problemas: a) Antes de realizar el experimento existen efectos que pueden comprometer la validez intema de los experimentos inh'a-sujetos como los efectos de persistencia (una [onna de controlarlos es que los sujetos realicen el experimento una sola vez, no 10 repitan), los efectos de fatiga (apreciables sobretodo en experimentos excesivamente largos), y los efectos debidos a la falta de motivaci6n. b) Durante la realizaci6n del experimento. Debemos de considerar los efectos de aprendizaje (que se evitan presentando las diferentes tareas a realizar en todos los diferentes 6rdenes posibles), los efectos de persistencia (cuando se sospecha que los efectos de un tratamiento persisten s610 se realizara una vez ese tipo de exper1mento con ese grupo de sujetos).

CAPiTULO II: GESTION DEL CONOCIMIENTO

335

6.

InstrumentaciOn. La instlUmentacion para un experimento se selecciona en la etapa de planificacion y puede ser de tres tipos: objetos particulares, instrucciones e instrumentos de medicion. Antes de la ejecucion, se desalTollan los instlUmentos especificos para el experimento. Los objetos del experimento pueden ser, pOI' ejemplo, especificacion 0 codigo de documentos. Las instlUcciones son necesm1as para organizar a los participantes durante el expe11mento, e incluyen los procesos descriptivos y las listas de comprobacion. Si se comparan diferentes metodos en el experimento, tienen que prepararse las instrucciones para cada metodo. Ademas de las instrucciones, los participantes tambien necesitan entrenamiento en los metodos que se van a usar. Las mediciones en un experimento se realizan a traves de los datos recabados.

3.1.1.3. Operacion
En la etapa operacional de un expe11mento, se aplican los tratamientos a los sujetos. Esta etapa se divide en tres partes:
A) Preparacion. Antes de que el expe11mento se 1111Cle, se debe encontrar el personal que se comprometa a pmiicipar como los sujetos delmismo. Es esencial que los sujetos que pariicipen en el experimento esten motivados y pmiicipen voluntariamente en todas las paries del expe11mento. Los siguientes aspectos deberian ser considerados respecto a los sujetos que participan en un expe11mento:
e

Obtener consentimiento. Los pmiicipantes tienen que estar de acuerdo con los objetivos de la investigacion. Resultados sensibles. Si los resultados obtenidos en el experimento son sensibles a los participantes, es importante hacer saber a los participantes que el resultado de su rendimiento personal en el expe11mento se mantendra confidencial. incentivos. Un modo de atraer a la gente a un experimento es ofrecer algtin tipo de incentivo. Frallde. El fi:aude, es decir, "engafiar" a los pmiicipantes, generalmente no favorecera al experimento. Si el fraude fuese la (mica altemativa solo deberia llevarse a cabo si concieme aspectos que sean insignificantes para los participantes y no afecten su voluntad de pmiicipar en el experimento.
Ejecucion. El experimento puede ser ejecutado de diferentes modos. Algunos experimentos se llevan a cabo de una vez juntando a todos los pmiicipantes, por ejemplo, en una sesion. La ventaja de este metodo es que el resultado de la obtencion de datos se puede obtener directamente en la sesion y no es necesario contactar posteriomlente con cada uno de los participantes para reque11rle los resultados. Otra ventaja es que el experimentador esta presente durante la

e

e

e

B)

336 CAUDAD DE SISTE\!AS INFOR\!.'\TICOS

realizacion y si surge alguna dud a se puede resolver directamente. Sin embargo, otros experimentos se llevan a cabo durante un intervalo de tiempo mucho mayor, y no es posible que el experimentador participe en cada detalle del experimento y en la recogida de datos. Los datos se pueden recoger tanto de fonna manual por los participantes que rellenan fonnulaIios como automaticamente a traves de helTamientas.
C)

Ejecucion. El expeIimento puede ser ejecutado de diferentes modos. Algunos experimentos se llevan a cabo de una vez juntando a todos los participantes, por ejemplo, en una sesion. La ventaja de este metodo es que el resultado de la toma de datos se puede obtener directamente en la sesion y no es necesario contactar posteIionnente con cada uno de los participantes para requeIirle los resultados. Otra ventaja es que el experimentador esta presente durante la realizaci6n y si surge alguna duda se puede resolver directamente. Sin embargo, otros experimentos se llevan a cabo durante un intervalo de tiempo mucho mayor, y no es posible que el experimentador participe en cada detalle del expeIimento y en la recopilacion de datos. Los datos se pueden obtener tanto de fonna manual por los participantes que rellenan fonnularios como automaticamente a traves de helTamientas. Validacion de los datos. Una vez que los datos han sido recopilados, el experimentador debe comprobar si los datos son razonables y se han obtenido COlTectamente. Para ella es necesario verificar que los participantes han comprendido bien los fOl111Ularios y que, por 10 tanto, los han rellenado corTectamente. Tambien es importante revisar que los expeIimentos se han desarTollado tal y como se habia previsto.

D)

3.1.1.4. Amilisis e Interpretacion
Una vez recabados los datos empiricos, deben ser analizados adecuadamente. Hay tres elementos principales a considerar cuando elegimos las tecnicas de analisis: la naturaleza de los datos que se han obtenido, por que se ejecuta el experimento, y el tipo de disefio experimental. Dependiendo del. prop6sito del experimento, se pueden utilizar diferentes tecnicas para probar las hip6tesis.

3.1.1.5. Evaluacion de la validez
Una cuesti6n fundamental relacionada con los resultados del experimento es la validez de esos resultados, ya que el grado de credibilidad de un experimento depende de la validez de las conclusiones que se obtengan. Se pueden distinguir cuatro tipos de cIiterios de evaluacion de los experimentos (Campbell y Stanley, 1963; Cook y Campbell, 1979):
e

Validez de constructo. Define el grado en el que las variables dependiente e independiente miden fielmente los constructos te6ricos establecidos en las

CAPiTULO II: GESTIO)\; DEL CO)\;OCIMIE)\;TO

337

hip6tesis. La amenaza a la validez de constmcto es la falta de evidencia teorica sobre si las metricas para las valiables dependiente e independiente miden realmente los conceptos que se pretende medir.
fa

Validez interna. La validez intema es el grado de confianza en la relaci6n causa-efecto entre los factores de interes y los resultados observados, es decir, el grado en el que se pueden obtener conclusiones sobre el efecto causal que la variable independiente tiene sobre la variable dependiente. Los factores que tienen repercusi6n en la validez intema son la seleccion y division de los sujetos en diferentes grupos, las diferencias entre sujetos y el balanceo de los mismos durante el experimento, el material utilizado en el experimento, etc. Validez de la conclusion. Trata sobre la validez estadistica de las conclusiones obtenidas en el estudio empirico. Validez externa. La validez extema es el grado en el que los resultados de la investigaci6n pueden ser generalizados a la poblaci6n estudiada y a otros entomos. Cuanto mayor es la validez extema, en mayor medida pueden generalizarse los resultados de un estudio empirico como una pnictica real de ingenieria del software. La validez extema no s610 se ve afectada por el disei'io del expelimento sino tambien por los objetos del expelimento y los sujetos que 10 realizan. Existen principalmente tres liesgos: no tener los sujetos adecuados para el experimento, realizar el experimento en un entorno erroneo y ejecutarlo en unas circunstancias que condicionen los resultados.

e

e

En la tabla 11.3 se muestra una lista de las diferentes amenazas a la validez de los expelimentos, que deberian ser controladas para obtener resultados vitlidos en cualquier estudio empirico.
MIENi\Zi\S AU.: Vi\LIDEZ ... D.ESCRlPCION
..

Validez de la conclusion,

I

Validez de constructo,

Validez intema.

Validez externa.

Baja potencia estadistica. \'iolar las suposiciones de los tests estadisticos. finalizacion y ratio de error, fiabilidad de las metricas, fiabilidad 0 tratamiento de implementacion. irrele\'ancias aleatorias en eLambiente experimental. Interpretacion pre-operacional inadecuada de los constructores. sesgo por monooperacion. sesgo por mono-metodo, confusion entre constructores y niveles de constructores. interaccion de diferentes tratamientos. interaccion de experimentacion y tratamientos, generalizacion restringida a traves de constructores, conjeturar hipotesis. aprension en la evaluacion, expcctativas del experimentador. Historia. madurez. experimentacion. instrumentacion. rcgresion estadistica. seleccion. mortalidad. ambigiiedad sobre el senti do de la influencia causal, interaccion con la selecci6n, difusi6n de duplicados del tratamiento, igualaci6n compensatoria de los tratamientos, rivalidad compensatoria. desmoralizaci6n resentida. Interacci6n de la selecci6n y el tratamiento, interaccion del ambiente y el tratamiento. interacci6n de la historia y el tratamiento.

Tabla 11.3. Amenazas a la validez de los experimentos

Existen diferentes tipos de replicas (Basili et al. Presentacion y Empaquetamiento Es esencial no olvidar. Estos estudios identifican potencialmente los aspectos e e . el contexto en el cual se llevo a cabo el experimento. y los metodos utilizados durante el amilisis de los datos empilicos. Las replicas de este tipo no varian ni las variables dependientes ni las independientes del experimento Oliginal. etc. el disefio experimental.-?\lA 3. 2003. la motivacion a la hora de realizar las decisiones clave del disefio.338 CAUDAD DE SISTEMAS INFOIUvlA TICOS 9 RA. Replicas que no varian las hipotesis.1. Replicas que varian las hipotesis. Estas replicas investigan que aspectos del proceso son impOltantes variando sistematicamente alguna variable independiente y examinando los resultados. Replicas que varian las variables de contexto en el entomo en el que la solucion es evaluada..1. Estas replicas cambian la fonna en que se mide la efectividad para intentar entender que dimensiones de que tareas son mas importantes.. que intentan incrementar nuestra confianza en los resultados expelimentales estudiando las mismas hipotesis pero altemando algunos detalles del experimento_ e 2. 2002) que faciliten la replicacion de los experimentos. Se puede distinguir entre: e Replicas que varian las variables independientes. Replicas que modifican la fonna en que el experimento se realiza. Aunque varian algunas variables pemmnecen en el mismo nivel de especificidad que el experimento original. para la presentacion y difusion de un experimento. Replicas que varian variables inuinsecas al objeto de estudio. Shull et al. REPLICACION DE LOS EXPERIMENTOS Es importante ademas realizar replicas de los experimentos. los aspectos impoltantes y la infonnacion necesaria que necesitamos para llevar a cabo las replicas y obtener beneficios del experimento y del conocimiento obtenido a u-aves de el.1. 1999): 1. incluyendo las amenazas a la validez y los puntos fueltes del experimento. es impOltante elaborar "paquetes de lab oratorio" (laboratory packages) (Basili et al. Denu-o de este tipo de replicas se puede distinguir enu-e: e Estlictas.6.. que duplican el expelimento Oliginal y son necesarias para incrementar la fiabilidad en la conclusion sobre la validez del experimento.. Para ello.. 3. Demuestran que los resultados del experimento Oliginal son repetibles. 1999. que incluyan: el amilisis y objetivos del experimento. Ciolkowski et al.2. porque con los resultados de un unico experimento es dificil apreciar si los resultados son generalizables y poder asi concluir que sus resultados son validos. el proceso para ejecutar el experimento.

Definici6n del Contexto Preparaci6n Experimentos Conducci6n Am31isis de la Experimentos f---I!>/ Familia de Individuales Datos Material Figura 11.1. y finalmente se analizan los resultados de los experimentos de fonna global. Estas replicas deberian encuadrarse dentro de la planificaci6n de una familia de expel1mentos como el que se muestra en la figura 11. para posterionnente !levar a cabo cada experimento de fonna individual teniendo en cuenta el contexto general establecido y elmatel1al necesar10. la planificaci6n de una familia de expel1mentos se inicia con una fase de preparaci6n en la que se definen los objetivos generales de la familia de experimentos y se planifica c6mo se van a analizar los resultados. 3..3. Ayudan a detem1inar los limites de la efectividad de un proceso.5.3. los productos y/o los modelos del contexto para vel' si los principios basicos siguen dandose. Replicas que extienden la teoria.1.6. Fases para el desarrollo de una Familia de Experimentos (Ciolkowski et al.6 (Ciolkowski et aI. haciendo gr'andes cambios en los procesos. 2002) Como se puede observar en la figura 11.1. La importancia de Pair designing para la gestion de conocimiento Uno de los aspectos relevantes a estudio en el ambito de la Ingenieria del software es la transferencia de conocimiento cuando se trabaja en pares. Dentro de las tecnicas que .CAPiTULO II: GESTION DEL CONOCIMIENTO 339 del entomo que son impOltantes ya que afectan a los resultados del proceso en investigaci6n y por tanto nos ayudan a entender la validez extema. EJEMPLO: DETERMINACION DE LA EFICACIA DEL PAIR DESIGNING PARA LA COMPARTICION Y DIFUSION DE CONOCIMIENTO 3.. 2002). 3.

S INFOR. En este caso la practica se ha denominado Pair designing. y en concreto el conocimiento tacito (F oresythe et or 1998: Williams y Kessler.er) identificando defectos y aspectos tacticos y estrategicos_ Los roles se intercambian peri6dicamente_ Un beneficio de esta practica es que se refuerza el incremento de conocimiento de los participantes. Con todo ella se planific6 una familia de experimentos cuyo objetivo fue demostrar la relaci6n existente entre la aplicaci6n de la practica Pair designing y la construcci6n y difusi6n de conocimiento. que es una pnictica utilizada en metodologias agiles consistente en que dos programadores trabajan "hombro con hombro" (side by side) en el desan-ollo de una misma pieza de c6digo_ Un programador. y en concreto de mucha experiencia. excepto mediante la comunicaci6n y el dialogo_ El disefio de software requiere de conocimiento tacito.-\lA favorecen esta transferencia de conocimiento se encuentra la denominada Pair designing. mientras que el refuerzo del conocimiento se refiere al incremento del conocimiento global de los miembros del equipo mediante la combinaci6n del conocimiento individual de sus miembros. un programador de sofuvare se convierte en disenador de sofuvare s610 despues de algunos ai'ios de experiencia. Preparaci6n de Experimentos.1. ."l. Como resultado del analisis anterior se podria pensar que la practica de pair programming podria ser aplicada al disei'io con los mismos beneficios. El objetivo general de los experimentos es el de demostrar la utilidad de la practica pair designing en relaci6n a la difusi6n y transferencia de conocimiento. De hecho. consistente en el que el dri"\'er edita activamente el documento de diseno mientras que el observer realiza una revisi6n continua. que asume el rol de conductor (driver) escribe activamente el c6digo mientras que el otro que asume un rol de meramente observador (obserl.2.-\ TICOS 1':: RA. Una familia de experimentos para evaluar la difusi6n y refuerzo del conocimiento de la tecnica Pair Designing De acuerdo al metodo de Ciolkowski et· or (2002) se slgmeron las siguientes etapas para la realizaci6n de la familia de experimentos: 1. 3. 2000)_ Este tipo de conocimiento no se puede f011nalizar y transferir facilmente. Usando la plantilla GQM este objetivo se puede definir de la siguiente f011na: e e Analizar la tecnica de Pair Designing.3-+0 CAUDAD DE SISTE\L".3. Con el proposito de evaluarlas en relaci6n a su capacidad de ser usadas como tecnica para mejorar la difusi6n y refuerzo del conocimiento. Por difusi6n del conocimiento se entiende la transferencia de conocimiento entre los miembros del equipo.

3.. 10 cual no siempre es posible (gasto significativo de tiempo. 1999). @ . a la hora de planificar el contexto de los experimentos individuales se debe tener en cuenta la utilizacion de estos grupos de sujetos. Definicion del Contexto. en muchas ocasiones los investigadores llevan a cabo estudios piloto con alumnos en entomos academicos (Carver et al. De hecho. por 10 siempre que sea posible se deben seleccionar este tipo de sujetos. El material experimental debe ser el mas adecuado para satisfacer los objetivos planteados. G A paItir de este objetivo se plantearon las hipotesis generales de la investigacion. Material. esfuerzo y recursos). G Profesionales. 2003). A la hora de llevar a cabo experimentos.OCIMIE]\. Alumnos. Dos diagramas de casos de uso junto con descripciones textuales de los m1smos. hay que considerar que los alumnos constituyen la proxima generacion de profesionales (Kitchenham et al. 2. De acuerdo al objetivo -de la investigacion y a las tare as planificadas en el experimento se preparo la documentacion de un sistema para la venta de libros de segunda mano a traves de Intemet. 2000: Basili et al. ya que antes de realizar estos estudios en entomos industriales. DEL CO. Son los sujetos ideales a la hora de poder generalizar los resultados..-YIA CAPiTULO 11: GESTIO]\.-'. En el contexto de alumnos de ingenieria del software y profesionales de los sistemas de infol111acion. Dependiendo de las tareas requeridas en cada experimento individual el material estaba compuesto por: G Una especificacion textual y una lista de requisitos candidatos sobre el sistema de venta de libros Book m'er the globe. las diferencias entre los alumnos y los profesionales son pequer1as y las tare as requeridas en cieltos experimentos no requieren experiencia industrial. los alunmos juegan un papel l11uy impoltante.. por ello se puede considerar la experimentacion con alurID10s como viable (Host et aI. 2002)..TO 341 G Desde el punta de l'ista de los investigadores. Con el fin de poder generalizar los resultados se identificaron dos grandes grupos de SlUetos experimentales a la hora de establecer el contexto de cada experimento individual.\: RA. Bajo cieltas circunstancias. @ Por 10 tanto.

En la figura 11. Vision general de la familia de experimentos lIeyada a cabo Como se puede observar en la figura 11. los experimentos quedaron divididos en dos grandes grupos en funcion de las tare as a realizar en cada uno: Desarrollo. junto con el marco general establecido en la familia de experimentos se debe tener en cuenta la realimentacion obtenida como resultado de lievar a cabo los experimentos previos. (2000). Italia) :vlantenimiento 2° Experimento 3° Experimento 42 Estudiantes 3' ITIG 39 Estudiantes 3' ITIS 12 Estudiantes 5' Ingenieria Informatica Escuela Superior de Informatica (Ciudad Real.7. Conducci6n de Experimentos Individuales. y MUTEGS Universidad del Sannio (Benevento. Cuestionarios de Evaluacion de Conocimiento."L~ e Dos gramas de clases en tres capas (presentacion. dominio y persistencia) con el disei'io del sistema. Teniendo en cuenta la planificacion general se planificaron y realizaron tres experimentos individuales con el objetivo de satisfacer los objetivos generales. Cada cuestionario incluia un conjunto de preguntas de respuesta (SiINo) para evaluar el conocimiento de los sujetos sobre el sistema software a desalTollar 0 mantener. Es importante destacar que a la hora de llevar a cabo cada experimento individual.342 CAUDAD DE SISTEMAS INTOIUvL~ TICOS :0 RA-.. se muestra una vision general de los experimentos llevados a cabo: Tarea Experimental 1° Experimento Desarrollo -r- 1 I 45 Estudiantes de 3' curso de Ingenieria en Informatica Universidad del Sannia (Benevento. Espana) t €I 36 Estudiantes del Master MUTS. En el primer experimento la tare a experimental que los sujetos debieron realizar fue el desanollo del sistema Book m'e!' the globe para 10 cual se . EI 4. Italia) I" Experimento I 2° Experimento I I 3" Experimento (replica 2") v Figura 11. Para la realizacion de cada experimento individual se siguio el proceso establecido pOI' Wholin et al.

Cada sujeto respondio el cuestionario de salida individualmente. Para ello ademas de la especificacion de requisitos y de los cuestionarios a los sujetos se les proporcionaron los diagramas de casos de uso y de clases del sistema. actores. Al final de cada ronda los sujetos producian los diagramas cOlTespondientes que respectivamente fueron: diagramas de casos de uso. metodos. realizando modificaciones sobre las entidades existentes o ailadiendo nuevas. El proceso expel1mental que siguieron los sujetos en el primer experimento fue dividido en tres sesiones 0 rondas. los sujetos que partlClparon en los experimentos fueron estudiantes de distintas universidades en Italia y Espana.) 0 relaciones entre entidades que no fueran fundamentales para el funcionamiento y la comprension del sistema.. e e . Sus tareas de mantenimiento consistian en: reducir la complejidad del diseno. atributos. El objetivo de este expelimento se centro en los aspectos de construccion de conocimiento. de forma individual durante 15 minutos. Para la realizacion del segundo experimento y de su replica (30 expel1mento) se pidio a los sujetos que realizaran tareas de mantenimiento del sistema. etc. diagramas de clases y diagramas de interaccion. casos de uso. Por su pmte el proceso seguido en el segundo y tercer experimento nle: e e Cada sujeto estudiaba la documentacion ind'i\"idualmente durante 30 minutos. mediante la eliminacion de entidades (clases. Como se puede verse en la figura 11. Los sujetos trabajando sobre el diseilo del sistema en pares 0 de forma individual realizaron las tare as de mantenimiento durante dos horas. mejora de la legibilidad del diseno. La mitad de los sujetos trabajaron en cada ronda aplicando la fonna tradicional de disefio (que denominaremos solo designing) mientras que la otra mitad fueron distribuidos en parejas y aplicaron pair designing. Cada sujeto respondia al cuestionario de entrada. Todos los sujetos antes de proceder con el experimento recibieron una sesion de entrenamiento y se familiarizaron con la tecnica de pair designing y con el tipo de tare as a realizar en el experimento. Al principio y final de cada ronda ten ian que contestar un cuestionario de fonna individual para evaluar sus conocimientos del sistema. El cuestionario inicial tenia como fin establecer el punto de pmtida: por ejemplo: ni\"el de conocimiento del sistema antes de trabajar con el y que habia sido construido lmicamente a partir de la lechlra de la documentacion.~ RA-illA C\PiTLiLO 11: GESTION DEL CONOCIMIENTO 343 les proporciono la lista textual de requisitos y cinco cuestionarios para evaluar su conocimiento del sistema. e Mantenimiento.

Las variables dependientes nleron medidas de la siguiente fOlma: e e Dinlsion del Conocimiento. 5 MUTEGS.IKFOR:VIATIeos La distribucion de los sujetos en sus modalidades de trabajo fueron las siguientes: e En el segundo experimento los estudiantes fueron organizados en nmcion del tipo de Master que estaban estudiando: MUTS (Master en Tecnologias Software). Renlerzo del conocimiento. para estudiantes de titulaciones tecnicas y MUTEGS (Master de Gestion y Tecnologias Software) para estudiantes de tihllaciones de humanidades y ciencias sociales. e 5. 8 eshldiantes MUTS en modo solo y 8 eshldiantes MUTEGS en modo solo. los resultados de las otras dos rondas no n:eron estadisticamente significativos. Los resultados individuales de cada experimento se resumen en la tabla 11. Sin embargo. en concreto el test de Mann Whitney. 10 que pudo ser debido principalmente a una amenaza de la validez experimental deb ida a que los sujetos no hlvieron un nlerte compromiso con el proceso del experimento. Para analizar los resultados individuales de cada experimento se aplicaron analisis estadisticos. En el tercer experimento los sujetos se dividieron en tres gmpos: alutlll10s con tihllacion de ingenieria tecnica en infonmitica de gestion (ITIG). sino extraer unas conclusiones globales. Ingenieria Tecnica en Infonmitica de Sistemas (ITIS) e Ingenieria en Infonmitica (II). ca1culado como la diferencia de puntuacion entre el cuestionario de salida y el cuestionario de entrada.4 (los del experimento 1) Y en la tabla 11. Una vez considerada la tihIlacion de los miembros de la pareja la seleccion de cada sujeto para cada pareja nle totalmente aleatoria.que los datos obtenidos no seguian la distribucion estadistica nonnai. se puede que el nivel de reforzamiento de conocimiento de los sujetos que aplicaron pail' designing nle mayor que el valor promedio de los que no aplicaron solo designing siendo ademas los resultados de la primera ronda estadisticamente significativos (nivel de significacion a <0. a partir de las punhlaciones de los cuestionarios de salida (rellenados una vez habian finalizado las rondas de trabajo). En Visaggio CW05) y Bellini et al. La . 10 parejas mixtas MUTS-MUTEGS. De acuerdo al nlllnero de sujetos y a la tihllacion se f0!111aron 32 pares y 32 sujetos trabajaron en modo solo designing. Una vez obtenidos los resultados de cada experimento individual. Analisis de la Familia de Datos. De ese modo se fonnaron 5 parejas MUTS. es impOltante no solo obtener conclusiones locales de cada experimento.05).5 (los de los experimentos :2 y 3): A partir de los resultados de la tabla. (2005) se puede consultar infonnacion mas de tall ada acerca de la realizacion de los tres experimentos de la familia. dado.

270 0.05) en la construccion y difusion de conocimiento de los pares respecto a los solos para los grupos MUTS.26 - I Tabla 11.00000 0.0009 0.'" .086 0.5: TESTS ESTAD1S"rlCOS ! I ".75 -0.049 0.36 -0.0309J. Espana Pares 3°Gestion(a) Solos 3°Sistemas(~) Pares 3°Gestion( a) Solos 3°Gestion(~) 0. ROl'\DA PROMEDlO DE LA REH1ERZODE COl'\OCEvllENTO DE LOS PARES PRO:VlEDlO DE LA REFUERZO DEL CONOC!:VI1ENTO DE LOS SOLOS SIG~lFICACION E:STADisnCA (.5. Esto puede ser debido al hecho de que habia alumnos con habilidades muy distintas. Un cierto nlllnero de sujetos abandonaron en la ronda 2 y en la ronda 3 porque 10 consideraron como una actividad de fOnllacion innecesaria para el curso que estaban siguiendo. mientras que en las ott'as dos rondas el nlllnero de sujeto disminuyo.5 ! 0.rlf.023 0.0102 0.27 1..CAPiTULO 11: GESTION DEL CONOCIMIENTO 345 primera ronda conto con todos los sujetos.53 0.00017 I I 0.86 I 1.05) I: Caso de Uso II: Diagrama de Clases III: Diagrama de " ImeraCClOn I 1. . Los .019 I 2.25 0. Resultados Estadisticos del Experimento 1 Los datos estadisticos obtenidos a par1ir de los datos del segundo y tercer expelimento se muestran en la tabla 11.- . Este fue un importante aspecto de reflexion que se tllVO en cuenta en los siguientes expelimentos inc1uyendo mecanismos para la motivacion de los ~~.042 Tabla 11.4 < 0.0428 0. Italia Pares lvfUTEGS (al Solo lvIUTEGS (~) Pares ivIUTS (a) Pares MUTEGS (~l Pares 5°II( a) Solos 5°II(~) 3°. Resultados Estadisticos de los Experimentos 2 y 3 Los resultados de la tabla indican para el segundo expelimento que se obwvieron diferencias significativas (a<O.2[6 0. L"tUI:' II I ! I "'USiO~ CONOCnIIE~TO I I SrGKIFIC-\CION ESTADisTICA REFORZA:VU£"iTO DE CO.4. pero no fue asi para los MUTEGS.2 0."iiOCrynENTO Pares MUTS (a) Solos MUTS (~) 2°.

346 CAUDAD DE SISTEMAS INFORMA TICOS © RA-ivlA almllllos de MUTS provenian de estudios de ciencias mientras que los MUTEGS provenian de otro tipo de estudios.1.2. ya que se demostr6 que los pares obtuvieron mejores resultados en construcci6n y difusi6n de conocimiento que los que trabajaron aplicando solo designing. Asi. 3. ya que un caso de estudio requiere los mismos pasos que los experimentos. Casos de estudio Los casos de estudio se utilizan para monitorizar proyectos. Hay que destacar que la mayoria de los aspectos considerados a la hora de realizar un experimento se tienen en cuenta a la hora de realizar un caso de estudio. 3. actividades 0 asignaciones y estan orientados normalmente a analizar un determinado atributo 0 establecer relaciones entre diferentes atributos. Este hecho fue confinnado en el tercer experimento para las parejas en las que uno de los miembros tenia una titulaci6n cientifica 0 tecnica y el otro no. Estos resultados fueron en general significativos para los tres grupos de titulaciones. 1998). Los alurnnos del curso MUTS se supone que estaban mas familiarizados con los algoritmos y con el razonamiento deductivo que los alurnnos MUTEGS. Los resultados del analisis estadistico en el tercer experimento fueron tambien significativos. Conclusiones A partir de los resultados anteriores se puede llegar a las siguientes conclusiones: • Pair designing pennite reforzar y difundir mejor el conocimiento que solo designing. Son estudios observacionales (es decir. tal y como se muestra en la tercera fila de la tabla. A partir de estas observaciones se puede plantear la hip6tesis de que la eficacia en la aplicaci6n de pair designing podria verse afectada por la habilidad de los sujetos a la hora de aplicarlo. En el caso particular de esta familia de experimentos la realimentaci6n obtenida con el primer experimento de la familia permiti6 refinar y enfocar la investigaci6n de los otros dos experimentos. y en concreto por su formaci6n academica.3. S610 en el caso del reforzamiento de conocimiento de los ingenieros superiores no se pudieron confirmar las diferencias entre solos y pares. se llevan a cabo mediante la observaci6n de un proyecto 0 actividad que esta en marcha) mientras que los experimentos son estudios controlados (Zelkowitz y Wallace. • La eficacia de pair designing a la hora de difundir y reforzar el conocimiento sobre el disefio podria verse afectada por el tipo de poblaci6n. De hecho se obtuvo evidencia estadistica de que el rendimiento de las dos muestras en terminos de conocimiento fue diferente. tambien en un caso de estudio es necesario minimizar los efectos de los factores .3. por ejemplo.

con datos necesarios para converger de una manera triangular. Trata con situaciones distintivas tecnicamente en las cuales habra muchas mas variables de interes que datos. 3. es que intentan aclarar una decisi6n 0 conjunto de decisiones: por que se tomaron. y con que resultado (Schramm. c6mo se implementaron.~ RA-MA CAPiTULO 11: GESTION DEL CONOCIMIENTO 347 confusos. . Explorar las situaciones en las que la intervenci6n que esta siendo evaluada no tiene un conjunto claro de resultados unicos.2. DEFINICION Y APLICACIONES Se puede definir "caso de estudio" como una investigaci6n empirica que aborda un fen6meno contemponineo dentro de su contexto real. la tendencia general de todos los tipos de caso de esmdio. iii iii iii iii Aunque. especialmente cuando: iii Las fronteras entre el fen6meno y el contexto no son claramente evidentes. DISENO DE CASOS DE ESTUDIO Se puede distinguir cuatro tipos de diseiio de casos de estudio segUn sea de caso unico 0 multiples casos y embebido u holistico. Se basa en mUltiples fuentes de evidencia.1. sin embargo. Se beneficia del desanollo prevlO de proposiciones te6ricas para guiar la obtenci6n y anaIisis de datos. 1971). en modo descriptivo. Estudiar un estudio de evaluaci6n (metaevaiuaci6n). no se tiene el mismo control en un caso de estudio que el que se tiene en un experimento.2. Los casos de estudio son valiosos porque incorporan cualidades que un experimento no puede visualizar. Ilustrar ciertos t6picos en una evaluaci6n. iii iii iii Se pueden distinguir varias aplicaciones de los casos de estudio: iii Explicar los supuestos enlaces causales en intervenciones reales que son muy complejos para las estrategias de encuesta 0 experimento. A continuaci6n se resumen los principales aspectos de los casos de eshldio siguiendo a Yin (2003). la complejidad. la falta de predictibilidad y el dinamismo. la escala.2. Describir una intervenci6n y el contexto real en la que ha ocurrido. 3. por ejemplo.

ya que el mismo caso de estudio puede involucrar a mas de una unidad de analisis (vease figura 1l. subdivididos en holisticos 0 embebidos. Es un caso longitudinal. Representa un caso extrema 0 ll11ico. A la hora de elegir entre los diferentes tipos de diseiio. hay que tener en cuenta que cada caso debe ser seleccionado con cui dado de manera que: .5.3-18 CAUDAD DE SISTE:VIAS fNFORM. e Caso simple Caso multiple Holistico caso Embebido Unidad de anal isis 1 Unidad de anal isis 2 Figura 11. La 16gica de replicaci6n es anaJoga a la utilizada en mUltiples experimentos. Pueden ser a su vez.5). Es un caso revelador (una oportunidad de observar y analizar un fen6meno previamente inaccesible).ATICOS '£iR:\-MA A) Diseiio de caso unico: es amilogo a un experimento unico y se justifica cuando: e III Representa un caso critico para probar una teoria. Tipos de disefio de casos de estudio B) Multiples casos de estudio: se considera la evidencia mas s6lida y el estudio mas robusto. 0 e e Representa un caso representativo tipico.

@ Una guia para el infol111e del caso de estudio (contenidos.3. cuestiones.1. Nivel 3. Nivel 5. Procedimientos de campo (presentacion de credenciales. 2. etc.CAPiTULO II: GESTlON DEL CONOCIMIENTO 3-+9 1.2. se muestran en la figura 11.2. 3. 3. Cuestiones preguntadas sobre el patron de hallazgos a 10 largo de varios casos. Cuestiones sobre el estudio completo.). Nivel 2. Pueden plantearse a diferentes niveles: I. @ @ 4. Preparacion en la obtencion de datos La primera fase de preparacion consta de diferentes tareas: A) FOl1nacion y preparacion para un caso de estudio especifico. 2. Para mejorar la fiabilidad del caso de estudio debe establecerse un protocolo. F ASES DE UN CASO DE ESTUDIO Las principales fases de una investigacion basada en casos de estudio. Cuestiones preguntadas sobre el caso individual.3. Prediga resultados contrarios pero por razones predecibles (replicacion teorica). B) Protocolo del caso de estudio. utilizacion y presentacion de otra documentacion. acceso a los sitios. lecturas relevantes acerca del tema investigado). . Nivel 4. infol111acion bibliognifica). con las siguientes secciones: @ Una vision general del proyecto de caso de estudio (objetivos y patrocinios. fuentes de infol1nacion.6. formato de los datos. Nivel I . Prediga resultados similares (replicacion literal). Cuestiones nOl1nativas sobre recomendaciones de politica y conclusiones. Cuestiones de caso de estudio (puestas al investigador). Las principales fases de un caso de estudio se resumen a continuacion. Cuestiones preguntadas a entrevistadores concretos. 3. 5.

.0 '" .I --:- Fu'El\"fE DERECOGlDA DE DATOS " ". .-. I I I 1 desarrollar implicaciones politicas i I I I I I I escribir conclusiones intercasos realizar I._.ldes individl._. C) Llevar a cabo un caso de estudio pilato. actitudes y percepciones reportadas Politic as de personal Productos de la organizacion Si el caso de estudio es un individuo Si el caso de estudio es una organizacion I Tabla 11. que no deben ser confundidas. I I I I I I .-. Unidad de anaIisis .Registros de archivo. I I . Investigaci6n basada en casos de estudio (Yin. Otros comportamientos.lales Percepciones individuales I Como trabaja la organizacion Por que trabaja la organizacion . I .6.i escribir :.' 1 I I I ...350 CAUDAD DE SISTEMAS INFORMATICOS © RA-tvL~ Ademas hay que elegir la unidad de toma de datos y la unidad de analisis.-. -> realizar 2° caso de estudio I I-!---.. 2003) D I S E I I . ' DE Ul'< L..\!)!VIDUO " I DEu'NA ORGANIZAOQN CONCLUSIONES DEL ESTUDIO N0 I ACERCADEUl'< Il\!)[V1DUO o' ACERCADE UNA ORGAi'\lZAC!ON Comportamiento indhoidual Actitl.. ' . vease tabla 11._-_.6.-.-.--t t r> I escribir realizar 1° I obtener Informe de f-o'------' caso de ~ conclusiones I caso estudio intercasos individual ! I I I seleccionar casos 1 escribir Informe de caso individual modificar teorfa -> ! desarrollar teorfa disefiar protocolo L...6.-. restantes I-----> Informe de f-o caso de caso estudio individual Figura 11... de recogida de datos .-. Unidad de recogida de datos Ys.

artefactos fisicos. etc. €I €I 3. entre diferentes evaluadores.3.2. Amilisis de series temporales. Analizar la evidencia del caso de estudio A la hora de analizar la evidencia del caso de estudio se pueden distinguir tres tipos de estrategias generales: €I Basarse en proposiciones te6ricas.2. observaci6n directa. etc. Hay varios tipos de triangulaci6n: de fuentes de datos. la triangulaci6n es el motivo para usar diferentes fuentes de evidencia. Sintesis de casos cmzados. €I €I €I €I . DesarTollar una descripci6n del caso. €I €I Tambien se pueden utlizar varias tecnicas analiticas especificas: €I Descubrimiento de patrones (pattern matching). Una cadena de evidencias. de metodos. Constmcci6n de explicaciones. por ejemplo. aumenta la fiabilidad. Modelos 16gicos. de perspectivas del misl110 conjunto de datos. que ayuda a l11ejorar la validez intema. Recopilacion de evidencias La evidencia en los casos de estudio proviene de varias fuentes: documentos. Pensar acerca de explicaciones rivales.3. Se deb en seguir tres principios fundal11entales a la hora de reunir datos: €I Varias fuentes de evidencias. entrevistas. el caso de estudio consta de dos colecciones separadas: datos de la base de evidencia y el infonne del investigador (articulo 0 infonne).3.2. Asi. observaci6n participante. registros de archivos.~ RA-MA CAPiTULO ll: GESTlON DEL CONOCIMIENTO 35l 3. Una base de datos del caso de estudio. podel11os establecer la siguiente cadena: cuestiones de caso de estudio -7 protocolo de caso de estudio (enlaza cuestiones con temas del protocolo) -7 citaciones a fuentes de evidencia especificas -7 base de datos del caso de estudio -7 infonne del caso de estudio.

Si se trata del infonne de un caso de eshldio que fonna parte de un eshldio mcis amplio multimetodo. patrocinadores de subvenciones. hay que tener en cuenta: e Audiencia: academicos.4. e e e e e . CONTRUCCION DE . . Estructura comparativa: repite el mismo caso de eshldio dos 0 mas veces..352 CAUDAD DE SISTEMAS INFOIUvlA TICOS ©RA..:.2. comparando descripciones 0 explicaciones altemativas delmisl110 caso. Estructura de suspenso: invierte la estruchlra lineal-analitica y la "respuesta'· directa 0 producto del caso de eshldio se presenta al principio..-MA 3.LI~EAL J I I PROPOSITO DEL CASO DE ESTUDIO EXPLORATORIO EXPLICATIVO I DESCRIPTNO X X X X COMPAR. Estructuras para la composicion de informes sobre casos de estudio Las principales caracteristicas de estas estmchlras son: e Estructura analitico-lineaI: es la forma estandar de componer infol111eS de investigacion.. e e TIPOnE ESTRUCTIJRA Al~ALiT1CA. TEORlA "SUSPENSO" NO SECUENCIAL I J I I x X X I I X X X X I X I I I X Tabla 11.3.7). gmpos especiales (tribunales de tesis).. La secuencia de sUbtopicos empieza con la cuestion 0 problema que esta siendo eShldiado y una revision de la literatura relevante existente.\TIVA CRONOLOGICA . Estructura de construccion de teo ria: la secuenCIa de los capihllos sigue alguna logica de construccion de teoria. Elaboraci6n del informe del caso de estudio A la hora de elaborar el caso de eShldio. Estructura sin secuencia: la secuencia de los capihllos no tiene ninguna importancia. La estruchlras elegida para el caso de estudio (tabla 11. profesionales.7. Estructura cronologica: presenta la evidencia del caso de estudio en orden cronologico.

ploleden repetirse con los mismos resultados II II II En la tabla 11. 3.5.-ivlA C\PiTULO II: GESTION DEL CONOClivlIENTO 353 3. como sei'ialan Pfleeger y Kitchenham (2001-2003).8 se presentan algunas tacticas para conseguir estos tipos de validez. Fiabilidad: demostrar que las operaciones de un estudio -tales como los procedimientos de obtenci6n de datos. debe poseer ciertas caracteristicas como: II Ser significativo. Encuestas Una encuesta. Habra que tener en cuenta adem as los diferentes tipos de validez: II II II II II Validez de constructo: establecer las medidas operacionales COlTectas para los conceptos que estan siendo estudiados.~ RA. comparar 0 explicar conocimientos.3. Mostrar suficiente evidencia. Ser completo. Validez externa: establecer el dominio en el que los resultados de un estudio pueden ser generalizados. Considerar perspectivas altemativas.3. Se obtiene mediante replicaci6n. mientras que los casos de estudio (y los experimentos) se basan en la generalizaci6n analitica (en la que el investigador intenta generalizar un conjunto de resultados particulares a una teoria mas amplia). distinguiendolas de las relaciones espmias. Validez interna: (s610 para estudios explicativos 0 causales. Hay que tener en cuenta que las encuestas se basan en la generalizaci6n estadistica. no exploratorios 0 descriptivos) establecer la relaci6n causal en las que ciertas condiciones se muestra que conducen a otras condiciones. no s610 es el instrumento (cuestionario 0 lista de control) utilizado para obtener infol111aci6n. . Debe componerse en una manera atractiva. Validacion del caso de estudio Para que un caso de estudio sea ejemplar. sino que es un sistema mas amplio que sirve para desclibir.2.

Administrar y calificar el instrumento. Planificar la encuesta. Disefiar la encuesta. Analizar los datos. Validar el instrumento.8. Seleccionar los paIiicipantes. Reportar los resultados.DECASO DE ESTUDIO F ASE DE LA INVESTIGAcrON EN QUE OCURRELA TACTICA Usar varias fuentes de evidencia Establecer una cadena de evidencias Hacer que infonnadores clave revisen el bon-ador del infonne de caso de estudio Hacer pal/em-marching Hacer construccion de explicaciones· Abordar las explicaciones ri\·ales Utilizar model as logicos Utilizar teoria en casas de estudio imicos Utilizar l6gica de replicacion en casas multiples Utilizar protocolo de caso de estudio Desarrollar una base de datos dc casas de estudio I Validez de constructo I Toma de datos Toma de datos Composicion Validez intern a Analisis de datos I Diseiio de la investigacion Validez externa I Toma de datos Fiabilidad Tabla 11. Preparar el instmmento de recogida de datos. EI proceso de una en cuesta comprende las siguientes actividades: e e e e e e e e e e Fijar objetivos especificos y medibles.kTICA. Asegurar que los recursos apropiados estan disponibles. PRlJEB.354 CAUDAD DE SISTEMAS INFOR..\L'\TICOS © RA-ivL>\ actitudes y comportamientos. Tacticas para conseguir la validez de los casos de estudio .""S I T.

en sentido de que sea resistente a los sesgos. etc.4. 0 experimental. con infol111aci6n e instrucciones adecuadas.) y el f0l111ato del cuestionario (legible. apropiada respecto al contexto de la poblaci6n y a la complejidad de la propia encuesta. especialmente la selecci6n de las preguntas (inteligibles.) Evaluacion del cuestionario. en un caso de estudio los datos son tornados durante la ejecuci6n de un proyecto. Ii) Ii) . etc. que tiene que escogerse para que esta sea representativa de la poblaci6n. en el caso de un estudio observacional. por ejemplo. En una en cuesta no es posible incluir medidas. y efectiva en coste (dentro de los medios disponibles) y tiempo de los encuestados. constmcto. Es posible realizar una comparaci6n de las estrategias de acuerdo a los siguientes factores: Ii) Control de la ejecucion. La encuesta es la estrategia de men or coste. Control de la medicion. el investigador no puede continuar con el estudio. etc. ya que no requiere gr'andes cantidades de recursos.~ RA-MA CAPITULO 11: GESTION DEL CONOCI. con prop6sito claro. Por el contrario en un experimento el investigador tiehe control pleno sobre la ejecuci6n. criterio. Coste de la investigacion. Comparativa entre las estrategias empiricas Los prerrequisitos de una investigaci6n limitan la elecci6n de las estrategias de investigaci6n. etc. y abordable en coste (sobre to do si la encuesta requiere asistencia presencial 0 telef6nica).MIENTO 355 Estas autoras recomiendan tener en cuenta algunos aspectos importantes a la hora de !levar a cabo una encuesta: Ii) Disefio de la encuesta. en numero apropiado. Describe cminto control tiene el investigador sobre el estudio.) del misrno Ii) Ii) Ii) 3. mediante un foclis group 0 un estudio piloto.) y validez (de contenido. interobservador. Por ejemplo. el coste asociado a la investigaci6n varia. Dependiendo de la estrategia elegida. consistencia intern a. con el tamafio de la investigaci6n y las necesidades de recurs os. por ejemplo por razones econ6micas. El disefio puede ser: descliptivo. Tamafio de la muestra. concretas. Si se decide suspender el estudio. A la hora de disefiar una encuesta se pretende conseguir que sea efectiva. Construccion del instrumento para la encuesta. Y estudio de la fiabilidad (test-retest. Es el grado en el que el investigador puede decidir las medidas que deben ser recogidas y las que deben ser incluidas 0 excluidas durante la ejecuci6n del estudio. Esto esta relacionado.

H. (eds.fhmre.M. P. S . B. http://\\ww..) (2006). Se refiere a la facilidad con la que podemos replicar la situacion base que estamos investigando. D.. no se puede llevar a cabo un experimento. L 2002.fhmre Engineering".• Pickard. S. Springer. Universidad de Castilla-La Mancha. IEEE Transactions on Software Engineering. Gracias a la posibilidad de replicacion de los expelimentos sus resultados son mas generalizables. L. Gestion del conOClIIllento en Ingenieria del So. henamientas.• El Emam. A. M.com/issn/13 82-3256. (eds. Factores de las estrategias de investigacion (Wohlin et al. FACTOR I I I ENCUESTA Control de la ejecuci6n Control de la medici6n Coste de Investigaci6n Facilidad de replica I I No No Bajo Alto I I I CASO DE ESTI5DIO I I No Si Medio Bajo I I I I I EXPERiiY1E:STO Si Si Alto Alto Tabla 11. Kitchenham. En esta recopilacion se abordan diversos aspectos de la gestion del conocimiento aplicada al desanollo y mantenimiento del software: uso de ontologias... Kluwer Academic Publishers.9 muestra cada uno de los factores mencionados antes para cada una de las estrategias y se puede usar como guia a la hora de decidir que estrategia seguir. y Kitchenham..9.fhmre Engineering: An Introduction. Regnell B. A. Rosenberg. La tabla 11. A.. Host M. Jeffery.. Runeson P. Se trata de una serie de seis articulos en los cuales se presentan los principios para llevar a cabo encuestas de una manera rigurosa. and Wesslen A. Wohlin c. (2000) Experimentation in So. ACM.) (2003). etc. y Moreno. Revista "Empirical So.A. N. Juristo. B. Este articulo da pautas sobre como llevar a cabo investigacion empirica en ingenieria del software de manera rigurosa.. 28(8).fhmre Engineering Experimentation.. Berlin.fhmre Engineering. Pfleeger. M.356 CAUDAD DE SISTEMAS INFOJUv!A TICOS e Facilidad de replica.. LECTURAS RECOMENDADAS e Aurum..fhmre Engineering KnOlrlegde. Principles of SlIlWY Research. (2001) Basics ofSo. y Piattini. Wohlin. j\lianaging So. Estos dos libros e . 721-734. R. Esta recopilacion reline los trabajos mas importantes sobre gestion del conocimiento en ingenieria del software a nivel intemacional. Handzic. metodos. Kluwer Academic Publishers. e e e Vizcaino. Pfleeger. es una revista de la editorial Kluwer especializada en Ingenieria del Software Empirica. Jones. Si la replicacion no es posible. Software Engineering Notes. Hoaglin. c. K .. (2001-2003). 2000) 4. Ohlson M.kluweronline. Preliminary Guidelines for Empirical Research in So.

I.) han recibido mayor atenci6n hasta el momento.l.de/ISERN/ La red ISERN (Jntel71acional Sofhrare Empirical Research Net1l'Ork) agrupa a los principales investigadores en el campo de la Ingenieria del Software Empirica. realice el estado del arte de la gestion del conocimiento en la ingenieria del software. Siguiendo la propuesta de Lawion (2001) que se presenta en la figura 11. Es el libro mas representativo para la utilizaci6n de casos de estudio. Iil Yin. etc. Si en su organizacion se utilizan sistemas cooperativos y de trabajo en grupo 0 Intranets estudie la utilidad de los mismos como sistemas de gestion de conocimiento.) 6.-'. destacando que aspectos (tecnologicos. sobre c6mo llevar a cabo estados del arie de manera sistematica. recomendar areas de investigaci6n y sopOliar la fonnaci6n en ingenieria del software.1. Case Study Research: Design and Methods. 4.t112:.cebase. Siguiendo el metodo propuesto por Kitchenham.orQ/ EI Center for Empirical~~'-Based Sojt. ERCiCIOS Para la obtencion de conocimiento uno de los principales metodos es la realizaci6n de un estado del ane 0 revision sistematica sobre 1a cuesti6n que se quiere conocer. organizativos. Analice la propuesta de Kitchenham (2004) "Procedures for Perfonning Systematic Reviews".iese. calendario. R. DEL COl\OCIMIENTO 357 han sido los primeros en abordar rigurosamente la experimentaci6n en el campo de la Ingenieria del software. Keele University. <!. 28. Nllmero de lnfonne 0400011 T. Cuales cree que seran los principales obstaculos que se encontraria en la implantacion de una estructura de este tipo? 2. . 3. Sage Publications. http://ww\v. (2003). SITIOS WEB RECOMENDADOS Iil w\vw.l'([re Engineering (CeBASE) reline modelos empiricos con el fin de proporcionar a las organizaciones guias para seleccionar tecnicas y modelos.[ RA-MA CAPiTULO 11: GESTIO. Presente un plan razonado (costes. 5. (. metod610gicos. 5.K.) de implantaci6n de una factoria de experiencia en su organizacion. analice la arquitectura de gesti6n de conocimiento de su organizaci6n identificando las posibles deficiencias de la misma. etc. si bien no esta adaptado ni a la Ingenieria del Software ni a los Sistemas de Infonnaci6n. Thousand Oaks.

Lethbridge llev6 a cabo una en cuesta para deterrninar en cuales areas de la infonniitica pensaban los profesionales que necesitaban una mejor forrnaci6n (vease "11171at Imowledge is important to a software professionaf'. Lleve a cabo un estudio sobre el significado y las implicaciones desde el punto de vista tanto investigador como practico del concepto de Evidence-based Software Engineering (Ingenieria del Software basada en evidencias). . IEEE Computer. Mayo 2000). 8. sobre los beneficios de pair designing para la mejora de la difusi6n y el reforzamiento del conocimiento (vease apartado 3. Lleve a cabo un caso de estudio sobre la implantaci6n de alguna metodologia herramienta en su organizaci6n.3). Replique alglin experimento sobre alglin tema de su interes. 9. Lleve a cabo una encuesta similar en su organizaci6n y compare los resultados entre las dos encuestas. T.1.358 CAUDAD DE SISTEMAS I1'IFORMA TICOS ©RA-MA 6. como por ejemplo. 0 7.

Software Engineering and Integrated Constl1lctil'e COTS .ACRONIMOS ACT ACP AEC AENOR AFNOR AIO AlvlFE Adaptatil'e Control of Thought Area Clave de Proceso Asociaci6n Espanola de la Calidad Asociaci6n Espanola de Nonnalizaci6n y Certificaci6n Association Franqaise de Nonnalisation Abstract Interaction Object Analisis Modal de Fallos y Efectos American National Standard Institute Application Programming Inteljace Appraisal Requirements for CALM! Architecture ofIntegrated Information Systems American Societyfor Quality British Standards Institute CMMAppraisal Framework ANSI API ARC ARIS ASQ BSI CAF CALDEA CASE CBA-IPI CMM Cl'vLvfI CMMI-SE/SW/IPPD COCOTS Cali dad de ALmacenes de Datos Computer Aided Software Engineering CJIM-BasedAppraisalfor Intemal Process Improvement Capability Maturity Model Capability }v/aturit)' Model Integration CMADfor Systems Engineering.

'ientatioJ] Capacil)' Process Gpper COTS-Based ReqIlirenlelltS Engineering CTh DDE DEC DOE EFQ\l ElA ElAIS EIS Comite Tecnico \acional Disefio de Experimentos.·lrchileC1Iire Coll1l11ercial-O(l: The-Shelf' Capaciz\· Process Coger Core Plan Repre.-\\..lFE Frumel\Drkj!Jr Ihe .-\:vIEC. R.-\L F\lE F\lEA FMESP FPKD GC GCR GQM GUI HCI HTML I+D L-\-SI IEC IEEE IFPUG IMS Fuzzy Prototypical Knowledge Discovery Gesti6n de la Configuraci6n Grupo Critico de Referencia Goal Question \!etric Graphical User Interface Human Computer Interaction Hypenext \!arkup Language Investigaci6n y Desarrollo Investigaci6n-Acci6n en Sistemas de Infoffilaci6n International Eleclroleclmical Commission Institute of Electrical and Electronics Engineers International Function Point Users Group indice de Madurez del Software .\Joe/ding and EmIllalion o/'So/il!'C1I'e Processes E\". Digiwl Eqllipmel11 COIporulicm Desing OfExperimel11s.lIodes and E.·llIiance Elec!rOlzic Jndzlsrrius .-\luaci0n y \lEjora de la C\Lidad de los datos y de la intomlUci6n Formal \kthods Europe Failllre .-\-MA COQ CORBA COTS CPL CPR CPU CRE COSI OfQllaliZl'.-\ \ '.t/cCls Ana(l'sis. Cosle de la Calidad.-\ Beans European :\onn EJB E\ EOQ ER Europ-=an Organization for Quali!)" Entidad-Inten'elacion E\'. C0ll11110n ObjecI Reqllesl Broker .·llliwice inlerin1 Slolldurc/ Entomo de Ingenieria del Sot1\\'are Enterprise J.360 CAUDAD DE SISTEMAS I0:FORMA TICOS .. \'ease . n'ase DDE European Foundation tor Quality \lanagement Eiecfl'(JIlic Indllslries .

Do. Act (Vease PHCA) Program Emluation and Re"iew Technique Planificar. Check.\/eaSllre Model L!ie Cycle . Actuar Productivity Index Process Interchange F 017lzat Project .·eloplllenr Capability MallIrity Model in dice de Priori dad de Riesgo.-are Engineering Ent'ironment Process Spec!izcalion Language Practical Sofnmre .MPI SCE Subcomite Standard CMAll Appraisal Alethodfo!" Process IlIlpro.-ivLA.\/eta Object Facility Object Constraint Language Object Management Group Plan. InrernationalStandardi::ation Organi::ation Joint Technical Committee I Japanese Union of Scientists and Engineers Knowledge Discovery in Databases Knowledge Il1Ierchange Format Key Practices (Pnicticas clave) Key Process Area (Vease ACP) KIF KP KPA LCI LCS LMP Limite de Control Inferior Limite de Control Superior Lenguaje de Modelado de Procesos Lines Of Code Ley Organica de Proteccion de Datos :\leta Data Coalition Massachllsells Institute ofTecl1l1ology LOC LOPD MDC ivllT ivL'vlHQ Miv[LC MOF OCL OMG PDCA PERT PHVA PI PIF PMBOK PSEE PSL PSM PSP QFD Multimedia House of Quality . Verificar.\JanagellIent Body o/Knowledge Process-centered So/tv-.~ RA. ACRONIMOS 361 IPD-CMM IPR ISO JTCI JUSE KDD Inregrated Prodllct De."elllenr So/hrare Capability Emillation . Hacer.\1easllrellIenr Pel:wnal Sofnmre Process Quality Function Deployment Rational Cni/zed Process RUP SC SCA.

TOO TQM TSP UEM UML Tecnologia Orientada a Objetos Total Quality Management Team Software Process Usability Emillation Methods u'n!fied . Grupo de Trabajo.\/odeling Language (Lenguaje Unificado de Modelado) LJNE UPM WfMC WG Una Norma Espanola Unified Process Model Wor~110>1" Management Coalition Working Group.362 CAUDAD DE SISTElvLAS INFORMATICOS ©RA-MA SEI SGBD SGC SI SMSDM SPEM SQL SQuaRE SUMI SUS SW-ClvL'v! TC SO/Al'are Engineering Institute Sistema Gestor de Base de Datos Sistema de Gestion de la Calidad Sistema de Informacion Standard Metamodel for Sofnmre De\'elopme!1/ Methodologies SO/Mare Process Engineering Metamodel Stl1lctured Quel)' Language Sofill'are Product Quality Requirements and Emluation So/nmre Usability /lJeasuremel1l!m'entOl)' System Usability Scale Capability Maturity Model for SO/Mare Technical Committee. .

Y Pfahl. June IS. (1991). Abran. R.283-328. y Fuggetta.. "Assessing Process-Centered Software Engineering Environments". ACM Transactions on Sofnrare Engineering and Method070gy 6. R. Adamson.Sofnrare DCI'elopmelll Capability Emluation.BIBLIOGRAFiA Abdel-Hamid. y Dumke. R. Handbook of Sofnrare Engineering and Knowledge Engineering.. Jo1m Wiley and Sons. A. A. pp.. T. Y Coallier. Anderson. S.UlJl.. Application Althoff. Monterey. Conradi. tv!. Proceedings of the 5th Intemational Co/?terence on Ente/prise biformation Systems IICElS 2003). y Verjus. F. Haurat A . "Languages and Mechanisms for Software Processes and Manufacturing Enterprise Processes: Similarities and Differences". (1983). Arbaoui. Cambridge: Harvard University press. Wohlin. (2003) "Integrating Experienced-Based Knowledge Management with Sustained Competence Development". 474-482. T. 2nd IEEE Software Engineering Standards Symposium. 193-237). D.. In S. Acuna. YMadnick. Springer. A1bretch. ivfeasuring Application Developmelll Productivity. pp. April. V. Ferre. April.. Ambrio1a. A. l.. A. J. pp. F. Data Warehouse Design Solutions. K. World Scientific. (1979). Joul7lal ofSofnrare Maintenance and Emlution: Research and Practice 17. (Vol. pp. (1995). A. Oquendo. Christopher y Venerable. Theroude. . (2005). Mate. Chang (Ed.. New Yersey (EE. De Antonio. Volumes I and 2. 'Trillium: a model for the assessment of telecom software system development and maintenance capability". Proceedings of the IBM Development Symposium. S. M. A. Michael (1998). x. Fundamentals . 83-92. H.) Berlin. Jeffery..3 (July 1997). (eds. R. "Software Maintenance Maturity Model: the software maintenance process model'·. (2003). Evaluation and Improvement"... Aurum. Prentice-Hall. USA. pp. Sofnrare Project Dynamics: An IllIegrated Approach. (2001). L y Lopez. A (1997). Handzic. c. 197-223. Huffman.). K. F. 175. AFMC (1994) Acquisition . The architecture ofcognition. S. pp. Air Force Materiel Conmland (AFMC) Pamphlet 63-103. J. En Afanaging Sofnrare Engineering Knowlegde. "The Software Process: Modelling. 1994.

So I. 186-206. 1999. IEEE Bansiya L Etzkorn L Davis C. ]\. Balzer. H. December 1993. D. y Li W. "Supporting Cooperation in the SPADE-I Em'ironmenCIEEE Transactions on Sojnmre Engineering. H. S . 22(2).I I. R. C. Y Narayanaswamy. IEEE So/nmre. Wohlin.. A. 'The Experience Factory Organization". Basili. (1984) "\Iethodology for Collecting Valid Software Engineering Data". 17-32. y Rombach. "Two case studies in modelling real. (1988) "Towards A Comprehensive Framework for Reuse: A Reuse-enabling Software Environment". December 1996. Basili. "A Hierarchical Transactions Oil Soll1mre Engineering. "Special Section: Assuring Information Quality". "Building knowledge through families of experiments". Ghezzi.gualitv.364 CAUDAD DE SISTEMAS INFO~'vIATICOS ©RA. Bansiya 1. 6. Bandinelli. Y Reaman.R. R . IEEE Transactions on So.0. (1995). y Davis c. Baldrige (2005). V. V. c. (1999). 11(S). (1999).R.... Management Science.. F. 37(1): pp. R.nisLgov CCltimo acceso Agosto de 2006). P. S. Managing Sojilrare Engineering Knowlegde. R. G.-'Ianagerial Issues in Data Quality". Proceedings oOhe First AC\! SIGSOFT Symposiulll 011 FOlindatiollS ofSojnmre Enginering.. A. A. Sloan . C. ". "Modeling Information Manufacturing Systems to Determine lnfornmion Product Quality".. IEEE Transactions on Sojnmre Engineering. pp. Ballou. "A Class Cohesion Metric For Object-Oriented Designs". Bandinelli.. (2002). Pazer. R. Ballou.K. 30-31. Berlin. (cds. pp. 462-484.D. Ballou D . E. y Fuggetta. 47-52.. pp. y Wang. V. K. (1999) "Enhancing data quality in Data Warehouse Fnvironments".PerF017I1WICe Ercellence. Y Weiss. 1984. Barghouti. Springer. 1'0142. Criteria . y Lanubile.. G. G. pp. M.. S. Disponible en: http:\\ww. M. BaIlOl~ D... Wang. Sojnmre Process -IlIlprol'emclll and Practice (Pilot Issue). Communications oltlze ACAf. Basili.K. A . IEEE Transactions on Sojnmre Engineering. Madnick. D . S. 2S(I). "Software Process Model Evolution in the SPADE Environment". 55-64. F. 440-454. (1996). D. N . pp. Management Science 4·1(4). (1993). Belanger. Uni\'ersit:y of Maryland. SE-IO. 9. pp. y Tayi. G. "Improve Software Quality by Reusing Knowledge & Experience". Pazer. corporate processes". AClvL Software Engineering Notes.-MA Aurum. pp..K. Y Tayi.. IEEE Transactions on Sojnmre Engineering.) (2003). \IIT Press. C. Handzic. January 1999.. G. 21(5).728-738. 4-17.tin. Proceedings of the First International Conlerellce on h?/ol7lwtion QlIali~l' (fClQ '96). Basili. (1995). L Loi. 25(4). Shull. H. The Malcolm Baldrige National Quality Award Program. Wang R. I 9( 12). (1998). . Basili. December 1993. Journal of .R. 1998. y G. 18(5). CS-TR-2I5S. JetTery. y Tayi. ~vlodel for Object-Oriented Design Quality Assessment". (2002). 435-437.. Tlze JOllrnal oj'Ol'iect-Oriellled Programming.. Fuggetta.. Y Tayi. Fuggetta. 19(3): pp. Bandinelli. y Alliegro./nmre Engineering. Lavazza. UAllACS-TR-SS-9:!. 20(3). "Modeling Infonnation Manufacturing Systems to Determine Infornmtion Product Quality". D.\Ianagemelll h?jol7lwtion Systems. (1996). V. Di Nitto. Rosenblum. "Modeling and improving an industrial software process". (1993). December 1988.K.. Ballou. pp. D . 462-484. pp. (2004). A . Y Caldiera. pp. (1995). V.\fanagemel/l Redl!\\'. "Mechanisms for Generic Process Support". 44(4).

November 1988.02. J.\!linch. Ltd. P.. 8. October 1991. R.rSecond IlIIel7l(J/ional So. Bella.. Bubenko l .R . A.. Annl/a/ ....P .·www. 2-13-250. Duran. R. (1988). Actas del SoJilmre Measurement European Fomlll (SMEF·O-l). Briand. Control. F. Disponible en: httn:. "A and Evaluation". y Vallecillo. y Navathe S. !\!. Kitchenhanl B.E .!aturitv assessment. Boman M. "A Conceptual Framework and Belief-Ftmction Approach to Assesing Overall Infonllation Quality". Pasquini A.. (1992). Z. November 1998. Batini C. Intemalional Sojilmre Engineering Research . 1'01 18. I.(IlIIelligenl 5.filmre Quality in Europe. y YaIlkele\·ich. ConceptuaIJ/odelling. D.. Sweden. Burgues.. Prentice HalL Botella. N. Benjamin Cununings Publishing Company.. "A Paradigm for Decentralized Process Modeling and its Realization in the Oz Environment". y MaIyin Zclkowitz.1. G. Redondo Beach CA (USA). Boudier. (1997). 1. IlIIel71ational Journal o. Serco. W.L (1991).. (2003). R. Franch. Proceedings o. Sojilmre Process ImprOl'elllelll and Praclice 5 (-I)..VASA Goddard Sojilmre Engineering Workshop. C.. y Morasca S.rl1mre De\'elopmelll EI1\·ironmellls. "An Experience Management System for a Software Engineering Research Organization ". pp. (2005) "Measuring the usability of software components".·. B.. Serco Csability Sen·ices. y Kaiser. M.. (1998) "A Software Engineering View of Data Quality".. Proceedings or the IlIIel71C1tional Workshop on Design and J/anagemelll o. Proct!edings a/the 16th Imel7lational Con/i!J'cncc on Sojilmre Engineering. Costa.~ RA. marzoabril. Technical report ISER. M. M. Ben-Shad. 1. A y Zenc!. "SPI in very small team: a case with CMM". (2000) "A quality-based framework for Physical Data Warehouse Desi&'Il". 1. y Thomas. (2000).. Batista J. "Towards a Quality Model for the Selection ofERP Systems". El Emam K. Bo\·ee. Stockholm. Minot. H. M. (2002). M.. (1994).l7npOSillfll on so. Malaga Bertoa. SPEARM!:VTf" i Lser :\[anual. A. (2003).. M. . ::6. Pastor y t.r Data Warehouse (DMDH"2000). . A..com·tnl111Ddocuments. 51-7-1. Gallo.-MA BIBLlOGRAFiA Y REFERENCIAS 365 Basili. Seaman. Fraunhofer Institute. Troya. pp.usabilitv·. Tesoriero. "An empirical review of use cases metrics for requirements \·erification". 225-245. JOlll7lal 5. An emily relationship approach. J y .n·lems. Lindvall. P. P. Component-Based So. y Mak. Belgium.\·slems and Solimre. Ceri S. 69-77. Bouzeghoub. "Quality Anributes for COTS Components". Boegh.M.\!elo. Marre. A. Quer (2003). Pp. Becker-Komstaedt. "Adele2: A Support to Large Software Development Process".filrare Quality. 0/ Bevans N.r SIGSOFT'88: Third 5. Can·alIo. L. Bemardez.i. M. lohannesson P.. pp. 6th Intel'l1ational Workshop on Qual1lilati\'e Approaches ill O~iect-Oriellted So/ilmre Engineering (QAOOSE'2002). IEEE SO/l1mre 23 (2). y Figueiredo A. V. Estublier.. y Kedad. 1.}. "Theoretical and empirical validation of software product measures". June 5-6. X.\ieMork.1. (2000).• Ocampo. (1999).V!" Srivastuv·a.serco. ~Iethod for Software Quality Planning. X.opLodf (Ultimo acceso en Mayo de 2006) Bobrowski. . Imrodllction to l/sabili(r mallirizr asseSSlIlenl. L Neu.V-95-03. DePanlilis S. lESE report n° 072. Bertoa. Proceedings of the 1st IllIel'l1ational Con/i!rence on the Sojilmre Process. Belkhatir. Concepllial daTabase design. Proceedings o. 1. (2001). 26-35. y Wangler 8. G. U.. F. F. N!endonca. 2000. y Genero. "An Oven'iew of PCTE and PCTE-". v. y Vallecillo. Agosto 2005.: London. 10. 2003. NL (200-1). (1995).

. y Basili V. V. Cant.S. Actims y Objeto-Relacionales. Garcia. Technical Report CMUiSEI-96-TR-002 ESC-TR-96-002.!io. 68-86.). . BringeL H. L Morasca.. "Evaluating the Impact of Object-Oriented Design on Software Quality". "An operational process for goal-driven definition of measures". CA. pp. Piattini. (1963). Gray. Joumal o. Ruiz. (2005). y Henderson-Sellers B. pp. Enterprise Planning and Architecture Strategies". En: b!lormation and Database Quali(\·. Kluwer Academic Publishers.A.0. y Carapuya R. Boston. "Object-Oriented Software Engineering: Measuring and controlling the development process". Piattini. 1.366 CAUDAD DE SISTEMAS INTOIUvlATICOS © RA-?vt. 1. (1994). (1998).6 Bymes. VA. B. W. pp. Briand. PascuaL C. F. Piattini. "A Family of Experiments to Validate ?vletrics for Software Process Models". Proceedings a/the Eighth International COl!lerence on b!formation Qualit)' (lCIQ ']003). M. 22( I). A. 199. y Visaggio. (1994) "Application of Cognitive Complexity Metrics to ObjectOriented Programs". y Stanley.nd Practice.stems and So.lor research. 1. 28(2). (2005). Houghton Mifflin Co • Canfora.. "Establishing the Environment for Implementation of a Data Quality Management Culture in the Military Health System". "Business Process Modeling Towards Data Quality Assurance". M.. (1996). S. EPAS Meta Practices 67. Proceedings 0/3rd Il1Iel71ational Metric Symposium. Calero. C. ivl. N. A. 1992. Sojhrare Capability Emluation I ersion 3. Brito e Abreu F. 351-362.E . "Evolving Architecture Maturity. Caetano. 7. "Towards Data Warehouse Quality Metrics". Burzy11ski T. 90-99.. y Basili.J. (1996). 2001 Cah·o-Manzano. S. y Tribolet. F. C (2001) Definicion de III/ Conjunto de Merricas para la Afalllenibilidad de Bases de Datos Relacionales.A . Brito e Abreu F. "Property-Based Software Engineering Measurement'". Meta Group.A.. M.\perimelllal and quasi-e. 57-84.. Wiley 17(6). pp. y Serrano.!!. 297-313 Burke. G. (2004). Henderson-Sellers B. S. pp. Calero. pp. (2002). 52-63. 1106-1125.. USA. "A Conceptual Model of Cognitiw Complexity of Elements of the Programming Process".. 2002 Calero. Method Description. Journal o. 18. (1992). pp./Dbject-Oriellled Programming. pp. 7(4). F. (2000). E.{S). "Pair Desi!. 565-568. G.. Pp.. M.. (1996).. Burgess..! and Diffusing Design Knowledge". pp. IEEE Transactions on So/nrare Engineering.{l\mre.. (2001).Jaillle~~nce and Emlution: ReseCII":ch . 401-423. 113-129. Merodo de Mejora del Proceso de desarrollo de sistemas de informacion en la pequel1a y medicllIa empresa. v Visa!. y Jeflery. ivl. Cant.. Ruiz. Jeffery R. Proceedings o/the Third Conference on In/ol7nation Quality ICIQ '1998.\perimelllal desigllS . IEEE Transactions on Sojhrare Engineering. L Morasca S. M.!Oing as Practice for Enforcin!. C y Piattini. Canfora.. Tesis DoctoraL Universidad de Castilla-La Mancha. (2002) "Metrics for databases: a way to assure the quality". M. Briand. P. Garcia. y Melo W. pp. 77 (2). Tesis Doctoral. b!lol7l1atioll and Sofilrare Technology. McLean. (2002). Joumal o{So/nrare :. y Philips.. (2003) "A flexible quality ftamework for use within information retrieval". R. Proceeding 0/ICEIS'2004 Porto (Portugal). y Fiddian. 4th Int Con(erence on So/nrare Quality. CampbelL D. Agosto.A.. Universidad de Vigo. Aetas del 3rd Workshop on Design and Managemelll olData Warehouses (DMDW'OI).

Septiembre. (1001) "Fast&&Serious: a UML based metric for effort estimation. San Feliu. Software Engineering Institute. D. lA. y Shull. "The R.iS£!. CMUSEI-200 I-MM-OO I. and B. Journal of Software Engineering and Knowledge Engineering.reports:02tr002. 4. Proceedings of the 9th IllIemational SO/Mare Metrics Symposium (AfETRlCS'03). (1003). 1. (2002) Capabili(\' Maturity Moder Integration (CMIIl'·\!).'plained ]nd Edition..'perimefllation: design and anaZ\'sis issues for field settings. en http://www. 1. G . Cook. Carbone M. Nueva York. S. Munch. 1 (1002). IEEE Transactions on SojAmre Engineering. West. editors. M. IfIlegrated Product and Process De\'eIopment and Supplier Sourcing (CMMI-SE. Version I. Carretero. B. B. A. (1979). 1. B.edu !publications /documents i 02. 101-123. 5. SojAmre Process Modelling and Technology.A.-'\FiA Y REFERENCL-'\S 367 Cantone. pp. 1268-1287. y Sanchez. Proiect Managemefll Maturi/)' :Hodel Pro\'iding a Prol'en Path to Project Management Ercellence.. A. (1979). (2002). 1 (1992). Component-Based Sofnmre Quality: Methods and Techniques. pp. McGraw-Hill. Carver. y Ghezzi. Houghton Mifflin Co.0. W . I ) Staged Repre-sentation CMUfSEI-2002-TR-012 ESC-TR-2002-012. P . y Over. En A Finkelstein. "EPOS: ObjectOriented and Cooperative Process Modelling". People Capabili(\' Malllri/)' Model (p-CIL_n.B. Garcia Cordero. Curtis.(l999).\D Fad: Is Timing Really EYerythingry"IEEE Sofnmre.. G. 605-616.sei. T . y Vallecillo. Nuseibeh. F. "Production and maintenance of software measurement models". F. pp. . G. Westby. pp. Crawford. "A Family of Experiments to Investigate the Influence of Context on the Effect of Inspection Techniques".hunl (ultimo acceso rvlarzo 2006) Conradi. 476-493.-'\-MA BIBLlOGR. A (eds. 1 Kramer.. 1accheri.1 . (1994). "Process Modeling". M . Calidad. "A Metrics Suite for Object Oriented Design". D.-. Cugola... Springer. Versioll 2. Quali(1" is Free. Boston. 1002. (1001). "Issues in Using Students in Empirical Studies in Software Engineering Education".. S. C. Keele (UK). lA. 19-11. Quasi-e. SO/Amre process ImprOl'ement and practice. Proceedings of the 6Th International Conterenee on Empirical Assessment in Sofnmre Engineering (E. Curtis. 1998. y Miller. Quality Press Ciolkowski. Cerrada. COlllmullications olACI/. Piattini. pp. SO/Amre Engineering.. Amescua.. Hefley. M. y Santucci G. 1994.i'. • Crosby. S. pp. M . GesTion del Proceso Sofnmre.. Zhu. y Campbell. A. M. Nguyen. 10(6). (1000). 1accheri.SWilPPDfSS. 3544 Card.N. R. Centro de Estudios Ramon Areces. B. Publisher Marcel Dekker/Center for Business Practices. S. pp.) 2003. C. 31( II). Y Kemerer C. Madrid: Editex.. Arcilla. C.. Sanchez-Infantes. R. 48-60. P. (2002). y Biffl. M .. 1 (2002). Alemania. Lecture Notes in Computer Science 2693 Chidamber S. Tsiakals. CMMJ. P. Research Studies Press Limited (1. 1. Calvo-Manzano.. Cuevas...A. 6th Intemational ECOOP Workshop on Quantitati\'e Approaches" in Object-Oriented Software Engineering (QAOOSE"]OO]). Cianmmi.139-251. lA. M . P. Sanchez-Infantes.. Ingelmo.. VI. Shull. vol. Wiley). y Donzelli..A. Ed.cmu.150 9001: ]000 E. Morasca. P.. (l995). Kellner. Pp. Liu. L. (1994).I C:I£I[f·\fjor Systems Engineering. Larsen. Cechich. T. "Software processes: a retrospective and a path to the future".

S . (2003). fTArchitecture Capability . (200-+). Ley de Proteccion de Datos: La nuem LORTAD. F.-\PEL: a Graphical Yet Executable Fom1alism for Process Modeling". J. (200'+). pp.2 Method Description. Englewoods Cliffs. "Dewloping data productions maps: meeting patient discharge data submission requirements".on!!archilectureto~af8-docarclYp4I11aturityfmat.ifJ. Prentice Hall. Dernian1e J. V. Working KnOlv/edge. MIT Center for Advanced Engineering. Y Gruhn. 6C!). DRA. y Kaba A. Dunaway. R. "Managing Processes for Information Quality: A Framework for Process !vletadata Development"'. "Software process analysis based on FlJNSOFT nets". A. J. (1995). (2000). Boston. 1996. . V. 74-81.368 CAUDAD DE SISTEMAS lNFORMATICOS gRA-?vlA Daich.YO 1:4 TICA 11" 171. S. Dumke. y Prusak. R. Y Winkler. "Cuestiones Clave y Nueyos Retos en la Tecnologia de Proceso Software".pp. Klwrer Academic Publishers. Version 1.oDenerouD. G. (200 I). R. B. Proc. (1998).E (2006). I'ersion 3. A. A. pp. January 1998. Proceedings of the Fourth Symposium on Sofl1rare De\'elopmelll Enl'ironmel1ls. D.i/atllrit)' Model rACif. W. E.C Y Oquendo. 8('+-5). ~!etrics Tools". Davidson. Derniame. (1990). (1997) "CAME Tools for an Efficient Software Maintenance". Systems Security Engineering Capability Maturity . A Total Technical Managemelll Approach. 315-325. January 1999. (1986). Carnegie Mellon UniYersity. Berlin. March 17-19.. Department of Defense U. Deming W. DoC (2003).L y Wang. pp. LNCS W1500.0. pp. Arlington VA.e. L. 2003: Disponible en: hnD:'w\\'\\'. Department of Defense. International Journal Healthcare Technology and Mallagemelll. K. SIGS Books. ". Derr. 223-2'+0. The Journal ofDe/ense Sofnrare Engineering. D.. (eds) (1999). Dami.A (1999). December 1990..il -Based Appraisal/or Intemal Process fmprm·ement.. (1988) Sofnrare Quality Engineering. Chapter 3. W. CJIM S. Estublier. 22'+-233. Haryard Business School Press. Deiters. YGruhn. (1991)..Hodel (SSE-OIM). Prentice Hall. Crosstalk. Y Masters. Madrid. The Open Group: Burlington ivlA. Deustch. T. Dawnport. NJ. Cif. S .s. Wastell D.illi1 -Based Appraisalfor IlIIemal Process fmpra\'cmelll (CBA IPI). Diaz de Santos. Dunaway. (CBA IPf) Lead Assessor's Guide (CMUSEl-96-HB-003r Software Engineering Institute. K. 60 . y M. Methodology and Technology. of the Euromicro'97.96. Cambridge. Springer Verlag. M. Proceedings of the Eigth IllIernational Conference on b!formation Quality (lCIQ '2003). New York. Lee. (2000). Dedeke. Deiters. Y. Pinsburgh. 1995.htm (ultimo acceso en Agosto de 2006). DicciOllario de la Real Academia de la Lengua. (1995) ApP(\'ing OMT. 326. Systems Ana~\'sis Modelling Simulation. Software Process: Principles. Amiour. "Universal Septiembre 1995. y Giles. "Managing Software Processes in the Environment MELMAC. y Willis. Ollt olthe Crisis.H. . US Departmelll of Commerce. R. Del Peso.

a[mil crosstalk fmmes. G.~FiA Y REFERENCIAS 369 Dybil.\'InposiulII onl!!!ormotion 5. L (19941. Lloyd's Register. Y?vlarciniak. Fagan.. . M.148-157. pp. Proceedings of fhe Eigth fl1lernarionol COl!!i:rellce on In/orlllalion QualifY (/CIQ ·:COO]). Gennany. (1995) "Metrics Tools: Effort and Schedule". Managing Sojilmre Engineering KnOll'iegde. (eds. IBM Systems Joumal Feigenbaum.\\" . 1. A. "Architectures for Process Support System Interoperability". "The Concept ofinfonnation Quality: An Interdisciplinary haluation of recent Infonl1ation Quality Frame\\Toks". Prooceedings (jf'the Filih fntemationol Conterence on the S()!ilmre Process. New York. \Iarch of 1995. D. D. Eppler. Springer.. Proceedings offile Conference on Database and Expert 5. A" JetTef)'. hans ?vl. ~lanagement Systems Services". John Willey & Sons. Eppler. Springer. S.. Second Ed. (1993 I.\lonagcmelll. 71-102). Disponible en: httD:' \\Ww.. (2003) "e-R&D: Effectively \'!unaging and using R&D Knowledge". Navuthe. pp. Aurum. LP. (1987) SojiH'are QualifY Assurance and Managemelll.. J.iinol de/iI'erabie (l'ersion 0. (19971. Dafabase Sysfellls.I . \!assachussets. Vega. 182-211. y Muezenmayer. (2001b).. (2001a).• y Schafer.~nh-Tuyet LE.aso'!uri= 1995 03. Eppler. P. y Be1khatir.'Y". 1. 1999. De?vlan. 46-61." Proceedings orthe ]000 Conference on fn:jimllation Qllalil)·.. (1999) flllpro\'ing Data Warehouse and Business Injimnation QualifY: Methodsfor reducing costs and increasing Pr(jiits. pp. G. Cunin. EC /. Y Steadman. Villalobos. Willey & Sons. Earthy.y S. Elmasri R. Sanlaville. En c.stsc. (1998).ntem and Engineering (/S£'01) June 25-28. "Increasing Infommtion Quality through Knowledge Ne\·ada. Las Vegas. 167-182. pp. (2000) "Conceptualizing Infommtion Quality: A review of Information Quality Frameworks !Tom the last ten years. Toral QualifY Control: Engineering and . 1. . Capitulo.1. C. (1961).\~"ellls Applications (DE. Smdies in Communication Sciences I (]OOf). to Reduce Errors in program de\·e!opment. F. IL June 1998.3. European Sofnmre Engineering COI!(erencl! (ESEC! Engineering (SIGSOFT FSE). 1997.\. Y Groenewegen. 1. R" Wohlin.f(p). \1. 1. (2003 I. Emmerich. W.I/ode//ing and Technology (pp.hill. Proceedings of the ]001 fntemillional 5. "Usability ?v!uturity \!odel: Processes".) Berlin. English.'tA '93). (19761 Design and Code Inspections 15. Estublier. Handzic. T. IXLSED5. 1. P. y Wittig.. CrossTalk: The Journal of'Defense Engineering.l87-196.V. Erickson.aso (ultimo acceso en Agosto de 2006). London. y Schelenz. ?vI. "SOCCA: Specitlcations of coordinated and cooperative activities'.1. En Sojilrare Process .. "Object-Oriented Database Management Systems for Construction of CASE Environments'. 1.?vl. (2002). So/ilmre Estublier. (2003) :llanaging b!fimnarion Qualizl'. Eppler. A. 2003. M. M. (2003) "Factors of software process improvement success in small and large organizations: an empirical FOlllldafions of Sojilrare study in the scandinavian context"". 1. "Measuring Infonnation Quality in the Web Context: A Survey of State-ofthe-Art Instruments and an Application \!ethodoloi.' RA-?vL~ BIBLIOGR.\!etrics. M. Engels. pp. 7 y 8. Eppler.YLSE (IE :COI6J. Research Studies Press. P. Addison-Wesley.1. Pp 83-96. "An Approach and Framework for Extensible Process Support System". Lisle.. N. McGraw-HilL Nueva York. W" Kroha. 9th European Workshop on Sojilmre Process Technolog}' (EHSPT. Ebert.Y.]).

Forth Collins (USA). 1 M.. y Neil. Y Carleton. Software Engineering Institute. D. Finkelstein. N. Y Ribci. D. (1994). pp.• Williams W. Department of Communication Systems. c. Bullis R. Kramer. pp. (1993) "ProcessWEA VER: Adding process support to UNL'C··. Lund University. LNCS. f7!J JOl'l1adas de Ingenieria del S(jfl1mre y Bases de Datos (JISBD'03).. Addison Wesley. ed. (1998). (1999). A. Taz Daughtrey Edi-tor. En http:! web. Godart.34-4!. y Wang. Franch. M. (1992). W.TICOS ©RA. Methodology and Technology.. Pp. c. Hedlund 1.. Master's thesis.. X.c.D. Anllllal JIeefing 0/ fhe American EdllCClrion Research Associatioll. Berlin. "Software Process: A roadmap". Fenton N.. Florae. C.miLeduitdqmipapers93 ipass I '93-03. 2002. W. 12-26.113-12!. Firth. Fuggeta. In Fundamel1lal Concepfsjor fhe SO/Mare QualifY Engineer. pp. Pp. 1 M. S{atisrical Process Comrolfor So/hmre Process Impro\·emel1l. A. Snook S. Dennis M" y Sternberg R. A. Proceedings of the Firsr Imernational Con/i?J'ence on the Sofl1mre Process. Chapman & Hall. pp. y Jahnke. \'01. LNCS 1500. 231-240. Sofl1mre !. 1998. Alicante (Espana). 2" edicion. in 2nd Inrematiollal Conference an rhe SO/Mare Process. IEEE S(jfl1mre 20(1): pp. 195-200 (2001). February 1993. "Software Metrics: a Roadmap". ed. A. Proceedings (jf U. 1713. P. Sweden. "Using UML for Modelling the Static Part of a Software Process".370 CAUDAD DE SISTEl'vV\S INFORJvLA. Research Studies Press. (2000). 20(3). (2002) "Using Statistical Process Control to Measure Software Process". Box 118. (1993).. (2003) "Using Quality Models in Software Package Selection".2000 Fuggetta. (1994). Fernstrom. R. Furure of Software Engineering".M . 1 y Nuseibeh. "Closing the Data Quality Gap: Using ISO 9000 to study Data Quality".-MA Feldt. (2003). A. 1 (1999): "Architectural Views and Alternatives".ferrics: A Rigorous Approach. September 1992. (1997). 95-116.. Fenton. Carnegie Mellon University. A. (200 I) "Viewpoint Article: Conducting and Presenting Empirical Software Engineering".27-34.P. pp. pp. (1991) "Detlning a corporate-wide software process".133-144. 199-206. Florae. B. J. W. Franch. . "Software Measurement: A Necessary Scientific Basis". Sojhmre Qualil}' Measuremel1l: A Fran/elrorkjor COllilling Problems alld Defecrs (CMUlSE!92-TR-22). FOreS)1he G. Requiremel1ls merrics based 011 use cases. ACM. Thejiilure of'Sofhmre Engineering. Y Can·allo. Pittsburgh.359-370.html (Ultimo acceso en Agosto de 2006) Florac. Fenton N. A . X. Pa . IEEE Trallsacriolls On Sofhmre Fenton N. S-221 00 Lund. (2000).. Anthony Finkelstein. "Promenade: Un Lenguaje para la Modelizacicin de Procesos Software". Horvath lA . Y Carleton. Springer-Verlag. Measuring rhe Sojhmre Process. Finkelstein ACvL Press. Sofhmre Process Modeling and Technology.. Springer-Verlag. X . American Society for Quality. A. En Sofhmre Process: Principles. Franch.\fL '99. Empirical Sofhmre Engineering 6(3): pp.... "Construct validation of tacit Knowledge for military Leadership". IEEE CS Press. Lund Institute of Technology. Frailey. Engineering. (1999). y Pfleeger S.B. Y Ribci. Gertnany. Londres.

Harlow (UK). A. Pearson Addisson Wesley. Calero. (2004) Flv/ESP: Marco de Trabajo lmegrado para el Modelado).. D. Proceedings of the Set'emh Co/?terence on b!{ol1nation Quality ICIQ·2003. 305-316. Geno G. September.Wide Program. Sojhmre E. (2004) Sojilmre Quality Assurance: .{!ort '\/easuremelll: A Framellwk/or Coullling Stat}: HOllrs (ClfU/SEJ-92-TR-2I I.. Giannocaro. pp. "Formulation of a Decision Support Model Using Quality Attributes". A. y Darke. . WI: American Society for Quality. Inc. y Sanler. Shanks.mil crosstalk rrames. Tesis DoctoraL Universidad de Castilla-La Mancha. M... A . (1993).lnformation and Sojilmre Tecllllolog)·.T. A . 1'01.R. Giles. N" 9. y D·Onofrio.stsc. S. tvl.I. Crosstalk. Proceedings ofthe Telllh Australasian Conference on h?/ormatioll Systems . Ruiz. Technical . P. y Genero../i"om theory to implementation.\'ole CJfLiSEI-2004. F. D. ?vlorasca. UK.. (1995). "?-.. Jarzombek. y Rout. (1998). G . 344-355. Otono. Gendron. pp.1.. Pittsburgh.. Prentice Hall. 20-24. 2004. T. (Ed. Octubre 1998. J. .letrics Tools: Software Cost Estimation". T. Garcia.25-38). G. Vallecillo. (Eds. Gilb. T. Y Siyiy. A. Garcia. \Y'.. Oldano. "Applications of the Indicador Template for Measurement and Analysis ". Giles. "Measurement and Analysis in Capability Maturity Model Integration Models and Software Process Impro\·ement".. Gardner. G. K. L. httn:' www. G. 52-60. Y Barney..J. Galin. En Daughtrey. (2005). YCasswelL D. (1992). (2003). So/hrare Inspection. The Journal o{De{ense SofMare Engineering. Febrero. y Calero M.4.\/etrics/or Sojilrare Conceptual Models. Pp. (1984).I/etries: Establishing a Company.\'-024. Septiembre 2004. Goethert.B .33. y Graham D. "Towards a Consistent Tern1inology for Software iVleasurement"'. (Pp. September 1992. Architeclllre Maturity Assesment Emluation... (2004) "Report on the Dagstuhl Seminar 'Data Quality on the web' ".aso (ultimo acceso en Agosto de 2006).) (2004) . S. London: Addison-Wesley Longman./hmre . (1998).vo. CROSSTALK The Journal of Defense So/hrare Engineering (Software Engineering Technology). A CM TrclIlsactions on Softwore Engineering and Methodology. Bertoa. Carnegie ivlellon Uniyersity. M.. Tamer. (2002). voL 41. M .~RA-MA BIBLIOGRAFLA. Lavazza. Pa . Genero M" Pianini M. F. 411-448. (2002).. "Risk ivlanagement Supporting Quality ivlanagement of Software Acquisition Projects".. M. pp. y Orazi. Software Engineering Institute. W. Gartner (2002). la Medicion de los Procesos SofMare. Grady. Gartner. (1999). E. May 1995. "Applying GQM in an Industrial Software Factory". No. S . pp. (1987) So. R. c. (1995). CrossTalk: The Journal o/Defense SO{llrare Engineering.hiILaf. Y REFERENCIAS 371 Fuggetta.:V1. (2004). Piattini. Goethert..lvl. D.L. "Building the data warehouse". Communications of the Ael/. Gertz. F. Gan·in. Y Daich. Milwaukee. Goldenson. VoL 7. Imperial College Press. Proceedings o{SIGJIOD record. Hhat is Qualit)':' Sloan Management Review.asn?uri=199505\letrics. Software Engineering Institute. March 2004. D. "Stakeholder Perceptions of Data Quality in a Data Warehouse Environment"'. "Metrics Tools'.. Saake.. Cinti.) Fundamental Concepts/or the So/hmre Qualit)' Engineer.

y. Hareton.Y..-\ Comparison of four process metamodels and the creation of a new generic standard". 7(5).27-60. 47 (2005). (1977) Elell/ellls orSojnmre Science. Regnel!. y Parasuram S. (200 J) Dimensions of Database Quality. pp. 1'v!. H. (1996). Henderson-Sellers B.B. Bridge. Hare!.lfDJI"2001) Interlaken.I/etrics-. enactment and work coordination". "The IDEAL Model: . H. Henderson-Sellers. ACM Software Engineering Notes.. (200 J ) ". pp. Host. (2001).-\n ISO 900 J:2000 compliant quality management System for Data Integration in Data Warehouse System". pp. Zowghi D.tems: Practices. y Terence. 5( I). Heimbigner. Halstead. R. Proceedings '. McGraw-HilI. J. "'-\ methodological approach to data quality management supported by data mining".. 510-518. lA. y Hinrichs. The Netherlands.-\ Strategy for Ylanaging Data Quality in data WarehoLlse Systems". 1. (2000) "CLIQ. In Dl!l'eloping Qualit)' Complex Database Sy.! on ili/ormatioll Quality. 8th O~iect-Oriel1led lnjormarion Systems 2002. Keele University. 49-65. 1vl.th Conference on Empirical Assessment & Emluation ill So/nl'are Engilleering (LISE!. 20 J-214.I/easures o(complexity_ Prentice-Hall. S. Software Engineering Institute (SE/) publicC/tion. (J 981).. B.-\ Practical Guide for Improvement". 1 (1998). "An Evaluation of the MOOD set of Object-Oriented Software Metrics".A. December 1990. pp. S. 24(6). Nithi. Nueva Jersey. 409--421.th ACMSIGSOFT SymposiulII Sojnrare Dewlopmelll EI1\·irol1l11eIll5. Lecture Notes in Computer Science. Else\'ier North Holland. (2001). Hoyer. "I. Hinrichs. y \\llOlin. C. UK. y Politi. Gnmdy. Idea Group Publishing. Klemola T.. In/ormatioll and Sojilmre Teclmolog)·. (2002) ". y von yIaur. Proceedings of the '. Henderson-Sellers B. (1999). R. H.. 2425. Proceedings o(the Sixth IlIIemational COI!(erence on In/orlllation Quality. pp. D. 491-496. Y Myers. Editor Shirley Becker. Switzerland. Hoxmaier. pp. 200 I. 67-83. pp. "Using Sllldents as Subjects . "Software Structure "jetrics Based on Infom1ation Flow". Proceedings O/i/II! Sixfh International conterenc!. IEEE TramCictions on So/ill'ore Engineering. H7wt is QualifY. C. (1997).J . (1998). "Managing Change in Process-Centered Em·ironments". Counsell S. Autoll/ated Software Engillel'l'illg: An Imernational Journal: Special Issue 0/1 Pracess Technology. SpringerVerlag... and Technologies. C. June 4. B. L. Harrison R. Proceedillgs q(thejourtiI IEEE illlernational Baltic Workshop on darabases and b?/ormation System. IEEE TrallSactions on SOrMare Engineering.l y Hoskins. S. 200J. Grimmer.. J5. Y. 217-232. 62-76. H. Quality Progress. L. Sojnmre Process Improl'elllelll alld Practice 6. "Sizing use cases: How to create a standard metrical approach". E.A comparative Sllldy of Sllldents & Professionals in Lead-Time Impact Assessment".D DE SISTEMAS INFORMATICOS Grembn. Julio. y Kafura. pp. vol. pp. Proceedings ql'the International Workshop 011 Design and . y Osterweil. T.issue three. J/odel/ing Reactiw Systems ll'ith Statecharts.-\ Process Framework for Small Projects". "Serendipity: integrated environment support for process modelling. y Hoyer.I/anogemelll o( Data Warehouse (D.. D. (2001 J. Henry. (2004) . Object-oriellled . "I. yAden. (2002).W.37~ CALID. B. Helfert. y Gonzalez-Perez. (2000). The Statemate approach. Upper Saddle River. 2000 Hinrichs.Inteligent Data Quality Management".... Techniques. Sunon.. . (1990).

Humprhey. In Fundamental Concepts for the Sqlhmre Quality Engineer. 0 I-!vlay. Humphrey. Humphrey. (1997).Sojilmre Life Cycle Processes .I 998 IEEE Siandarel/or a Sofhmre Qllality Metric. R. American Society for Quality.. 3-16.1-1997. IEEE Siandard guide (LSi) IEEE Complller Sociel)·. y Wang. EEUC./mroductionto Personal Sojhrare Process. Public Productil"ity and J!cmagement Redell'. Institute of Electrical and Electronics Engineers. (1989) Managing the so/im". W.1-1997. W. Addison \Yes!cy.e process.H. (2000).1-1988. R. Hunter. IEEE (1992) IEEE STD 1061-1992. pp. 16(1).fEC 11107) Standard/or In/orlllation Technology-Software life cycle processes. CW. InduSII)' Implemelllotion of IlIIernational Standard ISO/IEC 12107: 1995 (ISO. The Team Sojhmre Process (TSP).H. IEEE Sid 1074-1995. A. IEEEiEIA 12207. K. IEEE (1998cl. W. IEEE (l998d). Institute of Electrical and Electronics Engineers. IEEE (1987) IEEE STD 1058. IEEE . Taz Daughtrey Editor. Noyember 2000.). (2000a).BIBLIOGRAFiA Y REFERENCIAS 373 Huang. John Wiley & Sons. W. Y. Software Engineering Institute. IEEE (19971 IEEE ELi 11107. Addison Wesley. Pp. IEEE Computer Society. EEUU. Reading ylass. Introduction to Team Sofm'are Process. 2002.1-1987 IEEE Siandardjor Sofllmre ProjeCl . IEEE (1988) IEEE-982. y Kwak.32-43.' . Humphrey.1aturity··. Y . . "Assessing Project Management e. "Software process modelling". R. IEEE Std 1061. K. IEEE Swndard jar a Sqlhmre Qualil)' Metrics Methodology. IEEE (1995). (19991. W. En Sofllmre Process. IlIdllsll)' IlIIplemelllalion qlllllernational Standard ISO/IEC 11107: 1995 (!SO. 1989. Addison Wesley.. Institute of Electrical and Electronics Engineers. 10 So/hmre Requirelllellls Specification.Vel\" l"ork IEEE (I 998b I.I 997. (2000b). Standard Dictionary qfMeasures to Proc/uce Reliable Sqlhmre. EEUU. Prentice Hall.Standardjor b!/ormation Teeill/olog. Hutf. ProieCl Jfanagement Journal 31. 25-37. pp. Hyde. TECHYICIL REPORT CllUiSEJ-1000-TR-023 ESCTR-1000-013. (200 I) (eds. Life cycle data. IEEE (1998a) IEEE STD 830-1998.·. YTIJayer. !I/duslly Implementation ollSO/IEC 11107:1995 .lEC 11107) Standard for li!/imnation Technology-Software life cycle processes. IEEE (19861 IEEE STD 1011-1986 IEEE Standardjor Sqlhmre I'ailication (Ind I'alidation Plans. Methodolog. Sqlhmre Process ImprolWlent.0-1996. Qualil)' In/ormation and KnO\r/edge.\fanagement Plal15. (1992). 'The Proyerbs of Total Quality Management: Recharting the Path to Quality Improyement in the Public Sector". T. Upper Saddle RiYer.B. Lee. IEEE Standardfor Del'eloping Sofilrare Life Cycle Processes. Humphrey. Ibbs. (2002) "The Software Standard Profile". IEEE"EIA 12207.Life Cycle Data Institute of Electrical and Electronics EngineersiElectronic Industries Alliance. (19961.

Ginebra. H71C1t is Total QlIality COlllrol?: The Japanese \l'(e\". ISO/IEC 1550-1-2:2003. International Organization for Standarization. Ginebra. ISO/fEC 15504-4:2003.Sofnrare Measllremelll Process. part 2: A reference model jar processes and process capability. ISO (2000c). K. Ishikawa. AENOR. Part 2: Pe/fonning an Part 3: Gliidance on ISO (2004d). International Standards Organization. lINe-EN ISO 9000:2000 Sistemas de gestion de la calidad Flindamelllos y vocablilario. ISO (1998). Suiza.' . Process assessmelll - Part 1: Concepts and ISO (2004b). AENOR.. ISO (2003). Suiza.Part 4: Guidance on use for process impro\'ement and process capability detenninalioll. Standard for In[ormation Technolog. Madrid ISO (2001) Sofnrare Prodllct Em/liation-QlIality Characteristics and Gliidelinesjar their Use. Suiza. Suiza. Amendment 1. ISO/lEe. Directrices para la lI1ejora del desempeJio. Ginebra. ISO (2000a).ENOR. Suiza. 1S0/IEC 12]07. Ginebra.' .' . b!/al7l1C1tion teclmolog.' vocablila/)·. International Organization for Standarization. h?/armation tecllllolog. (1985). International Organization for Standarization. A. ISO/lEC Standard 9126. 1n[017l1C1tion Tecllllolog.~ Process assessmelll assessmelll. Suiza. Indllstry Implemel1lation of International Standard ISO/IEC 12207: 1995 (lSO/IEC 12]07.Sofia'are life-cycle processes. International Organization for Standarization.·. IEEEfEIA 12207. Ginebra.Sofnrare life-cycle processes. Suiza. International Standards Organization. ISO (2002a). Madrid. ISO (2000b). International Organization for Standarization. International Organization for Standarization. ISO (1995b). ISO/IEC 12]07. ISO (2002b). Suiza. ISO ]. . ISO/IEC International Standard ISO 17M. h!formation technolog. Londres. Ginebra. Suiza. EEUU. ISO (2004c). ISO (1995a). Ginebra. Intemational Standard In[ol7nation technolog.Sofnrare Prodllct Em/llation . ISO (1993). Suiza.IS0/IEC 15939: Sofnrare Engineering .' . Gliide to the Sojilrare Engineering Body ofKnowledge. IEEE Computer Society. ISO/IEC 1550-1-3:2003. International Organization for Standarization. International Standard ISO/lEC IS 14102. Englewood Cliffs. LiNE-EN ISO 900 I :2000 Sistemas de gestion de 10 calidad ReqllisilOs.Process assessment pe/fo17ning an assessment.2-1997. Ginebra. Suiza. International Standard lnjarmation technolog. Institute of Electrical and Electronics Engineers.L!re Cycle Management -System L!fe Cycle Processes. Prentice-Hall. Guideline for eraillation and selection of CASE tools. ISO/IEC 1550-1-1:2003. Implementation considerations.Parts 1-6. International Standards Organization. International Organization for Standarization. Madrid.' . IEEE (2004). Suiza.374 CAUDAD DE SISTENlAS Il'·lFOIUvlA.Process assessmelll. Ginebra. ISO IEC 15504 TR2: 1998. International Organization for Standarization./598: /999-2001. Ginebra.' . ISO (2004a). Ginebra. ISO/IEC 15288: b?formation Technolog. Suiza. International Standards Organization. Ginebra.~Sofnrare We cycle processes. Ginebra. ISO (1999). LiNE-EN ISO 9004:2000 Sistemas de gestion de la calidad. International VocablllCll)' of Basic and General Terms in Metrolog.TICOS ©RA-NlA IEEE (l998e). Information technolog.

y Rurnbaugh. International Organization for Standarization. International Organization for Standarization. Suiza. Addison Wesley. AlIImendmelll 2. ISO/IEC J5504-5:2003. ISO/IEC 250-13 S(jfnrare and system engineering Sojhrare product Quality Requirements and Emlua/ion (SQuaRE) -Process for acquirers.SofMare product Quality Requiremellls and Emluation (SQuaRE) Quali(l' model and guide.Sofnrare product Quality Requirements and Emluation (SQuaRE)-Emluatioll planning and managemelll. Suiza. ISO (2005rn). ISO/IEC 2502-1 S(jfnmre and system engineering S(jfnmre product Quality Requirements and Emluation (SQuaRE)-MeasuremellI (jf quality in use. Ginebra.Process assessment. . ISO/IE C 25030 S(jfhrare and system engineering . International Organization for Standarization.Sofnrare product Quali(l' Requirements and Emluation (SQuaRE) Measurement of internal quality. Suiza.S(jfhmre product Quality Requirements and Emlua/ion (SQuaRE) . Ginebra.l (1999). ISO/IEC 25022 S(jfnmre engineering . Suiza. Ginebra. G. Ginebra. Suiza. Ginebra. ISO (2005e).Measurement re.Part 5: An exemplar Process Assessmelll Model. ISO (2005h). ISO (2005i). Ginebra. Ginebra. Suiza.Sofnrare Life Cycle Processes. Jacobson. ISO/IEC 25021 S(jlhrare and system engineering Sofnrare product Quality Requiremellls and Emluation (SQuaRE) . . ISO (2005a).Measurement primitil'es. Booeh. International Organization for Standarization. ISO (2005j). ISO (2005f). ISO/IEC 250-1-1 Sofnmre and system engineering . Suiza.S(j(i\\'are product Quality Requirements and Emluation (SQuaRE)-Qualit)' requirements. Ginebra. International Organization for Standarization. lS0/lEC 25000 Sofnrare and system engineering Sofnrare product Quality Requiremellls and El'aluation (SQuaRE) -Guide to SQuaRE. ISO (2005d). ISOlfEC 25023 S(jfnrare and system engineering . ISO/IEC 25041 S(jfnmre and system engineering . Ginebra. Suiza. International Organization for Standarization. Suiza.Sofnrare product Quality RequiremellIs and Emlua/ion (SQuaRE) -Measuremelll ofextemal quality. Suiza. International Standards Organization. Suiza. Ginebra. International Organization for Standarization. b?/Cmnatian Tecilllologt. ISO (2005b). lnformationtecilllologt.Sofnrare product Quality Requirements and Emluation (SQuaRE)-Processjor emluators.-ivLA BlBLIOGRMiA Y REFERENCIAS 375 ISO (200-le). ISO (2005g). ISO/IEC 25040 Software and system engineering Sofnrare product Quality Requiremellls and Emluation (SQuaRE) -Quality emluation Ol'eITieH' and guide. ISO (2005n). Ginebra. International Organization for Standarization. Suiza. International Organization for Standarization. Suiza. International Organization for Standarization. Ginebra. Ginebra. ISO/IEC 25042 Sojhmre and system engineering~ S(j(ilmre product Quality Requirements and Emluation (SQuaRE)-Processfor del'elopers. ISO (200-lf).Sofnrare product QualiZl' Requirements and Emluation (SQuaRE)-Emluationmodules. Suiza. ISO (2005e). International Organization for Standarization. SofMare engineering-Guidelines for the application of ISO 9001:2000 to computer software. Ginebra. International Organization for Standarization. Ginebra. International Organization for Standarization.~ RA. Ginebra. . ISO (2006). lS0/lEC 25020 S(jfnrare and system engineering .terence model and guide. Ginebra. I. Suiza. International Organization for Standarization. lS0/lEC 25001 Sofnrare and system engineering . ISO (2005k). EI Proceso Unificado de Desarrollo de S(jfhrare. ISO/IEC 90003:2004. Suiza. ISO (20051).. Suiza. lS0/lEC 25010 Sojhrare and system engineering . International Organization for Standarization. International Organization for Standarization.

En A. Springer. McGraw-Hill.OIanagingfor Quality.• (2001) "Data Testing". N. J. B" (2003) "Towards Quantitying Data Quality Costs". Jorgensen. Kiszkumo. Kellner. "Making Measurement Work". Jones. Kim. M. Sofllmre Process Modelling and Technology. 14017nation and So. D.fhmre Technology 48. Nlay 1995. "Preliminary Experience with Process Modeling in the Man'e! Software Development Kernel". (1997). Jarke.hill. (1995) "Metrics Tools: Quality .M.1 88.. 1519.Juran·s Quality Control Handbook. Pp. 175-. A. M" Yassiliou. B. http: \\Ww. (2003). 125-134. M" Y Vassiliou. CrossTalk: The Journal o. G" Peuschel.(the 23 d Il1Iemational Con(erence on System Sciences. pp. "MERLIN: Supporting Cooperation in Software Development Through a Knowledge-Based Environment". "How large are software costs overruns" A review of the 1994 CHAOS report". 4" ed. :V1. pp.vo.. pp.Defect Tracking".) (1988). Kesh. Nueva York. Proceedings o. CWO I ). Kramer. Katayama.) (1995). Ed. 681-689. No. P. . Wiley). Fundamel1lals o. 1.fDefense Sofllrare Engineering.jhmre Engineering Erperimel1lation. "Software process modelling .inHal Hcnmi lmemational COI!terence on System Sciences. ASQC Quality Press. E. A History o.12. Kingsbury.-'\ case study". Vol. finkelstein. y Ylolokken-Ostvold.as 0 (ultimo acceso en Agosto de 2006). ~l y Hansen. Proceedings of'the 22nd . (1995). (1989) "A Hierarchical and functional Software Process Description and its Enaction". N. (ed. -I. :Vlassachusetls Institute of Technology. J.(Data Warehollses. y ~'Ioreno. R. "Non-Intrusive Assessment of Organizational Data Quality". Juristo. Jin y Embury (2001). pp. and B. 37. Crosstalk The Journal 0. Proceedings o/Second Con(erence on In/iJl7nation Quality. (2000). S. (ed.\ktrics. (1989). -15. Basics o/So. Research Studies Press Limited (1.afmikrosstalki frames. Strong. lnjiJl7nation and SO(lH'are Technology.stsc. 69-76. "Data Warehouse Quality: A rcview ofthc DWQ Project". ASSE 200 I Proceedings of'SADJO. W. 297-301. M" Lenzerini. pp. "Evaluating the Quality of Entity Relationship Models". Addison-Wesley. G. editors. Juran. Nuseibeh. Journal of Object Technology. Metrics and Models in Sojhmre Quality Engineering. Kan. Vol. 2. T. D. M. C. Junkermann. Proceedings o( the 11th II1Iel71ationai COI!ference 0/1 Sojhmre Engineering.. Juran. (I (90). B" Schafer. Hawai. 2" ed. (19911. 8-28.July-August 2003.H. "Software process modelling support for management planning and control". Milwaukee.mre Process. (2006). Y.376 CAUDAD DE SISTE~lAS INfO~vL'\TICOS '~~~-MA Jarke.f'the First International Conjerence on Sojr. Boston. K. (2002) "Information Quality Benchmarks: Product and Sen'ice Perfonnance". y Vassiliadis. Proceeding o.. Kaiser. y Yankclcyich. Communications ofthe AC\fApril 200:Ylol.!\1. y Walt: S. 398-411. y Sokols!"·y. M.( Defense Sojhmre Engineering. 1. pp. S. Proceedings of the Sixth Il1Iernational Con(erence on In/ormation Quality. (1994). Y. y \Vang. Kahn. G" Barghouti.asp'?uri= I 995:05. . (2003). Cambridge. Kellner.. noA" Pp. Kluwer Academic Publishers.. Woo y Choi. y Dawood.

(2003) "Principles of Survey Research. Kitchenham B. S. UK. Technical Report TRlSE0401. ACM SIGSOFT. J.. 58-76. (1996). Blacbvell Business Publishers. (1995). B.. S. 12-14. (2002c) "Principles of Survey Research. Lavazza. O. 28 N°8. y Pfleeger. FebnlalJ' (2001). Kitchenham. Finland. 82-95. S. Bicego. 2. AC\I SIGSOFT. 24-27.. (1995). n.4.. SJ.are Engineering Notes. pp. Kuvaja.©RA-MA BIBLIOGRAFiA Y REFERENCIAS 377 Kitchenham B. ACM SIGSOFT. S.L. "Design Metrics in Practice".. Simila.. Jyvash:yla. Afedical Devices and Diagnostic Indusfl)..2002. y Sindre. y Pfleeger.. D. IEEE Computer 34. y Rosenberg. Soft. Software Engineering Notes. y Pfleeger. (1990).1990. Part 6: Data Analysis".. y Pfleeger. enero/febrero. pp. S. (2004) Procedures for Peifonning Systematic Revie. pp. S. pp. 2nd edition.. (2002) "Principles of Survey Research. I. 103-108. Kitchenham. (2000) "Providing Automated Support for the GQM Measurement Process". Technology.. pp. 28. P. YLinkman.. Addison-Wesley. "Towards a Deeper Understanding of Quality in Requirements Engineering". Vol. 929-943..304310. (1990). 32. So/tlmre Engineering Notes. Part 3: Constructing a Survey Instrument". G.. y Fenton N. 242-259. S. Part 5: PopUlations and Samples". Kitchenham. (1999). Kitchenham B. 27. Kitchenham. (2002a) "Principles of Survey Research. CAiSE 1995. (2002). 2.12-21. 16(12). P. 1. A. 27. y Linkman.1990.. Krause. Oxford.2003. (2001) "Knowledge Management: Ready for Prime Time?". pp.. Jones. pp. IEEE SO/Mare 17(3). pp. (1999) The Rational Unified Process. Part 4: Questionnaire Evaluation". G.. IEEE Software 20(1). 2002. AC\1 SIGSOFT. Vol. "Towards a Framework for Software Measurement Validation". 32. L. D.. (2002b) "PrinCIples of Survey Research. n. Keele University. Vol. B. Pickard. pp. B. So/tlmre Process Assessment and Improvement: The BOOTSTRAP Approach. K.. vol. L. 1. EI Emam. B.4. 17-20. 18-20. "Has quality management any effect on qrtality?-Analysis of quality management by a nonlinear model". vol. Kitchenham. (1994). vol.. B. Kitchenham.s. 1. No. 20-23. 27.2002. pp. pp. (1994). Koch. IEEE Transactions 011 Software Engineering. Inf Soft. Kosar. ACM SIGSOFT. Pfleeger.. An Infl·oduction.. Part 2: Designing a Survey". Kitchenham.304310. SJ. Lindland. pp. n. 27. n. "Software Quality: The Elusive Target". y Pfleeger. 3. B. So/tlmre Engineering Notes. Technology.. "Developing a Framework to Manage Data Quality in Healthcare". 2002. Kruchten. 721-734. "Software: A maturity model for automated software testing". Kizanik. Proceedings o/the 2000 Conference on In/onnation Quality. 20-24. n. Inf Soft. pp. y Pfleeger. Pflegger S. Krogstie. 5. Maga::ine. Kitchenham. 21(12). M. B. G. y Saukkonen.. P. L. "Design Metrics in Practice". S.. pp. Lawton. IEEE Transactions o/So/tware Engineering. B. vol. Hoaglin. Kreutzberg. "Preliminary Guidelines for Empirical Research in Software Engineering". Software Engineering Notes. (2000). . vol. No. Proceedings o/the Fourth Conference on In/onnation Quality ICIQ' 1999.

fAIS 4 (14). N. y Yost. BOE num. 1997. Leonowich-Graharn. Y Rus. y Cheng.• Grunninger. Ley Organica 151l999. March-April 2003. Lindstrom. (2003) "Lessons Learned from Building Experience Factories for Software Organizations". (1994).• Jin. y Rombach. Y Wang. L. 1v!acDonelL S. R. Wang. Object-Oriented Sofl1mre Metrics: A Practical Guide. Infol7nation & Management . Proceedings of the Eigth International COf!ference onI'?fol7nation Quality (ICIQ-03). 679-708. pp. A. G.6.fEmpirical So. Loshin 0 . Y Willshire. (2004). pp. Wissensmanagemelll 2003: pp. pp. F. vol. (2002) "AIMQ: A methodology for Information Quality Assessment". Panorama de la Industria del So. vol. Shepperd y PJ. J. "Repeatable Software Engineering Experiments for Comparing Defect-Detection techniques". 133-150. 133-146. "Quality Characteristics for Software Architecture". Y. "The PIF Process Interchange Format and Framework Version LT. 2 (2002). Sindre G. Luftman. No. "A data quality framework for small business". B. Lind\·all. Li. (2002) "Evolutional Data Quality: a theory-specific \·iew". JOllmal o. "Mayer & Bunge Informatica LTDA".. Lund University. (1998). 1(3). The Knowledge Engineering Review. "The design and Implementation of a Corporate Householding Knowledgement Processor to Improve Data Quality". Prentice Hall. LUTEDX(TETS-5522)/I-72/(2004) & local 27. pp. 23 n° 2. Ley Orgclllica de Proteccion de Datos Personales. K. Losavio. Nueva Jersey. I. Li. (1994).. 42-49. Lon.(1993). 99-107. (2003). "Object-Oriented metrics that predict maintainability". Liu. pp. 8. Communication o. Madnick. y Chi. A. in Joul71al of Object Technology.• Tate. pp. 13. http://www. H. Lee. S. M&G (2004).N. W. Kahn. Sallis. 2. Morgan Kauffman. y Solvberg A. W. pp. 244-277.jOLfi11iisslles/issue 2003 03/article" (ultimo acceso en Agosto de 2006). Jou17lal ofSystems and Software".• Malone. Jou/7/al o.!'v!ATICOS ©RA-MA Lee. "Metrics for Database Systems: All Empirical Study". pp.• Strong.. vol. C. Y Henry S. F. IEEE Trans. 2. Fourth International Sofilmre Marics Symposium. pp. 20(3). 41-69. R.. Englewood Cliffs. December 14. 292-304. 239-244. Xian. L N. (200]) EllIe/prises Knowledge Managemelll: The Data Qualit)· Approach.fJfanagemelll Infol7lJation Systems. 59-63.. BrasiL 2004. pp. on Software Engineering.W . San Francisco (California). 91-120. (2003).. Master's Thesis. II. J. no. M. Lindland 0. Vol. pp. IEEE Computer Society. Department of Communication Systems. 298. H.f. Proc. T. . X. y Ramdane-Cherif. (1996). (1987) "An Empirical Study of Software Metrics".1999.. MJ. Lorenz M.G. M. 0 . P.1987. IEEE Software. Le\y. "Understanding Quality in Conceptual Modelling".378 CAUDAD DE SISTEMAS INFOR.. Y. n° 2.thmre Engineering. A Sofl1mre JHeasurement Case Study Using GQJI. Proceedings of the Seventh IllIernarionai COI!terence on b!formation Qualit)· (ICIQ-02). MJ. 111-122.• 40. L. y Kidd J.Metrics '97.thmre en Larinoallllirica.. Chirinos. (2004). 13(1). Albuquerque. (2000) "Assessing Business-IT Alignment Maturity".

R.mre Engineering. D. Taz Daughtrey Editor. "Organizational concepts and measures for the evaluation of data modelling". Programma di Ricerca Cofinanziato dal MIUR. Proceedings ojthe 15th JllIemational Conference on Sojt. 1. Meredith. Scannapieco.. (2003).VI.• Henderson-Sellers. 145-154. Addison-Wesley. Technical Report CMUiSEI-2000-TR-015 ESC-TR-2000-015.015. McBride. Catarci. (1996) IDEAL: A User's Guidejor Sojnmre Process Improl'elnelll. Ministerio de Administraciones PlIblicas. Layman. En Meersman. P. (2001). 10. McFeeley. C (2002). C (2002). New Yark. L Card. "Empirical validation of metrics for UlvIL statechart diagrams". E. "Managing with Metrics: Theory into Practice". :VlcDermid. P. (Ultimo acceso Agosto de 2006). McLeod.. 5th International Coi?ference on Ellie/prise Information Systems !lCEIS 03). L. 1996.'Y: McMillan Publishing.BffiLIOGRAFiA Y REFERENCLA. Ojthe 11th Asia-Pacific SojMare Engineering Coi?ference (APSEC04). Martin. McGarry. 2nd Euromicro COI?ference on SojMare Mailllenallce alld Reengineering. LYCS 2519. C y Bohner. Marchesi. Ed. Idea Group Publishing. 4-13. "Sustaining Best Practices: How Rt!al-World Software Organizations Improve Quality Processes". (Eds) CooPIIDOAIODBASE 2002. (1990). Virgilito. Richards. T. McCall. y Walters GF (1977) FactO/'S ill sojnmre quality. "OOA Metrics for the Unified Modeling Language". ivlekelburg. 67-73. . Y Batini. Z.. Butterworth Heinemann. "Project Management Capability Levels: An Empirical Study'·.. 1.. Sojnmre Engineering Reference Book. 308320. Batini. CAF . "Total Quality Management in the Public Sector". T. 202-211. pp. Pp. Managemelll InjomlCltion Systems. (1993). III: US Rome Air Development Center Reports NTIS ADiA-049 014. in Developing quality camplex databases systems: practices.. pp. Proc. Dean.. pp. (1993). Becker S. S. AIetodologie e Stl1lmenti per la Qualita dei Dati in Sistemi Illjormati~'i Cooperath·i. D. Software Engineering Institute.dis. McCabe. II. Direccion General de Inspeccion. Practical Sojtware AJeasuremelll. IEEE Computer Society. R.VLA. ~vlissier. j\..? (2003). 2003. The Team Sojnmre Process (TSPS): An Oven'iew and Preliminary Results oj Using Disciplined Practices. Chapter I.. DLl. 195-213. F..A: Descriptioll a/the Gelleral Rejerellce Scellariojor All b?/imllatioll Quali£~' Management Frallll?\\'orkjor Cooperath'e IlljomlCltion Systems. http://www.1. pp 486-502.. 87-95.it!-dg. y Zowghi. B. 1998. Sojnmre Quality Projessional7 (3). D. Madrid. (2004). y Tari.C (2002). 2. (1998). Simplificacion y Calidad de los Servicios. (1991).uniromal. . 055. D. "Managing Data Quality in Cooperative Information Systems". "Model based process assessments". M. Vols I. pp.S 379 Maier R. 1. Miranda D. pp. National Producth'ity Rel'ieH'. A.. 2003. 1-27. Genero M. report CMU/SEI-96-HB001. B. (1976). Inst. Clark. Baldoni. (2002). Objecth'e b?formationjor Decision Makers. y Hall. "A Sofuvare Complexity Measure". Sofuvare Eng. American Society for Quality. McGowan. pp. D. (200 I). techniques and technologies.• Jones. M.K. 1. tech. y Piattini . Mecella M. (2005). C. McAndrews. A. 2002.El Marco Comlln de Emluacioll. R.. IEEE Transactions on Sojnmre Engineering. In Fundamental Conceptsjor the Sofnmre Quality Engineer. B..

3. Enterprise Architecture Maturity Model. V. (2000). S. Disponible en http://www. The IT Service Capability Maturity lvfodel. Manchester. "Expanding Organizational Excellence: The Interplay between Data Quality and Organizational Performance".orllinotlssues/EAlEA.onvdoc!itscmm123-0.cs. c. G. Volume XI. (2002). Fermlndez.. Vol. 25-29.m'(}biblioteca/manualesimoprosofiiV%201. Motha. W. ISBN: 3540-30018-X. F. Web biformation Systems Engineering . National Association of State Chief Financial Officers: LeXington KY.. D. "Software Measurement". Proceedings of the 13th IllIemational COliference on Canceplllal Modelling (ER '94). "Improving the Quality of Entity Relationship Models-Experience in Research and Practice". Moody D. Su Ramos. (2001). (eds). The Data Administration Newsletter. F.. 35. University Press of America. Lopez.L.. Version l. 16.. (1994) "What Makes A Good Data Model? EValuating The Quality of Entity Relationships Models". 3.. Flores. M. Garcia. M.. En Workshop on Web biformation Systems Quality.. Release L2+ 3-0. G. M. Shanks G. Y Shanks G. Singapore. M. Robert Seiner: Pittsburgh PA. 1994. Singapore. "A Reusability model for Portlets". 251-271. (2005). 2002. G. M.... Boston.. Wiley). Orlando: USA. Mullins. Vol.lania. (1998). C.. Dispouible en: http://www..pdf (Ultimo acceso en Agosto de 2006). 239-276. Quintanilla. Orozco. "Calidad en Procesos de Software: Ejemplo de TSP·'. y Piattini. pp. NASCIO (2003).. (1998). December 14-17. pp. (2002). C. July 22-25. (2002) The quality Remlution A History of the Quality movement. Ruvalcaba. Mouradian. y Viktor H.. Niessink.tdan. pp. and B.pdf(ultimo acceso en Agosto de 2006). c. Piattini. Version 1. . O. 255-276.7. noviembre 16-19. Moody D. editors. Disponible en: http://www. The Netherlands. H. Niessink. Ok1aba. "Oikos: Consuucting process-centered" SDEs.itservicecmm. Planning Report 02-3. Finkelstein. pp. Kramer. (1994). 21-32. Inglaterra. Intemational COliference on Systems.. Proceedings of the Seventeenth Intel7lational COl!ference on ConceplZlal Modelling (ER '98). pp. YAmbriola.pdf(ultimo acceso en Agosto de 2006). Proceedings of the Seventeenth Intel7lational COliference 011 Conceptual Modelling (ER '98). En Handbook ofSoftl\'Ore Engineering and Knowledge Engineering. y Darke P. Moody D. (vbel71etics and !lifonnatics (SCI'2001). pp. Esquivel. 1. "The capability maturity model from a data perspective". N1ST (2002). Moraga.3 Draft. Oktaba. M. A. van Vliet.comli003fe04. 1: Fundamentals. Rivera.l Mayo 2003". "Metrics For Evaluating the Quality of Entity Relationship Models".TICOS ©RA-MA Montangero. Program Office Strategic Planning and Economic Analysis Group. 94-111. LCNS 3807.3.380 CAUDAD DE SISTEMAS INFORl'v!A. (2002). Martinez. Quality Progress. (2002) "Organize your quality tool belt". (2003).The Economic Impacts of Inadequate In/rastl1lcture for SofMare Testing. F..A. 213-225.!%20 DocumentoBase . Clerc. No. pp. Y.. New York (USA) 20-22 November 2005. Paz. Dispouible en: https:!!www. Morasca. "National Association of State Chief Financial Officers". H. (2002). 60-65. En Calidad en el desan'ollo y mantenimiento del sofMare. M.uu.. F. Diaz.MM. e Ibargtiengoitia. Nuseibeh. Research Studies Press Limited (1. "Sofrware Requirements: Functional & Non-functional Software Requirements".WISE 2005 Workshops. Software Engineering Research Centre: Utrecht. M. Okes. Disponible en: http://\Vww. H. En A. Calero.nl!wiki/SwaiWebHome (Ultimo acceso Agosto de 2006). A . 1. National Institute of Standards & Technology. V. Software Process Modelling and Technology.htm(ultimoaccesoAgostode2006).nascio. "Modelo de Procesos para la Industria de Software MoProSoft. pp. July 2002.

A" Jeffery. A (1998).1.L. 1'01. IEEE Computer Press. (1998).. Part I: Turning Lemons into Lemonade". (eds. Prentice-HalL . pp. pp. Proceedings of the 9th Il1Iel71ational Conference on Software Engineering. 16-18. Ed. K. Reading. OMS (2004). Pfleeger. Curtis.leH SIGSOFT.. Paulk. (2001). Monterey. Olson. Aurum. Park. A. "Evaluating an Approach to Sharing Software Engineering Knowledge to Facilitate Learning". y Chrissis.mit. (1999) "Active Database Management Systems". 1. Data Quality: the accuracy dimension. San Francisco. (1996). C Weber. Pfleeger. G" D'Ambra. 66-71. pp. 2-13. Handbook CMU/SEI-96-HB-002. Agosto 1996.) Berlin. 25-16. C (2003). y Kitchenham. I' 1. Pittsburgh. (2002).. 345-355. (1994) "Systems Approaches to Improving Data Quality". OMG. W. Onnan. R. "Acquiring experiences with the modelling and implementation of the project lifecycle process: the PMDB work". ''Testing Maturity Model". ParasuranJan. 6. The OMG. M. En Jl. Joul7lal ofRetailing. Olsen. Software Engineering Institute.. Agosto 1994. S . Fwure oj'Sojhmre Engineering. 31. VA.eduitdgm\vww!papers/94/94-05. (200 I) "Principles of Survey Research..2001. A. "Assessing Software Measurement". y Berry. y Wang. L (1987). Sojhmre Si::e Measurement: A Framework for Counting Source Statemel1ls (CMU/SEI-92-TR-20). CA. B. P. Vol.©RA-MA BIBLIOGRAFiA Y REFERENCIAS 381 Oliver. L. Pa. (1992). Storey. 26. Software Process Engineering Metamodel Specification. y Shu. "Software Processes Are Software Too". Addison-Wesley. Communication ofthe ACM. The Capabili(\' Maturity Model Guidelinejor Improt'ing the sojilmre Process. March 1987. No. 1995 Pease. mi. R. (Spring). 1. Object Management Group. Software Engineering Institute..htrnl (lJltimo acceso en Agosto de 2006) Orr. E. http://web. So/hmre Engineering Joumal.A Guidebook. Core Plan Representation.Modeling Language Specification. Penedo.M . Porte. 12-40. 2' cd. M. Perry. S()ft\mre Engineering Notes. September 1992. L. Anthony Finkelstein. Springer. pp. (2003). CA: Morgan Kaufmann Publishers. W . Wohlin. OMB Entelprise Architecture Assessment Executive Office of the President. IEEE S()fnmre. (1997). Goethert. Handzic. C. pp. adopted specification. pp. version 4. ACM. D.fanaging Software Engineering Knowlegde.. LL (1988): "SERVQUAL: A Multiple-item Scale for Measuring Consumers Perceptions of Service Quality".. L (2000). V. 64. O. Paton. Object Management Group. y Staal. M. 259-274. K. 6(5). y Diaz. (200 I).. Carnegie Mellon University. M. R. Pfleeger. Software Engineering Theory and Practice. S. Osterweil. y Van Toonn.0. OAIG Unified . n. Zeitharnl. Empirical Studies ofSofnmre Engineering: A Roadmap. Park. Goal-Drh'ell Software lvfeasuremel1l . ACM Computing SUlTeys. pp. 63-103. y Votta. B. \'ersion 1. K. S. . Florac. 41 (2). TIle Office of Management and Budget. 1999.. Mass.4. C (1991). March!ApriL pp. H. EPIC meeting on Software Improvement and Quality Testing. (1998) "Data Quality and System Theory".

The Data Modelling Handbook. 42( I). Jolm Wiley & Sons. In{ol7nation and SO/l1mre Technology. 243-258.. Digital Press. 35-46. IEEE Sojhmre.. Raffoul W.ore. \I'ithin budget. USA. IEEE. 79-97. 14(6). S. '80-86. (2001) Data Quality: The Field Guide. R. Genero M. P. y Wang. SO/l1mre Quality Joul71al. Madrid.). (2002). Model. pp. e. "Providing customized assistance for software lifecycle approaches". Software Engineering Institute. (1994). No.382 CAUDAD DE SISTEMAS INFOIUv1A. y Genero. CMMI 1. M. Prentice Hall.. H. T. "Leveraging Global Resources: A Process Maturity Framework for Managing Distributed Development". Lee. Reingruber M. Genero M. 1. 2001. Redman.!infoidefault. y Sarkar.e. M. (2002). Genero. Krihsnan.1 Ow"iew. y Gregory W. Pohl. Redondo. L. Reynoso L. K. 2004. J. . (2004) "Measuring OCL Expressions: An Approach Based on Cognitive Techniques". April 1994. (2002) "Data Quality Assessment". Project Management Institute Communications. M. "Estado del Arte en la ISOI1EC 15504". Piattini. 749-757. Inrol7nation systems. and Calero e. y Kompalli.Reliable soJllmre on time. pp. Piattini.. Calero. Madrid. AllIilisis y Diseiio de Aplicaciones Una perspectim de Ingenieria del Software. N. 22-26. Calero.2001. G.. Communications a/the A CAl. A best-practice approach to building quality data models. D. CS Press. Piattini ivl. e. IEEE Transactions on SO/Mare Engineering. y Dedene. Ramanathan. Disponible en: htm:iitechupdate. Vol... M. Chapter 5 en l'vfetrics/or SO/Mare COl1ceptual Models (Eds. (2004). Calidad. M.e. Cervera. NASA Software Engineering Conference: Carnegie Mellon. Inc. R. 45.pmi. Y.zdnet.. 1991. pp. M. pp. New Jersey.4. 1996. McGraw-Hill. PMI (2004) A Guide to the Project Management Body 0/ Knowledge. Raffo. http://www. 9. W. Ra-Ma. (1992). (2000). 19(3). (2001) "Table Oriented Metrics for Relational Databases".html#lc\·cl I (ultimo acceso en Agosto de 2006). (2003). (1988). (1999). Putnam. J. Boston. L. Pressman. Septiembre 2004. Calvo Manzano.ooolC 14 I79%2C2 85 I971-2%2COO. Ingenieria del Sojiware: un el!foqul! practico. y Fernandez. (2002) In{ol7nation and Database Qualit)'. UK. y Myers.S. Meta Group: Stamford CT. M. L. G. Boston. April2002Noi. (2005). Poe Is. y Piattini M. M.comlechupdatc!stories/[nain . Kluwer Academic Publishers.. (1996) Data Qualify/or the Information Age. (2001). Imperial College Press.. L. Ramasubbu. (1994). Measures Jar E>:cellence . 2' edici6n actualizada y ampliada. Elements a/Software Process Assessment and Impro\·ement. In/ormaticas de Gestion Piattini. Pipino. 'The three dimensions of requirements engineering: a framework and its applications". "ivlodelling software processes quantitatively and e\'aluating the perfonnance of process alternati\·es". y Kellner.TICOS ©RA-MA Philips. pp. The Outsourcing Maturit). T. Redman. Artech House Publishers. 2004 edition..asp (ultimo acceso en Agosto de 2006). "Distance-based software measurement: necessary and sufficient properties for software measures".

7-14.cl11u. Schuene R . Schekkennan. Proceedings of the Sel'enteenth International COI!ference on ConceplZlal Modelling (ER '98)..lor Systems Engineering. (2002). M. 7(3). c.cmu. c.sei. n. Version 1. (2002) Research Methods for Business Students. Keele. pp. A. y Ray.. J. IEEE Computer Society. http: www. C. Springer.C" Lujan-Mora. (eds. Proceedings (jlthe Conference on Empirical Assessment in Sofnrare Engineering (EASE 2002). (1971).eduioublications!documents02. Saeki. M. Singapore. html (Ultimo acceso en Agosto de 2006). "Design measurement: some lessons leamed". CMU!SEI-2001-HB-00I.SS. Reallmrld research: A resourcefor social sciemists and practitioners-researchers.1 CMAflSM . Knutilla.I: Method De.g. 0/ Schramm. r ·ersionI. Blacbvell. VI. Proceedings of the 26th Annual Intemational Computer SofMare and Applications COIiference (COMPSAC'02)...entemrise-architecture. rersion 1. "A Robust Process Ontology for Manufacturing Systems Integration". Lecture Notes in Computer Science 3084. c. Washington DC: The Academy for Educational Development. K. (2002) "Validating Metrics for Data Warehouses'·. R.. P. PrenticeHall. (1993).). "Effective Experience Repositories for Software Engineering". A. Rombach. A. En http://\\"\\w. Trujillo. l' von Hunnius. Standard C\JAfI Appraisal :\Iethodfor Process Improvement (SCAMPI).reports02trOO". J-P. (1998). M . (2003). Riga (Letonia) Agosto 1004.Business Process FramL7Jmrks. the 25'" Int. Saunders.IEEE SofMare. 506520. Maui (Hawaii). ARlS.'RA-MA BIBLIOGRAFiA Y REFERENCIAS 383 Robson. Calero. 3rd Edition. Reino Unido. l' Piattini. pp. D. (2003) "Embedding Metrics into Infonnation Systems Development Methods: An Application of Method Engineering Technique". Sclmeider. The Capabiliz\' Maturiz\' Model: Guidelinesjor bnpro\'ing the So/nmre Process.edU!publications'documents'02. SEI (2002) Capability /'v/alZlrity Model IT Imegration (CMMP!). SEI (2004). Oxford (England). Institute for Public Enterprise Architecture Development. 1. 374-389 Satpathy. 379-384.sei. (1998)./inition Document.lPPDSS. .. M. pp. M. abril 2002. y Stima. SEI (1995). 17-25.N.y Pianini. Proc. J. Lewis. pp. l' Rotthowe T. Calero. W. "The Guidelines of Modeling-An Approach to Enhance the Quality in Infonnation "'·10dels". "A Typed Generic Process Model for Product Focused Process Improvement". Software Engineering Institute. C~iSE 2003: Pp. I ) http://\\"\\w. Notes on case studies o/instl1lctionalmedia projects (December ed. A.1 CMAfI (CMMI-SDSHilPPD. Proceedings ofthe 2nd International COI!ference on Engineering Design andAutomation. pp. Serrano. 8-10. Sojhmre Engineering. y Harrison.I) Staged Representation CA/UISEl-2002-TR-012 ESC-TR-2002-012. W. M. H. M. (1998). Person. Scheer. SEI (2001).'i'02trOO". S. 240-254.info (ultimo acceso Agosto de 2006) Schlenoff. pp.).reDort. S. (2003) "Extended Enterprise Architecture Maturity Model (E2AMM)".html(ultimo acceso Agosto 1006). Integrated Product cnd Process Del'elopment and Supplier Sourcing (CvlMI-SE SW. C04 on Software Engineering (/CSE·03). (1990)..4iSE 2004). 16'" Intemational COIiference on Admnced In/ormation Systems Engineering (C. Serrano. y Thornhill. (2004) "Empirical Validation of Metrics for Conceptual Models of Data Warehouses". Capability MalZlriz\' Model Integration (e\/MI).

World Scientific. 53-60. pp. 1. Joumal Database Mallagement. YKumar. pp. In N. O. 298-303.. pp. Strong. IEEE Computer August 1997. D. (2002) "Defect Prevention: The road less Traveled". D.W . 103-110. (1998). (I 997b) "Ten potholes in the road to information quality". 38-46. y Wang.). 1998. Standard Metamodellor Sofl1mre Del"eiopment Methodologies. 14-32. Queensland University of Technology. (2005). G" Wang. H. Brisbane. Standish Group 1l1ternational. y Foshag. K. NFP..standishf1roup. y Lake.P. M. A. Shanks. http:!. 1-16.. Carver. (1999) "Information Modeling and Method Engineering: A Psychological Perspective". IEEE CS Press.. Travassos. (1997) "Quality in Conceptual Modelling: Linking Theory and Practice". (1999) "Quality Today: Recognizing the Critical Shift". Conradi. y Basili. Y. Joumal olDatabase Mallagement. pp. pp. P. (2000) "An integrative framework for IS quality management". 1. 1993. Lee. Shewhart W. (2003). ultimo acceso en Agosto de 2006) Standish (2001) Extreme CHAOS D. D. S. (1993) "A Visual Language to Describe Collaborative Work". 184-206. pp.PDFpaf1es /extreme cl1aos. y Heights. I.1 99-21 I. 85-117.D (2003) "Quality Characteristics for Software Components: Hierarchy and Quality Guides".. 10(4): pp. . Compollelll-Based Soll1mre Quality 2003: pp. 1. En http://www. Taz Daughtrey Editor. R. 14(4). M" y Wang. (2000) "IP-MAP: Representing the Manufacture of an Information Product". "An Empirical Study of Industrial Requirements Engineering Process Assessment and Improvement".M.. Standards Australia (2004). Proceedings of the 1993 IEEE Symposium on Visual Languages. Lee. (I 997a) "Data quality in context". Y. Pacific Asia Conlerence ollinlol7nation Systems. 805-814.html (ultimo acceso en Agosto de 2006). Silverman. (1998) "Measuring Legacy Database Structures". Proceedings olthe 2000 Conference 011 Inlol7nation Quality. Sneed. Simao. Lecture Notes on Empirical Soll1mre Ellgineering (pp.. 39-84).software. Juristo y A.. Proc. A CM Transactiolls 011 Soll1mre Ellgieering alld Methodology 14 (I). c. G.M .standards. Y Belchior. A. R. Ziad. "Replicated Studies: Building a Body of Knowledge about Software Reading Techniques". Systems Ellgineering Standards alld Models Compared Soltware Productivity Consortium. pp. drafi spec[ticatioll AS4651-2004 fhttu:iiwww. 40 (5). ComlllUllications of ACM 43(9): pp.A.. F.Y.aul. 1998. pp.com!samole research.. 1. American Society for Quality.C. Maldonado. In Fundamental Concepts lor the Soll1mre Quality Engineer. Smith. Coombes. Communication of the ACM. FESM~ 98. Quality Progress. pp. G. 99-104 (2000) Swenson. K. Nueva York. "Managing Data Quality in Dynamic Decision Environments: An Information Product Approach". Van Nostrand Company. y Darke. 1.Y. 1. Economic Control olQuality olManulactured Product.M. (193 I). R.. May 6-8. R. Sommerville..S. Shankaranarayanan. Proc 01 The Europeall Soll1mre Afeasurement Conference. Shull. Antwerp. y Ziad.or!lipub!extemalpapetS i 9804-2.orf1. February.). R.W" y Wang. Sheard. Siau. Moreno (Eds. Singapore. y Ransom.Y. Van Huysduyllen and Peeters (Eds. A. (May).D. 44-50 (1999). R. G. Stylianou.\\·ww. V. (2003).384 CAUDAD DE SISTEMAS INFORt'vlATiCOS ©RA-MA Shankaranarayanan. R.pdf(ultimo acceso en Abril de 2006) En Strong.

Selby. Tiwana. The Goal/Question/Metric MetllOd. y McNairm G. 246-258. Departamento de Ingenieria. L. A. Quality Press. Taylor. y Wang. 86-95 Wang. H.1999. R.. van Solingen. Alodelfor the Telecom Product Developmelll and Support Process Capability. y Falcao e Cunha. UK Department ofTrade and Industry and BCS. Wisconsin. (2006) Estadistica 2: resllmenes Idep!mate f estadistica2!estadistica_2. Boca Raton (Florida). Caise 2005. Y. B.) (2006). pp. Cuenca. Kon. Vilar.. van Solingen. Belz. Wileden.. Wang. R. Communications ofthe AC. y Madnick S. (eds. Storey: V. Bell Canada. y Berghout. y Wu. P. L.6i7. B. y Firth. Wolf.B.. "SPICE For Small Organisations". "Foundations of the Arcadia Environment Architecture". Guide to Sofnmre Quality Managemelll System Constl1lction and Certification using EN2900J. Tesis Doctoral.. "A framework for analysis of data quality Reseach'·.).. Topaloglu.\J (CACM). Wang. Computer Engineering Department Ege University. Pastor... (1988). . (2004). TickIT Project Office (1992).. 1. (2005).·. Tumey. Japan: Central Japan Quality Control Association. (1993) "Data Quality Requirements Analisys and Modeling" . Second Edition. O. y Berghout E. LNCS 3520. Turkey. Tague. Young.H 1'014112) pp. (2001).. Vizcaino. R. Austria. Issue 2... Negaya.. R.La Mancha. J. pp.. Hoorn. C.. "Integrating Goal-Oriented Measurement in Industrial Software Engineering: Industrial Experiences with and Additions to the Goal!Question/Metric Method (GQM).. de los capitulos.Vinth International Conference ofData Engineering. (eds. 39. OsterweiL L. practical techniques for building a Ia/owledge management system. M.©RA-MA BIBLlOGRAFiA Y REFERENCIAS 385 Taguchi G. E. Milwaukee. Benevento (ltalia).. Gestion del conocimielllO en ingenieria del Soft. Grove. (2003) Six Sigma Software Developmelll. Van der Raadt. (II). . Y. R. BornovaIzmir. F. 9. February 1998.F. Universidad del Sannio. n1e Quality Toolbox.are.es Visaggio. Universidad de Castilla. England: McGraw-Hill International (UK). Auerbach Publications. 58-65. A. SofMare Process Improvement and Practice. J. A Practical Guide for Quality ImprOl'elnelll ofsofnmre Del-e!opment. N. Wand. ISBN 007 709553 7.. (2005): Empiricall'alidation of Pair Programming. N. Clark. y Van Vliet H. c. (1998). 1..udc. 23-31. IEEE Transaction on Kno\l'ledge and Data Engineering 7(4). (2000) The Knowledge Managemelll Toolkit. Proceedings of the Third ACM SIGSOFTISIGPLAN Symphosium on SofMare Development Ent"ironments. (2005). c. Trillium Team (1994).R. M. London. Prentice Hall PTR. (1996) "Anchoring Data Quality Dimensions in Ontological Foundations". A. (1995). Viena. R. (1979) Imroduction to Qtfline Quality COlllrol. Y Piattini. R.'oceedings Sel'elllh Intel7lational sofnmre Metrics Symposium (METRlCs'OI). http://\\'\\w. Communications of the AC.htrn (ultimo acceso Agosto 2006). pp 623-642. 357-371. Pp. pp. A. "Alignment and Maturity are siblings in architecture assessment'". (1999). Assessment ofReuse Maturity. (1998) "A product perspective on data quality management". 670 .0. Tayntor. R..

I. Zelkowitz M. 5. Vol. 2002: Disponible en acceso en Agosto de 2006). . (2001). Disponible en: http://www. Westcott. Inc. Y Lee. Kluwer Academic Publishers.htm (ultimo acceso en Abril de 2006). pp. S. Software Engineering Processes: Principles andApplicatiollS. (1990).pdf(ultim0 Xu. ACSiIEEE International Conference on (. (2003). Westcott and Associates. State of Utah: Salt Lake City UI. 365-379. B. Proceedings ofthe First Intemational Conference on System Development Environments and Factories. htto: !www. Version 3. Wallace. CI: R. G.23-31.fMare Engineering Education and Training (CSEE&T 2000).. Wang. (2004). ZU5~ Complller Systems andApplicalions H. Object Oriented Design Measurement. IEEE Computer Society Press: Los Alamitos CA. pp. "The effects of 'Pair-Pressure' and 'Pair-Learning' ". Erperimel1lation in SofMare Engineering: An Introduction. y Rocha. Whitmire.n. Old Saybrook. W. (1998). K. 1998. M.\/ethods. Y. analysis.~ 2001). Massachussets (USA). "Modelo de Referencia para Melhoria de Processo de Software: uma abordagem brasileira". B. "Would organization size matter for data quality". Septiembre 1998. P. C. 2-1-26. Case Stuc(l' Research: Design and . H. A. y Wessh'..·jfCCs. YKing.. Proceedings ofthe 16 th Il1lernafional COI!ference 011 Software Engineering. A Framelmrk ofSojhmre MeasuremellI. (1997). pp. R. "Evaluating software complexity measures". Proceedings ofthe QUA TIC 2004. K.I. (2003). pp. "Measurement With a Focus: Goal-Driven Software Measurement?". y D. Weyuker E. Weber. Williams. (2000). Regnell. M.capQ:emini. "Iaxonomy of Process Modeling Languages". Y Kessler B (2000). (2003). (1994). D. pp. S. pp. Widdows C y Duijnhouwer. 1-10. F. TIlOusand Oaks.386 CAUDAD DE SISTEMAS INFORMATICOS ©RA-tvlA Wang. Host.59-{j5 Windley P. (1998). "Experimental models for validating technology". Yu. L. Sage Publications. Y Mylopoulos. Document number WFMC-TC-IOII. Walter de Gruy1er. Cap Gemini Ernst & Young: New York NY. C y Castleman.0: Disponible en: http://www. Proceedings Conference on So. Proceedings of the Eighth Conference on Infol7nation Quality ICIQ '2003. (2003) "Development of an Instrument to Evaluate the Quality of Delivered Infoffi1ation Systems". 14 No. y Lee.com·docs/eGo\"Crnment~o20e. Warboys. CrossTalk 1](9). Wilkin. 1357-1365. (200 I) Data quality. IEEE Transactions Software Eng.K. Beirut (Lebanon).. 31. Yin. P. CRC Press. "The IPSE 2. (2002).. (2001) Lel'els o. 1. eGo\"el?1mel1l Maturity.5 project: process modeling as the basis for a support environment". E.com!services·technolo!!Viooensource· (ultimo acceso en Agosto de 2006). A.windlev. R. Proceedings o. IEEE Computer. (2000).!aturitv. Zubrow. Y.9. Open Source Maturity Model. M. Ziad. "Understanding 'why' in software process modelling. Kluwer Academic Publishers. 73-78. (1988).I. -135-437.aiim. K.fMaturity Matrix. John Wiley & Sons. 26-29 June 2001.om:iwfi11cistandards!docs. Runeson. and design". R. Ohlson. WiMC Workflow Management Coalition (1999) Tel7ninology & GlOSSOlY. pp. Wohlin..fthe 36th Hmmii International Conference on System Sciences. Berlin. Zarnli.

108 Funcionalidad 85 .39 APEL. 346 CBA-IP!. 150 Cielo de vida software.132 Arquitectura de Sistemas de Infomlaci6n Integrados. 85 EFQM. 21 B Benchmarking. 326 Farnilias de estudio. 40. 30 Diagrama de controL 23 Diagrama de dispersi6n. 33 Diagrama de relaciones. 73. 308 Experimentos.66 CALDEA. 84 Casos de estudio. 86 Formato de intercambio de proceso. 154.303 Calidad de datos.62 Encuestas. 273 Calidad de producto software. 331 Fiabilidad. 289 Cali dad de los modelos conceptuales. 75 Cali dad en uso. 112 ASQ. 126 EV AMECAL. 19 Diagrama de Pareto. 161 Cielo de vida de sistemas. 332 F Factoria de experiencia.189 . 32 Diagrarna de procesos de decisiones.MFE. 35 Core Plan Representation. 261 Calidad de los modelos 16gicos. 29 Diagrall1a de matriz. 141 CrvfMI. 181. 301 Calidad de la informaci6n. 19 Diagrama de £lujo. 84 Calidad extema 84 Calidad intema. 33 Diagrama de redes de actividad. 148 Control Estadistico del Proceso.214 Compelisoft. 353 EnlOmos de Ingenieria del Software.69 D Definici6n de Calidad 3 Diagrarna de afinidad. 191 Complejidad. 31 Diagrama de causa-efeclo. 66 c CAF.A.INDICE ALFABETICO A AHvlQ. 43 E Eficiencia.14. 73 Calidad de Sistemas de Informaci6n. 110 Coste de la calidad.

83. 250 H Histograma. 110 MoProSoft. 68 Mantenibi1idad. 56. 83 ISO 9000. 158 Modelo de McCalL 81 Modelo de proceso unificado. 67 SERE)\:TI1PITY. 112 SPEi\1. 174 Personal Software Process (PSP). 240 ivledicion del proyecto. 14 Portabilidad. 14 Medicion del proceso. 86 w WorAjlow Management Coalition. 171 TQdM.53 ISO 90003.161 Seis . 53 ISO 9126. 188 T TDQM. 199 Metamodelo de proceso software. 114 Puntos funcion.50. 238 Medicion del Software. 241 M Malcom Baldrige Nacional Quality Award. 28 Hoja de chequeo.38 QIP.84. 12.121 SPADE.53 ISO 25000.292 u Usabilidad.388 CAUDAD DE SISTEMAS INFORMATICOS ©RA-MA G Gestion de la calidad total. 214 Goal-Driven Software Measurement. 109 Lenguajes de modelado de proceso. 156 ISO 9001. 87 Manual de la Ca1idad. 142 ISO 14598. 14 s L SCAl'v!P!. 142.91 ISO 15288. 190 MRmps.236 ISO 15939. 186 SCE. 136 SMSDM.58. 236 Modelo de madurez de la capacidad (ClvEv!). 209. 326 R Registros. 97 Promenade. 179. III . 49 Gestion de la calidad. 154 ISO 15504. 45.Sigma. 116 Lenguqje de especificacion de proceso. 237 Medicion del producto. 167 Plan de la Calidad. 88 Practical Sofllmre Management (PSM). 68 Proceso somvare. 59 ISO 9004. lSI Gestion del conocimieto. 229 Premio Deming. 223 Niveles de madurez. 130 Spearmint. 158 N p People-CMA!.298 Team Sofnmre Process ITSP). 106 Metricas.12. 22 I IDEAL 164 IP-tvIAP. 319 Goal Question Indicator Metric (GQ(I)}vf). 103 Linea de c6ciigo. 91 Q QFD. 291 ISO 12207.234 ISO 19011. 223 Goal Question Metric (GQivf).

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->