La Técnica de Revisión y Evaluación de Programas (en Inglés Program Evaluation and Review Technique), comúnmente abreviada como PERT, es un modelo para la administración y gestión de proyectos inventado en 1958 por la Oficina de Proyectos Especiales de la Marina de Guerra del Departamento de Defensa de los EE. UU. como parte del proyecto Polaris de misil balístico móvil lanzado desde submarino. Este proyecto fue una respuesta directa a la crisis del Sputnik.

PERT es básicamente un método para analizar las tareas involucradas en completar un proyecto dado, especialmente el tiempo para completar cada tarea, e identificar el tiempo mínimo necesario para completar el proyecto total.

Este modelo de proyecto fue el primero de su tipo, un reanimo para la administración científica, fundada por el fordismo y el taylorismo. A pesar de que cada compañía tiene su propio modelo de proyectos, todos se basan en PERT de algún modo. Sólo el método de la ruta crítica (CPM) de la Corporación DuPont fue inventado en casi el mismo momento que PERT.

La parte más famosa de PERT son las Redes PERT, diagramas de líneas de tiempo que se interconectan. PERT está diseñado para proyectos de gran escala, que se ejecutan de una vez, complejos y no rutinarios.

REDES PERT

Una malla PERT permite planificar y controlar el desarrollo de un proyecto. A diferencia de las redes CPM, las redes PERT trabajan con tiempos probabilísticos. Normalmente para desarrollar un proyecto específico lo primero que se hace es determinar, en una reunión multidisciplinaria, cuáles son las actividades que se deberá ejecutar para llevar a feliz término el proyecto, cuál es la precedencia entre ellas y cuál será la duración esperada de cada una.

Para definir la precedencia entre actividades se requiere de una cierta cuota de experiencia profesional en el área, en proyectos afines.

PRINCIPIOS

Estos tres principios deben respetarse siempre a la hora de dibujar una malla PERT:

* Principio de designación sucesiva: se nombra a los vértices según los

números naturales, de manera que no se les asigna número hasta que han sido nombrados todos aquellos de los que parten aristas que van a parar a ellos.

* Principio de unicidad del estado inicial y el final: se prohíbe la existencia de

más de un vértice inicial o final. Sólo existe una situación de inicio y otra de terminación del proyecto.

* Principio de designación unívoca: no pueden existir dos aristas que tengan

los mismos nodos de origen y de destino. Normalmente, se nombran las actividades mediante el par de vértices que unen. Si no se respetara este principio, puede que dos aristas recibieran la misma denominación

DURACIÓN DE UNA ACTIVIDAD

Para estimar la duración esperada de cada actividad es también deseable tener experiencia previa en la realización de tareas similares. En planificación y programación de proyectos se estima que la duración esperada de una actividad es una variable aleatoria de distribución de probabilidad Beta Unimodal” de parámetros (a, m, b) donde :

t_a = Se define como el tiempo optimista al menor tiempo que puede durar una actividad.

t_m = Es el tiempo más probable que podría durar una actividad

(Este corresponde al tiempo CPM, asumiendo que los cálculos son exactos).

t_b = Éste es el tiempo pesimista, o el mayor tiempo que puede durar una actividad.

t_e = Corresponde al tiempo esperado para una actividad.

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.

Este modelo fue desarrollado por Barry W. Boehm a fin

CARACTERÍSTICAS

Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.

INCONVENIENTES

• Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
• Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
• Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
• Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
• La medición por líneas de código no es válida para orientación a objetos.
• Utilizar esta modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).

MODELOS DE ESTIMACIÓN

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

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.