jueves, 31 de marzo de 2016

TÉCNICAS DE ESTIMACIÓN

Cuándo se definen las métricas de Software, se pueden considerar  diferentes técnicas para realizar la estimación.
Es muy importante realizar una estimación al momento de planear el desarrollo de un software para estimar el costo del proyecto, el recurso humano, el tiempo y los recursos que se usarán para el mismo.
Técnicas de Estimación

Puntos de Casos de Uso
La metodología de los puntos de casos de uso es una derivación de la metodología de puntos de función propuesta por Albretch. Este método de estimación fue desarrollado en 1993 por Gustav Karner de Rational Software, quien se basa en una metodología orientada a objetos y en la utilización de casos de uso como datos de entrada para calcular el esfuerzo en horas hombre (hh) que son necesarias para el desarrollo de un proyecto de software. 

Objetivo de la técnica
Estimar las horas necesarias para ejecutar un conjunto de casos de uso. Es decir, se necesita predecir cuanto tiempo llevara el desarrollo de software y cuantas personas se requieren para realizarlo. Para ello, es necesario cuantificar la complejidad del sistema y el tiempo necesario para producir una unidad de complejidad.

Clasificación de los Casos de Uso
Los casos de uso son clasificados de acuerdo a la cantidad de transacciones que poseen, incluyendo las transacciones de escenarios alternativos y excluyendo las extensiones o incluso de otros casos de uso. Un caso de uso simple (peso=5) es aquel que posee 3 o menos transacciones; uno medio (peso=10)  es aquel que posee de 4 a 7 transacciones; y un caso de uso complejo (peso=15)  es aquel que posee más de 7 transacciones. A   cada caso de uso le corresponde un peso. 

Factor de Complejidad Técnica del Proyecto de Software
Los factores técnicos (T) están definidos por las influencias técnicas que puedan afectar el proceso de desarrollo del sistema a construir. Cada factor técnico posee un grado de complejidad, que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5 determina un valor con alto grado de influencia. Cada factor técnico posee un valor de peso.

Factores de entorno del proyecto
Los factores de entorno (E) indican la influencia del grupo humano involucrado en el proyecto sobre el sistema a desarrollar. De manera similar a los factores técnicos, los factores de entorno poseen un grado de influencia que oscila entre 0 y 5, donde 0 significa un valor irrelevante o nulo y 5 determina un valor con alto grado de influencia. Cada factor de entorno posee un valor de peso. 


Pasos para determinar la estimación
Para determinar la estimación de los Puntos de Caso de Uso se deben cumplir los siguientes pasos:
  • Clasificar los actores para determinar el valor de UAW (Unadjusted Actor Weight).
UAW=Sumatoria de todos los pesos de los actores identificados.
  • Clasificar los casos de uso para determinar el valor de UUCW (Unadjusted Use Case Weight).
UUCW=Sumatoria de los pesos de los casos de uso.
  • Determinar el valor del UUCP (Unajusted Use Case Point, Puntos de Casos de Uso No Ajustados)
UUCP=UAW+UUCW
  • Determinar el valor de TCF (Technical Complexity Factor, Factores Técnicos de Complejidad)
TCF=0.6+(0.01*∑(T1 … T3)).
  • Determinar el valor de EF (Enviroment Factor, Factores de Entorno)
EF=1.4+(-0-03*∑(E1…E8))

  • Determinar el valor de AUCP(Adjusted Use Case Point)
AUCP=UUCP*TFC*EF
Karner establece un factor de 20hr hombre por punto de caso de uso para realizar la estimación de un proyecto de software.
UCP=AUCP*20
El valor de Use Case Point (UCP) obtenido indica el esfuerzo de horas hombre que se deben invertir para desarrollar el proyecto de software.
ESTIMACIÓN DEL ESFUERZO
Una vez obtenido el tamaño, se puede obtener el esfuerzo. Para ello se utiliza la expresión:
Esfuerzo=UCP* Factor de Productividad
El método originario propone usar un factor de ajuste similar al que se usa en el método de Puntos de Función clásico.
Contar los factores de entorno entre R1 y R6 cuya influencia es inferior a 3 (influencia promedio) y los factores de entorno entre R7 y R8 que son superiores a 3.
Entonces:
  • 20 horas-hombre por UCP si el valor es =2
  • 28 horas-hombre por UCP si el valor es=4
  • 36 horas-hombre por UCP si el valor es=5, en este caso se debería replantear el proyecto.

Puntos de Función

La técnica de Análisis de Puntos de Función fue introducida por Allan Albrecht de IBM. Albrecht comenzó a analizar sistemas buscando identificar los factores críticos que determinan el tamaño del software y por consiguiente, estimar el esfuerzo y el costo de desarrollarlo. Luego de analizar cientos de sistemas, nació la técnica de Análisis de Puntos por función. La técnica mide una aplicación con base en las funciones que éste realiza para y por solicitud del usuario final. 
Componentes de los Puntos de Función (PF)

La técnica mide lo que es el sistema y no como será o cómo será diseñado.
Características de los Puntos de Función:
  • Método independiente de las herramientas de análisis, diseño y programación, ya que solo se preocupa de la complejidad de las funciones a implementar.
  • Requerir de una descomposición funcional del proyecto a realizar, que se detecten todas las piezas elementales que componen el producto final.
  • Estimar la cantidad de Puntos de Función de las funciones medidas, se realiza contando la cantidad de entradas, salidas, archivos, consultas e interfaces que se utilizan. Entre mayor cantidad, mayor es el peso de complejidad que se le asignará.
  • Ajustar la estimación del esfuerzo requerido, para determinar la presencia de ciertos elementos que dificultan el desarrollo del proyecto.
  • Permitir realizar una estimación del esfuerzo requerido en etapas tempranas del proyecto. 
Para desarrollar la técnica de puntos de función se debe desarrollar una serie de pasos los cuáles se pueden ver en el siguiente link:
O se puede seguir el desarrollo que se explica en los siguientes vídeos.







El uso de técnicas de estimación es muy importante al momento de desarrollar software para poder mostrar al cliente una estimación del costo del proyecto y del tiempo, de acuerdo a los requerimientos que especifica.

jueves, 3 de marzo de 2016

MÉTRICAS DE SOFTWARE

MÉTRICA DE SOFTWARE
Es la aplicación continua de mediciones basadas en técnicas para el proceso de desarrollo del software y sus productos, de esta forma poder suministrar información relevante a tiempo y así el administrador junto con el empleo de estas técnicas mejorara el proceso y sus productos.

ACTIVIDADES DEL PROCESO DE MEDICIÓN
  • Formulación: La obtención de medidas y métricas del software apropiadas para la representación de software en cuestión.
  • Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
  • Análisis: Es el cálculo de las métricas y la aplicación de herramientas matemáticas.
  • Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación.
  • Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo de software.
MÉTRICAS DE PRODUCTO
  • Se centran en las características del software y no en cómo fue producido.
  • También son productos los artefactos, documentos, modelos, y componentes que conforman el software.
  • Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el esfuerzo.
MÉTRICAS DE PROCESO

Evalúan el proceso en sí de fabricación del producto correspondiente. Ejemplos de este tipo de métricas:
  • Tiempo de desarrollo del producto.
  • Esfuerzo que conlleva dicho desarrollo.
  • Número y tipo de recursos empleados (personas, máquinas. etc).
  • Costo del proceso.

Se emplean para fines estratégicos.
Se recopilan de todos los procesos y durante un largo periodo de tiempo.
MÉTRICAS DE PROYECTO
  • Permiten evaluar el estado del proyecto
  • Permiten seguir la pista de los riesgos
  • Son tácticas, las cuales permitirán al desarrollador de proyectos del software una evaluación al proyecto que sigue en continuo desarrollo, equivalente podrá ver los defectos que logren provocar riesgos a largo plazo (áreas problema) y observar si el área de trabajo (equipo) y las distintas tareas se ajustarán. 
MÉTRICAS DE CALIDAD
Las métricas de calidad ayudan a evaluar los modelos de análisis y diseño en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente, y ayudan en el diseño de pruebas más efectivas.
Modelos:
  • MCCALL: Describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre los factores de calidad, en base a criterios. Los factores de calidad se concentran en tres aspectos importantes de un producto de software: características operativas, capacidad de cambios y adaptabilidad a nuevos entornos.
  •  FURPS: Modelo desarrollado por Hewlett-Packard (HP) en 1987, desarrollando un conjunto de factores de calidad de software y sus respectivos atributos.
    Se basa en el modelo MCCALL y se utilizan para establecer métricas de la calidad para todas las actividades del proceso de desarrollo de un software, inclusive de un sistema de información. 
  • GILB: Definido en 1988 por Gilb, presenta como aspecto fundamental la definición de los atributos y el nivel de calidad que debe tener cada uno de ellos para satisfacer al usuario. La especificación de requisitos de calidad la realiza conjuntamente el usuario con el analista.
  • DROMEY: 
  1. Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guías de usuario, diseños y código).
  2. Sugiere el uso de cuatro categorías que implican propiedades de calidad que son: Correctitud, internas, contextuales y descriptivas. 
  • ISO 9126: 
El modelo ISO/IEC 9126  presenta el concepto de calidad en uso, la calidad externa y la calidad interna que corresponden con la visión del productor y del producto.
  1. Este modelo de ha desarrollado en un intento de identificar los atributos más importantes para la calidad interna y externa en un producto software.
  2. Define a la calidad interna como la totalidad de las características del producto software desde una perspectiva interna.
  3. La calidad externa se define como la totalidad de las características del producto software desde una perspectiva externa. 

  • MOSCA:  
Consta de 4 niveles: dimensiones, categorías, características y las métricas.
  1. Nivel 0. Dimensiones. Eficiencia del proyecto, efectividad del proceso, eficiencia del producto y efectividad del producto.
  2. Nivel 1. Categorías. Se contemplan 11 categorías: Producto: Funcionalidad (FUN), Fiabilidad (FIA), Usabilidad (USA), Eficiencia (EFI), Mantenibilidad (MAB) y Portabilidad (POR). Proceso: Cliente-Proveedor (CUS), Ingeniería (ENG), Soporte (SUP), Gestión (MAN) y Organizacional (ORG).
  3. Nivel 2. Características. Cada categoría tiene asociado un conjunto de características (56 asociadas al producto y 27 al proceso de desarrollo), las cuales definen las áreas claves a satisfacer para lograr, asegurar y controlar la calidad tanto en el producto como en el proceso.
  4. Nivel 3. Métricas. Para cada característica se propone una serie de métricas utilizadas para medir la calidad sistémica. 

Implementar métricas en el proceso de desarrollo de software garantizara a los clientes que su software será de calidad y que durante el desarrollo se cumplirá con cada requerimiento que se definió para cada fase  el tiempo estimado. A su vez el uso de métricas reduce los costos en el desarrollo ya que permite que se aprovechen todos los recursos en el menor tiempo posible y de esta manera entregar un producto funcional a los clientes que sea mantenible, robusto y sobre todo que se pueda adaptable.