Calidad Del Software PDF

UNIVERSIDAD SIMN BOLVAR
DEPARTAMENTO DE PROCESOS Y SISTEMAS
SISTEMAS DE INFORMACIN III

TEORA
CONTENIDO:
QU ES CALIDAD DEL SOFTWARE?
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
CONTROL DE LA CALIDAD DEL SOFTWARE
AUDITORA DE LA CALIDAD DEL SOFTWARE
CALIDAD DEL PRODUCTO DE SOFTWARE
CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE
Material diseado 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 explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las
caractersticas implcitas que se espera de todo software
desarrollado profesionalmente.
En la definicin de la calidad del software pueden estar
involucrados aspectos como la ausencia de defectos, aptitud
para el uso, seguridad, confiabilidad y reunin de especificaciones. 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 aadido despus.
Para que el producto final sea de calidad, el proceso por medio
del cual ste es elaborado debe ser tambin de calidad.
TEORA


Sridharan (Sridharan, 2000) indica que mientras el software que
se est desarrollado rene los requerimientos y su desempeo 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 relacin
aseguramiento de la calidad del software: (Wiegers, 1990)
al
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 estn
directamente involucradas en el esfuerzo de desarrollo.
TEORA


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 descripcin del
proyecto de software.
Revisar las actividades de ingeniera 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 estndares definidos.
Alamacenar cualquier inconformidad y reportarla a la gerencia
media.
TEORA

CONTROL DE LA CALIDAD DEL SOFTWARE

Segn 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
observacin 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 metodologas 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 necesarias 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, adems de que la calidad estara
asegurada en sus bases.
TEORA

AUDITORA DE LA CALIDAD DEL SOFTWARE

La auditora de la calidad se utiliza para descubrir y detener los
errores del software. Se lleva a cabo para monitorear eventos especficos, o bien para revisar todas las actividades de un sistema.
Las auditoras permiten garantizar la calidad del software: luego
de llevar a cabo una auditora de calidad, es ms fcil mantener
un registro con las deficiencias presentadas.
La auditora 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
proteccin soportados por el sistema.
2) Descubrir los usuarios frecuentes y espordicos que se
esfuerzan por desviar los mecanismos de proteccin.
3) Descubrir cualquier uso de privilegios que pueden ocurrir
cuando un usuario asume una funcionalidad con privilegios
mayores que el suyo propio.
TEORA


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 lneas de cdigo.
La calidad que pueden alcanzar los productos de software, y en
general cualquier tipo de producto, est sometida a la manera
cmo se desarrolla cada una de las etapas de la vida del
producto, inicindose con la concepcin de la idea del producto
hasta la entrega final y mantenimiento del mismo.
TEORA


La calidad del producto de software involucra actividades
como:
Administracin de la calidad.
Uso de tecnologa de Ingeniera de Software eficiente.
Aplicacin de tcnicas formales a lo largo de todo el
proceso de desarrollo.
Minimizacin de las variaciones entre productos.
Verificacin y pruebas formales en las diferentes etapas
del desarrollo.
Control de la documentacin.
Correcto mantenimiento y servicios de post-venta.
TEORA


La calidad est presente en todas las etapas del proceso de desarrollo de los productos de software. A grandes rasgos:
CALIDAD EN EL DISEO. Se basa en definir un listado de
especificaciones a seguir; involucra la descripcin de los
procesos de desarrollo, tareas y responsabilidades de los
equipos de desarrollo; dichos procesos pueden estar
estandarizados.
CALIDAD EN LA IMPLEMENTACIN. Se enfoca al grado de
cumplimiento de los requerimientos de diseo. Si los
requerimientos est bien definidos y especificados, el
cumplimiento de la calidad en esta fase no debe tornarse difcil.
CALIDAD EN LA SATISFACCIN. 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
preocupacin por ella en las etapas anteriores.
TEORA


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
DE TRABAJO
DESCRIPCIN
OPERACIN
DEL
PRODUCTO
Requiere que pueda ser comprendida rpidamente, operada

eficientemente y que los resultados sean aquellos requeridos por el
usuario
REVISIN
DEL
PRODUCTO
Est relacionada con la correccin de errores y la adaptacin de los

sistemas. Esto es importante porque es generalmente considerada
como la parte ms costosa en el desarrollo de software.
TRANSICIN
DEL
PRODUCTO
Puede que no sea muy importante en todas las aplicaciones. Sin

embargo, la orientacin a procesamiento distribuido y el rpido cambio
en el hardware es probable que incremente su importancia.
LAS TRES REAS DIRECCIONADAS POR EL MODELO DE MCCALL. (Gillies, 1997)
TEORA


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

los siguientes aspectos: (Pressman, 1998)
OPERACIN DEL PRODUCTO:
Correccin. Hasta dnde satisface un programa su
especificacin y logra los objetivos de la misin del cliente
Fiabilidad. Hasta dnde se espera que un programa lleve a
cabo su funcin pretendida con la exactitud requerida.
Eficiencia. Cantidad de recursos informticos y cdigo
necesarios para que un programa realice su funcin
Integridad. Hasta dnde 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.
TEORA


Mc Call
REVISIN DEL PRODUCTO:

Mantenibilidad (Facilidad de mantenimiento). Esfuerzo
necesario para localizar y arreglar un error del programa
(definicin limitada)
Flexibilidad. Esfuerzo
programa operativo.
necesario
para
modificar
un
Facilidad de prueba. Esfuerzo necesario para probar un

programa para asegurarse que realiza su funcin
pretendida.
TEORA


Mc Call
TRANSICIN DEL PRODUCTO:

Portabilidad. Esfuerzo necesario para transferir el
programa de un entorno de sistema de hardware y/o
software a otro.
Reusabilidad (capacidad de reutilizacin). Hasta dnde se
vuelve a emplear un programa [o partes de un programa] en
otras aplicaciones, en relacin al empaquetamiento y
alcance de las funciones que realiza el programa.
Interoperatividad. Esfuerzo necesario para acoplar un
sistema con otro.
TEORA


Boehm
Presentado por
Boehm en 1978
(Pfleeger, 1998),
incluye las necesidades de los
usuarios, como
lo hace Mc Call;
sin embargo, incluye caractersticas de rendimiento de hardware que no se
encuentran en
el modelo de
McCall.
Portabilidad
Independencia
de dispositivo
Auto-contencin
Fiabilidad
Precisin
Completitud
Robustez/integridad
Utilidad
General
Eficiencia
Por la
utilidad
Consistencia
Contabilidad
Ingeniera Humana
Eficiencia de dispositivo
Accesibilidad
Prueba
Comunicabilidad
Auto-descriptivo
Mantenibilidad
Entendibilidad
Estructuracin
Concisin
Modificabilidad
Legibilidad
Aumentabilidad
TEORA


FURPS (Funcionality, Usability, Reliability, Performance, Supportability)
Hewlett-Packard lo presenta
en 1987, desarrollando un
conjunto de factores de calidad de software (funcionalidad, facilidad de empleo,
fiabilidad,
rendimiento
y
capacidad de soporte) y sus
atributos.
Los factores de calidad FURPS
y sus atributos, pueden usarse para establecer mtricas de
la calidad para todas las
actividades del proceso de
desarrollo de Sistemas de
Informacin.
ATRIBUTOS
FUNCIONALIDAD
FACILIDAD
DE
USO
FIABILIDAD
RENDIMIENTO
CAPACIDAD
DE
SOPORTE
SUBATRIBUTOS
Conjunto de caractersticas
Capacidades
Generalidad
Seguridad
Factores humanos
Aesthetics
Consistencia
Documentacin
Frecuencia/severidad de falla
Recuperabilidad
Predictabilidad
Precisin
Tiempo promedio de falla
Velocidad
Eficiencia
Consumo de recursos
Throughput
Tiempo de respuesta
Capacidad de prueba
Extensabilidad
Adaptabilidad
Mantenibilidad
Compatibilidad
Configurabilidad
Capacidad de Servicio
Capacidad de Instalacin
Capacidad de Localizacin
TEORA


ISO/IEC 9126
Presentado en 1992, las caractersticas de calidad de los productos

de software que establece este estndar de calidad, son:
FUNCIONALIDAD. Existencia de un conjunto de funciones y
propiedades especficas establecidas.
CONFIABILIDAD. Capacidad del software para mantener su nivel
de actuacin bajo ciertas condiciones, en un perodo de tiempo.
USABILIDAD. Esfuerzo necesario para el uso y el valor de uso, por
un conjunto determinado de usuarios.
EFICIENCIA. Relacin entre el nivel de desempeo del software y
la cantidad de recursos usados bajo ciertas condiciones.
MANTENIMIENTO. Esfuerzo necesario para hacer modificaciones
especficas.
PORTABILIDAD. Habilidad del software para ser transferido de un
ambiente a otro.
TEORA


ISO/IEC 9126
ATRIBUTOS QUE ABARCAN LAS CARACTERSTICAS DE LA NORMA ISO/IEC 9126
FUNCIONALIDAD
Adaptabilidad
Exactitud
Interoperabilidad
Complacencia
Seguridad
USABILIDAD
Comprensibilidad
Aprendizaje
Operabilidad
CONFIABILIDAD
Madurez
Tolerancia a
fallas
Recuperabilidad
MANTENIMIENTO
Anlisis
Cambio
Estabilidad
Prueba
EFICIENCIA
Comportamiento
del tiempo
Comportamiento
de los recursos
PORTABILIDAD
Adaptabilidad
Instalacin
Conformidad
Reemplazo
TEORA


Dromey
En 1996, Dromey (Pfleeger, 1998) sugiere una tcnica genrica

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, guas de usuarios, diseos, y cdigo), las
propiedades tangibles de los componentes y las propiedades
tangibles de la composicin de los componentes.
Respecto a la conocida expresin 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 mdulos sin efectos colaterales) que
resulten en la fiabilidad y mantenibilidad.
TEORA


Dromey
Clasifica las
propiedades:
cualidades
tangibles
utilizando
cuatro
(4)
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, implementacin o que tan bien ha sido
compuesto.
Contextuales. Cmo los componentes son compuestos y las
influencias que ejercen sobre la calidad del producto.
Descriptivas. Para ser til un software debe ser fcil de entender
y utilizar de acuerdo a su propsito. Estas propiedades
descriptivas aplican a requerimientos, diseos, implementacin y a
las interfaces de usuario
TEORA


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

cuales son representados por las caractersticas externas de
alto nivel del modelo ISO 9126: Usabilidad, Funcionalidad,
Fiabilidad, Mantenibilidad, Eficiencia y Portabilidad.
Adems, incluye elementos de Eficiencia del Producto,
segn el modelo de Calidad Sistmica, representados por las
propiedades de los requerimientos, diseo e implementacin
del producto, siguiendo el modelo de Dromey.
Por ltimo contempla elementos de Eficiencia y Efectividad
del Proceso, los cuales fueron identificados en el Estndar
ISO 15504.
TEORA


MODELO ORIENTADO AL PRODUCTO PROPUESTO POR LISI
Atributos externos
Usabilidad
Atributos Internos/
Propiedades del Producto
Requerimientos
Funcionalidad
Fiabilidad
Diseo
Mantenibilidad
Eficiencia
Portabilidad
Implementacin
Efectividad
del Producto
Eficiencia
del Producto
Efectividad
del Proceso
Eficiencia
del Proceso
MODELO DE CALIDAD DE SOFTWARE

TEORA


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

que pueden usarse para los propsitos 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 demostracin de la capacidad de un proveedor para disear
y suministrar un producto determinado.
ISO 9000. Normas para la gerencia y el aseguramiento de la
calidad. Gua para la seleccin y uso.
ISO 9001. Sistemas de Calidad - Modelo para el asefuramiento
de la calidad en el diseo, desarrollo, produccin, instalacin y
servicio.
ISO 9002. Sistema de Calidad - Modelo para el aseguramiento
de la calidad en la produccin e instalacin.
TEORA


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

de la calidad en la inspeccin final y prueba.
ISO 9004. Gerencia de la calidad y elementos del sistema de
calidad - Pautas.
ISO 9000-3. Gua para la aplicacin 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 dems estndares.
La crtica ms importante es que descuida la etapa de anlisis,
haciendo nfasis en el diseo y el desarrollo. No fue creado
para el tratamiento del software especificamente, por cuanto es
una adaptacin de las ideas de los procesos de manufactura.
TEORA


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

Provee a las organizaciones de software de una gua sobre cmo
controlar el desarrollo y mantenimiento de sus procesos de
software, y cmo evolucionar hacia una cultura de ingeniera
de software y administracin
Proceso en
Nivel 5:
continuo
Nivel 5:
Optimizado
excelente.
mejoramiento
Optimizado
Fue diseado para guiar a las
organizaciones en la seleccin
de estrategias de mejoramiento de los procesos, determinando la madurez del proceso
actual e identificando los
problemas ms crticos para
la calidad y el mejoramiento
del proceso.
Proceso
predecible
Proceso
estndar y
consistente
Proceso
disciplinado
Nivel 4:
Nivel 4:
Gerenciado
Gerenciado
Nivel 3:
Nivel 3:
Definido
Definido
Nivel 2:
Nivel 2:
Repetitivo
Repetitivo
Nivel 1:
Nivel 1:
Inicial
Inicial
TEORA


El CMM est estructurado en cinco
(5) niveles de madurez que proporcionan las bases para el mejoramiento continuo del proceso. Estos
niveles definen una escala ordinal
para medir la madurez de un proceso
y evaluar su capacidad.
La madurez de un proceso de
software es el grado para el cual un
proceso especfico est definido,
manejado, medido, controlado y es
efectivo.
La capacidad del proceso de
software describe el rango de
resultados esperados que se pueden
alcanzar siguiendo tal proceso.
E
n
t
r
a
d
a
S
a
l
i
d
a
E
n
t
r
a
d
a
S
a
l
i
d
a
E
n
t
r
a
d
a
S
a
l
i
d
a
E
n
t
r
a
d
a
S
a
l
i
d
a
E
n
t
r
a
d
a
S
a
l
i
d
a
TEORA


A excepcin del nivel 1, cada
nivel de madurez se descompone en reas claves del proceso
(18 en total).
Cada rea clave est organizada en 5 secciones llamadas
caractersticas comunes.
Las caractersticas comunes
especifican las prctivas claves
(343 en total) que bien dirigidas, permiten alcanzar los
objetivos de las reas claves.
Las reas claves del proceso
indican las reas en que la
organizacin debera enfocar el
mejoramiento de un proceso de
desarrollo de software.
NIVELES DE MADUREZ
NIVELES DE MADUREZ
indican
contienen
Proceso de
Capacidad
REAS CLAVES DEL PROCESO

REAS CLAVES DEL PROCESO
alcanzan
organizadas por
Metas
RASGOS COMUNES
RASGOS COMUNES
dirigen
contienen
Implementacin
o
Institucionalizacin
PRCTICAS CLAVES
PRCTICAS CLAVES
describen
Infraestructura
o
Actividades
TEORA


SPICE (Software Process Improvement and Capacitability dEtermination)
Segn la ISO/IEC (ISO/IEC, 1997), SPICE es un modelo para la

evaluacin de procesos de software que se encuentra dentro de los
documento de la ISO y ha ido evolucionando hacia un proyecto de
estndar ISO 15504.
La arquitectura del modelo contiene dos jerarquas:
El lado izquierdo consiste en la
categora de procesos, compuestos
por procesos y stos estn compuestos por prcticas bases.
Los procesos son evaluacos en
trminos del lado derecho. Los
procesos pueden ser evaluados a un
nivel de capacidad; los niveles de
capacidad estn compuestos por
caractersticas comunes; las caractersticas comunes, a su vez, estn
compuestas por prcticas genricas.
Arquitectura
del modelo
Categora
Categora
del proceso
del proceso
Nivel de
Nivel de
capacidad
capacidad
Proceso
Proceso
Caractersticas
Caractersticas
comunes
comunes
Prctica
Prctica
base
base
Prctica
Prctica
genrica
genrica
TEORA


NIVELES DE
CAPACIDAD
0
NO REALIZADO
1
REALIZADO
INFORMALMENTE
DESCRIPCIN
El proceso no tiene ninguna caracterstica comn. Hay fracaso general para
realizar las prcticas bases en el proceso. No hay productos de trabajo o
rendimientos del proceso fcilmente identificables.
Generalmente se realizan prcticas bases del proceso. La actuacin de estas
prcticas bases no puede planearse rigurosamente. La actuacin depende del
conocimiento individual y el esfuerzo. Los individuos dentro de la organizacin
estn de acuerdo que esta accin debe realizarse y desde cuando. Hay productos
de trabajo identificables para el proceso.
2
PLANIFICADO Y
SEGUIDO
En el proceso, las prcticas bases se planifican y se siguen. Se verifica la

actuacin segn los procedimientos especificados. Los productos de trabajo
conforman los estndares especificados y los requisitos.
3
BIEN DEFINIDO
Las prcticas base son realizadas segn un proceso bien definido que usa
versiones aprobadas, ajustadas a los estndares y a los procesos documentados.
Se recolectan y analizan medidas detalladas de ejecucin. Esto lleva a una

4
comprensin cuantitativa de la capacidad del proceso y una habilidad mejoradas
CUANTITATIVAMENTE para predecir su actuacin. La actuacin se maneja objetivamente. La calidad de
CONTROLADO
los productos de trabajo es cuantitativamente conocida.
5
CONTINUAMENTE
MEJORADO
Se establece la efectividad del proceso cuantitativo y las metas de eficacia para la

ejecucin., basado en las metas comerciales de la organizacin. La mejora
continua del proceso contra estas metas es habilitada por feedback desde la
ejecucin de procesos definidos y manejando ideas y tecnologas innovadoras.
NIVELES DE CAPACIDAD. (ISO/IEC, 1997)

TEORA


CATEGORA
DEL PROCESO
DESCRIPCIN
CLIENTEPROVEEDOR
Procesos que directamente impactan al cliente, desarrollo, soporte y

transicin del software al cliente.
INGENIERA
Procesos que directamente especifican, llevan a cabo, o mantienen, un

sistema y la documentacin del usuario.
PROYECTO
Procesos que establecen el proyecto, coordinan y manejan los recursos

para elaborar un producto o proporcionar servicios que satisfacen al
cliente.
SOPORTE
Procesos que habilitan y apoyan la actuacin de los otrs procesos en

un proyecto.
Procesos que establecen las metas comerciales de la organizacin y

ORGANIZACIN desarrollan el proceso, el producto y los recursos determinador, que
ayudarn a que la organizacin logre sus metas comerciales.
REAS GENERALES DE ACTIVIDAD. CATEGORAS DE PROCESOS. (ISO/IEC, 1997)
El Modelo SPICE fue ideado pensando en las particularidades que

implica el desarrollo de software, es decir, fue diseado
especialmente para software
TEORA


IDEAL (Initiating, Diagnosing, Establishing, Acting and Learning)
Segn Gremba y Myers (Gremba y Myers, 1997), IDEAL provee

un enfoque efectivo para adoptar mejoras en los procesos de
ingeniera de software, los mtodos y las herramientas.
Es un modelo de mejora organizacional que sirve de mapa para
iniciar, planificar e implementar acciones de mejoramiento.
Gua a las organizaciones en la planificacin e implementacin
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 caractersticas del a organizacin 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.
TEORA


IDEAL (Initiating, Diagnosing, Establishing, Acting and Learning)
Learning
(Aprender)
Proponer
futuras
acciones
Analizar
y
validar
Implementar
la solucin
Refinar la
solucin
Estmulos para el
cambio
Fijar el
contexto
Construir el
patrocinio
Initiating
(Comenzar)
Establecer la
infraestructura
Prueba
piloto de
la solucin
Acting
(Actuar)
Caracterizar
las situaciones
presente y
futura
Crear la
solucin
Diagnosing
(Diagnosticar)
Desarrollar
recomendaciones
Fijar
prioridades
Plan de
acciones
Desarrollar
el acercamiento
Establishing
(Establecer)
MODELO IDEAL. FASES Y ACTIVIDADES (Gremba y Myers, 1997)

TEORA


PSP (Personal Software Process)
Hayes (Hayes, 1997) define al PSP como una medida del proceso
de software diseado 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 ingeniera 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 aadiendo algunos pasos; esto minimiza el
impacto de los cambios de los procesos en los ingenieros, ya que
adaptan las nuevas tcnicas a las prcticas existentes.
Las medidas que se introducen en cada nivel, estn basadas en:
tiempo de desarrollo, defectos y tamao de los programas.
TEORA


Cubo de Calidad Sistmica
Callaos y Callaos (Callos y Callaos, 1996) plantean que la calidad

del diseo debe ser sistmica, realmente calidad total.
El sistema diseado (producto) es diferente a las actividades
humanas (proceso) a travs del cual el producto de sistema es
desarrollado.
Tanto el producto como el proceso deben ser eficientes y efectivos
en su diseo; de esta relacin 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 trminos del paradigma de investigacin 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.
TEORA


Cubo de Calidad Sistmica
Callaos y Callaos (Callos y Callaos, 1996) diferencian entre las

clases de calidad segn quin la reciba (cliente) y quin la
perciba (usuario). La calidad total en el diseo 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 SISTMICA DE

ANLISIS Y SNTESIS DE SISTEMAS DE INFORMACIN
(Callaos y Callaos, 1996)
TEORA


MODELO ORIENTADO AL PROCESO PROPUESTO POR LISI
La solucin propuesta establece un modelo que integra el

enfoque de Calidad Sistmica (base conceptual), con las
caractersticas 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: Categoras.
Nivel 2: Procesos.
Nivel 3: Principios.
Nivel 4: Bases Prcticas.
TEORA


MODELO ORIENTADO AL PROCESO PROPUESTO POR LISI
Ciclo de Vida
Primario
Nivel 0
Ciclo de Vida de
Apoyo
Ciclo de Vida
Organizacional
Nivel 1
Categoria
Cliente_Proveedor
Categora
Ingeniera
Categora
de Soporte
ENG.1
SUP.1
Categora
de Gestin
Categora
Categora
Organizacional
organizacional
Nivel 2
CUS.1
CUS.3
CUS.2
CUS.4
ENG.2
SUP.2
SUP.5
MAN.1
SUP.3
SUP.4
SUP.6
SUP.7
MAN.3
ORG.1
MAN.2
MAN.4
ORG.2
ORG.3
ORG.4
ORG.5
ORG.6
ORG.7
ORG.8
SUP.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 EVALUACIN DE LA CALIDAD DEL PROCESO

TEORA

Calidad Del Software PDF

Cargado por

Información del documento

Título original

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 PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SIMN BOLVAR

DEPARTAMENTO DE PROCESOS Y SISTEMAS

SISTEMAS DE INFORMACIN III

UNIVERSIDAD SIMN BOLVAR

QU ES CALIDAD DEL SOFTWARE?

UNIVERSIDAD SIMN BOLVAR

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

La calidad no se puede probar, se construye.

UNIVERSIDAD SIMN BOLVAR

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CONTROL DE LA CALIDAD DEL SOFTWARE

UNIVERSIDAD SIMN BOLVAR

AUDITORA DE LA CALIDAD DEL SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

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

Requiere que pueda ser comprendida rpidamente, operada

Est relacionada con la correccin de errores y la adaptacin de los

Puede que no sea muy importante en todas las aplicaciones. Sin

LAS TRES REAS DIRECCIONADAS POR EL MODELO DE MCCALL. (Gillies, 1997)

SISTEMAS DE INFORMACIN III

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

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

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

REVISIN DEL PRODUCTO:

Facilidad de prueba. Esfuerzo necesario para probar un

SISTEMAS DE INFORMACIN III

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

TRANSICIN DEL PRODUCTO:

SISTEMAS DE INFORMACIN III

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

Presentado en 1992, las caractersticas de calidad de los productos

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

ATRIBUTOS QUE ABARCAN LAS CARACTERSTICAS DE LA NORMA ISO/IEC 9126

SISTEMAS DE INFORMACIN III

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

En 1996, Dromey (Pfleeger, 1998) sugiere una tcnica genrica

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

Correctitud. Pueden ser internas (asociadas con los componentes

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

El modelo presenta aspectos de Efectividad del Producto los

UNIVERSIDAD SIMN BOLVAR

CALIDAD DEL PRODUCTO DE SOFTWARE

MODELO DE CALIDAD DE SOFTWARE