Gestión y control de proyectos

Dentro de la Ingeniería la gestión o control de proyecto básicamente engloba las mismas características independientemente de la rama que se escoja o el ángulo desde el cual se mire,
Los primero es determinar cual es el objetivo que es lo que queremos alcanzar con tales fines, y luego que ha finalizado, lo que se quiere es analizar que sucedió con el proyecto ya finalizado.
Y las preguntas o interrogantes numérica cuáles son? Las mismas básicamente para todos los casos.
1.- En cuanto tiempo estará listo?
2.- Que personal y cuantos en total necesito?
3.- Cuanto me cuesta eso?
Ahora bien en el plano particular de la gestión de proyectos de software, es una rama de la ingeniería de Software, que posee su propia metodología además de la generales de la ingeniería normal.
Las gestiones dentro de un proyecto de software deben realizarse según el tipo de proyecto que se plantee, entre los cuales se encuentran:
Los proyectos nuevos: es por supuesto el más complicado por todo lo que implica un proyecto nuevo.
Replanteo de proyectos viejos: se busca corregir y actualizar la metodología de estimación.
Extensión o ampliación de un proyecto existente: para esta tipo de proyecto lo que se busca es tener buena precisión entre costos y plazos de ejecución.

Tamaño de los proyectos

Los proyectos de software son diferentes por la sola razón de su tamaño. Por lo que existen tres categorías diferenciadas de proyectos con problemas diferentes cada una:
Proyectos pequeños: conciten solamente en implementación. No tienes costos indirectos importantes.
Proyectos grandes: posees implementación, pero hay más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera información para mercadeo.
Proyectos medianos: es un caso intermedio entre los otros dos.
Un error clásico en la historia de la gestión de proyectos fue no advertir la existencia de tres categorías diferentes. Todavía hoy se sigue pensando que la información o la experiencia adquirida en proyectos pequeños pueden servir para proyectos medianos o grandes. Este es uno de los orígenes del los resultados catastróficos en la gestión de proyectos

Una breve historia de la gestión de proyectos.

En la década del 50 no se tenía metodología. La computación era incipiente. Neos diferenciaba bien entre software y hardware. Esta situación continúo hasta comenzada la siguiente década
En la década del 60 ocurre la primera gran crisis de la gestión de proyectos de software: la crisis del OS/360. La nueva línea de computadores de IBM, la líneas/360 planteo, por primera vez. La realización de un paquete de programación de tamaño mediano. Hasta este momento puede decirse que todos los proyectos eran pequeños, o si bien eran medianos se habían hecho en ambientes universitarios sin preocuparse por plazos y costos.
Con el sistema operativo de /360 IBM desborda todos los plazos y costos imaginables. De este primer gran atraso (que no fue el único atraso en la entrega de software,) nace la gestión de proyectos.
La década del 70 se caracteriza por la realización de los grandes estudios empíricos. La difusión de las computadoras y la aparición de las minicomputadoras hacen que se disponga de muchos proyectos medianos y grandes. Con todo este material empírico se hacen gran cantidad de estudios. De estos estudios nacen modelos y metodologías
La década de 80 es el periodo de confrontación de los modelos e metodología con los grandes proyectos de software. Es paradojal, pero la difusión de las computadoras personales hace que los proyectos sean más complejos y exigentes. De todas estas tecnologías sobreviven solamente unas pocas de la confrontación con la realidad.
La década del 90, es la época de normalización de las metodologías. Ya se ha separado lo útil de la teórico, lo bueno de lo malo y se procede a normalizar las metodologías