Trabajo Investigativo 01

Ingeniera de software

Presenta
David Camilo Snchez Mora 20132578060
Hector Felipe Hurtado Acosta 20131078401
Yojhan Rodrguez 20131078023
Sebastian Espitia 20131078050

Docente
Juan Carlos Guevara B.

Universidad Distrital Francisco Jos de Caldas

Sistematizacin de datos
Facultad tecnolgica
Bogot D.C Colombia 08 de febrero de 2016

Contenido
2. Introduccin
3. Calidad
3.1. Definicin
3.2. Importancia de la calidad
3.3. Caractersticas
3.4. Factores crticos de xito
4. Modelos de calidad (Documentar 4 modelos)
4.1. Nombre
4.2. Descripcin
4.3. Criterios
5. Normas de calidad (Documentar 4 normas)
5.1. Nombre
5.2. Descripcin
5.3. Criterios
6. Calidad de modelos conceptuales
6.1. Mtricas para modelos conceptuales tradicionales
(Documentar 2 mtricas)
6.1.1. Nombre
6.1.2. Descripcin

6.2. Mtricas para modelos conceptuales orientados a objetos

(Documentar 2 mtricas)
6.2.1. Nombre
6.2.2. Descripcin
7. Calidad de producto de software
7.1. Normas (Documentar 2 normas)
7.1.1. Nombre
7.1.2. Descripcin
7.2. Modelos (Documentar 2 modelos)
8. Calidad del proceso de software
8.1. Normas (Documentar 2 normas)
8.1.1. Nombre
8.1.2. Descripcin
8.2. Modelos (Documentar 2 modelos)
9. Calidad de interfaz de software
9.1. Normas (Documentar 2 normas)
9.1.1. Nombre
9.1.2. Descripcin
9.2. Modelos (Documentar 2 modelos)
9.2.1. Nombre

9.2.2. Descripcin
10. Software para estimar calidad (Documentar 4
herramientas de software que permitan medir la calidad)
10.1. Nombre
10.2. Descripcin
10.3. Funcionalidades
10.4. Ejemplo
11. Cuadro comparativo de herramientas de software
12. Conclusiones
13. Bibliografa

2. Introduccin
En el presente trabajo se pretende conocer la gestin de la calidad del software
como instrumento principal para asegurar que el software se realice de buena
manera, tanto para el desarrollador como para el cliente, por lo que existen
diferentes aplicaciones que ayudan a desarrollar este tipo de administracin para
el proyecto y se podrn encontrar en este taller de investigacin sin antes definir el
concepto de calidad, las caractersticas, modelos, normas, entre otros.
3. Calidad
3.1. Definicin
La calidad en el momento cuenta con no solo una definicin si no con varias las
cuales las expondremos a continuacin:

Conjunto de propiedades y caractersticas de un producto o servicio, que le

confieren aptitud para satisfacer una serie de necesidades explcitas o
implcitas. (ISO 8402).

Grado en el que un conjunto de caractersticas inherentes cumple con los

requisitos.

El conjunto de actividades encaminadas a descubrir y satisfacer las

necesidades de un colectivo o de una sociedad en general.

Satisfaccin del cliente y conformidad con sus requisitos y necesidades.

El proceso de identificar, aceptar, satisfacer y superar constantemente las

expectativas y necesidades de todos los colectivos humanos relacionados
con la empresa (clientes, empleados,) con respecto a los productos y
servicios que proporciona.

Existen tres tipos de calidad relacionados entre s:

Calidad necesaria. Calidad que pide el cliente y la que le gustara recibir.

Calidad programada. Es el nivel de calidad que se propone obtener el

fabricante.


Calidad realizada. Es la calidad que se puede obtener debido a las personas
que realizan el trabajo o a los medios utilizados.

Algunos de los rasgos de calidad los podemos ver a continuacin:

Implica la mejora continua de la productividad y de la competitividad.

Significa hacer las cosas bien a la primera.

Consiste en dar al cliente los que ste desea.

Se basa en el sentido comn.

Involucra a todos los niveles de la empresa

3.2. Importancia de la calidad

La importancia de la clida se ve reflejada en el momento en el que una empresa

ofrece un servicio o producto en el que satisfaga adecuada y de la mejor manera
la necesidad o lo que demanda el usuario.
3.3. Caractersticas

La calidad la definen los clientes: Los clientes determinan sus necesidades y

si los productos y servicios que se les ofrecen les satisfacen. Se deben

conocer estas necesidades, preferencias, percepciones y valores de los

clientes con el fin de establecer una posicin de liderazgo.

El proceso de calidad se inicia con el liderazgo activo de la Alta Direccin: La

calidad no se delega, se practica. Se ha de impulsar desde los puestos de
direccin la estrategia de calidad, su desarrollo y crecimiento.

La calidad es un factor estratgico de competitividad y diferenciacin: No hay

niveles de calidad absolutos, lo que existe es una comparacin de
calidades percibidas por los clientes entre los diferentes productos del
mercado. El factor de calidad vara a lo largo del ciclo de vida del producto,
desde la innovacin en su inicio, pasando a la competencia en precio y
calidad segn se avanza en su ciclo de vida.

La calidad efectiva es garanta de rentabilidad sostenida: Si el nivel de calidad

obtenido cumple con las expectativas de los clientes, la rentabilidad est
garantizada. A la larga esto implica reduccin de costes, aunque en
principio es necesaria una inversin en formacin, aprendizaje y
modificacin de hbitos.

La calidad involucra a todos los miembros de la organizacin: La implicacin

de todo el personal en la poltica de calidad es muy necesaria. La imagen
que de la empresa se forman los clientes est condicionada por el
entusiasmo, motivacin y conviccin que transmiten los empleados.

La calidad involucra tambin a los proveedores: La calidad de un producto

depende en gran medida de la calidad de sus materias primas y de las
herramientas utilizadas en su proceso. De ah nace el concepto de calidad
concertada, que implica el trabajo conjunto con los proveedores con el fin
de que estos asuman su parte de responsabilidad en obtener el objetivo
final de calidad.

La calidad debe ser el criterio que configure todos los sistemas y procesos de la
empresa: Los sistemas que influyen en la gestin eficaz son:

Sistemas de captacin de informacin externa.

Sistemas de medicin de la calidad.
Sistemas de retribucin e incentivos al personal.

La calidad debe ser el criterio que configure todos los sistemas y procesos de la
empresa:

Sistemas de captacin de informacin externa. Informacin base para el

conocimiento del mercado, de la competencia, de los gustos y necesidades
del cliente que permite que se traduzcan en innovaciones en los productos.

Sistemas de medicin de la calidad. Permiten evaluar los factores de

calidad que soportan la estrategia de la empresa. As es posible evaluar el
grado de cumplimiento de los objetivos de calidad establecidos e introducir
correcciones si fuese necesario.

Sistemas de retribucin e incentivos al personal. Incentivos ligados al

cumplimiento de objetivos de calidad. Es una herramienta eficaz para
motivar al personal.

La calidad debe comunicarse: Hay que dar a conocer las ventajas

diferenciadoras para que se perciba la calidad. Las estrategias
comunicacionales tienen como objetivo:

Crear una imagen institucional que se asocie con el concepto de calidad.

 La promocin de los aspectos de calidad diferenciadores.

Calidad implica sensibilidad y preocupacin de la empresa por su entorno

social y medioambiental: No debe separarse del concepto global de calidad
la responsabilidad social, la tica y la conservacin del medio ambiente.

La calidad es dinmica: Est constantemente en transformacin debido

fundamentalmente a tres factores: los gustos de los consumidores varan
con el tiempo, la competencia presiona mediante el lanzamiento de nuevos
productos, y el proceso evolutivo interno de la empresa hace que se fije
nuevas metas.

3.4. Factores crticos de xito

De un modo resumido los Factores Crticos de xito (FCE) se pueden definir como
elementos o variables clave de una organizacin cuyo correcto desarrollo asegura
el desarrollo satisfactorio de sus procesos y trabajo*. Su planteamiento se basa en
dos premisas fundamentales: la minimizacin del riesgo y la maximizacin de los
resultados
Dentro de sus caractersticas que poseen los Factores Crticos de xito se pueden
observar:

- Estn estrechamente relacionados con la dinmica interna de la empresa:

actividades, procesos, organigrama, gestin y disponibilidad de recursos, relacin
con sus clientes y proveedores; y se encuentran fuertemente influenciados por el
entorno econmico, social y cultural donde se desenvuelve la empresa.

- Constituyen elementos vitales de la organizacin que determinan la

supervivencia o competitividad de la entidad a la que se refieren. Su determinacin
como variables que no pueden fallar delimitan las actuaciones mnimas que la
entidad debe controlar y asegurar.

- Son especficos de cada negocio y empresa por lo cual el xito de planes,

objetivos o acciones estratgicas especficas de cada organizacin precisan de su
determinacin correcta. Muchas empresas efectan un anlisis de su sector y
competencia aplicando lasCinco Fuerzas de Porter.

Se enmarcan dentro de un marco temporal especfico, pues las condiciones

cambiantes de los procesos internos de la empresa y actuacin de medio
externo (ambiente, competidores, preferencias de clientes, etc.) obliga a la
empresa a su continua revisin.

4. Modelos de calidad

La calidad est compuesta por una composicin de muchas caractersticas.Un

modelo de calidad entonces describe estas caractersticas y sus relaciones.
Los modelos a continuacin han sido los mas populares e la comunidad pero sin
sustento cientfico.
4.1 Modelo de Mccall
El modelo de McCall fue el primero en ser presentado en 1977 y se origin por Air
Forc y Dod.
Adems, Se focaliza en el producto final identificando atributos claves desde el
punto de vista del usuario. Estos atributos se denominan factores de calidad y son
normalmente atributos externos, pero tambin se incluyen algunos atributos
posiblemente internos.
Los factores de calidad son demasiados abstractos para ser medidos
directamente, por lo que por cada uno de ellos se introduce atributos de bajo nivel
denominados criterios de calidad. Algunos criterios de calidad son atributos
internos segn McCall que el atributo interno tiene un efecto directo en el atributo
externo correspondiente.

Factores de calidad
McCall propone tres perspectivas para agrupar los factores de calidad:

Revisin del producto: habilidad para ser cambiado.

Transicin del producto: adaptabilidad al nuevo ambiente.

Operacin del producto: caractersticas de operacin.

Factores de calidad de revisin: La revisin del producto incluye los

siguientes factores de calidad:

Mantenibilidad: esfuerzo requerido para localizar y corregir fallas.

Flexibilidad: facilidad de realizar cambios.
Testeabilidad: facilidad para realizar el testing, para asegurarse que el
producto no tiene errores y cumple con la especificacin.

Factores de calidad de transicin: La transicin del producto incluye los

siguientes factores de calidad:

Portabilidad: esfuerzo requerido para transferir entre distintos ambientes de

operacin.
Reusabilidad facilidad de reusar el software en diferentes contextos.
Interoperabilidad esfuerzo requerido para acoplar el producto con otros
sistemas.

Factores de calidad de operacin: La operacin del producto incluye los

siguientes factores de calidad:

Exactitud: el grado en el que el producto cumple con su especificacin.

Confiabilidad: la habilidad del producto de responder ante situaciones no
esperadas.

 Eficiencia: el uso de los recursos tales como tiempo de ejecucin y memoria

de ejecucin.
Integridad: proteccin del programa y sus datos de accesos no autorizados.
Usabilidad facilidad de operacin del producto por parte de los usuarios.
4.2 Modelo de Boehm
El segundo modelo de calidad ms conocido es presentado por Barry Boehm en
1978. Este modelo introduce caractersticas de alto nivel, caractersticas de nivel
intermedio y caractersticas primitivas, cada una de las cuales contribuye al nivel
general de calidad.
Caractersticas de alto nivel: las caractersticas de alto nivel representan
requerimientos generales de uso pueden ser:

Utilidad per-se: cuan (usable, confiable, eficiente) es el producto en s

mismo

Mantenibilidad: cuan fcil es modificarlo, entenderlos y retestearlo.

Utilidad general: si puede seguir usndose si se cambia el ambiente

Aunque los modelos McCall y Boehm parezcan similares, la diferencia est en que
McCall focaliza en medidas precisas de alto nivel, mientras que Boehm presenta
un rango ms amplio de caractersticas primarias. Adems, la Mantenibilidad est
ms desarrollada en Boehm. Otras diferencias entre estos dos modelos las

podemos ver en el siguiente cuadro comparativo:

4.3 Modelo ISO

La ISO ha emitido algunas normas que definen un modelo de calidad del software,
en varios contextos de uso.
ISO 9126-1 define 6 caractersticas de calidad principales, y 27 subcaractersticas.
Incluye 3 reportes tcnicos (ISO/IEC 9126-2, 3 e 4).
ISO/IEC 9241 define las caractersticas de un software usable.
ISO 12119 define las caractersticas de calidad para un software COTS
(Commercial off the shelf).
La ISO tambin ha publicado la norma 14598 que gua en el proceso de valoracin
de la calidad del software segn los criterios de la 9126.
Modelo ISO 9126: Durante muchos aos se busc en la Ingeniera de Software un
modelo nico para expresar calidad. La ventaja era fcil de conocer: poder
comparar productos entre s en 1992, una variante del modelo de McCall fue
propuesta como estndar internacional para medicin de calidad de software.
ISO 9126 Software Product Evaluation: Quality Characteristics and Guidelines for
their Use es el nombre formal. La ltima revisin ha sido realizada en el 2004; est
en proceso de una nueva revisin. No se proveen certificados de calidad por esta
norma.

En ISO 9126 se reconocen seis factores de calidad que se pueden considerar

tanto internos como externos:

Funcionalidad.

Confiabilidad.

Eficiencia.

Usabilidad.

Mantenibilidad.

Portabilidad.

Los cuatro factores de calidad de uso que se conocen en el modelo ISO 9126:

Eficacia.

Seguridad.

Productividad.

Satisfaccin.

4.4 Modelo EFQM

El Modelo EFQM es un modelo no normativo, cuyo concepto fundamental es la
autoevaluacin basada en un anlisis detallado del funcionamiento del sistema de
gestin de la organizacin usando como gua los criterios del modelo.
Esto no supone una contraposicin a otros enfoques (aplicacin de determinadas
tcnicas de gestin, normativa ISO, normas industriales especficas, etc.), sino
ms bien la integracin de los mismos en un esquema ms amplio y completo de
gestin.
La utilizacin sistemtica y peridica del Modelo EFQM por parte del equipo
directivo permite a ste el establecimiento de planes de mejora basados en
hechos objetivos y la consecucin de una visin comn sobre las metas a alcanzar
y las herramientas a utilizar. Es decir, su aplicacin se basa en:

La comprensin profunda del modelo por parte de todos los niveles de direccin
de la empresa.
La evaluacin de la situacin de la misma en cada una de las reas.

El Modelo EFQM consta de dos partes:

Un conjunto de criterios de excelencia empresarial que abarcan todas las reas
del funcionamiento de la organizacin.
Un conjunto de reglas para evaluar el comportamiento de la organizacin en cada
criterio. Hay dos grupos de criterios:
Los Resultados (Criterios 6 al 9) representan lo que la organizacin consigue para
cada uno de sus actores (Clientes, Empleados, Sociedad e Inversores).
Los Agentes (Criterios 1 al 5) son aspectos del sistema de gestin de la
organizacin. Son las causas de los resultados. Para cada grupo de criterios hay
un conjunto de reglas de evaluacin basadas en la llamada lgica REDER.
Los resultados han de mostrar tendencias positivas, compararse favorablemente
con los objetivos propios y con los resultados de otras organizaciones, estar
causados por los enfoques de los agentes y abarcar todas las reas relevantes.
Los agentes han de tener un enfoque bien fundamentado e integrado con
otros aspectos del sistema de gestin, su efectividad ha de revisarse
peridicamente con objeto de aprender y mejorar, y han de estar sistemticamente
desplegados e implantados en las operaciones de la organizacin.

5. Normas de calidad (Documentar 4 normas)

Hoy en da la calidad es importante para poder satisfacer al cliente que pida un

sistema de calidad y cada vez hay mayor competitividad en el mundo de la
informtica lo cual hace que los desarrolladores busque opciones para desarrollar
software de calidad y para ello han venido creando estndares que hoy en da se

rigen para el desarrollo correcto de aplicaciones de calidad cumpliendo con sus

normas y parmetros hablaremos especficamente de 3 estndares aplicados al
desarrollo de software:
5.1 ISO
La organizacin para la estandarizacin, mejor conocida como la ISO es la
agencia especializada en estandarizacin fue establecida el 23 febrero de 1947
con el de promover estandarizacin internacional de manera que se facilitara el
intercambio internacional de bienes y servicios as como el desarrollo cientfico y
tecnolgico. Actualmente abarca los estndares nacionales de 91 pases y en
estados unidos la representacin se llama The American National Standards
Institute.
ISO comprende alrededor de 180 comits tcnicos cada uno es responsable de
una o ms reas de especializacin abarcan desde las abreviaturas de los
sistemas de medicin hasta la especificacin de protocolos de transferencia
pasando por especificacin de tornillos, lentes, contenedores martimos, medios
magnticos, hojas de papel, cables, elementos estructurales, pruebas de
seguridad, simbologa, medio ambiente, etc., principalmente el software.
Con el estndar ISO 9000-3, las 3 fallas predomnales que existen dentro de la
industria de software son: los altos costos en cuanto a depuracin de un sistema,
tiempo perdido en la correccin del sistema y la falla de conocer todas las
necesidades del usuario. Hoy en da la industria del software est implementando
modelos para mejorar sus operaciones y corregir sus fallas y la expectativa es
colocar el desarrollo de software bajo un control estadstico para verificar cuales
son las actividades repetitivas que continuamente se tienen que programar y que
producen el mismo resultado. Uno de los modelos base son las normas
estndares ISO 9000 que en especial han creado un inters masivo para la
industria del software a causa de su aceptacin internacional de muchas
compaas importantes.
ISO 9000-3
Ttulo: Normas de gestin de calidad y garanta de la calidad.
Naturaleza: internacional
mbito: desarrollo de sistemas de informacin, procesos de ciclo de vida, calidad
del software.

Campo de aplicacin y alcance: esta parte de la ISO 9000 contienen orientaciones

que facilitan la aplicacin de la norma ISO 9001 a las organizaciones dedicadas al
desarrollo, suministro y mantenimiento del software.
5.2 Estndar Spice
El creciente nmero de mtodos de evaluacin disponibles, y la creciente
utilizacin de la tcnica comercial en reas sensibles, fueron los factores clave que
impulsaron el desarrollo y la aceptacin de una propuesta para desarrollar un
estndar internacional para la evaluacin de procesos de software.
Una norma internacional sobre evaluacin de procesos de software ofrecer los
siguientes beneficios a la industria y los usuarios del software:
Beneficios para la Industria del Software.
Los proveedores de software se sometern a un solo esquema de proceso de
evaluacin.
Las organizaciones de desarrollo de software tendrn una herramienta para iniciar
y sostener un proceso continuo de mejora.
Los directores de programas tendrn un medio para garantizar que su desarrollo
de software est en consonancia con, y apoya, las necesidades comerciales de la
organizacin.
5.3 Estndar CMM
CMM es el mximo estndar en ingeniera de software Innovacin, velocidad y
satisfaccin del cliente se han convertido en la consigna de las organizaciones que
quieren sobrevivir y crecer en el cada vez ms competitivo mundo moderno. Como
las tecnologas de informacin resultan fundamentales para lograrlas, el software
se ha constituido en la piedra angular sobre la cual se soportan la gran mayora de
los nuevos modelos de empresa.
La creciente necesidad, sumada a dcadas de promesas incumplidas en cuanto a
calidad, costos y cumplimiento en el desarrollo de software, condujo al Instituto de
Ingeniera de Software de los Estados Unidos a desarrollar el modelo CMM
(CapabilityMaturityModel - Modelo de Madurez de Capacidad).
El CMM est compuesto de 316 prcticas claves agrupadas en 18 reas y
distribuidas en una jerarqua de cinco niveles, a travs de los cuales una

organizacin progresivamente alcanza mayor calidad, productividad y menores

costos en el desarrollo de software.
Los niveles progresan desde el 1, que representa el estado catico, hasta el nivel
5, que representa el estado de optimizacin continua.
Nivel 1. Inicial.
Nivel 2. Repetible.
Nivel 3. Definido.
Nivel 4. Administrado.
Nivel 5. Optimizacin.
Nivel 1. Inicial. En este nivel, los procesos y mtodos de ingeniera no se
encuentran definidos. Por esa razn, los proyectos son adelantados de manera
incoherente, incontrolada y poco profesional.
Nivel 2. Repetible. Se establecen algunos procesos y mtodos de ingeniera a
nivel de proyectos, an incipientes.
Nivel 3. Definido. Los procesos, actividades y mtodos relacionados con la
ingeniera y administracin de proyectos se encuentran documentados,
estandarizados y construidos alrededor de un marco integrado para toda la
compaa.
Nivel 4. Administrado. La compaa opera bajo Control Estadstico de Procesos,
tanto en procesos como en productos.
Nivel 5. Optimizacin. En este nivel, las organizaciones se encuentran en un
proceso de mejoramiento continuo. Todos los procesos y tcnicas modernas estn
en pie, lo mismo que la administracin cuantitativa.

6. Calidad de modelos conceptuales

Algunos autores definen modelo conceptual como sobre un dominio que un

sistema de informacin necesita conocer para llevar a cabo las

funciones requeridas. La influencia del modelo conceptual en el producto
resultante, aunque slo sea una fase inicial, es mucho mayor que la de otras
fases del ciclo de vida, ya que la deteccin y correccin de errores en las
primeras etapas de cualquier proceso, y en particular en el desarrollo del
software, permite una mejora de la calidad y unos menores costes de no
conformidad, la atencin al modelado es clave para el xito del proyecto.
La rpida evolucin de la tecnologa informtica, con sus impresionantes mejoras
en prestaciones y rendimiento, no ha sido acompaada por una anloga evolucin
en el desarrollo de la industria del software;
La ya conocida como crisis del software, por ello, los equipos de I+D de
las empresas y numerosas universidades han dedicado sus esfuerzos a
la investigacin y desarrollo de nuevas formas de creacin de software, dando
lugar a modelos y metodologas.
Estos modelos y metodologas, a pesar de mejorar la situacin, no llegan a
obtener resultados espectaculares, por lo que se abren camino nuevas
ideas y modelos.
De entre ellos empiezan a destacar los llamados modelos conceptuales, que
permiten el enlace entre los requisitos de los usuarios y la solucin software
correspondiente y permiten modelar, adems de los aspectos estticos de
los Sistemas Informticos, algunos aspectos de su comportamiento.
Los modelos conceptuales pueden clasificarse en dos grandes grupos

6.1. Mtricas para modelos conceptuales

6.1.2 Mtrica de Kesh

El mtodo se compone de tres pasos:

Clculo del valor de cada uno de los componentes ontolgicos: Se calcula

individualmente el valor de los componentes estructurales (las relaciones entre los
elementos que forman el modelo: adecuacin al problema: o1, validez: o2,
consistencia: o3 y concisin o4) y de los componentes de contenido (los atributos
de las entidades: completitud: o5, cohesin: o6 y validez: o7).

Clculo de los valores de los componentes de comportamiento. Este clculo

se hace a partir de los valores de los componentes ontolgicos relevantes para
cada uno de los componentes de comportamiento. Los componentes de
comportamiento a tener en cuenta son: facilidad de uso desde el punto de vista del
usuario: s1, usabilidad desde el punto de vista del diseador: s2, facilidad de
mantenimiento: s3, precisin: s4 y rendimiento: s5.

Clculo de la calidad del modelo. Este clculo se hace a partir de los valores
de los componentes de comportamiento de acuerdo con la frmula: Q =
wi si (con i de 1 a 5) donde wi son los pesos de los factores de comportamiento y
si los valores de dichos factores. Los pesos son determinados por la organizacin
en funcin de la importancia que tengan para la misma.
Las frmulas para el clculo de si son las siguientes:

Los valores de los factores ontolgicos son, en algunos casos, estimados por los
usuarios, y en otros calculados mediante frmulas.
Los procedimientos son los siguientes:
Adecuacin del modelo al problema (o1).
Validez del modelo (o2).
Consistencia del modelo (o3).
Concisin del modelo (o4).
Complecin del contenido (o5).
Cohesin del contenido (o6).
Validez del contenido (o7).
El modelo est poco experimentado, por eso se necesita mucha interaccin entre
los diseadores y los usuarios para su retroalimentacin. El propio Kesh considera
que el valor de Q no es una estimacin precisa, sino un indicador de la calidad del
modelo ER y que, por consiguiente, habra que seguir trabajando sobre el modelo.
6.1.3 Mtricas de Moody
Moody present un conjunto de mtricas, algunas objetivas y otras subjetivas,
para evaluar algunos factores de calidad de los modelos de datos. Estas
mtricas son, para los diferentes factores de calidad:

Complecin:

Nmero de elementos del modelo de datos que no

corresponden con los requisitos de usuario.

Nmero de elementos del modelo de datos que corresponden

con los requisitos de usuario, pero definidos incorrectamente.

Nmero de requisitos del usuario no representados en el

modelo.

Nmero de inconsistencias con el modelo de procesos.

Integridad:

Nmero de restricciones de integridad incluidas en el modelo

que no corresponden a polticas de negocio.

Nmero de reglas del negocio que no se cumplen por el

modelo de datos.

Flexibilidad:

Costes estimados de los cambios.

Importancia estratgica de los cambios.

Nmero de elementos del modelo que en el futuro estarn

sometidos a cambios.

Correccin:

Nmero de violaciones a las formas normales.

Nmero de violaciones a las convenciones de modelos de

datos.

Nmero de instancias de redundancias en el modelo.

Simplicidad:

Nmero de entidades.

Nmero de entidades y relaciones.

Nmero de constructores.

Integracin:

Nmero de conflictos con los sistemas existentes.

Nmero de conflictos con el modelo de datos corporativo.

Valoracin de los representantes de todas las reas del

negocio.

Implementabilidad:

Valoracin de riesgo tcnico.

Valoracin de riesgo de planificacin.

Estimacin del coste del desarrollo.

Nmero de elementos fsicos del modelo de datos.

Comprensilidad:

Valoracin de los usuarios sobre la comprensibilidad del

modelo.

Capacidad de los usuarios de interpretar el modelo

correctamente.

Valoracin de los desarrolladores sobre la comprensibilidad

del modelo.

Moody propuso que investigadores y profesionales trabajen conjuntamente para

demostrar la validez de estas mtricas. El mtodo de Moody no ha sido validado ni
terico ni prcticamente, no aporta herramientas, tiene medidas objetivas y
estimaciones subjetivas, y solo tiene en cuenta algunos factores de calidad para
modelos ER.
6.2. Mtricas para modelos conceptuales orientados a objetos
6.2.1Mtricas de Abreu y Melo
Abreu y Melo presentaron las mtricas MOOD (Metrics for Object Oriented Design)
para medir algunos de los principales mecanismos de los modelos orientados a
objetos (encapsulamiento, polimorfismo, herencia y paso de mensajes,...) para
poder evaluar la productividad del desarrollo y la calidad del producto.

Estn encuadradas dentro de lo que se conoce como mtricas a nivel de sistema.

Las mtricas MOOD se definieron para aplicarlas a nivel de diagramas de clases y
se pueden utilizar en la fase de diseo.
Las definiciones de las diferentes mtricas son:

MHF: El Method Hiding Factor (factor de ocultamiento de los mtodos) se

define como el cociente entre la suma de las invisibilidades de todos los mtodos
definidos en todas las clases y el nmero total de mtodos definidos en el sistema.
La invisibilidad de un mtodo es el porcentaje total de clases desde las cuales el
mtodo es invisible.

AHF: El Attribute Hiding Factor (factor de ocultamiento de los atributos) se

define como el consiente entre el nmero de invisibilidades de todos los atributos
definidos en todas las clases y el nmero total de atributos definidos en el sistema.
Se propone tambin como medida de encapsulacin. Idealmente el valor de esta
mtrica debera ser siempre del 100%, siendo necesario para ello ocultar todos los
atributos.

MIF: El Method Inheritance Factor (factor de herencia de los mtodos) es el

cociente entre el nmero de mtodos heredados en todas las clases del sistema y
el nmero total de mtodos (heredados y locales) en todas las clases.

AIF: El Attribute Inheritance Factor (factor de herencia de los atributos) est

definido como el cociente entre el nmero de atributos heredados en todas las
clases del sistema y el nmero total de atributos existentes (heredados y definidos
localmente) en todas las clases.

PF: El Polymorphism Factor (factor de polimorfismo) se define como el ratio

entre el nmero actual de situaciones diferentes posibles de polimorfismo y el
nmero mximo de posibles situaciones distintas de polimorfismos para cada
clase.

CF: Coupling Factor (factor de acoplamiento) se define como la proporcin

entre el mximo nmero posible de acoplamientos en el sistema y el nmero real
de acoplamientos no imputables a la herencia.
En resumen, las mtricas de Abreu y Melo se enfocan hacia las caractersticas de
los diagramas de clase, son medidas objetivas y han sido validadas de forma
terica y parcialmente de forma emprica.
6.2.2 Mtricas de Chindamber y Kemerer

En 1994, Chindamber y Kemerer propusieron seis mtricas para la complejidad

del diseo OO, aunque no todas pueden aplicarse a nivel conceptual, y adems
han sido muy criticadas por su ambigedad e imprecisin.
Algunas de estas mtricas estn encuadradas dentro de los que se conoce como
mtricas a nivel de herencia, otras mtricas a nivel de acoplamiento, otras a nivel
de clases.
El acoplamiento es el empleo de mtodos o atributos definidos en una clase que
son usados por otra.
Las clases tienen que interactuar unas con otras para formar sistemas, y esta
interaccin puede indicar su complejidad.
Las mtricas que se consideran a nivel de herencia son:

DIT: La mtrica Depth of Inheritance Tree (profundidad en

rbol de herencia ) se define como la profundidad del rbol de
una clase (en los casos de herencia mltiple es la mxima
longitud desde el nodo hasta la raz del rbol).

NOC: La mtrica Number Of Children (nmero de hijos) se

define como el nmero de subclases inmediatas subordinadas
a una clase, es decir, la cantidad de subclases que pertenecen
a una clase.

CBO: Coupling Between Objects (acoplamiento entre objetos)

de una clase se define como el nmero de clases a las cuales
una clase est ligada. Se da dependencia entre dos clases
cuando una de ellas usa mtodos o variables de la otra clase.

Las mtricas que se consideran a nivel de clases identifican caractersticas dentro

de las clases destacando diferentes aspectos de sus abstracciones y ayudando a
descubrir clases que podran necesitar ser rediseadas. Algunas de estas son:

RFC: Response For a Class (respuesta de una clase) es el cardinal del

conjunto de todos los mtodos que se pueden invocar como respuesta a un
mensaje a un objeto de la clase o como respuesta a algn mtodo en la
clase.

WMC: Weighted Methods per Class-WMC (mtodos ponderados por clase),

mide la complejidad de una clase. Si todos los mtodos se estiman
igualmente complejos, entonces WMC es, simplemente, el nmero de
mtodos definidos en una clase.

LCOM: Lack of Cohesion in Methods (falta de cohesin en los mtodos)

establece en qu medida los mtodos hacen referencia a atributos. LCOM
es una medida de la cohesin de una clase midiendo el nmero de atributos
comunes usados por diferentes mtodos, indicando la calidad de la
abstraccin hecha en la clase.

7. Calidad de producto de software

El concepto de Calidad asociado al desarrollo software, est ligado al
mismo desde sus orgenes. Desafortunadamente, se construyen proyectos y
productos que no alcanzan los mnimos de calidad esperado, incluso los
costes de no calidad, la deuda tcnica, inducen a la no finalizacin con
xito de los mismos. Planificamos el desarrollo de productos en base a una
metodologa o un marco de trabajo, siguiendo un proceso definido y obviando
actividades asociadas a la calidad.
A menudo confundimos la calidad del proceso con la calidad del producto, lo que
conlleva falsas expectativas en el desarrollo del software. Incluso en
muchas organizaciones no existe una mentalizacin real por la calidad del
producto, sino que prima la puesta en servicio sobre la calidad del mismo;
y lo que es peor, no cuentan con un proceso de V&V (verificacin y
validacin) definido y obviamente no implantado.
La Calidad del Producto es una ventaja inherente, consubstancial, y
connatural frente a la Competencia, un Producto no es slo la
implementacin software, escrito en un determinado lenguaje de
programacin, de un conjunto de funcionalidades, claras y explicitas, que
permiten establecer un proceso de negocio en nuestras Compaas, con el
fin de crear valor. Todo aquel activo generado en la Cadena de Valor, en
aras a la generacin de un activo software, forma parte inherente del mismo.
A este pool de assets lo denominamos producto.

7.1. Normas

7.1.2 SO/IEC 9126

Funcionalidad
Adecuacin: capacidad del producto software para proporcionar un conjunto
apropiado de funciones para tareas y objetivos de usuario especificados.
Exactitud: Capacidad del producto software para proporcionar los resultados o
efectos correctos o acordados, con el grado necesario de precisin.
Interoperabilidad: Capacidad del producto software para interactuar con uno o ms
sistemas especificados.
Seguridad de acceso: Capacidad del producto software para proteger informacin
y datos de manera que las personas o sistemas no autorizados no puedan leerlos
o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas
autorizados.
Cumplimiento funcional: Capacidad del producto software para adherirse a
normas, convenciones o regulaciones en leyes y prescripciones similares
relacionadas con funcionalidad.
Fiabilidad
Madurez: Capacidad del producto software para evitar fallar como resultado de
fallos en el software.
Tolerancia a fallos: Capacidad del software para mantener un nivel especificado de
prestaciones en caso de fallos software o de infringir sus interfaces especificados.
Capacidad de recuperacin: Capacidad del producto software para reestablecer
un nivel de prestaciones especificado y de recuperar los datos directamente
afectados en caso de fallo.
Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a
normas, convenciones o regulaciones relacionadas con al fiabilidad.
Usabilidad

Capacidad para ser entendido: Capacidad del producto software que permite al
usuario entender si el software es adecuado y cmo puede ser usado para unas
tareas o condiciones de uso particulares.
Capacidad para ser aprendido: Capacidad del producto software que permite al
usuario aprender sobre su aplicacin.
Capacidad para ser operado: Capacidad del producto software que permite al
usuario operarlo y controlarlo.
Capacidad de atraccin: Capacidad del producto software para ser atractivo al
usuario.
Cumplimiento de la usabilidad: Capacidad del producto software para adherirse a
normas, convenciones, guas de estilo o regulaciones relacionadas con la
usabilidad.
Eficiencia
Comportamiento temporal: Capacidad del producto software para proporcionar
tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo
condiciones determinadas.
Utilizacin de recursos: Capacidad del producto software para usar las cantidades
y tipos de recursos adecuados cuando el software lleva a cabo su funcin bajo
condiciones determinadas.
Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la eficiencia.
Mantenibilidad
Capacidad para ser analizado: Es la capacidad del producto software para serle
diagnosticadas deficiencias o causas de los fallos en el software, o para identificar
las partes que han de ser modificadas.
Capacidad para ser cambiado: Capacidad del producto software que permite que
una determinada modificacin sea implementada.
Estabilidad: Capacidad del producto software para evitar efectos inesperados
debidos a modificaciones del software.

Capacidad para ser probado: Capacidad del producto software que permite que el
software modificado sea validado.
Cumplimiento de la mantenibilidad: Capacidad del producto software para
adherirse a normas o convenciones relacionadas con la mantenibilidad.
Portabilidad
Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes
entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos
proporcionados para este propsito por el propio software considerado.
Instalabilidad: Capacidad del producto software para ser instalado en un entorno
especificado.
Coexistencia: Capacidad del producto software para coexistir con otro software
independiente, en un entorno comn, compartiendo recursos comunes.
Capacidad para reemplazar: Capacidad del producto software para ser usado en
lugar de otro producto software, para el mismo propsito, en el mismo entorno.
Cumplimiento de la portabilidad: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la portabilidad.
Efectividad: Capacidad del producto software para permitir a los usuarios alcanzar
objetivos especificados con exactitud y completitud, en un contexto de uso
especificado.
Productividad: Capacidad del producto software para permitir a los usuarios gastar
una cantidad adecuada de recursos con relacin a la efectividad alcanzada, en un
contexto de uso especificado.
Seguridad fsica: Capacidad del producto software para alcanzar niveles
aceptables del riesgo de hacer dao a personas, al negocio, al software, a las
propiedades o al medio ambiente en un contexto de uso especificado.
Satisfaccin: Capacidad del producto software para satisfacer a los usuarios en un
contexto de uso especificado.
7.1.2 ISO 14598

Planeamiento y Gestin: Recomendaciones y orientaciones que sirven como

apoyo para el proceso de validacin del producto software. Ej. desarrollo,
adquisicin, transferencia de tecnologas de validacin.
ISO/IEC 14598-3 Procesos para Desarrolladores: Seleccin y registro de
indicadores que pueden ser medidos y evaluados a partir de resultados
intermedios obtenidos durante las fases de desarrollo para que en base a stos se
tomen decisiones acerca del proyecto.
ISO-IEC 14598-4: proceso para los compradores: establece un proceso
sistemtico para la evaluacin de productos de software comercial, de productos
de software personalizado o modificar los productos existentes. Usado para
garantizar que un producto desarrollado o modificado cumple los requisitos
inicialmente especificados.
ISO-IEC 14598-5: proceso para evaluadores orientaciones y recomendaciones
para la aplicacin prctica de la evaluacin de producto de software cuando las
diversas partes, necesitan comprender, aceptar y confiar en los resultados de la
evaluacin.
ISO-IEC 14598-6: Documentacin de mdulos de evaluacin. Documento
estructurado
Establecer el propsito de la evaluacin.
Productos intermedios:

Decidir sobre la aceptacin de un producto intermedio de un subcontratista;

Decidir cundo un proceso est completo y cuando remitir los productos al

siguiente proceso; predecir o estimar la calidad del producto final;

Recoger informacin con objeto de controlar y gestionar el proceso.

Producto final:

Decidir sobre la aceptacin del producto; decidir cundo publicar el

producto; comparar el producto con otros productos competitivos;

Seleccionar un producto entre productos alternativos;

Valorar tanto el aspecto positivo como negativo cuando est en uso;

Decidir cundo mejorar o reemplazar un producto.

Producir un plan de evaluacin: El plan de evaluacin describe los mtodos de

evaluacin y el programa de acciones del evaluador. Debe ser consistente con el
plan de mediciones
7.2. Modelos
7.2.1 Modelo GQM (Goal Question - Metric)
El modelo GQM (objetivo-pregunta-mtrica /goal question - metric) de Basili y
Rombach (1998) es una propuesta de objetivos / metas orientado a la definicin
de modelos de calidad. Se propone el paradigma GQM para evaluar la calidad de
cada proyecto. Este modelo utiliza una propuesta para definir un modelo de
calidad hasta obtener las mtricas respectivas con el anlisis e interpretacin de
los datos de las 130 mediciones respectivas. Plantea el enfoque de medicin para
evaluar la calidad del software basado en la identificacin de objetivos a lograr. El
enfoque de GQM basa la mejora en la definicin clara de procesos y productos.
Proporciona la estructura para obtener los objetivos cruciales del proyecto .
Consta de 3 etapas (Figura 20): 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 estn cumpliendo los objetivos 3- Decidir
qu medir para poder contestar las preguntas de manera adecuada, es decir,
desarrollar un conjunto de mtricas que ayuden a responder la pregunta. Las
medidas individuales obtenidas se relacionan para poder ser utilizadas en el
contexto del proyecto completo. Otro aspecto preponderante en el enfoque GQM
es la interpretacin de los datos recolectados en funcin de las preguntas a partir
de las cuales se derivaron esas medidas.

La idea fundamental del GQM es la medicin orientada a objetivos / metas, la cual

est basada en el contexto. De acuerdo a esto, el modelo de medicin tiene 3
niveles (Tabla 15): (1) Nivel Conceptual (Goal): un objetivo / meta es definido para
un propsito especfico en base a las necesidades de la organizacin, teniendo en
cuenta una variedad de razones, desde distintos puntos de vista relacionados a un
ambiente en particular. Un objetivo / meta representa el nivel mximo de
caracterstica de calidad. 131 (2) Nivel Operacional (Question): es un conjunto de
preguntas que son utilizadas para caracterizar la forma de realizacin de una meta

especfica.22 Cada caracterstica de nivel mximo es redefinida en las

subcaractersticas usando un conjunto de preguntas. (3) Nivel Cuantitativo
(Metric): es un conjunto de datos que est asociado a toda pregunta de manera
cuantitativa 23. Para cuantificar una subcaracterstica se utiliza un conjunto de
mtricas. La interpretacin de las mtricas es utilizada para responder a las
preguntas y concluir si la meta u objetivo se ha cumplido.

Niveles de medicin del Modelo GQM

El modelo GQM es un enfoque til para decidir qu medir. Es un enfoque

orientado a metas, por lo tanto, permite a los tomadores de decisin, elegir
aquellas mtricas que se relacionen a las metas ms importantes de los
problemas ms urgentes.

7.2.1 Modelo de Gilb

El modelo de Gilb plantea la creacin de una especificacin de requisitos de
calidad para cada proyecto que deben escribir conjuntamente el usuario y el
analista. Es un modelo que permite determinar una lista de caractersticas que
definen la calidad de la aplicacin. Puede ser de 2 tipos: (1) Originales y (2) de
modelos tradicionales. Las caractersticas se pueden medir mediante varias
subcaractersticas o mtricas detalladas. Para cada una de ellas, se deben
especificar los siguientes conceptos: (1) nombre y definicin de la caracterstica,
(2) Escala o unidades de medicin, (3) recopilacin de datos o prueba, (4) valor
previsto, (5) valor ptimo, (6) valor en el sistema actual y (7) comentarios. En la

dcada del ochenta, se comenzaron a usar modelos particulares de evaluacin

para cada empresa o proyecto, implantndose el concepto de calidad relativa.
Este enfoque se ha asociado a la filosofa QFD (Quality Function Deployment), o
el despliegue de la funcin de la calidad, que se aplica al mbito de la gestin de
la calidad industrial y en el que se han basado modelos posteriores.

8. Calidad del proceso de software

La calidad vista desde el mundo de los procesos nos dice que la calidad
del producto software est determinada por la calidad del proceso.
La calidad del proceso, afecta a las caractersticas de calidad de los
productos software, que a su vez repercuten en la calidad en el uso tal y como es
percibido por el cliente.Para alcanzar la calidad del proceso de software, es
necesario la satisfaccin por parte de los elementos que intervienen en el proceso:

La satisfaccin de la alta direccin,

La satisfaccin del personal involucrado en el desarrollo del sistema

La satisfaccin del usuario final.

La aplicacin del control de calidad de sistemas no es solamente al sistema en s,

sta conforma la ltima parte de la evaluacin. En cada una de las etapas
del proceso de desarrollo de los sistemas se llevar a cabo un control de calidad,
ya que, si el sistema presenta fallas o errores, no solamente
depender del funcionamiento de ste, sino de cmo ha ido cambiando, o
evolucionando en todo este proceso. En este caso, la calidad depende de
cmo se lleve a cabo todo el proceso y cada subproceso del proyecto. Una
desviacin en cualquiera de las fases significar puntos menos en la calidad
que el proyecto presente, de igual manera en el nivel de satisfaccin del
usuario.
La Calidad del Software se disea conjuntamente con el sistema, nunca al
final. En los sistemas de garanta de calidad, se observa una relacin entre los
precios y costos que generan fallas al producir software, costos al volver a trabajar
sobre un software ya desarrollado para reparar defectos, la reduccin de precios al

obtener una calidad ms pobre, los costos del proceso de inspeccin del software,
el costo del sistema de garanta de calidad y los beneficios obtenidos. A
mayor calidad, mayores son los costos, pero mayores tambin los beneficios
obtenidos en la fase del mantenimiento del software. Este costo hay que
considerarlo dentro de todo el ciclo de vida del proyecto.
Una de las formas de evaluar la calidad es a travs de las Revisiones
Tcnicas Formales (RTF), las cuales consisten en una actividad que garantiza la
Calidad del Software y que es llevada a cabo por los profesionales de la
Ingeniera de Software. Es una actividad colectiva que permite ampliar la visin
sobre lo que se revisa, situacin que se profundiza al ser aplicada por
distintos niveles y especialidades de profesionales a distintos elementos que
componen el software, lo cual permite; por una parte que los profesionales
que recin se incorporan al equipo de trabajo puedan observar los
diferentes enfoques del anlisis, diseo e implementacin del software,
adems que sirve para promover la seguridad y la continuidad, ya que varias
personas se familiarizan con partes del software que de otro modo no hubiesen
visto nunca. Las RTF permiten establecer un marco comn para la definicin
de distintas etapas de revisin en el ciclo de vida del software, este
mecanismo no slo est pensado para las etapas tempranas del ciclo de vida,
sino que tambin puede-y-debe - ser utilizado en etapas como la de prueba de
software y mantenimiento. El mecanismo ms comn para su implementacin es
la reunin de revisin, la cual deber regirse, para asegurar su xito, por una
buena planificacin, control y, sobre todo, por la participacin dedicada de todos
y cada uno de los involucrados

8.1. Normas

8.1.1 ISO/IEC 90.003:2004

La norma ISO/IEC 90.003, como aplicacin de la norma ISO 9001 en el desarrollo
de software, nos indica que, en toda actividad, hay que buscar los procesos que la
componen, para poder asegurar la calidad en cada uno de ellos y, por tanto,
asegurar la calidad final de la actividad realizada.
Un documento debe contener toda la informacin necesaria relacionada con un
proceso. Asimismo, un proceso puede estar compuesto, o no, por sub-procesos,
cada uno de los cuales tiene su correspondiente documento. En funcin de la
longitud del documento del proceso, ste contendr 1 ms artculos (o partes).

Esquema documentacin
Correspondencia

Proceso

ISO/IEC 90003:2004

Documento

Partes y/o vnculos a documentos

Joomla!

Categora

Artculo(s) y/o vnculos a categoras

Implementacin de la norma ISO/IEC 90003:2004

Para que cada documento quede, pues, correctamente completado, se le deben
aadir una serie de campos que contengan informacin adicional.
Dicha informacin es la siguiente:
Autor
Creacin (fecha)
Versin
Documento complemento/sustitucin. Indica el documento al que complementa o
substituye, no al que pertenece, que aparece en otro campo.
Fuentes de informacin
Ficheros adjuntos
Demo (ejemplo)
Documento(s) padre
La idea inicial, y la ms sencilla, sera implementar esta informacin directamente
en el desarrollo del artculo o de la categora, pero esto supondra una mayor
complejidad en el texto, y no tener bien dispuesta esta informacin en el front-end.
Busqu entonces la manera de aadir campos a los artculos, pero esto
significaba acceder directamente a la base de datos y realizar modificaciones en el
'core' de Joomla!, que correran peligro en cada actualizacin del CMS.
Por tanto, busqu extensiones de Joomla!, y encontr Fields Attach.
8.2. Modelos

8.2.1Modelo de Cascada

Las fases del Modelo de Cascada son:

Anlisis de requerimientos y definicin.

Diseo del sistema y del software.

Implementacin y prueba de unidades

Integracin y prueba del sistema.

Operacin y mantenimiento.

La dificultad en esta modelo reside, en la dificultad de hacer cambios entre

etapas.
Problemas

Poca visibilidad en el proceso

Los sistemas estn pobremente especificados

Se requieren habilidades especiales.

Aplicabilidad

Para sistemas interactivos pequeos o medianos.

Para partes de sistemas grandes (ej. la interfaz de usuario).

Para sistemas de corta vida.

Prototipado
Prototipado exploratorio: El objetivo es trabajar con clientes hasta evolucionar a un
sistema final, a partir de una especificacin inicial. Se debe comenzar con unas
especificaciones bien entendidas.
Prototipado de throw-away: El objetivo es entender los requerimientos del
sistema. Se puede comenzar con especificaciones poco entendidas.
Problemas y Riesgos de los Modelos
Cascada:
Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el
diseo.
Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida.
Prototipado:
Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el
diseo se llevan a cabo paso a paso.
Alto riesgo debido a falta de visibilidad.
Evolutivo: Alto riesgo debido a la necesidad de tecnologa avanzada y habilidades
del grupo desarrollador.
Manejo de Riesgos
La tarea principal del administrador consiste en minimizar riesgos. El riesgo
inherente en una actividad es se mide en base a la incertidumbre que presenta el
resultado de esa actividad. Las actividades con alto riesgo causan sobre-costes en
cuanto a planeacin y costos. El riesgo es proporcional al monto de la calidad de
la informacin disponible. Cuanto menos informacin, mayor el riesgo.
8.2.2 Modelo de proceso espiral

Fase del Modelo de Espiral

Planteamiento de Objetivos: Se identifican los objetivos especficos para cada fase
del proyecto.
Identificacin y reduccin de riesgos: Los riesgos clave se identifican y analizan, y
la informacin sirve para minimizar los riesgos.
Desarrollo y Validacin: Se elige un modelo apropiado para la siguiente fase del
desarrollo.
Planeacin: Se revisa el proyecto y se trazan planes para la siguiente ronda del
espiral.
Plantilla para una ronda de espiral

Objetivos.

Restricciones.

Alternativas.

Riesgos.

Resolucin de riesgos.

Resultados.

Planes.

Garantas (commitments).

Mejoramiento de la calidad del Modelo de Espiral

Objetivos:

Mejorar significativamente la calidad del software.

Restricciones:

Dentro de los 3 primeros aos.

Sin que se produzcan grandes inversiones de capital.

Sin que se lleven a cabo grandes cambios organizacionales.

Alternativas:

Reutilizar software certificado existente.

Introducir especificaciones formales y verificacin.

Invertir en herramientas de prueba y validacin.

Riesgos.

No existen mejoras en el software baratas.

Las mejoras en la calidad pueden incrementar costes excesivamente

Los nuevos mtodos pueden causar bajas en el personal.

Solucin de riesgos.

Estudio de la literatura existente. Proyecto piloto.

Bsqueda de todos los componentes reutilizables potenciales.

Identificacin del soporte disponible de herramientas

Entrenamiento al personal y seminarios motivacionales.

Resultados.

La experiencia en mtodos formales es limitada - es muy difcil cuantificar

las mejoras.

Limitado el soporte en herramientas para sistemas de desarrollo de la

compaa.

Existencia de componentes reutilizables, pero poco soporte de herramientas

de reso.
Planes.

Explorar la opcin de la reutilizacin a mas detalle.

Desarrollar herramientas prototipo para reutilizacin.

Explorar el esquema de certificacin de componentes.

Garantas.

Explorar los siguientes 18 meses.

9. Calidad de interfaz de software

Describe la manera de comunicarse el software dentro de s mismo, con sistemas
que interoperan dentro de l y con las personas que lo utilizan. Una
interfaz implica un flujo de informacin (por ejemplo, datos y/o control) y un tipo
especfico de comportamiento. Por lo tanto, los diagramas de flujo de control
y de datos proporcionan gran parte de la informacin que se requiere para
el diseo de la interfaz.

9.1. Normas
9.1.2 NORMA ISO 14915-3:2002

Proporciona recomendaciones y orientaciones paras el diseo, seleccin

y combinacin de interfaces de usuario interactivas que integran y
sincronizan diferentes medios. Contempla las interfaces de usuario empleadas en
aplicaciones que incorporan, integran y sincronizan medios diferentes,
incluidos medios estticos, tales como textos, grficos o imgenes, as
como dinmicos, es decir, audio, video, animacin o medios relacionados
con otros modos sensoriales. Los aspectos referentes al diseo detallado de un
nico medio (por ejemplo, el diseo grfico de una secuencia de animaciones)
solo se contemplan en cuanto puedan tener consecuencias ergonmicas para
el usuario.
Esta parte de la norma ISO 14915 se aplica a:

Tcnicas de presentacin para aplicaciones informticas multimedia en

general, incluyendo aplicaciones para usuarios individuales y en red,
cuyo principal objetivo es ayudar al usuario en su tarea o
suministrarle informacin
.
El diseo de usuario de la interfaz de usuario
La formacin y entrenamiento multimedia, en tanto que las
recomendaciones proporcionadas den lugar a una transmisin eficiente
de la informacin.

9.1.2 NORMA IEC TR 61997 CDV

Directrices para las interfaces de usuario en equipos multimedia para uso general
(2000) Da principios generales y orientacin diseo de tallado para la
seleccin de los medios de comunicacin, y para las interfaces de usuario
mecnicos, grficas y auditivas.

Interfaz de Hardware. Estas normas se pueden utilizar en el diseo y

evaluacin de los lugares de trabajo, pantallas, teclados
y otros dispositivos de
la mayora de estas
ISO 13406 contienen
oficinas. Estas normas

entrada. A diferencia de los estndares de software,

normas contienen requisitos explcitos. ISO 9241 e
requisitos para pantallas de visualizacin en las
pueden ser utilizados para apoyar la adhesin a la

normativa europea para el uso de pantallas de visualizacin (Bevan, 1991)

.Gestures para los sistemas basados en la pluma estn cubiertos en la
norma ISO / IEC 11064 14754.ISO contiene requisitos ergonmicos para el diseo
de los centros de control

9.2. Modelos
9.2.1 Modelo de Tareas
El modelo de tareas expresa cules son las tareas que va a realizar el usuario de
la aplicacin a travs de la interfaz de usuario. Las tareas se descomponen
en acciones atmicas que representan los paso
s necesarios para alcanzar los objetivos de la tarea. Dentro de los datos
capturados en este modelo tambin se recogen los requisitos no funcionales
de las tareas, como son por ejemplo los requisitos de tiempo de respuesta.
los conceptos de tarea y subtarea para un cuadro de dilogo para abrir un
fichero. Para la especificacin del modelo de tareas se han utilizado
distintas aproximaciones, entre las que destacan los mtodos textuales
basados en el anlisis cognitivo como GOMS (Goals, Operators, Methods,
Selection rules) o los mtodos basados en formalismos como
ConcurTaskTrees. Habitualmente la captura de los requisitos de las distintas
tareas que se realizarn con la interfaz de usuario suele realizarse utilizando
diagramas de casos de uso.
9.2.2 El Modelo de Dominio
El modelo de dominio incluye una visin de los objetos sobre los que
actan las tareas capturadas en el modelo de tareas. La especificacin del
modelo de dominio va muy ligada a las especificaciones realizadas
dentro del modelador del dominio de la parte funcional. Esto puede producir
una duplicidad de informacin con el consecuente peligro de aparicin de
incoherencias. En la figura 2.3 se muestran algunos de los objetos del
Estado Del Arte 40 dominio que sera necesario especificar para modelar un
tpico cuadro de dilogo para abrir un fichero.

10. Software para estimar calidad

10.1 PMD
Es un analizador esttico de cdigo que utiliza unos conjuntos de reglas
para identificar problemas dentro del software, ya sean posibles bugs, cdigo
muerto, duplicado, etc. La importancia de esta herramienta es que podemos
entregar un producto de calidad a nuestros clientes, ya que dentro de sus reglas
se encuentra incluido las buenas prcticas de programacin con Java
.
Caracterstica:
PMD escanea el cdigo fuente de Java y busca problemas potenciales como:

Posibles errores -/ finally vacas try / catch / interruptor

Cdigo Dead -variables locales no utilizados, parmetros y mtodos

privados

Cdigo subptima -Cadena derrochador / uso de StringBuffer

Expresiones overcomplicated - declaraciones innecesarias si, por lazos que
podran ser bucles while

Duplicar cdigo -copiar / pegar el cdigo significa copiados / insectos

Pegados

10.2 Check Style.

Checkstyle es una herramienta de desarrollo que ayudar a los
programadores a escribir cdigo Java para que se adhiera a un
estndar de codificacin.
Automatiza el proceso de comprobacin de cdigo Java. Esto lo hace ideal
para los proyectos a los que se desea aplicar un estndar de codificacin.
Checkstyle es altamente configurable y se puede hacer para apoyar casi cualquier
estndar de codificacin. De tal manera que se puedan suministrar
diferentes estndares de cdigo para su posterior comprobacin mediante la
herramienta.

Reglas del CheckStyle

El conjunto de reglas disponible es muy completo y est clasificado en los
siguientes grupos:
Comentarios Javadoc:
Facilita el mantenimiento pasa por comentar el cdigo, pero luego los
comentarios tambin hay que mantenerlos... CheckStyle tiene muchas reglas
para los javadoc y es muy flexible. Te permite, por ejemplo, obligar a comentar
los nombres de clases, todos los mtodos menos los get/set y los
atributos pblicos.
Convenciones de nombres:

puedes definir una expresin regular para el nombre de todo

Cabeceras: expresiones regulares para la cabecera de los ficheros
Imports :Reglas para los import, como no usar *, imports sin usar, etc
Violaciones de tamao: Define un mximo para el tamao de tus
clases,
mtodos, lneas y nmero de parmetros de un mtodo.
Espacios en blanco: un montn de reglas para definir donde se ponen espacios
en blanco y tabuladores en el cdigo.
Modificadores: establece un orden para los modificadores y evita
modificadores
innecesarios.
Bloques: reglas para los bloques de cdigo y sus llaves.
Problemas en la codificacin: Ac hay de todo, desde malas prcticas tipo
asignaciones internas y posibles fuentes de bugs como definir un mtodo
equals que no es el equals(Object), a cosas ms estticas o poco prolijas,
como que el default sea el ltimo elemento en un switch o parntesis
innecesarios.
Diseo de clases: varias reglas sobre el diseo de interfaces y clases, con
especial atencin en las excepciones.
Duplicados: te permite definir un mnimo de lneas para buscar cdigo
duplicado
en tus clases.
Mtricas: define

mximos

para

mtricas

como

complejidad

ciclomtica,

complejidad de expresiones lgicas, npath, lneas de cdigo seguidas

sin
comentar y dependencia de clases.
Miscelneo: variables final, indentacin, un buscador de expresiones
regulares y

varias cosas ms.

J2EE:reglas para EJBs.
Otros: internos a CheckStyle y activados por defecto.
Filtros: para eventos de auditoria del propio CheckStyle, no hace falta mirarlos

10.3 Google CodePro Analytix.

Herramientas de calidad software, ofrece un entorno para evaluacin de
cdigo, mtricas, anlisis de dependencias, cobertura de cdigo, generacin
de Test unitarios, etc. Mira las excepciones, refactorizaciones potenciales.
CodePro Analytix, herramienta de pruebas de software ms importante para
los desarrolladores de Eclipse que estn preocupados por la mejora de la calidad
del software y la reduccin de costos y horarios desarrollos.Las
caractersticas de auditora de software Java de la herramienta hacen que
sea un ayudante indispensable para el desarrollador en la reduccin de
errores como se est desarrollando el cdigo y mantener prcticas de
codificacin en lnea con las directrices de la organizacin. La capacidad de
hacer correcciones en el cdigo de inmediato puede reducir drsticamente los
costos de desarrollos y mejorar la velocidad de la entrega del producto
terminado. nete a las filas de los principales lderes de la industria de software
y las empresas de Fortune 500 que han estandarizado en tornoCodePro
Analytix como la herramienta con todas las funciones ms rentable de la
industria.
Caractersticas
Herramientas dinmicas, extensibles que permiten detectar, informar y reparacin
desviaciones o incumplimiento de las normas predefinidas de codificacin, marcos
populares, la seguridad y las convenciones de estilo.
Herramientas para medir e informar sobre los indicadores clave de calidad
automatizada en un cuerpo de cdigo fuente de Java

Eficientemente examina el cdigo de Java para encontrar segmentos duplicados o

muy similares de cdigo que contiene la copia / pegar o errores que puede
ser rediseado para mejorar el diseo de aplicaciones y facilidad de
mantenimiento

10.4 Kiuwan
Herramienta en Cloud (Saas) de anlisis de cdigo que permite medir la calidad y
la deuda tcnica del software entre otras cosas. Para Java, PHP,
Javascript, C#, COBOL, ABAP IV, VB.net, C/C++, Objective-C, Android, JSP,
Hibernate, SQL, PL/SQL. Cuadro de mando basado en la ISO 9126.

Caractersticas

Medir y analizar su software

Analice su software de forma segura en la nube
Soporte de aplicaciones multi idioma / tecnologa
Mtricas de cdigo
Anlisis de la duplicacin Cdigo
Indicadores Kiuwan Software
Lista de Defectos
Defectos muter
Deuda tcnica o esfuerzo para apuntar
Evolucin histrica
Analice su software de forma segura en la nube
Analice su software localmente
Medir y analizar su software
Listo para usar modelo de software
Personaliza tu modelo de software
Reutilice sus conjuntos de reglas OpenSource PMD, Checkstyle y FindBugs
Soporte de aplicaciones multi idioma / tecnologa
Indicadores Kiuwan Software
Integracin con el proceso de implementacin continua
Jenkins Plugin
API REST
Atlassian JIRA integracin

11. Cuadro comparativo de herramientas de software

PMD

Check Style.

PMD escanea el cdigo

fuente de Java y busca problemas
potenciales como:
Posibles errores -/ finally vacas try / catch / interruptor
Cdigo Dead -variables locales no utilizados, parmetros y
mtodos privados
Cdigo subptima -Cadena derrochador / uso de
StringBuffer
Expresiones overcomplicated -declaraciones innecesarias
si, por lazos que podran ser bucles while
Duplicar cdigo -copiar / pegar el cdigo significa copiados
/ insectos pegados

Agrupacin de reglas
Ahorro de tiempo/costes para atacar problemas
de calidad
concretos
Seguridad y fiabilidad en las interpretaciones
Facilitar la priorizacin y correccin (toma de decisiones)

Google CodePro
Analytix.

Kiuwan

Herramientas dinmicas, extensibles que permiten

detectar, informar y reparacin desviaciones o incump
limiento de las normas predefinidas de codificacin,
marcos populares, la seguridad y las convenciones de estilo

Medir y analizar su software

Analice su software de forma segura en la nube
Soporte de aplicaciones multi idioma / tecnologa
Mtricas de cdigo
Anlisis de la duplicacin Cdigo
Indicadores Kiuwan Software
Lista de Defectos
Defectos muter

Deuda tcnica o esfuerzo para apuntar

Evolucin histrica
Analice su software de forma segura en la nube
Analice su software localmente
Medir y analizar su software
Listo para usar modelo de software
Personaliza tu modelo de software

12. Conclusiones

Los requisitos son la base de la calidad.

Existen normas y protocolos de calidad regidas por diferentes
instituciones, dejando de lado la opinin del cliente, para que un
software
ser catalogado como producto de calidad es necesario cumplir
con las normas regidas y el gusto del usuario.
Con este taller de investigacin se pudo conocer la importancia de
implementar la gestin de calidad en el desarrollo de un proyecto para
evitar los problemas que normalmente se presentan y atrasan su desarrollo
o pierde el xito del software, siendo uno de los elementos que se deben
saber controlar.
Un producto como el software ser de calidad cuando siga la
metodologa propuestas por organizaciones dedicadas a la calidad de
software y el programa sea til en todos los aspectos de requerimientos
para el cliente.
La calidad es importante en un sistema por que se ponen los
recursos de las empresas

13. Bibliografa

http://dbcalidad.blogspot.com.co/2015/06/los-factores-criticos-de-exito.html

http://es.slideshare.net/tegsistemas/modelo-de-calidad-del-software

file:///C:/Users/Angy%20Alvarado/Downloads/cap1.pdf

file:///C:/Users/Angy%20Alvarado/Downloads/Medida%20del%20SW.pdf

http://issuu.com/myti/docs/my_primer_doc

file:///C:/Users/Angy%20Alvarado/Downloads/cap5.pdf

http://es.slideshare.net/albert317/calidad-del-producto-software

http://alarcos.esi.uclm.es/per/fruiz/cur/santander/mrodriguez-iso25000-update.pdf

http://www.infor.uva.es/~manso/calidad/trasmedicion1-intro-medida-2011.pdf

http://sg.com.mx/revista/40/midiendo-la-calidad-del-software#.Vg4DLPl_Oko

http://conaiisi.unsl.edu.ar/2013/62-438-1-DR.pdf

http://www.kmkey.com/software_gestion_calidad

http://www.sinap-sys.com/es/content/programas-informaticos-para-la-gestion-desistemas-calidad-medio-ambiente-y-prevencion-de-ri

http://www.guiadelacalidad.com/modelo-efqm/modelo-efqm