1. Introducción a la Gestión de Proyectos.

1.1 Marco de la Gestión de ProyectosAnteriormente los proyectos se encontraban dirigidos más bajo

consideraciones técnicas, que de gestión, por lo que las actividades de

estimación y planificación quedaban como un acto protocolario al inicio del

proyecto. Posteriormente el seguimiento y control se realizaban sin el mínimo

de rigor, ocasionado por la baja calidad de la estimación y planificación,

provocando que las desviaciones de costo y tiempo sean consideradas como

algo natural en un proyecto de Software.

Por otra parte el incremento de las computadoras ha hecho posible concebir

sistemas más complejos, además conforme los costos del Hardware

disminuyen, los costos de producir Software tienen un mayor peso dentro del

costo del proyecto, y conforme los costos de desarrollo y mantenimiento del

Software crecen es necesario predecirlos y controlarlos, esto es algo que hasta

hoy en día los desarrolladores de Software han encontrado muy difícil de

realizar.

Acorde al crecimiento de la experiencia en el desarrollo de Software, se han

elaborado técnicas para el desarrollo de las especificaciones y el diseño, en la

actualidad estas disciplinas pueden enseñarse y aplicarse según reglas muy

precisas, sin embargo el uso constante de estas técnicas de especificación y

diseño de Software no ha resuelto el problema de la producción del Software,

el hecho es que no es suficiente avanzar a través de las etapas tradicionales

del proceso de construcción de Software, por lo tanto la clave del éxito en la

gestión del desarrollo de Software son: la adecuada gestión del proyecto de

desarrollo de software y la adecuada gestión del proceso de Software.

La gestión del proceso de Software es el conjunto de técnicas y actividades

que consienten en una adecuada gestión de los procesos personales de los

constructores y de los productos que participan en el proyecto para conseguir

un producto de Software de alta calidad de acuerdo a las necesidades de los

usuarios.

Un proyecto es una acción en la que recursos humanos, financieros y

materiales se organizan para acometer un trabajo único, el aspecto esencial de

un proyecto es el de ser un trabajo único que se realiza con una nueva

organización para producir un cambio beneficioso.

1.2 Tareas Críticas en la Gestión de ProyectosEl número de tareas identificables a realizarse por un director de proyectos en

el área de gestión de proyectos son muchas, sin embargo existen tres tareas

que son críticas:

a) Estimación de duración, costo y esfuerzo para la construcción del

producto.

b) Planificación de tareas para realizarse, asignación de personas y tiempo

para desarrollar el producto.

c) Seguimiento durante la realización del trabajo para asegurar el

cumplimiento de lo planificado.

Estas tareas deben desarrollarse adecuadamente si se desea que el proyecto

finalice correctamente.

1.2.1 Estimación de ProyectosLa primera tarea en la gestión de proyectos es la estimación, la cual se define

como el proceso que proporciona un valor a un conjunto de variables para la

realización de un trabajo, dentro de un rango aceptable de tolerancia. Un

parámetro crítico es determinar su exactitud, la estimación puede realizarse a

partir de datos históricos o con herramientas, hoy en día existen unas

herramientas que proporcionan una estimación más exacta que la obtenida por

la propia empresa.

1.2.2 Planificación de ProyectosLa planificación de un proyecto es un proceso en el que se selecciona una

estrategia para la producción de productos finales, así como también la

definición de las actividades a realizarse para conseguir el objetivo.

La estimación y la planificación son actividades relacionadas pero difieren en

su alcance y propósito, por un lado la estimación se orienta al proyecto en todo

su conjunto, mientras que por otra parte la planificación esta dirigida a los

individuos, por lo que obviamente existe una fuerte correlación entre la

estimación realizada y las tareas específicas a realizar día a día por el equipo

de proyecto. La estimación es realizada al principio del proyecto, justamente

para solicitar el presupuesto y saber cuanta gente se necesita, entre otros

recursos., la planificación es una etapa en donde a cada persona qué hace y

en cuanto tiempo.

Una diferencia técnica entre las herramientas de planificación y estimación es

que las de estimación son normalmente sistemas expertos construidos a partir

de las reglas derivadas de varios proyectos. Las herramientas de planificación

no son sistemas expertos, sino herramientas para que sean utilizadas por

personas expertas. La razón de estas diferencias es que las herramientas de

estimación están basadas en miles de proyectos y pueden llegar a alcanzar

una gran exactitud, pero el trabajo de las personas que participan en el

proyecto con sus conocimientos, planes de vacaciones e interrupciones

requieren un director de proyectos expertos. Por lo que se dice que las

herramientas de planificación dan los mejores resultados con los mejores

directores. A diferencia de las herramientas de estimación estas, pueden

aumentar y mejorar las capacidades de los nuevos jefes de proyecto o de los

expertos.

1.2.2 Seguimiento de ProyectosUn seguimiento de proyecto es la recolección de datos y su almacenamiento

sobre tiempos, recursos, costos e hitos asociados con un proyecto, para el

análisis y estudio de la evolución real de dicho proyecto, comparando el

progreso real con el planificado, desafortunadamente el seguimiento de

proyectos de desarrollo de software no ha sido todo lo correcto que cabría

esperar.

1.2.4 Relación entre las Actividades Clave de la Gestión de Proyectos

Cuando se tiene una estimación inicial sobre el proyecto que se va a

desarrollar, se debe definir una planificación para el proyecto, siempre dentro

del marco de esa estimación, es decir que la salida del proceso de estimación

debe ser una de las entradas del proceso de planificación. Después de

realizarse la planificación, comienza el seguimiento del proyecto, por lo tanto,

las entradas del proceso de seguimiento serán la estimación y planificación del

proyecto, además de los datos reales recogidos mientras evoluciona el

proyecto. Durante la realización del proceso del seguimiento puede producirse

una replanificación, esto si nos apartamos del plan original.

La gestión del desarrollo del Software es ineficaz a causa de que dicho

desarrollo es extremadamente complejo. Por lo que sin una estimación eficaz y

exacta, la planificación y el seguimiento eficaz son prácticamente imposible de

conseguir.

2. Método de Estimación: Puntos de Función

2.1 Desarrollo de la técnica de Puntos de FunciónLos puntos de función miden el Software cualificando la funcionalidad que

proporciona externamente, basándose en el diseño lógico del sistema.

Unos de los objetivos de los puntos de función son:

a) Medir lo que el usuario pide y lo que recibe.

b) Medir independientemente de la tecnología utilizada en la implantación

del sistema.

c) Proporcionar un medio para la estimación del software.

Además de estos objetivos, el proceso de contabilizar los Puntos de Función

debería ser suficientemente simple para minimizar la carga de trabajo de los

procesos de medida y conciso en sus resultados.

El análisis de los Puntos de Función se desarrolla considerando cinco

parámetros básicos externos del Sistema.

1. Entrada

2. Salida

3. Consultas

4. Grupos de datos lógicos internos

5. Grupos de datos lógicos externos

Con estos parámetros se determinan los puntos de función sin ajustar. A este

valor se le aplica un Factor de Ajuste obtenido en base a unas valoraciones

subjetivas sobre la aplicación y su entorno, es decir, las características

generales del sistema.

La aplicación de dicha técnica de los Puntos de Función comprende los

siguientes pasos:

a) Definición de los límites del sistema

b) Definición de parámetros

c) Valoración de la complejidad

d) Análisis de las características generales del sistema.

2.2 Definición de los Límites del Sistema.El límite es utilizado para definir el alcance del sistema y ayudar a identificar los

parámetros externos. Existen tres visiones de los límites del sistema,

dependiendo de la utilización que quiera realizarse de la técnica.

1. La aplicación o límite del producto: abarca a la totalidad de la

aplicación, y se realiza la cuenta de puntos al final del desarrollo del

proyecto cuando se gestiona el grupo de mantenimiento o cuando la

organización inicia el uso de puntos de función ajustados

2. Límite inicial del proyecto a desarrollar: es un tipo de conteo similar al

anterior, la diferencia es que se deriva de los requisitos de un sistema

que aun no existe.

3. Límite del proyecto de mejora: surge cuando ya existe el sistema y se

trata de obtener nuevas versiones del mismo. La utilización de puntos de

función ajustados en proyectos de mejora difiere de las anteriores, en

que se consideran adiciones, modificaciones o anulaciones de

funcionalidades.

La formula que permite calcular los Puntos de Función de un nuevo desarrollo

es la siguiente:

Donde:

- FP es el número de Puntos de función sin ajustar la aplicación.

- AF es el Factor de Ajuste de la aplicación.

2.3 Análisis de las características generales del sistemaUna vez obtenidos el total de Puntos de Función sin ajustar, debe realizarse un

ajuste del mismo en función de las características generales del sistema.

1. Comunicación de datos.

2. Funciones distribuidas.

3. Rendimiento.

4. Configuraciones fuertemente utilizadas.

5. Frecuencia de transacciones.

6. Entrada on-line de datos.

7. Diseño para la eficiencia del usuario final.

8. Actualización on-line.

9. Procesos complejos

10.Utilización en otros sistemas.

11.Facilidad de Instalación.

12.Facilidad de operación

13. Instalación de Múltiples sitios

14.Facilidad de cambio.

En función de estas catorce características se calcula el grado de influencia,

una vez demostrado el grado de influencia de las características, se puede

llegar al valor del factor de ajuste mediante la fórmula:

FPA = FP X AF

AF = (TDI x 0.01) + 0.65

El valor final de Puntos de Función ajustados será:

Existe un debate general sobre las características generales del sistema, ya

que en gran parte su evaluación es subjetiva y por otro lado su valor

multiplicador es muy bajo. Sin embargo, forma parte de la técnica y en el futuro

se prevé que sea uno de los aspectos más importantes en la evolución de la

misma.

Para usar eficientemente los Puntos de Función, se emplean unos rangos

relativos a las siguientes métricas:

a) Productividad: número de Puntos de Función que puede desarrollar una

persona en un mes.

b) Calidad: número de errores que supuestamente se cometerán por Punto

de Función.

c) Costo: dinero en pesos que le constará a la empresa el desarrollo de un

Punto de Función.

d) Documentación: número de páginas de documentación que será

generada por Punto de Función.

e) Líneas de Código: número de líneas de un determinado lenguaje de

programación, que se escribirán por Puntos de Función.

Estos rangos estarán medidos en:

- Productividad = punto de función / persona-mes

- Calidad = errores / punto de función

- Costo = dinero en pesos / punto de función

- Documentación = páginas / punto de función

- Líneas de código = líneas / punto de función

La clave de utilizar esta técnica radica en la obtención de estos rangos, que

serán específicos de cada organización, y que n os darán información sobre el

FPA = FP x AF

tamaño de la aplicación. Estos rangos se obtendrán de proyectos anteriores

que se hayan desarrollado en la organización.

3. Método de Estimación: COCOMO II

3.1 Antecedentes de COCOMO IIEl modelo original COCOMO se público por primera vez en 1981 por Barry

Boehm y reflejaba las practicas en desarrollo de software de aquel momento.

En la década y media siguiente las técnicas de desarrollo de software

cambiaron drásticamente, estos cambios incluyen el gasto de esfuerzo en

diseñar y gestionar el proceso de desarrollo de software como en la creación

del producto de software, un giro total desde los mainframe que trabajan con

procesos batch nocturnos hacia los sistemas en tiempo real y un énfasis

creciente en la reutilización de software ya existente y en la construcción de

nuevos sistemas que utilizan componentes de software a la medida.

Estos cambios hicieron que la aplicación del modelo COCOMO original

empezara a resultar problemática y la solución al problema era reinventar el

modelo para aplicarlo en los 90’s. Después de años de esfuerzo, el resultado

es COCOMO II, un modelo de estimación de costo que refleja los cambios en

la práctica de desarrollo de software profesional. Este nuevo y mejorado

COCOMO resultará de gran ayuda para los estimadores profesionales de costo

de software.

Por lo que COCOMO II es un modelo que permite estimar el costo, esfuerzo y

tiempo cuando se planifica una nueva actividad de desarrollo de software.

COCOMO II apunta hacia los proyectos de software de los 90’s y de la primera

década del 2000 y continuará evolucionando durante los próximos años.

Los objetivos a la hora de la creación de COCOMO II fueron

- Desarrollar un modelo de estimación de tiempo y costo del software de

acuerdo con los ciclos de vida utilizados.

- Desarrollar bases de datos con costos de software y herramientas de

soporte para la mejora continua del modelo.

- Proporcionar un marco analítico cuantitativo y un conjunto de

herramientas y técnicas para la evaluación de los efectos de la mejora

tecnológica del software en costo y tiempo del ciclo de vida del software.

Los cuatro elementos de la estrategia que ha seguido COCOMO II son

- Preservar la apertura del COCOMO original.

- Desarrollar COCOMO II de forma que sea compatible con el futuro

mercado del software.

- Ajustar las entradas y salidas de los submodelos de COCOMO II al nivel

de información disponible.

- Permitir que los submodelos de COCOMO II se ajusten a las estrategias

de procesos particulares de cada proyecto.

COCOMO II sigue los principios de apertura usados en el COCOMO original.

De esta manera todos sus algoritmos y relaciones están disponibles

públicamente. Todas sus interfaces están diseñadas para ser públicas, bien

definidas y parametrizadas para que los procesos complementarios, post-

procesos y paquetes de alto nivel puedan combinarse estrechamente con

COCOMO II.

Para apoyar a los diferentes sectores de software COCOMO II proporciona una

familia de modelos de estimación de costo de software cada vez más detallado

y tiene en cuenta las necesidades de cada sector y el tipo de información

disponible para sostener la estimación del costo de software. Esta familia de

modelos se encuentra compuesta por tres submodelos, donde cada uno ofrece

mayor fidelidad a medida que uno avanza en la planificación del proyecto y en

el proceso de diseño.

Estos submodelos se denominan

- El modelo de Composición de Aplicaciones: para proyectos construidos

con herramientas modernas de construccion.

- El modelo de diseño anticipado: para obtener estimaciones aproximadas

del costo de un proyecto antes de que esté determinada por completo su

arquitectura.

- El modelo Post-Arquitectura: es el modelo COCOMO II mas detallado,

se utiliza ya que se ha desarrollado por completo la arquitectura del

proyecto.

INTRODUCCIONANTECEDENTES

En este punto debe comentar cómo se interesó en el proyecto, dónde, cuándo,

qué o quién lo estimuló para llevarlo a cabo.

Desarrolle el marco de referencia del problema indicando: el lugar, áreas con

las que interactúa, desde dónde se conoce el problema. Es importante

comentar el enfoque con que se está analizando el problema

Manifestar todo lo que conoce sobre el tema que pretende desarrollar, lo más

amplio y completo que se pueda. Es deseable que indique sus referencias

sobre el tópico, las disciplinas comprendidas, la bibliografía y todos los posibles

detalles que permitan evaluar su conocimiento del tema.

 

Lo que se busca es conocer qué tanto sabe y entiende del tema el egresado

que lo propone, a fin de tener los elementos de juicio necesarios para

determinar sus posibilidades de desarrollo de la investigación propuesta.

DEFINICION DEL PROBLEMAJUSTIFICACIÓNOBJETIVO

.