15
CUADRO COMPARATIVO NORMAS Y MODELOS PARA EVALUAR LA CALIDAD EN LOS PROCESOS DE DESARROLLO Y PRODUCTO FINAL DEL SOFWARE NURIS CELENA MONTERO SANTIAGO TUTOR: PAOLA ANDREA BACCA PACHON UNIVERSIDAD DE SANTANDER MAESTRIA GESTION DE LA TECNOLOGIA EDUCATIVA 2015

Nuris Montero Cuadrocomparativo Actividad.1.2

Embed Size (px)

DESCRIPTION

Cuadro comparativos modelos y estándares para evaluar la calidad de software

Citation preview

CUADRO COMPARATIVO NORMAS Y MODELOS PARA EVALUAR LA CALIDAD EN LOS PROCESOS DE DESARROLLO Y PRODUCTO FINAL DEL SOFWARE

NURIS CELENA MONTERO SANTIAGO

TUTOR:

PAOLA ANDREA BACCA PACHON

UNIVERSIDAD DE SANTANDER

MAESTRIA GESTION DE LA TECNOLOGIA EDUCATIVA

2015INTRODUCCION

El software como producto debe poseer atributos o cualidades que midan y lo categoricen con alto grado de calidad. Como tal es necesario que en el desarrollo o ciclo de vida del software se implementen estrategias o metodologas estndares que permitan detectar problemas desde su diseo, desarrollo, proceso y uso. Para obtener un Software de calidad se debe tomar en cuenta las Normas y Modelos que los Organismos Nacionales, Regionales E internacionales han formulado para este fin. En el presente trabajo se elaboraran unos cuadro comparativo donde se pretende mostrar un cuadro las principales caractersticas, la estructura de cada modelo, sus ventajas y desventajas. CUADRO COMPARATIVO NORMAS Y MODELOS PARA EVALUAR LA CALIDAD EN LOS PROCESOS DE DESARROLLO Y PRODUCTO FINAL DEL SOFWARE

ASPECTOCARACTERSTICASESTRUCTURA JERARQUICAVENTAJASDESVENTAJAS

Nivel 1Nivel 2Nivel3

Modelo McCall

Fue desarrollado en 1977 por Jim MacCall

McCall est organizado sobre tres tipos de caractersticas de calidad:

(Factores (especificar)

(Criterios (construir)

( Mtricas (controlar)

Este modelo organiza 11 factores en tres ejes o puntos de vista :

Operacin, Transicin y Revisin. A travs de ellos el usuario puede contemplar la calidad de un producto. Cada factor tiene asociado sus respectivos criterios o mtricas.El modelo refleja perspectivas del desarrollador y del usuario, adems presenta una estructura jerrquica para organizar los factores.EJE DE OPERACIONFACTORESCRITERIOSMETRICASEst orientado al producto final pero se puede aplicar al proceso.Este Modelo crea un puente entre el desarrollador y el usuario.

Por su estructura jerrquica, se puede observar que es prctico, fcil de entender y fcil de aplicar.

Los criterios se calculan a travs de preguntas dicotmicas del tipo SI-NO, las cuales son contestadas por una o varias personas, lo cual podra implicar subjetividad dado que cada una puede evaluar la calidad de forma diferente.

Facilidad de usoFacilidad de aprendizaje.

IntegridadControl de accesos.

Facilidad de auditora.

Seguridad.

CorreccinCompletitud.

Consistencia.

Trazabilidad o rastreabilidad.

FiabilidadPrecisin.

Consistencia

Tolerancia a fallos.

Modularidad.

EficienciaEficiencia en ejecucin.

Eficiencia en almacenamiento.

ASPECTOCARACTERSTICASESTRUCTURA JERARQUICAVENTAJASDESVENTAJAS

Nivel 1Nivel 2Nivel3

Modelo McCall

Fue desarrollado en 1977 por Jim MacCall

Satisface las necesidades tanto de los desarrolladores como las del usuario.

Se focaliza en el producto final, identificando atributos claves

desde el punto de vista del usuarioUtiliza criterios de calidad en los relaciona atributos internos y externos.

Cada Criterio tiene varias mtricas o atributos que en si son los que permiten medir la calidad.

EJE DE REVISIONFACTORESCRITERIOSMETRICASSu aplicacin resulta viable por sus bajos costos.

Se podra utilizar no para uno sino para varios proyectos.

En este Modelo se evalan muchos factores lo que implicara un trabajo adicional al proceso de desarrollo que denota tiempo y costo.

Facilidad de Mantenimiento

Modularidad

Simplicidad

Consistencia

Concisin.

Auto descripcin.

Facilidad de pruebaModularidad

Simplicidad

Auto descripcin

Instrumentacin.

FlexibilidadAuto descripcin

Capacidad de expansin.

Generalidad.

Modularidad

ASPECTOCARACTERSTICASESTRUCTURA JERARQUICAVENTAJASDESVENTAJAS

Nivel 1Nivel 2Nivel3

Modelo McCall

Fue desarrollado en 1977 por Jim MacCall

Presenta un nivel ms para descomponer y mapear cada

criterio de calidad en un conjunto de mtricas de calidad que son

atributos (tanto del producto como del proceso) de muy bajo

nivel, medibles directamente.la medicin de cualquiera de estos factores est definida en este modelo en base a 41 mtricas para cada criterio existe una lista de condiciones que se deben cumplir en distintas etapas: requerimientos (R), diseo (D),

implementacin (I).EJE DE REVISIONFACTORESCRITERIOSMETRICASEs difcil que las caractersticas y subcaractersti-cas sean siempre

perfectamente independientesImplicara un trabajo tedioso por la cantidad de mtricas que se utilizaran.

Facilidad de reutilizacinAuto descripcin

Generalidad

Modularidad

Independencia entre Sistema y Software.

Independencia del Hardware.

Interoperabili-dadModularidad

Compatibilidad de comunicaciones.

Compatibilidad de datos.

Estandarizacin en los datos.

PortabilidadAuto descripcin

Modularidad

Independencia entre Sistema y Software

Independencia del Hardware.

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

ALTO NIVEL O USOS PRIMARIOSNIVEL O CONSTRUCTORES INTERMEDIONIVEL BAJO O CONSTRUCT. PRIMITIVOSCRITERIOS O METRICAS

Modelo Boehmcreado por Barry Boehm en 1978.Se conoce como modelo espiral. Presenta una jerarqua de caractersticas que sirven para medir la calidad del producto software:

Caractersticas de alto nivel: representan requisitos generales de uso o usos primarios. (Caractersticas de nivel intermedio: representan los factores de calidad de Bohem. (Caractersticas primitivas: nivel ms bajo que corresponde a caractersticas Directa- mente asociadas a uno o ms mtricas de calidad.

Tiene similitudes con el modelo McCall, porque muchos de sus factores de calidad son los mismos. Utilidad Per-se

Cun usable, confiable y eficiente es el producto en si mismo.ConfiabilidadAutocontencinConsidera explcitamente los riesgos.Al gestionar los riesgos, se reducen los problemas en el proyecto y el costo del mismo.

Permite especificar alternativas para lograr los objetivos.Es adaptable a desarrollo de todo tipo.

Permite una mezcla con las metodologas de prototipos, cascada e incremental.

Requiere de una considerable habilidad y experiencia para la evaluacin de riesgos.Si no se detectan los riesgos a tiempo surgirn dificultades.

Debido a su complejidad no es aconsejable su uso en sistemas pequeos.

Limita la reusabilidad.

Exactitud

Completitud

Consistencia

Integridad

EficienciaAccesibilidad

Eficiencia de uso de dispositivos

UsabilidadIntegridad

Accesibilidad

Comunicacin

MantenibilidadCuan fcil es modificarlo, entenderlo y retestearlo.TesteabilidadComunicacin

Autodescripcin

Estructuracin

FlexibilidadEstructuracin

Aumentabilidad

Utilidad generalSi puede seguirse usando si se cambia de ambientePortabilidadIndependencia de los dispositivos

Autocontencin

Facilidad de entendimientoConsistencia

Estructuracin

Concisidad

Legibilidad

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

TIPOS DE REQUERIMIENTOSATRIBUTOS O REQUISITOSCRITERIOS O METRICAS

Modelo

FURPScreado por Hewlett-Packard, 1987.Este Modelo desarroll una serie de factores de calidad que reciben el acrnimo de FURPS.

Incluye cinco (5) categoras principales las cuales se derivan de su nombres en ingls: -Funcionalidad (Functionality),

-Usabilidad (Usability), -Confiabilidad (Reliability),-Desempeo (Performance) -Soportabilidad (Supportability).

FUNCIONALESFFuncionalidadCaractersticas y capacidades del ProgramaSe puede utilizar en varios proyectos.

Tiene en cuenta las fallas en el producto y en el proceso, este control permite correcciones.Se requieren de Muchas mtricas para la evaluacin del producto.No tiene en cuenta la portabilidad de los productos de Software.

Generalidades de las funciones

Seguridad

NO FUNCIONALESUUsabilidadFactores humanos

Estticos

Consistencia de la Interfaz

Ayuda en lnea

Asistentes

Documentacin del usuario

RConfiabilidadFrecuencia y severidad de fallas.

Recuperacin a fallos

Exactitud de las salidas

Tiempo entre fallos.

Capacidad de Prediccin.

PDesempeoVelocidad

Eficacia

Consumo de recurso

Tiempo de respuesta

Rendimiento efectivo total.

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

TIPOS DE REQUERIMIENTOSATRIBUTOS O REQUISITOSCRITERIOS O METRICAS

Modelo

FURPSCreado por Hewlett-Packard, 1987.El modelo FURPS incluye, adems de los factores de calidad y los atributos, restricciones de diseo y requerimientos de implementacin, fsicos y de interfaz..

Tiene un enfoque industrial.

Plantea dos categoras de requerimientos:

-Requerimientos Funcio-

nales (F)

-Requerimientos No

Funcionales (URPS).

A cada uno de ellos NO FUNCIONALESPDesempeoUtilizacin de RecursosSe utiliza para establecer mtricas de la calidad para todas las actividades del proceso de desarrollo de un software, inclusive de un sistema de informacin.

Se establecen restricciones en el diseo y los requerimientos de implementacin, fsicos y de interfaz

SSoporteRequisito de Instalacin

Requisito de Configuracin.

Requisito de Adaptabilidad

Requisito de Compatibilidad.

+ImplementacinLimitacion de recurso

Lenguajes

Herramientas, Hardware.

InterfazRestricciones para interaccin con sistemas externos.

OperacionesGestin del Sistema

Pautas administrativas

Puesta en Marcha

EmpaquetamientoForma de distribucin

LegalesLicencias

Derecho de autor

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

FACTORESCRITERIOS METRICAS

Modelo

ARTHURCreado por Arthur Andersen, 1985.Este Modelo de calidad creado por Arthur Andersen, presenta una variante del modelo de calidad propuesto por McCall.

Arthur, para diferenciarlo del McCall, aade tres nuevos criterios de valoracin: Complejidad, Seguridad, Auditabilidad

CorreccinCompletitudPosee un Valor agregado ya que incorpora un factor de calidad que muchos modelos no presentan: Correccin.

Presenta demasiados criterios por lo cual se deber utilizar una gran cantidad de mtricas para verificar la calidad del producto o proceso de Software.

Consistencia

Seguimiento

FiabilidadComplejidad

Consistencia

Modularidad

Preciso

simplicidad

Tolerante a errores

EficienciaConcisin

Eficiencia de Ejecucin

Operatividad

IntegridadAuditabilidad

Instrumentacin

Seguridad

UtilizableEntretenimiento

Operatividad

MantenibleAuto-documentado

Concisin

Consistencia

Instrumentacin

Modularidad

Simplicidad

FlexibleAuto-documentado

Complejidad

Concisin

Consistencia

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

FACTORESCRITERIOS METRICAS

Modelo

ARTHURCreado por Arthur Andersen, 1985.Este Modelo introduce una variacin entre

las relaciones de los factores y los criterios.Presenta como factor de calidad la Correccin y criterios que denotan un seguimiento que conlleva a procesos de calidad.

VerificableAuditabilidadEl Criterio de Auditabilidad, genera un alto grado de confiabilidad ante posibles riesgos.

Debido al uso de muchas mtricas para medir la calidad, se requiere de mucho esfuerzo y un alto costo econmico.

Auto-documentado

Complejidad

Instrumentacin

Modularidad

Simplicidad

PortableAuto-documentado

Generalidad

Independencia de la mquina

Independencia del sistema software

Modularidad

ReutilizableAuto-documentado

Generalidad

Independencia del hardware

Independencia del sistema software

Modularidad

Inter-operableComunicaciones comunes

Datos comunes

Generalidad

Modularidad

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

CARACTERISTICAS INTERNAS Y EXTERNASCRITERIOS METRICAS

Estndar

ISO 9126Primer versin

1992

Es reemplazado en el 2001 por

ISO 9126:1.

Es Actualizada en el 2005 con una nueva versin

ISO/IEC 25000Es un estndar internacional para la evaluacin del Software, est supervisado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos.

Propone un modelo de calidad que se divide en tres vistas:interior,exteriorydeuso.Estas estncompuestas por caractersticas, las que se dividen en sub caractersticas, y estas a su vez se componen deatributo.

Se divide en:

ISO 9126-1 Modelo de calidad (ISO/IEC, 2001).ISO 9126-2 Mtricas externas (Mide el software ens mismo)ISO 9126-3 Mtricas de internas (mide elcomportamiento del sistema)ISO 9126-4 Calidad en el usode mtricas (mide el efecto de usarel software en un contexto especfico).Funcionalidad.

Adecuacin.Es un Modelo que puede ser usado en cualquier parte porque es de mbito internacional.

Al ser norma de aplicacin internacional siempre est actualizada.

Es aplicada al producto y al proceso.

.

Presenta una superposicin de conceptos, al definir usabilidad (Facilidad de uso) como una caracterstica de calidad internaexterna, y llamar calidad en uso a otras caractersticas tambin vinculadas a la usabilidad.

Exactitud.

Interoperabilidad.Seguridad.

Cumplimiento de normas.

ConfiabilidadMadurez.

Tolerante a defectos.

Facilidad de recuperacin.

Facilidad de uso.

Fcil de comprender.

Fcil de aprender.

Fcil de operar.

Atractividad.

Eficiencia.

Comportamiento en el tiempo.

Comportamiento de recursos.

Facilidad de mantenimiento.Fcil de comprender.

Fcil de aprender.

Fcil de operar.

Atractividad. .

Portabilidad

Facilidad de instalacin.

Facilidad de reemplazo.

Adaptabilidad

ASPECTOCARACTERSTICASESTRUCTURA DEL MODELOVENTAJASDESVENTAJAS

CARACTERISTICAS CALIDAD DE USO METRICAS

FACTORESDESCRIPCION

Estndar

ISO 9126Primer versin

1992

Es reemplazado en el 2001 por

ISO 9126:1.

Es Actualizada en el 2005 con una nueva versin

ISO/IEC 25000.La mantenibilidad es una de las caractersticas ms importantes de la calidad de un producto software, quiz sea la parte ms famosa de la norma ISO 9126 / ISO 25000. Atributo intrnsecamente asociado con el proceso de mantenimiento, y que representa la mayor parte de los costes en el Ciclo de Vida Software.

EficienciaCapacidad de ayudar al usuario a cumplir sus objetivos con exactitud y completitud en un contexto de uso dado. Este Estndar implementa la calidad en el uso, por lo cual se obtiene informacin de parte del usuario que facilita generar procesos de mejoramientos en la calidad del software.Posee muchas mtricas por lo cual, requiere tiempo, trabajo y costos.

ProductividadCapacidad de ayudar al usuario a emplear una cantidad apropiada de recursos para obtener sus resultados

SeguridadCapacidad de alcanzar niveles aceptables de riesgo para las personas, el ambiente de trabajo y la actividad, en un contexto de uso dado

SatisfaccinCapacidad de satisfacer a un usuario en un contexto de uso dado

CONCLUSIONESToda organizacin automatiza tareas a travs de la implementacin de Sistemas de Informacin, por esta razn adquirir un software es un requisito fundamental para el desarrollo organizacional. Teniendo en cuenta este fundamento administrativo se debe preveer obtener un producto de software que cumpla con las condiciones de calidad.Para poder evaluar la calidad del software debe tener en cuenta que existen una variedad de Modelos y Estndares que permiten medir la calidad a travs de atributos que son evidenciados a travs no solo de su uso sino a travs de los resultados que se obtienen a travs del procesamiento de la informacin. Por eso debe determinar qu Modelo o Estndar utilizar segn los objetivos que se pretendan alcanzar.

Lo ms recomendable analizar y comparar cada uno de los modelos y estndares, para poder efectuar una correcta eleccin del Modelo y/o Estndar de Calidad del Software a aplicar, determinar que beneficios ofrece a nivel proceso, a nivel de resultado. Slo as se puede desarrollar una evaluacin eficiente que permita de la futura implantacin teniendo en cuenta un contexto integral: recursos humanos, materiales, tiempos y costos.

BIBLIOGRAFIACalidad del Software: camino hacia una verdadera industria del software.Revista de la Escuela Administracin de Negocios, 38, 38-57. Rojas, S., & Borja, J. (1999). Recuperado el 10 de Febrero de 2015, de: http://aulavirtual.eaie.cvudes.edu.co/publico/lems/L.000.008.MG/Documentos/Anexos/Cap1/1.pdfEl Modelo de Capacidad de Madurez y su Aplicacin en Empresas Mexicana de Software.Puebla: Universidad de las Amricas Puebla. p (10-18, 68-75). Garca Romero, C. (2001). Recuperado el 12 de Febrero de 2015 de;

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/garcia_r_ci/capitulo_2.html.Introduccin a la Calidad del Software.Scientia et Technica(39), 326-331.ISSN 0122-1701. Lpez, A., Cabrera, C., & Valencia, L. (2008). Recuperado el 15 de febrero de 2012, de http://aulavirtual.eaie.cvudes.edu.co/publico/lems/L.000.008.MG/Documentos/Anexos/Cap1/2.pdfMedinatic. (14 de 02 de 2013). http://medinatic.scoom.com. Recuperado el 11 de Febrero de 2015, dehttp://medinatic.scoom.com/2013/02/14/cuadro-comparativo-sobre-normas-y-estandares-de-calidad/Piedrahita Mesa, Sebastin. Construccin de una herramienta para evaluar la calidad de un producto software. Recuperado el 18 de febrero de 2.015 de: https://repository.eafit.edu.co/handle/10784/2431.