jueves, 26 de mayo de 2016

¿QUE ES LA CALIDAD DEL SOFTWARE?

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.

La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.



¿COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.

El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.

El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?

Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se puede medir".

Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.

Todos los autores coinciden en que 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.
A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de Aseguramiento de la Calidad del Software.

CONCLUSIONES


Lograr el éxito en la producción de software es hacerlo con calidad y demostrar su buena calidad. Esto sólo es posible con la implantación de un Sistema para el Aseguramiento de la Calidad del Software directamente relacionado con la política establecida para su elaboración y que esté en correspondencia con la definición internacional ISO de calidad, amplia mente aceptada, y por los estándares del grupo ISO 9000.



Mantenimiento de Software


El Servicio de mantenimiento de software es una de las actividades en la Ingeniería de Software y es el proceso de mejorar y optimizar el software desplegado (revisión del programa), así como también remediar los defectos.

El mantenimiento de software es también una de las fases en el Ciclo de Vida de Desarrollo de Sistemas (SDLC ó System Development Life Cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo.

La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software






Tipos de mantenimiento

A continuación se señalan los tipos servicio de mantenimientos existentes, y entre paréntesis el porcentaje aproximado respecto al total de operaciones de mantenimiento:

Perfectivo (60%): Mejora del software ( rendimiento , flexibilidad , reusabilidad ..) o implementación de nuevos requisitos. También se conoce como mantenimiento evolutivo .

Adaptativo (18%): Adaptación del software a cambios en su entorno tecnológico (nuevo hardware, otro sistema de gestión de bases de datos , otro sistema operativo ...)

Correctivo (17%): Corrección de fallos detectados durante la explotación.


Preventivo (5%): Facilitar el mantenimiento futuro del sistema (verificar precondiciones, mejorar legibilidad.)

miércoles, 11 de mayo de 2016

MANTENIMIENTO Y REINGENIERIA

Mantenimiento y reingenieria de software.


El mantenimiento del software es una actividad que permite extender la vida utili del software y adaptarlo a las necesidades cambiantes de la organización.
El mantenimiento del software es un proceso natural del desarrollo de software, y puede ser clasificado según algunos autores en 4 clases de mantenimiento de acuerdo a la función u objetivo que persiga dicho mantenimiento:
1.- Mantenimiento correctivo
En este tipo de mantenimiento buscamos eliminar errores que no fueron detectados durante las pruebas al sistema, no porque no se hicieran las pruebas correctas, sino porque es imposible prever todas aquellas situaciones a las que nuestro software se enfrentara una vez que este en funcionamiento.
El problema con este tipo de mantenimiento es que podemos estar tratando con problemas de muy variados orígenes, siendo los mas problemáticos, aquellos que ocurren de forma esporádica, ya que resulta difícil encontrar las causas, dado que no siguen un patrón de causa-consecuencia.
Dentro de este tipo de mantenimiento tendremos actividades como:
  • Depuración del código
  • Corrección de mensajes y de interfaz
  • Ajustes para adaptar el software a hardware de uso especifico.
  • Corrección de vulnerabilidades.
2.- Mantenimiento adaptativo.
En este mantenimiento, el objetivo es como su nombre lo indica, adaptar el software a los cambios que ha sufrido la empresa desde que se le desarrollo el software.
Uno de los mayores peligros de este mantenimiento es el retraso, ya que si las actividades del mantenimiento adaptativo no se realización en el momento adecuado, puede llevarnos a hacer cambios mayores en la arquitectura del software.
Las actividades de este mantenimiento pueden incluir
  • Agregar nuevos módulos al sistema
  • Agregar nuevos reportes
  • Agregar nuevas funciones
  • Escalar las capacidades del sistema para el manejo de un mayor volumen de datos.
  • Agregar el manejo de nuevos datos en la base de datos.
3.- Mantenimiento de perfeccionamiento o mejoras.
En este, el objetivo es mejorar el sistema, es decir, el software no presenta fallas criticas y sigue vigente en la organización , con este mantenimiento nos referimos a ajustes menores que pueden incluir.
  • Agregar atajos
  • Nuevas funciones que no fueron solicitadas por el usuario, pero que generan una plusvalía en el software.
4.- Mantenimiento preventivo
Este mantenimiento tiene como objetivo, mantener el software funcionando en optimas condiciones, y es una actividad muy absorbente en sistemas de tipo gerencial y en sistemas empresariales para grandes organizaciones.
Entre las actividades del mantenimiento preventivo tendremos
  • Compactación de la base de datos.
  • Respaldo de la base de datos.
  • Eliminación de datos innecesarios u obsoletos.
  • Eliminación de claves y usuarios que ya no son parte de la organización
  • Mejoras en la seguridad para impedir ataques al sistema y/o robo de información.
Como vemos todas estas actividades pueden llegar a consumir demasiado tiempo.
Estas actividades pueden ser muy difíciles, sobre todo, si en el desarrollo del software no se aplicaron correctamente  los principios el diseño.
Ahora bien, sabemos que no se puede dar mantenimiento de forma eterna, no es técnica, ni económicamente viable, y es en este punto donde entra la ingeniería de software.
La reingeniería es un proceso de reconstrucción del software en el que aplicamos los procesos de ingeniería de software a un sistema que nos servirá de base o punto de partida, y del cual deberemos:
  • reestructurar los documentos
  • reestructurar los datos.
  • reestructurar el código.
Es decir descomponemos el software en sus partes fundamentales y comenzamos un  proceso de reconstrucción del mismo, dejando aquellas partes que se consideren  esenciales preservar de esa forma.
En muchos casos el proceso se lleva a cabo tantos años después que o bien ya no trabajan con nosotros los programadores originales o si somos nosotros mismos, ya no nos acordamos de los detalles y las especificaciones de nuestro trabajo.
Ante esta situación muchas veces se requiere recurrir a la ingeniería inversa, en la que tratamos de recuperar las especificaciones del diseño arquitectónico, de datos y de procesos de un software ya existente.

miércoles, 4 de mayo de 2016

ADMINISTRACION DE LA CONFIGURACION DEL SOFTWARE

Administración de la configuración del software

La Administración de la Configuración del Software (SCM) es la disciplina de identificar la configuración de un sistema en distintos puntos en el tiempo, con el propósito de controlar sistemáticamente cambios en la configuración del software y mantener la integridad y la rastreabilidad de la configuración a través del ciclo de vida del sistema. Esta área del conocimiento incluye seis subáreas.

La primera subárea es la administración del proceso de SCM. Cubre los tópicos del contexto de la organización para SCM, las restricciones y las guías para SCM, planeando para SCM, el plan mismo del SCM y la vigilancia del SCM.

La segunda subárea es la identificación de la configuración del software, la cual identifica los elementos que se controlarán, establece esquemas de identificación para los elementos y sus versiones, y establece las herramientas y las técnicas que se utilizarán en la adquisición y manejo de los artículos controlados. Los tópicos en esta subárea son, primero la identificación de los artículos que se controlarán y la biblioteca del software.
La tercera subárea es el control de la configuración del software, que es la administración de cambios durante el ciclo de vida del software. Los asuntos son, primero, solicitando, evaluando y aprobando los cambios al software, y segundo, implementar los cambios al software, y tercero, desviaciones y renuncias.

La cuarta subárea es contabilización del estado de la configuración del software. Sus tópicos son información de estado de la configuración del software y reportes de estado.

La quinta subárea es la revisión de la configuración del software. Que consiste en revisión de la configuración funcional del software, revisión de la configuración física del software y de revisiones en proceso de una línea base del software.

La última subárea es la administración de versiones y entrega, que cubre la construcción de software y la administración de versiones.

Los cambios dentro del desarrollo del software pueden ocurrir en cualquier momento por lo tanto debemos estar preparados, las actividades de CGS sirven para:
  • Identificar el cambio de nuestro software.
  • Controlar ese cambio.
  • Garantizar que el cambio quede bien implantado.
  • Informar el cambio.
La gestión de configuración del software no es un mantenimiento del software, el mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina sólo una vez que el software queda fuera de circulación.

Desgraciadamente, en el proceso de ingeniería del software existe una variable importantísima que entra en juego,el cambio.

La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida”.

Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema? ¿Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del desarrollo del software:
  • Nuevos requisitos del negocio o condiciones que dictan los cambios en las condiciones del producto o en las normas comerciales.
  • Nuevas necesidades del los clientes que demandan la modificación de los datos producidos por un sistema basado en computadora.
  • Reorganización y/o reducción del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software.
  • Restricciones presupuestarias o de planificaciones que provocan una redefinición del sistema o del producto.
La gestión de configuración del software realiza un conjunto de actividades desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del software de computadora.

La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases del proceso de ingeniería del software.

miércoles, 13 de abril de 2016

PRUEBAS DEL SOFTWARE

Pruebas de software

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Historia

El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste. Las pruebas de calidad presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad, facilitar información para la toma de decisiones, evitar la aparición de defectos.
Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más variada. Esto hace que el proceso de testing sea completamente dependiente del contexto1 en el que se desarrolla.
El ambiente ideal de las pruebas de testing es aquel que es independiente del desarrollo del software, de esta manera se logra objetividad en las pruebas.
A pesar de lo que muchos promueven, no existen las "mejores prácticas" como tal. Toda práctica puede ser ideal para una situación pero completamente inútil o incluso perjudicial en otra.
Por esto, las actividades, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar, deben ser seleccionados y utilizados de la manera más eficiente según contexto del proyecto.

Pruebas estáticas

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.
Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.

Pruebas dinámicas

Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.
Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de la aplicación desarrollada.

Tipos de pruebas

Hay todo tipo de pruebas, pero nos centraremos en tres de ellas:

Pruebas de Compatibilidad

Se comprueba el funcionamiento del software desarrollado en muchas plataformas: sistemas operativos, navegadores, redes, hardware...entre otros

Pruebas de Regresión

Se evalúa el correcto funcionamiento del software desarrollado frente a evoluciones o cambios funcionales. El propósito de éstas es asegurar que los casos de prueba que ya habían sido probados y fueron exitosos permanezcan así. Se recomienda que este tipo de pruebas sean automatizadas para reducir el tiempo y esfuerzo en su ejecución.

Pruebas de Integración

Es el nivel de pruebas posterior a las pruebas modulares de los componentes de un sistema. Se centra principalmente en probar la comunicación entre los componentes de un mismo sistema, comunicación entre sistemas o entre hardware y software.

Tipos de pruebas por su ejecución

·         Pruebas manuales
·         Pruebas automáticas
·         Enfoques de pruebas[editar]
·         Pruebas de Caja blanca
·         Pruebas de Caja negra
·         Testing aleatorio2

Niveles de pruebas

·         Pruebas unitarias
·         Pruebas modulares
·         Pruebas de integración
·         Pruebas de sistema
·         Pruebas de aceptación de usuario UAT

Pruebas funcionales

·         Pruebas funcionales
·         Pruebas de humo
·         Pruebas de regresión
·         Pruebas de aceptación
·         Alpha testing
·         Beta testing

Pruebas no funcionales

·         Pruebas no funcionales
·         Pruebas de seguridad
·         Pruebas de usabilidad
·         Pruebas de rendimiento
·         Pruebas de internacionalización y localización
·         Pruebas de escalabilidad
·         Pruebas de mantenibilidad
·         Pruebas de instalabilidad
·         Pruebas de portabilidad

miércoles, 6 de abril de 2016

METRICAS DEL PRODUCTO SOFTWARE OO

Métricas para Sistemas Orientados a Objetos

El Software Orientado a Objetos (OO) es fundamentalmente distinto del software que se desarrolla utilizando métodos convencionales. Las métricas parasistemas 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.

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

Características del software Orientado a Objetos

El software orientado a objetos es esencialmente distinto del software que se desarrolla utilizando métodos convencionales. Por esta razón, las métricas para sistemas 00 deben de concordarse a las características que distinguen el software 00 del software convencional.
Berard [Laranjeira ‘90] define cinco características que dan lugar a unas métricas especializadas:
· Localización,
· Encapsulamiento,
· Ocultamiento de información,
· Herencia y
· Técnicas de abstracción de objetos.

Localización

La localización es una característica del software que indica la forma que se concentra la información dentro de un programa. En el contexto OO, la información se concentra mediante el encapsulamiento tanto de datos como de procesos dentro de los límites de una clase u objeto.
Dado que el software convencional hace hincapié en las funciones como mecanismos de localización, las métricas de software se han centrado en la estructura interna o complejidad de las funciones (p. ej.: longitud del módulo, cohesión, o complejidad ciclomática) o bien en la forma en que las funciones se conectan entre sí (p. ej.: acoplamiento de módulos).
Dado que las clases constituyen la unidad básica de los sistemas 00, la localización está basada en los objetos. Por tanto, las métricas deberían de ser aplicables a la clase (objeto) como si se tratara de una entidad completa. Además, la relación entre operaciones (funciones) y clases no es precisamente uno-a-uno.
Por tanto, las métricas que reflejan la forma en que colaboran las clases deben de ser capaces de adaptarse a las relaciones uno-a-muchos y muchos-a-uno.

Encapsulamiento

Berard [Pressman ‘98] define el encapsulamiento como “el empaquetamiento (o enlazado) de una colección de elementos. Entre los ejemplos de encapsulamiento de bajo nivel (software convencional) se cuentan los registros y matrices, y los subprogramas (por ejemplo, procedimientos, funciones, subrutinas y párrafos) son mecanismos de nivel medio para el encapsulamiento”.
Para los sistemas 00, el encapsulamiento comprende las responsabilidades de una clase, incluyendo sus atributos (y otras clases para objetos agregados) y operaciones, y los estados de la clase, según se definen mediante valores específicos de atributos.
El encapsulamiento influye en las métricas cambiando el objetivo de la medida, que pasa de ser un único módulo a ser un paquete de datos (atributos) y de módulos de procesamiento (operaciones). Además, el encapsulamiento impulsa a la medida hasta un nivel de abstracción más elevado.

Ocultamiento de información

El ocultamiento de información suprime los detalles operativos de un componente de un programa. Tan sólo se proporciona la información necesaria para acceder a ese componente o a aquellos otros componentes que deseen acceder a él.
Un sistema 00 bien diseñado debería de impulsar al ocultamiento de información. Por tanto, aquellas métricas que proporcionen una indicación del grado en que se ha logrado el ocultamiento proporcionarán una indicación de la calidad del diseño 00.

Herencia

La herencia es un mecanismo que hace posible que los compromisos de un objeto se difundan a otros objetos. La herencia se produce a lo largo de todos los niveles de la jerarquía de clases, bien es sabido que en general, el software convencional, no admite esta característica.
Dado que la herencia es una característica fundamental de muchos sistemas 00, hay muchas métricas 00 que se centran en ella. Esto se conocerá entre los ejemplos que se tratarán más adelante: se cuentan el número de descendientes (número de instancias inmediatas de una clase), número de predecesores (número de generalizaciones inmediatas), y grado de anidamiento de la jerarquía de clases (profundidad de una clase dentro de una jerarquía de herencia) y otros.

Abstracción

La abstracción es un mecanismo que permite al diseñador centrarse en los detalles esenciales de algún componente de un programa (tanto si es un dato como si es un proceso) sin preocuparse por los detalles de nivel inferior. Cuando los niveles de abstracción van elevándose, se ignoran más y más detalles, por lo tanto, se proporciona una visión más general de un concepto u objeto. A medida que pasamos a niveles más reducidos de abstracción, se muestran más detalles, esto es, se proporciona una visión más específica de un concepto u objeto.


Dado que una clase es una abstracción que se puede visualizar con muchos niveles distintos de detalles, y de muchas maneras diferentes, las métricas OO representan la abstracción en términos de medidas de una clase (p.ej.: número de instancias por clase por aplicación).

miércoles, 23 de marzo de 2016

METRICAS DEL PROYECTO DEL SISTEMA DE INFORMACION DE ADMINISTRACION PARA LOS GIMNASIOS APP BODYPERFECT GYM

1.    METRICA ENTORNO AL PRODUCTO
-       FRECUENCIA DE ERRORES
Esta métrica será importante en la evaluación de nuestro producto del proyecto como tal, ya que con esta podremos evaluar la calidad y la eficiencia entorno al comportamiento que tendrá el sistema de información.
Una manera de medición de esta métrica seria:
N= número de errores del usuario
T= tiempo de la prueba o número de tareas

F = N / T
2.    METRICA ENTORNO AL PRODUCTO
-       ESCALA DE SATISFACCION
El propósito de esta métrica es tomar el nivel de satisfacción que puede expresar el usuario final frente a nuestro producto de software, la cual puede comprender varios aspectos en esta satisfacción como la navegabilidad, la funcionalidad, diseño y demás factores.
Esta métrica la podremos medir en nuestro producto con un simple cuestionario en el cual se aborden todas las posibles evaluaciones de cada uno de los componentes del producto.
A= calificación obtenida en el cuestionario
T = total posible de calificación del cuestionario
C= A / T





3.    METRICA ENTORNO AL PROYECTO (METRICA ORIENTADA A OBJETO- ORIENTADA A CLASES)
-       ARBOL DE PROFUNDIDAD DE HERENCIA (APH)
Esta métrica orientada a clases nos permitirá analizar en gran valor la herencia y la reutilización que se aplicaron en el diseño del código de cierto modulo.
Ya que a medida que va creciendo la longitud del APH  significara que mayor herencia y reusabilidad de métodos serán aplicados por las clases inferiores.
El siguiente esquema nos puede dar una imagen clara de cómo representar esta clase con sus subclases que reúsan sus métodos.



4.    METRICA ENTORNO AL PRODUCTO
-       TAREAS COMPLETADAS (EFECTIVIDAD)
En esta métrica se podrá evaluar la cantidad y proporción de numero de tareas o requerimientos que el producto puede realizar de una manera correcta tal y como se elaboró en el análisis del sistema. Permitiéndonos obtener un nivel de efectividad del sistema de información
Una fórmula para medir esta métrica podría aplicarse de esta manera:
EfectividadTareas= A / B
A= número de tareas completadas
B= tiempo de la tarea o requerimiento



HERRAMIENTAS DE SOFTWARE LIBRE PARA APLICAR METRICAS EN EL SOFTWARE

PMD.
Analizador estático de código que utiliza unos conjuntos de reglas para identificar problemas dentro del software. Detecta cosas como código duplicado (te recomiendo aquí este post), código muerto (variables, parámetros o métodos sin usar), complejidad de métodos (if innecesarios, etc., te recomiendo aquí este otro post sobre código complejo). Trabaja principalmente con lenguaje Java, aunque, con menos soporte, también posee conjuntos de reglas para JavaScript, xsl y ecmascript. Página oficial: http://pmd.sourceforge.net/.

Check Style.
Herramienta de análisis estático de código que se utiliza para comprobar que el código analizado cumple con una serie de reglas de estilo. Ejemplo, analiza el código según el estandar “Sun Code Conventions” (mira las cabeceras, importaciones de paquetes, Javadoc, etc.). Página oficial: http://checkstyle.sourceforge.net/. Trabaja para Java. La licencia es: GNU Lesser General Public License Version 2.1.

SONAR.
 Una herramienta de software libre y gratuita que permite gestionar la calidad del código fuente. Al instalarla podremos recopilar, analizar, y visualizar métricas del código fuente. Sonar es básicamente la fusión de las siguientes herramientas Checkstyle y PMD, más otras que no menciono en este post, como Findbugs, Clover y Cobertura. También realiza un histórico de todas las métricas del proyecto. Permite visualizar informes con resumenes de las métricas. Página oficial: http://www.sonarsource.org. Trabaja, principalmente, para Java. Aunque da soporte, gracias a la amplia librería de plugins (algunos de pago), a los siguientes lenguajes: ABAP, C, Cobol, C#, Delphi/Pascal, Flex/ActionScript, Groovy, JavaScript, Natural, PHP, PL/SQL, Visual Basic 6, Web y XML.  La licencia es: LGPL.

Google CodePro Analytix.
 Otra de las herramientas de calidad software, ofrece un entorno para evaluación de código, métricas, análisis de dependencias, cobertura de código, generación de Test unitarios, etc. Mira las excepciones, refactorizaciones potenciales (te dejo un post de refactorización), convenios de JavaDoc, métricas, etc. Disponible como plugin de Eclipse. Página oficial: http://code.google.com/intl/es-ES/javadevtools/codepro/doc/index.html. Trabaja para Java, concretamente en Eclipse. La herramienta es gratis.


Simian. Herramienta para detectar código duplicado (que es el mayor enemigo de la mantenibilidad, es decir, que si hay código repetido te va a costar más euros mantener el software, te recomiendo aquí este post) en desarrollos realizados con los lenguajes: Java, C#, C, C++, COBOL, Ruby, JSP, ASP, HTML, XML y Visual Basic. Página oficial: http://www.redhillconsulting.com.au/products/simian/. La licencia es libre si su uso está destinado a proyectos OpenSource.