Aseguramiento de la calidad

Definición

Al igual que ocurrió con la definición de calidad hay varios puntos de vista desde donde se
puede definir el aseguramiento de la calidad del software.

Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad

como
“Una guía planificada y sistemática de todas las acciones necesarias para proveer la
evidencia adecuada de que un producto cumple los requerimientos técnicos establecidos.
Un conjunto de actividades diseñadas para evaluar el proceso por el cual un producto es
desarrollado o construido.”

Daniel Galin define SQA como “Un conjunto, sistemático y planificado, de acciones
necesarias para proveer la evidencia adecuada de que el proceso de desarrollo o
mantenimiento de un sistema de software cumple los requerimientos técnicos funcionales
tan bien como los requerimientos gerenciales para cumplir la planificación y operar dentro
del presupuesto confinado”.

Desde el punto de vista de la visibilidad, el SEI define SQA como

“El aseguramiento de la calidad del software provee claro control del proceso que está
siendo usado por el proyecto y del producto que se está construyendo.”

Desde el punto de vista del aseguramiento, Don Reifer define SQA como
“El aseguramiento de la calidad del software es el sistema de métodos y procedimientos
usados para asegurar que el producto de software alcanza sus requerimientos. El sistema
involucra la planificación, estimación y monitoreo de las actividades de desarrollo
realizadas por otros.”

Desde el punto de vista de la capacidad de uso Schulmeyer y McManus definen SQA

como
“Las actividades sistemáticas que proveen evidencia de la capacidad o disponibilidad de
uso del producto de software total.”

Para certificar madurez de procesos, hay que evidenciar que uno aplica un cierto proceso
y para esto se deben registrar las distintas actividades de tal proceso de desarrollo, como
éste es el objetivo que persigue el software a desarrollar como parte de esta tesis,
elegiremos la definición que da la IEEE desde el punto de vista de la generación de
evidencia adecuada que muestre que se cumple con el proceso que se dice seguir y con
los requerimientos establecidos.
El Aseguramiento de la Calidad del Software engloba:

 Un enfoque de gestión de calidad.

 Métodos y herramientas de Ingeniería del Software.
 Revisiones técnicas formales en el proceso del software.
 Una estrategia de prueba multiescala.
 El control de la documentación del software y de los cambios realizados.
 Procedimientos para ajustarse a los estándares de desarrollo del software.
 Mecanismos de medición y de generación de informes.

Las revisiones del software son un "filtro" para el proceso de Ingeniería del Software. Esto
es, las revisiones se aplican a varios momentos del desarrollo del software y sirven para
detectar errores y defectos que pueden ser eliminados. La revisión técnica formal (RTF), a
veces llamada inspección, es el filtro más efectivo desde el punto de viste del
aseguramiento de la calidad y es un medio efectivo para mejorar la calidad del software.

Las actividades de diseño introducen entre el 50 y 65% de todos los errores durante el
proceso de software. Sin embargo, se ha demostrado que las RTF son efectivas en un
75% a la hora de detectar errores. Con la detección y la eliminación de un gran porcentaje
de errores, el proceso de revisión reduce substancialmente el coste de los pasos
siguientes en las fases de desarrollo y mantenimiento.

Los objetivos de la Revisión Técnica Formal son:

 Descubrir errores en la función, la lógica o la implementación de cualquier

representación del software.
 Verificar que el software bajo revisión alcance sus requisitos.
 Garantizar que el software ha sido representado de acuerdo con ciertos
estándares predefinidos.
 Conseguir un software desarrollado en forma uniforme
 Hacer que los proyectos sean más manejables.

El aseguramiento de calidad se refiere a validar los procesos usados para crear los
productos. Es una herramienta especialmente útil para administradores y patrocinadores,
ya que permite discutir los procesos usados para determinar si los productos creados son
razonables. Este aseguramiento tiene asociado 2 constitutivos diferentes:

1. Los ingenieros del Software que realizan el trabajo técnico.

2. Un grupo de SQA (Software Quality Assurance) que se responsabiliza en la
planificación de aseguramiento de la calidad, supervisión, mantenimiento de
registros, análisis e informes.

Las actividades del grupo de SQA son:

 Establecimiento de un plan de SQA para un proyecto.

 Participación en el desarrollo de la descripción del proceso de software
del proyecto.
 Revisión de las actividades de Ingeniería del Software para verificar su ajuste al
proceso de software definido
  Auditoria de los productos de software designados para verificar el ajuste con los
definidos como parte del proceso del software.
 Asegurar que las desviaciones del trabajo y los productos del software se
documentan y se manejan de acuerdo con un procedimiento establecido.
 Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

Además de estas actividades, el grupo de SQA coordina el control y la gestión de

cambios y; ayuda a recopilar y analizar las métricas del software.
El trabajo del equipo de SQA es asegurar que el desarrollo sigue el proceso establecido.
Entre sus funciones en este rol se encuentran:

 Auditar los productos del trabajo para identificar deficiencias.

 Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de
desarrollo de software.
 Juzgar el proceso y no el producto.

“Como abogado del cliente”: el trabajo del equipo de SQA es representar al cliente. Entre
sus funciones en este rol se encuentran:

 Identificar la funcionalidad que al cliente le gustaría encontrar. o Ayudar a la

organización a sensibilizarse con las necesidades del cliente.
 Actuar como un cliente de prueba para obtener una alta satisfacción del cliente.

“Como analista” el trabajo del equipo de SQA es recabar información. Entre sus funciones
en este rol se encuentran:

 Juntar muchos datos sobre todos los aspectos del producto y del proceso.
 Con esta información ayudar a mejorar los procesos y los productos.

“Como proveedor de información” el trabajo del equipo de SQA es revisar qué es lo que
esté hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la
gerencia pueda tomar mejores decisiones de negocios. Entre sus funciones en este rol se
encuentran:

 Proveer información técnica objetiva para que la gerencia pueda usarla para tomar
mejores decisiones.
 Proveer información apropiada de las clases de productos y de los riesgos
asociados con estos.
 Concentrarse más en la reducción de los riesgos que en el cumplimiento del
proceso.

“Como responsable de la elaboración del proceso” el trabajo del equipo de SQA es

participar en la definición de los planes, procesos, estándares y procedimientos para
asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para
realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las políticas
de la organización. Para cumplir este rol el aseguramiento de la calidad debería comenzar
en las fases tempranas del proyecto.
Estándares y métricas de calidad
Un problema de la garantía de la calidad basada en el proceso es que el equipo de
garantía de la calidad (QA) insista en unos estándares de proceso independientemente
del tipo de software a desarrollar. El gestor principal debe intervenir para asegurar que el
proceso de calidad ayude al desarrollo del producto en lugar de impedirlo.

Podemos definir dos tipos de estándares como parte del proceso de garantía de calidad:

1. Estándares de producto. Se aplican sobre el producto software que se comienza a

desarrollar. Incluyen estándares de documentación, como cabecera de comentarios
estándar para definición de clases, y estándares de codificación.

2. Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo
del software. Pueden incluir definiciones de procesos de especificación, diseño y
validación, así como una descripción de los documentos que deben escribirse en el curso
de estos procesos.

Los estándares de producto se aplican a las salidas del proceso software y. en muchos
casos, los estándares de proceso incluyen actividades de proceso específicas que
garantizan que se sigan los estándares de producto. Los estándares de software son
importantes por varias razones:

1. Están basadas en el conocimiento de la mejor o más apropiada práctica de la empresa,

evita la repetición de errores anteriores.

2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de garantía

de la calidad. El control de la calidad sencillamente asegura que los estándares se siguen
adecuadamente.

3. Ayudan a la continuidad cuando una persona continúa el trabajo que llevaba a cabo
otra. Se reduce el esfuerzo de aprendizaje cuando se comienza un nuevo trabajo.

Utilizando estándares como punto de partida, el equipo de garantía de la calidad debe

crear un «manual» de estándares. Éste define los estándares que son apropiados para la
organización. Algunas veces, los ingenieros de software consideran a los estándares
como burocráticos e irrelevantes para las actividades técnicas de desarrollo de software.

Un conjunto de estándares internacionales que se puede utilizar en el desarrollo de un

sistema de gestión de calidad en todas las industrias es ISO 9000. Los estándares ISO
9000 pueden aplicarse a un amplio abanico de organizaciones desde las de manufactura
hasta las de servicios. ISO 9001 es el más general de estos estándares y se aplica en
organizaciones interesadas en el proceso de calidad de diseño, desarrollo y
mantenimiento de productos. I
Los estándares de documentación en un proyecto de software son documentos muy
importantes ya que son la única forma tangible de representar al software y su proceso.

Existen tres tipos de estándares de documentación:

1. Estándares del proceso de documentación. Definen el proceso a seguir para la

producción del documento, esto implica definir los procedimientos involucrados en el
desarrollo del documento y las herramientas de software utilizadas. También definen
procedimientos de comprobación y refinamiento que aseguren que se produzcan
documentos de alta calidad.

2. Estándares del documento. Gobiernan la estructura y presentación de los documentos.

3. Estándares para el intercambio de documentos. Aseguran que todas las copias

electrónicas de los documentos sean compatibles.

Los estándares de calidad del proceso de documentos deben ser flexibles y les debe ser
posible ajustarse a todos los tipos de documentos.

El plan de calidad selecciona los estándares organizacionales apropiados para un

producto y un proceso de desarrollo particulares. Esta estructura comprende:

1. Introducción del producto. Descripción del producto, el mercado al que se dirige y las
expectativas de calidad.

2. Planes de producto. Contiene las fechas de terminación del producto y las

responsabilidades importantes junto con los planes para la distribución y el servicio.

3. Descripciones del proceso. Contiene los procesos de desarrollo y de servicio a utilizar

para el desarrollo y administración del producto.

. Metas de calidad. Contiene las metas y planes de calidad para el producto. Incluyendo la
identificación y justificación de los atributos de calidad importantes del producto.

5. Riesgos y gestión de riesgos. Contiene los riesgos clave que podrían afectar a la
calidad del producto y las acciones para abordar estos riesgos.
Modelo de madurez
El grado en el cual una organización, o una unidad organizacional desarrolla, asimila e
implementa buenas prácticas en dirección de proyectos, programas y portafolios, se
conoce como madurez en administración/dirección de proyectos.

El nivel de madurez en administración de proyectos de una organización u unidad

organizacional, es factible de ser medido mediante modelos de madurez.

Un modelo de madurez, es un conjunto estructurado de elementos (buenas prácticas,

herramientas de medición, criterios de análisis, etc.), que permite identificar las
capacidades instaladas en dirección de proyectos en la organización, compararlas con
estándares, identificar vacíos o debilidades y establecer procesos de mejora continua.

Los modelos de madurez en administración de proyectos, derivan del Capability Maturity

Model, CMMdesarrollado, a requerimiento del Gobierno Federal de Estados Unidos, en
1986 por el Software Engineering Institute, SEI, para la evaluación de procesos
vinculados con el desarrollo de software.

El modelo de capacidad de madurez está basado en prácticas reales, refleja las mejores
prácticas en el área, también refleja la necesidad de los individuos de llevar a cabo una
mejora en el proceso de desarrollo de software, al igual que la valoración del proceso de
desarrollo de software el CMM está documentado y es público.

CMM es...

• Una estrategia de mejora

• Una señalización de deficiencias Dentro de una organización

• Una guía para poder avanzar hacia una cultura de calidad

CMM no es...

• Una solución rápida, sino gradual

• Una lista de verificación que puede ser utilizada en todos los ambientes, aunque las
prácticas detalladas en el CMM sirven como guía para tomar decisiones
Enfoque de procesos
Los procesos de acreditación, tanto a nivel institucional como a nivel programa
requieren que la institución presente evidencias en la forma de información y
documentos, que demuestren el cumplimiento de los criterios para evaluación.

Por tanto, la institución deberá contar con procesos para la organización y

allegamiento de información y documento, y el nivel de desarrollo e integración de
estos procesos puede afectar la eficiencia de los procesos de acreditación que la
institución lleve a cabo, y para ello es pertinente estudiar los modelos de madurez
de procesos.

La madurez la podemos definir como la medida que permite a la organización

evaluar sus capacidades en torno a un área de enfoque en particular (Rosemann y
de Bruin, 2005), y este concepto puede aplicarse a distintos recursos en la
organización, tales como procesos, objetos, tecnologías e inclusive capacidades
de los individuos (Mettler, 2011). El nivel de madurez se evalúa mediante etapas
secuenciales, cada una de las cuales está descrita por una serie de variables
(Rao, et al 2003; Dekhleva y Dremmer, 1997), y la premisa fundamental es que
esta progresión jerárquica es benéfica para la organización y difícilmente
reversible (Soli-Saether y Gottschalk, 2010).

Los niveles de madurez se describen a continuación (Paulk, 2001):

NIVEL 1 – Inicial: El proceso para llevar a cabo los proyectos no está estructurado
ni institucionalizado, existe en un ambiente inestable, impredecible y aleatorio, por
tanto no existen políticas ni documentación de las actividades ni de los resultados.

NIVEL 2 – Repetible: Existen políticas para administrar los proyectos y

procedimientos para implementarlos. La planeación y administración de los
proyectos está basada en la experiencia sobre proyectos realizados
anteriormente.

NIVEL 3 – Definido: Existe un proceso estándar y documentado para el desarrollo

y administración de los proyectos.

NIVEL 4 – Administrado: Existen metas cuantitativas y cualitativas para los

productos y procesos, y por ello la productividad y calidad son medidas y
evaluadas.

NIVEL 5 – Optimizado: Existe un enfoque organizacional hacia la mejora continua:

Los procesos de medición y evaluación arrojan información que es usada para
identificar áreas de oportunidad y atenderlas.
Partiendo de la premisa de que los procesos de administración de información sobre calidad
educativa en una IES pueden encontrarse en distintos niveles de madurez en función de los
requerimientos establecidos por las distintas etapas de los procesos de acreditación, se buscó
contextualizar las áreas de proceso clave del CMM a los procesos de administración de
información sobre indicadores de calidad educativa desde esta perspectiva.

A su vez la planeación institucional debe ser congruente y plantear estructuras y mecanismos que
permitan que la administración de la información sobre indicadores de calidad educativa coadyuve
al logro de resultados positivos en los procesos de acreditación y que esto sea de forma continua y
sostenible para la institución.

De acuerdo al estudio llevado a cabo, se observó que es posible trasladar un modelo de madurez,
en este caso CMM al contexto de la administración de la información sobre indicadores de calidad
educativa tomando como base la perspectiva de los procesos de acreditación.

PSP Y TSP

PSP
El Personal Software Process, conocido por sus siglas como PSP, es una
metodología de reciente creación, proveniente del Instituto de Ingeniería del
Software (SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que
les permite mejorar la forma en la que construyen software. Considerando
aspectos como la planeación, calidad, estimación de costos y productividad.

VENTAJAS Y DESVENTAJAS PARA UTILIZAR PSP

Características:

 PSP es una metodología basada en estimación. La estimación permite saber

cuándo y cómo se desarrollan las tareas de un proceso, por lo que podría
citarse como un aspecto importante de esta metodología el estar basada en
métricas y estimaciones.
 La información de las métricas y estimaciones se utiliza para evaluar y mejorar
procesos futuros. PSP parte de la premisa que, si el ingeniero de software
conoce sus fortalezas y debilidades, puede establecer las acciones necesarias
para erradicar o explotar los aspectos identificados en la forma en que
desarrolla software.
 Los pasos de registro de información a detalle en el nivel de medición pueden
resultar frustrantes cuando se tiene presión de tiempo.

 En los scripts de PSP no se incluyen tareas y actividades para la etapa de

análisis de requerimientos. Siempre se parte de una definición de
requerimientos que no va a cambiar.
 Aún no existe una herramienta automatizada que facilite el registro y análisis
de datos generados por la aplicación de PSP.

En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante
el proceso de desarrollo de un producto de software, están puntualmente definidas en un
conjunto de documentos conocidos como scripts. Los scripts son el punto medular de
PSP, por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada,
ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y
actividades definidas en los scripts generará en su realización un conjunto de datos,
fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de
desarrollo, y el análisis de la información estadística generada en cada uno de éstos,
permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y
crecer a través de un proceso de auto aprendizaje y auto mejora. La calidad en PSP, es
un aspecto fuertemente relacionado con la cantidad de defectos que el producto de
software contiene.

TSP
TEAM SOFTWARE PROCESS (TSP)
Team Software Process (TSP) es un método de establecimiento y mejora del
trabajo en equipo para procesos software.

TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a

planificar sus procesos y a revisar su trabajo con el fin de que la organización
pueda establecer prácticas de ingeniería avanzadas y así obtener productos
eficientes, fiables y de calidad. Está formado por dos componentes primarios que
abarcan distintos aspectos del trabajo en equipo:

 Formación del equipo de trabajo.

 Gestión del equipo de trabajo.
Características de los grupos eficaces (I).

 Miembros expertos en papeles de liderazgo y pertenencia.

 Relaciones tranquilas y establecidas entre los miembros.
 Los miembros se sienten atraídos por el grupo y son fieles.
 Los valores y metas del grupo son los de sus integrantes.
 Los miembros están motivados por hacer lo que puedan por el grupo.
 La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
 El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea
ayudar a cada miembro a adquirir su pleno potencial.
 Cada miembro acepta con gusto y sin resentimiento las metas y normas
establecidas.
 Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
 Existe una atmósfera de creatividad.
 El grupo conoce el “conformismo constructivo” y se sirve de él.
 Existe gran motivación para iniciar y recibir las comunicaciones.
 Los miembros son flexibles y adaptables en sus metas y actitudes.
 Los miembros se sienten seguros al tomar decisiones que les Los miembros se
sienten seguros al tomar decisiones que les parecen apropiadas al entender la
filosofía de la operación.

LOS OBJETIVOS DEL TSP

– Generar un marco basado en psp
– Desarrollar productos en varios ciclos

– Establecer estándares para medir la calidad y el comportamiento

proporcionar métricas para equipos

– Evaluar roles y equipos

– Guías para solución de problemas en equipos.

TSP es una solución basada en procesos para resolver problemas de negocio,

tales como:

 Predictibilidad de costo y tiempo

 Mejora de productividad
 Ciclos de desarrollo y mejora de calidad de productos.

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se
realiza:

Lanzamiento, Estrategia, Plan, Requisitos, Diseño, Implementación, Pruebas ,

Postmortem
SPICE
La ISO/IEC TR 15504, conocida como SPICE (Software Process Improvement and
Capability dEtermination) es un modelo de evaluación y mejora de los procesos de
desarrollo y mantenimiento de sistemas y productos de software. El estándar ISO
15504 es una herramienta que ayuda a reducir costes y mejorar la calidad
evitando problemas

Proporciona todas las facilidades para la evaluación del proceso y establece los
requisitos mínimos para realizar una evaluación que asegure la repetibilidad y
consistencia de las valoraciones obtenidas.

El objetivo principal de evaluar estos procesos es conocer la capacidad que tienen

en una organización.

Después de su ejecución, se debe obtener la información relevante de cada

proceso, y el punto hasta el cual estos cumplen con su propósito.

Es un Marco de referencia para:

 Determinar las fortalezas y debilidades de los procesos.

 Mejorar los procesos de software y medir sus mejoras.
 Aquellos que adquieren un sistema para evaluar la capacidad de los
proveedores de sistemas.
 Determinar los riesgos de negocio para una empresa que considera
desarrollar un nuevo producto de software o servicio.

CARACTERISTICAS DEL MODELO DE CALIDAD SPICE

• Marco de referencia para determinar las fortalezas y debilidades de los

procesos. Es aplicable a cualquier organización o empresa que quiera mejorar la
capacidad de cualquiera de sus procesos de software. El modelo de referencia de
SPICE describe los procesos que una organización puede realizar para comprar,
suministrar, desarrollar, operar, mantener y soportar el software, así como los
atributos que caracterizan la capacidad de estos procesos.

• Marco de referencia para los que adquieren un sistema para evaluar la

capacidad de los proveedores de sistemas y determinar los riesgos de negocio
para una empresa que considera desarrollar un nuevo producto de software o
servicio.
Abarca:
• Evaluación de procesos
• Mejora de procesos.
• La calidad del todos los componentes integrados en el proceso de
desarrollo del software NO mejora necesariamente por el simple hecho de adoptar
un estándar
• Es necesario que el proceso de adopción conlleve una gestión del cambio
adecuada.
• Es necesario tener un estándar como objetivo y referencia del proceso de
desarrollo del software.
• El modelo seleccionado no es tan importante como el compromiso de
mejora
• Determinación de capacidad.
• Contiene los procesos que se han de evaluar. Se corresponden con los
procesos del ciclo de vida del software, definidos al estándar ISO 12207:1995.
Se agrupan en categorías, en función del tipo de actividad al cual se aplican:

v CUS: Cliente-Proveedor.
v ENG: Ingeniería.
v SUP: Soporte.
v MAN: Gestión.
v ORG: Organización

COMPONENTES
CMM
El Modelo de Capacidad y Madurez Integrado CMMI (Capability Maturity Model®
Integration) es un modelo de referencia de prácticas maduras usadas para evaluar
y mejorar la capacidad de los procesos. Es una ruta evolutiva de implementación
de las mejores prácticas en los procesos organizacionales.

Un nivel de madurez bien definida con un meseta evolutiva hacia la consecución

de un proceso software maduro. Cada nivel de madurez proporciona una capa en
la base para una mejora continua del proceso.

Los modelos CMMI con representación por etapas, tienen cinco niveles de
madurez designado por los números del 1 al 5. Estos son:

 Inicial
 Gestionado
 Definido
 Cuantitativamente gestionado
 Optimizar

La siguiente imagen muestra los niveles de madurez de CMMI representación por

etapas.
Los niveles de madurez consisten en un conjunto predefinido de áreas de proceso.
Los niveles de madurez se miden por el logro de los
objetivos genéricos y específicos que se aplican a cada conjunto predefinido de
áreas de proceso.

Cada nivel de madurez proporciona un fundamento necesario para la aplicación

efectiva de los procesos en el siguiente nivel.

 Los procesos a un nivel superior tienen menos posibilidades de éxito sin la

disciplina de los niveles inferiores.

 El efecto de la innovación puede ser ocultada en un ruidoso proceso.

Nivel de madurez inicial 1

En el nivel de madurez 1, los procesos suelen ser ad hoc y caótico. La
organización normalmente no proporciona un entorno estable. El éxito de estas
organizaciones depende de la competencia y de la disposición de las personas
de la organización y no en el uso de procesos probados.

Las organizaciones con un nivel de madurez 1 a menudo se producen los

productos y servicios que funcionan; sin embargo, frecuentemente exceden el
presupuesto y el calendario de sus proyectos.

Nivel de madurez 2 administrado

En el nivel de madurez 2, la organización ha logrado todos los
objetivos genéricos y específicos del nivel de madurez 2 áreas de proceso. En
otras palabras, los proyectos de la organización han asegurado que los requisitos
son gestionados y de que los procesos se planifican, realizan, medido y
controlado.
La disciplina de los procesos reflejados por nivel de madurez 2 ayuda a garantizar
que se conserven las prácticas existentes en los momentos de estrés.

En el nivel de madurez 2, los requisitos, los procesos, los productos de trabajo, y

los servicios son administrados. El estado de los productos de trabajo y la
prestación de servicios son visibles a la gestión en puntos definidos.
Nivel de madurez 3, definida
En el nivel de madurez 3, la organización ha alcanzado todos los objetivos
específicos y de las áreas de proceso asignadas a los niveles de madurez 2 y 3.
En el nivel de madurez 3, los procesos están bien caracterizados y entendidos, y
se describen en las normas, procedimientos, herramientas y métodos.

En el nivel de madurez 3, los estándares, las descripciones de los procesos y

procedimientos de un proyecto se diseñan a partir del conjunto de procesos
estándar de la organización para adaptarse a un determinado proyecto o unidad
organizativa. El conjunto de procesos estándar de la organización incluye los
procesos abordados en el nivel de madurez 2 y el nivel de madurez 3. Como
resultado de ello, los procesos que se llevan a cabo en toda la organización son
compatibles excepto por las diferencias de la sastrería.

Nivel de madurez 4 administrado cuantitativamente

En el nivel de madurez 4, una organización ha logrado todos los objetivos
específicos de las áreas de proceso asignadas a los niveles de madurez 2, 3 y 4
y los objetivos genéricos asignados a los niveles de madurez 2 y 3.

En el nivel de madurez 4, se seleccionan los que contribuyen de forma significativa

al rendimiento del proceso en general. Estos sub-procesos están controlados
mediante técnicas estadísticas y otras técnicas cuantitativas.

Objetivos cuantitativos de calidad y rendimiento de los procesos se establecen y

se utilizan como criterios para la gestión de procesos.

Para estos procesos, las medidas detalladas del rendimiento de los procesos son
recogidas y analizadas estadísticamente.
Nivel de madurez 5 Optimización

En el nivel de madurez 5, una organización ha logrado todos los goalsof el

proceso zonas asignadas a los niveles de madurez 2, 3, 4 y 5, y los objetivos
genéricos asignados a los niveles de madurez 2 y 3.

Mejorar continuamente los procesos se basa en una comprensión cuantitativa de

las causas comunes de variación inherentes a los procesos.

Este nivel se centra en mejora continua del rendimiento de los procesos a través
de los aumentos y mejoras tecnológicas innovadoras.

Los objetivos cuantitativos de mejora de procesos para la organización se

establecen y se revisan de forma continua a fin de reflejar los cambios objetivos
de negocio, y se utilizan como criterios para la administración de la mejora de
procesos.

Los efectos de las mejoras implementadas en los procesos se miden y evalúan

en relación con los objetivos cuantitativos de mejora de procesos. Tanto los
procesos definidos como el conjunto de procesos estándar de la organización son
objetivos para las actividades de mejora considerables.
MoProSoft
El Modelo de Procesos para la Industria de Software, Moprosoft, tiene por objetivo
proporcionar a la industria mexicana, y a las áreas internas dedicadas al desarrollo
y mantenimiento de software, un conjunto integrado de las mejores prácticas
basadas en los modelos y estándares reconocidos internacionalmente, tales como
ISO 9000:2000, CMM-SW, ISO/ IEC 15504, PMBOK, SWEBOK entre otros.
Moprosoft contiene tres categorías de procesos que corresponden a las capas de
Alta Dirección, Gestión y Operación. La categoría de Alta Dirección contiene el
proceso de Gestión de Negocio; la categoría de Gestión se compone de Gestión
de Procesos, Gestión de Proyectos y Gestión de Recursos, a su vez, este último
se divide en tres subprocesos:

El de Recursos Humanos, el de Bienes, Servicios e Infraestructura y el de

Conocimiento de la Organización. Finalmente, la categoría de Operación contiene
los procesos de Administración de Proyectos Específicos y de Desarrollo y
Mantenimiento de Software. El propósito de contar con un modelo de estas
características es apoyar a la industria de software en su tránsito del estado
actual, en el cual la calidad de los productos depende principalmente de las
habilidades de los individuos, al estado deseado: en donde la calidad de los
productos de software será la consecuencia de la madurez en los procesos de las
organizaciones.

Categorías

Categoría alta dirección (DIR)

• Gestión de Negocio

• Gestión de memorización

Categoría Gerencia (GER)

• Gestión de Procesos

• Gestión de Proyectos

• Gestión de Recursos

• Recursos Humanos y Ambiente de Trabajo

• Bienes Servicios e Infraestructura

• Conocimiento de la Organización.

Categoría Operación (OPE)

• Administración de Proyectos Específicos

• Desarrollo y Mantenimiento de Software.

Características:

Las categorías de procesos corresponden a niveles organizacionales de

administración. Procesos Integrados y Relacionados.
Foco en producto y su capitalización.
Capacidad Organizacional de gestión de procesos.
Capacidad Organizacional de gestión de proyectos.
Alineación con objetivos de negocio.
Fácil de entender.
Modelo mexicano.

Ventajas

Está basado en normas ISO.

Facilita la comprensión del Modelo utilizado.
Simplifica la relación entre el modelo de procesos y la organización.
Cuenta únicamente con 9 procesos evitando la fragmentación que se presenta
en otros modelos.
Mejora la planificación, para que se establezcan planes más realistas.
Los clientes viven más informados.

Desventajas
Define actividades de manera muy general.
Para asegurar la calidad de un producto y un proceso se requiere CMMI.
El 33% de las prácticas no cubiertas de definir e implementar como lo son
Administración de Configuración (CM) Y Medición y Análisis (MA).
Evaluaciones formales constantes.
No comprensible para los modelos ISO 9000: 2000.
Proyectos para largos plazos.
http://sedici.unlp.edu.ar/bitstream/handle/10915/3956/3_-
_Aseguramiento_de_la_calidad_del_software.pdf?sequence=11

http://dankocs2012.blogspot.mx/2012/12/aseguramiento-de-la-calidad-de-software.html

https://sg.com.mx/revista/45/integrando-tsp-y-cmmi-lo-mejor-dos-mundos#.WglRSkgZPIU

file:///C:/Users/tony/Downloads/modelosdecalidad-cmmi-moprosoft-150417160536-
conversion-gate02.pdf