NORMAS Y MODELOS REFERENTES A LA CALIDAD DE SOFTWARE TANTO PARA

LOS PROCESOS DE DESARROLLO COMO PARA EL PRODUCTO FINAL

KEYLA FERNANDA SARMIENTO USCÁTEGUI

Profesora: Gloria Elisa Torres Rodríguez

CUADRO COMPARATIVO

UNIVERSIDAD DE SANTANDER

MAESTRÍA EN GESTIÓN DE LA TECNOLOGÍA EDUCATIVA

EVALUACIÓN DE LA CALIDAD DE LA TECNOLOGÍA EDUCATIVA

BUCARAMANGA

2017
 NORMAS Y MODELOS REFERENTES A LA CALIDAD DE SOFTWARE TANTO PARA LOS PROCESOS DE
DESARROLLO COMO PARA EL PRODUCTO FINAL

PROCESO
NORMA O CARACTERÍSTICAS Y ESTRUCTURA VENTAJAS DESVENTAJAS
MODELO OBJETIVOS
El propósito del modelo es El CMMi está caracterizado por La mayor ventaja del El modelo CMMI
evaluar la madurez de los áreas de proceso para las 4 CMMI es que ha no es un buen
procesos de una organización y disciplinas que cubre actualmente, demostrado ser una indicador del
proporcionar una orientación es decir: Ingeniería de Sistemas metodología de gran rendimiento
referente a cómo mejorar los (SE), Ingeniería del Software, eficacia.  económico de una
CMMi procesos que darán lugar a Desarrollo Integrado del Producto y organización. 
mejores productos. El modelo del Proceso (IPPD) y la Fuente Aumento de la
se diseñó para que se use como proveedora (A). productividad. El proceso de
El modelo CMMI base de las iniciativas evaluación es muy
vio la luz en 1987 enfocadas a mejorar los Mejora la comunicación, costoso en tiempo y
como Capability procesos y, en el ámbito de la para que cada participante esfuerzo.
Maturity Model evaluación, únicamente como cumpla con sus
(CMM), un ayuda para medir las mejoras. responsabilidades. La complejidad de
proyecto del la evaluación
Software Los Enfoques del CMMi tienen Mejora la planificación, continua puede
Engineering como finalidad atender a las para que se establezcan atentar contra la
Institute, que es un diversas necesidades de las planes más realistas. definición de
centro de organizaciones que quieren objetivos concretos
investigación de la realizar la mejora de sus Mejora la calidad del de madurez.
Universidad procesos. Existen 2 enfoques: producto.
Carnegie-Mellon. Continuo y Escalonado.
Se establece más
conocimiento sobre la
organización.
 El esquema TickIT es una La guía de TickIT provee el enlace Reduce el riesgo de Tiempo
certificación de sistemas de necesario para que la conformación errores y tiempos de
gestión ISO 9000 para (o no) del sistema inactividad. Presupuesto
TickIT fabricantes de programas auditado respecto al modelo TickIT,
informáticos y proveedores de pueda ser expresada en función de Mejora la efectividad de Costos
En 1991, el servicios. Está enfocado a los criterios de la su producto o servicio.
Consejo Nacional organizaciones en las que la ISO 9001, logrando así la
de Acreditación de actividad empresarial primaria aplicación de esta última al Comprende las
los Organismos de es el desarrollo y distribución desarrollo de software. Esta guía necesidades de sus
Certificación de programas informáticos, la está compuesta por las siguientes clientes en cada etapa del
(National operación de centros de datos o partes: ciclo de vida de su
Accreditation la entrega de servicios producto.
Council of informáticos. Parte A - Introducción al TickIT y
Certification el proceso de certificación. Proporciona una mejora
Bodies, NACCB), Los objetivos principales de continua, obteniendo una
introdujo en el TickIT son, además de Parte B - Guía para los Clientes. calidad de producto
Reino Unido el desarrollar un sistema de mejorada y repetibilidad
programa TickIT certificación aceptable en el Parte C - Guía para los
como una respuesta mercado, estimular a los Distribuidores. Desarrolla un marco para
a las quejas desarrolladores de software a controlar las
emitidas por las implementar sistemas de Parte D - Guía para los Auditores. consideraciones de
organizaciones calidad, dando la dirección y pruebas, costes y tiempos
dedicadas a la guías necesarias para tal efecto. Parte E - Requerimientos del
elaboración de El objetivo de la certificación es Sistema de Administración de la
software con demostrar que las prácticas Calidad del Software Perspectivas
respecto a la necesarias para asegurar la estándares.
calidad y calidad durante el desarrollo de
consistencia de las software existen y son Parte F - Requerimientos del
evaluaciones para verificables. En general, el Sistema de Administración de la
la certificación ante modelo permite certificar Calidad del Software Perspectiva
la norma ISO cualquier tipo de proyecto a del Proceso.
9001:2000. través de una estructura más
flexible.
 Este proyecto al igual que otros, 1. Organización. Fundamentado en Se implementa
tiene como principio el reducir 2. Metodología modelos ISO 9000 y principalmente en
costos y mejorar la calidad 2.1 Ciclo de Vida Dependiente CMMi Europa.
previendo problemas. Su 2.2 Ciclo de Vida Independiente
Bootstrap
objetivo es desarrollar un 2.2.1 Gestión Uso de tecnología Incompleto en
método para la evaluación de 2.2.2 Soporte moderna. comparación de
Este proyecto fue
procesos de desarrollo de 2.2.3 Cliente proveedor otros modelos.
creado por la
software (SW). Inicialmente se 2.2.4 Relacionado a proceso Da soporte a la
Comisión Europea
basó en el modelo de madurez 3. Tecnología evaluación, indicando
como parte del
de CMM añadiendo conceptos como el estándar de
programa ESPRIT
de calidad de ISO 9000. A esto referencia ha sido
(ESPRIT 5441
incluyó conceptos para poder aplicado
BOOTSTRAP: A
evaluar desarrollos de SW de en la organización
European
otras industrias distintas a la evaluada.
Assessment
militar y cambiar su cobertura
Method to Improve
de evaluación para tomar desde Ayuda a incrementar la
Software
pequeñas UPS hasta grandes eficacia de los procesos
Development).
corporaciones. poniendo en práctica los
requisitos del
estándar en la
organización.

Personal SW El proceso de PSP consiste de La estructura del proceso PSP los datos del PSP mejoran Es necesario que
Process (PSP) un conjunto de métodos, comienza con los requerimientos, y el planeamiento y siguen cada uno de los
formularios y scripts que con el primer llamadolos proyectos de software miembros tengan el
El PSP fue muestran a los Ingenieros de “Planificación”. Hay un script de compromiso y la
desarrollado Software cómo planificar, planificación que sirve de guía para Eliminación de defectos disciplina de seguir
por Watts medir y administrar su trabajo. este trabajo y un resumen de la en productos de alta el plan.
Humphrey. Es una El PSP está diseñado para ser planificación para registrar los datos
calidad, así como
tecnología de SEI usado en algún lenguaje de de la planificación. reducciones en los costos Se debe llenar toda
(Software programación o metodología de de prueba y en el tiempo la documentación
Engineering diseño, y puede ser usado en Los Ingenieros registran el tiempo y del ciclo requerida que
Institute) que trae varios aspectos del trabajo de los datos de los defectos. Al final incluye sus
disciplina a las software. Consiste en un del trabajo, durante la última etapa PSP provee un espacio registros,
prácticas de los proceso de nivel 5 de CMM (post mortem), los Ingenieros para aprender y practicar planificación, las
Ingenieros de diseñado para calcular el costo sumarizan tanto los datos de los las mejoras del proceso plantillas o
 individual. defectos como formularios.
los tiempos, miden el tamaño del PSP ayuda a los
programa e ingresan estos datos en Ingenieros y a sus Se debe contar con
el resumen de plan. Luego, se Gerentes a poner en un buen conjunto
entrega el producto terminado con práctica la administración de métricas y
el resumen de la planificación. del proceso cuantitativo. parámetros de
Software,
calidad, lo cual,
mejorando la
Aprenden a utilizar para algunas
calidad del
procesos definidos y a organizaciones,
producto,
recopilar datos para puede ser difícil de
aumentando los
administrar, controlar y definir.
costos y
mejorar el trabajo.
reduciendo el
Cada miembro
tiempo del ciclo de
debe de estar
desarrollo del
entrenado en el
software.
PSP, si algún
miembro se va, es
necesario entrenar a
los nuevos
miembros.

Team SW Process El objetivo del TSP es construir
(TSP) y guiar a los equipos. Los
equipos son requeridos para la
El proceso TSP mayoría de los proyectos de
(Team Software Ingeniería. El desarrollo de
Process) fue sistemas es una actividad en
desarrollado por equipo, y la efectividad del
Watt Humphrey en equipo determina la calidad de
1996. la Ingeniería. En Ingeniería, los
equipos de desarrollo tienen
múltiples especialidades y todos
los miembros trabajan en vista
de un objetivo en común.
Los objetivos de TSP son: (1)
CMM – mejora la capacidad de la Mejora la productividad Los miembros
organización y el enfoque de la de las personas. tienen que tener el
Dirección compromiso y la
Mejora en los hábitos de disciplina de seguir
TSP – mejora el rendimiento del programación. el plan.
equipo. Existe un enfoque respecto
del proceso / producto Detección temprana de Se debe llenar toda
defectos y riesgos. la documentación
PSP – mejora las falencias requerida.
individuales. Tiene un enfoque Mejora en la calidad.
respecto del personal. Puede resultar una
desventaja don
El entrenamiento en PSP es gerencia no deje
requerido para suministrar a los trabajar a los
Ingenieros del conocimiento equipos de trabajo
 ayudar a los equipos de
Ingeniería de Software a
elaborar productos de calidad
dentro de los costos y tiempos
establecidos, (2) tener equipos
rápidos y confiables; y (3)
optimizar el performance del
equipo durante todo el
proyecto.
Es una propuesta de objetivos /
metas orientado a la definición
de modelos de calidad. Se
propone el paradigma GQM
para evaluar la calidad de cada
proyecto. Este modelo utiliza
una propuesta para definir un
GQM
modelo de calidad hasta
obtener las métricas respectivas
(objetivo-pregunta-
con el análisis e interpretación
métrica /goal –
de los datos de las mediciones
question - metric)
respectivas. Plantea el enfoque
de Basili y
de medición para evaluar la
Rombach (1998).
calidad del
software basado en la
identificación de objetivos a
lograr.
necesario para utilizar TSP. El autodirigidos de
entrenamiento en PSP incluye: (1) acuerdo a sus
aprender cómo realizar un planes, algo que no
planeamiento detallado, (2) muchos resisten.
recopilar y utilizar los datos del
proceso, (3) desarrollar planes
valuados, (4) medir y administrar la
calidad del producto y (5) definir y
utilizar los procesos operacionales.
PRODUCTO
Consta de 3 etapas:
1. Listar los objetivos principales
del desarrollo y mantenimiento
del proyecto.
2. Para cada objetivo, se deben
obtener las preguntas que
deben contestarse para saber si
se están cumpliendo los
objetivos.
3. Decidir qué medir para poder
contestar las preguntas de
manera adecuada, es decir,
desarrollar un conjunto de métricas
que ayuden a responder la
pregunta.
 McCall se focaliza en el El modelo de McCall organiza los
producto fina identificando factores en tres ejes o puntos de
atributos claves desde el punto vista desde los cuales el usuario
de vista del usuario, estos puede contemplar la calidad de un
atributos se denominan factores producto (1) Operación del
de calidad y son normalmente producto, (2) Revisión del producto
McCall atributos externos; pero y (3) Transición del producto. Cada
también se incluyen algunos punto de vista se descompone en
El modelo McCall atributos posiblemente una serie de factores que
fue el primero en internos. Los factores de determinan la calidad de cada una
ser presentado en calidad son demasiados de ellos. Cada factor determinante
1977 y se originó abstractos para ser medidos de la calidad, se descompone, a su
motivado por Air directamente, por lo que por vez, en una serie de criterios o
Forcé y Dod. cada uno de ellos se introduce propiedades que determinan su
atributos de bajo nivel calidad. Los criterios pueden ser
denominados criterios de evaluados mediante un
calidad. conjunto de métricas. Para cada
criterio deben fijarse unos valor
máximo y mínimo aceptable para
cada criterio.

Furps Cuenta con 5 características de Plantea 2 categorías de

calidad del software: (1)
Propuesto por
Funcionalidad, (2) Facilidad de
Robert Grady y
uso, (3) Confiabilidad, (4)
Heweltt Packard
Performance y (5) Facilidad de
Co (HP).
soporte.
El modelo FURPS incluye,
además de los factores de
calidad y los atributos,
restricciones de diseño y 2. requerimientos no funcionales
requerimientos de
implementación, físicos y de
interfaz. Una limitación de este
modelo de calidad es que no
requerimientos, las cuales son:
1. requerimientos funcionales (F):
especifican funciones que el
sistema debe ser capaz de
realizar, sin tomar restricciones
físicas a consideración, y se
definen a través de las entradas
y salidas esperadas.
(URPS): Usability (Facilidad
de uso), Reliability
(Confiabilidad), Performance y
Supportability (Facilidad de
 tiene en cuenta la portabilidad
de los productos software que
se estén considerando, factor
digno de consideración en
función de las exigencias
actuales que recaen sobre el
proceso de desarrollo del
software.
Boehm Éste define la calidad de
software en términos de
Barry Boehm en
atributos cualitativos y los
1978
mide usando métricas.
Consiste en un modelo de
descomposición de
características de calidad del
software en 3 niveles (usos
principales, componentes
intermedios y componentes
primitivos) previos a la
aplicación de métricas. Este
modelo plantea factores de
calidad formados por criterios
de calidad y métricas
respectivas
soporte). describen atributos
del sistema o atributos del
ambiente del sistema.
El modelo de Boehm tiene como
finalidad que a través de la calidad
del software, el software: (1)
realice lo que desea el usuario, (2)
utilice recursos informáticos de
manera correcta y eficiente, (3) sea
fácil de utilizar y aprender; y (4)
sea bien diseñado, codificado,
probado y mantenido. Este modelo
es similar al de McCall ya que
presenta una jerarquía de
características, está basado en una
amplio rango de características e
incorpora 19 criterios que incluyen
características de performance del
hardware.
 REFERENCIAS

Microsoft. Información general de CMMI. 2008. Recuperado de:

https://msdn.microsoft.com/es-co/library/ee461556.aspx

Fillottrani, Pablo. Calidad en el desarrollo de software. Modelos de calidad de software.

Universidad Nacional del Sur. 2007. recuperado de:

http://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase6.pdf

Bolaños, Liliam; Navia, Manuel. Exploración de modelos y estándares de calidad para el

producto software. Universidad del Cauca. 2010. Recuperado de:

http://revistas.uis.edu.co/index.php/revistauisingenierias/article/viewFile/1055/1434

Scalone, Fernanda. Estudio comparativo de los modelos y estándares de calidad del

software. Universidad Tecnológica Nacional. Buenos Aires, Argentina. 2006. Recuperado de:

http://laboratorios.fi.uba.ar/lsi/scalone-tesis-maestria-ingenieria-en-calidad.pdf