Control de Calidad

MODALIDAD ABIERTA Y A DISTANCIA
Departamento de Ciencias de la Computación y Electrónica

Sección Ingeniería del Software y Gestión de Tecnologías de la Información
Control de Calidad
Guía didáctica
4 créditos
Titulación Ciclo
Informática X
Autor:
Ing. Manuel Eduardo Sucunuta
La Universidad Católica de Loja

Asesoría virtual:
www.utpl.edu.ec
CONTROL DE CALIDAD
Guía didáctica
Manuel Eduardo Sucunuta
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

CC 4.0, CC BY-NY-SA
Diagramación, diseño e impresión:

Ediloja Cía. Ltda.
Telefax: 593-7-2611418
San Cayetano Alto s/n
www.ediloja.com.ec
edilojainfo@ediloja.com.ec
Loja-Ecuador
Derecho de autor: CUE-001748
Tercera edición
Séptima reimpresión
ISBN físico - 978-9942-08-584-9

ISBN digital - 978-9942-04-848-6
La versión impresa y digital han sido acreditadas bajo la licencia Creative Commons 4.0, CC BY-NY-SA: Reconocimiento-No comercial-
Compartir igual; la cual permite: copiar, distribuir y comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice
con fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al ser divulgada. https://
creativecommons.org/licenses/by-nc-sa/4.0/deed.es
Abril, 2018
2. Índice
2. Índice............................................................................................................................................................. 3
3. Introducción............................................................................................................................................. 5
4. Bibliografía............................................................................................................................................... 6
4.1. Básica........................................................................................................................................... 6
4.2. Complementaria...................................................................................................................... 6
5. Orientaciones generales para el estudio.............................................................................. 8
6. Proceso de enseñanza-aprendizaje para el logro de competencias................. 11
PRIMER BIMESTRE
6.1. Competencias............................................................................................................................ 11
6.2. Planificación para el trabajo del alumno......................................................................... 11
6.3. Sistema de evaluación (primero y segundo bimestre)................................................ 13
6.4. Orientaciones específicas para el aprendizaje por competencias............................ 14
UNIDAD 1. INTRODUCCIÓN A LA CALIDAD....................................................................................... 14

1.1. La calidad................................................................................................................................... 14
1.2. Evolución histórica de la calidad......................................................................................... 17
1.3. Normas de calidad................................................................................................................... 18
1.4. Gestión de la calidad total (TQM)....................................................................................... 18
1.5. Normas ISO 9000...................................................................................................................... 19
1.6. Modelo EFQM............................................................................................................................ 20
1.7. Seis-Sigma................................................................................................................................. 22
Autoevaluación 1................................................................................................................................. 24
UNIDAD 2. CALIDAD DE LOS SISTEMAS DE INFORMACIÓN........................................................... 26

2.1. Situación actual de la calidad de los Sistemas de Información................................ 26
2.2. Importancia de la calidad en los SI.................................................................................... 27
2.3. Componentes de calidad de un SI...................................................................................... 28
2.4. Calidad de un sistema de información y la gestión del conocimiento................... 28
Autoevaluación 2................................................................................................................................. 30
UNIDAD 3. CALIDAD DEL PRODUCTO SOFTWARE........................................................................... 32

3.1. Modelos clásicos de calidad de productos software..................................................... 32
3.2. Normas relacionadas con la calidad del software......................................................... 32
3.3. Familia de normas ISO 25000.............................................................................................. 34
Autoevaluación 3................................................................................................................................. 37
SEGUNDO BIMESTRE
6.5. Competencias............................................................................................................................ 39
6.6. Planificación para el trabajo del alumno......................................................................... 39
6.7. Orientaciones específicas para el aprendizaje por competencias............................ 41
UNIDAD 4. CALIDAD DEL PROCESO SOFTWARE.............................................................................. 41

4.1. El procesos software............................................................................................................... 41
4.2. Gestión de procesos software.............................................................................................. 42
4.3. Modelado de procesos software......................................................................................... 43
4.4. Entornos de Ingeniería del software orientados al proceso....................................... 44
Autoevaluación 4................................................................................................................................. 46
UNIDAD 5. EVALUACIÓN Y MEJORA DE PROCESOS......................................................................... 48

5.1. La mejora de procesos............................................................................................................ 48
5.2. La norma ISO/IEC 90003........................................................................................................ 50
5.3. SEIS-SIGMA para software.................................................................................................... 50
5.4. Mejora de procesos en PYMES............................................................................................. 50
5.5. CMMI............................................................................................................................................ 52
5.6. IDEAL............................................................................................................................................ 56
5.7. SCAMPI........................................................................................................................................ 56
Autoevaluación 5................................................................................................................................. 57
UNIDAD 6. GESTIÓN DE LA CALIDAD DE LOS PROYECTOS............................................................. 59

6.1. Gestión de la calidad de los proyectos.............................................................................. 59
6.2. Plan de aseguramiento de calidad del software........................................................... 59
6.3. Revisiones e inspecciones..................................................................................................... 60
6.4. Calidad de las personas.......................................................................................................... 64
Autoevaluación 6................................................................................................................................. 66
7. Solucionario.............................................................................................................................................. 67
8. Anexos........................................................................................................................................................... 73
PRELIMINARES Guía didáctica: Control de Calidad
3. Introducción
Control de Calidad se imparte en el décimo ciclo en la Titulación de Ingeniería en Informática del

Departamento de Ciencias de la Computación y Electrónica, de la Universidad Técnica Particular de Loja,
Modalidad Abierta y a Distancia. Es un componente educativo troncal de carrera y tiene una valoración
de 4 créditos.
Este componente educativo se ha diseñado para que adquiera habilidades y capacidades relacionadas
con la calidad en la planificación y gestión de proyectos de software, mediante el estudio, análisis y
discusión de guías, normas, estándares y procedimientos que se han establecido para cada uno de los
componentes de un proyecto.
Durante el estudio de la carrera, ha tenido la oportunidad a través de los componentes educativos

estudiados de conocer sobre el desarrollo de productos software, empezando con elementos básicos
de programación para luego profundizar sobre la línea de la ingeniería de software; esto le ha permitido
adquirir competencias relacionadas con el desarrollo y la gestión de proyectos al elaborar productos
software.
El componente educativo se encuentra estructurado de seis capítulos, los mismos que se han dividido
en dos bimestres. El primer bimestre está conformado por las primeras tres unidades en las que se
analizan la calidad desde una perspectiva general. En la Unidad 1 se abordan conceptos relacionados
con la calidad, la forma en que la calidad ha evolucionado a través del tiempo, y de forma general sobre
las normas y modelos de calidad que aportan a los productos software.
En la Unidad 2, se analiza la calidad en los sistemas de información de forma general, empezando con la
situación actual de los SI en cuanto al éxito, deficiencias y fallas de los productos software, para de esta
manera justificar la importancia de la calidad en los SI. Se realiza una exposición de los compontes de
calidad en los SI, y de cómo la gestión del conocimiento se relaciona con los SI desde el punto de vista
de la calidad.
En la Unidad 3, se enfoca la calidad del producto software, empezando con los modelos clásicos de
calidad, luego se realiza un análisis de las normativas que se podría utilizar, especialmente lo relacionado
con el estándar 25000, con sus respectivas divisiones.
En el segundo bimestre se profundiza el análisis de la calidad relacionada con los procesos software, con
la mejora de procesos y sobre el estándar IEEE 730-2002.
En la unidad 4, se hace un análisis de los procesos software, ya que para aplicar los aspectos relacionados
con la calidad es fundamental conocer de la gestión y del modelado de los procesos software.
En la unidad 5, se expone sobre la evaluación y mejora de procesos, por lo tanto los temas analizados
tienen que ver con la importancia, normativa, mejora en las PYMES y los modelos del SEI, como es: CMMI,
SCAMPI e IDEAL.
En la unidad 6, se finaliza concretamente analizando dos temas: el primero relacionado con la gestión
de la calidad por parte del PMBOK y del estándar IEEE 730-2002, que tiene que ver con el plan de
aseguramiento de la calidad del software.
Finalmente, le deseo el mejor de los éxitos en el estudio del presente componente educativo y le recuerdo
que tiene a su disposición una serie de recursos educativos en línea, además de la ayuda de su tutor.

5
Guía didáctica: Control de Calidad PRELIMINARES
4. Bibliografía
4.1. Básica
• Piattini, M.; García, F.; García, I. y Pino, F. (2012). Calidad de Sistemas de Información. México:
Alfaomega.
El texto cubre diferentes aspectos de calidad relacionados con todos los componentes que
intervienen en el desarrollo de un proyecto de software, por lo que se analizan diversos factores
que se deben considerar para construir e implementar software de calidad. Los autores son
reconocidos investigadores que ha publicado varios artículos y texto relacionados con la calidad.
• Sucunuta, M. (2014). Guía didáctica Control de Calidad. Loja, Ecuador: Ediloja.
Guía didáctica elaborada para el componente educativo de Control de Calidad, de la titulación de

Informática de la modalidad de estudios abierta y a distancia de la Universidad Técnica Particular
de Loja.
4.2. Complementaria
• Pressman, R. (2010). Ingeniería del Software. Un enfoque práctico. México: McGrawHill.
El texto cubre temas relacionados con la gestión y desarrollo de proyectos de software desde el
punto de vista de la ingeniería del software, se exponen casos que facilitan la comprensión de las
diversos temas.
• Sommerville, I. (2011). Ingeniería de Software. México: Pearson.
El texto cubre los temas relacionados con el desarrollo y gestión de proyectos software. Su autor
es un reconocido académico vinculado con importantes proyectos relacionados con la ingeniería
del software, por lo que en el texto los temas se abordan de una manera coherente y con casos
que resultan fácilmente entendibles.
• Project Management Institute. (2013). A Guide to the Project Management Body Of Knowledge.
Newton Square, Pennsylvania: PMI.
Guía de los fundamentos de la dirección de proyectos del PMI, es un estándar internacional para
la gestión de proyectos aplicable a cualquier industria, este texto tiene valiosa información tanto
en la conceptualización como en las actividades de planificación, ejecución, seguimiento y cierre
de los proyectos.
Direcciones electrónicas
• Carnegie Mellon University. (2014). Software Engineering Institute. Pittsburgh: Carnegie Mellon
University. Recuperado de: http://www.sei.cmu.edu/.
Es el sitio oficial del Carnegie Mellon Software Engineering Institute (SEI), realiza investigaciones
para explorar soluciones prometedoras a los problemas de ingeniería de software, identifica y
codifica soluciones tecnológicas y metodológicas, pruebas y refina las soluciones a través de
6 MODALIDAD ABIERTA Y A DISTANCIA

programas piloto que ayudan a la industria y al gobierno a resolver sus problemas, difunde
soluciones probadas a través de la formación, concesión de licencias, y la publicación de las mejores
prácticas. En esta dirección encontrará recursos para complementar su estudio y el desarrollo de
sus trabajos tanto académico como profesional.
• Project Management Institute. (2014). PMBOK Guide and Standards. Pensilvania: PMI. Recuperado
de: www.pmi.org.
Sitio oficial del Project Management Institute, ofrece recursos en temas de gestión de proyectos,
eventos pagados y gratuitos. Se puede pagar una membresía anual que le daría acceso a todos los
estándares internacionales relacionados con su área.
Recursos OCW
• Barreiro, P. S., Bueno, C. B., Marqués, J. H., González, F. R. (2011). Ingeniería del Software II. Cantabria:
Creative Commons. Recuperado de: http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-
software-ii.
Curso de la Universidad de Cantabria, que cubre las diferentes disciplinas de la Ingeniería de

Software, entre ellas la Calidad de Sistemas y Procesos Software, además de las Pruebas de
Sistemas Software.
• Velasco, C. L., Montoro, F. A. (2012). Software Quality. Madrid: Creative Commons. Recuperado de:
http://ocw.upm.es/lenguajes-y-sistemas-informaticos/software-quality.
Curso introductorio de la Universidad Politécnica de Madrid sobre las técnicas de calidad aplicadas
a la Ingeniería del Software. Relacionado directamente con las técnicas utilizadas para probar el
producto software.

7
5. Orientaciones generales para el estudio
5. ORIENTACIONES GENERALES PARA EL ESTUDIO
Para el estudio del presente componente educativo el estudiante contará con las siguientes herramientas
básicas:
La guía didáctica:
Le orientará sobre cómo y qué temas estudiar, además contiene ejercicios de autoevaluación que le
permitirán medir su grado de comprensión y la necesidad de tutoría por parte del docente. Muchos
alumnos empiezan estudiando directamente el texto, pero como verá más adelante no es recomendable
hacerlo.
El texto básico:
Le servirá para desarrollar los contenidos principales conforme se indica en la guía didáctica. Vale acotar
que no todos los capítulos del texto se consideran para el componente educativo y tampoco cubre
todos los contenidos por lo que el estudio debe hacerse siguiendo las instrucciones de la guía didáctica.
El Entorno Virtual de Aprendizaje:
Donde podrá interactuar con sus profesores a través de una orientación del trabajo semanal, uso de
mensajería electrónica para resolver inquietudes, foros, desarrollo de ejercicios prácticos, publicación de
recursos, todo este trabajo tendrá una valoración de acuerdo a lo que disponga el tutor.
La Tutoría personal:
Es un tiempo semanal que como profesores dedicamos para atender las inquietudes en relación a
los contenidos o desarrollo de trabajos, para ello se publicará un horario en el cual podrán asistir
personalmente o contactarse vía telefónica, el mismo que se detalla en la carátula de la evaluación a
distancia.
Los trabajos a distancia:
Son actividades teóricas y prácticas que acompañan a la guía didáctica de cada una de las materias,
le permiten aplicar y reforzar los conocimientos adquiridos mediante su desarrollo, y debe enviarlos a
su profesor. La entrega de estos trabajos con su respectiva carátula es obligatoria y no recuperable, lo
cual significa que si no entrega alguno de los mismos no tendrá opción a la evaluación presencial, su
valoración es de 6 puntos considerando la interacción en el EVA.
En cuanto a la forma de trabajo damos algunos lineamientos que le ayudarán a aprovechar su tiempo y
lograr mejores resultados:
• El tiempo que dedique a la lectura y desarrollo de los ejercicios es fundamental, por lo tanto
deberá dedicar al menos 8 horas semanales. Puede apoyarse con técnicas como subrayado,
cuadros sinópticos y sobre todo mapas conceptuales.
• Recuerde que cuenta con su profesor tutor para la comprensión de los temas, por lo que
la comunicación con el mismo será fundamental, para lo cual debe familiarizarse con las
formas de comunicación que tiene, ya sea por teléfono (consultar horario de tutoría), correo

electrónico, chat, y otras herramientas tecnológicas. Recuerde además que existe una
variada información en el internet, bibliotecas digitales y también la documentación que su
profesor le acerca a través del EVA.
• En la guía didáctica encontrará la planificación del trabajo con las actividades sugeridas
para cada unidad, distribuidas en semanas, por lo tanto trate de cumplir con éstas según se
indica.
• Las autoevaluaciones que se presentan al final de cada unidad así como las que constan en
el texto básico le ayudarán a comprender de mejor manera cada uno de los temas por lo que
su realización es de suma importancia para afianzar el proceso de enseñanza aprendizaje.
• Una vez resueltas las autoevaluaciones de la guía didáctica puede comparar sus respuestas
con el solucionario al final de la guía. En caso que su resultado no sea satisfactorio le
sugerimos volver a revisar los temas y acudir a su tutor para aclarar sus dudas.
Como ayudas, a lo largo del presente documento encontrará los siguientes focalizadores:
Focalizador Propósito
Actividad recomendada:
Se refiere a ciertas actividades que el tutor recomienda para reforzar el conocimiento
del tema. Es una actividad complementaria.
Lectura:
Debe recurrir al texto básico y realizar una lectura comprensiva del literal y/o sub-
literales que se indique.
Autoevaluación:
Conjunto de literales que le permitirán en forma general saber el grado de asimilación
de los contenidos. Las respuestas están al final de la guía.
Buscar en la web:
Deberá buscar o ingresar al sitio que se indica para afianzar sus conocimientos, es
una actividad complementaria.
Importante:
Aporte significativo que deberá analizar detenidamente.
Evaluación
El sistema de estudios de la modalidad abierta y a distancia de la Universidad Técnica Particular de Loja

contempla los siguientes parámetros de evaluación, con la particularidad de que en la titulación de
Ingeniería en Informática el tutor tiene la posibilidad de valorar la interactividad en el EVA.
El componente educativo se encuentra dividido en dos bimestres, cada uno de los cuales se califica
sobre 20 puntos, en el caso de que algún estudiante no obtenga una nota mínima de 14 puntos,
deberá presentarse a un examen final calificado sobre 20 puntos: que reemplaza la nota bimestral
correspondiente. Los estudiantes aprueban cuando han logrado un mínimo de 28 puntos.

9
En el presente cuadro constan los parámetros y puntajes que se tomarán en cuenta en el primer y
segundo bimestre.
Instrumento Puntaje
Trabajo a distancia:
• Objetiva 2 puntos
• Ensayo e interacción en el EVA 4 puntos
Evaluación presencial 14 puntos
TOTAL 20 PUNTOS

6. Proceso de enseñanza-aprendizaje para el logro de competencias
PRIMER BIMESTRE
PRIMER BIMESTRE
6.1. Competencias

COMPETENCIAS GENÉRICAS DE LA UTPL
Trabajo en equipo II: Contribuye en la consolidación y desarrollo del equipo, favoreciendo la comunicación, el reparto equilibrado de tareas, el clima
interno y la cohesión.
üü Acepta y cumple las normas del grupo

üü Contribuye al establecimiento y aplicación de los procesos de trabajo del equipo.
6.2. Planificación para el trabajo del alumno
COMPETENCIAS
COMPETENCIAS CONTENIDOS
ESPECÍFICAS DEL INDICADORES DE
ESPECÍFICAS DE ACTIVIDADES DE APRENDIZAJE TIEMPO DE DEDICACIÓN
COMPONENTE APRENDIZAJE
TITULACIÓN UNIDADES
EDUCATIVO
UNIDAD1. Introducción a la • Estudiar la unidad 1 de la guía • Reconoce los diferentes
calidad. didáctica. conceptos relacionados con
la calidad
1.1. La calidad • Desarrollar las actividades
Implementar 1.2. Evolución histórica de la recomendadas. • Reconoce los eventos que
aplicaciones a partir de Asocia los conceptos Semana 1 y 2
calidad marcaron la calidad a través
especificaciones y de calidad con los • Desarrollar la autoevaluación 1
dela historia • 8 horas de autoestudio
modelos de software proyectos de 1.3. Normas de calidad • Desarrollar los ejercicios del capítulo 1
utilizando estándares desarrollo de • Diferencia entre gestión de • 8 horas de interacción
1.4. Gestión de la calidad y 2 del texto básico.
de documentación y software proyecto y producto de
total software.
de programación. • Desarrollar la evaluación a distancia.
1.5. Normas ISO 9000
Guía didáctica: Control de Calidad
1.6. Modelo EFQM
11
1.7. Seis-Sigma
COMPETENCIAS
12
ESPECÍFICAS DEL INDICADORES DE
ESPECÍFICAS DE ACTIVIDADES DE APRENDIZAJE TIEMPO DE DEDICACIÓN
COMPONENTE APRENDIZAJE
EDUCATIVO
UNIDAD2. Calidad de los • Estudiar la unidad 2 de la guía • Describe los factores que
sistemas de información didáctica. inciden en el fracaso de los
proyectos.
2.1. Situación actual de los SI • Desarrollar las actividades
2.2. Importancia de la recomendadas. • Identifica los componentes Semana 3 y 4
Define los conceptos de calidad de un SI.
calidad en los SI • Desarrollar la autoevaluación 2. • 8 horas de estudio
relacionados con la
calidad en los 2.3. Componentes de calidad • • Describe los elementos de personal
Desarrollar los ejercicios del capítulo 3
sistemas de de un SI calidad que intervienen en
del texto básico. • 8 horas de interacción
información. un SI al gestionar el
2.4. Calidad del SI
• Desarrollar la evaluación a distancia. conocimiento.

y la gestión del
conocimiento • Interactúe en el EVA con aportes
significativos de la temática que
proponga el tutor.
UNIDAD3. Calidad del • Estudiar la unidad 3 de la guía • Identifica la norma

producto software. didáctica. adecuada para aplicar al
producto software.
3.1. Modelos clásicos de • Desarrollar las actividades
Construir modelos y calidad de productos recomendadas. • Reconoce las normas de Semana 5 y 6
especificaciones de Identifica la software calidad de acuerdo al área
• Desarrollar la autoevaluación 3. • 8 horas de estudio
software que permitan normativa de calidad 3.2. Normas relacionadas requerida.
personal
validar un producto relacionada con el con la calidad de • Desarrollar los ejercicios del capítulo 4
previo a su producto software. del texto básico. • 8 horas de interacción
productos software
implementación • Desarrollar la evaluación a distancia.
3.3. Familia de normas ISO
25000 • Interactúe en el EVA con aportes
significativos de la temática que
proponga el tutor.
Unidades 1 a 3 • Revisión de contenidos como

preparación para la evaluación Semana 7 y 8
presencial.
8 horas de estudio personal
• Interactúe en el EVA con aportes
significativos de la temática que 8 horas de interacción
proponga el tutor.
PRIMER BIMESTRE

PRIMER BIMESTRE Guía didáctica: Control de Calidad
6.3. Sistema de evaluación (primero y segundo bimestre)
Formas de evaluación 2. Heteroevaluación

Evaluación a Evaluación
1. Autoevaluación *
distancia ** presencial
3. Coevaluación
Interacción en el EVA
Parte de ensayo
Prueba objetiva
Parte objetiva
Competencia: criterio
Comportamiento ético x x x x x
Cumplimiento, puntualidad,
x x x x x
Actitudes
responsabilidad
Esfuerzo e interés en los trabajos x x x x x
Respeto a las personas y a las
x
normas de comunicación
Creatividad e iniciativa x x x x
Habilidades
Contribución en el trabajo
x
colaborativo y de equipo
Presentación, orden y ortografía x x x x
Emite juicios de valor
x
argumentadamente
Dominio del contenido x x x x x
Conocimientos
Investigación (cita fuentes de

x x
consulta)
Aporta con criterios y soluciones x x
Análisis y profundidad en el
x
desarrollo de temas
Máximo 1 punto
PORCENTAJE 10% 20% 30% 70%

Estrategia de
aprendizaje
presenciales y en el
evaluación a
(completa la
distancia)
Puntaje 2 4 6 14
Actividades
EVA
TOTAL 20 puntos
Para aprobar la asignatura se requiere obtener un puntaje mínimo de 28/40 puntos, que equivale al 70%.
* Son estrategias de aprendizaje, no tienen calificación; pero debe responderlas con el fin de autocomprobar su
proceso de aprendizaje.
** Recuerde que la evaluación a distancia consta de dos partes: una objetiva y otra de ensayo, debe desarrollarla
y enviarla a través del EVA según las fechas establecidas.
Señor estudiante:
Tenga presente que la finalidad de la valoración cualitativa es

principalmente formativa.

13
Guía didáctica: Control de Calidad PRIMER BIMESTRE
6.4. Orientaciones específicas para el aprendizaje por competencias
UNIDAD 1. INTRODUCCIÓN A LA CALIDAD
Estimado estudiante.
Iniciamos la presente unidad con un análisis de los conceptos relacionados con la calidad de forma
general, ya que cualquiera sea el producto que se utiliza, la principal característica que se observa para
su uso es la calidad. Hoy en día ya no solamente se habla de hacer las cosas bien, sino de mantener un
nivel adecuado de calidad durante la realización de un servicio o producto.
La calidad tiene que ver con la apreciación que pueda tener cada individuo al comparar una cosa con
otra de su misma especie, por lo tanto la calidad está implícita en las capacidades que posee un objeto
para satisfacer ciertas necesidades de los individuos.
1.1. La calidad
El interés por la calidad ha existido desde hace mucho tiempo, por lo que el concepto y formas de
gestionar la calidad han evolucionado progresivamente. El concepto de calidad se encuentra inmerso
en diversos ámbitos donde se produce un servicio o producto que será requerido por unos interesados.
Varios son los pensadores que han contribuido y se han distinguido por sus definiciones y propuestas
con respecto a la calidad.
Estimado estudiante:
Para profundizar la definición y tener idea del concepto de calidad es necesario que
realice la lectura comprensiva del literal “1.1. Definición de la calidad” del texto básico.
Finalizada la lectura del literal indicado, se puede deducir que el concepto de calidad ha evolucionado
a lo largo de la historia, de tal manera que actualmente los mercados son muy competitivos, por lo que
se requiere productos y servicios con altos niveles de calidad, ya que no es suficiente con producirlos y
distribuirlos de forma masiva, sino que deben ser útiles para las organizaciones.
La calidad con respecto a servicios o productos pueden ser definidos de diferente

manera. En la actualidad el concepto de calidad tiene que ver con entregar al cliente
beneficios que no los ha solicitado, pero una vez que los conoce se da cuenta que
son los que necesita. De todas formas, es recomendable que el producto sobrepase
ligeramente las expectativas del cliente, de esta forma quedará sorprendido y por lo
tanto se mantendrá su lealtad hacia el producto o servicio.
Un tema importante en nuestros días es la calidad de la información, ya que la falta de calidad de los
datos es uno de los mayores problemas a los que se enfrentan los responsables de los sistemas en
las organizaciones de todo el mundo. En la tabla 1.1, se indica un resumen de la forma en que ciertas
organizaciones o pensadores han definido a la calidad.

Tabla 1.1: Definición de calidad (Piattini, García, & Caballero, 2007)
Organización/Pensador Calidad es…

El grado en que un conjunto de características esenciales cumple con los
ISO 9000
requisitos.
La propiedad o conjunto de propiedades esenciales a una cosa que
Real Academia Española permiten apreciarla como igual, mejor o peor que las restantes de su
especie.
El resultado de la interacción de dos dimensiones: la subjetiva (lo que el
Shewhart
cliente quiere) y la objetiva (lo que se ofrece).
Crosby El cumplimiento de requisitos.
Feigenbaum La satisfacción de las expectativas del cliente.
Juran La adecuación al uso del cliente.
La pérdida (monetaria) que el producto o servicio ocasiona a la sociedad
Taguchi
desde que es expedido.
Deming La satisfacción del cliente.
Calidad y gestión de la calidad no es lo mismo. En Menéndez (2010) se define a la gestión de la calidad

como el conjunto de caminos que se requiere para lograr la calidad deseada. El fundamento principal
es que tanto la calidad realizada, la calidad programada y la calidad necesaria coincidan entre sí, de tal
manera que todo lo que este fuera de esta coincidencia será motivo de derroche, gasto e insatisfacción.
En la figura 1.1, se muestra que los esfuerzos de las organizaciones deben apuntar a lograr la calidad
deseada (esperada), escogiendo el camino más adecuado de acuerdo al tamaño, los recursos, las
características, en fin de acuerdo al motivo sobre el que necesita gestionar la calidad.
Figura 1.1: Gestión de la calidad
Calidad
programada
Calidad G E S T ION DE L A
programada C AL IDAD
Calidad
esperada
Calidad Calidad
realizada necesaria
Calidad Calidad
realizada necesaria
Fuente: Menéndez, R. (2010)
En definitiva, la gestión de la calidad requiere que los esfuerzos encaminados a lograr la

calidad programada, realizada y necesaria sean los adecuados para cubrir un único fin,
la calidad deseada. Todo lo que se encuentre fuera de dicha coincidencia será motivo
de insatisfacción y/o gasto inapropiado.
Otro aspecto ha considerar es que la calidad es multidimensional, tal como se indica en la figura 1.1.1,
del texto básico, los tres ejes “Funcionalidad, Oportunidad y Costo” son los que determinan la calidad.
Estos componentes se presentan de forma transparente cuando están presentes en el producto o

15
servicio, pero resulta fácilmente reconocible cuando se carece o presenta deficiencias alguno de los
componentes. Ante esta situación Garvin (1984) propone las cinco “vistas” de la calidad:
• Vista trascendental
• Vista de usuario
• Vista de fabricante
• Vista de producto
• Vista basada en valor
Estimado estudiante, revise el sitio de la “AEC” (Asociación Española para la Calidad),

para conocer y analizar las funciones que desempeña con respecto a la calidad. El sitio
web es: http://www.aec.es.
Así como la AEC, existen otros organismos e instituciones que contribuyen al desarrollo de la calidad, es
el caso de organizamos relacionados con normativas, procesos, herramientas, etc.
Continuemos el estudio aclarando conceptos relacionados con la “calidad”, ya que la palabra abarca un
contexto bastante grande, y es preciso diferenciar los términos más comunes y por supuesto generales
que abarcan este tema.
Lea detenidamente el literal “1.3. Conceptos relacionados con la calidad” en el texto

básico.
Es necesario que todos estos conceptos los asimile de manera correcta, para evitar diversas
interpretaciones, por ejemplo: ¿“corrección” es lo mismo que “reparación”?, o algo más general, en ¿Qué
consiste la mejora de la calidad?. Seguro que la definición que podamos dar es variable, pero desde el
punto de vista de la calidad de un producto o servicio el enfoque debe ser el mismo. En el texto básico
los conceptos que se indican en este apartado son mínimos pero necesarios para empezar.
Actividad recomendada
Le invito a que busque en la web, información adicional sobre el estándar “ISO 9000
Sistemas de gestión de la calidad. Fundamentos y vocabulario”, para elaborar un mapa
conceptual de términos relacionados a:
• La calidad
• La gestión
• La organización
• Al proceso y producto
• Las características
• La conformidad
• La documentación
• Al examen
• La auditoría
• La gestión de la calidad para los procesos de medición

1.2. Evolución histórica de la calidad
De acuerdo con el autor del texto básico la calidad moderna surge a partir de 1924, donde se dan
importantes hechos que permiten el desarrollo de estándares que posteriormente se convertirán en
elementos fundamentales que se deberá adoptar para garantizar tanto los productos como los servicios
en una organización.
Para tener una idea concreta de cómo ha evolucionado la calidad a través del tiempo
es necesario que revise el tema “1.2. Evolución histórica de la calidad” en el texto básico.
Como puede ver, la calidad evoluciona a la par como lo han hecho diferentes disciplinas, por lo tanto
diferentes autores establecen la evolución de la calidad en base a hechos relevantes por parte de los
gurús de la calidad.
De la misma forma en Menéndez (2010), se establece que la calidad es un concepto cambiante que ha
evolucionado en el tiempo, lo que permite identificar seis etapas en el tiempo:
• Etapa artesanal
• Etapa de la industrialización
• Etapa de control final
• Etapa de control en proceso
• Etapa de control en diseño
• Mejora continua
Lo invito a revisar el anexo 1, donde se indica la evolución de la calidad en el tiempo y cómo los “gurús
de la calidad” han aportado con elementos que han marcado hitos importantes en esta área.
En el gráfico 1.2, se indican las etapas que se han dado en cuanto a la evolución de la gestión de la
calidad a través del tiempo, de acuerdo a Nava (2005).

17
Figura 1.2: Evolución del concepto de calidad
Fuente: Nava, V. (2005)

Elaboración: Manuel Sucunuta
1.3. Normas de calidad
La gestión de la calidad requiere de establecer ciertas normas y estándares que se utilizarán para los
productos y servicios destinados a satisfacer las necesidades de clientes y usuarios. Por lo que las
organizaciones públicas y privadas adoptan normas internacionales de calidad. En la actualidad las
normas de calidad son una necesidad antes que una moda ya que permite a las organizaciones ofrecer
servicios y productos altamente competitivos.
Existen algunos lineamientos orientados a la calidad en las organizaciones, entre los que tenemos:
• Gestión de la calidad total (TQM del inglés Total Quality Management): cuya filosofía busca
la excelencia en los resultados de las organizaciones.
• EFQM (European Foundation for Quality Model): quienes han desarrollado un modelo

de gestión de la calidad total o excelencia.
• ISO 9000: normativa desarrollada por la ISO (International Standard Organization) cuyo
objetivo es asegurar los sistemas de calidad de las organizaciones.
1.4. Gestión de la calidad total (TQM)
El concepto de calidad total hace alusión a la mejora continua con el objeto de lograr la calidad óptima
en las organizaciones. La TQM es utilizada ampliamente en áreas de: manufactura, educación, gobierno e
industrias. Su denominación de “total”, se debe porque comprende tanto a la organización de la empresa
como a las personas que en ella trabajan.
Para tener una idea global del tema, revise el literal “2.2. Gestión de la calidad total” en
el texto básico.

Lo expuesto en el texto básico sobre el tema es bastante general, pero se podría rescatar el “Ciclo de
Deming”, donde se establece la gestión mediante un proceso cíclico, tal como se indica en la figura 1.3.
Figura 1.3: Ciclo de Deming
Fuente: http://www.thegoatblog.com.br/archives/2010/01/entry_276.html
Existen otros modelos que se han desarrollado y que apuntan a la mejora continua, es el caso del modelo
de Baldrige1, el modelo de calidad europeo (E.F.Q.M)2, entre otros.
1.5. Normas ISO 9000
La ISO 9000, es un conjunto de normas sobre calidad y gestión de calidad determinadas por la Organización
Internacional de Normalización (ISO), que la conforman organismos nacionales de normalización, donde
las normas son preparadas por los comites técnicos de la ISO.
Las normas internacionales ISO3, permiten asegurar que los productos y servicios son: seguros, fiables
y de buena calidad. Para las empresas existen herramientas estratégicas que reducen los costos al
minimizar los residuos y errores e incrementar la productividad, permitiendo a las empresas acceder
a nuevos mercados y nivelar el campo de juego para los países en desarrollo, facilitando el comercio
mundial de forma libre y justa.
Es necesario que conozca la estructura de una de las normativas relacionadas con la

calidad, por lo que es necesario que revise detenidamente el literal “2.3 NORMAS ISO
9000”, con sus respectivos sub-literales en el texto básico.
Como pudo apreciar en la lectura, la primera edición de las normas ISO 9000, se publicó en 1987,
posteriormente han sido modificadas en: 1994, 2000 y 2008, siendo esta última la que actualmente está
vigente. Desde su primera edición se pretendió que se puedan aplicar a cualquier tipo de organización.
1 http://www.fundameca.org.mx/Biografias/mbaldrige.php
2 http://www.efqm.org
3 http://www.iso.org/iso/home.html

19
Estimado estudiante, ingrese al sitio http://www.iso.org/iso/home.htm, sitio oficial de

publicación de las normas ISO 9000. Revise cada una de las secciones y determine las
principales normas que se puedan utilizar en el medio.
Como puede ver, existen varias normativas que se pueden aplicar a diversos ámbitos. En las siguientes
unidades se abordará al detalle ciertas normas que se relacionan con el área de los productos software.
1.6. Modelo EFQM
El modelo EFQM se utilizó inicialmente a partir de 1992 como marco para los Premios EFQM. En
la actualidad se lo utiliza en Europa y otras partes del mundo, llegando a ser la base para diversos
premios. De la misma forma el modelo EFQM se utiliza como herramienta de autoevaluación para
las organizaciones, ya que proporciona una marco metodológico que permite medir su posición con
respecto a la excelencia.
El modelo EFQM no es un modelo normativo, la finalidad es la autoevaluación basada en un análisis

detallado del funcionamiento del sistema de gestión de la organización usando como guía los criterios
del modelo.
Revise detenidamente el literal “2.4 Modelo EFQM”, con sus respectivos sub-literales
en el texto básico. Ponga especial énfasis en los principios ya que son los que rigen el
modelo.
Como pudo apreciar en la lectura el modelo se basa en nueve principios, que claramente están
delimitados en dos grupos:
1. Agentes facilitadores: Que comprenden los criterios del 1 al 5. Han de tener un enfoque
bien fundamentado e integrado con otros aspectos del sistema de gestión, su efectividad
ha de revisarse periódicamente con el objeto de aprender y mejorar, y han de estar
sistemáticamente desplegados e implantados en las operaciones de la organización.
2. Resultados: Que comprenden los criterios del 6 al 9. Permiten mostrar tendencias positivas,
compararse favorablemente con los objetivos propios y con los resultados de otras
organizaciones, estar causados por los enfoques de los agentes y abarcar todas las áreas
relevantes.
La utilización del modelo por parte del equipo directivo permite que se puedan establecer planes de
mejora basados en hechos y el establecimiento de una visión común sobre las metas a alcanzar y las
herramientas a utilizar. Es decir, su aplicación se basa en:
• La comprensión profunda del modelo por parte de todos los niveles de dirección de la

empresa.
• La evaluación de la situación de la misma en cada una de las áreas.

Durante los últimos años, se ha utilizado el modelo EFQM 2010, pero tras la presentación oficial del
modelo “EFQM de Excelencia 2013” en el reciente Foro de la EFQM, y desde el punto de vista de evaluación,
reconocimiento y acreditación, los dos modelos 2010 y 2013 se utilizaron durante el año 2013. A partir
del 1 de enero de 2014, sólo se utilizará el modelo 2013.
En el portal del EFQM, se muestran los conceptos fundamentales de la excelencia, que sirven de base para
describir atributos de una cultura organizacional basada en la excelencia. En la figura 1.4 se presentan
estos conceptos que son utilizados como lenguaje común por la alta dirección.
El modelo EFQM con respecto a los sistemas de calidad ISO, se diferencian en que para
obtener la certificación ISO es necesario acogerse a ciertos estándares, mientras que el
modelo EFQM, es un sistema de máximos, basados en la mejora continua.
Figura 1.4: Modelo EFQM de excelencia
Fuente: http://www.efqm.org/efqm-model/fundamental-concepts
Estimado estudiante es necesario que ingrese al sitio del modelo EFQM (http://www.
efqm.org), y realice un mapa conceptual con los conceptos fundamentales de excelencia.
En el sitio escoja la sección EFQM MODEL, donde existen diferentes secciones que le
permitirán abstraer los conceptos necesarios.
1.7. Seis-Sigma
Seis-Sigma (Six-Sigma en inglés), es una metodología estadística que se basa en el método científico
para reducir significativamente los defectos establecidos por el cliente, de tal manera que establece un
esfuerzo en eliminar los defectos de cada unos de los productos, procesos y servicios.

21
Los esfuerzos de Seis-Sigma se enfocan en tres áreas principales:
• Mejorar la satisfacción del cliente.

• Reducir el tiempo de ciclo.
• Reducir los defectos.
La correcta aplicación de Seis-Sigma mejorará los procesos, maximizará el rendimiento de negocios y

aumentará los beneficios económicos. Si los principios están correctamente aplicados, con los resultados
se puede llegar a obtener grandes mejoras:
• Mejora de la satisfacción del cliente.

• Aumento de productividad y valor agregado.
• Aumento de capacidad y fabricación de productos.
• Reducción de defectos totales y de tiempos de ciclo.
• Aumento de confiabilidad del producto.
• Mejora de flujo de procesos.
• Incremento en el retorno de la inversión.
Revise detenidamente el literal “2.5 SEIS-SIGMA”, en el texto básico. Ponga especial

énfasis en las dos metodologías que propone el modelo.
Como pudo apreciar en la lectura, el uso de una de las dos metodologías DMAIC y DMADV, depende de
si ya existe o no un proyecto. DMAIC se utiliza en proyectos que desean mejorar el proceso existente, el
mismo que consta de cinco fases, tal como se muestra en la figura 1.5
Figura 1.5: Fases de la metodología DMAIC
Fuente: http://www.six-sigma.me/Six_Sigma_DMAIC_Prozess.htm

Tal como se indica en el texto básico la metodología DMADV, es utilizada en proyectos que desean
crear nuevos productos o procesos. En la figura 1.6 se muestran las cinco fases que componen esta
metodología.
Figura 1.6: Fases de la metodología DMADV
Fuente: http://www.cicsworld.org/blogs/kpanasoot/2009/12/six_sigma.html
Lo invito a ingresar al sitio http://www.dmaictools.com, donde se describe de forma

detallada las cinco fases de la metodología DMAIC. Elabore un mapa conceptual con los
entregables de cada fase.

23
Autoevaluación 1
Estimado estudiante, hemos finalizado el estudio de la presente unidad, por lo que se

recomienda realizar la autoevaluación que se indica a continuación con el propósito de
comprobar el conocimiento adquirido. Recuerde que al final de la guía se han incluido
las soluciones a estas autoevaluaciones; sin embargo deberá revisarlas sólo después de
haber obtenido sus propias respuestas, lo que le permitirá saber si los temas están o no
entendidos.
Lea detenidamente cada una de las preguntas y seleccione la alternativa correcta según corresponda.
1. Una de las vistas de calidad, se refiere a que la calidad se la puede reconocer pero no se la define,
esto se refiere a la:
a. Vista trascendental
b. Vista de usuario
c. Vista de fabricante
2. La vista basada en valor, se refiere a:
a. La calidad está conforme con las especificaciones

b. La calidad depende de lo que el cliente esté dispuesto a pagar
c. La calidad está unida a las características innatas del producto
3. La calidad necesaria es:
a. La que se pretende obtener

b. La que es capaz de obtener la persona que realiza el trabajo
c. La que el cliente exige o al menos la que le gustaría recibir
4. El control de calidad se refiere a:
a. Sistema de gestión que permite gestionar, dirigir y controlar la organización con respecto
a la calidad.
b. Cumplimiento de los requisitos de calidad
c. Proporcionar confianza para que se cumplan los requisitos de calidad
5. El incumplimiento de un requisito, se lo conoce como:
a. Acción correctiva
b. Desecho
c. No conformidad
6. El ciclo de Deming, consiste en:
a. Planificar y Actuar
b. Planificar, hacer, verificar y actuar
c. Planificar y hacer

7. Uno de los principios de la gestión de la calidad de la familia de normas ISO 9000, es “enfoque al
cliente”, que consiste en:
a. Identificar, entender y gestionar los procesos interrelacionados

b. Decisiones eficaces basadas en el análisis de los datos y la información
c. Comprender las necesidades actuales y futuras, satisfacer los requisitos y esforzarse en
exceder las expectativas de los clientes
8. Los criterios del modelo EFQM, que actúan como “agentes facilitadores”, son:
a. Liderazgo, Política y estrategia, Personas, Alianzas y Recursos, Procesos, Clientes, Resultados

en las personas, Resultados en los clientes, Resultados en la sociedad, y Resultados clave de
desempeño
b. Liderazgo, Política y estrategia, Personas, Alianzas y Recursos, y Procesos
c. Clientes, Resultados en las personas, Resultados en los clientes, Resultados en la sociedad, y
Resultados clave de desempeño
9. DMAIC es una metodología Seis-Sigma que se utiliza para:
a. Proyectos que pretenden mejorar un proceso existente

b. Proyectos que pretenden diseñar nuevos productos o procesos
c. Establecer normas basadas en procesos estadísticos
10. Las fases de la metodología DMADV son:
a. Definir, Medir, Analizar, Mejorar y Controlar

b. Captura, Análisis, Especificación y Validación
c. Definir, Medir, Analizar, Diseñar y Verificar

25
UNIDAD 2. CALIDAD DE LOS SISTEMAS DE INFORMACIÓN
Estimado estudiante
Una vez que se han estudiado y analizado los conceptos relacionados con la calidad en forma general,
ahora vamos a enfocarnos en la calidad de los sistemas de software. Inicialmente analizaremos
la necesidad de utilizar criterios de calidad en los productos software, además de conocer sobre las
diferentes normativas para producir y verificar que el producto software cumple con estándares de
calidad, basados en normas y métricas.
2.1. Situación actual de la calidad de los Sistemas de Información
En la década de los 60 se descubre el problema de la calidad del software cuando se desarrollan los
primeros grandes sistemas de software, ya que el software entregado era lento, poco fiable, difícil de
mantener y reutilizar (Sommerville, 2011). Por esta razón varias entidades se han interesado en analizar
y dar seguimiento a los desastres y fallos que el software puede llegar a causar en las organizaciones, es
así que el Standish Group4, mediante sus informes recopila información sobre las fallas en los proyectos
y precisamente nos muestra que, por ejemplo en el 2012 solamente el 39% de todos los proyectos
terminan con éxito, esto nos conduce a enfocar los esfuerzos en elementos fundamentales sobre la
calidad de los proyectos de software.
Revise detenidamente el literal “3.1 Situación de la calidad de SI” en el texto básico,

además ingrese a los enlaces a los que se hace referencia y analice los casos que se
indican.
Como se recomienda en el texto básico, analice los casos de pérdidas económicas debido a fallos en
el software que se han dado en el transcurso del tiempo. Busque fuentes confiables que realicen un
adecuado análisis de los fallos.
En la tabla 2.1, se indican los porcentajes de los proyectos terminados con éxito, deficientes y con fallas
en determinados años de acuerdo al informe de CHAOS publicado por el Standish Group.
Tabla 2.1: Situación de los proyectos de software (CHAOS, 2013)

Año Éxito(%) Deficiencias(%) Fallas(%)
1994 16 53 31
1996 27 33 40
1998 26 46 28
2000 28 49 23
2002 34 51 15
2004 29 53 18
2006 35 46 19
2008 32 44 24
2010 37 42 21
2012 39 43 18
4 Sitio: http:/www.standishgroup.com

Como se puede ver en la Tabla 2.1, en el 2012 existe un porcentaje del 39% de proyectos terminados
exitosamente, esto es: entregado a tiempo, dentro del presupuesto establecido y con las funciones
y características necesarias, de la misma manera podemos observar que el 43% de los proyectos son
deficientes, esto es: entrega tardía, por encima del presupuesto y/o con menos de las características y
funciones requeridas. Finalmente están los proyectos fallidos con el 18%, esto es: cancelado antes de su
finalización o entregados pero que nunca se utilizaron.
Los criterios que se han utilizado para analizar los proyectos tiene que ver con: Tiempo, costo y
características. En la figura 2.1 se muestra el comportamiento de cada uno de estos elementos por años.
Figura 2.1: Situación de los proyectos en base a criterios organizacionales
Fuente: CHAOS, (2013).
Como se observa en la figura 2.1, en el año 2010 existen excesos tanto en el tiempo como en el costo,
pero en lo referente a las características existe un decremento, esto nos da la pauta para pensar que se
está dando atención a los requisitos de alta prioridad.
2.2. Importancia de la calidad en los SI
Card (1995), establece que la calidad de los Sistemas de Información depende de dos factores: la cantidad
de consumidores y la cantidad de proveedores.
Le invito a revisar el literal “3.2 Importancia de la calidad en los SI”, en el texto básico.
Como pudo apreciar con la lectura, en la figura 3.2.1, del texto básico, la calidad se logra cuando se tiene
una gran cantidad tanto de proveedores como de consumidores. Tal es así que para ubicar un proyecto
en uno de los mercados que propone Card (1995), será necesario realizar un análisis de su planificación
en cuanto a costo, tiempo y características, por ejemplo:

27
Si tenemos un proyecto en el que se utilizará como técnica de desarrollo “Herramientas CASE”, entonces
se podría sugerir ubicarlo en el cuadrante “Time to market”, dado que el producto:
• En determinada fecha estará en el mercado.
• Existirá una alta demanda de clientes.
• La aplicación podrá ser utilizada por varios usuarios.
• Existen pocos proveedores que estén en capacidad de utilizar las herramientas CASE.
• Se tendrá que aprender a utilizar las herramientas sobre la marcha del proyecto.
Es necesario que realice un análisis sobre las técnicas del ejercicio 1 del texto básico para
sugerir el cuadrante en el que podrían ubicarse cada una de ellas. Busque información
adicional, sobre todo con relación a los proveedores y consumidores.
2.3. Componentes de calidad de un SI
Los componentes de calidad en un sistema de información no solamente tienen que ver con el producto
que se construye y se implemente o con el uso de algún software del mercado que se pueda utilizar; la
calidad involucra todos los elementos que giran en torno a la organización, por ejemplo las personas, las
actividades relacionadas con el proceso, el software, en fin todos aquellos componentes que intervienen
en los procesos de la organización.
Lo invito a revisar el literal “3.3 Componentes de calidad de un SI”, en el texto básico,

ya que es fundamental que se establezca cuales son los componentes que interactúan
directamente con los SI.
Tenga presente que en el modelo de las “cinco pes”, que se propone en el texto básico, el producto es
un componente más de todo el modelo. El hecho de incluir otros componentes donde se evalúa el
contexto de operación de la organización permitirá disponer de elementos adicionales que garanticen
el desempeño de toda la organización y no solamente de un producto software.
2.4. Calidad de un sistema de información y la gestión del conocimiento
Muchas de las organizaciones interesadas en conservar el conocimiento y experiencia que se ha logrado

a través de los años requiere que aquella información que no está en las bases de datos ni en los sistemas
de información en cierta medida se gestione y organice de tal manera que contribuya en las actividades
propias de la organización. Existe una gran cantidad de información que está en los correos electrónicos,
en las personas, en informes, etc., y que normalmente es de suma importancia para la organización.
La gestión del conocimiento es un tema al que muchas organizaciones le están dando un espacio muy
importante en su gestión, por lo que asociarlo con temas de calidad es fundamental para que dicho
conocimiento sea el adecuado. Muchos autores han definido a la gestión del conocimiento desde
diferentes contextos. Nonaka & Takeuchi (1995), definen a la gestión del conocimiento como: “Es la

capacidad de una organización para crear nuevo conocimiento, diseminarlo a través de la organización
y expresarlo en productos, servicios y sistemas”.
Revise el literal “3.4 Calidad de un SI y la Gestión del Conocimiento”, en el texto básico

conjuntamente con sus respectivos sub-literales.
Como pudo apreciar, la figura 3.4.1, referente a la arquitectura de gestión del conocimiento del texto
básico nos muestra los elementos básicos en los que se encuentra el conocimiento. Podemos precisar
que la capa “Información y Fuente de Conocimiento” considera todos aquellos elementos que aportan
con el conocimiento que posteriormente será gestionado por medios tecnológicos o por intervención
del usuario.
Las técnicas y herramientas para implementar la gestión del Conocimiento son

diversas. Elegir la técnica y herramienta adecuada depende de la organización ya que
si nos enfocamos en los modelos, estos involucran a las “fuentes de conocimiento” que
generalmente son gestionadas por personas, y que están de acuerdo a un contexto
organizacional.

29
Autoevaluación 2

entendidos.
Lea detenidamente cada una de la preguntas y seleccione la alternativa correcta según corresponda.
1. Los proyectos de software exitosos en el 2012, son del:
a. 39%
b. 70%
c. 15%
2. Los proyectos de acuerdo al informe CHAOS se evalúan en base a:
a. Metodologías y herramientas
b. Tiempo, costo y características
c. Requisitos de usuario
3. Con respecto a la importancia de los SI, el Time-to-market, se refiere a:
a. Cuando existe un mercado con pocos consumidores y muchos proveedores

b. Poner el producto lo antes posible en el mercado
c. Conseguir el costo más bajo
4. En el modelo de las “cinco pes” la calidad del sistema informático depende de:
a. Las personas, los procesos, los proveedores, los productos y las plataformas
b. Las personas, los proyectos, los proveedores, los procesos y las propuestas
c. Las propuestas, los proyectos, los procesos y las plataformas.
5. Unas de las áreas en las que se da la gestión del conocimiento es:
a. Herramientas CASE y entornos de desarrollo de software

b. La reutilización de experiencias
c. Localización de fuentes de información
6. Los modelos de predicción se los considera como:
a. Área en la que se da la gestión del conocimiento

b. Metodología para implementar la gestión del conocimiento
c. Herramientas para la gestión del conocimiento

7. Uno de los obstáculos relacionados con las cuestiones organizacionales en la implantación de la

gestión del conocimiento se refiere a:
a. Fallos del proceso de estrategia e implementación de gestión del conocimiento

b. Integrar los sistemas
c. Falta de tiempo de los empleados
8. Compartir conocimiento, experiencias, tecnología e innovación, es uno de los factores que

posibilitan la implantación de estrategias de gestión del conocimiento en las organizaciones de
software, se conoce como:
a. Tecnología
b. Liderazgo
c. Cultura organizacional
9. Cuando la estrategia empresarial es la reducción de costos, el tipo de conocimiento es:
a. Explícito
b. Tácito
c. Dinámico
10. El ciclo de aprendizaje del modelo DE (DYBA, 2003), se refiere a:
a. Comprender el proceso dialéctico que integra la experiencia local y los conceptos

organizacionales
b. Agrupar los resultados de las actividades de mejora de la organización
c. Describir el entorno general que impone restricciones y oportunidades de la organización.

31
UNIDAD 3. CALIDAD DEL PRODUCTO SOFTWARE
Estimado estudiante
En la presente unidad nos vamos a enfocar en los componentes relacionados con la calidad del software.
Inicialmente se realizará un estudio de los atributos de calidad de los modelos clásicos para luego hacer
un repaso sobre la familia de normas ISO relacionados con el producto software. Se enfocará en conocer
sobre los apartados de la familia de normas ISO/EIC 25000.
3.1. Modelos clásicos de calidad de productos software
Los modelos de calidad para el software que han sobresalido son: McCall, Evans y Marciniak, Deutsch y
Willis, FURPS, entre otros. Cada uno de estos modelos se descomponen en características o factores de
calidad que permiten determinar el grado de calidad de los proyectos de software.
Revise el literal “4.1 Modelos clásicos”, en el texto básico. Revise detenidamente el

modelo de calidad de McCall.
El modelo de McCall, inicialmente desarrollado para la Fuerza Aérea de los EE.UU en 1977, es uno de los
más renombrados actualmente. Este modelo busca reducir la brecha entre usuarios y desarrolladores
enfocándose en un número de factores de calidad que reflejen las prioridades de ambos. El modelo
establece una jerarquía de Perspectivas (3), Factores (11), Criterios de Calidad (23) y Métricas (41), tal
como se puede apreciar en la figura 4.1.1 del texto básico.
En definitiva cada una de las organizaciones han adoptado modelos de acuerdo a las
necesidades y circunstancias. Estos modelos requieren de atributos de calidad, que
no son otra cosa que las cualidades o propiedades de calidad que la aplicación debe
satisfacer. Finalmente los modelos establecen técnicas que permiten medir estos
atributos durante la verificación, ya sea que estén expresados de forma cuantitativa o
cualitativa.
Busque en cualquier fuente de información sobre el significado de cada uno de los

atributos de calidad que se indican en la tabla 4.1.1 del texto básico.
3.2. Normas relacionadas con la calidad del software
El objetivo de la Ingeniería del Software es desarrollar productos de calidad, por lo que se requiere aplicar
los métodos más efectivos en el proceso de desarrollo, esto sugiere el uso de diferentes normativas para
asegurar y certificar la calidad del producto.
La Organización Internacional de Normalización (ISO) es el organismo encargado de promover el

desarrollo de normas internacionales. Su función principal es la de buscar la estandarización de normas
de productos y seguridad para las empresas u organizaciones (públicas o privadas) a nivel internacional.
El contenido de los estándares está protegido por derechos de copyright y para acceder a ellos el público
debe comprar cada documento.

Estimado estudiante, revise el literal “4.2 Normas ISO sobre calidad de producto software”,
en el texto básico.
En concreto la norma ISO/IEC 25000, proporciona una guía en el uso de los estándares internacionales,
llamados “Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE), que consiste en una
serie de normas basadas en la ISO 9126 e ISO 14598, cuyo objetivo es guiar el desarrollo de productos
software con la especificación y evaluación de requisitos de calidad.
El modelo establece diez características, seis que son comunes a la vista interna y externa, tal como se
muestra en la figura 3.1.
Figura 3.1: Características de la Calidad según la ISO/IEC 9126
Fuente: ISO 25000
Como se puede ver en la figura 4.2.1 del texto básico, las dos familias de normas: la ISO 9126 con sus
métricas y la ISO 14598 con sus normas, cubren los aspectos relacionados con la evaluación de productos
software.
Entre los beneficios de utilizar SQuare tenemos:
• El modelo representa la calidad esperada del producto de software.
• Planteo del desdoblamiento de las necesidades o expectativas en calidad en uso, calidad

externa y calidad interna.
• Permite una mayor eficacia en la definición del software.
• Plantea la evaluación de productos intermedios.
• Propone una calidad final a través de las evaluaciones intermedias.

33
• Permite efectuar un rastreo entre las expectativas, requisitos y medidas de evaluación.
• Mejora la calidad del producto.
3.3. Familia de normas ISO 25000
La familia de normas ISO/IEC 25000, proporciona una guía para el uso de una serie de estándares
internacionales, llamados Requisitos y Evaluación de calidad de productos software. Constituyen una
serie de normas basadas en la ISO 9126 y en la ISO 14598, y su objetivo principal es guiar el desarrollo de
los productos de software. Establece criterios para la especificación de requisitos de calidad de productos
software, sus métricas y su evaluación.
En la figura 3.2, se indican las secciones que componen la familia de normas ISO 25000, donde se
destacan las guías para la gestión de la calidad.
Figura 3.2: Arquitectura de la familia de normas ISO/IEC 25000
Fuente: ISO 25000
Revise el literal “4.3 Familia de normas ISO 25000”, con todos los sub-literales en el texto
básico. Cabe señalar que se aborda los cinco apartados de las normas ISO 25000.
La figura 4.3.1, del texto básico, claramente indica los 5 apartados de los que consta la familia de normas
ISO 25000. Es importante aclarar que cada uno de estos apartados cubre un conjunto de elementos que
permiten gestionar la calidad de forma adecuada. Las principales ventajas respecto a sus predecesoras
son:
• Mejor coordinación de la guía en la medición y evaluación de la calidad de los productos

software.
• Mejor orientación para la especificación de requisitos de calidad de los productos software.
• Mejor distinción entre las partes beneficiarias del producto software del sistema y sus
necesidades.

Lo invito a ingresar al sitio oficial de la ISO 25000 Calidad del producto software http://
iso25000.com/index.php/en/ y revise cada una de las secciones del portal, en especial
la relacionada con los estándares.
En la figura 3.3, se muestra las secciones de la familia de normas ISO 25000, con sus respectivas normas,
que ayudan a determinar los atributos de calidad.
Figura 3.3: Normas ISO/IEC 25000
Fuente: ISO 25000

Elaboración: Manuel Sucunuta
En la tabla 3.1, se indica al detalle las normas de la familia ISO/IEC 25000, con una pequeña descripción
de cada una. Además en el texto básico se hace un análisis mas detallado de cada uno de los apartados
de la norma.
Tabla 3.1: Familia de normas ISO/IEC 25000 (ISO 25000)

ISO 2500n  Gestión de la calidad
ISO/IEC 25000  
Guía de Describe la arquitectura de SQuaRe, la terminología y los modelos de
SQuaRE referencia.
ISO/IEC 25001  Planificación Describe el soporte necesario para la gestión en la evaluación y especificación
y Gestión de requisitos de calidad.
ISO 2501n  Modelo de calidad
Detalla las características para la calidad interna, externa y en uso. Este
ISO/IEC 25010  Modelo de detallado se hace descomponiendo cada tipo de calidad en características,
Calidad aunque el nivel de descomposición es mayor para la calidad en uso que para
la interna y externa.
ISO 2502n  Medición de calidad
ISO/IEC 25020  Modelo de
Presenta una introducción y un modelo de referencia común para las
referencia para  la medida
primitivas, medidas de calidad interna, externa y en el uso.
con guía
Define y especifica medidas base y derivadas a utilizar durante el desarrollo
ISO/IEC 25021  Primitivas del software. Este conjunto de primitivas se utilizará como entrada en el
proceso de medida de la calidad interna, externa y en el uso.

35
ISO 2500n  Gestión de la calidad

ISO/IEC 25022  Medidas de Define las medidas de calidad interna en función de las características y
Calidad Interna subcaracterísticas.
ISO/IEC 25023  Medidas de Define las medidas de calidad externa en función de las características y
Calidad Externa subcaracterísticas.
ISO/IEC 25024  Medidas de Describe un conjunto de medidas para la calidad en el uso y una guía para la
Calidad en Uso utilización de estas medidas.
ISO 2503n  Requerimientos de calidad
Este conjunto de estándares están orientados a ayudar en la especificación
de requisitos. Estos requisitos pueden utilizarse en la licitación de contratos
ISO/IEC 25030  Requisitos de de desarrollo pero también como entradas en el proceso de evaluación. Cabe
Calidad destacar que según el propio estándar, el proceso de definición de requisitos
se corresponde con procesos técnicos definidos en el estándar ISO/IEC 15288
Proceso de ciclo de vida.
ISO 2504n  Evaluación de calidad
Describe los requisitos generales a cumplir en la especificación y evaluación
ISO/IEC 25040  Modelo de de la calidad de un software. Proporciona una base para la evaluación de la
referencia para la evaluación calidad de un software. Especifican los requisitos que deben cumplir los
métodos de evaluación y medida de un producto software.
ISO/IEC 25041  Módulos de Describe la estructura y contenido de la documentación que debe describir
evaluación los módulos de evaluación.
ISO/IEC 25042  Proceso de Proporciona requisitos y recomendaciones de carácter práctico para la
evaluación para implementación de la evaluación cuando esta se da en paralelo con el
desarrolladores desarrollo.
ISO/IEC 25043  Proceso de Describe requisitos y recomendaciones para la medida y evaluación
evaluación para sistemática de productos software comerciales, productos desarrollados a
compradores medida, o productos a modificar bajo contrato.
ISO/IEC 25044  Proceso de Detalla requisitos y recomendaciones para la evaluación de software de
evaluación para evaluadores forma que dicha evaluación sea fiable y comprensible.
Finalmente en la figura 3.4, se concluye la relación que existe entre proceso y producto. Tanto la calidad
interna como externa tienen incidencia en el proceso y viceversa, por lo tanto la calidad del producto
depende de la calidad del proceso.
Figura 3.4: Relación entre calidad de proceso, calidad de producto y efectos del producto
Fuente: Hernández, 2011

Autoevaluación 3

entendidos.
Responda apropiadamente cada una de las preguntas que se indican a continuación.
1. ¿Para qué sirve la norma ISO/IEC 25000?
………………………………………………………………………………………………
………………………………………………………………………………………………
2. ¿ Cuál es el objetivo principal de la norma ISO/IEC 25000?
………………………………………………………………………………………………
………………………………………………………………………………………………
3. ¿ Por quién fue desarrollada la norma ISO/IEC 25000?
………………………………………………………………………………………………
………………………………………………………………………………………………
4. ¿ En qué consiste la división del modelo ISO/IEC 2501n?
………………………………………………………………………………………………
………………………………………………………………………………………………
5. ¿ Qué es calidad del producto?
………………………………………………………………………………………………
………………………………………………………………………………………………
6. La norma que define todos los modelos, términos y definiciones comunes referenciados por todas
las otras normas de la familia ISO 25000, se llama:
a. ISO/IEC 2500n – División de gestión de la calidad

b. ISO/IEC 2501n – División de modelo de calidad
c. ISO/IEC 2502n – División de medición de calidad

37
7. La norma sobre modelado de calidad (ISO/IEC 2501n), clasifica las propiedades del software en:
a. Procesos de negocio humanos y Sistemas mecánicos

b. Hardware, Software y Datos
c. Inherentes y Asignadas
8. La calidad en uso contempla las siguientes características:
a. Adaptabilidad, Capacidad para ser instalado

b. Efectividad, Eficiencia, Satisfacción, Libre de riesgos y Cobertura del contexto
c. Adaptabilidad, Eficiencia, Capacidad para ser reemplazado
9. El modelo de calidad del producto software en cuanto a la característica de “Fiabilidad” se divide

en:
a. Madurez, Disponibilidad, Tolerancia a fallos y Recuperabilidad

b. Completitud funcional, Corrección funcional y Adecuación funcional
c. Comportamiento temporal, Utilización de recursos y Capacidad
10. En la norma sobre “Medición de Calidad (ISO 2502n)”, las medidas internas se refiere a:
a. Propiedades estáticas del software que se puede evaluar durante su desarrollo

b. Propiedades relacionadas con la ejecución del software en el hardware y un sistema
operativo
c. Una visión de caja negra

O BIMESTRE
6.5. Competencias
SEGUNDO BIMESTRE
COMPETENCIAS GENÉRICAS DE LA UTPL

Trabajo en equipo II: Contribuye en la consolidación y desarrollo del equipo, favoreciendo la comunicación, el reparto equilibrado de tareas, el clima
interno y la cohesión.
üü Actúa constructivamente para afrontar los conflictos del equipo.
6.6. Planificación para el trabajo del alumno
COMPETENCIAS
ESPECÍFICAS DEL INDICADORES DE TIEMPO DE
ESPECÍFICAS DE ACTIVIDADES DE APRENDIZAJE
COMPONENTE APRENDIZAJE DEDICACIÓN
EDUCATIVO
UNIDAD4. Calidad del proceso • Estudiar la unidad 4 de la guía didáctica. • Identifica las actividades
Construir modelos y Semana 1 y 2
Describe modelos de software relacionadas con el
especificaciones de • Desarrollar las actividades recomendadas.
aseguramiento de proceso de producción y el • 8 horas de
software que 4.1. El proceso software
calidad aplicables a • Desarrollar la autoevaluación 4. proceso de gestión de autoestudio
permitan validar un 4.2. Gestión de procesos software
proyectos de software.
producto previo a su • Desarrollar los ejercicios del capítulo 5 del • 8 horas de
implementación. ingeniería de 4.3. Modelado de procesos software interacción
texto básico.
software 4.4. Entornos de IS orientados al
proceso • Desarrollar la evaluación a distancia.
UNIDAD5. Evaluación y mejora de • Estudiar la unidad 5 de la guía didáctica. • Reconoce los elementos
procesos. necesarios para la mejora
• Desarrollar las actividades recomendadas.
de procesos software.
5.1. La mejora de procesos Semana 3 y 4
Identifica • Desarrollar la autoevaluación 5.
5.2. La norma ISO/IEC 90003 • Utiliza la norma que
oportunidades de • 8 horas de
• Desarrollar los ejercicios del capítulo 7 del permita la mejora de
mejora de procesos 5.3. Seis-Sigma para software autoestudio
texto básico. procesos.
de desarrollo de 5.4. Mejora de procesos en PYMES • 8 horas de
software de acuerdo • Desarrollar la evaluación a distancia. • Utiliza los modelos de
5.5. CMMI interacción
al modelo CMMI mejora del SEI.
39
• Interactúe en el EVA con aportes
5.6. IDEAL • Relaciona los procesos de
significativos de la temática que proponga
5.7. SCAMPI el tutor. desarrollo con estándares
de mejora de procesos.
COMPETENCIAS
40
ESPECÍFICAS DEL INDICADORES DE TIEMPO DE
ESPECÍFICAS DE ACTIVIDADES DE APRENDIZAJE
COMPONENTE APRENDIZAJE DEDICACIÓN
EDUCATIVO
UNIDAD6. Gestión de la calidad de los • Estudiar la unidad 6 de la guía didáctica. • Reconoce los
proyectos. componentes de calidad
• Desarrollar las actividades recomendadas.
de los proyectos.
6.1. Gestión de la calidad de los
• Desarrollar la autoevaluación 6. Semana 5 y 6
proyectos • Desarrolla el plan de
Desarrollar 6.2. Plan de aseguramiento de la • Desarrollar los ejercicios del capítulo 10 y aseguramiento de calidad • 8 horas de
auditorias de 11 del texto básico. de software. autoestudio
calidad de software
productos y
6.3. Revisiones e inspecciones • Desarrollar la evaluación a distancia. • 8 horas de
procesos vinculados
a la gestión de TI. 6.4. Calidad de las personas • Interactúe en el EVA con aportes interacción
significativos de la temática que proponga

el tutor.
Unidad 4 a la 6 Revisar los contenidos como preparación para Semana 7 y 8

la evaluación presencial.
• 8 horas de
Interactúe en el EVA con aportes significativos autoestudio
de la temática que proponga el tutor.
• 8 horas de
interacción
SEGUNDO BIMESTRE

SEGUNDO BIMESTRE Guía didáctica: Control de Calidad
6.7. Orientaciones específicas para el aprendizaje por competencias
UNIDAD 4. CALIDAD DEL PROCESO SOFTWARE
Una vez analizadas las normativas para aplicar calidad es necesario enfocarse la calidad para el proceso
software, por lo que es necesario que se analice las actividades que están relacionadas con la gestión
y modelado de los procesos para el software. Los elementos del proceso, los lenguajes que se utilizan
para modelar y los metamodelos son contenidos indispensables para asegurar la calidad en base a
normativas.
4.1. El procesos software
La ingeniería del software ha permitido el desarrollo de productos software basados en modelos y

metodologías que han permitido enfocar el desarrollo y la gestión de forma ordenada, donde el proceso
es un elemento indispensable para poder gestionar cada una de las actividades.
Revise el literal “5.1 Introducción” del texto básico para recordar algunos conceptos y
actividades relacionadas con los procesos, ya que son contenidos abordados en otras
asignaturas.
Tenga presente la diferencia entre proceso de producción y de gestión en lo relacionado al software,

ya que no son lo mismo, pero se vuelven complementarios a la hora de construir un producto lo
suficientemente bueno que garantice un desempeño adecuado.
La ingeniería del software se enfrenta a una problemática debido a que el desarrollo y mantenimiento del
software es un trabajo altamente complejo por lo tanto los proyectos software son difíciles de gestionar.
En los últimos años se ha desarrollado un campo en la Ingeniería del Software, denominado Tecnología
de Proceso Software cuya finalidad es aportar al mundo del software algunas soluciones que han sido
eficaces en el mundo de la ingeniería de producción tradicional para facilitar la Gestión de los Proyectos.
La importancia que la tecnología de Proceso de Software tiene dentro de la Ingeniería

del Software se comprueba viendo su aparición en el SWEBOK(Software Engineering
Body of Knowledge), donde 3 de las 10 áreas de conocimiento que forman la Ingeniería
del Software se refieren a esta tecnología. También utiliza 4 de las 7 disciplinas
relacionadas

41
Guía didáctica: Control de Calidad SEGUNDO BIMESTRE
Dado el siguiente caso: “La empresa xyz, ha decidido incursionar en la producción de un

nuevo producto que lo lanzará al mercado en el próximo semestre, se han realizado los
estudios pertinentes y se han aprobado desde la dirección ejecutiva realizar la producción
del producto. También se ha visto la necesidad de construir un software que permita
automatizar los procesos de producción y de esta manera tener un control adecuado de
los recursos que se utilizan”.
Desde el punto de vista de los procesos de software determine:
• Los procesos de gestión y
• Los procesos de producción.
4.2. Gestión de procesos software
Como se vio en el apartado anterior, cuando nos referimos a los procesos de software, la gestión es la
que se encarga de la estimación, planificación y control de los recursos necesarios para poder ejecutar y
controlar el proceso de producción.
Florac, Park & Carleton (1997), indican que el concepto de gestión de procesos se basa en los principios
de la tecnología del control estadístico de procesos, donde se establece que para mantener niveles
estables de variabilidad, los procesos deberán producir resultados predecibles, solo entonces se puede
decir que un proceso esta bajo control estadístico. Al existir variaciones, para mantener el control estas
deberán estar dentro de los límites predecibles, de lo contrario los procesos estarán fuera de control,
por lo que es necesario identificar la causa que originan la inestabilidad, para ser corregida y lograr
nuevamente la estabilidad.
Revise el literal “5.2 Gestión de los procesos software” del texto básico.
Es necesario prestar mucha atención a la compleja interrelación que se produce en un Proceso de

Software entre los diversos factores organizacionales, culturales, tecnológicos y económicos.
La calidad enfocada a la gestión del proceso, permite determinar que:
• Los Procesos Software tienen una influencia directa en la calidad de los productos software.
• Las aplicaciones software son productos cada vez más complejos lo que influye en la
complejidad de sus procesos de desarrollo y mantenimiento.
Un Proceso de Software es un Proceso de Negocio realizado por una organización para desarrollar y
mantener un producto software, por lo tanto su mejora está en función de un conjunto de actividades
agrupadas en fases e interrelacionadas.
En la figura 4.1, se indica las etapas de la gestión de los procesos software, observe que la etapa en la
que se define el proceso, se especifica el modelado como técnica principal para entender y delimitar el
proceso.

Figura 4.1: Responsabilidades clave en la Gestión de Proceso de Software
Fuente: García, F. (2008)
4.3. Modelado de procesos software
Es fundamental representar la forma de hacer las cosas en la organización, para esto se requiere de
los Lenguajes de Modelado de Procesos que permiten expresar los procesos de software en forma de
modelos de procesos de software, esto es, que todos los elementos del proceso (actividades, roles,
recursos, etc.) se puedan describir.
Revise el literal “5.3 Modelado de los procesos software” del texto básico, conjuntamente
con todos sus sub-literales.
Como pudo apreciar en la lectura, es fundamental en un proceso software la forma en que interactúan
sus elementos, precisamente en la figura 5.3.1, del texto básico se establecen las relaciones entre los
elementos básicos del modelo.
Otro de los temas que se abordan en este apartado, es lo referente a los Metamodelos de proceso
software, que permiten construir modelos específicos de un determinado dominio de interés. Uno de
los metamodelos que se proponen en el texto básico es el SPEM 2.0, que permite definir modelos de
procesos de ingeniería del software y de ingeniería de sistemas.
En la figura 4.2, se muestra un ejemplo de modelo de procesos de ingeniería de software utilizando

SPEM 2.0.

43
Figura 4.2: Ejemplo: Desglose de un Proceso utilizando SPEM
Fuente: Ruiz & Verdugo, 2008
Lo invito a buscar en la web el documento “Guía de uso de SPEM 2 con EPF Composer”
de Francisco Ruiz y Javier Verdugo, para profundizar en temas relacionados con el
metamodelo.
4.4. Entornos de Ingeniería del software orientados al proceso
Los Entornos de Ingeniería del Software Orientados al Proceso (PSEE), permiten dar soporte a los
procesos de ingeniería, mediante un modelo de procesos definido mediante un lenguaje de modelado
de proyectos (LMP).
Revise el literal “5.4 Entornos de Ingeniería del Software Orientados al Proceso” del texto
básico, conjuntamente con todos sus sub-literales.
Como pudo apreciar en la lectura, a más de indicar las características y la clasificación del entorno de
PSEE, se describen tres ejemplos (SPADE, APEL y SERENDIPITY), que proporcionan soporte a los procesos
software.
De acuerdo al sitio oficial de SPADE, se indica que esta es una plataforma de agentes interoperable y
multiplataforma, implementado en Python. Del mismo modo la interfaz gráfica está basada en HTTP,
siendo accesible desde multitud de dispositivos. Las principales características de la plataforma SPADE
es:
• Soporte del estándar FIPA mediante el protocolo de mensajería instantánea XMPP (agentes

AMS y DF incluidos)

• Notificación de presencia entre agentes.
• Organizaciones virtuales basadas en el protocolo de multi-conferencia MUC.
• Comunicación P2P entre agentes.
• Invocación remota de servicios entre agentes usando el estándar XML-RPC.
• Procesadores de lenguajes de contenido en SL0 y RDF.
• Modelo de agente BDI basado en conocimiento, deseos e intenciones.
• Modelo de comportamientos: cíclicos, periódicos, tiempo de espera, una ejecución, máquina

de estados finita y basado en eventos.
• Soporte de comunicación con otras plataformas mediante diversos protocolos de

transporte: JADE (vía HTTP o XMPP) y SIMBA.
• Publicación y subscripción de eventos mediante el estándar PubSub.
• Interfaz gráfica basada en web.
En la figura 5.3, se muestran los componentes que conforman la arquitectura de SPADE, en donde se
puede apreciar que la tecnología XMPP basa sus raíces en el uso de agentes.
Figura 5.3: Arquitectura SPADE
Fuente: https://github.com/javipalanca/spade

45
Autoevaluación 4

recomienda realizar la autoevaluación que se indica a continuación con el propósito
de comprobar el conocimiento adquirido. Recuerde que al final de la guía se han
incluido las soluciones a estas autoevaluaciones; sin embargo deberá revisarlas sólo
después de haber obtenido sus propias respuestas, lo que le permitirá saber si los
temas están o no entendidos.
1. Un proceso software se define como:
a. Se organiza, gestiona, mide, soporta y mejora el desarrollo, independiente de las técnicas y

métodos utilizados
b. El que permite organizar y estimar los recursos
c. El que se relaciona con la gestión de proyectos
2. Los procesos de software constan de los subprocesos:
a. Tecnología de desarrollo de software y comportamiento organizacional

b. Producción y gestión
c. Métodos y técnicas de desarrollo
3. En la gestión de los procesos software, la definición del proceso consiste en:
a. Evaluar y detectar en que se puede mejorar

b. Controlar en todo momento la ejecución del proyecto
c. Modelar el proceso
4. En el modelado de procesos software, al conjunto de artefactos a ser desarrollados, entregados y

mantenidos en un proyecto es lo que se denomina
a. Recurso
b. Producto
c. Actividad
5. El lenguaje de modelado de procesos que representa dónde y porqué persona de la organización

son implementados los elementos del proceso, se lo conoce como:
a. Funcional
b. Informativo
c. Organizacional

6. Cuando los LMP proporcionan soporte únicamente a aspectos de entendimiento y comunicación,

se los conoce como:
a. No ejecutables
b. Simulados
c. Ejecutables
7. SPEM es:
a. Una metodología de desarrollo de software

b. Un metamodelo para definir modelos de procesos de IS
c. Un framework para desarrollo de aplicaciones
8. En SPEM 2 el paquete que contiene las clases y abstracciones que sirven de base para las clases de
los demás paquetes, se conoce como:
a. Process Structure
b. Process Behavior
c. Core
9. El elemento del motor de procesos que ejecuta el modelo controlando las herramientas usadas
mediante el proceso, se conoce como:
a. Interprete
b. Entorno
c. Repositorio
10. Al PSEE que da soporte al análisis, diseño y ejecución de los procesos software, y que para modelar
utiliza el formalismo SLANG, se conoce como:
a. APEL
b. SPADE
c. SERENDIPITY

47
UNIDAD 5. EVALUACIÓN Y MEJORA DE PROCESOS
En la presente unidad vamos a enfocarnos en los temas relacionados con la mejora de procesos, ya
que muchas de las empresas dedicadas al desarrollo de software requieren que sus productos sean de
mayor calidad cada vez con tiempos mas cortos y con presupuestos mas bajos. Estudios indican que
gran cantidad de organizaciones dedicadas al desarrollo de software lo conforman las PYMES por lo que
los esfuerzos de mejora en la actualidad se inclinan hacia estas organizaciones.
5.1. La mejora de procesos
Hoy en día existe una demanda por software de mejores características, más barato y entrega en plazos
mas cortos, por lo que las compañías dedicadas al software han dirigido sus esfuerzos a la mejora de
procesos software con el objetivo de producir software de calidad, reducir los costos y acelerar los
procesos de desarrollo. Por lo que la mejora de procesos (SPI en inglés, MPS en español), se refiere a
comprender los procesos actuales y cambiarlos para incrementar la calidad del producto y reducir los
costos y tiempo de desarrollo. En Pressman (2010) se establece que la parte más complicada del MPS es
lograr el consenso para iniciar y definir una estrategia para implementarlo de forma continua a través de
una organización de software.
En Sommerville (2011), se indican dos enfoques para la mejora y cambio de procesos: el enfoque de
madurez de procesos y el enfoque ágil, todo esto en base a tres componentes fundamentales que
determinan el ciclo del proceso, tal como se indica en la figura 5.1.
Figura 5.1: El ciclo de mejora de procesos
Fuente: Sommerville, 2011
El proceso de “mejora de procesos”, es cíclico, el mismo que incluye tres subprocesos:
• Medición del proceso
• Análisis del proceso
• Cambio del proceso

La mejora de procesos es una actividad a largo plazo y continua, por lo que cada una de las etapas
del proceso de mejoras puede durar varios meses con una constante evolución de los procesos. A
continuación vamos a indicar brevemente en que consisten los subprocesos de acuerdo a Sommerville
(2011).
1. Medición del proceso:
Se miden atributos del proyecto o producto actual. Dado que la meta es mejorar de acuerdo con
los objetivos de la organización, por lo que se constituye en una línea de referencia que ayuda a
determinar si son efectivas las mejoras del proceso. Se pueden recopilar tres tipos de métricas
• El tiempo que tarda en completarse un proceso particular
• Los recursos requeridos para un proceso particular
• El número de ocurrencias de un evento particular
2. Análisis del proceso:
Se valora el proceso actual y se identifican las debilidades y cuellos de botella. Se puede utilizar
modelos como por ejemplo mapas de procesos que describan al proceso actual, para determinar
características de rapidez y robustez. Las técnicas mas comunes para este análisis son:
• Cuestionarios y entrevistas
• Estudios etnográficos
3. Cambio del proceso:
Son las propuestas que servirán para atacar las debilidades encontradas en el proceso actual. Al
realizar estos cambios se vuelve a ejecutar el ciclo para verificar la efectividad de los cambios.
Existen cinco etapas en el proceso de cambio:
• Identificación de mejoras
• Priorización de las mejoras
• Introducción de cambios a los procesos
• Capacitación de proceso
• Afinación del cambio
Con esta breve introducción revise el literal “7.2 Panorámica General” del texto básico,
conjuntamente con su sub-literal.
Es importante que analice detenidamente el “framework” de armonización que se propone de forma

gráfica en la figura 7.2.2 del texto básico. Observe que es fundamental partir del plan y objetivos
estratégicos de la organización para obtener las estrategias adecuadas de mejora.

49
5.2. La norma ISO/IEC 90003
ISO/IEC 90003 fue elaborada por el Comité Técnico Conjunto ISO/IEC JTC 1 Tecnología de la Información,
Subcomité SC-7 Ingeniería de sistemas y de software. La aplicación de las normas cubre a software que:
• Es parte de un contrato comercial con otra organización (desarrollo a medida)
• Está disponible en el mercado (paquetes)
• Es utilizado para apoyar los procesos de una organización (desarrollos internos)
• Está embebido en un producto de hardware
• Está relacionado a servicios de software
Revise el literal “7.3 La norma ISO/IEC 90003” del texto básico.
Como pudo apreciar, la norma ISO 9000-3 no impone un modelo de ciclo de vida específico. Asimismo,
no provee métodos específicos para evaluar la capacidad de aseguramiento de la calidad de una
organización. Por lo tanto, puede ser combinado con otros enfoques más específicos, como por ejemplo
el modelo Espiral de Boehm (Boehm, 1988). En resumen, la norma supone un cambio cualitativo para
que los ambientes tecnológicos más especializados avancen, especialmente los enfocados al diseño y
desarrollo de software.
5.3. SEIS-SIGMA para software
Seis-Sigma (Six-Sigma en inglés), se lo puede utilizar en varios frentes, tal es así que se puede utilizar
como definición de calidad de software, o como método de mejora de procesos.
Revise el literal “7.4 Seis-Sigma para software” del texto básico.
Observe detenidamente la tabla 7.4.1 del texto básico, donde se realiza un mapeo de las fases de
desarrollo seis-sigma y DFSS.
5.4. Mejora de procesos en PYMES
Muchos autores indican que en la actualidad las organizaciones que tienen que ver con el software, las
pequeñas y microempresas tienen una importante responsabilidad en el mercado mundial de productos
software y servicios, ya que de acuerdo a recientes estudios se estima que el 80% de las organizaciones
de desarrollo de software son las PYMES (Espinosa-Curiel, 2013), por lo que la competencia en el mercado
del software fomenta a muchas de estas organizaciones a iniciar una mejora de proceso software, cuyo
objetivo es:
• Aumentar la productividad y la calidad de sus procesos y productos de software.
• Reducir el tiempo y los costes asociados al desarrollo.
• Incrementar la satisfacción de los clientes

En la tabla 5.1, se muestran algunos ejemplos de atributos de proceso que pueden ser objeto de mejora,
todo dependerá de lo que este dispuesto a mejorar.
Tabla 5.1: Atributos de proceso
Características del proceso Cuestiones clave
¿En qué medida el proceso está definido explícitamente y que tan fácil es
Comprensión
entender la definición del proceso?
¿Hasta qué punto el proceso se basa en el proceso genérico?
Estandarización ¿Hasta dónde se usa el mismo proceso en todas las partes de una
compañía?
¿Las actividades del proceso culminan en resultados claros, de modo que
Visibilidad
el avance del proceso se observa externamente?
¿El proceso incluye recolección de datos u otras actividades que permiten
Mensurabilidad
medir las características del proceso o del producto?
¿En qué medida pueden usarse herramientas de software para apoyar las
Soportabilidad
actividades del proceso?
¿El proceso definido es aceptable y útil para los ingenieros responsables
Aceptabilidad
de elaborar el producto software?
¿El proceso está diseñado de tal forma que se evitan o se detectan errores
Fiabilidad
de proceso antes de que deriven en errores de producto?
Robustez ¿El proceso puede continuar a pesar de problemas inesperados?
¿El proceso puede evolucionar para reflejar los requerimientos cambiantes
Mantenibilidad
de la organización o mejoras identificadas en el proceso?
¿Qué tan rápido puede completarse el proceso de entrega de un sistema
Rapidez
a partir de una especificación dada?
Fuente: Sommerville, 2011
Por ejemplo, asumiendo que se desea mejorar el atributo “Compresión”, entonces se relaciona con la
definición del proceso para los involucrados y la forma en que estos entienden. Cuales deberían ser las
acciones a tomar ante la pregunta ¿En qué medida el proceso está definido explícitamente y qué tan
fácil es entender la definición del proceso? Con respecto a la comprensión no es una pregunta que se
puede responder con un SI o NO, sino que requiere de un exhaustivo análisis en donde es importante
analizar el proceso con cada una de sus tareas y actividades desde el punto de vista de los participantes
para lograr una adecuada comprensión, puede ser que se requiera hacer un ajuste al proceso y esto
consecuentemente ocasiona que se tenga que hacer una adecuada planificación que se acople a un
proceso de mejora.
Revise el literal “7.6 Mejora de procesos en PYMES” con cada uno de los sub-literales
que se indican en el texto básico.
El SEI ha desarrollado modelos de procesos para MPS. Cada uno de los modelos proveen un enfoque
disciplinado de ingeniería, que se focaliza en el gerenciamiento del proyecto, mejorando y estableciendo
los fundamentos para diferentes estrategias. Los modelos representativos son: CMMI, SCAMPIE E IDEAL,
que los abordaremos en los siguientes literales.

51
5.5. CMMI
El modelo CMII es una guía para los procesos gerenciales, técnicos y de soporte. Es un modelo de
referencia para evaluar los procesos y ayudar a su mejora mediante una ruta evolutiva. Estructura las
etapas por las que atraviesan las organizaciones de software. Además propone estrategias de mejora a
partir de la identificación de los puntos críticos para la calidad del software y la revisión constante del
proceso (CMMI, 2010).
Revise el literal “8.2 Framework CMMI” con cada uno de los sub-literales que se indican
en el texto básico.
Como podrá haber apreciado, podemos decir que el CMMI da soporte en dos caminos usando niveles.
Estos dos caminos de mejora están asociados con dos tipos de niveles: niveles de capacidad y niveles
de madurez. Estos niveles corresponden a dos aproximaciones de mejora de procesos llamadas
“representaciones”. Las dos representaciones se las conoce como: “continua” y “por etapas.” El uso de la
representación continua permite alcanzar “niveles de capacidad”. El uso de la representación por etapas
permite alcanzar “niveles de madurez”. En la tabla 5.2, se indican de forma general ciertos características
de cada uno de los niveles.
Tabla 5.2: Representaciones del modelo CMMI

Continua Por niveles
• Permite a la organización tener un camino
• Permite a la organización elegir el orden del
predefinido de mejora ya comprobado.
proceso de mejora que mejor se adapte a las
necesidades. • Enfocado en proveer a la organización un
conjunto de procesos con capacidades
• Mejora la visibilidad de las capacidades
específicas representadas por un nivel de
obtenidas en cada área de proceso individual.
madurez.
• El proceso de mejora puede ser realizado en
• Resume el resultado del proceso de mejora en
ritmos diferentes según las áreas.
un único indicador: nivel de madurez
El metamodelo CMMI continuo describe un proceso en dos dimensiones, tal como se observa en la
figura 5.2, en la que cada área de proceso se valora formalmente contra metas y prácticas, permitiendo
clasificarse de acuerdo a los niveles:
• Nivel 0: Incompleto
• Nivel 1: Realizado
• Nivel 2: Administrado
• Nivel 3: Definido
• Nivel 4: Administrado cuantitativamente
• Nivel 5: Optimizado

Figura 5.2: Perfil de capacidad de área de proceso CMMI.
Fuente: Pressman, 2010
Dependiendo de la organización CMMI puede implementarse en tres constelaciones: CMMI para

desarrollo, CMMI para servicios y CMMI para adquisición. En la figura 5.3 se indican las constelaciones
del CMMI.
Figura 5.3: Las tres dimensiones críticas
Fuente: CMMI, 2010
Revise el literal “8.3 CMMI-DEV”, “8.4 CMMI-ACQ” y “8.5 CMMI-SVC” del texto básico.
Como pudo apreciar cada uno de los modelos buscar realizar las mejoras y en cada uno de sus niveles se
especializan las actividades para poder determinar cada vez una mejor calidad.
CMMI for development (DEV)
Es el más utilizado, se emplea para la mejora de procesos de las organizaciones que desarrollan productos
y servicios de software y hardware. Contiene prácticas que cubren la administración de proyectos, de
procesos, ingeniería de software, de hardware, ingeniería de sistemas y procesos de soporte.

53
CMMI for services (SVC)
Esta dirigido principalmente a las empresas que se encuentran en el sector de servicios (consultoría,
capacitación, logística, recursos humanos, etc.), proporcionando las directrices para lograr administrar
y entregar servicios mediante procesos previamente definidos y controlados. Con el modelo se pueden
lograr los siguientes objetivos:
• Establecer un nuevo sistema o cambiarlo, sin afectar, de forma negativa, el servicio que se
tiene de antemano.
• Identificar las fallas dentro del servicio proporcionado y lograr prevenirlas en situaciones
posteriores.
CMMI for acquisition (ACQ)
Proporciona todas las pautas necesarias a las organizaciones que se dedican principalmente a adquirir
productos y servicios de otras empresas, para integrarlos en un producto final que cumpla con las
necesidades del cliente. Las empresas conocidas como “integradoras” podrían optar por este modelo.
Uno de los objetivos del modelo es evitar o eliminar barreras y problemas en el proceso de adquisición,
mediante mejoras en la eficiencia operativa.
Para dar soporte a aquellas organizaciones que utilizan la representación continua, todos los modelos
CMMI reflejan niveles de capacidad en su diseño y contenido. Son cuatro niveles de capacidad, cada uno
es una capa base para la mejora de procesos en curso, y se denominan por los números del 0 al 3:
0. Incompleto.
1. Realizado.
2. Gestionado.
3. Definido.
Un nivel de madurez es una plataforma evolutiva definida para la mejora de procesos de la organización.
Cada nivel de madurez desarrolla un subconjunto importante de procesos de la organización,
preparándola para pasar al siguiente nivel de madurez. Los niveles de madurez se miden mediante el
logro de las metas específicas y genéricas asociadas con cada conjunto predefinido de áreas de procesos.
Los cinco niveles de madurez para este modelo, permiten la mejoras de proceso en curso, y se identifican
por los números del 1 al 5, tal como se puede apreciar en la figura 5.4.
1. Inicial.
2. Gestionado.
3. Definido.
4. Gestionado cuantitativamente.
5. En optimización.

Figura 5.4: Niveles de madurez
Fuente: CMII, 2010
Áreas de proceso
Cada área de proceso identifica un conjunto de actividades relacionadas, que realizadas en forma
colectiva alcanzan un conjunto de metas consideradas de importancia para mejorar la capacidad del
proceso. Son 22 áreas de procesos en total, agrupadas en 4 categorías, tal como se indica en la tabla 5.3.
Tabla 5.3: Áreas de proceso por categoría.

Categoría Área Nivel
Gestión de requerimientos (REQM) 2
Integración del Producto (PI) 3
Desarrollo de Requisitos (RD) 3
Ingeniería
Solución Técnica (TS) 3
Validación (VAL) 3
Verificación (VER) 3
Monitorización y Control del Proyecto (PMC) 2
Planificación del Proyecto (PP) 2
Gestión de Gestión de Acuerdos con Proveedores (SAM) 2

proyectos Gestión Integrada del Proyecto (IPM) + IPPD 3
Gestión de Riesgos (RSKM) 3
Gestión Cuantitativa del Proyecto (QPM) 4
Formación en la Organización (OT) 3
Definición de Procesos de la Organización (OPD)+IPPD 3
Gestión de
Enfoque en Procesos de la Organización (OPF) 3
procesos
Rendimiento de Procesos de la Organización (OPP) 4
Innovación y despliegue organizacional (OID) 5

55
Categoría Área Nivel

Gestión de la Configuración (CM) 2
Medición y Análisis (MA) 2
Soporte Aseguramiento de la Calidad del Proceso y del Producto (PPQA) 2
Análisis de Decisiones y Resolución (DAR) 3
Análisis Causal y Resolución (CAR) 5
5.6. IDEAL
El SEI desarrolló un modelo de mejoramiento organizacional denominado IDEAL, que es representativo

de muchos modelos de procesos para MPS. Este modelo provee un enfoque disciplinado de ingeniería,
que se focaliza en el gerenciamiento del proyecto, mejorando y estableciendo los fundamentos para
una estrategia a largo plazo. El modelo consiste de cinco fases con sus respectivas actividades.
Revise el literal “8.7 IDEAL” con cada uno de los sub-literales que se indican en el texto
básico.
Adicional a la lectura lo invito a visitar el sitio del SEI y acceder al documento relacionado con el modelo
IDEAL (http://www.sei.cmu.edu/library/assets/idealmodel.pdf ).
Tal como lo pudo apreciar con la lectura, el proceso de MPS es cíclico de, con las etapas de: medición,
análisis y cambio; mientras que en Pressman (2010), se establece que el proceso MPS es una filosofía que
requiere que una organización:
a. Se observe en el espejo
b. Se vuelva mas astuta para tomar elecciones inteligentes
c. Seleccione el modelo de procesos
d. Ejemplifique el modelo en su entorno operativo
e. Evalúe lo que se realizó
5.7. SCAMPI
SCAMPI proviene de las siglas en inglés de Método Estándar de Evaluación CMMI para la mejora de
procesos. La evaluación SCAMPI determina el nivel, de madurez o capacidad, que ha alcanzado una
organización que aplica CMMI en sus procesos. Su objetivo principal es determinar las fortalezas y
oportunidades de mejora de los procesos de la organización, respecto a las prácticas descritas en el
modelo de referencia.
Revise el literal “8.6 SCAMPI” que se indica en el texto básico.
Como pudo apreciar en la lectura, el SEI no establece un mecanismo de vigilancia para garantizar el
mantenimiento de los resultados, por eso no es una certificación; pero establece un período de tres años
en los cuales reconoce los resultados publicados como válidos, tal como se puede apreciar en el sitio
oficial del SCAMPI: https://sas.cmmiinstitute.com/pars/.

Autoevaluación 5

1. De los modelos de MPS, los que permiten juzgar y decidir sobre la capacidad de los procesos y la
madurez de las organizaciones, se los conoce como:
a. Estándares y guías
b. Métodos de evaluación
c. Modelo de referencia
2. La norma ISO/IEC 90003, se refiere a:
a. Proporcionar pautas para las organizaciones en la aplicación de ISO 9001 para la adquisición,
provisión, desarrollo, operación y mantenimiento del software.
b. Ofrecer técnicas para garantizar que se entiende los requisitos del cliente.
c. Buscar e identificar clientes para entender el proceso actual antes de cualquier cambio.
3. A la iniciativa integradora de diferentes propuestas de mejora de procesos software para micro,

pequeñas y medianas empresas desarrolladoras de software, se las conoce como:
a. ISO 29110
b. EFQM
c. Competisoft
4. En el framework CMMI, el que proporciona guías para controlar y gestionar los procesos de
desarrollo, se conoce como:
a. CMMI para los servicios (CMMI-SVR)

b. CMMI para la adquisición (CMMI-ACQ)
c. CMMI para el desarrollo (CMMI-DEV)
5. En lo referente al área de procesos del Framework CMMI, la planificación del proyecto se refiere a:
a. Establecer y mantener planes que definan las actividades del proyecto.

b. Desarrollar y mantener una capacidad de medición.
c. Establecer y mantener la integridad de los productos de trabajo.

57
6. La gestión de acuerdos del CMMI-ACQ, permite:
a. Desarrollar y analizar los requerimientos contractuales y de los clientes

b. Demostrar que un producto o servicio adquirido cumple con el uso previsto.
c. Garantizar que el proveedor y comprador lleven a cabo el trabajo de acuerdo con los
términos del contrato del proveedor.
7. La gestión estratégica del servicio, en el CMMI-SVC, se refiere a:
a. Gestionar la adquisición de productos.

b. Establecer y mantener los servicios estándar de acuerdo con las necesidades y planes
estratégicos.
c. La entrega de servicios en conformidad con los acuerdos de servicio.
8. En el modelo SCAMPI, el desarrollo del plan de evaluación se realiza en la fase de:
a. Planificación y preparación de la evaluación

b. Realización de la evaluación
c. Informe de resultados
9. El modelo IDEAL consta de las fases:
a. Planificación y preparación de la evaluación, Realización de la evaluación, y Establecimiento

de resultados
b. Iniciación, Diagnóstico, Establecimiento, Actuación y Aprendizaje
c. Planificación, Diagnostico, Establecimiento y Resultados
10. En la fase de Establecimiento del modelo IDEAL se:
a. Crean y se llevan a cabo las acciones destinadas a mejorar las áreas identificadas en las fases
previas.
b. Tratar de hacer más efectiva la siguiente iteración del modelo.
c. Priorizan los aspectos que la organización ha decidido mejorar

UNIDAD 6. GESTIÓN DE LA CALIDAD DE LOS PROYECTOS
Vamos a finalizar el estudio de la presente asignatura enfocando la calidad en el proyecto software,

específicamente la formalización de las pruebas, mediante el análisis del plan de aseguramiento de
la calidad del software. De igual forma se analizan dos temas puntuales: las revisiones e inspecciones
cuestiones fundamentales a la hora de ejecutar los escenarios de prueba a un producto y la forma en
que los errores (en el producto), pueden amplificarse.
6.1. Gestión de la calidad de los proyectos
El PMBOK (Guide to the Project Management Body of Knowledge) en su quinta edición, es una guía para
la gestión de proyectos, que permite a los administradores de proyectos aplicar practicas necesarias que
permitan alcanzar los resultados esperados.
Revise el literal “10.2 Gestión de la calidad de los proyectos según PMBOK” que se indica
en el texto básico, con sus respectivos sub-literales
Observe detenidamente la figura 10.2.2 del texto básico, en el que se indican cada uno de los elementos
(Entradas, Herramientas y Técnicas, y Salidas), que conforman los procesos del área de gestión de la
calidad de los proyectos.
En el anexo A del texto básico, se indica el uso de cada una de las técnicas y herramientas de calidad
necesarias para proceder con los procesos de gestión de la calidad.
Busque en la web, ejemplos acerca de:
• Diagramas de flujo.
• Diagrama Causa-Efecto.
• Diagrama de Pareto.
6.2. Plan de aseguramiento de calidad del software
El plan de aseguramiento de la calidad del software permite entregar a la administración una visibilidad
adecuada del proceso utilizado y los productos construidos mediante acciones planificadas y sistemáticas
que aseguren la calidad de dichos procesos y productos. Cabe indicar que el plan se basa en el estándar
IEEE 730-2002.
Revise el literal “10.3 Estándares IEEE 730-2002” que se indica en el texto básico, con sus
respectivos sub-literales.

59
Es necesario que analice detenidamente los sub-literales que se señalan en el texto básico, dado que
cada sub-literal es una parte del modelo que está compuesto el estándar. En el Anexo 2 se plantea un
ejemplo general basado en el estándar que se indica.
En conclusión podríamos indicar que el plan de aseguramiento de calidad del software busca establecer
los responsables, fases, técnicas, indicadores y documentación que se usarán para asegurar la calidad
del producto.
El aseguramiento no es una actividad que se desarrolla por si sola, se requiere de la elaboración de

actividades paralelas relacionadas con la gestión y desarrollo del proyecto, lo que deriva en la elaboración
de documentos.
Lo invito a buscar en la web, las plantillas que permiten documentar las actividades de
gestión y desarrollo del proyecto de software.
6.3. Revisiones e inspecciones
Un tema importante con la calidad del producto software son las revisiones y las inspecciones que se
realizan como parte de las actividades de QA, cuyo objetivo es analizar la calidad de los entregables del
proyecto.
1. Revisiones
Las revisiones de software sirven para validar la calidad y/o el estado de un producto. El producto
a revisar puede ser un documento, un módulo, un prototipo, etc. Existen distintos tipos de
revisiones; cada una especializada en un determinado producto o escenario. Las revisiones ayudan
a encontrar falencias, y a identificar riesgos, que serían difíciles de encontrar de otra manera.
Considere:
• Leer y seguir el manual sobre “Protocolos de Comunicación entre miembros del Proyecto”
• Revisar el trabajo, no al autor.
• Buscar defectos, no formas de implementar sus ideas.
• Seguir las instrucciones del moderador, y los tiempos asignados a cada actividad.
• Que las críticas destructivas, no benefician a nadie.
Asuntos a Revisar (entre pares):
• Correctitud.
• Variables en desuso.
• Funciones omitidas.
• Práctica de programación pobres.
• Redundancia.

• Adhesión al estándar de escritura de código.
• Límite de tiempo: 60 min. (por sesión)
Auditorías
Revisión formal, su objetivo es:
• Evaluar el nivel de conformidad con estándares y planes.
• Controlar que se han hecho los cambios programados.
• Auditar el proyecto… en forma interna o externa.
• El auditor es el responsable de verificar el proceso de auditoría, y las acciones derivadas de

esta verificación.
• Límite de tiempo: 60 min. (por sesión)
2. Inspecciones
Las inspecciones del software:
• Es una técnica muy efectiva para descubrir errores.
• No se requiere que el sistema esté en ejecución por lo que pueden ser aplicadas a cualquier
representación del sistema (requerimientos, diseño, datos de prueba, etc.).
• Varios y diferentes defectos pueden ser descubiertos en una sola inspección.
• Se resalta la reutilización y el conocimiento de programación de modo que los revisores

están preparados para ver aquellos tipos de errores que aparecen comúnmente.
• Las inspecciones y pruebas son complementarias y no técnicas de verificación opuestas, por

lo que deberían ser utilizadas en conjunto durante el proceso de verificación y validación.
• Las inspecciones pueden chequear conformidad con una especificación, pero no

conformidad con los requerimientos reales del cliente.
• Las inspecciones no pueden chequear características funcionales, como es: rendimiento,

usabilidad, etc.
• Las inspecciones sobrecargan el costo inicial pero conducen a ahorros luego que los equipos
adquieren experiencia en su utilización.
• Las inspecciones de programa, se encargan de detectar defectos, que consisten en: errores
lógicos, anomalías en el código o el no cumplimiento de estándares.
En la figura 6.1, se indica los pasos que debe realizarse al momento de hacer una inspección a un
producto software.

61
Figura 6.1: El proceso de inspección
Fuente: Sommervile, 2010
Funciones de inspección
Durante la inspección el equipo de QA delega responsabilidades, los mismo que se definen los siguientes
roles.
• Autor: La persona que creó el producto del trabajo se está inspeccionando.
• Moderador: Es el líder de la inspección, por lo tanto revisa y coordina los planes de inspección.
• Lector: La persona que revisa los documentos de uno en uno.
• Grabador/Escritor: La persona que documenta los defectos. que se encuentren durante la

inspección.
• Inspector: La persona que examina el producto de trabajo para identificar posibles defectos.
Amplificación y eliminación de defectos
En Pressman (2010) se sugiere usar un modelo de ampliación del defecto, tal como se muestra en la
figura 6.2, dónde el cuadro representa una acción de la ingeniería de software. Durante el desarrollo los
errores nuevos que se generan pueden pasar inadvertidos. En ciertos casos con los errores de las etapas
anteriores, donde cierto número pueden multiplicarse por un factor x de amplificación en la acción en
curso.

Figura 6.2: Amplificación y eliminación de defectos
La figura 6.3, ilustra un ejemplo para un proceso de software en el que no se hacen revisiones. Se realizan
revisiones en cada etapa de prueba dónde se detecta y corrige el 50% de todos los errores; se puede
observar que los 10 errores de entrada del diseño preliminar, se amplifican a 94 antes que empiecen las
pruebas. Luego de realizar las pruebas finalmente los errores latentes son 12, que de acuerdo al diseño
preliminar (10 errores), es un valor significativo.
Figura 6.3: Amplificación del defecto sin revisiones
La figura 6.4, muestra la misma situación con la diferencia que se efectúan revisiones de diseño y código
como parte de cada acción de ingeniería de software. En este caso son 10 los errores iniciales de diseño
preliminar que se amplifican a 24 antes de empezar las pruebas, en consecuencia al finalizar las pruebas
existen solamente 3 errores latentes.

63
Figura 6.4: Amplificación del defecto con revisiones
Podemos concluir que mientras se realicen revisiones que permitan eliminar los defectos en etapas
tempranas del proyecto, permitirá que el esfuerzo en las revisiones será menor, de lo contrario los
factores de amplificación establecen el esfuerzo que se traduce en costo para resolver los defectos en las
fases finales del proyecto.
Lo invito a revisar el texto de Ingeniería del Software de Rogger Pressman, séptima

edición, el literal 15.2 Amplificación y eliminación del defecto, y realice un análisis del
caso hipotético que se expone.
6.4. Calidad de las personas
El modelo de madurez de capacidad de personal (P-CMM), es propuesto por el SEI de la Carnegie-Mellon,

diseñado para ayudar a las organizaciones a mejorar la capacidad de su equipo humano y la efectividad
de la organización. El modelo ofrece un marco de mejora de la madurez que las organizaciones pueden
utilizar para gestionar y mejorar sus acciones para atraer, motivar y retener al personal mejor calificado.
Los componentes esenciales de la estructura del modelo People CMM son los siguientes:
• Niveles de madurez
• Áreas de proceso
• Objetivos
• Prácticas
El modelo Personal-CMM (People-CMM, en inglés), consiste de cinco niveles de madurez como se

indica en la tabla 6.1, o estados evolutivos, a través de los cuales evolucionan las prácticas y procesos
de gestión de las capacidades del recurso humano de una organización. En cada nivel de madurez, un
nuevo sistema de prácticas es superpuesto a aquellas implementadas en los niveles anteriores. Cada

superposición de prácticas eleva el nivel de sofisticación por medio de cual la organización desarrollo
su fuerza laboral. Para esto, las organizaciones se equiparan de prácticas más poderosas para atraer,
desarrollar, organizar y motivar a sus empleados.
Tabla 6.1: Niveles y áreas del modelo Personal CMM

Disciplinas de Personal CMM
Creación de una
Niveles Desarrollo de Motivación y
cultura y de Manejo del
Capacidades y administración
grupos de personal
Competencias del desempeño
trabajo
Alineamiento Innovación
Optimizado Capacidad de mejora continua del desempeño continua del
organizacional personal
Integración de
Tutoría competencias. Administración Administración de
Predecible Recursos basados Grupo de trabajo cuantitativa del las capacidades
en competencias con poder de desempeño organizacionales.
decisión.
Desarrollo de Prácticas
Desarrollo de
grupos de basadas en Planeación de la
competencias.
Definido trabajos. competencias. planta de
Análisis de personal.
Cultura de Desarrollo de
competencias.
participación carrera
Compensación
Administración
Formación y Comunicación y
Administrado del desempeño. Contratación
desarrollo coordinación
Ambiente
laboral
Inicial Sin definir Sin definir Sin definir Sin definir
Fuente: Pressman (2010)
Revise el literal “11.2 People CMM” que se indica en el texto básico, con sus respectivos
sub-literales.
Como pudo apreciar en la lectura, el modelo Persona CMM (PCMM), se centra únicamente en la gestión
del recurso humano, por lo que mediante prácticas a través de los diferentes niveles se van adquiriendo
un estado de mejora continua.

65
Autoevaluación 6

Lea detenidamente cada una de las afirmaciones y conteste con una V si considera que es verdadera
o una F si considera como falsa.
1. ( ) El PMBOK se clasifica en nueve áreas de conocimiento.
2. ( ) El área de “Gestión de la calidad”, del PMBOK determina políticas, objetivos y

responsabilidades.
3. ( ) La Línea base es considerada como una entrada en el proceso de “Realizar el control
de Calidad”.
4. ( ) El muestreo estadístico es una de las herramientas para planificar la calidad.
5. ( ) Al realizar el control de calidad las actualizaciones de los documentos del proyecto se
la considera como entradas.
6. ( ) Los diagramas causa-efecto, gráficos de control, diagramas de flujo, Histogramas se

los considera como herramientas para realizar el control de calidad.
7. ( ) El estándar IEEE 730-2002, es una plantilla que permite desarrollar el plan de
aseguramiento de calidad del software.
8. ( ) En el propósito del SQAP debe ir la lista de los elementos software cubiertos por el
plan y su uso previsto.
9. ( ) El control de medios del SQAP se refiere a las prácticas y procedimientos a seguir para
la generación de informes.
10. ( ) El People CMM, es un modelo de procesos que se centra únicamente en los procesos
de gestión de recursos humanos.

SOLUCIONARIO Guía didáctica: Control de Calidad
7. Solucionario
PRIMER BIMESTRE
Unidad 1: Introducción a la calidad
Autoevaluación 1
Pregunta Respuesta
1. A
2. B
3. C
4. B
5. C
6. B
7. C
8. B
9. A
10. C

67
Guía didáctica: Control de Calidad SOLUCIONARIO
Unidad 2: Calidad de los sistemas de información
Autoevaluación 2
Pregunta Respuesta
1. A
2. B
3. B
4. A
5. A
6. C
7. A
8. C
9. A
10. A

Unidad 3: Calidad del producto software
Autoevaluación 3
Pregunta Respuesta
Proporciona una guía

para el uso de las nuevas
series de estándares
1. internacionales, llamadas
requisitos y evaluación de
calidad de productos de
software
Guiar el desarrollo de los
productos de software
2. con la especificación y
evaluación de requisitos de
calidad
Fue desarrollada por el
subcomité SC 7( Ingeniería
3. de software y sistemas) del
comité técnico conjunto
ISO/IE JTC.
Presenta un modelo
de calidad detallado,
4. incluyendo características
para la calidad interna,
externa y en uso
Es el grado en el q el producto
software incorpora unas
características, de tal
5. manera q se garantiza
su eficiencia de uso a los
requerimientos de los
clientes.
6. A
7. C
8. B
9. A
10. A

69
SEGUNDO BIMESTRE
Unidad 4: Calidad del proceso software
Autoevaluación 4
Pregunta Respuesta
1. A
2. B
3. C
4. B
5. C
6. A
7. B
8. C
9. A
10. B

Unidad 5: Evaluación y mejora de procesos
Autoevaluación 5
Pregunta Respuesta
1. B
2. A
3. C
4. C
5. A
6. C
7. B
8. A
9. B
10. C

71
Unidad 6: Gestión de la calidad de los proyectos
Autoevaluación 6
Pregunta Respuesta
1. V
2. V
3. F
4. V
5. V
6. V
7. V
8. V
9. F
10. V

ANEXOS Guía didáctica: Control de Calidad
8. Anexos
El presente material ha sido reproducido con fines netamente didácticos,

cuyo objetivo es brindar al estudiante mayores elementos de juicio para la
comprensión de la materia, por lo tanto no tiene fin comercial.
Anexo 1

73
Guía didáctica: Control de Calidad ANEXOS
Anexo 2: Ejemplo de Plan de aseguramiento de calidad del software
1. Propósito
El objetivo fundamental de documento es definir el PLAN DE ASEGURAMIENTO DE LA CALIDAD

del proyecto “Sistema de Gestión de Trámites de la UTPL” (SGT-UTPL), así como la organización ,
tareas y responsabilidades del equipo de SQA. Esto permitirá proporcionar guías, herramientas,
técnicas y metodologías para la realización de las actividades y de los reportes de calidad.
El contenido de este plan especifica las acciones a realizar para cada una de las interacciones de
las fases de:
• Inicio.
• Elaboración.
• Construcción.
• Transición.
La meta de este plan de aseguramiento de la calidad es verificar que todo el software y la
documentación se entregue y cumplan con todos los requerimientos técnicos.
2. Documentos de referencia
Los documentos que aportarán para la elaboración del plan son:
• IEEE STD 730-2002 (Standard for Software Quality Assurance Plans)

• Plan de administración de la configuración del proyecto SGT-UTPL.
• Documento de reglas de reglas.
• Documento de reglas de documentación.
• Documento de reglas de codificación.
• Plan de especificación de requerimientos de software.
• Plan de desarrollo del proyecto.
3. Gestión
En la siguiente figura se muestra la organización del SQA con relación a la organización del
proyecto.
A continuación se indica la responsabilidad de cada uno de los componentes de acuerdo a la

estructura organizacional de la figura anterior.

Responsabilidad Es responsable de:

• Establecer un programa de calidad para el proyecto.
• Identificar las actividades de SQA que se llevarán a cabo.
• Revisar y aprobar el plan de SQA del proyecto SCPCM .
Administrador SQA
• Resolver problemas relacionados con la calidad.
• Auditar y reportar las funciones SQA para este proyecto.
• Identificar los factores de calidad a ser implementados en el SCPCM
• Revisar y comentar sobre el plan de SQA del Proyecto.
• Implementar las actividades definidas de calidad acordadas en el plan
Administración y de SQA.
configuración del
software • Asegurarse que los factores de calidad referentes a ACS son
implementados en el proceso de ACS.
• Revisar que los interesados en el proyecto cumplan con el plan de ACS.
• Revisar y aprobar el Plan de aseguramiento de la calidad del proyecto
SCPCM
• Identificar a una persona o grupo que realice las funciones de SQA
• Identificar los factores de calidad a ser implementados en el SCPCM
Administración del
proyecto • Resolver y dar seguimiento a cualquier asunto de calidad levantado por
el SQA
• Identificar y asegurarse que los factores de calidad se implemente en el
software.
• Identificar, desarrollar y mantener documentos de planeación.
• Comentar acerca del plan de SQA.
• Implementar la calidad en las pruebas de acuerdo al plan SQA
• Resolver y dar seguimiento a cualquier asunto de calidad que tenga
Pruebas relación con las pruebas del sistema
• Verificar que los factores de calidad se implementaron en el sistema
• Implementar las practicas de pruebas en el sistema, procesos y
procedimientos, como está definido en el documento de pruebas
• Comentar acerca del plan de SQA
• Implementar la calidad en el diseño y codificación de acuerdo a este
plan de SQA
• Resolver y dar seguimiento a cualquier asunto de calidad que tenga
relación con el diseño del sistema, arquitectura del sistema y desarrollo
Diseño y codifica-
del mismo.
ción
• Identificar, implementar y evaluar los factores de calidad que van a ser
implementados en el sistema.
• Implementar el diseño, arquitectura, desarrollo, procesos y
procedimientos necesarios para el sistema, siguiendo los documentos
de planeación para cada uno de estos.
• Dar seguimiento a los riesgos identificados.
• Buscar medidas de contingencia de los riesgos identificados
Administración de
riesgos • Comentar acerca del plan de aseguramiento de la calidad
• Notificar al administrador del proyecto cuando un riesgo identificado,
se convierta en un problema.

75
Responsabilidad Es responsable de:

• Realizar el ERS
Administrador de • Comentar acerca del plan de aseguramiento de la calidad
requerimientos • Implementar calidad en el ERS
• Analizar los requerimientos
• Realizar el plan de Métricas para el proyecto
• Evaluar las métricas recabadas a lo largo del proyecto
Métricas
• Comentar acerca del plan de aseguramiento de la calidad
• Implementar la calidad en el plan de métricas del proyecto
El responsable de SQA tiene la libertad de reportar anomalías y no conformidades al siguiente o al nivel

más alto en la cadena de liderazgo en la organización del proyecto.
4. Documentación
A continuación se indican los documentos que estarán bajo la administración del equipo de
configuración:
Documento Descripción
Especificación de Describe los requisitos del software tanto
requerimientos de software funcionales como no funcionales.
Plan de aseguramiento de Describe los planes y roles que adoptara cada uno
calidad de los interesados en el desarrollo del software.
Describe los módulos a ser probados, así como las
Plan de pruebas pruebas que se utilizaran , entradas y salidas
esperadas para cada prueba.
Administración de la Describe la nomenclatura utilizada en el proyecto
configuración así como la forma en que se determina la línea base.
Describe lo que se va a implementar, los calendarios,
Plan de desarrollo de
actividades y responsabilidades de los miembros
software
del equipo de desarrollo.
5. Estándares, Prácticas, Convenciones y Métricas
Los estándares seguir durante el desarrollo del proyecto estarán dadas por los documentos de:
• Reglas de Reglas.
• Reglas de documentación.
• Reglas de Codificación.
• Reglas de Diseño.
• Estándar IEEE 730
• Estándar IEEE 829
6. Revisiones de software
Propósito
Con respecto a las revisiones que requiere garantizar la calidad del desarrollo de software,
verificando que se cumplan con los estándares mencionados en la sección 5 de este documento.

Requerimientos mínimos
Para asegurar que la implementación del software satisfaga lo requerimientos técnicos, se requiere
realizar lo siguiente:
• Revisión de las especificaciones de software.

• Revisión de la arquitectura.
• Revisión del modelo de diseño propuesto al detalle.
• Revisión del plan de verificación y validación.
• Revisiones de gestión (si es necesario realizar actualización en el PSQA).
• Revisión de la gestión de la configuración del software.
• Revisión post-implementación
Auditorias
Mediante técnicas de observación directa, validar la documentación del usuario.
7. Pruebas
Las pruebas serán realizadas como lo indica el documento de Plan de pruebas
8. Informes de problemas y acciones correctivas
Si se detectan problemas o fallas en algún documento aceptado, se generara un registro que

describirá el problema encontrado, y así poder hacer las correcciones que correspondan. Los
registros generados deben incluir la siguiente información:
• Proyecto
• Fecha
• Documento fuente (aceptado)
• Descripción
• Estatus
• Importancia (crítico, no crítico, editorial)
Después de generar el registro, se creara una nueva versión del documento, en donde se corregirán
los problemas. Esta nueva versión del documento debe indicar los registros que se corrigen o
ajustan.
Todo registro esta asociado a un proyecto, estos se pueden listar, ver su estatus y la versión del
producto que los resuelve, y por ultimo se genera un documento final que resume todos los
registros.
9. Herramientas, técnicas y metodologías
Las herramientas que utilizará el equipo de QA tienen que ver con utilidades del SO, debuggeadores,
documentos de ayuda, checklist, analizadores de estructuras, analizadores de código, auditorias
de estándares, monitoreo de rendimiento, software de desarrollo, matrices de seguimiento de
software, pruebas de generadores de casos
Como técnicas se incluirá la revisión de uso de estándares, inspecciones de software, trazabilidad

de requerimientos, verificación y validación de diseño y requerimientos, mediciones y evaluaciones
de fiabilidad, análisis de lógica de negocio.

77
En cuanto a la metodología, se utilizarán las técnicas y herramientas que se indican anteriormente,

con lo cual se podrá documentar de acuerdo al Proceso Unificado.
10. Control de medios
Los documentos generados durante el proyecto podrán ser consultados en la herramienta

colaborativa que se utiliza en la organización.
11. Control de proveedor
No aplica, por cuanto no se usará ninguna herramienta que directamente requiera el producto.
12. Colección de riesgos, mantenimiento y conservación
La documentación relacionada con este documento podrá ser consultada en la herramienta

colaborativa SharePoint, el mantenimiento a la documentación de realizara como lo indica la
sección 8 de este documento, y las nuevas versiones de la documentación deberá ser almacenada
en la misma herramienta.
13. Formación
Los participantes en el desarrollo deben conocer y aplicar
El procedimiento de revisión.
• El procedimiento de reporte de errores y actualización de documentos aceptados

• Las reglas de documentación
• Si son diseñadores: las reglas de diseño
• Si son programadores: las reglas de codificación
Se notificara, y se actualizara el SQAP , en caso de existir un nuevo documento de especificación
que aplique para alguno de los roles dentro del equipo de desarrollo.
14. Gestión de riesgos
La gestión de riesgos se realizara según lo indique la sección gestión de riesgos de los documentos
que se generen. Para evaluar que se cumple el objetivo planteado se deberán realizar actividades
de SQA como las que se sugieren a continuación:
• Asegurar que se realice una evaluación de riesgos en el proyecto.

• Que la evaluación de riesgos esté bien hecha, lo cual implica:
• Que se evalúen riesgos en todas las áreas del proyecto y por personas diferentes.
• Que la evaluación de riesgos se haga de forma individual y luego se reúnan los riesgos
detectados para determinar el impacto de cada riesgo, con todos los integrantes del
equipo de trabajo.
• Que se prioricen los riesgos.
• Que se planifique su eliminación, mitigación y/o contingencia.
• Que se incorporen los riesgos a los planes del proyecto para su seguimiento.
Se deberá regir de acuerdo al plan de riesgos del proyecto.

15. Glosario
• Registro: Procedimiento de actualización de un documento aceptado con el cual se

pretende detectar errores en los documentos con estatus de aceptado. Un registro puede
afectar a diversos documentos.
• Rol: Es una definición abstracta de un conjunto de responsabilidades tomadas por uno o más
integrantes del equipo de desarrollo, en otras palabras un rol define las responsabilidades
de cierto actor el cual puede tener asociados varios roles.
• Documento Fuente: Documento que mantiene las bases para la redacción de documentos.
• Documento Producto: Documento que se someterá a una inspección mediante la
aprobación de un Inspección Líder.
• PSQA: Plan de aseguramiento de calidad del software.
• QA: Control de calidad.
• SQA: Aseguramiento de calidad del software.
16. Procedimientos de cambio e historia del PSQA
Se le realizarán revisiones e inspecciones cada semana, se recolectaran los T-records y se generara

una nueva versión.
Se seguirá el procedimiento de la sección 8 de este documento para el reporte de problemas y su

corrección.
MES/yc/2014-02-26/79pág.

79

Control de Calidad

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Control de Calidad

Enviado por

Direitos autorais:

Formatos disponíveis

MODALIDAD ABIERTA Y A DISTANCIA

Departamento de Ciencias de la Computación y Electrónica

La Universidad Católica de Loja

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

Diagramación, diseño e impresión:

Derecho de autor: CUE-001748

ISBN físico - 978-9942-08-584-9

6. Proceso de enseñanza-aprendizaje para el logro de competencias................. 11

UNIDAD 1. INTRODUCCIÓN A LA CALIDAD....................................................................................... 14

UNIDAD 2. CALIDAD DE LOS SISTEMAS DE INFORMACIÓN........................................................... 26

UNIDAD 3. CALIDAD DEL PRODUCTO SOFTWARE........................................................................... 32

UNIDAD 4. CALIDAD DEL PROCESO SOFTWARE.............................................................................. 41

UNIDAD 5. EVALUACIÓN Y MEJORA DE PROCESOS......................................................................... 48

UNIDAD 6. GESTIÓN DE LA CALIDAD DE LOS PROYECTOS............................................................. 59