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

El modelo de McCall.

El modelo de McCall fue el primero en ser presentado en 1977, y se originó motivado por US Air Force y DoD 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 normalmentes atributos externos pero también se incluyen algunos atributos posiblementes internos

Cada atributo externo atributo se dominan factores de calidad los cuales son abstractos para ser medidos directamente por lo cual se introduce un atributo de bajo nivel denominado criterios de calidad.

Según McCall algunos criterios de calidad son atributos internos que tienen efectos directos en atributos externos.

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 criterios de calidad.

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:

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.

 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.