El poder y complejidad de los software empresariales va en aumento día a día. Por ejemplo, poderosos software de gestión integrada (Enterprise Resource Planning - ERP) como SAP se están volviendo “indispensables” en las grandes compañías, también el diseño de software a la medida para todo tipo de compañía es cada vez más frecuente aumentando año a año los presupuestos que las organizaciones, especialmente medianas y grandes empresas, destinan a las TIC en general y al desarrollo y mantenimiento de aplicaciones en particular.
Pero, cuando se invierten estas sumas multimillonarias en un producto, es indispensable diseñar estrategias que tiendan a garantizar su calidad ya que una mayor inversión no siempre conlleva a una mayor calidad.
La calidad del software puede definirse como: “todo el conjunto de cualidades que lo caracterizan determinando su eficiencia y utilidad, satisfaciendo las necesidades tanto implícitas como explícitas del cliente”. (ECURed, s.f.). También puede definirse como “concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente”. (Pressman, 1998)
Según el artículo sobre calidad del software publicado en EcuRed, “El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad. Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
- Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
- Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.
- Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo.
Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.” (ECURed, s.f.)
No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificación se da a los procesos, la correcta consecución de los mismos garantizaría un buen software. No se puede medir al software como tal, sino los atributos que la conforman, tales métodos de medida deben ser exactos. El usuario final mide la calidad del software según lo que tenga o no, es en ese sentido de que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificación en calidad de software no garantiza que su software sea de calidad.
Evaluar la calidad del software, implica la utilización de los llamados modelos de calidad, los cuales descomponen el concepto de calidad en propiedades que pueden ser medidas y evaluadas de manera más sencilla llamadas métricas, un ejemplo moderno de modelo de calidad es el CMMI (Capability Maturity Model Integration) el cual “permite evaluar las capacidades de las organizaciones que trabajan en el campo del software, y proporciona un marco para organizar la evolución dentro de cinco niveles de madurez que van estableciendo elementos para la mejora continua de los procesos”. (CVUDES, s.f.). Un modelo de calidad permite evaluar, o si se quiere, medir la calidad del producto en cada una de las etapas de producción del producto o servicio, desde que es una idea hasta que se concreta y llega al cliente.
Una clasificación tradicional de los modelos de calidad es la que plantea que hay modelos fijos, en los que se disponen un inventario de factores de calidad de partida, y para la evaluación de la calidad de un producto se selecciona un subconjunto de dichos factores por ejemplo el modelo de McCall; modelos a medida los cuales no se desarrollan por factores, ya que se identifican de acuerdo a cada proyecto, en los que se encuentran el modelo GQM de Basili y modelos mixtos que se encargan de aprovechar las ventajas de los otros modelos en los que se encuentran el modelo ADEQUATE de Horgan (1999) y el modelo estándar ISO/IEC 9126 (2001).
Con la implementación de esto modelos y estándares se busca mas no se garantiza:
- Cumplir con las expectativas del cliente.
- Brindar productos con cero o mínimos defectos.
- Producir artículos o brindar servicios de acuerdo a las normas establecidas.
- Diseñar, producir y comercializar un producto con calidad.
- Obtener la participación de todos los miembros de la organización.
- Implementar la cultura de la calidad.
- Establecer una tendencia a la excelencia.
- Desarrollar procesos confiables, eficientes y automáticos.
La importancia de implementar modelos de calidad en las empresas radica en que dichos modelos les permiten estandarizar sus procesos de producción y/o organizacionales con el fin de ser más competitivas en un mundo globalizado y responder satisfactoriamente a las necesidades de sus clientes para lograr su permanencia en el mercado. La implementación de un modelo de calidad permitirá también hacer una evaluación de sus procesos y a partir de dicha evaluación crear nuevos procesos o replantear, reformular, eliminar procesos ineficientes. Es innegable que el concepto de calidad.
Adoptar un modelo de calidad y cumplir con unos parámetros estandarizados de calidad no garantizan per se el éxito de la empresa, pero es un gran paso hacia la generación de procesos de calidad que conlleven a la obtención de productos y/o servicios de calidad lo cual se convierte en un factor diferenciador a la hora de competir en un mercado globalizado.
Modelos de calidad para evaluar la calidad de productos software
| Modelo | Características | Ventajas | Desventajas |
| MACCALL (1977) | Descompone el concepto genérico de calidad en tres capacidades o ejes importantes para un producto software: operación, transición y revisión. A su vez cada capacidad se descompone en un conjunto de factores y finalmente se definen criterios para evaluar el factor a través de métricas. Este modelo busca reducir la brecha entre usuarios y desarrolladores enfocándose en un número de factores de calidad que reflejen las prioridades de ambos. Características de calidad: - Facilidades de uso - Integridad - Corrección - Confiabilidad - Eficiencia - Facilidad de mantenimiento - Facilidad de prueba - Flexibilidad - Facilidad de reutilización - Interoperabilidad - Portabilidad Su finalidad, atender a las diversas necesidades de las organizaciones que quieren realizar la mejora de sus procesos. |
- Se focaliza en el producto final, pero también se puede aplicar al proceso. - Identifica atributos claves desde el punto de vista del usuario. - Se focaliza en medidas precisas de alto nivel. - Su estructura jerárquica lo hace fácil de entender y de aplicar. - Su costo hace viable su aplicación. - Se puede utilizar para múltiples proyectos. - Existe una relación directa entre los desarrolladores y el usuario. |
- Algunas veces se pierde la relación entre las métricas y las características que se quieren estimar. - Se evalúan muchos factores lo que implica un trabajo adicional al desarrollo. - Resulta tedioso por la gran cantidad de métricas. - Falta una asociación explícita entre el modelo y el proceso. |
| BOEHM (1978) |
Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Define la calidad en términos de atributos cualitativos y métricas para realizar las medidas. Plantea 3 niveles para las características: de alto nivel, de nivel intermedio y nivel primitivo. El modelo se centra en: - Sus características operativas. - Su capacidad para soportar los cambios. - Su adaptabilidad a nuevos entornos. - La evaluación del desempeño del hardware. El modelo se basa en que el software debe: - Hacer lo que el usuario quiere que haga. - Utilizar los recursos de la computadora correcta y eficientemente. - Ser fácil de usar y de aprender para los usuarios. - Estar bien diseñado, bien codificado y ser probado y mantenido fácilmente. |
- Involucra menos factores y criterios que el modelo de MacCall lo que lo hace que se necesite menos tiempo en su desarrollo
Se puede utilizar para múltiples proyectos. - Está fundamentado en los modelos ISO 9000 y CMMI. - No implica un esfuerzo adicional para mejorar y certificarse en ISO 9000. - Puede adaptarse y aplicarse a lo largo de la vida del software de computadora. - Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. - Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. - Si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. |
- Deja de lado muchos aspectos relacionados con el usuario. - Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. - Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. - Genera mucho tiempo en el desarrollo del sistema. - Es un modelo costoso. - Requiere experiencia en la identificación de riesgos. - No se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos. |
| FURPS (1987) |
El modelo FURPS establece cinco características como factores de calidad que son los que le dan nombre: - Functionality (Funcionalidad). - Usability (Usabilidad). - Reliability (Confiabilidad). - Perfomance (Prestación) y - Supportability (Soporte). El modelo FURPS incluye, además de los factores de calidad y los atributos, restricciones de diseño y requerimientos de implementación, físicos y de interfaz. Es un modelo de calidad fijo y para realizar la evaluación de la calidad de un producto, primero se asignan prioridades y después se definen los atributos de calidad que pueden ser medidos. |
- Los criterios son claramente entendibles, lo que implica su fácil utilización. - En cierta forma su división en factores funcionales y no funcionales es conveniente para determinar la calidad, aun así, hayan restricciones físicas. - Tiene en cuenta las fallas en el producto y en el proceso, esto permite una mayor corrección. - Se podría utilizar no para uno sino para varios proyectos. |
- No tiene en cuenta la portabilidad de los productos software que se estén considerando. - Se necesitan de muchas métricas lo que implica un mayor esfuerzo de tiempo y costo. |
| CMMI (1984) |
Constituye un marco de referencia de la capacidad de las organizaciones de desarrollo de software en el desempeño de sus diferentes procesos, proporcionando una base para la evaluación de su madurez y una guía para implementar una estrategia para la mejora continua de los mismos. |
- Inclusión de las prácticas de institucionalización, que permiten asegurar que los procesos asociados con cada área de proceso sean efectivos, repetibles y duraderos. - Guía paso a paso para la mejora, a través de nivel es de madurez y capacidad. - Transición del aprendizaje individual al aprendizaje de la organización por mejora continua, lecciones aprendidas y uso de bibliotecas y bases de datos de proyectos mejorados. - Reducción del costo de desarrollo. - Localización y resolución de defectos. |
- El CMMI puede llegar a ser excesivamente detallado para algunas organizaciones. - Puede ser considerado muy detallado. - Requiere mayor inversión que ISO/IEC 15504 e ISO 9000, para ser completamente implementado. - Puede ser difícil de entender. - Da la idea de que sólo se pueden mejorar áreas de proceso del actual nivel de madurez; se centra más en alcanzar el siguiente nivel de madurez, más que la mejora medible de los objetivos de la organización. - Presta excesiva atención a aspectos de gestión, dejando a un lado aspectos técnicos, o que podamos mejorar áreas de proceso según nuestro interés obviando las relaciones y dependencias entre ellas. |
| Bootstrap.ESPRIT |
- Tiene como principio el reducir costos y mejorar la calidad previendo problemas. - Su objetivo es desarrollar un método para la evaluación de procesos de desarrollo de software (SW). - Describe el proceso de evaluación de desarrollo para determinar si una organización se encuentra en un cierto nivel de madurez (CMM), identificando puntos fuertes, débiles y también el de ofrecer pautas de mejora. - El enfoque de Bootstrap es evaluar el proceso, no el producto. Para esto: Define características de los procesos Provee un análisis cuantitativo, hace evidentes fortalezas y debilidades, identifica áreas de mejora, provee recomendaciones, sugiere un plan de implementación. - La metodología Bootstrap se compone de: un modelo, un proceso de evaluación, una base de datos de soporte, un proceso de mejora y los instrumentos de evaluación. |
- La descomposición en procesos detallados ofrece un buen marco para la evaluación de procesos. - El proceso de mejora está muy claro a la hora de aplicarlo. - Usa una base de datos global que es beneficioso para la comunicación. - Engloba tanto la evaluación para establecer el diagnóstico de un proceso para desarrollo de software como la creación de un plan de acción que defina los pasos, los detalles de la implantación y los marcos temporales para que la organización aumente su capacidad de entrega de productos y servicios de calidad. - La metodología tiene una gran ventaja, compara los resultados de la evaluación con los resultados de sus competidores. - Prioriza qué necesidades se deben mejorar primero. |
- Se implementa principalmente en Europa. - Incompleto en comparación con otros modelos. - Faltaría un poco más de atención en lo que se refiere a la satisfacción del cliente. - No hay herramientas de terceras partes accesibles para los usuarios. |
