Métricas del software: una métrica del software es cualquier medida o conjunto

utilizado para conocer o estimar el tamaño de un software o sistema de

información. Entre los usos más frecuentes de las métricas del software están el

realizar comparaciones costo beneficio y estimaciones de costos en proyectos de

software.

Un ejemplo de métrica del software es el punto de función, su uso permite mayor

precisión en las estimaciones de costo, posibilidad de comparar funcionalidades

del software a desarrollar y tomar decisiones en base al costo beneficio, más

información para priorizar trabajo, posibilidad de hacer avaluos de activos de

software, entre otros beneficios.

¿Para qué se utilizan las métricas del software?

De la misma forma que en ingeniería de construcción necesitaríamos definir la

altura y ancho de una estructura y sus componentes expresados en metros o

centímetros, en desarrollo de software podemos valernos de una unidad de

medida que nos permitiera conocer el tamaño del reto al que como

desarrolladores de software nos enfrentamos.

Una vez conocido el tamaño en unidad de medida, podríamos utilizarla para

determinar con precisión cuál es la estimación de tiempo y presupuesto de un

proyecto de software, si nuestras especificaciones de requerimientos son

ambiguas o falta información, impacto de un cambio de alcance propuesto, medir

unidades planificadas vs. Producidas, graficar la cantidad de unidades de medica

producidas en el tiempo (para medir la productividad), entre otros usos.

¿Cuáles son los métodos más utilizados para determinar métricas del software?

Existen diversas técnicas de estimación de esfuerzo y costo en proyectos de

software. Un ejemplo ampliamente usado para realizar mediciones del tamaño de

un software es la métrica del punto de función.

Desarrollada originalmente en los años 70, la técnica del análisis de puntos de

función permite asignar un tamaño a los requerimientos de software (sus

funcionalidades) expresadas en una métrica que se conoce como el punto de

función.

Para medir el software utilizando los puntos de función, primero se toman

los requerimientos del software (que pueden estar documentados en la

especificación de requerimientos o historias de usuario) y se realiza una

descomposición funcional en sus componentes.

Realizada la descomposición funcional, se le asigna a cada componente una

cantidad de puntos de función que vienen dados por su complejidad, si son

movimientos de entrada o salida, solo consulta o transferencia de datos.

Los sistemas de métricas de calidad del software tradicionales se han centrado

fundamentalmente en las métricas de procesos, de productos y de recursos, Los

sistemas de métricas para tiempo de ejecución más comunes hoy en día son los

usados en los profilers o aplicaciones para probar las aplicaciones Este tipo de

aplicaciones usan sistemas de métricas en tiempo de ejecución para medir

tiempos, buscar cuellos de botella en las aplicaciones, medir capacidades

máximas, etcétera. Así, las métricas tratan de servir de medio para entender,

monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de

mantenimiento (Briand et al., 1996)

Los tres objetivos fundamentales de la medición son (Fenton y Pfleeger, 1997):

Entender qué ocurre durante el desarrollo y el mantenimiento. Controlar qué es lo

que ocurre en nuestros proyectos. Mejorar nuestros procesos y nuestros

productos. En ingeniería del software, la medición es una disciplina relativamente

joven, y no existe consenso general sobre la definición exacta de los conceptos y

terminología que maneja. Proporcionamos a continuación las definiciones del

Institute of Electrical an Electronics Engineers (IEEE):

Métricas del código fuente de un software:

La teoría de Halstead de la ciencia del software es ‘probablemente la mejor

conocida y más minuciosamente estudiada... medidas compuestas de la

complejidad (software)’ [Ejiogo ‘91]. La ciencia software propuso las primeras

‘leyes’ analíticas para el software de computadora. La ciencia del software asigna

leyes cuantitativas al desarrollo del software de computadora. La teoría de

Halstead se obtiene de un supuesto fundamental [Pressman ‘98]: ‘el cerebro

humano sigue un conjunto de reglas más rígido (en el desarrollo de algoritmos) de

lo que se imagina...’. La ciencia del software usa un conjunto de medidas

primitivas que pueden obtenerse una vez que se ha generado o estimado el

código después de completar el diseño. Estas medidas se listan a continuación.

n1: el número de operadores diferentes que aparecen en el programa

n2: el número de operandos diferentes que aparecen en el programa

N1: el número total de veces que aparece el operador

N2: el número total de veces que aparece el operando

Halstead usa las medidas primitivas para desarrollar expresiones para la longitud

global del programa; volumen mínimo potencial para un algoritmo; el volumen real

(número de bits requeridos para especificar un programa); el nivel del programa

(una medida de la complejidad del software); nivel del lenguaje (una constante

para un lenguaje dado); y otras características tales como esfuerzo de desarrollo,

tiempo de desarrollo e incluso el número esperado de fallos en el software.

Halstead expone que la longitud N se puede estimar como:

N = n1 log2 n1 + n2 log2 n2

y el volumen de programa se puede definir como:

V = N log2 (n1 + n2)

Se debería tener en cuenta que V variará con el lenguaje de programación y

representa el volumen de información Teóricamente debe existir un volumen

mínimo para un algoritmo. Halstead define una relación de volumen L como la

relación volumen de la forma más compacta de un programa respecto al volumen

real del programa. Por tanto L, debe ser siempre menor de uno. En términos de

medidas primitivas, la relación de volumen se puede expresar como:

L = 2/n1*n2/N2

Halstead propuso que todos los lenguajes pueden categorizarse por nivel de

lenguaje, I, que variará según los lenguajes. Halslead creó una teoría que suponía

que el nivel de lenguaje es constante para un lenguaje dado, pero otro trabajo

[Pressman ‘98] indica que el nivel de lenguaje es función tanto del lenguaje como

del programador.

Parece que el nivel de lenguaje implica un nivel de abstracción en la

especificación procedimental. Los lenguajes de alto nivel permiten la 98

especificación del código a un nivel más alto de abstracción que el lenguaje

ensamblador (orientado a máquina).

Métricas aseguramiento calidad del software:

El objetivo primordial de la ingeniería del software es producir un sistema,

aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros de

software deben emplear métodos efectivos junto con herramientas modernas

dentro del contexto de un proceso maduro de desarrollo del software. Al mismo

tiempo, un buen ingeniero del software y buenos administradores de la ingeniería

del software deben medir si la alta calidad se va a llevar a cabo. A continuación se

verá un conjunto de métricas del software que pueden emplearse a la valoración

cuantitativa de la calidad de software

El punto de vista de ¿Qué es calidad? Es diverso, y por lo tanto existen distintas

respuestas, tales como se muestra a continuación:

El American Heritage Dictionary [Pressman ´98] define la calidad como “Una

característica o atributo de algo.” La definición estándar de calidad en ISO-8402 es

“La totalidad de rasgos y características de un producto, proceso o servicio que

sostiene la habilidad de satisfacer estados o necesidades implícitas” [Mcdermid

’91]. “Concordar explícitamente al estado funcional y a los requerimientos del

funcionamiento, explícitamente a los estándares de documentación de desarrollo,

e implícitamente características que son expectativas de todos los desarrolladores

profesionales de software” [Pressman ’93]. La calidad de un sistema, aplicación o

producto es tan buena como los requisitos que detallan el problema, el diseño que
modela la solución, el código que transfiere a un programa ejecutable y las

pruebas que ejercita el software para detectar errores. Un buen ingeniero del

software emplea mediciones que evalúan la calidad del análisis y los modelos de

diseño, así como el código fuente y los casos de prueba que se han establecido al

aplicar la ingeniería del software. Para obtener esta evaluación de calidad, el

ingeniero debe utilizar medidas técnicas, que evalúan la calidad con objetividad,

no con subjetividad. Asimismo, un buen administrador de proyectos debe evaluar

la calidad objetivamente y no subjetivamente. A medida que el proyecto progresa

el administrador del proyecto siempre debe valorar la calidad. Aunque se pueden

recopilar muchas medidas de calidad, el primer objetivo en el proyecto es medir

errores y defectos. Las métricas que provienen de estas medidas proporcionan

una indicación de la efectividad de las actividades de control y de la garantía de

calidad en grupos o en particulares. Por ejemplo los errores detectados por hora

de revisión y los errores detectados por hora de prueba suministran una visión

profunda de la eficacia de cada una de las actividades envueltas en la métrica. Así

los datos de errores se pueden utilizar también para calcular la eficiencia de

eliminación de defectos en cada una de las actividades del marco de trabajo del

proceso.

Métricas basadas en atributos internos del producto de software:

Los atributos internos de un producto, proceso o recurso son aquellos que

podemos medir puramente en términos del producto, proceso o recurso del

mismo. Pueden ser medidos directamente. Por ejemplo: la longitud de un

programa o el tiempo transcurrido de cualquier documento de software

[Fenton‘91]. Los atributos externos de un producto, proceso o recurso son aquellos

que solamente pueden ser medidos con respecto al cómo el producto, proceso o

recurso se relacionan a su ambiente. Estos tienden a ser los que el administrador

y el usuario del software comúnmente gustan de medir y predecir. Por ejemplo el

administrador de software le gustaría saber el costo de eficacia de algunos

procesos o de la productividad de su personal, mientras los usuarios les gustaría

saber la usabilidad, fiabilidad, o portabilidad de un sistema que ellos observan

para comprar. Desgraciadamente los atributos externos son los más difíciles de

medir, porque estos no pueden ser medidos directamente.

Cualquier cosa que queramos medir o predecir en un software es un atributo de

cualquier entidad de un producto, proceso o recurso asociado a éste. Cada

entidad de software tiene varios atributos que pueden ser medidos. Es por eso que

se necesita hacer una distinción entre atributos que son internos o externos y

medidas directas e indirectas.

Métricas sistema orientado a objetos: Las métricas orientadas a objetos se

centran en métricas que se pueden aplicar a las características de

encapsulamiento, ocultamiento de información, herencia y técnicas de abstracción

de objetos que hagan única a esa clase.

El Software Orientado a Objetos (OO) es fundamentalmente distinto del software

que se desarrolla utilizando métodos convencionales. Las métricas para sistemas

OO deben de ajustarse a las características que distinguen el software OO del

software convencional. Estas métricas hacen hincapié en el encapsulamiento, la

herencia, complejidad de clases y polimorfismo. Por lo tanto, las métricas OO se

centran en métricas que se pueden aplicar a las características de

encapsulamiento, ocultamiento de información, herencia y técnicas de abstracción

de objetos que hagan única a esa clase. Como en todas las métricas los objetivos

principales de las métricas OO se derivan del software convencional: comprender

mejor la calidad del producto, estimar la efectividad del proceso y mejorar la

calidad del trabajo realizado a nivel del proyecto. Se conoce que las medidas y las

métricas son componentes clave de cualquier disciplina de la ingeniería; la

ingeniería de software orientada a objetos no es una excepción.

Lamentablemente, la utilización de métricas para sistemas orientados a objetos ha

progresado con mucha más lentitud que la utilización de los demás métodos OO

[Luis A. Laranjeira ‘90]. Sin embargo, a medida que los sistemas OO van siendo

más habituales, resulta fundamental que los ingenieros del software dispongan de

mecanismos cuantitativos para estimar la calidad de los diseños y la efectividad de

los programas 00.

Gran parte del diseño orientado a objetos es subjetivo un diseñador

experimentado “sabe” como puede caracterizar un sistema 00 para que se

implemente de forma efectiva los requisitos del cliente. Pero a medida que los

modelos de diseño 00 van creciendo de tamaño y complejidad, puede resultar

beneficiosa una visión más objetiva de las características del diseño, tanto para el

diseñador experimentado como para el menos experimentado. Una visión objetiva

del diseño debería de tener un componente cuantitativo y esto nos lleva a las
métricas 00, en donde se pueden aplicar no solo al modelo de diseño, sino

también al modelo de análisis

Objetivo de las métricas Orientados a Objetos:

Los objetivos principales de las métricas orientadas a objetos son los mismos que

los existentes para las métricas surgidas para el software estructurado:

 Comprender mejor la calidad del producto

 Estimar la efectividad del proceso

 Mejorar la calidad del trabajo realizado en el nivel del proyecto.

Cada uno de estos objetivos es importante en sí, pero para el ingeniero de

software, la calidad del producto debe de ser lo esencial. ¿Cómo se puede medir

la calidad de un sistema 0?0? ¿Qué características del modelo de diseño se

pueden estimar para decretar si el sistema será o no fácil de implementar, se

podrá probar, que será fácil de modificar, y lo que es más importante, resultará

tolerable para los usuarios finales? [Laranjeira 1990]. Estos argumentos se

tratarán de resolver a lo largo de este capítulo

Chidamber & Kemerer1 proponen una familia de medidas para desarrollos

orientados a objetos:

 Métodos ponderados por clase (MPC): Tamaño y complejidad

 Profundidad árbol de herencia (PAH): Tamaño

 Número de descendientes (NDD): Tamaño, acoplamiento y cohesión

  Acoplamiento entre clases (ACO): Acoplamiento

 Respuesta para una clase (RPC): Comunicación y complejidad

 Carencia de cohesión en los métodos (CCM): Cohesión interna

Estas métricas, en líneas generales, permiten averiguar cuán bien están definidas

las clases y el sistema, lo cual tiene un impacto directo en la mantenibilidad del

mismo, tanto por la comprensión de lo desarrollado como por la dificultad de

modificarlo con éxito.

Métricas basadas en estructura de diseño:

Permiten medir de forma cuantitativa la calidad de los atributos internos del

software. Esto permite al ingeniero evaluar la calidad durante el desarrollo del

sistema.

Las métricas para software, como otras métricas, no son perfectas; muchos

expertos argumentan que se necesita más experimentación hasta que se puedan

emplear bien las métricas de diseño. Sin embargo, el diseño sin medición es una

alternativa inaceptable. A continuación, se mostrarán algunas de las métricas de

diseño más comunes. Aunque ninguna es perfecta, pueden proporcionarle al

diseñador una mejor visión interna y así el diseño evolucionara a un mejor nivel de

calidad.

Métricas de rendimiento:
muestran un valor mensurable del progreso de los objetivos comerciales de una

empresa. Las métricas empresariales también indican si una empresa ha

alcanzado sus objetivos en un marco de tiempo planificado.

Hay cientos de diferentes ejemplos de indicadores clave de rendimiento.

Dependiendo de los objetivos de tu negocio, debes hacer un seguimiento de las

métricas comerciales que realmente muestren cómo le va a tu negocio. El

seguimiento de los KPI irrelevantes te distraerá de centrarte en las cosas que

realmente importan. De esta manera, terminarás haciendo hincapié en los

números que no tienen un impacto real en el desarrollo de tu empresa. Por lo

tanto, es muy importante que no solo realices un seguimiento de las métricas

empresariales, sino que también elijas las más adecuadas para percibirlas.

el rendimiento del sistema actual utilizando métricas. Puede evaluar el estado del

sistema en su totalidad, así como el estado de los servidores individuales, los

asignadores y los servicios habilitados.

Por ejemplo, comprueba las métricas de rendimiento y observa que el servicio de

informes muestra un indicador con un cuadrado rojo que identifica un rendimiento

bajo. Consulta las métricas del servicio de informes y determina que el número de

solicitudes que están en la cola supera el número que puede procesarse en un

espacio de tiempo especificado.

Ejemplos de métricas de negocios:

  Los ingresos por ventas

 Margen de beneficio neto

 Margen bruto

 Ingreso periódico recurrente

Valor asignado a una métrica del software:

Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de

mantenimiento, integridad y facilidad de uso suministran indicadores útiles para el

equipo del proyecto. Gilb [Len O. Ejiogo ‘90] sugiere definiciones y medidas para

cada uno de ellos, tales como:

Corrección: A un programa le corresponde operar correctamente o suministrará

poco valor a sus usuarios. La corrección es el grado en el que el software lleva a

cabo una función requerida. La medida más común de corrección son los defectos

por KLDC, en donde un defecto se define como una falla verificada de

conformidad con los requisitos.

Facilidad de mantenimiento. El mantenimiento del software cuenta con más

esfuerzo que cualquier otra actividad de ingeniería del software. La facilidad de

mantenimiento es la habilidad con la que se puede corregir un programa si se

encuentra un error, se puede adaptar si su entorno cambia o optimizar si el cliente

desea un cambio de requisitos. No hay forma de medir directamente la facilidad de

mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una

métrica orientada al tiempo simple es el tiempo medio de cambio (TMC), es decir,

el tiempo que se tarda en analizar la petición de cambio, en diseñar una

modificación apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio

a todos los usuarios. En promedio, los programas que son más fáciles de

mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los

programas que son más difíciles de mantener. Hitachi ha empleado una métrica

orientada al costo (precio) para la capacidad de mantenimiento, llamada

“desperdicios”. El costo estará en corregir defectos hallados después de haber

distribuido el software a sus usuarios finales. Cuando la proporción de

desperdicios en el costo global del proyecto se simboliza como una función del

tiempo, es aquí donde el administrador logra determinar si la facilidad de

mantenimiento del software producido por una organización de desarrollo está

mejorando y asimismo se pueden emprender acciones a partir de las conclusiones

obtenidas de esa información.

Integridad. En esta época de intrusos informáticos y de virus, la integridad del

software ha llegado a tener mucha importancia. Este atributo mide la habilidad de

un sistema para soportar ataques (tanto accidentales como intencionados) contra

su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes

del software, ya sea en los programas, datos o documentos. Para medir la

integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad.

La amenaza es la probabilidad (que se logra evaluar o concluir de la evidencia

empírica) de que un ataque de un tipo establecido ocurra en un tiempo

establecido. La seguridad es la probabilidad (que se puede estimar o deducir de la

evidencia empírica) de que se pueda repeler el ataque de un tipo establecido, en

donde la integridad del sistema se puede especificar como: integridad = Ó[1-

amenaza x (1- seguridad)] (4.1) donde se suman la amenaza y la seguridad para

cada tipo de ataque.

El propósito de una métrica es el de conseguir que un producto software sea un

aparato de ingeniería, cuya calidad pueda ser medida y que pueda ser producido

eficientemente.

Las métricas de software se aplican a todas las fases del desarrollo de software

(especificaciones, análisis, diseño, pruebas de codificación, documentación, etc.),

no solo el producto final.

Según algunos autores podemos clasificar a las métricas de software atendiendo

dos criterios, por un lado, como entidades pueden ser procesos, productos y

recursos.

Procesos: son actividades que tienen una cierta duración (la codificación,

integración, etc.)

Productos: son resultados tangibles de los procesos (tipos abstractos de datos,

objetos codificados, etc.)

Recursos: son entradas a procesos (personal, hardware, otro software, etc.)

Por otro lado, como atributos que pueden ser internas y externas.
Atributos internos de una entidad son los que pueden ser medidos en términos de

la entidad misma (tamaño, funcionalidad, esfuerzo, número de errores detectados,

etc.)

Atributos externos de una entidad son aquellos que solo pueden ser medidos en

términos de otras entidades (mantenibilidad, comprensibilidad, calidad, coste, etc.)

Clasificaciones métricas del software: Clasificación de las métricas de Software

Según los criterios: Métricas que definen la medición de la complejidad: volumen,

tamaño, de complejidad anidaciones, y configuración. Métricas que definen la

calidad del software: exactitud, estructuración o de calidad modularidad, pruebas,

mantenimiento. Métricas que intentan valorar o medir las actividades de

productividad de competencia de los programadores con respecto a su certeza,

rapidez, eficiencia y competencia Métricas que miden la conducta de módulos y

sistemas de un software, de desempeño bajo la supervisión del SO o hardware.

Métricas de experimentación y de preferencia: estilo de código, estilizadas

convenciones, limitaciones, etc.

Métricas que definen la medición de la complejidad: volumen, tamaño,

anidaciones, y configuración

de calidad

Métricas que definen la calidad del software: exactitud, estructuración o

modularidad, pruebas, mantenimiento.
de competencia

Métricas que intentan valorar o medir las actividades de productividad

de los programadores con respecto a su certeza, rapidez, eficiencia y

competencia

de desempeño

Métricas que miden la conducta de módulos y sistemas de un software,bajo la

supervisión del SO o hardware.

estilizadas

Métricas de experimentación y de preferencia: estilo de código,

convenciones, limitaciones, etc.

Beneficios de aplicar métricas en un proyecto:

Una métrica de gestión de proyectos es por definición cualquier tipo de variable

que pueda ser usada para medir el desempeño de algún aspecto del proyecto que

sea importante y queramos controlar. Como ya se intuye por esta definición, una

métrica debe ser o estar basada en un valor numérico que nos dé una visión
objetiva del estado de esta variable. De esta forma vamos a tener métricas

relacionadas con los costes, los plazos, los entregables, la calidad, etc.

En función de la forma de calcular la métrica, esta puede ser un valor observable

directamente, como el número de documentos aprobados o el número de defectos

encontrados; la diferencia entre el valor planificado y la situación real, como los

días de retraso o la diferencia de costes; o una variable derivada de valores

observables que requiera de algún cálculo, como el EV (valor ganado), ETC (coste

total estimado) o el PV (valor planificado).

Herramientas disponibles

Uno de los principales problemas de trabajar con métricas es recopilar información

fiable para su cálculo, y en algunos casos hacer este de forma más o menos

automatizada; lo que en última instancia dependerá de las  herramientas de

gestión de proyectos, que tengamos a nuestra disposición.

Actualmente existen varios programas comerciales de gestión de proyectos que

permiten aplicar diferentes metodologías y crear cuadros de mando, así como

programas que permiten gestionar portfolios y programas unificando las métricas

en cuadros de mando generales.

Las métricas tienen dos funciones principales, la primera a nivel del proyecto como

cuadro de mando del director del proyecto, y la segunda a nivel de la organización

como herramienta para reportar y controlar de forma simple el estado del conjunto

de proyectos.
Desde el punto de vista del director del proyecto las métricas permiten conocer de

forma rápida y objetiva el estado del proyecto, identificando fácilmente aquellos

aspectos donde tengamos problemas.

Facilidad de uso del software: El calificativo “amigable con el usuario” se ha

transformado universalmente en disputas sobre productos de software. Si un

programa no es “amigable con el usuario”, prácticamente está próximo al fracaso,

incluso aunque las funciones que realice sean valiosas. La facilidad de uso es un

intento de cuantificar “lo amigable que pude ser con el usuario” y se consigue

medir en función de cuatro características:

(1) destreza intelectual y/o física solicitada para aprender el sistema;

(2) el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del

sistema;

(3) aumento neto en productividad (sobre el enfoque que el sistema reemplaza)

medida cuando alguien emplea el sistema moderadamente y eficientemente, y

(4) valoración subjetiva (a veces obtenida mediante un cuestionario) de la

disposición de los usuarios hacia el sistema. Los cuatro factores anteriores son

sólo un ejemplo de todos los que se han propuesto como medidas de la calidad

del software.
Riesgo en proyecto de software:

Cualquier proyecto, tenga la característica que tenga, presenta problemas.

Cuando hablamos de proyectos de implantación de software es casi imposible no

pensar en ellos y en cómo ejecutar una correcta gestión de riesgos.

La cantidad de personas involucradas, el tamaño de los proyectos, la involucración

de software e infraestructura y la siempre presente posibilidad de la dilatación de

los plazos, nos hacen pensar en cómo se pueden gestionar para minimizarlos.

Cualquier cosa que lo retrase, impida que avance al ritmo esperado o que

provoque que se salga del presupuesto estimado.

En definitiva, cualquier aspecto del proceso que suponga una desviación del plan

previsto y que permita que el proceso fracase.

Análisis de riesgos

Además, si los riesgos están por todas partes y no se pueden evitar, ¿para qué

preocuparse?

Estos son algunos de los casos más sonados de fracasos en la implementación de

software.

 
En 1982, la empresa Allstate quiso automatizar las actividades administrativas.

Las estimaciones del proyecto eran de 5 años y 8 millones de dólares.

La realidad fue bien diferente: 6 años y 15 millones de dólares más tarde, tuvieron

que redefinir el plan con una nueva fecha de entrega y un presupuesto que

alcanzó los 100 millones, casi 7 veces más que el presupuesto original.

Y no es un caso aislado. En 1988, la Westpac Banking Corporation decidió volver

a definir sus sistemas de información. Los 3 años estimados se convirtieron en 6, y

los 85 millones en 150, por no hablar de los empleos perdidos y el impacto

económico que supuso para la compañía.

Los riesgos son una realidad y la gestión de riesgos una forma de acotarlos y

evitar que terminen en desastre.

Riesgos más comunes en los proyectos

¿Son el presupuesto y el plazo de entrega los dos únicos riesgos a los que se

debe enfrentar una empresa que desea una implantación de software?

Ni mucho menos, más bien son la consecuencia de los muchos riesgos que

pueden presentarse. La variedad es amplia, aunque podemos utilizar la siguiente

clasificación en el caso concreto de proyectos de implantación:

1/ Riesgos derivados del cliente

Partimos de la base de que este tipo de proyectos se encaran con la contratación

de un partner tecnológico externo.

Como es lógico, el cliente puede ser un riesgo potencial importante,

independientemente de que sea el principal interesado en que el proyecto llegue a

buen puerto.

Los riesgos derivados del cliente son múltiples. El desconocimiento de lo que se

ha comprado, las expectativas poco realistas o la falta de colaboración de los

empleados pueden llevar al fracaso incluso con el partner más entusiasta. Una

actitud positiva y talentosa de los empleados facilita el éxito del proyecto.

Incluso cuando la directiva está fuertemente involucrada, si la cultura empresarial

es reticente al cambio, el proyecto puede fracasar.

2/ Riesgos derivados de la empresa suministradora de servicios

No siempre se acierta con la elección del proveedor de servicios.

Si el personal no tiene los conocimientos y experiencia suficientes, subcontrata

partes del proyecto a terceros que no responden, y toda la gama de posibilidades

que abarca la rotación de los consultores hace acto de presencia (nuevo personal,

abandono del equipo, incorporaciones que no dominan la tecnología, falta de

formación), el fracaso está asegurado.

3/ Riesgos derivados de la planificación

Por muy involucrados que estén ambos equipos (cliente y proveedor), si la

planificación no es metódica y constante, el riesgo se vuelve muy real.

Uno de los ejemplos más típicos derivados de la falta de planificación es no

establecer claramente quién debe realizar cada una de las fases del plan, algo que

sucede con frecuencia en los casos de migración de un sistema a uno más actual.

La falta de disponibilidad del equipo de cliente se convierte en un exceso de carga

de trabajo en el equipo del proveedor y por tanto no es viable cumplir los hitos /

fases planificados.

Si hay que realizar nuevos desarrollos en un paquete estándar, alguien debe

asumir esa tarea. Incluso tener que pasar datos de unas tablas a otras, algo en

teoría muy simple, debe hacerlo alguien.

Una planificación muy optimista o impuesta por el cliente, o no evaluar la carga de

trabajo que supone el proyecto, son algunos de los riesgos más comunes.

4/ Riesgos derivados del producto

Por último, existe una gran variedad de riesgos derivados del propio producto a

implantar, porque hasta que no se comienza el trabajo con frecuencia no es

posible hacerse una idea exacta ni de la complejidad ni de si las soluciones

aportadas serán factibles.

Por último, señalar que todos estos riesgos pueden coexistir en el mismo proyecto

y al mismo tiempo, lo que complica todavía más el panorama.

 

Es evidente que se necesita analizar y realizar un plan de gestión de riesgos en la

implantación de software.

 Fallos en la gestión de proyectos, debido a implantar recursos sin

experiencia al proyecto.

 Falta de preparación en la organización para adaptarse al cambio.

 Mala planificación, o estimaciones poco realistas.

 Falta de apoyo y compromiso de las principales partes interesadas.

 Objetivos poco claros, contradictorios o cambios en los objetivos durante la

ejecución del proyecto.

 Fallos en la comunicación, tanto interno como externo.

Factores que afectan la calidad del software: McCall y Cavano [John A.

McDermid ‘91] definieron un juego de factores de calidad como los primeros pasos

hacia el desarrollo de métricas de la calidad del software. Estos factores evalúan

el software desde tres puntos de vista distintos: (1) operación del producto

(utilizándolo), (2) revisión del producto (cambiándolo) y (3) transición del producto

(modificándolo para que funcione en un entorno diferente, por ejemplo:

“portándolo”) Los autores describen la relación entre estos factores de calidad (lo

que llaman un ‘marco de trabajo’) y otros aspectos del proceso de ingeniería del
software: En primer lugar el marco de trabajo proporciona al administrador

identificar en el proyecto lo que considera importante, como: facilidad de

mantenimiento y transportabilidad, atributos del software, además de su corrección

y rendimiento funcional teniendo un impacto significativo en el costo del ciclo de

vida. En segundo lugar, proporciona un medio de evaluar cuantitativamente el

progreso en el desarrollo de software teniendo relación con los objetivos de

calidad establecidos. En tercer lugar, proporciona más interacción del personal de

calidad, en el esfuerzo de desarrollo. Por último, el personal de calidad puede

utilizar indicaciones de calidad que se establecieron como ”pobres” para ayudar a

identificar estándares “mejores” para verificar en el futuro. Es importante destacar

que casi todos los aspectos del cálculo han sufrido cambios radicales con el paso

de los años desde que McCall y Cavano hicieron su trabajo, teniendo gran

influencia, en 1978. Pero los atributos que proporcionan una indicación de la

calidad del software siguen siendo los mismos. Si una organización de software

adopta un juego de factores de calidad como una “lista de comprobación” para

evaluar la calidad del software, es probable que el software construido hoy siga

exhibiendo la buena calidad dentro de las primeras décadas del siglo XXI. Incluso,

cuando las arquitecturas del cálculo sufrán cambios radicales (como seguramente

ocurrirá), el software que exhibe alta calidad en operación, transición y revisión

continuará sirviendo a sus usuarios.

Tipos de herramientas de calidad:

Las herramientas de control de calidad se utiliza ´para determinar, medir, analizar,

y proponer solucione a los problemas identificados que interfieren con el

rendimiento de los procesos  de la organización, ayudando a mejorar los

indicadores de calidad.

Aunque hemos hecho referencia a algunas de estas herramientas de control

de calidad, en algunos textos anteriores, aún no habíamos publicado una entrada

en la que abordáramos las 7 principales.

Estas herramientas surgen en los años 50, con base en conceptos y prácticas

existentes en el momento, y desde esa década se han utilizado como apoyo

a los sistemas de gestión, a través de modelos estadísticos contribuyen a la

mejora de los procesos y los procedimientos.

Es una denominación dada a un conjunto fijo de técnicas gráficas identificadas

como las más útiles en la solución de problemas relacionados con la calidad.

Se llaman básicas porque son adecuadas para personas con poca formación en

materia de estadística, también pueden ser utilizadas para resolver la gran

mayoría de las cuestiones relacionadas con la calidad.

Las siete herramientas básicas están en contraste con los métodos más

avanzados de estadística, tales como muestreos de encuestas, muestreos de

aceptación, pruebas de hipótesis, diseño de experimentos, análisis multivariados,

y los distintos métodos desarrollados en el campo de la Investigación de

operaciones.
Diagrama Causa – Efecto

Identifica muchas causas posibles de un efecto o problema y clasifica las ideas en

categorías útiles.

El enunciado del problema, colocado en la cabeza de la espina de pescado, se

utiliza como punto de partida para trazar el origen del problema hacia su causa

raíz.

Típicamente, el enunciado describe el problema como una brecha que se debe

cerrar o como un objetivo que se debe lograr. El mecanismo para encontrar las

causas consiste en considerar el problema y preguntarse “por qué” hasta que se

llegue a identificar la causa raíz o hasta que se hayan agotado las opciones

razonables

Diagrama de flujo

Muestran la secuencia de pasos y las posibilidades de ramificaciones que existen

en un proceso que transforma una o más entradas en una o más salidas. Los

diagramas de flujo muestran las actividades, los puntos de decisión, las

ramificaciones, las rutas paralelas y el orden general de proceso.

Los diagramas de flujos pueden resultar útiles para entender y estimar el costo de

la calidad de un proceso. Esto se consigue mediante la aplicación de la lógica de

ramificaciones del diagrama de flujo y sus frecuencias relativas para estimar el

valor monetario esperado para el trabajo conforme y no conforme requerido para

entregar la salida conforme esperada.

Estratificación
La estratificación es una técnica utilizada en combinación con otras herramientas

de análisis de datos. Cuando se han agrupado los datos de una variedad de

fuentes o categorías, el significado de los mismos puede ser imposible de ver.

Esta técnica los separa para que los patrones se puedan ver.

Hojas de verificación

También conocidas como hojas de control, se pueden utilizar como lista de

comprobación a la hora de recoger datos.

Las hojas de verificación se utilizan para organizar los hechos de manera que se

facilite la recopilación de un conjunto de datos útiles sobre un posible problema de

calidad.

Son especialmente útiles a la hora de recoger datos de los atributos mientras se

realizan inspecciones para identificar defectos. Por ejemplo, los datos sobre

frecuencias o consecuencias de defectos recogidos en las hojas de verificación se

representan a menudo utilizando diagramas de Pareto.

Diagrama de Pareto

Los diagramas de Pareto son una forma particular de un diagrama de barras

verticales y se utilizan para identificar las pocas fuentes clave responsables de la

mayor parte de los efectos de los problemas.

Las categorías que se muestran en el eje horizontal representan una distribución

probabilística válida que cubre el 100% de las observaciones posibles.

Las frecuencias relativas de cada una de las causas especificadas recogidas en el

eje horizontal van disminuyendo en magnitud, hasta llegar a una fuente por

defecto denominada “otros” que recoge todas las causas no especificadas. Por lo
general, el diagrama de Pareto se organiza en categorías que miden frecuencias o

consecuencias.

Histogramas

Son una forma especial de diagrama de barras y se utilizan para describir la

tendencia central, dispersión y forma de una distribución estadística. A diferencia

del diagrama de control, el histograma no tiene en cuenta la influencia del tiempo

en la variación existente en la distribución.

Diagramas o gráficos de control

Se utilizan para determinar si un proceso es estable o tiene un comportamiento

predecible.Los límites superior e inferior de las especificaciones se basan en los

requisitos establecidos previamente. Reflejan los valores máximo y mínimo

permitidos. Puede haber sanciones asociadas al incumplimiento de los límites de

las especificaciones. Los límites de control superior e inferior son diferentes de los

límites de las especificaciones. Estos se determinan mediante la utilización de

cálculos y principios estadísticos estándar para establecer la capacidad natural de

obtener un proceso estable.

Se puede utilizar los límites de control calculados estadísticamente para identificar

los puntos en que se aplicarán medidas correctivas para prevenir un desempeño

anormal. En general la acción correctiva busca el mantener la estabilidad natural

de un proceso estable y eficaz.

Para procesos repetitivos, los límites de control se establecen por lo general en ±3

s alrededor de una media del proceso, que se establece a su vez en 0 s.

 Un proceso se considera fuera de control cuando:

1. Un dato excede un límite de control.

2. Siete puntos consecutivos se encuentran por encima de la media, o

3. Siete puntos consecutivos se sitúan por debajo de la media.

Se puede utilizar los diagramas de control para monitorear diferentes tipos de

variables de salida. Se utilizan con mayor frecuencia para realizar el seguimiento

de actividades repetitivas relativas a la fabricación de lotes.

Diagramas de dispersión

Representan pares ordenados (X, Y) y a menudo se les denomina diagramas de

correlación, ya que pretenden explicar un cambio en la variable dependiente Y en

relación con un cambio observado en la variable independiente X.

La dirección de la correlación puede ser proporcional (correlación positiva), inversa

(correlación negativa), o bien puede no darse un patrón de correlación (correlación

cero). En caso de que se pueda establecer una correlación, se puede calcular una

línea de regresión y utilizarla para estimar cómo un cambio en la variable

independiente influirá en el valor de la variable dependiente.