domingo, 1 de julio de 2007

1 Motivación

La planificación de un proyecto se basa en una buena estimación del esfuerzo requerido para realizarlo, y para apoyar esta difícil tarea, se han desarrollado varios métodos que han encontrado aceptación comercial en forma creciente en la planificación del desarrollo de software.

La mayoría de estos métodos incluyen modelos empíricos de estimación y poseen como variable manejadora del costo principal el tamaño de la aplicación a desarrollar, lo que es suficientemente difícil de estimar como para que se justifique pensar en automatizar o apoyar fuertemente esta tarea con la generación de un método fácil de usar.

Por otro lado, aquellos modelos que fueron desarrollados con base empírica, pueden carecer de validez en ambientes de desarrollo distintos a aquel del que se obtuvieron los datos.

Para el caso de los modelos basados en líneas de código, se puede observar que en la actualidad, las herramientas de desarrollo proveen la capacidad de disminuir substancialmente el esfuerzo de codificación, pues la tendencia actual ya no es codificar, sino generar código. Por el lado de las técnicas basadas en el enfoque de puntos de función, el problema radica en que la estimación sólo puede realizarse con un diseño externo acabado de la aplicación, y si consideramos la utilización de herramientas de generación de código (CASE o 4GL's), a la altura en que por fin se puede realizar la estimación ya se ha consumido la mayor cantidad del esfuerzo del desarrollo (es decir, si antes el esfuerzo se centraba en la fase de construcción vía codificación en algún lenguaje de programación, hoy el esfuerzo se centra en las fases de diseño, ya que la codificación se ve fuertemente asistida por herramientas automatizadas), por lo que la estimación ya no es tan útil.

Todos los puntos mencionados anteriormente, dificultan que la utilización de modelos de gestión sea una práctica generalizada en los administradores de proyectos de desarrollo de software.

2 Conceptos básicos de casos de uso

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Elementos

  • Actor:

    Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

  • Caso de Uso:

    Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

  • Relaciones:
    • Asociación

      Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

    • Dependencia o Instanciación

      Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

    • Generalización

      Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<>) o de Herencia (<>).

      Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

      extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

      uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

      De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

  • Registrar el número de ítemes ingresados.
  • Imprimir un recibo cuando el usuario lo solicita:
    1. Describe lo depositado
    2. El valor de cada item
    3. Total
  • El usuario/cliente presiona el botón de comienzo
  • Existe un operador que desea saber lo siguiente:
    1. Cuantos ítemes han sido retornados en el día.
    2. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
  • El operador debe además poder cambiar:
    1. Información asociada a ítemes.
    2. Dar una alarma en el caso de que:
      1. Item se atora.
      2. No hay más papel.


      Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

3 Algunas metodologías de estimación de esfuerzo

Otras técnicas de estimación de esfuerzos en proyecto de software son:
  • Puntos de Función.
  • COCOMO II

Puntos de Función.

La técnica de punto función, definida por Allan Albrecht, de IBM, en 1979 , es un método para medir el tamaño del software. Pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la explotación y mantenimiento.

Existen diferentes metodologías de medición, la más popular de las cuales es la mantenida por el International Function Point Users Group (IFPUG).

Método de recuento

La técnica de medición del tamaño en punto-función consiste en asignar una cantidad de "puntos" a una aplicación informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos. Siempre tratando de considerarlo desde el punto de vista del usuario.

Por ejemplo, el método IFPUG-FPA (Function Point Analisys) establece los siguientes pasos:

  • Determinar el tipo de recuento

Puede tratase de un proyecto, una mejora a una aplicación o recontar una aplicación ya instalada. Según el tipo se incluirán funciones de conversión, modificación y baja de funcionalidad.

  • Identificar el alcance del recuento y los límites de la aplicación

Se delimita el alcance de lo que se va a medir.

  • Contar las funciones de datos

Se realiza un inventario de los ficheros lógicos utilizados (vistos como un usuario) tanto internos de la aplicación como mantenidos por otra aplicación. Para cada uno de ellos se recuenta el número de datos y de registros lógicos. En función de este número se calcula para cada fichero un índice de complejidad y posteriormente una contribución en puntos función.

  • Contar las funciones transaccionales

De modo similar se inventarían los procesos elementales del sistema, distinguiendo los procesos de entrada, salida y consulta. Según el número de ficheros lógicos y datos que maneja cada proceso y de su naturaleza, se calcula su índice de complejidad y su contribución en puntos función.

  • Calcular el recuento bruto de puntos función

A partir de los recuentos anteriores se calcula un recuento total bruto (unadjusted).

  • Determinar el factor de ajuste

En función de 14 "características generales del sistema" que se valoran de 0 a 5 en función de su grado de influencia, se calcula un factor de ajuste al recuento.

Estas características tienen que ver con la arquitectura de la aplicación, sus requisitos de carga y rendimiento, complejidad de cálculos, etc..

  • Calcular el recuento ajustado

Aplicando el factor de ajuste al recuento bruto se obtiene el recuento final.

Crítica

La principal crítica que recibe esta métrica es la de requerir una dedicación adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados.

Su implantación en una organización no acostumbrada a su uso suele resultar penosa y requerir un fuerte compromiso de la dirección. Suele ser vista por los desarrolladores como un mecanismo de control de su trabajo.

Otros aspectos negativos serían:

  • Resulta arduo formar al personal en su utilización y más todavía mantener unos criterios homogéneos de recuento.
  • Carece de precisión cuando se trata de proyectos pequeños. Por debajo de unos 100 pf resulta demasiado poco fiable.
  • Para resultar realmente útil, una organización de desarrollo y mantenimiento de software debe tener recontada la mayor parte de su base instalada, pero hacerlo resulta muy costoso especialmente si mantiene software adquirido a terceros.
  • El factor de ajuste calculado a partir de las características generales del sistema resulta de dudosa utilidad.


COCOMO II

Propuesto y desarrollado por Barry Boehm, es uno de los modelos de estimación de costos mejor documentados y utilizados.

El método de estimación COCOMO II está basado dos modelos: uno aplicable al comienzo de los proyectos (Diseño preliminar, en inglés Early Design) y otro aplicable luego del establecimiento de la arquitectura del sistema (Post arquitectura, en inglés Post Architecture).

El modelo de Diseño preliminar (Early Design) contempla la exploración de las arquitecturas alternativas del sistema y los conceptos de operación. En esta etapa no se sabe lo suficiente del proyecto como para hacer una estimación fina. Ante ésta situación, el modelo propone la utilización de Puntos de Función como medida de tamaño y un conjunto de 7 factores (cost drivers) que afectan al esfuerzo del proyecto. Estos 7 factores son agrupaciones de los factores que se utilizan en la otra variante del modelo (Post Arquitectura).

El modelo Post arquitectura (Post Architecture) contempla el desarrollo y el mantenimiento de un producto software. Esta estrategia es más precisa si se ha desarrollado una arquitectura del sistema, la cual haya sido validada y establecida como base para la evolución del producto. Ante ésta situación, el modelo propone la utilización de Líneas de código fuente y/o Puntos de Función como medidores del tamaño, modificadores para indicar el grado de reutilización y descarte del software, un conjunto de 17 estimadores de costo, y un conjunto de 5 factores que afectan de manera exponencial en el esfuerzo del proyecto.




donde:

PM nominal: es el esfuerzo nominal requerido en meses-hombre

Size : es el tamaño estimado del software, en miles de líneas de código (KSLOC) o en Puntos de Función sin ajustar (convertibles a KSLOC mediante un factor de conversión que depende del lenguaje y la tecnología).

A : es una constante que se utiliza para capturar los efectos multiplicativos en el esfuerzo requerido de acuerdo al crecimiento del tamaño del software. El modelo la calibra inicialmente con un valor de 2.94.

B : es una constante denominada Factor escalar, la cual tiene un impacto exponencial en el esfuerzo y su valor está dado por la resultante de los aspectos positivos sobre los negativos que presenta el proyecto.




Inconvenientes

Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizar las tareas.

  • Se puede desviar de la realidad debido a la existencia de comentarios en las líneas de código.
  • No es objetivo puesto que se realizan estimaciones sobre estimaciones del número de líneas de código que tendrá nuestro proyecto.
  • Se mide el producto, o su tamaño, cosa totalmente diferente a medir la productividad.
  • La medición por líneas de código no tienen sentido en la orientación a objetos.



4 Método de puntos de casos de uso

Descripción

El método de Puntos de Casos de Uso es un método de estimación y cálculo de tamaño del software basado en cuentas hechas sobre los casos de uso para un sistema de software.

El método exige la existencia de un modelo de casos de uso, por lo que la labor deberá ser hecha cuando exista algún entendimiento del dominio del problema o cuando se esté realizando las labores de arquitectura y dimensionamiento del tamaño del sistema. Por lo general , estas condiciones están dadas al término de las actividades de Análisis.

En términos simples, el método requiere de casos de uso en modo textual y gráfico sólo en términos de mayor claridad, se revisan en detalle los casos de uso seleccionados en la etapa del proyecto que se defina y se realizan los siguientes pasos:

Cuantificación de caracaterísticas funcionales del Sistema:

· Clasificación de Actores, obtención del Peso de Actores Sin Ajustar (PASA).

· Clasificación de los Casos de Uso, obtención del Peso de Transacciones Sin Ajustar (PTSA)

· Obtención del Peso o Puntos de Casos de Uso Sin Ajustar (PCUSA).

Cuantificación de característias no funcionales del Sistema:

· Clasificación de Factores de Complejidad Técnica (FCT)

· Clasificación de Factores Ambientales (FA)

· Cálculo de Puntos de Casos de Uso Ajustados (PCU)

Cuantificación de características funcionales del Sistema.

La cuantificación de los requerimientos funcionales trata la extracción de información del modelo de caso de uso en su forma textual de acuerdo a una clasificación de Actores y Transacciones de los Casos de Uso.

Clasificación de Actores.

Se debe realizar un catastro de todos los actores del sistema y deben ser clasificados como Simple, Promedio y Complejo, de acuerdo al siguiente criterio:

  • Actor Simple: Se trata de otro sistema interactuando a través de una interfaz de programación definida y conocida (API).
  • Actor Promedio: Es otro sistema interactuando a través de un protocolo (como TCP/IP).
  • Actor Complejo: se trata de una persona interactuando con el sistema a través de una interfaz gráfica de usuario (GUI) o página Web.

Junto a la cuenta y clasificación de los actores se debe asociar un factor de peso de a cuerdo a la siguiente tabla:





Finalmente, se cuentan los actores de acuerdo a su clasificación o grado de complejidad, multiplicando cada subtotal por su factor de complejidad y sumando cada producto obteniéndose el peso de los actores sin ajustar (PASA).

Clasificación de Casos de Uso a partir de las Transacciones

Teniendo el modelo de casos de uso, cada uno de ellos debe clasificarse como Simple, Medio o Complejo, de acuerdo al número de transacciones descritas en el caso de uso, incluyendo los cursos de acción alternativos. La cuenta del número de transacciones puede ser hecha a través de la cuenta de los pasos descritos en el caso de uso en forma textual según el siguiente criterio:

  • Casos de Uso Simple: Tres o menos transacciones (o pasos).
  • Casos de Uso Promedio: entre 4 o 7 Transacciones.
  • Casos de Uso Complejos: Más de 7 Transacciones.

Los factores de peso asociados a la clasificación son los siguientes:






Al igual que las clasificación de los actoreslas cuentas de las transacciones de los casos de uso se multiplican por los factores de complejidad y finalmente se suman los productos obteniendose el peso de las transacciones sin ajustar (PTSA)

Obtención de Factores de Peso o Puntos de Casos de Uso Sin Ajustar (PCUSA).

Es la suma del Peso de los Actores Sin ajustar más el Peso de las Transacciones Sin Ajustar, es decir:

PCUSA = PASA + PTSA

Cuantificación de características no funcionales del Sistema.

El método considera las características de complejidad técnica tomando en cuenta algunos requerimientos no funcionales como un factor de ajuste al Sistema, y además, factores ambientales que se concentran en las características del equipo de desarrollo.

En ambos casosm, se debe evaluar cada Factor multiplicado por un valor que corresponde a los siguientes grados de influencia:

  • 0: Sin influencia
  • 3: Promedio
  • 5: Fuerte influencia

Clasificación de Factores de Complejidad Técnica (FCT)

Se adjunta tabla con los factores de peso que incorporan la complejidad técnica del sistema y algunas características no funcionales, en este caso, en cada uno de los ítems se tomaron en cuenta factores de complejidad propios de sistemas desarrollados bajo orientación a objetos.










Para obtener el factor final se debe multiplicar cada item (T1 a T13) por el grado de influencia sobre el sistema y se obtiene la suma llamada FactorT, de acuerdo a la siguiente Fórmula:

FCT = 0.6 + (0.01*FactorT)

Clasificación de Factores Ambientales (FA)

Corresponden en términos generales, las características del equipo de desarrollo en cuanto a perfiles, experiencia y capacidad técnica.


Para obtener el factor final se debe multiplicar cada item (F1 a F8) por el grado de influencia sobre el sistema y se obtiene la suma llamada FactorA, de acuerdo a la siguiente Fórmula:

FA = 1.4 + (-0.03*FactorA)

Cálculo de Puntos de Casos de Uso Ajustados (PCU)

Finalmente, se obtiene la siguiente fórmula que representa los puntos de casos de uso ajustados:

PCU = PCUSA* FCT*FA

5 Software de apoyo a la metodología

Algunos software o planillas de Excel que apoyan esta técnica son:




7 Bibliografía y fuentes de información

  • Estimación del esfuerzo basada en casos de uso

Mario peralta, centro de ingeniería del software e ingeniería del conocimiento , escuela de postgrado. Instituto tecnológico de buenos aires


http://www.itba.edu.ar/capis/rtis/rtis-6-1/estimacion-del-esfuerzo-basada-en-casos-de-usos.pdf


http://www.itba.edu.ar/capis/epg-tesis-y-tf/cao-trabajofinaldeespecialidad.pdf



  • Métodos de la ingeniería informática avanzada

Britos, p., y cia; centro de ingeniería del software e ingeniería del conocimiento; escuela de postgrado. Instituto tecnológico de buenos aires


http://www.ing.unp.edu.ar/wicc2007/trabajos/isbd/090.pdf


http://www.osmosislatina.com/lenguajes/uml/casos.htm




  • Documentos de estimación de esfuerzo en la red.

http://eiec.ucentral.cl/ftp/material/apuntes/iec61/diseno/metodo_pcu.doc


www.inf.udec.cl/~mvaras/papers/arica/arica.htm


http://www.inf.utfsm.cl/~guerra/publicaciones/estimaciondeproyectos_16_.pdf




  • Métrica de punto función

http://es.wikipedia.org/wiki/m%c3%a9trica_de_punto_funci%c3%b3n




  • El modelo cocomo II
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
http://www.ldc.usb.ve/~teruel/ci4713/clases2001/cocomo2.html

6 Conclusiones

El concepto de tamaño no es tan claro en la ingeniería de software como en otras disciplinas de la ingeniería.

Si bien existen dos factores fundamentales a examinar en la estimación de un proyecto Software, su duración y costo, la importancia cada vez mayor que toma la información Como factor estratégico ha determinado que sea la duración de un proyecto uno de lo aspectos más prioritarios en su realización.

La Estimación del esfuerzo basada en casos de uso resulta muy efectiva para estimar el esfuerzo requerido en el desarrollo de los primeros Casos de Uso de un sistema. En éste tipo de aproximación, los primeros Casos de Uso a desarrollar son los que ejercitan la mayor parte de la arquitectura del software y los que a su vez ayudan a mitigar los riesgos más significativos.