Nuris Montero Cuadrocomparativo Actividad.1.2
-
Upload
nuris-montero -
Category
Documents
-
view
209 -
download
21
description
Transcript of Nuris Montero Cuadrocomparativo Actividad.1.2
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.