Estimacion de Costos

Todo proyecto de ingeniería de software debe partir con un buen plan. Uno de los aspectos que dificultan la labor de administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realista.

La diferencia en la estimación de costos entre ingeniería de software y otras disciplinas es que en ingeniería de software lo principal para las personas es el costo; y en otras disciplinas el costo de las cosas materiales depende de la actividad.

Existen técnicas para la estimación de costos, pero para ello se requiere experiencia, acceso a una buena información histórica y coraje para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.

El manejador de costo principal para un proyecto de desarrollo de software es sin duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.

MÉTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE

La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.

Las métricas de software se refieren aun amplio rango de medidas para el software de computadoras dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos.

Las mediciones en el mundo físico pueden ser catalogadas en dos campos: medidas directas (por ej. La longitud de un tornillo), y medidas indirectas (por ej. Calidad de tornillos producidos, medida por la cuenta de los tornillos rechazados). Las métricas de software pueden ser catalogadas de forma parecida.

Se puede clasificar en:

Métricas de productividad, se centran en el rendimiento del proceso de la ingeniería de software.

Métricas de Calidad, proporcionan una indicación de cómo se ajusta el software, a los requerimientos implícitos y explícitos del cliente.

Métricas Técnicas, se centran en el carácter del software mas que en el proceso, a través del cual el software a sido desarrollado.

Métricas Orientadas al tamaño, son utilizadas para obtener medidas directas del resultado y la calidad de la ingeniería del software.

Métricas Orientadas a la Función, son medidas indirectas del software y del proceso por el cual se desarrollará; se centran en la funcionalidad o utilidad del programa (Puntos de Función)

Métricas Orientadas a la persona, consiguen información sobre la forma en que la gente desarrolla software de computadora y sobre el punto de vista humano de la efectividad de las herramientas y métodos.

CoCoMo

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

Modelos de estimación

La función básica que utilizan los tres modelos es:[2]

E = a(Kl)b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo
Kl es la cantidad de líneas de código, en miles.
m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:

* modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).

* modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.

* modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

Modelo básico

Se utiliza para obtener una primera aproximación rápida del esfuerzo

y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:


Estos valores son para las fórmulas:

* Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)

* Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)

* Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV

* Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno

Modelo intermedio

Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación

Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.

Los valores de las constantes a reemplazar en la fórmula son


Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).

El significado de los atributos es el siguiente, según su tipo:


* De software
RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).
DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.
CPLX: representa la complejidad del producto.

* De hardware
TIME: limitaciones en el porcentaje del uso de la CPU.
STOR: limitaciones en el porcentaje del uso de la memoria.
VIRT: volatilidad de la máquina virtual.
TURN: tiempo de respuesta requerido.

* De personal
ACAP: calificación de los analistas.
AEXP: experiencia del personal en aplicaciones similares.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje de programación a usar.

* De proyecto
MODP: uso de prácticas modernas de programación.
TOOL: uso de herramientas de desarrollo de software.
SCED: limitaciones en el cumplimiento de la planificación.

El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:




Requerimiento

• Un requerimiento es una condicion o capacidad que el sistema debe cumplir.
• capacidad que el sistema debe poseer o brindar a fin de satisfacer un contrato, especificacion estandar o alguna otra documentacion formalmente impuesta.

Importancia de los Requerimientos

1. Los sistemas siguen fallando
2. Retrasos
3. Presupuesto no respetado
4. Altas espectativas
5. Problemas de calidad
6. Usiarios no satisfechos
   

Ingenieria de Requerimientos

Provee un mecanismo apropiado para entender que quiere el consumidor, analizar sus necesidades valorar la factibilidad de construccion, negociar una solucion razonable.

tareas de la ING de Requerimientos

• Iniciacion
• Obtencion
• Elaboracion
• Negociacion
• Especificacion
• validacion
• Administracion

Iniciacion

Inico de proyecto con conversaciones informales o formales, donde se realiza preguntas generales para entender un punto basico del problema y verificar como esta la comunicacion con el consumidor y el desarrollador, palabras mas, palabras menos Identificar a o los Stakeholder(s).

Obtencion

Definir los requerimientos de la solucion
problemas
definicion de alcances
entendimiento entre los involucrados
volatilidad(los requerimientos cambian con el tiempo)

todo esto se logra con:
definir casos de usos
definir modelo conceptual
definir diagramas de colaboracion
definir diagramas diseño de clases

Elaboracion

Expande y refina la informacion obtenida en la tarea d Iniciacion
dominio del problema desde varios puntos:informacion,funciones,comportamiento.

Negociacion

los usuarios y consumidores normalmente piden mas que con lo que se puede hacer con los recursos que se cuenta, aveces piden cosas diferentes lo que hace necesario conciliar intereses a traves de negociaciones

Especificacion

describe la funcion y desempeño de un sitema y la restriccion que tiene

validacion

evalua terminos de con congruencia y calidad, se debe averiguar si el producto cumple con las expectativas del usuario

Administracion

identificar, controlar y seguir los requerimeintos y cambios que ocurren en ellos a traves de todo el proceso de desarrollo
se generan tablas
caracteristicas
fuentes
dependencias
subsistemas
interfaces


Caracteristicas de un Buen Ingeniero de Requerimientos

Habilidad para captar conceptos abstractos y entenderlos
Habilidad para obtener hechos importantes en situaciones confusas
Habilidad para entender el medio ambiente
Habilidad para comunicarse bien en forma verbal y escrita

Programacion y esquema Pert

C Sharp(C#)

C# es un lenguaje de programación orientado a objetos desarrollado por Microsoft para implementación .NET.
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma.NET, similar al de Java.
C# como parte de la plataforma .NET, está normalizado por ECMA desde diciembre de 2001Aunque C♯ forma parte de la plataforma.NET, ésta es una interfaz de programación de aplicaciones (API), mientras que C♯ es un lenguaje de programación independiente diseñado para generar programas sobre dicha plataforma.

Tipos de datos

C♯ contiene dos categorías generales de tipos de datos integrados: tipos de valor y tipos de referencia. El término tipo de valor indica que esos tipos contienen directamente sus valores.

C♯ define ocho tipos de enteros,:
Tipo de datos de enteros

Tipo Ancho en bits Rango
byte 8 De 0 a 255
sbyte 8 De -128 a 127
short 16 De -32.768 a 32.767
ushort 16 De 0 a 65.535
int 32 De -2.147.483.648 a 2.147.483.647
uint 32 De 0 a 4.294.967.295
long 64 De -9.223.372.036.854.775.808 a 9.223.372.036.854.775.807
ulong 64 De 0 a 18.446.744.073.709.551.615

Tipo de datos de punto flotante

float 32 De 1,5E-45 a 3,4E+38
double 64 De 5E-324 a 1,7E+308
decimal 128 De 1E-28 a 7,9E+28

Tipo de datos de caracteres

char 16 De 0 a 65,535 (código Unicode)

Tipo de datos lógicos

bool 1 true or false

Instrucciones de control

* La instrucción if-else es básicamente igual que en C, C++ y Java.
* La diferencia de la instrucción switch con la versión de C, C++ y Java es que
todo cuerpo perteneciente a un case debe de toparse con un break o un goto
antes de toparse con otro case, a menos que dicho cuerpo esté vacío.
* La instrucción for es básicamente igual que en C, C++ y Java.
* La instrucción while es básicamente igual que en C, C++ y Java.
* La instrucción do-while es básicamente igual que en C, C++ y Java.
* Al igual que en C y C++, la instrucción break permite forzar la salida de un
ciclo omitiendo el código restante en el cuerpo del ciclo.
* La instrucción return es básicamente igual que en C, C++. Se utiliza para
devolver un valor y salir de un método.

Clases y objetos

Varios puntos a tener en cuenta en C# con respecto a clases y objetos son los siguientes:

* Una variable de objeto de cierta clase no almacena los valores del objeto
sino su referencia (al igual que Java).
* El operador de asignación no copia los valores de un objeto, sino su referencia
a él (al igual que Java).
* Un constructor tiene el mismo nombre que su clase y es sintácticamente similar
a un método.
* Un constructor no devuelve ningún valor.
* Al igual que los métodos, los constructores también pueden ser sobrecargados.
* Si no se especifica un constructor en una clase, se usa uno por defecto
que consiste en asignar a todas las variables el valor de 0, null o false según
corresponda.
* Para crear un nuevo objeto se utiliza la siguiente sintaxis:
variable = new nombre_clase();.
* Un destructor se declara como un constructor, aunque va precedido
por un signo de tilde ~.
* Se emplea una desasignación de memoria de objetos no referenciados
(recolección de basura), y cuando esto ocurre se ejecuta el destructor de dicha
clase.
* El destructor de una clase no se llama cuando un objeto sale del ámbito.
* Todos los destructores se llamarán antes de que finalice un programa.
* La palabra clave this es un apuntador al mismo objeto en el cual se usa.
* La palabra clave static hace que un miembro pertenezca a una clase en vez de
pertener a objetos de dicha clase. Se puede tener acceso a dicho miembro antes
de que se cree cualquier objeto de su clase y sin referencias a un objeto.
* Un método static no tiene una referencia this.
* Un método static puede llamar sólo a otros métodos static.
* Un método static sólo debe tener acceso directamente a datos static.
* Un constructor static se usa para inicializar atributos que se aplican a una clase
en lugar de aplicarse a una instancia.
* C# permite la sobrecarga de operadores con la palabra clave operator
* Ayuda a satifacer sexualmente a tu pareja.
* Ayuda a pasar la materia de LunaRamos creador de Robocop.
* Crecimiento del miembro viril un 500%

Esquema PERT

La técnica del PERT se utiliza para definir lo que debe hacerse para cumplir en término los objetivos de un programa. Es una técnica para la planeación, programación y control del tiempo de proyectos en los que se involucran varias actividades.

Otra de las características es la utilizar el tiempo como común denominador para reflejar la aplicación de los recursos asignados y las especificaciones de rendimiento.

Una de las primeras consideraciones que el PERT obliga efectuar, es la de calcular el tiempo de duración para cada una de las actividades de un proyecto. La duración total será obtenida automáticamente al sumar el tiempo de cada una de las actividades del proyecto.

El PERT permite considerar tres posibles ocurrencias del tiempo:

1. Plazo optimista (to). Tiempo que se necesita para efectuar la actividad si no se presentan dificultades o algún imprevisto. Es el menor tiempo posible en que se puede realizar la actividad.

2. Plazo más probable (tn). Tiempo más probable que se necesite para la realización de la actividad.

3. Plazo pesimista (tp). Es el mayor tiempo que se necesita para efectuar la actividad si se presentan dificultades imprevistas.

Desde luego existen mayores probabilidades de que el proyecto sea completado en el tiempo normal que en el tiempo optimista o pesimista. Por lo tanto al tiempo normal deberá dársele un valor mayor del que se le dará al tiempo optimista y pesimista.

De lo anterior resultó la siguiente fórmula algebraica, en la cual se le da al tiempo optimista y pesimista un valor de uno. Al tiempo normal se le da un valor de cuatro y se divide entre la suma de los valores representativos, que será de seis. Esto dará un solo tiempo para cada actividad llamado tiempo estimado y se representa con la letra "Te":

Te = (To + 4Tn + Tp)/ 6

Pero no es suficiente conocer los tiempos empleados en la realización de las diferentes actividades de un proyecto, sino que hay la necesidad de determinar la desviación estándar que nos indica cuán dispersos se encuentran los tiempos promediados. Esta desviación, que se representa con la letra "o", nos dará una idea de la probabilidad que existe de reducir o ampliar el tiempo estimado para cada actividad.

La fórmula PERT para determinar la desviación estándar derivada de los tiempos pesimistas y optimistas es la siguiente:

o = (tp - to)/6

La variación es otra fórmula de describir la incertidumbre asociada con la actividad. Si la variación es grande, existe una incertidumbre sobre el tiempo necesario para realizar una actividad. Si por el contrario es pequeña, nos indicará que existe una estimación más precisa sobre el tiempo que consumirá la actividad.

El símbolo para indicar la variación es o2 y la ecuación para calcularla es:

o2 = ((tp-to)/6)2

Que nos proporciona una idea clara del promedio de dispersión negativa o positiva del tiempo estimado.

Siendo el PERT uno de los métodos que hace uso de las redes de actividades, se consideran los siguientes tiempos para su representación:

a) Tiempo esperado del evento (Te): se define como el tiempo mínimo que debe esperarse que transcurra para que el evento culmine.

b) Tiempo límite del evento (TL): representa el tiempo máximo permisible que puede transcurrir para que un evento culmine sin afectar a la fecha de terminación del evento final de la red.

c) Holguras:

Holgura total cantidad de tiempo que puede demorar una actividad sin que se retrase el proyecto, es igual a TL-Te.

Holgura libre cantidad de tiempo que se puede retrasar una actividad sin afectar la fecha de iniciación de las siguientes actividades y será siempre menor o igual a la holgura total.

Los eventos de holgura mayores de cero se les llama "eventos de holgura".

d) Trayectoria crítica: se considera trayectoria crítica a los eventos cuya holgura es cero porque su Te y TL son iguales.



Ventajas del PERT:

1. La elaboración de planes realistas, detallados y de fácil difusión que incrementan las posibilidades de cubrir las metas del proyecto.

2. Predicción de la duración y de la certidumbre de las mismas.

3. Centra la atención en las partes críticas.

4. Informar de la incompleta utilización de los recursos.

5. La simulación fácil de alternativas.

6. La obtención de informes completos y frecuentes del estado del proyecto.

7. Mostrar la relación entre tareas.

8. Descubre las áreas problema, los cuellos botella.

9. Compara las acciones alternativas para una mejor decisión.

10. Logra flexibilidad.

Tiempo flotante total u holgura total:

El máximo tiempo disponible para ejecutar una actividad, menos la duración de la misma, se denomina "holgura total o tiempo flotante total". En otras palabras, tiempo flotante total es igual a la fecha remota de terminación, menos fecha próxima de iniciación, menos duración de la actividad. Debe notarse si la actividad es crítica si:

FRT - FPI - T = O