Modelo de calidad CMMI (página 5)

Actividad: Determinar tipo de
requerimiento

Entradas: N. A.

Salidas: N.
A. 

Actores Involucrados: Jefe de
Proyecto

Descripción:

De esta decisión pueden surgir dos
alternativas:

1.- El requerimiento es un Cambio de
Requerimiento.

El requerimiento es una modificación,
corrección o simplemente la eliminación de un
requerimiento que pertenece a la Línea Base vigente
y aprobada.

2.- El requerimiento es un Requerimiento
Nuevo.

El requerimiento no ha sido analizado antes, por
lo tanto es necesario hacer su estudio
detallado.

Actividad: Ingresar
Información del Proyecto y del
requerimiento

Entradas: N. A.

Salidas: Registro de
Requerimientos. 

Actores Involucrados: Jefe de
Proyecto

Descripción:

La información de cada requerimiento
incluye:

Fecha: Fecha en que se realiza este
plan.

ID Proyecto: Identificación del
proyecto.

Nombre Proyecto: Nombre completo del
proyecto.

Responsable GR: Nombre de la persona responsable
de la Administración de los
Requerimientos.

Fase: Número de la fase del mismo proyecto.
Se genera un nuevo encabezado por cada fase del mismo
proyecto.

ID LB: Identificación de la Línea
Base vigente de la fase y el proyecto

Fecha inicio LB: Fecha planificada del comienzo de
esta fase, aprobada por CM. Si está en blanco
implica que aun  no está definida.

Fecha aprobación LB: Fecha de
aprobación de LB utilizada cuando hay cambio de LB
debido a Control de Cambios, si está en blanco
implica que aún no se ha modificado la Línea
Base inicial.

Se actualiza además el estado del
requerimiento como "Ingresado".

El Registro de Requerimientos se realiza en el
software Enterprise Architect[3].

Actividad: Completar o adaptar
requerimientos predefinidos según aplican al
proyecto

Entradas: Glosario y Ayuda.
2.7 Forma de llenado del Registro de
Requerimientos

Salidas: Registro de
Requerimientos

Actores Involucrados: Jefe de
Proyecto

Descripción:

En base a la forma de llenado de los
requerimientos en el Enterprise Architect se actualiza los
datos en el sistema, agregando a su vez mayor detalle a
cada uno, dependiendo del proyecto y del requerimiento en
sí.

Actividad: Evaluar Control de
Cambios

Entradas: Antecedentes
Asociados al control de cambio, Registro de
Requerimiento

Salidas: Registro de
Requerimiento

Actores Involucrados: Jefe de
Proyecto, Gerente de Proyecto

Descripción (Ver Figura
15):

Figura 15: Evaluar Control de
Cambios

El objetivo de esta actividad es evaluar un
control de cambios desde el punto de vista de su
complejidad para ser implementado. El proceso se inicia
registrando la incidencia de realizar el cambio. Si son
varios los cambios involucrados en la misma solicitud se
debe sumar todo lo que está contenido en ella. Para
estimar el esfuerzo se recomienda considerar al menos los
siguientes aspectos:

– Cantidad de cambios incluidos en la
solicitud.

– Complejidad en cuanto a si los requerimientos
afectan pocas o muchas áreas del proyecto, en cuanto
a funciones y  a áreas de desarrollo y
producción involucradas (cliente, usuarios, ambiente
de desarrollo, explotación)

-  Fase del proyecto en que llega el
requerimiento. A mayor avance del proyecto puede ser
más complejo incorporar un cambio.

Los niveles de complejidad del cambio son tres:
Complejo, Medio y Simple. Se define que un cambio es de
nivel complejo si se encuentra en alguna de las siguientes
situaciones:

   – El número de cambios a los
requerimientos es mayor que cinco.

   – Es necesario un cambio importante
en el diseño.

   – El esfuerzo para implementar el
cambio es superior a dos días.

Se define que un cambio de nivel Medio cuando no
es Complejo, pero si requiere análisis o
especificación detallada durante su
ejecución. Se define que un cambio es de nivel
Simple si no cumple con la definición de nivel
Complejo y el detalle de la especificación se puede
realizar durante la especificación inicial del
cambio y no requiere análisis o
especificación durante su ejecución. El
alcance del cambio es acotado y sin
ambigüedades.

Luego de determinar el nivel de complejidad del
cambio se da a conocer al Gerente de Proyecto, y es
éste quien decide si realizar o declinar el
Análisis de Impacto para un control de cambio. Las
opciones que tiene son aprobar, rechazar o postergar el
análisis de impacto del cambio, dependiendo del
estado del proyecto, de la disponibilidad inmediata de
recursos, de la criticidad del cambio o algún otro
criterio aplicable para la decisión. En caso de
aprobar el análisis de impacto, se definirá
también la conveniencia de aplicar el Proceso Formal
de Toma de Decisiones dependiendo de la magnitud de los
cambios y los riesgos que se visualicen para los objetivos
del proyecto. Tomada la decisión se actualiza el
estado del requerimiento como  Aprobado, Rechazado,
Postergado según corresponda. El proceso finaliza al
designar un responsable de la incidencia en base a las
competencias y disponibilidades existentes.

Actividad: Analizar Control de
Cambios

Entradas: Antecedentes
asociados al Control de Cambios, Registro de
Requerimientos

Salidas: Registro de
Requerimientos, Carta Gantt

Actores Involucrados: Jefe de
Proyecto, Analista

Descripción (ver Figura
16):

Figura 16: Analizar Control de
Cambios

El objetivo general de esta actividad es analizar
en profundidad el alcance de un cambio solicitado, para
efectos de estimar el esfuerzo y costos necesarios para
implementarlo, así como evaluar los riesgos
asociados

En base a la decisión tomada en el paso
anterior, que depende de la magnitud de los cambios y los
riesgos que se visualicen para el cumplimiento de los
objetivos del proyecto, se realiza un Proceso Formal de
Toma de Decisiones (basado en el área de proceso DAR
del modelo CMMI) o se procede como se describirá a
continuación.

El Analista a cargo del Control de Cambio
determinará la necesidad de planificar actividades
específicas dependiendo de la complejidad del cambio
analizada en la etapa anterior. Esta complejidad
determinará también la necesidad de ejecutar
las actividades venideras. El Jefe de Proyecto debe
actualizar la carta Gantt del proyecto registrando cambios
en los cronogramas de las actividades debido al
cambio.

Se debiesen identificar todos los objetos
afectados por el cambio, seleccionar a las personas
idóneas para resolver el cambio, definir
cuáles serán los artefactos que
generará el implementar el cambio e identificar
también las eventuales inconsistencias con la
solución ya definida que provocará el cambio.
Con todas estas actividades resueltas ya se podría
actualizar el detalle del control de cambio con su estado,
como a su vez mantener un historial y actualizar la
trazabilidad de requerimientos.

Actividad: Calcular
tamaño y esfuerzo según metodología y
tailoring seleccionados para cada disciplina de la
ingeniería.

Entradas: Work Breakdown
Structure (WBS).

Salidas:  Work Breakdown
Structure (WBS), Estimación de Esfuerzo,
Estimación de Costo.

Actores Involucrados: Equipo
responsable de estimar tamaño, esfuerzo, costos y
plazos del proyecto.

Descripción (Ver Figura
17):

El objetivo de esta actividad es efectuar
estimaciones de tamaño, esfuerzo y costos del
proyecto, de acuerdo a la metodología seleccionada,
a datos históricos y supuestos. Se debiesen
considerar datos históricos acumulados para ajustar
supuestos y validar resultados de estimaciones. Se debiese
también fundamentar el uso de estos datos
históricos seleccionados para las estimaciones y se
debe mantener consistencia en los nombres usados en el
Registro de Requerimientos en EA para asegurar
trazabilidad.

Todas las estimaciones e identificaciones,
tamaño, esfuerzo y costo principalmente, deben ser
actualizadas en el Work Breakdown Structure
(WBS).

Figura 17: Calcular tamaño y
esfuerzo según metodología y tailoring
seleccionados para cada disciplina de la
ingeniería

Actividad: Ingresar
cubicación y evaluar compromisos

Entradas: Resultado de
Cubicación

Salidas: Registro de
Requerimientos, Informe de Control de Cambios al
Cliente

Actores Involucrados:
Ejecutivo Comercial, Jefe de Proyecto

Descripción (Ver Figura
18):

Figura 18: Ingresar
cubicación y evaluar compromisos

El objetivo de esta actividad es adoptar una
posición definitiva ante el cambio solicitado y
formalizar la respuesta al cliente.

Luego de actualizar la información de
esfuerzo y costo correspondiente al requerimiento tratado,
se procede a revisar, sobre la base del análisis de
impacto realizado y el estado actual del proyecto, los
compromisos que deben asumirse por el proyecto para
implementar el cambio solicitado. Si no se realiza un
cambio por desaprobación del cliente se elabora una
propuesta alternativa y se informa al cliente para
conseguir la aprobación formal por parte del
cliente. Si el cambio es realizado se debe generar la
propuesta comercial para el cliente cuando corresponda, y
crear una carta de aprobación formal para el cambio,
que debe ser enviada al cliente para su
aprobación.

Actividad: Formalizar
implementación

Entradas: Informe de Control
de Cambios al Cliente, Carta de Respuesta

Salidas: N. A.

Actores Involucrados: Cliente,
Jefe de Proyecto

Descripción (Ver Figura
19)

Figura 19: Formalizar
implementación

El objetivo de esta actividad es formalizar la
implementación del Control de Cambios a un
requerimiento. La información del informe de control
de cambios preparado para el cliente y la carta de
respuesta enviada al Cliente es revisada por éste
para su aprobación. Cuando el cambio es aprobado por
el cliente se gestionan las líneas bases del
proyecto, tanto las correspondientes a los requerimientos
como a las de planificación y de entregables. Junto
con ello se actualizan los artefactos de gestión que
correspondan, de acuerdo a las características e
impacto del cambio aprobado y considerando al menos los
siguientes: Carta Gantt, Plan de Riesgos, Cálculo de
Esfuerzo, WBS y Plan de Proyecto. Finalmente se debe
comunicar a todas las partes interesadas el alcance del
control de cambios, llámense equipo de proyecto,
equipo de pruebas, de aseguramiento de la calidad y de
administración de la configuración. Si el
cambio no es aceptado por el cliente, se debe escalar el
caso al nivel de jefatura correspondiente, ajustando
estimaciones de esfuerzo y costos y replanteando las
estrategias.

Actividad:
Planificación

Entradas: N. A.

Salidas: N. A.

Actores Involucrados: Jefe de
Proyecto

Descripción:

La planificación realizada para cada
requerimiento entrega como resultado las estimaciones de su
costo, esfuerzo y tamaño.

Actividad: Incorporar
información de esfuerzo al requerimiento que
corresponda

Entradas:

Salidas: Registro de
Requerimientos

Actores Involucrados: Jefe de
Proyecto

Descripción:

Los datos de cubicación, llámense
estimaciones de esfuerzo, tamaño y costo
principalmente, son incorporadas al requerimiento
correspondiente, siendo a su vez actualizadas en la
herramienta Enterprise Architect.

Actividad: Recopilar
información de requerimientos

Entradas: xxx.PPPYE.Productos
y Entregables.xls, xxx.PDP.Plan de Proyecto.doc,
xxx.PPCDE.Calculo de Esfuerzo.xls, xxx.PPPAR.Plan
Administración de Riesgos.xls

Salidas: N. A.

Actores Involucrados: Jefe de
Proyecto

Descripción:

Se recopila la información almacenada de
los requerimientos en base a las planillas y documentos
generadas y al registro de requerimientos almacenado en
Enterprise Architect

Actividad: Enviar
Documentación a grupos involucrados

Entradas: N. A.

Salidas: QA,CM, Testing,
Gerente Proyectos, otros roles identificados.

Actores Involucrados: Jefe de
Proyecto

Descripción:

La información de los requerimientos se
envía a las partes involucradas en el desarrollo del
proyecto.

Actividad: Preparar
revisión de pares

Entradas: Checklist de
Revisión de Pares, Producto de trabajo a
revisar

Salidas: N. A.

Actores Involucrados: Jefe de
Proyecto, Revisor, Autor del producto a revisar

Descripción (Ver Figura
22):

Figura 22: Preparar revisión
de pares

El objetivo de esta actividad es efectuar las
actividades preparatorias y generar las condiciones para
una revisión de pares. El criterio de entrada es
cuando corresponda examinar un artefacto del proyecto con
esta técnica.

En principio de debe convocar al autor del
producto a revisar y al revisor designado a una
reunión y en ella se deben exponer brevemente las
características del producto a ser revisado y se
acuerdan criterios básicos para realizar la
revisión de pares, según las
características del proyecto y del producto. Algunas
de las características que se deben definir son:
Criterios de entrada y salida, Reglas de proceso, Plazos de
la revisión. Luego de esto se procede a actualizar
el checklist de la Revisión de Pares con las
definiciones realizadas.

El autor debe seleccionar el material de apoyo que
se le proveerá al revisor dependiendo del producto
de trabajo a revisar y de las definiciones surgidas de la
reunión de coordinación y finalmente debe
enviar el producto a ser verificado junto con sus
antecedentes asociados y cualquier material de apoyo
útil para realizar la revisión.

Actividad: Ejecutar
Revisión de Pares

Entradas: Checklist de
Revisión de Pares, Producto de trabajo a
revisar

Salidas: Informe de
observaciones

Actores Involucrados: Jefe de
Proyecto, Revisor(es), Autor(es)

Descripción (Ver Figura
23):

Figura 23: Ejecutar Revisión
de Pares

El objetivo de esta actividad es ejecutar una
revisión de pares en el momento en que un revisor ha
recibido conforme el artefacto a revisar junto con todo su
material de apoyo.

Esta actividad comienza verificando que existan
las condiciones para efectuar la Revisión de Pares,
en cuanto a disponibilidad de artefactos y
documentación asociada según los acuerdos
alcanzados en la reunión preparatoria. Luego se
realiza la revisión del artefacto según la
checklist, la aplicación de la metodología y
los antecedentes asociados, registrando los defectos
encontrados en el Reporte de Observaciones y registrando
además el tiempo dedicado a la
revisión.

Paso siguiente es convocar a reunión al
Jefe de Proyecto y al Autor o Autores del artefacto con el
objetivo de analizar las observaciones encontradas,
unificar criterios, determinar los defectos definitivos,
registrarlos en el reporte y de ser necesario definir
plazos para nueva revisión. El autor debe responder
a las observaciones mencionadas y aclarar los temas que
sean necesarios. Si la respuesta satisface al equipo
revisor, el problema no se registra. El Jefe de Proyecto
registra el resultado de la reunión y entrega al
Autor y Equipo Revisor sus conclusiones.

Además se debe determinar si las
modificaciones requeridas ameritan una nueva
revisión de pares; si es así, se planifica
una nueva reunión. También se deben registrar
métricas asociadas, como lo son esfuerzo, cantidad
de defectos encontrados, cantidad de revisión de
pares por producto, etc.

Luego se debe planificar la incorporación
de las correcciones requeridas al artefacto
revisado,   ingresando los defectos
válidos como eventos no planificados. Hecha la
planificación, se realizan las modificaciones
solicitadas y en base a estas se realiza la
evaluación y validación a estas correcciones
para determinar si estas corrigen los defectos encontrados
en la revisión, para en consecuencia definir si el
producto cumple con los criterios de salida definidos, de
manera de dar por finalizada la Revisión de Pares.
Si las modificaciones no son satisfactorias, se
efectúan nuevamente las modificaciones solicitadas
hasta que cumplan con los criterios de salida.

La revisión de pares culmina con la
recolección de métricas generadas en cada una
de las etapas del proceso, con la incorporación de
nuevas métricas y con la generación de
resultados en el informe consolidado del proceso. Se debe
verificar que la Revisión de Pares se haya aplicado
sobre el producto definido, que los reportes generados se
hayan completado, que los productos y métricas hayan
sido actualizados según lo acordado, que se haya
consolidado y archivado la documentación del
proceso.

Actividad: Preparar
Pruebas

Entradas: Bases de
Licitación, Registro de Requerimientos, Informe de
Diseño, Metodologías de prueba de
software.

Salidas: Casos de Prueba,
Datos de Prueba, Definición de ambientes de prueba,
Plan de Pruebas.

Actores Involucrados:
Responsable de Pruebas de Software, Jefe de
Proyecto

Descripción (Ver Figura
25):

Esta actividad o proceso tiene como objetivo
efectuar actividades preparatorias y generar las
condiciones para pruebas de software y se ejecuta
cuando  hay que verificar el funcionamiento del
software construido en un proyecto de desarrollo. El
proceso describe las siguientes actividades:

1.     Determinar
productos de software que serán probados a partir
del contenido de las Bases de Licitación y
Registro de Requerimientos. Estos pueden ser
módulos, funciones, requerimientos, productos y
componentes de productos.

2.     Definir alcance
de las pruebas. Incluye tipos de pruebas, enfoques y
restricciones. Los tipos de prueba son funcionales, de
seguridad, de rendimiento, de aceptación o de
instalación.

3.     Definir
método de pruebas para productos y componentes de
software. Los métodos pueden ser: Caja Negra, Caja
Blanca, Partición Equivalente, Análisis de
Valor Límite, Comparación, Caja de Cristal,
Caja de Pandora, Integración Ascendente,
Integración Descendente, Integración
Combinada o  Integración Big-Bang.

4.     Generar casos
de prueba y datos  de prueba que se
utilizarán en la ejecución de
pruebas.  Los datos de prueba mencionados en el
punto 4 pueden ser generados por el equipo de trabajo, el
equipo de pruebas o proporcionados por el cliente, lo
cual debe quedar establecido en el Plan de
Pruebas.

5.     Definir
ambiente de pruebas. Se debe Registrar todos los detalles
técnicos de la creación y todas aquellas
consideraciones especiales que sea necesario recordar
ante una reconstitución del ambiente para iterar
todos o algunos de los casos de prueba.  Los datos
son registrados en el documento Definición de
Ambiente de Pruebas el cual es anexado al Plan de
Pruebas.  Este documento incluye red, servidor,
privilegios, espacio en disco, herramientas de prueba y
recurso humano que ejecutarán las
pruebas.

Figura 25: Preparar
Pruebas

6.     Estimar
esfuerzo para ejecución de las pruebas.  Se
debe considerar todas las actividades relacionadas con
las pruebas: revisión de documentación,
elaboración del Plan de Pruebas, generación
del ambiente de pruebas, análisis transaccional,
generar escenarios de pruebas, preparación de
casos de prueba, generación de datos de prueba,
ejecución de las pruebas, seguimiento de las
pruebas, consolidar resultados y generar reportes, y
generar informe final y métricas.

7.     Estimar plazos
para ejecución de las pruebas, considerando
recursos disponibles para pruebas y estimaciones de
productividad individual

* Todos los anteriores documentos generados
formarán parte del Plan de Pruebas.

8.     Informar
planificación de pruebas al Jefe de Proyecto para
coordinación

El Jefe de Proyecto es el encargado de aprobar el
Plan de Pruebas analizando su compatibilidad con las
eventuales restricciones del proyecto.  En el caso de
no aprobar el documento se debe revisar los puntos en
conflicto.

Actividad: Ejecutar
Pruebas

Entradas: Plan de Pruebas,
Informe de Diseño, Software a probar, Casos de
Prueba, Datos de Prueba

Salidas: Métricas de
validación, Reporte de Observaciones

Actores Involucrados:
Responsable de Pruebas de Software, Equipo de
Proyecto.

Descripción (ver Figura
26):

Figura 26: Ejecutar
Pruebas

Esta actividad o proceso tiene como objetivo
verificar el funcionamiento del software construido en un
proyecto de desarrollo y alcanzar los criterios de
aceptación o de término de pruebas
definidos.  El proceso contiene las siguiente
actividades:

1.     Ejecutar
pruebas de acuerdo al plan: Se ejecutan las acciones,
procedimientos y programas establecidos para cada prueba
aplicando los Casos de Prueba definidos y los datos de
pruebas generados para tal efecto.

2.     En caso de
pruebas sobre funciones corregidas se ejecutan pruebas de
regresión para asegurar que las correcciones no
crearon problemas en otra parte del software.

3.     Documentar
resultados en el Informe de Observaciones.

4.     Analizar
resultados de las pruebas determinando: problemas de
construcción de software, problema con el
método de pruebas seleccionado, problemas del
ambiente de pruebas (infraestructura, datos de pruebas,
componentes de software faltantes, emitir recomendaciones
de mejora si es posible).

5.     Determinar
criticidad de las observaciones: defectos de forma,
defectos de fondo, factibilidad de continuar con otras
pruebas a pesar de los defectos detectados.

6.     Comunicar
resultados de las pruebas al proyecto

7.     Acumular
métricas del proceso: cantidad de defectos total,
cantidad de defectos por categoría (grave,
mediana, leve), cantidad de iteraciones.

[Bat95]

Roger Bate, Dorothy Kuhn, Curt Wells, James
Armitage, Gloria Clark, Kerinia Cusick, Suzanne Garcia,
Mark Hanna, Robert Jones, Peter Malpass, Ilene Minnich, Hal
Pierson, Tim Powell, Al Reichner: "A Systems Engineering
Capability Maturity Model, Version 1.1",
1995.

[Chr06]

Mary Beth Chrissis, Mike Konrad, Sandy Shrum;
"CMMI® for Development, v1.2", 2006.

[Gon07]

Gonzalez, Carlos: "Conceptos Generales de
Calidad Total", Monografías, 2007. 

http://www.monografias.com/trabajos11/conge/conge.shtml

[Inc96]

INCOSE: "Systems Engineering Capability
Assessment Model", 1996.

http://www.incose.org/ProductsPubs/pdf/SECAM-SysEngCapabilityAssessModel_1996-06.pdf

[Jac99]

Ivar Jacobson, Grady Booch, James Rumbaugh:
"The Unified Software Development Process",
1999.

[Kul03]

Margaret K. Kulpa, Kent A. Johnson:
"Interpreting the CMMI: A Process Improvement
Approach", 2003.

[Pal06]

Palacio, Juan: "Sinopsis de los modelos CMM-SW
y CMMI", 2006

http://www.navegapolis.net/files/articulos/sinopsis_cmm.pdf

[Pau93]

Mark C. Paulk, Bill Curtis, Mary Beth Chrissis,
Charles V. Weber: "Capability Maturity Model for
Software, Version 1.1", 1993.

http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf

[Rat03]

IBM Staff: "Rational Unified Process Best
Practices for Software Development Teams",
2003.

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

[Rig06]

Rigoni, Cecilia: "CMMI®: Mejora del proceso
en Fábricas de Software", 2006.

http://www.mityc.es/NR/rdonlyres/A570B90C-B41A-46E2-BD39-4A31D18BB7FD/0/s01CeciliaRigoni.pdf

[Sec07a]

© SECAT LLC: "Understanding the SECM
(EIA/IS 731.1)", 2007.

http://www.secat.com/workshops/731.1_WorkshopDescription.htm

[Sec07b]

© SECAT LLC: "Integrated Product
Development Capability Maturity Model overview
briefing", 2007.

http://www.secat.com/download/locked_pdf/IPDovrvw_lkd.pdf

[SEI00]

Software Engineering Institute, Carnegie Mellon
University: "ARC, V1.0 Assessment Requirements for CMMI
Version 1.0", 2000

http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr011.pdf

[SEI01]

Software Engineering Institute, Carnegie Mellon
University: "Standard CMMI Appraisal Method for Process
Improvement (SCAMPI) Version 1.1: Method Definition
Document", 2001

http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01hb001.pdf

[SEI06a]

Software Engineering Institute, Carnegie Mellon
University: "A Standard CMMI Appraisal Method for
Process Improvement (SCAMPI) Version 1.2: Method Definition
Document", 2006.

http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06hb002.pdf

[SEI06b]

Software Engineering Institute, Carnegie Mellon
University: "Appraisal Requirements for CMMI, Version
1.2 (ARC, V1.2)", 2006.

http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr011.pdf

[SEI07a]

Software Engineering Institute, University
Carnegie-Mellon: "Capability Maturity Model®
Integration (CMMI), Version 1.2 Overview",
2007.

http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview07.pdf

[SEI07b]

Software Engineering Institute, Carnegie Mellon
University: What is CMMI?, Septiembre 2007.

http://www.sei.cmu.edu/cmmi/general/index.html

[Vil00]

Villate Blanco, José María:
"Modelos de calidad en la industria. Situación y
perspectivas de futuro en la CAPV", 2000.

http://www.euskonews.com/0061zbk/gaia6103es.html