Calidad Del Software

UNIVERSIDAD SIMÓN BOLÍVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
SISTEMAS DE INFORMACIÓN III

TEORÍA
CONTENIDO:
¿QUÉ ES CALIDAD DEL SOFTWARE?
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
CONTROL DE LA CALIDAD DEL SOFTWARE
AUDITORÍA DE LA CALIDAD DEL SOFTWARE
CALIDAD DEL PRODUCTO DE SOFTWARE
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
Material diseñado y elaborado por:

Prof. Luis Eduardo Mendoza M.
¿QUÉ ES CALIDAD DEL SOFTWARE?
• Pressman (Pressman, 1998) define la calidad del software

como:
“la concordancia con los requerimientos funcionales y de
rendimiento explícitamente establecidos, con los estánda-
res de desarrollo explícitamente documentados y con las
características implícitas que se espera de todo software
desarrollado profesionalmente”.
• En la definición de la calidad del software pueden estar
involucrados aspectos como la ausencia de defectos, aptitud
para el uso, seguridad, confiabilidad y reunión de especificacio-
nes. Sin embargo, hay algo importante que se debe tener
presente: la calidad del software debe ser construida desde
el comienzo, no es algo que puede ser añadido después.
• Para que el producto final sea de calidad, el proceso por medio
del cual éste es elaborado debe ser también de calidad.
SISTEMAS DE INFORMACIÓN III TEORÍA
• Sridharan (Sridharan, 2000) indica que mientras el software que

se está desarrollado reúne los requerimientos y su desempeño es
el esperado, es preciso que se supervisen las actividades de
desarrollo del software y su rendimiento, en distintas
oportunidades durante cada fase del ciclo de vida. Este es el papel
del aseguramiento de la calidad del software.
• Hay tres (3) aspectos muy importantes con relación al

aseguramiento de la calidad del software: (Wiegers, 1990)
– La calidad no se puede probar, se construye.
– El aseguramiento de la calidad del software no es una tarea
que se realiza en una fase particular del ciclo de vida de
desarrollo.
– Las actividades asociadas con el aseguramiento de la calidad
del software deben ser realizadas por personas que no estén
directamente involucradas en el esfuerzo de desarrollo.
• Pressman (Pressman, 1998) considera que el aseguramiento de la

calidad del software comprende una gran variedad de tareas
asociadas:
– Preparar u plan de aseguramiento de la calidad del software
para un proyecto.
– Participar en el desarrollo del proceso de descripción del
proyecto de software.
– Revisar las actividades de ingeniería del software para verificar
su consistencia con el proceso de software definido.
– Auditar el producto de software para verificar el cumplimiento
del proceso de software definido
– Asegurar que las divergencias en el trabajo de software sean
documentadas de acuerdo a los estándares definidos.
– Alamacenar cualquier inconformidad y reportarla a la gerencia
media.
CONTROL DE LA CALIDAD DEL SOFTWARE
• Según Monsalve (Monsalve, 1998), el control de la calidad se

relaciona con la vigilancia permanente de todo el proceso de
desarrollo y el ciclo de vida del software. Se logra mediante la
observación constante del cumplimiento de cada una de las fases y
actividades involucradas en el proceso de desarrollo.
• Para realizar un control de calidad deben ejecutarse frecuentes
inspecciones a las metodologías de trabajo y a el uso de las
herramientas, revisiones de prototipos y de las pruebas formales
de los productos finales.
• El control de la calidad permite realizar las rectificaciones necesa-
rias a cualquier falla encontrada durante el proceso de desarrollo.
• Adicionalmente, el asegurar la calidad en las primeras fases del
proceso de desarrollo del software implica que los costos del
control en las etapas posteriores tiende a disminuir al tener menos
aspectos que controlar, además de que la calidad estaría
asegurada en sus bases.
AUDITORÍA DE LA CALIDAD DEL SOFTWARE
• La auditoría de la calidad se utiliza para descubrir y detener los

errores del software. Se lleva a cabo para monitorear eventos espe-
cíficos, o bien para revisar todas las actividades de un sistema.
• Las auditorías permiten garantizar la calidad del software: luego
de llevar a cabo una auditoría de calidad, es más fácil mantener
un registro con las deficiencias presentadas.
• La auditoría de la calidad del software tiene tres (3) metas de
seguridad importantes:
1) Revisar los modelos de acceso a los componentes, las historias
de acceso a los procesos y el uso de los mecanismos de
protección soportados por el sistema.
2) Descubrir los usuarios frecuentes y esporádicos que se
esfuerzan por desviar los mecanismos de protección.
3) Descubrir cualquier uso de privilegios que pueden ocurrir
cuando un usuario asume una funcionalidad con privilegios
mayores que el suyo propio.
• Para Monsalve (Monsalve, 1998), la principal meta de un

equipo desarrollador de software debe ser siempre producir
software de calidad; para ello, se deben tener en cuenta dos (2)
ideas muy importantes:
– Los productos de software son realizados por personas y
para personas.
– Muchas personas asocian la calidad a un atributo exclusivo
del producto y que comienza a considerarse una vez que se
escriben las primeras líneas de código.
• La calidad que pueden alcanzar los productos de software, y en

general cualquier tipo de producto, está sometida a la manera
cómo se desarrolla cada una de las etapas de la vida del
producto, iniciándose con la concepción de la idea del producto
hasta la entrega final y mantenimiento del mismo.

• La calidad del producto de software involucra actividades

como:
– Administración de la calidad.
– Uso de tecnología de Ingeniería de Software eficiente.
– Aplicación de técnicas formales a lo largo de todo el
proceso de desarrollo.
– Minimización de las variaciones entre productos.
– Verificación y pruebas formales en las diferentes etapas
del desarrollo.
– Control de la documentación.
– Correcto mantenimiento y servicios de post-venta.

La calidad está presente en todas las etapas del proceso de desa-

rrollo de los productos de software. A grandes rasgos:
• CALIDAD EN EL DISEÑO. Se basa en definir un listado de
especificaciones a seguir; involucra la descripción de los
procesos de desarrollo, tareas y responsabilidades de los
equipos de desarrollo; dichos procesos pueden estar
estandarizados.
• CALIDAD EN LA IMPLEMENTACIÓN. Se enfoca al grado de
cumplimiento de los requerimientos de diseño. Si los
requerimientos está bien definidos y especificados, el
cumplimiento de la calidad en esta fase no debe tornarse difícil.
• CALIDAD EN LA SATISFACCIÓN. Es la medida de calidad
apreciada por los usuarios finales de los productos de software.
No puede esperarse calidad en esta fase si no hubo
preocupación por ella en las etapas anteriores.

Mc Call
• El modelo fue propuesto por Mc Call en 1977 (Gillies, 1997) y

está orientado a los desarrolladores de Sistemas, para ser
utilizado durante el proceso de desarrollo.
• Abarca tres (3) áreas de trabajo:
ÁREA
DESCRIPCIÓN
DE TRABAJO
OPERACIÓN Requiere que pueda ser comprendida rápidamente, operada
DEL eficientemente y que los resultados sean aquellos requeridos por el
PRODUCTO usuario
REVISIÓN Está relacionada con la corrección de errores y la adaptación de los
DEL sistemas. Esto es importante porque es generalmente considerada
PRODUCTO como la parte más costosa en el desarrollo de software.
TRANSICIÓN Puede que no sea muy importante en todas las aplicaciones. Sin
DEL embargo, la orientación a procesamiento distribuido y el rápido cambio
PRODUCTO en el hardware es probable que incremente su importancia.
LAS TRES ÁREAS DIRECCIONADAS POR EL MODELO DE MCCALL. (Gillies, 1997)


Mc Call
Las tres (3) áreas que contempla el Modelo de Mc Call abarcan

los siguientes aspectos: (Pressman, 1998)
• OPERACIÓN DEL PRODUCTO:
– Corrección. Hasta dónde satisface un programa su
especificación y logra los objetivos de la misión del cliente
– Fiabilidad. Hasta dónde se espera que un programa lleve a
cabo su función pretendida con la exactitud requerida.
– Eficiencia. Cantidad de recursos informáticos y código
necesarios para que un programa realice su función
– Integridad. Hasta dónde se controla el acceso al software o
a los datos por personas no autorizadas.
– Usabilidad (Facilidad de manejo). Esfuerzo necesario para
aprender, operar, preparar los datos de entrada e interpretar
las salidas (resultados) de un programa.

Mc Call
• REVISIÓN DEL PRODUCTO:
– Mantenibilidad (Facilidad de mantenimiento). Esfuerzo

necesario para localizar y arreglar un error del programa
(definición limitada)
– Flexibilidad. Esfuerzo necesario para modificar un

programa operativo.
– Facilidad de prueba. Esfuerzo necesario para probar un

programa para asegurarse que realiza su función
pretendida.


Mc Call
• TRANSICIÓN DEL PRODUCTO:
– Portabilidad. Esfuerzo necesario para transferir el

programa de un entorno de sistema de hardware y/o
software a otro.
– Reusabilidad (capacidad de reutilización). Hasta dónde se

vuelve a emplear un programa [o partes de un programa] en
otras aplicaciones, en relación al empaquetamiento y
alcance de las funciones que realiza el programa.
– Interoperatividad. Esfuerzo necesario para acoplar un

sistema con otro.


Boehm
• Presentado por
Boehm en 1978 Independencia
Portabilidad de dispositivo
(Pfleeger, 1998), Auto-contención
incluye las ne- Fiabilidad
Precisión
cesidades de los Completitud
usuarios, como Utilidad Eficiencia

Robustez/integridad
Consistencia
lo hace Mc Call; General
Por la
Contabilidad
sin embargo, in- utilidad
Ingeniería Humana Eficiencia de dispositivo
cluye caracterís- Accesibilidad
ticas de rendi- Prueba Comunicabilidad
miento de hard- Mantenibilidad Auto-descriptivo

Estructuración
ware que no se Entendibilidad
Concisión
encuentran en Modificabilidad Legibilidad
el modelo de Aumentabilidad
McCall.


FURPS (Funcionality, Usability, Reliability, Performance, Supportability)
• Hewlett-Packard lo presenta ATRIBUTOS SUBATRIBUTOS

Conjunto de características
en 1987, desarrollando un FUNCIONALIDAD
Capacidades
Generalidad
conjunto de factores de cali- Seguridad
dad de software (funcio- FACILIDAD
Factores humanos
Aesthetics
DE
nalidad, facilidad de empleo, USO
Consistencia
Documentación
fiabilidad, rendimiento y Frecuencia/severidad de falla
Recuperabilidad
capacidad de soporte) y sus FIABILIDAD Predictabilidad
Precisión
atributos. Tiempo promedio de falla
Velocidad
Eficiencia
• Los factores de calidad FURPS RENDIMIENTO Consumo de recursos
Throughput
y sus atributos, pueden usar- Tiempo de respuesta
se para establecer métricas de Capacidad de prueba
Extensabilidad
la calidad para todas las CAPACIDAD
Adaptabilidad
Mantenibilidad
actividades del proceso de DE Compatibilidad
SOPORTE Configurabilidad
desarrollo de Sistemas de Capacidad de Servicio
Capacidad de Instalación
Información. Capacidad de Localización


ISO/IEC 9126
Presentado en 1992, las características de calidad de los productos

de software que establece este estándar de calidad, son:
• FUNCIONALIDAD. Existencia de un conjunto de funciones y
propiedades específicas establecidas.
• CONFIABILIDAD. Capacidad del software para mantener su nivel
de actuación bajo ciertas condiciones, en un período de tiempo.
• USABILIDAD. Esfuerzo necesario para el uso y el valor de uso, por
un conjunto determinado de usuarios.
• EFICIENCIA. Relación entre el nivel de desempeño del software y
la cantidad de recursos usados bajo ciertas condiciones.
• MANTENIMIENTO. Esfuerzo necesario para hacer modificaciones
específicas.
• PORTABILIDAD. Habilidad del software para ser transferido de un
ambiente a otro.

ISO/IEC 9126
ATRIBUTOS QUE ABARCAN LAS CARACTERÍSTICAS DE LA NORMA ISO/IEC 9126
FUNCIONALIDAD USABILIDAD MANTENIMIENTO
• Adaptabilidad • Comprensibi- • Análisis

• Exactitud lidad • Cambio
• Interoperabilidad • Aprendizaje • Estabilidad
• Complacencia • Operabilidad • Prueba
• Seguridad
CONFIABILIDAD EFICIENCIA PORTABILIDAD

• Madurez • Comportamiento • Adaptabilidad
• Tolerancia a del tiempo • Instalación
fallas • Comportamiento • Conformidad
• Recuperabilidad de los recursos • Reemplazo


Dromey
• En 1996, Dromey (Pfleeger, 1998) sugiere una técnica genérica

para construir un modelo de calidad. El mismo resalta el hecho
de que la calidad del producto es altamente determinada por
los componentes del mismo (incluyendo documentos de
requerimientos, guías de usuarios, diseños, y código), las
propiedades tangibles de los componentes y las propiedades
tangibles de la composición de los componentes.
• Respecto a la conocida expresión “construir la calidad en el

software”, Dromey indica que no se pueden construir atributos
de calidad, como la fiabilidad y la mantenibilidad, de alto nivel
en el software. Lo que se puede hacer es identificar y construir
en una forma consistente, armoniosa y completa un conjunto
de propiedades (tales como módulos sin efectos colaterales) que
resulten en la fiabilidad y mantenibilidad.


Dromey
• Clasifica las cualidades tangibles utilizando cuatro (4)

propiedades:
– Correctitud. Pueden ser internas (asociadas con los componentes
individuales) o contextuales (asociadas con la manera en que los
componentes son utilizados en el contexto)
– Internas. Miden que tan bien un componente ha sido entregado

de acuerdo a su objetivo, implementación o que tan bien ha sido
compuesto.
– Contextuales. Cómo los componentes son compuestos y las

influencias que ejercen sobre la calidad del producto.
– Descriptivas. Para ser útil un software debe ser fácil de entender

y utilizar de acuerdo a su propósito. Estas propiedades
descriptivas aplican a requerimientos, diseños, implementación y a
las interfaces de usuario


MODELO ORIENTADO AL PRODUCTO PROPUESTO POR LISI
• El modelo presenta aspectos de Efectividad del Producto los

cuales son representados por las características externas de
alto nivel del modelo ISO 9126: Usabilidad, Funcionalidad,
Fiabilidad, Mantenibilidad, Eficiencia y Portabilidad.
• Además, incluye elementos de Eficiencia del Producto,

según el modelo de Calidad Sistémica, representados por las
propiedades de los requerimientos, diseño e implementación
del producto, siguiendo el modelo de Dromey.
• Por último contempla elementos de Eficiencia y Efectividad

del Proceso, los cuales fueron identificados en el Estándar
ISO 15504.


MODELO ORIENTADO AL PRODUCTO PROPUESTO POR LISI
Atributos Internos/
Atributos externos Propiedades del Producto
•Usabilidad
Requerimientos
•Funcionalidad
•Fiabilidad
Diseño
•Mantenibilidad
•Eficiencia
Implementación
•Portabilidad
Efectividad Eficiencia
del Producto del Producto
Efectividad Eficiencia
del Proceso del Proceso
MODELO DE CALIDAD DE SOFTWARE


ISO 9000
• La serie de normas ISO 9000 es un conjunto de documentos

que pueden usarse para los propósitos de aseguramiento de la
calidad de casi cualquier cosa.
• Esta norma especifica los requisitos de los sistemas de calidad
para ser usados en un contrato entre dos partes que requieren
la demostración de la capacidad de un proveedor para diseñar
y suministrar un producto determinado.
• ISO 9000. Normas para la gerencia y el aseguramiento de la
calidad. Guía para la selección y uso.
• ISO 9001. Sistemas de Calidad - Modelo para el asefuramiento
de la calidad en el diseño, desarrollo, producción, instalación y
servicio.
• ISO 9002. Sistema de Calidad - Modelo para el aseguramiento
de la calidad en la producción e instalación.

ISO 9000
• ISO 9003. Sistemas de Calidad - Modelo para el aseguramiento

de la calidad en la inspección final y prueba.
• ISO 9004. Gerencia de la calidad y elementos del sistema de
calidad - Pautas.
• ISO 9000-3. Guía para la aplicación de la ISO 9001 al
desarrollo, suministro y mantenimiento del software.
• Dentro de las ventajas que presenta, se puede mencionar que
es bastante conocido por las organizaciones y sus clientes, y
sirve de apoyo a los demás estándares.
• La crítica más importante es que descuida la etapa de análisis,
haciendo énfasis en el diseño y el desarrollo. No fue creado
para el tratamiento del software especificamente, por cuanto es
una adaptación de las ideas de los procesos de manufactura.


CMM (Capability Maturity Model)
• Para Le Manh (Le Mahn, 1998), el CMM -creado por el SEI-.

Provee a las organizaciones de software de una guía sobre cómo
controlar el desarrollo y mantenimiento de sus procesos de
software, y cómo evolucionar hacia una cultura de ingeniería
de software y administración Proceso en
Nivel 5:
excelente. continuo
mejoramiento
Nivel 5:
Optimizado
Optimizado
• Fue diseñado para guiar a las Nivel 4:

Proceso Nivel 4:
organizaciones en la selección predecible Gerenciado
Gerenciado
de estrategias de mejoramien- Proceso

Nivel 3:
to de los procesos, determi- estándar y
consistente
Nivel 3:
Definido
Definido
nando la madurez del proceso
actual e identificando los Proceso
disciplinado
Nivel 2:
Nivel 2:
Repetitivo
Repetitivo
problemas más críticos para
la calidad y el mejoramiento Nivel 1:
Nivel 1:
Inicial
del proceso. Inicial


• El CMM está estructurado en cinco E
n S
a
(5) niveles de madurez que propor-
t
r l
a i
d d
cionan las bases para el mejora- a a
5
miento continuo del proceso. Estos
niveles definen una escala ordinal
para medir la madurez de un proceso E
y evaluar su capacidad. n S
t a
4 r l
a i
d d
a a
• La “madurez de un proceso de
software” es el grado para el cual un E
n
t
S
a
proceso específico está definido, 3 r

a
d
l
i
d
a
manejado, medido, controlado y es a
efectivo. E
n S
t a
2 r l
a i
• La “capacidad del proceso de d

a
d
a
software” describe el rango de E
resultados esperados que se pueden n S

a
1
t
r l
i
alcanzar siguiendo tal proceso.
a
d d
a a


• A excepción del nivel 1, cada NIVELES DE MADUREZ
NIVELES DE MADUREZ
nivel de madurez se descompo-
ne en áreas claves del proceso indican contienen
(18 en total).
Proceso de
• Cada área clave está organiza- Capacidad
ÁREAS CLAVES DEL PROCESO
ÁREAS CLAVES DEL PROCESO
da en 5 secciones llamadas
alcanzan organizadas por
características comunes.
• Las características comunes Metas
RASGOS COMUNES
RASGOS COMUNES
especifican las práctivas claves
(343 en total) que bien dirigi- dirigen contienen
das, permiten alcanzar los

objetivos de las áreas claves. Implementación
o
PRÁCTICAS CLAVES
PRÁCTICAS CLAVES
Institucionalización
• Las áreas claves del proceso describen
indican las áreas en que la
organización debería enfocar el Infraestructura
o
mejoramiento de un proceso de Actividades
desarrollo de software.

SPICE (Software Process Improvement and Capacitability dEtermination)
• Según la ISO/IEC (ISO/IEC, 1997), SPICE es un modelo para la

evaluación de procesos de software que se encuentra dentro de los
documento de la ISO y ha ido evolucionando hacia un proyecto de
estándar ISO 15504.
• La arquitectura del modelo contiene dos jerarquías:
– El lado izquierdo consiste en la
Arquitectura
categoría de procesos, compuestos del modelo
por procesos y éstos están compues-
tos por prácticas bases.
Categoría Nivel de
– Los procesos son evaluacos en Categoría
del proceso
del proceso
Nivel de
capacidad
capacidad
términos del lado derecho. Los
procesos pueden ser evaluados a un
Características
nivel de capacidad; los niveles de Proceso
Proceso
Características
comunes
comunes
capacidad están compuestos por
características comunes; las caracte-
Práctica Práctica
rísticas comunes, a su vez, están Práctica
base
base
Práctica
genérica
genérica
compuestas por prácticas genéricas.

NIVELES DE DESCRIPCIÓN
CAPACIDAD
0 El proceso no tiene ninguna característica común. Hay fracaso general para

NO REALIZADO realizar las prácticas bases en el proceso. No hay productos de trabajo o
rendimientos del proceso fácilmente identificables.
Generalmente se realizan prácticas bases del proceso. La actuación de estas
1 prácticas bases no puede planearse rigurosamente. La actuación depende del
REALIZADO conocimiento individual y el esfuerzo. Los individuos dentro de la organización
INFORMALMENTE están de acuerdo que esta acción debe realizarse y desde cuando. Hay productos
de trabajo identificables para el proceso.
2 En el proceso, las prácticas bases se planifican y se siguen. Se verifica la
PLANIFICADO Y actuación según los procedimientos especificados. Los productos de trabajo
SEGUIDO conforman los estándares especificados y los requisitos.
3 Las prácticas base son realizadas según un proceso bien definido que usa
BIEN DEFINIDO versiones aprobadas, ajustadas a los estándares y a los procesos documentados.
Se recolectan y analizan medidas detalladas de ejecución. Esto lleva a una
4 comprensión cuantitativa de la capacidad del proceso y una habilidad mejoradas
CUANTITATIVAMENTE para predecir su actuación. La actuación se maneja objetivamente. La calidad de
CONTROLADO los productos de trabajo es cuantitativamente conocida.
Se establece la efectividad del proceso cuantitativo y las metas de eficacia para la
5 ejecución., basado en las metas comerciales de la organización. La mejora
CONTINUAMENTE continua del proceso contra estas metas es habilitada por “feedback” desde la
MEJORADO ejecución de procesos definidos y manejando ideas y tecnologías innovadoras.
NIVELES DE CAPACIDAD. (ISO/IEC, 1997)


CATEGORÍA
DESCRIPCIÓN
DEL PROCESO
CLIENTE- Procesos que directamente impactan al cliente, desarrollo, soporte y
PROVEEDOR transición del software al cliente.
Procesos que directamente especifican, llevan a cabo, o mantienen, un
INGENIERÍA sistema y la documentación del usuario.
Procesos que establecen el proyecto, coordinan y manejan los recursos
PROYECTO para elaborar un producto o proporcionar servicios que satisfacen al
cliente.
Procesos que habilitan y apoyan la actuación de los otrs procesos en
SOPORTE un proyecto.
Procesos que establecen las metas comerciales de la organización y
ORGANIZACIÓN desarrollan el proceso, el producto y los recursos determinador, que
ayudarán a que la organización logre sus metas comerciales.
ÁREAS GENERALES DE ACTIVIDAD. CATEGORÍAS DE PROCESOS. (ISO/IEC, 1997)
• El Modelo SPICE fue ideado pensando en las particularidades que

implica el desarrollo de software, es decir, fue diseñado
especialmente para software

IDEAL (Initiating, Diagnosing, Establishing, Acting and Learning)
• Según Gremba y Myers (Gremba y Myers, 1997), IDEAL provee

un enfoque efectivo para adoptar mejoras en los procesos de
ingeniería de software, los métodos y las herramientas.
• Es un modelo de mejora organizacional que sirve de mapa para
iniciar, planificar e implementar acciones de mejoramiento.
• Guía a las organizaciones en la planificación e implementación
de programas para mejorar la efectividad del proceso de
desarrollo de software, siendo la estrategia que creó y
actualmente emplea el SEI para prestar sus servicios.
• Cubre todas las etapas del proceso de desarrollo de software y
toma en cuenta la características del a organización donde se
aplica. Sin embargo, no brinda suficiente detalle por cada
actividad. Hace mucho énfasis en el proceso y no da la
importancia necesaria al producto final.

IDEAL (Initiating, Diagnosing, Establishing, Acting and Learning)
Learning
(Aprender)
Analizar
Proponer y
futuras validar
acciones Implementar
la solución
Refinar la
solución
Estímulos para el Fijar el Construir el Establecer la

cambio contexto patrocinio infraestructura Acting
Prueba (Actuar)
piloto de
Initiating Caracterizar
la solución
(Comenzar) las situaciones

presente y
futura
Crear la
solución
Desarrollar
Diagnosing recomendaciones
(Diagnosticar) Plan de
Fijar acciones
prioridades
Desarrollar
el acercamiento
Establishing
(Establecer)
MODELO IDEAL. FASES Y ACTIVIDADES (Gremba y Myers, 1997)


PSP (Personal Software Process)
• Hayes (Hayes, 1997) define al PSP como una medida del proceso
de software diseñado para ser usado individualmente por los
ingenieros de software y, al igual que el CMM, el PSP está basado
en los principios del mejoramiento de procesos.
• Mientras CMM se enfoca en el mejoramiento de la capacidad
organizacional, el PSP se enfoca en la ingeniería individual y
extiende los procesos y el control gerencial a los ingenieros de
software; ásí, estos pueden desarrollar utilizando un enfoque
disciplinado y estructurado.
• El PSP está estructurado en siete niveles. Cada nivel se construye
sobre el anterior añadiendo algunos pasos; esto minimiza el
impacto de los cambios de los procesos en los ingenieros, ya que
adaptan las nuevas técnicas a las prácticas existentes.
• Las medidas que se introducen en cada nivel, están basadas en:
tiempo de desarrollo, defectos y tamaño de los programas.

Cubo de Calidad Sistémica
• Callaos y Callaos (Callos y Callaos, 1996) plantean que la calidad

del diseño debe ser sistémica, realmente calidad total.
• El sistema diseñado (producto) es diferente a las actividades

humanas (proceso) a través del cual el producto de sistema es
desarrollado.
• Tanto el producto como el proceso deben ser eficientes y efectivos

en su diseño; de esta relación se desprenden cuatro (4) clases de
calidad: eficiencia del producto, efectividad del producto, eficiencia
del proceso y efectividad del proceso.
• Cada una de las cuatro (4) clases de calidad dependen de las

otras. En términos del paradigma de investigación de operaciones,
no se puede maximizar una de ellas independientemente de las
otras; el óptimo global no necesariamente es el mismo óptimo local
y por lo general, el óptimo global no coincide con el óptimo local.


Cubo de Calidad Sistémica
• Callaos y Callaos (Callos y Callaos, 1996) diferencian entre las

clases de calidad según quién la reciba (cliente) y quién la
perciba (usuario). La calidad total en el diseño debe ser
orientada a ambos: al usuario y al cliente.
Cliente
Usuario
Eficiencia Efectividad
del del
producto producto
Eficiencia Efectividad
del del
proceso proceso
CUBO DE CALIDAD SISTÉMICA DE

ANÁLISIS Y SÍNTESIS DE SISTEMAS DE INFORMACIÓN
(Callaos y Callaos, 1996)


MODELO ORIENTADO AL PROCESO PROPUESTO POR LISI
• La solución propuesta establece un modelo que integra el

enfoque de Calidad Sistémica (base conceptual), con las
características presentes en el modelo de procesos de SPICE.
• El modelo propuesto presenta una estructura compleja que

está definida por niveles, donde cada nivel superior esta
conformado por elementos del nivel inferior. Los niveles son:
– Nivel 0: Ciclos de Vida.
– Nivel 1: Categorías.
– Nivel 2: Procesos.
– Nivel 3: Principios.
– Nivel 4: Bases Prácticas.


MODELO ORIENTADO AL PROCESO PROPUESTO POR LISI
Ciclo de Vida Ciclo de Vida de Ciclo de Vida

Nivel 0 Primario Apoyo Organizacional
Nivel 1
Categoría
Categoría
Categoria Categoría Categoría Categoría Organizacional
organizacional
Cliente_Proveedor Ingeniería de Soporte de Gestión
Nivel 2
SUP.1 ORG.1
ENG.1 MAN.1 MAN.2
CUS.1 CUS.2
SUP.2 SUP.3 SUP.4 ORG.2 ORG.3 ORG.4
ENG.2 MAN.3 MAN.4
CUS.3 CUS.4
SUP.5 SUP.6 SUP.7 ORG.5 ORG.6 ORG.7
SUP.8 ORG.8 ORG.9
Nivel 3
Principio 1 Principio 2 Principio 1 Principio 1 Principio 2 Principio 1 Principio 2 Principio 1 Principio 2
Principio 3 Principio 4 Principio 2 Principio 3 Principio 4 Principio 3 Principio 4 Principio 3 Principio 4
Principio 5 Principio 6 Principio 5 Principio 6
Principio 7 Principio 8 Principio 7 Principio 8
Principio 9
Nivel 4
ESTRUCTURA DEL MODELO DE EVALUACIÓN DE LA CALIDAD DEL PROCESO


Calidad Del Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Calidad Del Software

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SIMÓN BOLÍVAR

DEPARTAMENTO DE PROCESOS Y SISTEMAS

SISTEMAS DE INFORMACIÓN III

Material diseñado y elaborado por:

¿QUÉ ES CALIDAD DEL SOFTWARE?

• Pressman (Pressman, 1998) define la calidad del software

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

• Sridharan (Sridharan, 2000) indica que mientras el software que

• Hay tres (3) aspectos muy importantes con relación al

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

• Pressman (Pressman, 1998) considera que el aseguramiento de la

CONTROL DE LA CALIDAD DEL SOFTWARE

• Según Monsalve (Monsalve, 1998), el control de la calidad se

AUDITORÍA DE LA CALIDAD DEL SOFTWARE

• La auditoría de la calidad se utiliza para descubrir y detener los

CALIDAD DEL PRODUCTO DE SOFTWARE

• Para Monsalve (Monsalve, 1998), la principal meta de un

• La calidad que pueden alcanzar los productos de software, y en

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

• La calidad del producto de software involucra actividades

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE

La calidad está presente en todas las etapas del proceso de desa-

CALIDAD DEL PRODUCTO DE SOFTWARE

• El modelo fue propuesto por Mc Call en 1977 (Gillies, 1997) y

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

Las tres (3) áreas que contempla el Modelo de Mc Call abarcan

CALIDAD DEL PRODUCTO DE SOFTWARE

• REVISIÓN DEL PRODUCTO:

– Mantenibilidad (Facilidad de mantenimiento). Esfuerzo

– Flexibilidad. Esfuerzo necesario para modificar un

– Facilidad de prueba. Esfuerzo necesario para probar un

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

• TRANSICIÓN DEL PRODUCTO:

– Portabilidad. Esfuerzo necesario para transferir el

– Reusabilidad (capacidad de reutilización). Hasta dónde se

– Interoperatividad. Esfuerzo necesario para acoplar un

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

cesidades de los Completitud

usuarios, como Utilidad Eficiencia

ticas de rendi- Prueba Comunicabilidad

miento de hard- Mantenibilidad Auto-descriptivo

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

• Hewlett-Packard lo presenta ATRIBUTOS SUBATRIBUTOS

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

Presentado en 1992, las características de calidad de los productos

CALIDAD DEL PRODUCTO DE SOFTWARE

ATRIBUTOS QUE ABARCAN LAS CARACTERÍSTICAS DE LA NORMA ISO/IEC 9126

FUNCIONALIDAD USABILIDAD MANTENIMIENTO

• Adaptabilidad • Comprensibi- • Análisis

CONFIABILIDAD EFICIENCIA PORTABILIDAD

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

• En 1996, Dromey (Pfleeger, 1998) sugiere una técnica genérica

• Respecto a la conocida expresión “construir la calidad en el

SISTEMAS DE INFORMACIÓN III TEORÍA

CALIDAD DEL PRODUCTO DE SOFTWARE

• Clasifica las cualidades tangibles utilizando cuatro (4)