UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERA DE SISTEMAS E

INFORMTICA

TRABAJO DE INVESTIGACIN
CALIDAD DE SERVICIO DE SOFTWARE
GRUPO/CICLO: GRUPO 1/ CICLO 1
CURSO:
PROFESOR:

TICA DE LA PROFESIN
FERNANDO CERN VALENCIA

INTEGRANTES:

Bejar Mallma Joel Antonio

Caillahua Castillo Mara Katherine
Caldern Saldaa Hilton Eduardo
Coaguila Limache Omar Andrs

LIMA, 22 de Abril del 2015

1

CONTENIDO
INTRODUCCIN
DEFINICIN

MODELOS PARA OBTENER CALIDAD DE SOFTWARE

5
CMMI

ISO 7

ISO 9000

ISO 9126

ISO 14000

12

PROCESOS

13

CMO OBTENER UN SOFTWARE DE CALIDAD?

13

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

PLAN SQA

13

ESTNDARES

14

13

CONTROLAR LA CALIDAD DEL SOFTWARE 15

PRUEBAS DE SOFTWARE

15

FACTORES
PARA CONTROLAR LA CALIDAD DEL
SOFTWARE
17
CERTIFICACIN Y ACREDITACIN

CASOS EMBLEMTICOS
CONCLUSIONES

22

BIBLIOGRAFA

23

18

19

INTRODUCCIN

A medida que la Tecnologa de la Informacin va desarrollndose, los

problemas van siendo ms complejos, esto obliga a buscar nuevas
soluciones, nuevos caminos o nuevos paradigmas que solucionen los
problemas. La solucin generalmente, incluye un software, por la gran
cantidad de informacin y la complejidad del problema. Pero, el desarrollo
del Software se ha convertido en una tarea muy compleja que ha
sobrepasado en gran medida la habilidad para el mantenimiento de las
empresas que se dedican al desarrollo de software. Hoy en da, las
empresas cubanas y al igual que las del mundo, buscan una alternativa para
mejorar la produccin de software, garantizar la calidad y la satisfaccin del
usuario. El aumento de la cultura hacia la excelencia y la administracin del
desarrollo, darn como resultado la mejor produccin y empleo de los
recursos para la fabricacin.

Los requisitos del software son la base de las medidas de calidad. La

falta de concordancia con los requisitos es una falta de calidad.

Los estndares o metodologas definen un conjunto de criterios de

desarrollo que guan la forma en que se aplica la ingeniera del
software. Si no se sigue ninguna metodologa siempre habr falta de
calidad.

1.- DEFINICIN
QUE ES LA CALIDAD DEL SOFTWARE?
La calidad del software es aquel proceso en donde se verifica que el
software o aplicacin cumpla con los requerimientos o necesidades del
cliente, integrando la velocidad de respuesta de la aplicacin, el sistema de
seguridad
y
confiabilidad.
Tambin se puede definir como la coordinacin, integridad y la aplicacin de
los estndares que tiene que ver con la correcta funcionabilidad y desarrollo
de
una
aplicacin.
No hay que olvidar la evolucin de las propuestas de calidad que son:
-Factores
-factores

de
de

revisin:

flexibilidad,

mantenibilidad

transicin:

portabilidad,

reusabilidad

interoperabilidad

contestacin.

-factores de operacin: eficiencia, integridad, usabilidad, fiabilidad y

correccin.
Tambin se debe tener en cuenta que en el mantenimiento de hardware es
muy diferente al de software, porque el hardware se puede reemplazar la
pieza, mientras el software requiere de ingeniera, el software no se
deteriora con el tiempo pues su curva de fallos es muy diferente a la del
hardware
La calidad del software es el conjunto de cualidades que lo caracterizan y
que determinan su utilidad y existencia. La calidad es sinnimo de
eficiencia,
flexibilidad,
correccin,
confiabilidad,
mantenibilidad,
portabilidad, usabilidad, seguridad e integridad.
Existen 3 puntos importantes de la definicin de calidad de software:
1- los requerimientos del software son los fundamentos desde los que se
mide
la
calidad
2- los estndares especficos definen un conjunto de criterios de desarrollo
que guan la forma de aplicacin de la ingeniera de software
3- existen requerimientos implcitos que no se mencionan
La calidad del software es medible y vara de un sistema a otro o de un
programa a otro. Un software elaborado para el control de naves espaciales
debe ser confiable al nivel de "cero fallas"; un software hecho para
ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que
un producto de software para ser explotado durante un largo perodo (10
aos o ms), necesita ser confiable, mantenible y flexible para disminuir los
costos de mantenimiento y perfeccionamiento durante el tiempo de
explotacin.
4

La calidad del software puede medirse despus de elaborado el producto.

Pero esto puede resultar muy costoso si se detectan problemas derivados de
imperfecciones en el diseo, por lo que es imprescindible tener en cuenta
tanto la obtencin de la calidad como su control durante todas las etapas
del ciclo de vida del software.
Calidad en los productos Software.
Hasta el momento puede dilucidarse algunos de los atributos que hacen
comparable un producto de otro. Quizs podemos considerar formas,
colores, tamaos, manejabilidad, entre otros muchos. Estas caractersticas
pueden ser fsicamente mensurables y, por ello, fcilmente comparables.
As como existen medidas para atributos fsicos, para el software tambin
existen medidas que pueden hacerlo comparables, tales como puntos de
Calidad de los Productos Software
Estas medidas aportan a la medida de variacin entre productos software,
las cuales podran ser analizadas con detenimiento en otro trabajo.
La principal meta de un equipo desarrollador de software debera ser
siempre producir software catalogado como de alta calidad.
De qu depende la calidad del software?
La calidad de software va a depender en su totalidad de la concordancia
entre los requisitos planteados respecto a los obtenidos. Ambos conceptos
resaltan la necesidad de que un software de calidad debe satisfacer los
requisitos dados por el usuario. La obtencin de un software con calidad
implica la utilizacin de metodologas o procedimientos estndares para el
anlisis, diseo, programacin y prueba del software que permitan
uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad,
tanto para la labor de desarrollo como para el control de la calidad del
software.
No se puede medir la calidad del software de forma correcta debido a
su naturaleza, la certificacin se da a los procesos, la correcta consecucin
de los mismos garantizara un buen software. No se puede medir al software
como tal, sino los atributos que la conforman, tales mtodos de medida
deben ser exactos. El usuario final mide la calidad del software segn lo que
tenga o no, es en ese sentido de que la calidad del software depende de
quien la juzgue. El hecho de que una empresa tenga certificacin en calidad
de software no garantiza que su software sea de calidad.
La calidad del software puede medirse despus de elaborado el producto.
Pero esto puede resultar muy costoso si se detectan problemas derivados de
imperfecciones en el diseo, por lo que es imprescindible tener en cuenta
tanto la obtencin de la calidad como su control durante todas las etapas
del ciclo de vida del software.

Concordancia con los requisitos 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

2. -MODELOS PARA OBTENER CALIDAD DE

SOFTWARE
La calidad del software es una preocupacin a la que se dedican muchos
esfuerzos. Sin embargo el software casi nunca es perfecto, todo proyecto
tiene como objetivo producir software de la mejor calidad posible, que
cumpla con las expectativas de los usuarios, para ello se ha dado normas
modelos, parmetros que pueden seguir las empresas. Ahora cabe sealar
que estos modelos son sistemas
que ayudan a una organizacin a
implementar un sistema de aseguramiento de la calidad, ahora hay una
gran cantidad de modelos implantados alrededor del mundo pero en este
trabajo sealaremos los ms importantes o los ms usados por todo el
mundo los cuales son los siguientes

CMMI
ISO 9000
ISO 9126
ISO 14000

2.1 CMMI
Traducido como modelo de madurez de capacidad una de las caractersticas
de este modelo es que es Ajustable a cualquier tipo de organizacin en este
caso, una organizacin de software, este modelo entrega una gua donde se
encuentran una serie de actividades los cuales van a mejorar los procesos
y es utilizada en el mtodo de evaluacin. Ahora el modelo cuenta con dos
formas una mejorando un proceso especifico o conjunto de ellos usando la
representacin continua ya la otra es la mejora de la organizacin completa
segn los procesos definidos
y ocupados usando la representacin
escalonada o tambin llamada por etapas , en el siguiente grafico podemos
ver ambas formas

Representacin Continua

Representacin
Escalonada

Nivel de capacidad

Nivel de Madurez

Nivel 0

Incompleto

Nivel 1

Realizado

Inicial

Nivel 2

Manejado

Manejado

Nivel 3

Definido

Definido

Nivel 4

Manejado cuantitativamente Manejado cuantitativamente

Nivel 5

Optimizado

Optimizado

A continuacin se explicara cada una de estas formas de manera detallada

Representacin continua: La representacin continua se focaliza en la
mejora de un proceso o un conjunto de ellos relacionados estrechamente a
un rea de proceso en que una organizacin desea mejorar, por lo tanto una
organizacin pude ser certificada para un rea de proceso en cierto nivel de
capacidad. Existen seis niveles de capacidad por donde transitan los
procesos asociados a un rea de proceso y cada nivel es construido sobre el
nivel anterior, es decir para que un proceso alcance un nivel de capacidad
necesariamente debe haber alcanzado el nivel anterior.
Representacin escalonada: En la representacin escalonada o por
etapas se ofrece un mtodo estructurado y sistemtico de mejoramiento de
procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la
organizacin se asegura de contar con una infraestructura robusta en
trminos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto es
una organizacin la que puede ser certificada bajo un nivel, en este caso
llamado nivel de madurez. Segn esta representacin un nivel de madurez
est compuesto por reas de procesos (ver tabla 2) en donde los objetivos
asociados a ese nivel deben ser cumplidos para que la organizacin pueda
certificarse en aquel nivel de madurez. Se implementan cinco niveles de
madurez por los que se van evaluando las entidades segn las condiciones
para el desarrollo de sistemas de aplicaciones, en cada nivel se evaluar el
nivel de madurez alcanzado.
El modelo CMMI constituye un modelo de validacin de calidad ya que al
aplicarse a las reas de proceso estas transitan de un nivel inferior a un
nivel ms alto de calidad lo que hace posible agregar una valor de calidad
superior a los productos software que son elaborados bajo estos estndares.
Desde el punto de vista del desarrollo de software existe un mejoramiento
por etapas o ciclos de desarrollo alcanzndose un nivel de madurez superior
aplicando mtricas establecidas en el modelo CMMI el cual est orientado
fundamentalmente a la mejora continua del proceso influyendo
positivamente estas mejoras en la calidad, no desde el punto de vista de los
desarrolladores, si no, que al mejorar continuamente el proceso evaluando
cada una de las etapas por las cuales transita el producto (software) existen
en ellas un aumento de la calidad ya que la misma es verificada durante
estas.
Utilizando CMMI en el rea de desarrollo de software se valida la gestin de
proyectos, se logra durante la fase inicial de desarrollo un despliegue de los
requerimientos donde se asegura la calidad de los procesos y productos
desde edades tempranas del desarrollo, al utilizar este estndar se prev
una medicin y anlisis constante de la calidad del software en desarrollo,
as como, el monitoreo y control de los proyectos en ejecucin por grupos o
direcciones y a nivel gerencial.
Las acciones que provee la aplicacin de este estndar para validacin son
especficas para cada una de las reas de procesos para lograr alta calidad
y prever mejoras continuas en el producto en desarrollo teniendo presente
que la validacin de requerimientos se realiza tempranamente con los
usuarios para obtener certeza de que los requerimientos permitirn guiar el
desarrollo que resulte en una validacin final exitosa demostrando que el
producto (software), componentes del producto (componentes del software)
y los artefactos utilizados se corresponden con las especificaciones inciales
para su uso. Las organizaciones con un grado de madurez aceptable
realizara la validacin de requerimientos de una manera ms sofisticada
aplicando diversas tcnicas y aplicarn la base de la validacin para incluir
necesidades y expectativas de otras partes interesadas (usuarios del futuro
7

software, terceros y proveedores de software al equipo de desarrollo u

organizacin).
Tambin existen en el modelo CMMI acciones encaminadas a la verificacin
que demuestran que el producto (software), componentes del producto
(componentes del software) y los artefactos utilizados cumplen con los
requerimientos establecidos. Durante la realizacin de pruebas sean estas
de Caja Negra o Caja Blanca se propicia un escenario ideal para la
verificacin de los requerimientos desde que el producto o software
comienza a responder a los requisitos funcionales que lo proveen de
funcionalidad; adems utilizando este modelo se verifica bajo qu
condiciones el producto es capaz de responder exitosamente a las
solicitudes del usuario final.
2.2 ISO
Las normas ISO traducido vendra hacer Organizacin Internacional para los
Estndares han desarrollado una serie de norma y modelos para la
evaluacin de la calidad de productos aplicables a productos generales,
adaptndose a veces difcilmente al rea de produccin de software, en las
que se exponen los conceptos de calidad para aplicarlos mejor al producto
terminado el software que al proceso de desarrollo. Estas normas hacen
posible que se sigan patrones de calidad generalmente aceptados con los
que se logran mtricas para determinar las cualidades de un producto,
teniendo en cuenta que en la prctica existen dos tipos de calidad:
Calidad externa, que corresponde a la satisfaccin de los clientes. El logro
de la calidad externa requiere proporcionar productos o servicios que
satisfagan las expectativas del cliente para establecer lealtad con el cliente
y de ese modo mejorar la participacin en el mercado. Los beneficios de la
calidad externa son los clientes y los socios externos de una compaa. Por
lo tanto, este tipo de procedimientos requiere escuchar a los clientes y
tambin debe permitir que se consideren las necesidades implcitas que los
clientes no expresan.
Calidad interna, que corresponde al mejoramiento y validacin de
las operaciones internas de una compaa. El propsito de la calidad interna
es implementar los medios para permitir la mejor descripcin posible de la
organizacin, validar y detectar funcionamientos incorrectos. Los beneficios
de validar y verificar la calidad interna son de la gestin y los empleados de
la compaa. La validacin y verificacin de la calidad interna pasa
generalmente por una etapa participativa en la que se identifican y
formalizan los procesos internos.

2.2.1 ISO 9000

Pone a disposicin de un certificador los procesos internos del a empresa, de
forma que este debe indicar si se cumple con la normativa al 100%, si en
caso es positivo, se audita el sistemas ahora cada cierto se tiene que
renovar, las caractersticas son que este modelo es apropiado por casi 140
pases, tambin esta ISO sugiere un plan de atencin de calidad dejando a
los propietarios adaptarse o modificar el plan .cuenta con tres etapas:
8

Control de calidad
Gestin de calidad
Calidad total

GRAFICA DE LAS ETAPAS Y COMO SE RELACIONAN ENTRE S

Control de calidad
Son los hitos de control, que verifican la existencia del producto, ahora
quien hace el control de calidad lo hacen, los analistas y desarrolladores del
software, ahora el control de calidad es un producto tcnico.
Contrato de desarrollo tambin es parte del control de calidad y vendra
hacer el documento legal que hace parte integral del anlisis de requisitos
Anlisis de requisitos
Documento diseo
Generacin de pruebas

Gestin de calidad
Proceso por el cual se garantiza que las entregas lleguen a punto y fecha
determinados, este es un proceso administrativo no tcnico.
Calidad total
Es un proceso por el cual se determinan la satisfaccin total del cliente en
trminos de
Requisitos del software, anlisis y diseo, producto documentacin, cdigo
y pruebas.

2.2.2 ISO 9126

Es un estndar internacional para la evaluacin de la calidad de software.
Est reemplazado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los
mismos conceptos.

El estndar est dividido en cuatro partes las cuales dirigen, realidad,

mtricas externas, mtricas internas y calidad en las mtricas de uso y
expendido,

clasifica

la

calidad

del

software

en

caractersticas

subcaractersticas, los cuales son:

Funcionabilidad - Un conjunto de atributos que se relacionan con la
existencia de un conjunto de funciones y sus propiedades especficas. Las
funciones son aquellas que satisfacen las necesidades implcitas o
explcitas.
Adecuacin - Atributos del software relacionados con la

presencia y aptitud de un conjunto de funciones para tareas

especificadas.
Exactitud

Atributos

del

software

relacionados

con

la

disposicin de resultados o efectos correctos o acordados.

Interoperabilidad - Atributos del software que se relacionan con

su habilidad para la interaccin con sistemas especificados.

Seguridad - Atributos del software

relacionados con su

habilidad para prevenir acceso no autorizado ya sea accidental o

deliberado, a programas y datos.
Cumplimiento funcional.

Fiabilidad - Un conjunto de atributos relacionados con la capacidad del

software

de

mantener

su

nivel

de

prestacin

bajo

condiciones

establecidas durante un perodo establecido.

Madurez - Atributos del software que se relacionan con la

frecuencia de falla por fallas en el software.

Recuperabilidad - Atributos del software que se relacionan con

la capacidad para restablecer su nivel de desempeo y recuperar los
datos directamente afectos en caso de falla y en el tiempo y esfuerzo
relacionado para ello.

Tolerancia a fallos - Atributos del software que se relacionan

con su habilidad para mantener un nivel especificado de desempeo
en casos de fallas de software o de una infraccin a su interfaz
especificada.
10

Cumplimiento de Fiabilidad - La capacidad del producto

software para adherirse a normas, convenciones o legislacin
relacionadas con la fiabilidad.

Usabilidad - Un conjunto de atributos relacionados con el esfuerzo

necesario para su uso, y en la valoracin individual de tal uso, por un
establecido o implicado conjunto de usuarios.

Aprendizaje- Atributos del software que se relacionan al

esfuerzo de los usuarios para reconocer el concepto lgico y sus
aplicaciones.

Comprensin - Atributos del software que se relacionan al

esfuerzo de los usuarios para reconocer el concepto lgico y sus
aplicaciones.

Operatividad - Atributos del software que se relacionan con el

esfuerzo de los usuarios para la operacin y control del software.

Atractividad

Eficiencia - Conjunto de atributos relacionados con la relacin entre el

nivel de desempeo del software y la cantidad de recursos necesitados
bajo condiciones establecidas.

Comportamiento en el tiempo - Atributos del software que se

relacionan con los tiempos de respuesta y procesamiento y en las
tasas de rendimientos en desempear su funcin.

Comportamiento de recursos - Usar las cantidades y tipos de

recursos adecuados cuando el software lleva a cabo su funcin bajo
condiciones determinadas.

Mantenibilidad - Conjunto de atributos relacionados con la facilidad de

extender, modificar o corregir errores en un sistema software.

Estabilidad - Atributos del software relacionados con el riesgo

de efectos inesperados por modificaciones.

11

Facilidad de anlisis - Atributos del software relacionados con el

esfuerzo necesario para el diagnstico de deficiencias o causas de
fallos, o identificaciones de partes a modificar.

Facilidad de cambio - Atributos del software relacionados con el

esfuerzo necesario para la modificacin, correccin de falla, o cambio
de ambiente.

Facilidad de pruebas - Atributos del software relacionados con

el esfuerzo necesario para validar el software modificado.

Portabilidad- Conjunto de atributos relacionados con la capacidad de

un sistema software para ser transferido desde una plataforma a otra.

Capacidad de instalacin - Atributos del software relacionados

con el esfuerzo necesario para instalar el software en un ambiente
especificado.

Capacidad

de

reemplazamiento

Atributos

del

software

relacionados con la oportunidad y esfuerzo de usar el software en

lugar de otro software especificado en el ambiente de dicho software
especificado.

Adaptabilidad - Atributos del software relacionados con la

oportunidad para su adaptacin a diferentes ambientes especificados
sin aplicar otras acciones o medios que los proporcionados para este
propsito por el software considerado.

Co-Existencia - Coexistir con otro software independiente, en

un entorno comn, compartiendo recursos comunes.

La subcaracterstica Conformidad no est listada arriba ya que se aplica a

todas las caractersticas. Ejemplos son conformidad a la legislacin
referente a usabilidad y fiabilidad.
Cada subcaracterstica (como adaptabilidad) est dividida en atributos. Un
atributo es una entidad la cual puede ser verificada o medida en el producto
software. Los atributos no estn definidos en el estndar, ya que varan
entre diferentes productos software.
Un producto software est definido en un sentido amplio como: los
ejecutables, cdigo fuente, descripciones de arquitectura, y as. Como
resultado, la nocin de usuario se ampla tanto a operadores como a
12

programadores, los cuales son usuarios de componentes como son

bibliotecas software.
El estndar provee un entorno para que las organizaciones definan un
modelo de calidad para el producto software. Haciendo esto as, sin
embargo, se lleva a cada organizacin la tarea de especificar precisamente
su propio modelo. Esto podra ser hecho, por ejemplo, especificando los
objetivos para las mtricas de calidad las cuales evalan el grado de
presencia de los atributos de calidad.
Mtricas internas son aquellas que no dependen de la ejecucin del
software (medidas estticas).
Mtricas externas son aquellas aplicables al software en ejecucin.
La calidad en las mtricas de uso estn slo disponibles cuando el producto
final es usado en condiciones reales.
Idealmente, la calidad interna no necesariamente implica calidad externa y
esta a su vez la calidad en el uso.
Este estndar proviene desde el modelo establecido en 1977 por McCall y
sus colegas, los cuales propusieron un modelo para especificar la calidad del
software. El modelo de calidad McCall est organizado sobre tres tipos de
Caractersticas de Calidad:
Factores (especificar): Describen la visin externa del software, como

es visto por los usuarios.

Criterios (construir): Describen la visin interna del software, como es

visto por el desarrollador.

Mtricas (controlar): Se definen y se usan para proveer una escala y

mtodo para la medida.

ISO

9126 distingue

entre

fallo y no conformidad.

Un

fallo

es el

incumplimiento de los requisitos previos, mientras que la no conformidad es

el incumplimiento de los requisitos especificados. Una distincin similar es la
que se establece entre validacin y verificacin.

2.3 ISO 14000

La ISO 14000 es una serie de normas internacionales para la gestin
medioambiental. Es la primera serie de normas que permite a las
organizaciones de todo el mundo realizar esfuerzos medioambientales y
medir

la

actuacin

de

acuerdo

con

unos

criterios

aceptados

internacionalmente. La ISO 14001 es la primera de la serie 14000 y

13

especifica

los

requisitos

que

debe

cumplir

un

sistema

de

gestin

medioambiental. La ISO 14001 es una norma voluntaria y fue desarrollada

por la International Organization for Standardization (ISO) en Ginebra. La
ISO 14001 est dirigida a ser aplicable a organizaciones de todo tipo y
dimensiones y albergar diversas condiciones geogrficas, culturales y
sociales. El objetivo general tanto de la ISO 14001 como de las dems
normas de la serie 14000 es apoyar a la proteccin medioambiental y la
prevencin

de

la

contaminacin

en

armona

con

las

necesidades

socioeconmicas. La ISO 14001 se aplica a cualquier organizacin que

desee mejorar y demostrar a otros su actuacin medioambiental mediante
un sistema de gestin medioambiental certificado.
La ISO 14001 no prescribe requisitos de actuacin medioambiental,
salvo el requisito de compromiso de continua mejora y la obligacin de
cumplir la legislacin y regulacin relevantes. La norma no declara la
cantidad mxima permisible de emisin de xido nitroso de gases de
combustin, ni el nivel mximo de contenido bacteriolgico en el efluente
de aguas residuales. La ISO especifica los requisitos del propio sistema de
gestin, que, si se mantienen adecuadamente, mejorarn la actuacin
medioambiental reduciendo los impactos, tales como emisiones de xido
nitroso y efluentes bacteriolgicos. Todo ello se da para la proteccin del
medio ambiente.

3.- PROCESOS
3.1

COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtencin de un software de calidad implica la utilizacin de

metodologas o procedimientos estndares para el anlisis, diseo,
programacin y prueba del software que permitan lograr una mayor
confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la

14

productividad, tanto para la labor de desarrollo como para el control de la

calidad del software.
La poltica establecida debe estar sustentada sobre tres principios bsicos:
tecnolgico, administrativo y ergonmico.
El principio tecnolgico define las tcnicas a utilizar en el proceso de
desarrollo del software.
El principio administrativo contempla las funciones de planificacin y control
del desarrollo del software, as como la organizacin del ambiente o centro
de ingeniera de software.
El principio ergonmico define la interfaz entre el usuario y el ambiente
automatizado.
La adopcin de una buena poltica contribuye en gran medida a lograr la
calidad del software, pero no la asegura. Para el aseguramiento de la
calidad es necesario su control o evaluacin.

3.1.1 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

(Standard for Software Quality Assurance)
La planificacin de la calidad es el proceso en el cual se desarrolla un plan
de calidad para un proyecto determinado. El plan de calidad que define la
calidad del software deseado y describe cmo valorarlo. Por lo tanto, define
lo que es software de alta calidad.
El plan de calidad selecciona los estndares organizacionales apropiados
para un producto y un proceso de desarrollo particular.
El estndar IEEE 730 es una recomendacin para elaborar un Plan de
Aseguramiento de la Calidad del Software (SQAP) para los proyectos de
desarrollo de software. Proporciona los requisitos mnimos aceptables para
la preparacin y el contenido de los planes de aseguramiento de calidad.
Fue escrito para ser utilizado en las fases de desarrollo y mantenimiento del
software. El plan SQA sirve como gua de las actividades de SQA en el
proyecto.
Las actividades principales del SQA incluyen la gestin, documentacin,
mediciones, revisiones, testing, informes de problemas y las acciones
correctivas, control de medios de comunicacin, control de proveedores,
gestin de registros, capacitacin y gestin de riesgos.

3.1.1.1

PLAN SQA

Un plan SQA, proporciona un mapa para institucionalizar la garanta

de la calidad de SW en una empresa.
Este plan sirve como modelo para actividades de SQA instituidas para
cada proyecto de SW que desarrolle la empresa.
Segn IEEE un plan de calidad SQA debe contemplar:
Un propsito - Por qu se hace?
Un alcance - Qu reas cubre?
Documentos referentes (requeridos).
Estndares a usar.
Una gestin del plan. (Doc. Del proyecto, modelos, Doc.
Tcnicos, Doc. De Usuarios).
Estndares, prcticas y convenciones, utilizados en procesos de
SW.
Pruebas (plan de pruebas de sw, problemas y acciones
tomadas).
15

Herramientas y mtodos que soportan tareas y actividades SQA.

3.1.1.2 ESTNDARES
Son los cimientos de cualquier sistema de calidad de software, pues
proveen la base para la evaluacin y medicin de las actividades y de
los productos de trabajo durante todo el ciclo de vida del software.
Su aplicacin otorga uniformidad, consistencia, rigurosidad y fortaleza
a los mtodos y a las actividades del desarrollo de software.
Las reas contenidas en los estndares varan de una organizacin a
otra segn sus necesidades. Lo importante es no estandarizar todo.
Por lo tanto la estandarizacin puede ser aplicada a cualquier o a
todas las reas de desarrollo de software y mantencin el cual
debera cubrir:
Ciclo de vida del software
Documentacin
Cdigo fuente
Criterios para denominar los tems de configuracin
Procedimientos y protocolos

Objetivos del aseguramiento de calidad de software

1.- Satisfaccin del cliente: la satisfaccin del cliente significa relaciones a
largo plazo (opinin positiva del cliente)
2.- Reducir costes del desarrollo: se lleva a cabo este plan para prevenir
defectos e ineficacias del software. La idea es que siguiendo un plan de SQA
el plan termine a tiempo y dentro del presupuesto establecido. Se reduce
inversin en pruebas.
3.- Reducir costes en el mantenimiento: siguiendo un plan de
aseguramiento de la calidad del software se generan aplicaciones ms
seguras y estables. Por tanto, nos ahorramos el invertir en tareas para
solucionar fallos, revisiones con el cliente.
4.- Reducir tiempos de desarrollo: se ahorra tiempo en la fase de testing.
5.- Hace que la gestin de cambio sea ms fcil de realizar. (Permeabilidad
al cambio).
6.- Asegura los requisitos funcionales que ha solicitado el cliente.
7.- Asegura que se estn siguiendo la metodologa de desarrollo adoptada
por la organizacin.
8.- Los desarrollos son ms predecibles al mantener informacin que pueda
ayudar a las estimaciones futuras.

Como garantizar que el Plan de Aseguramiento de la Calidad

Software se est cumpliendo
Se realizan auditoras:
Auditoras internas: llevadas a cabo por la misma empresa
Auditoras externas: llevadas a cabo por empresas ajenas. Normalmente
estas empresas expiden certificados de calidad una vez ha terminado la
auditora.

Quin lleva a cabo las actividades de Aseguramiento de la

Calidad Software?
16

Directivos (promueven y motivan)

Ingenieros software (mximo responsable).
Grupo SQA: preparan el plan de aseguramiento de la calidad, revisan el
software, lo verifican, generan los informes y otra documentacin.

3.1.2 CONTROLAR LA CALIDAD DEL SOFTWARE

Para controlar la calidad del software es necesario, ante todo, definir los
parmetros, indicadores o criterios de medicin, ya que, no se puede
controlar lo que no se puede medir.
Las cualidades para medir la calidad del software son definidas por
innumerables autores, los cuales las denominan y agrupan de formas
diferentes. Por ejemplo, John Wiley define mtricas de calidad y criterios,
donde cada mtrica se obtiene a partir de combinaciones de los diferentes
criterios. La Metodologa para la evaluacin de la calidad de los medios de
programas de la CIC, de Rusia, define indicadores de calidad estructurados
en cuatro niveles jerrquicos: factor, criterio, mtrica, elemento de
evaluacin, donde cada nivel inferior contiene los indicadores que
conforman el nivel precedente. Otros autores identifican la calidad con el
nivel de complejidad del software y definen dos categoras de mtricas: de
complejidad de programa o cdigo, y de complejidad de sistema o
estructura.
Todos los autores coinciden en que el software posee determinados ndices
medibles que son las bases para la calidad, el control y el perfeccionamiento
de la productividad.
Una vez seleccionados los ndices de calidad, se debe establecer el proceso
de control, que requiere los siguientes pasos:
Definir el software que va a ser controlado: clasificacin por tipo,
esfera de aplicacin, complejidad, etc., de acuerdo con los estndares
establecidos para el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control.
Para cada clase de software es necesario definir los indicadores y sus
magnitudes.
Crear o determinar los mtodos de valoracin de los indicadores:
mtodos manuales como cuestionarios o encuestas estndares para
la medicin de criterios periciales y herramientas automatizadas para
medir los criterios de clculo.
Definir las regulaciones organizativas para realizar el control: quines
participan en el control de la calidad, cundo se realiza, qu
documentos deben ser revisados y elaborados, etc.

3.1.2.1

PRUEBAS DE SOFTWARE

Las pruebas de software son las investigaciones empricas y tcnicas

cuyo fin es proporcionar informacin objetiva e independiente sobre
la calidad del producto. Esta actividad forma parte del proceso de
control de calidad global. Las pruebas son bsicamente un conjunto
de actividades dentro del desarrollo de software y dependiendo del
tipo de pruebas, estas actividades podrn ser implementadas en
cualquier momento del proceso de desarrollo.
17

Para conseguirlo, en realidad no existen las "mejores prcticas" como

tal, debido a que cada prctica puede ser ideal para una situacin
pero completamente intil o incluso perjudicial en otra, por lo que las
actividades de testeo, tcnicas, documentacin, enfoques y dems
elementos que condicionarn las pruebas a realizar deben ser
seleccionados y utilizados de la manera ms eficiente segn contexto
del proyecto.

Qu tipos de prueba de programa deben ser considerados?

Caja negra. No est basada en el conocimiento del cdigo o diseo
interno, determina la funcionalidad del sistema.
Caja blanca. Est basada en la lgica interna de la aplicacin y el
cdigo. Hace una cobertura de declaraciones del cdigo, ramas,
caminos y condiciones.
Unidad de testeo o prueba. Es la escala ms pequea de la prueba,
est basada en la funcionalidad de los mdulos del programa, como
funciones, procedimientos, mdulos de clase, etc. En ciertos sistemas
tambin se verifican o se prueban los drivers y el diseo de la
arquitectura.
Prueba de integracin. Se basa en las pruebas de conexiones y
comunicaciones entre diferentes mdulos. Es esencial en sistemas de
cliente, servidor o red.
Prueba funcional. La caja negra hace la prueba funcional de los
requerimientos de la aplicacin y generalmente es realizada por el
programador, en cambio, la prueba funcional es realizada por los
testers.
Prueba de sistema. Es una prueba de caja negra incluyendo todos
los componentes del sistema desde el hardware a la documentacin.
Prueba de sanidad. Determina si la nueva versin de un software
est bien realizada y si necesita un nuevo esfuerzo en la prueba de
software. Por ejemplo la nueva versin de un programa cumple con
casi todos los requisitos pero destruye la base de datos al leerla, por
lo tanto se dice que este software no est en una condicin sana.
Prueba de regresin. Es una nueva revisin en las pruebas del
programa luego de que este haya sufrido algn cambio o por apuros
de tiempo o la modificacin fue en el ambiente en que se
desenvuelve. Actualmente aparecieron herramientas automatizadas
que hacen que este tipo de pruebas no lleve demasiado tiempo.

18

Prueba de aceptacin. Es la prueba final basada en las

especificaciones del usuario o basada en el uso del programa por el
usuario final luego de un periodo de tiempo.
Prueba de carga. Est basada en las aplicaciones bajo cargas
pesadas, generalmente usadas en sitios web y en servidores con gran
cantidad de datos donde se determina en cuales puntos existen
degradaciones del sistema.
Prueba de perfomance. Es una de las pruebas finales y sirve para
definir los requerimientos y la calidad del software, en base a las
pruebas de carga y estrs. Incluye entrevistas con el usuario y
programador.
Prueba de instalacin y desinstalacin. Determina la eficiencia de los
procesos que instalan y desinstalan las aplicaciones del programa.
Prueba de recuperacin. Es la prueba que evala que tan bien se
recupera el sistema luego de bloqueos, fallas del hardware u otros
problemas catastrficos.
Prueba de seguridad. Evala que tan bien el sistema se protege
contra accesos, internos o externos, no autorizados, esta prueba
requiere sofisticadas tcnicas y herramientas.
Prueba de compatibilidad. Evala el desempeo del software en
diferentes hardwares, sistemas operativos, redes, etc.
Prueba de exploracin. Es una prueba informal del software que no
est basada en ningn plan o caja de prueba y a menudo los testers
aprenden de programa al explorar todas las aplicaciones posibles.
Prueba de anuncio. Es similar a la prueba de exploracin pero los
testers deben tener suficiente nocin sobre el funcionamiento del
programa antes de comenzar esta prueba. Incluye reunin con
analistas y programadores.
Prueba de usuario. Determina si el usuario se desenvuelve
satisfactoriamente con el programa.
Prueba de comparacin. En esta prueba se comparan los pro y los
contra del programa con los programas creados con la competencia.

3.1.2.2
FACTORES
DEL SOFTWARE

PARA CONTROLAR LA CALIDAD

Segn Juran (1992), la calidad, para poder ser entendida de una

mejor manera y posteriormente ser medida con eficacia, debe ser
expresada por medio de otros trminos que tengan ms sentido para
el usuario. En el caso del software. Estos factores son el medio por el
cual se traduce el trmino calidad al lenguaje de las personas que
manejan
la
tecnologa.

19

Los factores de calidad que afectan a la calidad del software se

dividen en dos grandes grupos:
Los que miden directamente (defectos descubiertos en las pruebas).
Los que se miden directamente (facilidad de uso o de
mantenimiento).
En cada caso debe presentarse una medicin. Se debe comparar el
software con algn conjunto de datos y obtener as algn indicio
sobre la calidad. McCall, Richards & Walters (1977), propusieron una
clasificacin de los factores que afectan directamente a la calidad del
software. En ella se concentran tres aspectos importantes de un
software:
Caractersticas operativas.
Capacidad para experimentar cambios.
Capacidad para adaptarse a nuevos entornos.
A continuacin se describen los factores que propone McCall, Richards
& Walters.
Correccin.
El grado en que el programa cumple con su especificacin y satisfacer
los objetivos que propuso el cliente.
Confiabilidad.
El grado en que se esperara que un programa desempea su funcin
con la precisin requerida.
Eficiencia.
La cantidad de cdigo y de recursos de cmputo necesarios para que
un programa realice su funcin.
Integridad.
El grado de control sobre el acceso al software o los datos por parte
de las personas no autorizadas.
Facilidad de uso.
El esfuerzo necesario para aprender, operar y preparar los datos de
entrada de un programa interpreta la salida.
Facilidad de mantenimiento.
El esfuerzo necesario para localizar y corregir un error en un
programa.
Flexibilidad.
El esfuerzo que demanda probar un programa con el fin de asegurar
que realiza su funcin.
Portabilidad.
El esfuerzo necesario para transferir el programa de un entorno de
hardware o software a otro.
Facilidad de reutilizacin.
El grado en que un programa o partes de l pueden reutilizarse en
otras aplicaciones (en relacin con el empaquetamiento y el alcance
de las funciones que realiza el programa).
Interoperabilidad.
El esfuerzo necesario para acoplar un sistema con otro.
Es difcil y en algunos casos imposibles, desarrollar medidas
directas 1de estos factores de la calidad. En realidad, muchas de las
mtricas que definen McCall et al. Slo se miden de forma subjetiva.
Ya que es comn que las mtricas adquieran la forma de una lista de
comprobacin que se emplea para asignar una graduacin a
20

atributos especficos del software. Vega et al. (2008), proponen un

modelo con mtricas distintas al propuesto por McCall y que ha sido
utilizado y comprobado en distintos proyectos de desarrollo de
software.

3.2 CERTIFICACIN Y ACREDITACIN

El mundo de la certificacin de la calidad del software, y por extensin el de
cualquier tipo de certificacin existente a la que puedan acogerse las
empresas que lo soliciten, se basa en la confianza que el cliente (cualquier
entidad solicitante) deposita en la empresa que lo certifica. Con este
planteamiento, basta ser una entidad suficientemente reconocida en la
prctica para poder emitir sellos de certificacin basados en cualquier tipo
de norma.
Cmo se obtiene una certificacin de Calidad de software?
En general, las empresas realizan estos pasos:
Identificar, en el mercado al que se orienta la empresa u
organizacin, cul es el Modelo o Norma de Calidad ms adecuado.
Evaluar la situacin actual de la empresa u organizacin y compararla
con las exigencias del Modelo o Norma elegida. En muchos casos esta
etapa es denominada Gap Anlisis (Deteccin de brecha existente).
A partir de este anlisis y una vez detectada la diferencia, se planifica un
proyecto de mejoras que busca corregir las debilidades en los procesos,
segn el Modelo o Norma elegido.
Este proceso de mejora debe finalizar con la evaluacin correspondiente.

AENOR (Asociacin Espaola de normalizacin y certificacin)

Certificado de medio ambiente: Los productos certificados debern
fabricarse cumpliendo unos criterios ecolgicos y el proceso de fabricacin
no afecta al medio ambiente.
Certificado de gestin ambiental: los productos deben cumplir con una
elaboracin siguiendo un sistema normalizado de gestin

4.- CASOS EMBLEMTICOS

1. MARINERO SIN RUMBO (1962)

21

Coste:
Desastre:

18,5
El

de
293

millones

de

dlares.

cohete Mariner 1, en una investigacin espacial

destinada a Venus, se desvi de su trayectoria
vuelo poco despus de su lanzamiento. El
control de la misin destruy el cohete pasados
segundos
desde
el
despegue.

Causa: Un
software una

programador codific incorrectamente en el

frmula manuscrita, saltndose un simple guin
sobre una expresin. Sin la funcin de
suavizado indicada por este smbolo, el software interpret como serias las
variaciones normales de velocidad y caus correcciones errneas en el
rumbo que hicieron que el cohete saliera de su trayectoria.

2. LA CIA LE DA GAS A LOS SOVITICOS (1982)

Coste: Millones de dlares, dao significativo a la economa sovitica.

Desastre: El software de control se volvi loco y produjo una presin
excesiva en la tubera de gas transsiberiana, provocando la mayor explosin
no nuclear, causada por el hombre, de la historia de la tierra.
Causa: los agentes de la CIA supuestamente introdujeron un error en el
sistema informtico canadiense adquirido por los soviticos para controlar
sus tuberas de gas. La compra era parte de un estratgico plan sovitico
para robar u obtener de forma encubierta tecnologa secreta de los Estados
Unidos.
Cuando la CIA descubri la compra, sabotearon el software de forma que
ste superara la inspeccin sovitica pero fallara una vez operativo.
22

3. EL PATRIOTA LE FALLA A LOS SOLDADOS (1991)

Coste:

28

soldados

muertos,

100

heridos.

Desastre: Durante la Guerra del Golfo, un sistema de misiles americanos

Patriot en Arabia Saudita fall en la intercepcin de un misil iraqu Scud. El
misil
destruy
una
barraca
de
la
armada
americana.
Causa: Un error de redondeo hizo que se calculara el tiempo de forma
incorrecta, provocando que el Patriot ignorara al misil Scud atacante.

4. EL FALLO DEL PENTIUM EN LAS DIVISIONES LARGAS (1993)

Coste:

475

millones

de

dlares,

credibilidad

de

Intel.

Desastre: el promocionadsimo chip de Intel, Pentium, produca errores al

dividir nmeros en coma flotante que se encontraban en un rango
determinado. Por ejemplo, dividiendo 4195835,0/3145727,0 se obtena
1,33374 en lugar de 1,33382, un error del 0,006%. Aunque el error afectaba
a pocos usuarios, se convirti en una pesadilla en cuanto a sus relaciones
pblicas; con unos 5 millones de chips en circulacin, Intel ofreci
reemplazar los Pentium slo de aquellos clientes que demostraran que
necesitaban alta precisin en sus clculos. Finalmente, reemplaz los chips
de
todos
los
que
lo
solicitaron.
Causa: El divisor en la unidad de coma flotante contaba con una tabla de
divisin incorrecta, donde faltaban cinco entradas sobre mil, y que
provocaba
estos
errores
en
los
redondeos.
23

El sistema de guiado se detuviera. En ese momento, el control pas a un

sistema idntico redundante, que tambin fall al ejecutar el mismo
algoritmo.

5. EL DESORBITADO MARS CLIMATE (1998)

Coste:

125

millones

de

dlares.

Desastre: Despus de un viaje de 286 das desde la tierra, la nave "Mars

Climate Orbiter" encendi sus motores para ponerse en rbita alrededor de
Marte. Los motores arrancaron, pero el ingenio entr demasiado en la
atmsfera del planeta, provocando que se estrellara en su superficie.
Causa: El software que controlaba los propulsores del Mars Orbiter usaban
unidades imperiales (libras de fuerza) en lugar de unidades mtricas
(Newtons), como especificaba la NASA.

6. LAS PRUEBAS SOFTWARE EN GOOGLE

El Google Testing Blog ha estado publicando estos meses una serie de
post, escritos por el director de pruebas de Google, James Whittaker,
contando cmo organizan las pruebas software en Google. La serie es
extensa, est formada por cinco post, de los que he querido extraer y
resumir aqu lo que me ha parecido ms interesante:
Estructura organizacional. Las pruebas se realizan desde un rea
llamada Engineering Productivity
, Horizontal y compuesta por:
Un equipo de producto, que desarrolla herramientas de productividad.
Analizadores de cdigo, IDEs, herramientas de testing, etc.
Un equipo de servicios, que proporciona experiencia en herramientas,
documentacin, etc.
Los ingenieros, que se dividen por productos.
Los roles. En Google hay tres roles relacionados con la calidad y las
pruebas:
El SWE o Software Engineer, que desarrolla y hace las pruebas unitarias.
24

 El SET o Software Engineer in Test, que revisa diseos y se ocupa de la

calidad.
Esta
es
la
figura
que
ms
me
ha
llamado
la
atencin. Refactorizan cdigo y lo hacen ms estable. Trabajan en
desarrollo, con los desarrolladores, pero enfocados en asegurar la calidad.
Los TE o Test Engineer, dedicados a las pruebas, expertos en cada uno de
los productos que desarrollan.
Los tipos de pruebas. A las pruebas de cdigo, integracin y sistemas les
llaman pruebas pequeas, medianas y grandes. Las pueden realizar
cualquiera de los anteriores roles y pueden ejecutarse de manera manual o
automtica. Incluso destacan el importante papel que juegan para ellos las
pruebas manuales

5. CONCLUSIONES
En este trabajo presentamos una vista general sobre la calidad de Software,
los modelos de calidad y se puede verificar como estas ayudan al
aseguramiento de calidad.
La calidad total de un producto es muy difcil obtener y ms an para el
software, solo se puede maximizar. La calidad total est fundamentada en
diversos puntos de la Ingeniera de Software como se ha visto. Uno de los
ms importantes y que no debe faltar, es una herramienta para detectar los
defectos en cualquier momento del desarrollo y cuantificar con la ayuda de
las mtricas a dar un significado al proceso que se sigue, adems, realizar
un seguimiento de los distintos atributos de calidad que fueron definidos
para el proyecto de software en los requisitos no funcionales. Esto permite
caracterizar al proceso de desarrollo, permite tener bases objetivas para
mejorar el proceso de software.
Se ve que los atributos de calidad, los modelos, las listas de comprobacin,
planes SQA y las mtricas definidas para las inspecciones, son un conjunto
de herramientas que permiten la mejora incremental del proceso de
desarrollo en el transcurso del tiempo y as lograr cumplir con las
recomendaciones de los Modelos de Madurez de Capacidad CMMI y CMM.

25

6. BIBLIOGRAFA
http://eprints.rclis.org/5424/1/aci05395.ht
m
http://www.javiergarzas.com/calidadsoftware
http://aprenderaprogramar.com/index.php
?
option=com_content&view=article&id=19
8:calidad-del-software-metricas-yfiabilidad-de-aplicaciones-1a-partedv00103a&catid=45:tendenciasprogramacion&Itemid=164
http://www.eumed.net/tesisdoctorales/2014/jlcv/calidad-software.htm

26