Está en la página 1de 40

Trabajo Investigativo No.

06
Ingeniera de Software

Presentado por:
Camilo Esteban Rodriguez
Andres Mauricio Clavijo
Brayan Andres Valero
Jhon Alexander Chacon

Presentado a:
Juan Carlos Guevara Bolaos

Universidad Distrital Francisco Jos de Caldas, Facultad Tecnolgica


Bogot D.C.
2016

Tabla de contenido
1. Introduccin ...................................................................................................... 4
2. Calidad.............................................................................................................. 4
2.1.

Definicin ................................................................................................... 4

2.2.

Importancia de calidad ............................................................................... 5

2.3.

Caractersticas ........................................................................................... 5

2.4.

Factores crticos de xito ........................................................................... 8

3. Modelos de calidad (Documentar 4 modelos)................................................... 8


3.1.1.

Nombre ................................................................................................... 9

3.1.2.

Descripcin ............................................................................................. 9

3.1.3.

Criterios................................................................................................... 9

3.2.1. Nombre .................................................................................................... 10


3.2.2. Caractersticas ......................................................................................... 10
3.2.3. Criterios.................................................................................................... 11
3.3.1. Nombre .................................................................................................... 11
3.3.3. Criterios.................................................................................................... 12
3.4.1. Nombre .................................................................................................... 12
3.4.2. Caractersticas ......................................................................................... 12
3.4.3. Criterios.................................................................................................... 13
4. Normas de calidad (Documentar 4 normas) ................................................... 14
4.1.1.

Nombre ................................................................................................. 14

4.1.2.

Descripcin ........................................................................................... 14

4.1.3.

Criterios................................................................................................. 14

4.2.1. Nombre .................................................................................................... 15


4.2.2. Caractersticas ........................................................................................ 15
4.2.3. Criterios.................................................................................................... 15
4.3.1. Nombre .................................................................................................... 15
4.3.2. Caractersticas ......................................................................................... 15
4.3.3. Criterios.................................................................................................... 16
5. Calidad de modelos conceptuales .................................................................. 17
5.1. Mtricas para modelos conceptuales tradicionales (documentar 2
mtricas) ............................................................................................................ 17
5.1.1.

Nombre ................................................................................................. 17

5.1.2.

Descripcin ........................................................................................... 17

5.2. Mtricas para modelos conceptuales orientados a objetos (documentar 2


mtricas) ............................................................................................................ 19
5.2.1.

Nombre ................................................................................................. 19

5.2.2.

Descripcin ........................................................................................... 19

6. Calidad del producto de software ................................................................... 21


6.1.

Normas (Documentar 2 normas) .............................................................. 21

6.1.1.

Nombre ................................................................................................. 21

6.1.2.

Descripcin ........................................................................................... 21

6.2.

Modelos (documentar 2 modelos) ............................................................ 22

6.2.1.

Nombre ................................................................................................. 22

6.2.2.

Descripcin ........................................................................................... 22

7. Calidad del proceso de software..................................................................... 23


7.1.

Normas (Documentar 2 normas) .............................................................. 23

7.1.1.

Nombre ................................................................................................. 23

7.1.2.

Descripcin ........................................................................................... 23

7.2.

Modelos (Documentar 2 modelos) ........................................................... 26

7.2.1.

Nombre ................................................................................................. 26

7.2.2.

Descripcin ........................................................................................... 26

8. Calidad de interfaz del software...................................................................... 27


8.1.

Normas (Documentar 2 normas) .............................................................. 27

8.1.1.

Nombre ................................................................................................. 27

8.1.2.

Descripcin ........................................................................................... 27

8.2.

Modelos (Documentar 2 modelos) ........................................................... 29

8.2.1.1.

Nombre.............................................................................................. 29

8.2.1.2.

Descripcin ........................................................................................ 29

8.2.2.1. Nombre ................................................................................................. 30


8.2.2.2. Descripcin ........................................................................................... 30
9. Software para estimar calidad (Documentar 4 herramientas de software que
permitan medir la calidad) ..................................................................................... 33
10.

Cuadro comparativo de herramientas de software ...................................... 37

11.

Conclusiones ............................................................................................... 38

12.

Bibliografa................................................................................................... 39

1. Introduccin
Se presenta 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.

2. Calidad
2.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

2.2.

Importancia de 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.

2.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.

2.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 las Cinco 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.

3. Modelos de calidad (Documentar 4 modelos)


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 ms populares e la comunidad, pero
sin sustento cientfico.

3.1.1. Nombre
Mccall

3.1.2. Descripcin
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.

3.1.3. Criterios
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.

3.2.1. Nombre
Modelo de Boehm

3.2.2. Caractersticas
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

3.2.3. Criterios
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:

3.3.1. Nombre
Modelo ISO
3.3.2. Caractersticas
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.

3.3.3. Criterios
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.

3.4.1. Nombre
Modelo EFQM

3.4.2. Caractersticas
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.

3.4.3. Criterios
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.

4. Normas de calidad (Documentar 4 normas)


4.1.1. Nombre
ISO

4.1.2. Descripcin
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.

4.1.3. Criterios
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.

4.2.1. Nombre
Estndar Spice

4.2.2. Caractersticas
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.

4.2.3. Criterios
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.

4.3.1. Nombre
Estndar CCM

4.3.2. Caractersticas
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.

4.3.3. Criterios
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.

5. Calidad de modelos conceptuales


5.1.

Mtricas para modelos conceptuales tradicionales (documentar 2


mtricas)
5.1.1. Nombre
Mtrica KESH

5.1.2. Descripcin
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.

5.2.

Mtricas para modelos conceptuales orientados a objetos


(documentar 2 mtricas)
5.2.1. Nombre
Mtrica de MOODY

5.2.2. Descripcin
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:
o Nmero de elementos del modelo de datos que no corresponden con
los requisitos de usuario.
o Nmero de elementos del modelo de datos que corresponden con los
requisitos de usuario, pero definidos incorrectamente.
o Nmero de requisitos del usuario no representados en el modelo.
o Nmero de inconsistencias con el modelo de procesos.

Integridad:
o Nmero de restricciones de integridad incluidas en el modelo que no
corresponden a polticas de negocio.
o Nmero de reglas del negocio que no se cumplen por el modelo de
datos.

Flexibilidad:
o Costes estimados de los cambios.
o Importancia estratgica de los cambios.
o Nmero de elementos del modelo que en el futuro estarn sometidos
a cambios.

Correccin:
o Nmero de violaciones a las formas normales.
o Nmero de violaciones a las convenciones de modelos de datos.

o Nmero de instancias de redundancias en el modelo.

Simplicidad:
o Nmero de entidades.
o Nmero de entidades y relaciones.
o Nmero de constructores.

Integracin:
o Nmero de conflictos con los sistemas existentes.
o Nmero de conflictos con el modelo de datos corporativo.
o Valoracin de los representantes de todas las reas del negocio.

Implementabilidad:
o Valoracin de riesgo tcnico.
o Valoracin de riesgo de planificacin.
o Estimacin del coste del desarrollo.
o Nmero de elementos fsicos del modelo de datos.

Comprensilidad:
o Valoracin de los usuarios sobre la comprensibilidad del modelo.
o Capacidad de los usuarios de interpretar el modelo correctamente.
o 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. Calidad del producto de software


6.1. Normas (Documentar 2 normas)
6.1.1. Nombre
Mtrica de ABRE y MELO

6.1.2. Descripcin
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. Modelos (documentar 2 modelos)


6.2.1. Nombre
Mtricas de CHINDAMBER y KEMERER

6.2.2. Descripcin
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 del proceso de software


7.1. Normas (Documentar 2 normas)
7.1.1. Nombre
SO/IEC 9126

7.1.2. Descripcin

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.2. Modelos (Documentar 2 modelos)


7.2.1. Nombre
ISO 14598

7.2.2. Descripcin
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.

8. Calidad de interfaz del software


8.1. Normas (Documentar 2 normas)
8.1.1. Nombre
ISO/IEC 90.003:2004

8.1.2. Descripcin
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 (Documentar 2 modelos)


8.2.1.1. Nombre
Modelo de cascada

8.2.1.2. Descripcin

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 sobrecostes en cuanto a planeacin y costos. El riesgo es proporcional al monto de la
calidad de la informacin disponible. Cuanta menos informacin, mayor el riesgo.
8.2.2.1. Nombre
Modelo de proceso espiral

8.2.2.2. Descripcin

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. Software para estimar calidad (Documentar 4


herramientas de software que permitan medir la calidad)
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

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
clases,

de

tamao: Define

un

mximo

para

mtodos, lneas y nmero de parmetros de un mtodo.

el

tamao

de

tus

Espacios en blanco: un montn de reglas para definir donde se ponen espacios


en blanco y tabuladores en el cdigo.
Modificadores: establece
modificadores

un

orden

para

los

modificadores

evita

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

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
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

10.
PMD

Cuadro comparativo de herramientas de software


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

Check Style.

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
decisiones)

de

Google
CodePro
Analytix.

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

Kiuwan

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

11.

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

12.

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-iso25000update.pdf
http://www.infor.uva.es/~manso/calidad/trasmedicion1-intro-medida2011.pdf
http://sg.com.mx/revista/40/midiendo-la-calidad-delsoftware#.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-lagestion-de-sistemas-calidad-medio-ambiente-y-prevencion-de-ri
http://www.guiadelacalidad.com/modelo-efqm/modelo-efqm

También podría gustarte