Instituto

Instituto Tecnolgico
Superior De San Andrs Tuxtla
Carrera

Ingeniera En Sistemas Computacionales

Profesor@

MTI Montserrat Masdefiol Surez

Grupo

604 A
Alumnos

Anglica Rub Baxin Ruiz

Brenda Denis Vsquez Cortez
Anglica Isabel Cagal Malaga
Carolina Temich Fermn
Elfega Denis Romn Cortes
Izbeth Berenice Pucheta Fiscal
Jos Alberto Hernndez Snchez
Juan Francisco Temich Ponciano
Mnica Daisy Velasco Hernndez
Omar Chigo Acua
Petra Yadira Hernndez Texna
Santiago Jess Notario Gasca
Asignatura

Gestin de Proyectos de Software

Trabajo

U1 Introduccin a la Gestion De Proyectos.

**1.2 Fases de la gestin de proyectos**

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

NDICE
INTRODUCCIN ....................................................................................................................... 3
1.2 FASES DE LA GESTIN DE PROYECTOS DE SOFTWARE ............................................ 3
EL PERSONAL. .................................................................................................................... 4
LOS PARTICIPANTES .................................................................................................... 4
EL PRODUCTO .................................................................................................................... 5
EL PROCESO ...................................................................................................................... 5
EL PROYECTO .................................................................................................................... 6
1.2.1 PLANIFICACIN .............................................................................................................. 6
OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES ............................... 7
Organizacin jerrquica ................................................................................................... 7
Organizacin horizontal ................................................................................................... 7
Organizacin de colegas .................................................................................................. 8
Fuentes de personal para un proyecto............................................................................. 8
1.2.2 PROPUESTA ................................................................................................................... 9
1.2.3 SELECCIN Y EVALUACIN DE PERSONAL ............................................................... 9
ADMINISTRACIN DE LA COMUNICACIN ................................................................. 9
OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES ............................. 10
FUENTES DE PERSONAL PARA UN PROYECTO. ..................................................... 13
1.2.4 SUPERVISIN Y REVISIN DEL PROYECTO ............................................................. 14
SUPERVISIN DE LOS RESULTADOS ....................................................................... 15
SEGUIMIENTO DE COSTES Y CALENDARIO ............................................................. 16
SEGUIMIENTO DE ASPECTOS TCNICOS ................................................................ 16
GENERACIN DE DATOS HISTRICOS .................................................................... 16
1.2.5 INFORMES ..................................................................................................................... 17
CONCLUSIN ......................................................................................................................... 18
BIBLIOGRAFA ........................................................................................................................ 18

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

INTRODUCCIN
En el presente trabajo se explicarn los conceptos bsicos del tema de fases de la gestin de
proyectos, esta disciplina est encaminada a la aplicacin de metodologas, tcnicas, y
herramientas para lo que son las fases de planeacin, propuesta, seleccin y supervisin del
personal que estar a cargo del proyecto, as como la supervisin y la revisin del mismo.
La gestin de proyectos de software es una parte esencial de la ingeniera del software. La
buena gestin no puede garantizar el xito del proyecto. Sin embargo, la mala gestin
usualmente lleva al fracaso del proyecto. El software es entregado tarde, los costes son
mayores que los estimados y los requerimientos no se cumplen.
La gestin de proyectos es la rama de la ciencia de la administracin que trata de planificar y
llevar el control de proyectos, la planificacin consiste en determinar qu se debe hacer cmo
debe hacerse, quin es el responsable de que se haga y por qu, por lo tanto, para poder
aplicar los mtodos de la gestin de proyectos las actividades se deben dividir en tareas que no
sean cclicas, que se caractericen con precisin y que las relaciones entre cada una de ellas
sean conocidas.
Los gestores de software son responsables de la planificacin y temporalizacin del desarrollo
de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los
estndares requeridos y supervisan el progreso para comprobar que el desarrollo se ajusta al
tiempo previsto y al presupuesto. La administracin de proyectos de software es necesaria
debido a que la ingeniera de software profesional siempre est sujeta a restricciones
organizaciones de tiempo y presupuesto. El trabajo del gestor de proyectos de software es
asegurar que stos cumplan con dichas restricciones y entregar software que contribuya a las
metas de la compaa de desarrollo de software.
Sommerville, I. (2005). Ingenieria del software. Espaa: Pearson.

1.2 FASES DE LA GESTIN DE PROYECTOS DE SOFTWARE

La administracin efectiva de un proyecto de software se enfoca en las cuatro P: personal,
producto, proceso y proyecto. El orden no es arbitrario. El gerente que olvida que el trabajo de
la ingeniera del software es una empresa intensamente humana nunca triunfar en la
administracin del proyecto. Un gerente que fracase en alentar una comunicacin comprensiva
con los participantes durante las primeras etapas de la evolucin de un producto se arriesga a
construir una solucin elegante para el problema equivocado. El gerente que ponga poca
atencin al proceso corre el riesgo de insertar mtodos y herramientas tcnicos competentes,
pero en el vaco. Aquel que se embarque sin un plan slido pone en peligro el xito del proyecto.

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

EL PERSONAL.
Desde la dcada de 1960 se estudia la formacin de personal de software motivado y
enormemente calificado. De hecho, el factor humano es tan importante que el Software
Engineering Institute desarroll un Modelo de madurez de capacidades del personal (PeopleCMM, por sus siglas en ingls), en reconocimiento al hecho de que toda organizacin requiere
mejorar continuamente su habilidad para atraer, desarrollar, motivar, organizar y conservar la
fuerza de trabajo necesaria a fin de lograr sus objetivos empresariales estratgicos.
El People-CMM define las siguientes reas prcticas clave para el personal de software:
plantilla, comunicacin y coordinacin, ambiente de trabajo, desempeo administrativo,
capacitacin, compensacin, anlisis y desarrollo de competencias, desarrollo profesional,
desarrollo de grupo de trabajo y desarrollo de equipo/cultura, entre otros. Las organizaciones
que conforme a este modelo logran altos niveles de madurez de capacidades de personal tienen
una probabilidad muy elevada de alcanzar la implementacin de prcticas administrativas
efectivas en los proyectos de software.
LOS PARTICIPANTES
El proceso de software (y todo proyecto de software) est poblado de participantes, quienes
pueden organizarse en alguna de las siguientes reas:
1. Gerentes ejecutivos, quienes definen los temas empresariales que con frecuencia tienen
una influencia significativa sobre el proyecto.
2. Gerentes de proyecto (tcnicos), quienes deben planificar, motivar, organizar y controlar a
los profesionales que hacen el trabajo de software.
3. Profesionales que aportan las habilidades tcnicas que se necesitan para someter a
ingeniera un producto o aplicacin.
4. Clientes que especifican los requerimientos para el software que se va a fabricar, as como
otros participantes que tienen un inters perifrico en el resultado.
5. Usuarios finales, quienes interactan con el software una vez que se libera para su uso
productivo.
Para lograr un equipo de alto rendimiento:
Los miembros del equipo deben tenerse confianza entre s.
La distribucin de habilidades debe ser adecuada para el problema.
Es posible que tenga que excluirse del equipo a los inconformes si debe mantenerse la
cohesin del equipo.
Sin importar el tipo de organizacin del equipo, el objetivo para todo gerente de proyecto es
ayudar a crear un equipo que muestre cohesin.

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

EL PRODUCTO
Antes de poder planear un proyecto, deben establecerse los objetivos y el mbito del
producto, considerarse soluciones alternativas e identificar las restricciones tcnicas y
administrativas.
Sin esta informacin, es imposible definir estimaciones razonables (y precisas) del costo, una
valoracin efectiva del riesgo, una descomposicin realista de las tareas del proyecto y un
calendario de proyecto manejable que proporcione en cada momento un indicio significativo del
progreso.
Como desarrolladores de software, todos los participantes deben reunirse para definir los
objetivos y el mbito del producto. Los objetivos identifican las metas globales para el producto
(desde el punto de vista de los participantes) sin considerar cmo se lograrn estas metas. El
mbito identifica los datos, funciones y comportamientos principales que caracterizan al
producto y, ms importante, intenta ligar dichas caractersticas en forma cuantitativa.
Una vez comprendidos los objetivos y el mbito del producto, se consideran soluciones
alternativas.
Aunque se analizan muy pocos detalles, las alternativas permiten a los gerentes y profesionales
seleccionar un mejor enfoque, dadas las restricciones impuestas por fechas de entrega,
restricciones presupuestales, disponibilidad de personal, interfaces tcnicas y muchos otros
factores.

EL PROCESO
Un proceso de software proporciona el marco conceptual desde el cual puede establecerse un
plan completo para el desarrollo de software. Un pequeo nmero de actividades de marco
conceptual se aplica a todos los proyectos de software, sin importar su tamao o complejidad.
Algunos conjuntos de diferentes tareas (tareas, hitos, productos operativos y puntos de
aseguramiento de calidad) permiten que las actividades del marco conceptual se adapten a las
caractersticas del proyecto de software y a los requerimientos del equipo del proyecto.
Finalmente, las actividades sombrilla (como el aseguramiento de la calidad del software, la
administracin de configuracin del software y las mediciones) recubren el modelo de proceso.
Las actividades sombrilla son independientes de cualquier actividad del marco conceptual y
ocurren a lo largo del proceso.
El equipo debe decidir qu modelo de proceso es ms adecuado: 1) para los clientes que
solicitaron el producto y el personal que har el trabajo, 2) para las caractersticas del producto
en s y 3) para el entorno de proyecto donde trabaja el equipo de software. Cuando se
selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar con
base en el conjunto de actividades del marco conceptual del proceso. Una vez establecido el
plan preliminar, comienza la descomposicin del proceso, es decir, debe crearse un plan
completo que refleje las tareas laborales requeridas para poblar las actividades del marco
conceptual.

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

EL PROYECTO
Los proyectos de software se planean y controlan debido a una razn principal: es la
nica forma conocida para manejar la complejidad. E incluso as, los equipos de software
todava batallan.
Actualmente la tasa de xito para los proyectos de software puede haber mejorado un poco, la
tasa de falla de proyecto sigue siendo mucho ms alta de lo que debiera.
Para evitar el fracaso del proyecto, un gerente de proyecto de software y los ingenieros de
software que construyan el producto deben evitar un conjunto de seales de advertencia
comunes, entender los factores de xito cruciales que conducen a una buena administracin
del proyecto y desarrollar un enfoque de sentido comn para planificar, monitorear y controlar
el proyecto.
Para cada proyecto de desarrollo de software se puede decir que existen dos puntos de partida:
uno a nivel de empresa y otro a nivel del propio proyecto. El primero es un precedente necesario
del segundo, ya que este ltimo slo tiene lugar cuando anteriormente la empresa ha tomado
ya la decisin de emprender el proyecto.
Pressman, R. s. (2010). Ingenieria del Software un enfoque Prctico. Mxico: McGraw-Hill.

1.2.1 PLANIFICACIN
La planificacin del proyecto se refiere a la identificacin de las actividades, hitos y entregas de
un proyecto. Por lo tanto, se debe bosquejar un plan para guiar el desarrollo hacia las metas
del proyecto.
Muchos planes incluyen las siguientes secciones:
1. Introduccin. Describe brevemente los objetivos del proyecto y expone las restricciones (por
ejemplo, presupuesto, tiempo, entre otros) que afectan a la gestin del proyecto.
2. Organizacin del proyecto. Describe la forma en que el equipo de desarrollo est
organizado, la gente involucrada y sus roles en el equipo.
3. Anlisis de riesgo. Describe los posibles riesgos del proyecto, la probabilidad de que surjan
estos riesgos y las estrategias de reduccin de riesgos propuestas
4. Requerimientos de recursos de hardware y software. Describe el hardware y el software
de ayuda requeridos para llevar a cabo el desarrollo. Si es necesario comprar
hardware, se deben incluir las estimaciones de los precios y las fechas de entrega.
5. Divisin del trabajo. Describe la divisin del proyecto en actividades e identifica los
hitos y productos a entregar asociados con cada actividad.
6. Programa del proyecto. Describe las dependencias entre actividades, el tiempo estimado
requerido para alcanzar cada hito y la asignacin de la gente a las actividades.

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

7. Mecanismos de supervisin e informe. Describe la gestin de

informes y cundo deben producirse, as como los mecanismos de supervisin del
proyecto a utilizar.
El plan del proyecto debe revisarse regularmente durante el proyecto. Algunas partes, como el
calendario del proyecto, cambiarn frecuentemente; otras sern ms estables. Para
simplificarlas revisiones, se debe organizar el documento en secciones separadas que permitan
su reemplazo de forma individual conforme evoluciona el plan.
Sommerville, I. (2005). Ingenieria del software. Espaa: Pearson.
OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES
Organizacin jerrquica
En esta organizacin existe una gerente global, con tres personas que le reportan. El
responsable de los aspectos de mercadotecnia del proyecto, es el que interacta con los
clientes para asegurar que el producto es lo que desean. Todos deben entender las lneas de
autoridad y decisin, y el nmero de personas con quienes cada uno debe interactuar con
regularidad es aceptable. La desventaja es que los miembros del equipo tienden a participar
menos en las decisiones porque es probable que las tareas se asignen desde arriba. Si todo lo
dems es igual, sta es una manera segura de organizar un proyecto. Los proyectos ms
grandes organizados con este estilo jerrquico requieren organigramas ms amplios.
La ventaja de esta organizacin es el potencial para la motivacin que viene con la participacin
por igual en el proyecto. Esto funciona bien en especial si el grupo es pequeo, muy competente
y est acostumbrado a trabajar en equipo.
Las desventajas incluyen la dificultad para resolver las diferencias y el hecho de que nadie est
a cargo. Slo establecer que todas las decisiones son participativas y por consenso
(unanimidad) no hace que el proceso funcione de manera automtica. El TSP de Humphrey es
un conjunto especfico de guas para este tipo de equipos. En ltima instancia, debe
establecerse una mezcla de participacin de colegas y responsabilidad de liderazgo adecuada
para el tamao del proyecto, su naturaleza, su madurez y las personas involucradas.
Organizacin horizontal
La idea es que los miembros del equipo son iguales, excepto por el lder designado. En la
situacin ideal, l debe estimular la participacin de los miembros del equipo, pero debe tomar
decisiones cuando se requiere.
Los papeles pueden intercambiarse una vez durante un periodo de tres meses para
proporcionar a los miembros del equipo una experiencia ms amplia. Como cada papel es crtico,
es buena idea designar un tipo de sistema de amigos para cada lder. El amigo del ingeniero
puede hacerse cargo si el lder est incapacitado. l o ella deben inspeccionar el resto de los
trabajos de los ingenieros.

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

Organizacin de colegas
Promueve que los artefactos cambien de manos sin problemas de una etapa a la
siguiente, pues cada ingeniero se familiariza con el producto de la etapa anterior a la que l o
ella ser el responsable.
Conforme el nmero de participantes crece en un proyecto, la organizacin pura de los colegas
se convierte en algo imposible debido a que el nmero de vnculos de comunicacin, crece con
el cuadrado del nmero de participantes. Una alternativa para proyectos grandes es realizar los
grupos de colegas pequeos y se designa un miembro de cada grupo como comunicador con
los otros grupos. Este tipo de organizacin intenta preservar los beneficios de los equipos pequeos, pero cuenta con muchas personas para construir una aplicacin extensa. Es de
conocimiento general que es raro el ingeniero con aptitudes para labores tanto de ingeniera
como de administracin.
Fuentes de personal para un proyecto
En las organizaciones orientadas a proyectos, el personal del proyecto reporta al gerente del
proyecto en el sentido organizacional. l o ella es su jefe. Un ingeniero de software est ligado
de todas las maneras a un proyecto especfico, y no tiene afiliacin organizacional con los otros
ingenieros de software en otros proyectos de la compaa. Esto tiene la ventaja de simplificar
las lneas de autoridad, pero la desventaja de aislar a los ingenieros en el sentido profesional.
Por ejemplo, las compaas pequeas casi siempre estn organizadas con una orientacin a
los proyectos, pero incluso en las grandes se ve esta organizacin, en especial cuando intentan
resaltar el enfoque en el cliente.
En trminos generales, las estructuras segn el reporte de actividades son ms complejas que
en las organizaciones orientadas a proyectos, debido al uso de la organizacin matricial. En
estas organizaciones, los empleados pertenecen a unidades funcionales (como ingeniera,
ventas, etctera) y se prestan a los proyectos. As, el supervisor de un ingeniero de software la
persona responsable de evaluarlo sera miembro de la unidad funcional de ingeniera de
software. Sin embargo, dentro de cada proyecto en el que trabaje estar supervisado por el
lder del proyecto. Por lo comn, los ingenieros estn incluidos en un proyecto, a veces dos,
pero muy pocas veces ms.
Las organizaciones matriciales tienen la ventaja de mejorar las aptitudes y el profesionalismo,
y la desventaja de debilitar las lneas de autoridad. Las compaas con frecuencia intentan
encontrar un punto medio entre las organizaciones matriciales y las orientadas a proyectos.
Braude. Ingeniera de software Una perspectiva orientada a objetos. Alfaomega

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

1.2.2 PROPUESTA
La propuesta describe los objetivos del proyecto y cmo se llevara a cabo. Por lo
general, incluye estimaciones de coste y tiempo y justifica por qu el contrato del proyecto se le
debe dar a una organizacin o a un equipo en particular. La redaccin de la propuesta es una
tarea crtica, ya que la existencia de muchas organizaciones de software depende de las
propuestas aceptadas y los contratos asignados. No existen guas para esta tarea; la redaccin
de propuestas es una habilidad que se adquiere con la prctica y la experiencia.

1.2.3 SELECCIN Y EVALUACIN DE PERSONAL

Por lo general, los gestores de proyectos tienden a seleccionar a las personas para trabajar en
su proyecto. De forma ideal, habr personal disponible con habilidades y experiencia apropiada
para trabajar en el proyecto. Sin embargo, en muchos casos, los gestores tienen que establecer
un equipo ideal mnimo para el proyecto. Las razones que explican esto son:

El presupuesto del proyecto no cubre la contratacin de personal con sueldos altos. Se

tiene que contratar personal con menos experiencia y menor sueldo.
El personal con experiencia apropiada no est disponible dentro o fuera de la
organizacin. Es imposible reclutar nuevo personal para el proyecto. Dentro de la
organizacin, los mejores trabajadores ya se han asignado a otros proyectos.
La organizacin desea desarrollar las habilidades de sus empleados. El personal
inexperto puede ser asignado al proyecto para aprender y adquirir experiencia.
El gestor de software tiene que trabajar con estas restricciones al seleccionar el personal
del proyecto, Sin embargo, todos estos problemas son probables a menos que exista un
miembro del proyecto que cuente con algo de experiencia en el tipo de sistema a
desarrollar. Sin esta experiencia, probablemente se cometern muchos errores
pequeos.

En este apartado se analizan los aspectos organizacionales de los equipos de proyecto desde
dos perspectivas. Primero, Cul es la estructura de responsabilidades del proyecto? Segundo,
de dnde viene la gente y a quin reportan? De cualquier modo, poco se puede lograr a menos
que los participantes se comuniquen de manera adecuada.
ADMINISTRACIN DE LA COMUNICACIN
La experiencia del autor y de otra muestra que el nmero de desarrolladores con quienes cada
desarrollador debe interactuar con regularidad debe ser entre tres y siete. Los estudios formales
acerca del efecto del tamao del equipo sobre el desempeo son raros, en la figura 1 ilustra los
extremos que llevan a las recomendaciones del tamao del equipo. En un extremo, el
desarrollador trabaja de manera individual sin interacciones del tamao del equipo. En un
extremo, el desarrollador trabaja de manera individual sin interaccin habitual con otros. Aunque
no gaste tiempo en comunicacin, ese aislamiento suele repercutir en malos entendidos

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

respecto a lo que se espera del desarrollador, y conducir a un nivel

relativamente bajo de efectividad. En el otro extremo, el desarrollador tiene que
interactuar por rutina con tantos individuos que no queda tiempo para realizar el desarrollo en
s, y de nuevo el resultado es inefectividad. En particular, comunicacin habitual implica hablar
con alguien para algo, alrededor de dos horas a la semana. Si un ingeniero tiene una
comunicacin, lo que le deja slo media semana para su contribucin individual. Los
organizadores del proyecto deben tener esto en cuenta cuando planeen proyectos, ya sea de
diez o de cien personas.

Fig1. Tamao ptimo aproximado para la interaccin

OPCIONES PARA LA ESTRUCTURA DE RESPONSABILIDADES
La estructura jerrquica de la administracin, figura 2, es un extremo organizacional. Las
ventajas de este esquema organizacional son que todos entienden las lneas de autoridad y
decisin, y el nmero de personas con quienes cada uno debe de interactuar con regularidad
es aceptable. Las desventajas es que los miembros del equipo tienden a participar menos en
las decisiones porque es probable que las tareas se asignen desde arriba. Si todo lo dems es
igual, sta es una manera segura de organizar un proyecto. Los proyectos ms grandes
organizados con este estilo jerrquico requieren organismos ms amplios.

10

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

Fig. 2 Organizacin jerrquica para la administracin de proyectos

El otro extremo organizacional hay un equipo que consiste en una comunidad que colegas con
las mismas autoridades. La ventaja de esta organizacin es el potencial para la motivacin que
viene con la participacin por igual en el proyecto. Esto funciona bien en especial si el grupo es
pequeo, muy competente y est acostumbrado a trabajar en equipo. Las desventajas incluyen
la dificultad para resolver las diferencias y el hecho de que nadie est a cargo. En ltima
instancia, debe establecerse una mezcla de participacin de colegas y responsabilidad de
liderazgo adecuado para el tamao del proyecto, su naturaleza, su madurez y las personas
involucradas.
Un punto medio es la estructura de organizacin horizontal, como ilustra la figura 3. La idea es
que los miembros del equipo son iguales, excepto el lder designado.

Fig. 3

Organizacin
horizontal para la administracin de proyectos

En las situaciones ideales, l debe estimular la participacin de los miembros del equipo, pero
debe tomar decisiones cuando se requiere. En la figura 4 muestra una forma ms detallada
para la organizacin de los equipos. Si hay cinco integrantes, entonces uno de ellos tal vez

11

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

quiera ser el lder de requerimientos al igual que lder de implementacin,

ya que slo una de estas actividades tiene tareas en un tiempo dado. Se puede
prescindir del lder de requerimientos, aunque alguien debe ser responsable de mantener el
ERS (especificacin de requerimientos de software, documento que establece lo que una
aplicacin debe lograr). Los papeles pueden intercambiarse una vez durante un periodo de tres
meses para proporcionar a los miembros del equipo una experiencia ms amplia. Como cada
papel es crtico, es buena idea designar un tipo de Sistema de amigos para cada lder. El lder
amigo del ingeniero puede hacerse cargo si est incapacitado.

Fig. 4. Una manera de organizar un equipo (PAPS: Plan de administracin del proyecto de
software, PACS: Plan de administracin de la configuracin del software, PAQS: Plan de
aseguramiento de la calidad de software, PPS: Plan de prueba de software, ERS: Especificacin
de requerimientos de software, DDS: Documento de diseo de software.)
l o ella deben inspeccionar el resto de los trabajos de los ingenieros. El esquema de respaldo
de la figura 4 promueve que los artefactos cambien de manos sin problemas de una etapa
anterior a la que l o ella ser el responsable.
Conforme al nmero de participantes crece en un proyecto, la organizacin pura de los colegas
se convierte en algo imposible debido a que el nmero de vnculos de comunicacin (entre
todos los pares) crece con el cuadro del nmero de participantes.
Una alternativa para proyectos grandes es la organizacin que se muestra en la figura 5 donde
los grupos de colegas son pequeos y se designan un miembro de cada grupo como
comunicador con los otros grupos. Este tipo de organizacin intenta preservar los beneficios de
los equipos pequeos, pero cuenta con muchas personas para construir una aplicacin extensa.

12

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

Fig. 5. Organizacin de colegas para proyectos grandes.

Es de conocimientos general que es raro el ingeniero con aptitudes para labores tanto de
ingeniera y de administracin. Sin embargo, el autor ha observado que muchos ingenieros se
han desempaado bien dirigiendo grupos, incluso cuando muy pocos esperaban que pudieran.

FUENTES DE PERSONAL PARA UN PROYECTO.

En las organizaciones orientadas a proyectos, el personal del proyecto reporta el gerente del
proyecto en el sentido organizacional. l o ella es su jefe. Un ingeniero de software est ligado
de las maneras a un proyecto en especfico, y no tiene afiliacin organizacional con los otros
ingenieros de software en otros proyectos en la compaa. Esto tiene la ventaja de simplificar
las lneas de autoridad, pero la desventaja de aislar a los ingenieros en el sentido profesional.
Por ejemplo, las compaas pequeas casi siempre estn organizadas con una orientacin a
los proyectos, pero incluso en las grandes se ve esta organizacin, en especial cuando intentan
resaltar el enfoque en el cliente.
En trminos generales la estructura segn el reporte de actividades es ms complejas que en
las organizaciones orientadas a proyectos, debido al uso de la organizacin matricial. En estas
organizaciones, los empleados pertenecen a unidades funcionales (ingeniera, ventas, entre
otros) y se presenta los proyectos figura 6.

13

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

As el supervisor de unos ingenieros de software- la persona responsable de evaluarlo- sera

miembro de la unidad funcional de ingeniera de software. Sin embargo, dentro de cada proyecto
en el que trabaje estar supervisado por el lder del proyecto.
Braude, E. J. (s.f.). Ingeniera de Software. Una perspectiva Orientada a Objetos.

1.2.4 SUPERVISIN Y REVISIN DEL PROYECTO

La supervisin del proyecto es una actividad continua. El gestor debe tener conocimiento del
progreso del proyecto y comparar el progreso con los costes actuales y los planificados. Aunque
muchas organizaciones tienen mecanismos formales para supervisar, un gestor hbil podra
formarse una imagen clara de lo que pasa llevando a cabo una entrevista informal con el
personal del proyecto.
La supervisin informal predice problemas importantes del proyecto, y revela dificultades que
pueden aparecer, Por ejemplo, las entrevistas diarias con el personal del proyecto pueden
exteriorizar un problema en un fallo del software. Ms que esperar un informe de atraso del
proyecto, el gestor de software podra asignar algn experto para resolver el problema o podra
decidir si se vuelve a programar.
Durante el proyecto, es normal tener varias revisiones formales de su gestin. Se hace la
revisin completa del progreso y de los desarrollos tcnicos del proyecto, y se tiene en cuenta
el estado del proyecto junto con los propsitos de la organizacin que ha encargado el software.
El resultado de una revisin puede dar lugar a la cancelacin del proyecto, El tiempo de
desarrollo para un proyecto grande de software puede ser de varios aos. Durante ese tiempo
los objetivos organizaciones tienden obviamente a cambiar. Estos cambios pueden significar
que el software ya no se necesita o que los requerimientos originales del proyecto son
inapropiados. La gestin puede decidir parar el desarrollo del software o cambiar el proyecto
para adecuarlo a los cambios de los objetivos de la organizacin.

14

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

SUPERVISIN DE LOS RESULTADOS

Para conseguir el primer objetivo, se han de desarrollar las siguientes actividades:

Desarrollar estndares que establezcan las condiciones o medidas que deben cumplir
cuando se realizan correctamente las diferentes tareas del proyecto.
Establecer sistemas de supervisin y de informes, para lo cual hay que determinar: los
datos necesarios. Quin los recibe y cundo se reciben
Medir los resultados. Lo que permite determinar la consecucin o la desviacin de los
objetivos y estndares.
Los jefes de proyecto deben discutir la necesidad de controlar sus proyectos de acuerdo a los
planes establecidos. El reto es utilizar las herramientas y las tcnicas disponibles de forma
efectiva, es decir, gestionar el esfuerzo de tal forma que el personal acepte los objetivos que
debe cumplir dentro de unos tiempos y recursos dados. Sin embargo. Pueden existir problemas
que llevan a salir del calendario y sobrepasar l presupuesto. Algunos de estos problemas son:
Dificultad para definir el trabajo con el detalle suficiente.
Poca implicacin del equipo de proyecto durante la planificacin.
Problemas con la organizacin y la constitucin del equipo del proyecto.
Organizacin del equipo del proyecto insuficientemente definida.
El proyecto se considera poco importante o interesante.
No existen planes de contingencia.
Mala comunicacin con la direccin y con el cliente.
Mala comprensin en las lneas de comunicacin en la organizacin.
Dificultad al trabajar entre distintos departamentos de la organizacin.
Mala direccin del proyecto.
Poca asistencia y ayuda de la direccin.
El jefe de proyecto no se compromete con el equipo.
Dificultades la valorar los riesgos.
Algunas de las razones que conducen a los problemas anteriores son;

Planificacin insuficiente.
Plan del proyecto no relista.
Cambios del cliente/direccin.
Planificacin de contingencia insuficiente.
Incapacidad para controlar el progreso.
Incapacidad de detectar los problemas tempranamente.
Nmero de puntos de verificacin insuficiente.
Problemas de la plantilla.
Complejidades tcnicas.

15

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

SEGUIMIENTO DE COSTES Y CALENDARIO

Muchas organizaciones muestran un gran inters en el seguimiento de cortes y
calendario. Con frecuencia, se exige que las organizaciones mantengan sistemas de informes
de costes y progresos muy formales. Sin embargo, es fundamental reconocer las limitaciones
de tales sistemas. Muchas organizaciones asumen que el seguimiento de los costes frente a
los presupuestos y el seguimiento de los sucesos frente al calendario, representan todo el
control del progreso que necesitan. Si no existe un informe serio de las variaciones, se supone
que todo va bien. Sin embargo, puede que los jefes de proyecto sufran un shock cuando surjan
problemas serios, aparentemente fuera de contexto.
Por lo tanto, adems de los costes y del calendario, tambin es necesario tratar aspectos ms
tcnicos del estado del proyecto del software. Especficamente, el seguimiento de los recursos
crticos del proyecto y el seguimiento del tamao de los productos software.
SEGUIMIENTO DE ASPECTOS TCNICOS
Para comprender la importancia de estos aspectos tcnicos, pensaremos, por ejemplo, en un
proyecto que trata de mejorar una funcin (por ejemplo, control de temperatura), similar a las
de proyectos anteriores, dentro de un perodo limitado de tiempo. Al terminar el diseo
preliminar, el prototipo construido muestra que el algoritmo probado ms rpido no alcanza los
requisitos de tiempo establecidos. Desde el punto de vista del sistema de informes de coste y
de progreso, no existe ningn problema visible, ya que el diseo preliminar se finaliz a tiempo
y los costes son concordantes con el presupuesto. Pero el personal tcnico sabe, de antemano,
que existe una dificultad. Si el jefe de proyecto les obliga, pueden ocultar el problema durante
un largo tiempo (al menos hasta la fase de integracin y pruebas). Tambin pueden abordar el
problema inmediatamente y as resolverlo mientras todava hay tiempo. En cualquier caso, el
control ms riguroso de los informes del estado del coste y calendario no pueden detectar este
problema. Solo un control directo suplementario de los aspectos tcnicos crticos del proyecto
traer el problema a primer plano de atencin de la direccin o el jefe del proyecto.
A veces, puede que los problemas tcnicos o de la plantilla sean la causa de una desviacin
respecto al plan. En este caso, hay que supervisar dichos problemas y no enmascararlos
respecto al cambio en la planificacin: no trate de estar bien hoy a expensas de maana. En
definitiva, el jefe de proyecto tiene que valorar cuidadosamente el motivo y el impacto de un
cambio en la planificacin. De esta forma, se tendrn presiones hoy, pero cuando se llegue a
los hitos importantes, el proyecto cumplir sus objetivos.
GENERACIN DE DATOS HISTRICOS
Otro aspecto importante del seguimiento y la supervisin de proyectos es la generacin de datos
histricos para utilizarlos como soporte de estimacin de futuros desarrollados. De nuevo, los
sistemas de seguimiento econmicos pueden interferir en la tarea. Si el objetivo es saber en
qu se gasta el dinero, entonces no hay necesidad de mantener un seguimiento de las horas
extraordinarias no remuneradas. Como resultado, muchos sistemas de seguimiento econmico

16

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

no requieren registrar tales horas e, incluso, algunos lo tienen prohibido y

archivan no ms de cuarenta horas por semana y por empleado.
Este enfoque causa problemas cuando los registros almacenados se utilizan como fuente de
datos histricos para la estimacin y planificacin de un nuevo proyecto. En un proyecto donde
el nivel de horas extraordinarias no remuneradas est limitado (por ejemplo, en un 10-20%), la
distorsin de los datos histricos estar limitada en igual proporcin. Sin embargo, en muchas
organizaciones, el nivel de horas extras no remuneradas puede fcilmente alcanzar el 25%. El
50% o incluso el 100% de las horas pagadas, y estos niveles pueden mantenerse durante
semanas, meses o, incluso, aos. Cuando las horas no registradas alcanzan este nivel, datos
como nmeros de horas para finalizar el diseo preliminar o productividad de la plantilla por
da estn seriamente distorsionados. Las estimaciones basadas en tales datos histricos
errneos conducen inevitablemente a estimaciones inapropiadas de las horas necesarias para
las tareas, dando como resultado una planificacin muy ajustada y un presupuesto muy bajo.
Pero, Qu se hace en estos casos? La respuesta es obvia: incluir ms horas extras no
remuneradas. La organizacin esta as en un ciclo destructivo que algunos han denominado la
espiral de la muerte.
La frase mantener dos juegos de libros de contabilidad tiene una connotacin negativa, porque
la gente lo asocia con el uso de mltiplos registros econmicos para realizar un fraude. Pero las
organizaciones deben reconocer que, mientras existan las horas extraordinarias no
remuneradas, el seguimiento del dinero y el seguimiento del esfuerzo real son cosas distintas.
Si aquellos que estn a cargo del sistema econmico estn dispuestos a asumir la tarea extra
de seguimiento del esfuerzo real, est pagado o no, entonces no hay problema. Sin embargo,
si no estn dispuestos a hacerlo, entonces el mantenimiento de un informe del esfuerzo real
realizado debe convertirse en una tarea de alta prioridad en la organizacin independientemente
del esfuerzo pagado. Con frecuencia, el mero hecho del seguimiento de esas horas y su informe
a la direccin, abrir sus ojos a la carga de trabajo que han estado poniendo en su plantilla y
les sensibilizar con los impactos producidos por la planificacin de los proyectos.
Piattini, M. G. (2004). Anlisis y diseo de Aplicaciones Informticas de Gestin una perspectiva
de Ingeniera del Software. Mxico: Alfaomega.

1.2.5 INFORMES
Los gestores del proyecto son responsables de informar a los clientes y contratistas sobre el
proyecto. Tienen que redactar documentos concisos y coherentes que resuman la informacin
crtica de los informes detallados del proyecto. Les debe ser posible presentar esta informacin
durante las revisiones de progreso. En consecuencia, comunicarse efectivamente de forma oral
y escrita es una habilidad esencial que un gestor de proyectos debe tener,
Sommerville, I. (2005). Ingenieria del software. Espaa: Pearson.

17

GESTIN DE PROYECTOS DE SOFTWARE

UNIDAD 1-FASES DE LA GESTIN DE PROYECTOS 704-A

MTI. MONTSERRAT MASDEFIOL SUREZ

CONCLUSIN
Como se mencion anteriormente, la Gestin de Proyectos trata de planificar y llevar
el control de proyectos, por lo que, aplicados al software, podemos decir que se convierte en
la llamada Gestin de Proyectos de Software, integrada por la planificacin, una propuesta, la
seleccin y evaluacin del personal y los informes.
Cada uno de ellos a su vez cuenta con pasos indispensables a realizar para que la gestin
pueda cumplir el objetivo.
Con esto equipo de trabajo concluye que es importante conocer estos aspectos ya que estas
bases son necesarias para lograr comprender la forma en que se debe elaborar una Gestin
de Proyecto de Software exitosa.

BIBLIOGRAFA
Braude, E. J. (s.f.). Ingeniera de Software. Una perspectiva Orientada a Objetos.
Pressman, R. s. (2010). Ingenieria del Software un enfoque Prctico. Mxico: McGraw-Hill.
Sommerville, I. (2005). Ingenieria del software. Espaa: Pearson
Braude, E. J. (s.f.). Ingeniera de Software. Una perspectiva Orientada a Objetos.Alfaomega
Piattini, M. G. (2004). Anlisis y diseo de Aplicaciones Informticas de Gestin una
perspectiva de Ingeniera del Software. Mxico: Alfaomega.

18