Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

El modelo de mccall como aplicación de la calidad a la revision del software de gestion empresarial




Enviado por angel.cervera



     

    1.
    Resumen

    2.
    Abstract


    4. Calidad:
    definiciones.

    5. Calidad del
    software.

    6. La calidad a través de la
    normalización en la ingeniería del software y su
    problemática.

    7. Los modelos de calidad del software de
    gestión.

    8. El modelo de
    McCall.

    9. Cómo emplear el modelo de
    mccall.

    10.
    Conclusiones
    .
    11. Bibliografia.

    1.
    Resumen

    La mayor importancia de las nuevas tecnologías de
    la información y su creciente presencia en los
    diversos ámbitos de la industria
    moderna (robots, centros de control, etc.) y
    sus productos
    finales (aviación, automóviles,
    electrodomésticos, telefonía, etc.) conlleva cada
    vez más la presencia de programas
    informáticos que gobiernan muchas de sus prestaciones,
    o bien como herramientas
    que el cliente
    empleará en su propio beneficio. Basta con observar la
    frenética actividad que ha supuesto para la industria, las
    empresas de
    servicios y la
    Administración el enfrentarse al tan temido
    "efecto 2000", así como el gasto que ha conllevado la
    revisión y modificación de los programas, para
    vislumbrar la punta de un iceberg: la falta de un control
    riguroso y sistemático de la calidad del software de
    gestión. En el presente trabajo se aborda
    este tema y se presenta un modelo de aplicación que
    ayudaría a proveedores y
    clientes desde el
    comienzo del diseño
    de una aplicación específica de software para su
    negocio o actividad.

    Palabras Claves: calidad, hardware, modelo de McCall,
    software.

    2. Abstract

    The major importance of new information technologies and
    their increasing presence in the various scopes of modern
    industry (robots, control centres, etc.) together with their end
    products (aviation, automobiles, household appliances, telephony,
    etc.) is increasingly leading to a greater presence of computer
    programs either for controlling many of its features, or as tools
    that the client will use in his own benefit. You only need to
    observe the frenetic activity that facing the fearful Y2K effect
    has supposed for industry, service companies and Administration
    as well as the expenses brought forth by the revision and
    modification of programs, in order to catch a glimpse of the tip
    of the iceberg: the lack of a rigorous and systematic control of
    the quality of management software. In the present work this
    subject is approached and an application model is depicted that
    would help suppliers and clients from the very first stages of
    the design of a specific software application for their business
    or activity.

    Keywords: Quality, hardware, McCall´s model,
    software.

    3. Algunos antecedentes
    al
    concepto de
    calidad.

    A lo largo de toda la historia la búsqueda
    y el afán de perfección por parte del hombre ha sido
    constante, de tal forma, que el interés
    por el trabajo
    bien hecho y la necesidad de asumir responsabilidades sobre la
    labor efectuada poco a poco derivó en el concepto de
    calidad.

    Un ejemplo temprano se encuentra entre los 2000 y 3000
    años A.C. cuando los faraones egipcios mandaron construir
    las famosas pirámides de Egipto. Muchas
    de ellas tienen parámetros que las acercan casi a la
    perfección en la construcción pues en la orientación
    de la base con respecto a la alineación N-S, E-W el error
    máximo llega a ser de 6 minutos de arco, distando la base
    de algunas de ellas de ser un cuadrado perfecto menos de 17,78
    cm. Todo ello se conseguía gracias a los métodos de
    inspección empleados durante su
    construcción.

    Mucho más tarde, ya entrada la edad media
    surgió en Europa el
    sistema de
    organización en gremios. Estos
    imponían los precios y
    especificaciones de los distintos productos de los que
    proveían a la sociedad. Los
    productos de calidad daban prestigio al artesano, así como
    al gremio de la zona cuando todos sus artesanos seguían
    sus especificaciones. Este hecho constituye una de las primeras
    pruebas de un
    organismo que se encarga tanto de fijar unas normas
    básicas, como de controlar su cumplimiento.

    Con la revolución
    industrial comienza a desaparecer el artesanado, se crean
    grandes organizaciones y
    los antiguos artesanos se transforman en los trabajadores de las
    empresas. En esta época Taylor
    elaboró su teoría
    acerca de la "gestión científica del trabajo", cuyo
    objeto fue la preparación de normas para que los
    trabajadores las cumpliesen. Comenzó con ello la
    instauración paulatina de la división del trabajo,
    lo que suponía que los operarios interviniesen solamente
    en algunas operaciones del
    proceso
    productivo. Este hecho provocó la necesidad de que
    surgiese la figura de los empleados dedicados a tareas de
    inspección, aunque se prestaba más atención
    a la forma de realizar el trabajo (los procesos) que
    a la calidad de los productos.

    Finalmente el control de
    calidad moderno o control de calidad estadístico
    comenzó en los años 30 del siglo XX con la
    aplicación industrial del cuadro de control ideado por el
    Dr. W. A. Shewhart, de Bell Laboratories, que fue el inventor de
    los conocidos gráficos de control.

    Continuando en este proceso cronológico destaca
    el hecho de que pasados unos años del final de la II
    Guerra Mundial
    los japoneses comienzan a hacer verdadero énfasis en la
    calidad. En 1950 la Unión de Científicos e
    Ingenieros Japoneses realizó un seminario cuyo
    conferenciante, el Dr. W.E. Deming,
    desarrolló los siguientes temas: Cómo mejorar la
    calidad mediante el ciclo de planear, hacer, verificar y actuar;
    La importancia de captar la dispersión en las estadísticas; Control de procesos mediante
    el empleo de
    cuadros de control y su aplicación.

    Cuatro años más tarde el Dr. J.M. Juran
    introdujo en Japón la idea de que la calidad de un
    producto o
    servicio
    residía en el grado de mentalización de todo el
    personal de
    la
    organización e impartió seminarios a los mandos
    altos y medios de las
    empresas niponas, explicándoles las funciones que les
    correspondían a cada uno en la promoción del control de
    calidad.

    La visita de Juran marcó una transición en
    las actividades de control de calidad y creó un ambiente en
    que se reconoció el Control de Calidad como un instrumento
    de gerencia
    abriendose las puertas para el establecimiento del control total
    de calidad tal como se concibe hoy.

    4. Calidad:
    definiciones.

    Una vez revisados los antecedentes del concepto calidad
    para concretar su significado se van a reproducir tres
    definiciones de calidad emanadas de personas y entidades de
    reconocido prestigio:

    • "Conjunto de esfuerzos efectivos de los diferentes
      grupos de una
      organización para la integración del desarrollo,
      del mantenimiento y de la superación de la
      calidad de un producto, con el fin de hacer posible la
      fabricación y servicio a satisfacción completa
      del consumidor y
      al nivel más económico" [Feigenbaun, Deming y
      Juran]
    • "La mejor calidad que una empresa puede
      producir con su tecnología de producción y capacidades de proceso
      actuales, y que satisfará las necesidades de los
      clientes, en función de factores tales como el coste y
      el uso previsto" [Dr. Kaoru Ishikawa]
    • " La gestión de calidad en la empresa es
      el proceso de identificar, aceptar, satisfacer y superar
      constantemente las expectativas y necesidades de todos los
      colectivos humanos relacionados con ella, clientes, empleados,
      directivos, propietarios, proveedores y la comunidad con
      respecto a los productos y servicios que esta proporciona"
      [consultora Arthur Andersen]

    De todas estas definiciones se extraen una serie de
    parámetros básicos que definen la calidad: si se
    desea producir productos y servicios de buena calidad para el
    consumidor será necesario decidir por adelantado que
    calidad de producto (o servicio) planificar (calidad de
    diseño), producir (calidad de fabricación) y vender
    (calidad que desea el cliente).

    5. Calidad del
    software.

    A la hora de definir la calidad del software se debe
    diferenciar entre la calidad del producto software y la calidad
    del proceso de desarrollo de éste (calidad de
    diseño y fabricación). No obstante, las metas que
    se establezcan para la calidad del producto van a determinar los
    objetivos a
    establecer de calidad del proceso de desarrollo, ya que la
    calidad del primero va a depender, entre otros aspectos, de
    ésta. Sin un buen proceso de desarrollo es casi imposible
    obtener un buen producto. Este proceso constituye el objeto del
    presente trabajo.

    Pero la calidad del producto software se diferencia de
    la calidad de otros productos de fabricación industrial,
    ya que el software tiene sus propias características
    específicas:

    • El software es un producto mental, no restringido por
      las leyes de la
      Física o
      por los límites de los procesos de fabricación.
      Es algo abstracto, un intangible.
    • Se desarrolla, no se fabrica. El coste está
      fundamentalmente en el proceso de diseño, no en la
      posterior producción en serie, y los errores se
      introducen también en el diseño, no en la
      producción.
    • Los costes del desarrollo de software se concentran
      en las tareas de Ingeniería, mientras que en la
      fabricación clásica los costes se acentúan
      más en las tareas de producción.
    • El software no se deteriora con el tiempo. No es
      susceptible de los efectos del entorno y su curva de fallos es
      muy diferente de la del hardware. Todos los problemas
      que surjan durante el mantenimiento estaban allí desde
      el principio y afectan a todas las copias del mismo; no se
      generan nuevos errores.
    • Es artesanal en gran medida. El software, en su
      mayoría, se construye a medida, en vez de ser construido
      ensamblando componentes existentes y ya probados, lo que
      dificulta aún más el control de su
      calidad.
    • El mantenimiento del software es mucho más
      complejo que el mantenimiento del hardware. Cuando un
      componente del hardware se deteriora se sustituye por una pieza
      de repuesto, pero cada fallo en el software implica un error en
      el diseño o en el proceso mediante el cual se tradujo el
      diseño en código máquina
      ejecutable.
    • Es engañosamente fácil realizar cambios
      sobre un producto software, pero los efectos de estos cambios
      se pueden propagar de forma explosiva e
      incontrolada.
    • Como disciplina,
      el desarrollo de software es aún muy joven, por lo que
      las técnicas de las que dispone aún no
      están perfeccionadas.
    • El software con errores no se rechaza. Se asume que
      es inevitable que el software presente algunos errores de poca
      importancia.

    También es importante destacar que la calidad de
    un producto software debe ser considerada en todos sus estados de
    evolución (especificaciones, diseño,
    códigos,…). No basta con verificar la calidad del
    producto una vez finalizado cuando los problemas de mala calidad
    ya no tienen solución o su reparación es muy
    costosa.

    La problemática general a la que se enfrenta el
    software es:

    • Aumento constante del tamaño y complejidad de
      los programas.
    • Carácter dinámico e iterativo a lo
      largo de su ciclo de
      vida, es decir que los programas de software a lo largo de
      su vida cambian o evolucionan de una versión a otra para
      mejorar las prestaciones con respecto a las
      anteriores.
    • Dificultad de conseguir productos totalmente
      depurados, ya que en ningún caso un programa
      será perfecto.
    • Se dedican elevados recursos
      monetarios a su mantenimiento, debido a la dificultad que los
      proyectos de
      software entrañan y a la no normalización a la hora de realizar los
      proyectos.
    • No suelen estar terminados en los plazos previstos,
      ni con los costes estipulados, ni cumpliendo los niveles
      deseables de los requisitos especificados por el
      usuario.
    • Incrementos constantes de los costes de desarrollo
      debido entre otros, a unos niveles de productividad
      bajos.
    • Los clientes tienen una alta dependencia de sus
      proveedores por ser en muchos casos aplicaciones a
      "medida".
    • Procesos artesanales de producción con escasez
      de herramientas.
    • Insuficientes procedimientos
      normalizados para estipular y evaluar la productividad, costes,
      y calidad.

    Todo lo anterior puede concretarse en:

    • Ausencia de especificaciones completas, coherentes y
      precisas previas por parte del cliente, así como
      posteriores por parte de los proveedores del
      software.
    • Ausencia de la aplicación sistemática
      de métodos, procedimientos y normas de ingeniería
      del software.
    • Escasez o ausencia de entornos integrados de programación.
    • Escasez de uso de técnicas actuales y
      automatizadas para la gestión de proyectos.
    • Escasez de personal con formación y
      experiencia en los nuevos métodos, normas y uso de
      entornos y utilidades de programación.
    • Otros derivados del grado de desarrollo
      técnico y organizativo de cada
      compañía.

    6. La calidad a
    través de la normalización en la ingeniería
    del software y su problemática.

    La normalización consiste en un proceso donde se
    elaboran guías, normas y convenciones sobre una
    determinada materia, con
    el objeto de definir, simplificar y especificar las actividades
    relacionadas con la materia de que se trate.

    La Ingeniería del Software (IS) se ha ido
    desarrollando en los últimos 15 años, a
    través de la creación e implantación en la
    industria software de métodos, procedimientos,
    técnicas y útiles que tratan de cubrir las
    necesidades de cada una de las etapas del ciclo de vida de un
    producto software, desde la definición de sus requisitos
    hasta su mantenimiento una vez el producto comience a emplearse.
    Y ello con las restricciones generales de todos los procesos
    modernos de ingeniería, esto es, la necesidad creciente de
    incrementar la productividad de la programación mejorando
    y garantizando, simultáneamente la calidad del producto
    resultante.

    La creación e implantación de normas de
    desarrollo del software son un autentico desafío que tiene
    la IS como medio de comunicación para transferir sus
    métodos, técnicas y procedimientos a la industria
    del software para el diseño y desarrollo de nuevos
    productos. Estas normas tienen como criterio general de
    desarrollo maximizar la
    comunicación entre los profesionales del software a
    través de la definición de documentos
    generales que se han de producir, proveyendo de guías que
    indican a nivel de detalle el contenido de dichos documentos y
    recomendaciones de las actividades que hay que realizar durante
    todo el proceso de producción del software. En pocas
    palabras, las normas de IS son la solución a una de las
    mayores necesidades de la industria del software actual: la
    comunicación mas adecuada y precisa entre sus
    profesionales.

    A medida que ha ido aumentando la necesidad de un
    software más fiable, se ha reconocido que las normas de
    ingeniería del software (NIS) son una contribución
    fundamental para asegurar la producción de software de
    calidad. Además una consecuencia del objetivo
    genérico de mejorar la comunicación es que se
    reducen los costes por un aumento de productividad y una mejora
    de la calidad de los desarrollos de software.

    En relación a las normas los profesionales se
    encuentran con un problema fundamental: la dispersión de
    las normas relativas a1 software que, con frecuencia, han sido
    creadas por organismos muy diversos, bajo enfoques distintos y
    destinadas a ámbitos de actuación diferentes.
    Muchas compañías, por su parte, se han visto
    obligadas a generar sus propias normas cuando no disponen de unas
    de ámbito general. De hecho muchas organizaciones
    desarrollan sus propios conjuntos de
    normas adecuándolas a sus fines específicos. Pero
    también se dan casos en que organizaciones distintas
    tienen los mismos objetivos por lo que resultaría
    razonable su colaboración y, en todo caso, la adopción
    de las normas de la organización que tenga más
    avanzados sus desarrollos y un ámbito de actuación
    más amplio. Puede afirmarse que en la actualidad se ha
    llegado a un nivel de madurez en la industria del software que ha
    permitido a todos 1os implicados que exista un interés por
    aunar sus experiencias y esfuerzos para crear normas generales
    que abarquen sus áreas de interés.

    Estos esfuerzos varían en cuanto al tipo de
    industrias o
    usuarios así como en lo relativo a los logros alcanzados,
    pero la tendencia actual es hacia la normalización de1
    proceso de desarrollo software a través de normas que
    conduzcan a homogeneizar los planes de garantía de calidad
    de él, los planes de gestión de la
    configuración del software, la documentación de sus
    pruebas, etc.

    De hecho en EEUU existen varias entidades
    públicas y privadas que publican normas en diversos
    aspectos del software entre las que destacan: el American
    Institute of Aeronautics and Astronautics (AIAA), la American
    Nuclear Society (ANS), la American Society of Quality Control
    (ASQC), la Data Processing Management Association (DPMA) y la
    Electronic Industries Association (EIA).

    Sin embargo las actividades de normalización en
    IS son relativamente recientes, siendo tres las instituciones
    de mayor prestigio y difusión que las generan: el
    Instituto de Ingenieros Eléctricos y Electrónicos
    de los EE.UU. (IEEE) a través del Subcomité de
    Normas de IS de la Computer Society, el National Bureau of
    Standards (NBS) que publica las normas FIPS (Federal Information
    Proccessing Standards) o normas a aplicar en todos los Estados
    Federales y e1 Departamento de Defensa (DOD -USAF, ARMY y NAVY-)
    que publica normas en el terreno militar.

    En cuanto al proceso de creación e
    implantación de las normas, nos remitiremos a las dictadas
    por el IEEE: una nueva idea puede tenerla y sugerirla cualquiera
    de sus miembros, pasándola a continuación al
    Comité de Normas de IS, el cual cursará una
    Petición de Autorización de Proyecto (PAP)
    que se transmite a todos los grupos que hacen normas y al ANSI
    (American National Standard Institute) que se encargará de
    la coordinación.

    La PAP define el objetivo, ámbito,
    descripción y principales contactos para llevar a cabo el
    proyecto. La etapa siguiente corresponde al desarrollo de la
    norma a cargo de un grupo de
    trabajo. Cualquiera puede adherirse al grupo y el IEEE se
    encargará de implicar a todos los interesados para que
    participen en reuniones con los demás miembros (unas
    cuatro reuniones anuales). También pueden intervenir a
    distancia detallando las contribuciones oportunas y
    remitiéndolas al grupo correspondiente. El proceso
    será más enriquecedor cuantos más
    profesionales de distinto nivel y más organismos
    intervengan.

    Una vez terminado un desarrollo se concretará en
    un documento (borrador o draft) que pasará por varias
    revisiones como consecuencia del proceso de valoración y
    votación para aceptarlo. Durante este periodo
    habrán de votar al menos el 75% de los miembros del grupo
    de votación (unos 100 expertos) y a su vez el 75% debe ser
    positivo. Tras su aprobación sé distribuirá
    la nueva norma. En cuanto al tiempo medio que se tarda desde que
    se inicia la elaboración de una norma hasta que se aprueba
    es de tres años. Finalmente, como trabajo complementario
    se procede difundir la norma a través de
    Seminarios.

    La etapa siguiente en este ciclo corresponde con la de
    uso de la norma por las empresas u organismos. Durante esta fase
    los usuarios proporcionan comentarios positivos o negativos
    acerca de la norma, según su propia experiencia, y en
    ocasiones aceptan o modifican las normas para sus fines
    específicos. Las modificaciones se remiten al consejo de
    normas del IEEE para su evaluación
    por el grupo de trabajo entrando en una nueva fase del ciclo de
    elaboración de normas. Finalmente se decidirá
    dejarla igual, modificarla o eliminarla si ya ha sido superada
    por una nueva norma. El ciclo completo dura cinco
    años.

    7. Los modelos de
    calidad del software de gestión.

    En este apartado se presenta, como propuesta de ayuda
    para mejorar la calidad del software de gestión, una
    síntesis del modelo de McCall por ser uno de los
    más difundidos y porque además ha servido de base
    para otros modelos (el modelo de Boehm y el Software Quality
    Management –SQM- de Murine).

    En general los modelos de calidad definen a ésta
    de forma jerárquica, o sea la calidad se produce como
    consecuencia de la evaluación de un conjunto de indicadores o
    métricas en diferentes etapas:

    En el nivel más alto de la jerarquía se
    encuentran los factores de calidad definidos a partir de la
    visión del usuario del software, y conocidos
    también como atributos de calidad externos.

    Cada uno de los factores se descompone en un conjunto de
    criterios de calidad, o sea aquéllos atributos que cuando
    están presentes contribuyen a obtener un software de la
    calidad. Se trata de una visión de la calidad
    técnica, desde el punto de vista del producto software y
    se les denomina también atributos de calidad
    internos.

    Finalmente para cada uno de los criterios de calidad se
    definen un conjunto de métricas o medidas cuantitativas de
    ciertas características del producto que indican el grado
    en que dicho producto posee un determinado atributo de
    calidad.

    De esta manera, a través de un modelo de calidad
    se concretan los aspectos relacionados con ella de tal manera que
    se puede definir, medir y planificar. Además el empleo de
    un modelo de calidad permite comprender las relaciones que
    existen entre diferentes características de un producto
    software.

    En contra de los modelos de calidad pesa que aún
    no ha quedado demostrada la validez absoluta de ninguno de
    ellos.

    8. El modelo de
    McCall.

    El modelo de McCall organiza los factores en tres ejes o
    puntos de vista desde los cuales el usuario puede contemplar la
    calidad de un producto, basándose en once factores de
    calidad organizados en torno a los tres
    ejes y a su vez cada factor se desglosa en otros
    criterios:

    Puntos De Vista O Ejes

    Factor

    Criterios

    OPERACIÓN DEL
    PRODUCTO

    Facilidad de uso

    – Facilidad de operación: Atributos del
    software que determinan la facilidad de operación
    del software.

    – Facilidad de comunicación: Atributos
    del software que proporcionan entradas y salidas
    fácilmente asimilables.

    – Facilidad de aprendizaje: Atributos del software que
    facilitan la familiarización inicial del usuario
    con el software y la transición del modo actual de
    operación.

    – Formación: El grado en que el software
    ayuda para permitir que nuevos usuarios apliquen el
    sistema.

    Integridad

    – Control de accesos. Atributos del software que
    proporcionan control de acceso al software y los datos
    que maneja.

    – Facilidad de auditoría: Atributos del software
    que facilitan la auditoría de los accesos al
    software.

    Seguridad: La disponibilidad de mecanismos
    que controlen o protejan los programas o los
    datos.

    Corrección

    – Completitud: Atributos del software que
    proporcionan la implementación completa de todas
    las funciones requeridas.

    – Consistencia: Atributos del software que
    proporcionan uniformidad en las técnicas y
    notaciones de diseño e
    implementación.

    – Trazabilidad o rastreabilidad: Atributos del
    software que proporcionan una traza desde los requisitos
    a la implementación con respecto a un entorno
    operativo concreto.

    OPERACIÓN DEL
    PRODUCTO

    Fiabilidad

    – Precisión: Atributos del software que
    proporcionan el grado de precisión requerido en
    los cálculos y los resultados.

    – Consistencia.

    Tolerancia a fallos: Atributos del
    software que posibilitan la continuidad del
    funcionamiento bajo condiciones no usuales.

    – Modularidad: Atributos del software que
    proporcionan una estructura de módulos altamente
    independientes.

    – Simplicidad: Atributos del software que
    posibilitan la implementación de funciones de la
    forma más comprensible posible.

    – Exactitud: La precisión de los
    cálculos y del control.

    Eficiencia

    Eficiencia en ejecución: Atributos
    del software que minimizan el tiempo de
    procesamiento.

    – Eficiencia en almacenamiento: Atributos del software que
    minimizan el espacio de almacenamiento
    necesario.

    REVISION DEL PRODUCTO

    Facilidad de
    mantenimiento

    – Modularidad.

    – Simplicidad.

    – Consistencia.

    – Concisión: Atributos del software que
    posibilitan la implementación de una
    función con la menor cantidad de códigos
    posible.

    – Auto descripción: Atributos del
    software que proporcionan explicaciones sobre la
    implementación de las funciones.

    Facilidad de prueba

    – Modularidad.

    – Simplicidad.

    – Auto descripción.

    Instrumentación: Atributos del software
    que posibilitan la observación del comportamiento del software durante su
    ejecución para facilitar las mediciones del uso o
    la identificación de errores.

    Flexibilidad

    – Auto descripción.

    – Capacidad de expansión: Atributos del
    software que posibilitan la expansión del software
    en cuanto a capacidades funcionales y datos.

    – Generalidad: Atributos del software que
    proporcionan amplitud a las funciones
    implementadas.

    – Modularidad.

    Reusabilidad

    – Auto descripción.

    – Generalidad.

    – Modularidad.

    Independencia entre sistema y software:
    Atributos del software que determinan su dependencia del
    entorno operativo.

    – Independencia del hardware: Atributos del
    software que determinan su dependencia del
    hardware.

    Interoperabilidad

    – Modularidad.

    – Compatibilidad de comunicaciones: Atributos del software que
    posibilitan el uso de protocolos de comunicación e
    interfaces estándar.

    – Compatibilidad de datos: Atributos del
    software que posibilitan el uso representaciones de datos
    estándar.

    – Estandarizacion en los datos: El uso de
    estructuras de datos y de tipos
    estándar a lo largo de todo el
    programa.

    Portabilidad

    – Auto descripción.

    – Modularidad.

    -Independencia entre sistema y
    software.

    – Independencia del hardware.

    9. Cómo emplear el
    modelo de mccall.

    Antes de comenzar a utilizar el modelo de McCall hay
    que seguir las siguientes pautas:

    1. Se aceptan los factores, criterios y métricas
      que propone el modelo.
    2. Se aceptan las relaciones entre factores y criterios,
      y entre criterios y métricas.
    3. Se selecciona un subconjunto de factores de calidad
      sobre los que aplicar los requisitos de calidad establecidos
      para el proyecto.

    Al comienzo del proyecto habrá que especificar
    los requisitos de calidad del producto software, para lo cual se
    seleccionarán los aspectos inherentes a la calidad deseada
    del producto, teniendo que considerarse para ello:

    • Las características particulares del propio
      producto que se está diseñando: por ejemplo, su
      ciclo de vida que si se espera que sea largo implicará
      un mayor énfasis en la facilidad de mantenimiento y la
      flexibilidad, o bien si el sistema en desarrollo está
      destinado a un entorno donde el hardware evoluciona
      rápidamente implicará como requisito su
      portabilidad, …
    • La relación calidad-precio, que
      puede evaluarse a través del coste de cada factor de
      calidad frente al beneficio que proporciona. La siguiente tabla
      muestra la
      relación calidad-precio para cada factor
      considerado:

    Factor

    Beneficio / coste

    Corrección

    alto

    Fiabilidad

    alto

    Eficiencia

    bajo

    Integridad

    bajo

    Facilidad de uso

    medio

    Facilidad de mantenimiento

    alto

    Facilidad de prueba

    alto

    Flexibilidad

    medio

    Portabilidad

    medio

    Reusabilidad

    medio

    Interoperabilidad

    bajo

    • La determinación de las etapas del ciclo de
      vida donde es necesario evaluar cada factor de calidad para
      conocer en cuales se dejan sentir más los efectos de una
      calidad pobre con respecto a cada uno de los
      factores.
    • Las propias interrelaciones entre los factores debido
      a que algunos factores pueden entrar en conflicto
      entre sí: por ejemplo, la eficiencia plantea conflictos
      prácticamente con todos los demás factores de
      calidad. La interacción entre los diversos factores a
      evaluar queda reflejada en la tabla I que indica la dependencia
      entre los factores de McCall.

    También habrá que establecer valores
    deseables para los criterios, para lo cual se emplearán
    datos históricos, el promedio en la industria, …. y con
    ellos se concretarán los valores
    finales y otros intermedios o predictivos en cada período
    de medición durante el desarrollo, así como unos
    valores mínimos aceptables. La explicación para
    cualquier selección o decisión deberá ser
    adecuadamente documentada.

    En la fase de desarrollo será necesario
    implementar las métricas elegidas, analizar sus resultados
    y tomar medidas correctivas cuando los valores obtenidos
    estén por debajo de los mínimos
    aceptables.

    Una vez finalizado el proyecto será necesario
    contrastar las medidas predictivas utilizadas y comprobar si, en
    efecto, se pueden tomar como indicadores de los valores
    finales.

    10. Conclusiones.

    Como se ha visto a lo largo de esta exposición,
    hoy día se comienza a imponer la obligación de
    normas de calidad del software donde un fallo en la
    información, o en el tratamiento de ésta puede
    llevar a fallos catastróficos y de consecuencias
    imprevisibles. Por ello las organizaciones están exigiendo
    controles de calidad más rigurosos en la confección
    de su software.

    Hoy día el tener implantados sistemas de
    calidad en la empresa, debe llevar no solo él tener
    que instalar la metodología del sistema de calidad sino
    también sistemas de
    información que controlen y coordinen el sistema,
    sistemas
    automáticos, sistemas documentales, etc. Por todo ello la
    implantación de sistemas de calidad en cualquier empresa u
    organización debe implicar que también el software
    que empleen los posea, y ello repercute en la obligación
    de que sus proveedores de software los hayan empeado en la
    elaboración de sus productos. De esa forma se
    evitarían defectos provenientes de los sistemas de
    información.

    11. Bibliografia.

    Boehm, B.W., Brown, J.R., Lipow, M., Macleod, G.J.,
    Merritt, M.J.; Characteristics of Software Quality,
    North-Holland, 1978.

    Boehm, B.W., Brown, J.R., Lipow, M.; Quantitative
    Evaluation of Software Quality, Proceedings 2nd International
    Conference on Software Engineering, pp. 592-605, 1976.

    Cavano, J.P., McCall, J.A., A Framework for the
    Measurement of Software Quality, Proc. of the ACM Software
    Quality Assurance Workshop, pp. 133-139, Nov. 1978.

    Chidung Lac; Raffy, J.-L., A tool for software Quality,
    Proceedings of the Second Symposium on Assessment of Quality
    Software Development Tools; New Orleans, LA, USA; 27-29 May 1992;
    IEEE Comput. Soc. Press; pp. 144-150; Nahouraii, E.
    (ed.).

    De Domingo, J. y Arranz, A., Calidad y mejora continua,
    Ed Donostiarra. 1997.

    De Millo, R. A. et al., Software Testing and Evaluation,
    Benjamin/Cummings Pub. Co., 1987.

    Dijkstra, E.W., Formal development of programs and
    proofs, Addison-Wesley, 1989.

    Hivart, M.P.; Romain, M.M.; Software Quality measurement
    in complex systems, Proceedings 7th International Conference on
    Reliability and Maintainability; Brest, France; pp. 18-22, Jun.
    1990.

    Hoare, C.A.R., An Axiomatic Basis for Computer
    Programming, Communications of the ACM 12, 10, pp. 576-583, Oct.
    1969.

    Howden,W.E., Reliability of the Path Analysis Testing
    Strategy, IEEE Transactions on Software Engineering SE-2, 3
    (Sept. 1976), pp. 37-44, 1976.

    Kitchenham,B.; Towards a Constructive Quality Model,
    Software Engineering Journal, Vol.2, N. 4, pp. 105-113,
    1987.

    Miller, E., Howden, W. E., Tutorial, Software Testing
    & Validation Techniques, 2a ed., IEEE Computer Society Press,
    1981.

    Murine, G.E. , Integrating software quality metrics with
    software QA, Quality Progress vol.21, no.11; pp. 38-43; Nov.
    1988.

    Oman, P. W. , A case study in SQA Audits, Software
    Quality Journal nº 2, pp. 13-27, 1993.

    Pressman, Roger S, Ingeniería del software, un
    enfoque práctico, Mcgraw Hill 95.

    Rapps, S., Weyuker, E.J., Selecting Software Test Data Using
    Data Flow Information, IEEE Transactions on Software Engineering
    SE-11, 4 (Abr. 1985), pp. 367-375, 1985.

    Reifer, D. J., Knudson, R. W., Smith, J., Final report :
    Software Quality Survey, American Society for Quality Control,
    Aerospace Industries Association of America, 1988.

    Richards Adrion, W., Branstad M.A., Cherniavsky, J.C.,
    Validation, Verification and Testing of Computer Software,
    Computing Surveys, Vol. 14, Nº 2, pp. 159-192, Junio
    1982.

    Senn, James, Análisis y
    diseño de sistemas de información, Mcgraw Hill
    1997.

     RESUMEN: La mayor importancia de las nuevas
    tecnologías de la información y su creciente
    presencia en los diversos ámbitos de la industria moderna
    (robots, centros de control, etc.) y sus productos finales
    (aviación, automóviles, electrodomésticos,
    telefonía, etc.) conlleva cada vez más la presencia
    de programas informáticos que gobiernan muchas de sus
    prestaciones, o bien como herramientas que el cliente
    empleará en su propio beneficio. Basta con observar la
    frenética actividad que ha supuesto para la industria, las
    empresas de servicios y la Administración el enfrentarse
    al tan temido "efecto 2000", así como el gasto que ha
    conllevado la revisión y modificación de los
    programas, para vislumbrar la punta de un iceberg: la falta de un
    control riguroso y sistemático de la calidad del software
    de gestión. En el presente trabajo se aborda este tema y
    se presenta un modelo de aplicación que ayudaría a
    proveedores y clientes desde el comienzo del diseño de una
    aplicación específica de software para su negocio o
    actividad.
    PALABRAS CLAVES: calidad, hardware, modelo de McCall,
    software.

     

     

    Autor:

    Cervera Paz, Angel

    Dpto. Organización de Empresas
    Núñez Moraleda, Bernardo M.;
    Dpto. Lenguajes y Sist. Informáticos
    Universidad
    Cádiz

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter