Planificacin de Proyectos de Software

El objetivo de planificacin del proyecto de Software es proporcionar un marco de

trabajo que permita al gestor hacer estimaciones razonables de recursos, costo y
planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo
limitado al comienzo de un proyecto de Software, y deberan actualizarse a medida que
progresa el proyecto. Adems, las estimaciones deberan definir los escenarios del "
mejor caso " y " peor caso " de forma que los resultados del proyecto puedan limitarse.
El objetivo de la planificacin se logra mediante un proceso de descubrimiento de la
informacin que lleve a estimaciones razonables.

mbito del Software.

La primera actividad de la planificacin del proyecto de Software es determinar
el mbito del Software. Se deben evaluar la funcin y el rendimiento que se asignaron
al Software durante la ingeniera del sistema. El mbito del Software describe la
funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad.

Se evalan las funciones descritas en el enunciado del mbito, y en algunos casos se

refinan para dar ms detalles antes del comienzo de la estimacin. La tcnica ms
utilizada con frecuencia para acercar al cliente y al desarrollador, y para hacer que
comienza el proceso de comunicacin es establecer una entrevista preliminar.

La comunicacin con el cliente lleva a una definicin de datos, funciones, y

comportamientos a implementarse, y de informacin sobre el rendimiento e imitaciones
que delimitan el sistema.

Recursos
La segunda tarea de la planificacin del desarrollo de Software es la estimacin de los
recursos requeridos para acometer el esfuerzo de desarrollo de Software.

Personas.

Componentes del Software Reutilizables.

Herramientas software y hardware.

En base a la pirmide de recursos se encuentra el entorno de desarrollo- Hardware y

Software- que proporciona la infraestructura de soporte al esfuerzo de desarrollo. En un
nivel ms alto se encuentra los componentes del Software Reutilizables, los bloques de
Software que pueden reducir drsticamente los costos de desarrollo y acelerar la
entrega. En la parte ms alta est el recurso primario- las personas.

Recursos Humanos
El encargado de la planificacin comienza elevando el mbito y seleccionando las
habilidades tcnicas que se requieren para llevar acabo el desarrollo. El nmero de
personas requeridas para un proyecto de Software slo puede ser determinado
despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo, personas -
mes o personas - aos.)

Recursos de Software Reutilizables.

Cualquier estudio sobre recurso de Software estara incompleto sin estudiar la
reutilizacin, esto es, la creacin y la reutilizacin de bloques de construccin de
software [H0091]. Tales bloques deben establecerse en catlogos para una consulta
ms fcil, estandarizarse para una fcil aplicacin y validarse para tambin la fcil
integracin.

Bernnatan [BEN92] sugiere cuatro categoras de recursos de Software que se deberan

tener en cuenta a medida que se avanza con la planificacin.

Componentes ya desarrollados. El Software existente se puede adquirir de

una tercera parte o provenir de uno desarrollado internamente para un proyecto
anterior. Estos componentes estn listos para utilizarse en el proyecto actual y
se han validado totalmente.

Componentes ya experimentados. Las especificaciones, diseos, cdigos, o

datos de pruebas ya existentes y desarrollados para proyectos anteriores que
son similares al Software que se va a construir para el proyecto actual. Los
miembros del equipo del Software actual ya han tenido la experiencia completa
en el rea de la aplicacin representada para estos componentes, Las
modificaciones, por tanto, requeridas para componentes de total experiencia,
tendr un riesgo relativamente bajo.

Componentes con experiencia parcial. Las especificaciones, los diseos,

cdigos o los datos de prueba existentes ya desarrollados para proyectos
anteriores que se relacionan con el Software que se va a construir para el
proyecto actual, pero que requerirn una modificacin sustancial. Los miembros
 del equipo del Software actual han limitado su experiencia slo al rea de
aplicacin representada por estos componentes. Las modificaciones, por tanto,
requeridas para componentes de experiencia parcial tendrn bastante grado de
riesgo.

Componentes nuevos. Los componentes de Software que el equipo de

Software debe construir son especficamente para las necesidades del proyecto
actual.

Recursos de entorno. El entorno es donde se apoya el proyecto de Software,

llamado a menudo entorno de Ingeniera de Software (EIS) incorpora Hardware
y Software. El Hardware proporciona una plataforma con las herramientas
(Software) requeridas para producir los productos que son el resultado de una
buena prctica de la ingeniera de Software.

Estructura Orgnica en Proyectos de Software

Existen tres tipos de estructura orgnica para los proyectos de desarrollo de software:

1. Formato de Proyecto
2. Formato Funcional
3. Formato Matricial

La misin y responsabilidad fluctan de acuerdo con el encargo de cada momento,

Todos los puestos tienen por objeto satisfacer las necesidades del cliente, con el
nfasis puesto en sus necesidades.

Los individuos adquieren mayor autonoma en su funcionamiento y la autoridad se basa

en sus competencias y capacidad de aprendizaje, en lugar de basarse en
responsabilidades previas. Esto da lugar a organizaciones por proyectos y estructuras
ms transversales, que aseguran la coherencia de los planes de accin. Las
organizaciones que se basan en polos de excelencia son el resultado de nuestra
ambicin de ser el nmero uno en todo lo que hacemos. Pueden ser formales o
informales, reales o virtuales. Pueden materializarse en la forma de Centros de Servicio
Compartidos que alojan centros de excelencia y crean sinergias. Los Factores a
considerar en la seleccin de la Estructura Organizacional del Proyecto de Desarrollo
de Software son:

1. Tamao del producto a desarrollar.

2. Nmero de proyectos. Pocos proyectos grandes (mayores de 20 personas),
muchos proyectos pequeos (menores de 10 personas).
3. Alcance del desarrollo. Tipo de actividades distintas que se realizan en un
instante dado.
4. La estructura organizacional debe reconocer y ser capaz de operar en la cultura
organizacional de la empresa en la cual est inserta.
5. Limitaciones fsicas. Proyecto es desarrollado localmente o en diversos lugares
distantes entre s.
6. Cultura organizacional. Cul es el estilo de gestin de la organizacin.
7. Con que estructura se siente ms cmodo el ejecutivo superior.

Formato de Proyecto.
En el formato de proyecto el grupo de trabajo est formado por desarrolladores que
llevan a cabo el proyecto de principio a fin. Realizan las tareas involucradas en las
fases de Definicin de Requerimientos, Diseo, Codificacin y Prueba, adems de las
revisiones del producto y la documentacin. Algunos miembros del equipo de desarrollo
pueden permanecer durante la Instalacin y Mantenimiento, mientras otros participan
en nuevos proyectos, sin dejar de lado la responsabilidad del mantenimiento del
producto de software entregado.

Organizacin por Proyecto.

Es efectiva cuando los proyectos son pequeos y cada proyecto tiene una sola
ubicacin. Por lo menos el 70% de los recursos necesarios estn bajo el control directo
del Jefe de Proyecto, quien cumple los roles de Jefe Tcnico y Jefe Administrativo.

Las empresas entrevistadas presentan un proceso de mutacin en marcha en la

industria que refleja en este sector tendencias ms amplias y generales en la
administracin de empresas. En particular, se encontraron dos evidencias que abren la
puerta para futuras investigaciones:

1. Las empresas se encuentran en un proceso de cambio de paradigma de

organizacin. Esta mutacin obedece, por un lado, a los cambios que se verifican
en el entorno y a las adaptaciones de las empresas al mismo, y por otro, a la
evolucin de las empresas y la sofisticacin de sus procesos de gestin.
2. El modo (las rutinas), a travs del cual los clientes participan en el proceso de
desarrollo de los productos est evolucionando. Este cambio incluye el uso
intensivo de la experimentacin y el trabajo con usuarios avanzados. Esta
metodologa permite reducir costos derivados de errores comerciales y de diseo y
maximiza las posibilidades comerciales del producto.

Las evidencias encontradas permiten extraer las

siguientes premisas:
1.-De la definicin por productos a la definicin por competencias Las empresas han
dejado progresivamente de definirse en funcin de los productos que hacen y a hacerlo
en funcin de las habilidades o competencias centrales que les permiten desarrollar
esos productos. Este enfoque desarrollado por primera vez por Hamel y Prahalad
(1990) ha dado paso a una variacin sobre el mismo tema. En particular, las empresas
reconocen explcita o implcitamente que sus competencias bsicas no son las
tecnolgicas sino, crecientemente, las asociadas a habilidades organizacionales:

1. Identificacin de oportunidades de negocio.

2. Diseo de productos (soluciones).
3. Gestin de proyectos.

2.- De la organizacin funcional a la organizacin por proyectos.

Ventajas:
1. Las decisiones tcnicas y administrativas se hacen en los niveles ms bajos,
permitiendo rapidez y control efectivo.
2. La autoridad impersonal, minimiza las interfaces y define claramente las
responsabilidades.
3. Motivacin es alta durante el perodo de desarrollo.

Desventajas:
1. Alta gerencia no ve el desarrollo de los proyectos.
2. No se logra economa de escala en los recursos crticos (personal
especializado).
3. Entrenamiento es alto.
4. Desplazamiento de personal de un proyecto a otro es difcil.
5. Inhibe la estandarizacin.

Organizacin funcional.
El principio fundamental de este tipo de organizacin es el Staff. Este tipo de
organizacin se sustituy en la organizacin lineal por la funcional en la que cada
operario pasa a reportar, no solo a su jefe superior, sino a varios, pero cada uno en su
especialidad. El Staff es el resultado de la organizacin lineal y funcional, en esta
organizacin existen rganos de decisin en la asesora. En la fusin de la estructura
lineal con la funcional, predomina la estructura lineal. Cada rgano reporta a un solo y
nico rgano superior; Principio de autoridad. Pero cada rgano recibe asesora y
servicio especializado de los diversos rganos de staff.

Ventajas:
1. ! Administracin fuerte y control centralizado.
2. ! Se puede reforzar e implantar fcilmente estndares.
3. ! Personal est asociado a una unidad.
4. ! Se adapta fcilmente a las decisiones de largo plazo.

Desventajas:
1. La resolucin de las decisiones la realiza una sola autoridad para todos los
proyectos.
2. Limita la creacin de generalistas, tiende a la especializacin.
3. El control de los proyectos es bajo.

Formato Matricial.
En organizaciones matriciales, las funciones de Desarrollo, Soporte Tcnico, Control de
Calidad y Mantenimiento, tienen su propia administracin y un equipo de gente
dedicada exclusivamente a dicha funcin. Cada grupo funcional participa en todo
proyecto; por ejemplo, los miembros del equipo de desarrollo pertenecen
organizacionalmente a esa funcin, pero trabajan bajo la supervisin de un jefe de
proyecto en particular. De la misma manera, el personal de control de calidad
pertenece a esa funcin, pero trabaja en uno o ms proyectos bajo la supervisin del
jefe de proyecto correspondiente. En las organizaciones matriciales cada quien tiene
por lo menos dos jefes, la ambigedad.

Organizacin Matricial.
Esta estructura busca optimizar la organizacin. Su mayor desventaja es que no hay un
responsable por el xito de un proyecto. En este esquema el Gerente funcional decide
cmo hacer el trabajo. Suministra los recursos para el desarrollo.

La Organizacin Matricial se usa debido a que las compaas y los consumidores se

han interesado en los resultados finales, han surgido presiones para establecer la
responsabilidad de garantizar dichos resultados.

Problemas de la Organizacin Matricial.

1. Existe una situacin de conflicto entre los gerentes funcionales y los de proyecto.
2. El conflicto y la ambigedad de papeles pueden provocar stress a los gerentes,
as como a los miembros del equipo.
3. En las organizaciones matriciales tambin suelen ser fuentes de problemas, el
desequilibrio de autoridad y el poder.
4. Requiere de muchas reuniones que consumen tiempo.

Normas para ser eficaz la Organizacin Matricial.

1. Definir los objetivos del proyecto.
2. Clasificar roles, autoridad y responsabilidad de los administradores y miembros
del equipo.
3. Equilibrar el poder en los gerentes funcionales y de proyecto.
4. Seleccionar para el proyecto un administrador con dotes de liderazgo.
5. Poner en prctica controles apropiados de costos, tiempo y calidad.
6. Recompensar en forma justa a los gerentes y miembros del equipo.

Organizacin Matricial del Equipo de Proyecto.

Relacin Jefe De Proyecto Jefe Unidad Funcional
Una de las funciones ms relevantes de la direccin de proyectos es a de integrar en el
equipo de proyecto a especialistas procedentes de otras reas o de otras empresas,
responsabilidad que debe ser asumida por el jefe de proyecto. La mayor dificultad
deriva de que se rompe uno de los principios de gestin clsicos, como es el principio
de unidad de direccin. Es decir, un empleado de una unidad funcional que es
asignado temporalmente a un proyecto pasa a tener dos jefes: su jefe jerrquico de la
unidad funcional, del cual depende formal y habitualmente, y el jefe de proyecto, a las
rdenes del cual trabaja slo en el mbito del proyecto.

Si el director funcional es el que posee los recursos y conoce la vala personal y forma
de trabajar de los mismos, es evidente que ser la persona ms adecuada para
proporcionar las personas que intervendrn en el proyecto. Pero si el jefe de proyecto
ha de conseguir sus objetivos poniendo en juego los recursos aportados al proyecto,
deber velar porque esos recursos sean idneos en calidad y cantidad, no pudiendo en
caso contrario responsabilizarse de la consecucin de los objetivos.

La malla organizacional.
La eficiencia organizacional es la habilidad intrnseca de una organizacin para generar
software de calidad en el mnimo de tiempo con el mnimo de recursos. Una vez que la
eficiencia de la organizacin ha sido determinada se puede resolver el problema de
estimar el esfuerzo de desarrollo. Partiendo de las necesidades de los clientes, se
identifican los procesos clave y se dirigen los esfuerzos de la organizacin hacia una
integracin internacional. El resultado, en la mayora de las organizaciones, es el
aplanamiento de la estructura.

Las organizaciones que operan un cambio en su

estructura, basado en el enfoque de los procesos,
obtienen las siguientes ventajas:
1. Mayor calidad en menor tiempo y al menor coste.
2. Ms capacidad de respuesta al cambio de las necesidades y expectativas del
cliente.
3. Mejor posicionamiento ante el constante cambio en las oportunidades y
amenazas del mercado.
4. Despliegue del conocimiento existente en la organizacin para resolver
problemas y aadir valor.

Perfil de un Analista y TFEA

El analista es el encargado de generar una especificacin que satisfaga completamente
los objetivos de la gestin para el desarrollo de SW.

El analista idealmente debe tener las siguientes

caractersticas:
1. Habilidad para comprender conceptos abstractos, reorganizarlos en divisiones
lgicas y sintetizar soluciones basadas en cada divisin;
2. Habilidad para entresacar hechos importantes de fuentes conflictivas o confusas;
3. Habilidad para comprender entornos de usuario/cliente;
4. Un gran bagaje tcnico;
5. Conocimientos bsicos en otras disciplinas: administracin, economa,
organizacin.
Existen numerosas tcnicas aplicables a la especificacin, una de ellas es la

Tcnica para Facilitar la Especificacin de la Aplicacin (TFEA), Sus directrices bsicas

son:

1. Reunin en lugar neutral donde asisten tcnicos y clientes.

2. Establecimientos de reglas para la preparacin y participacin.
3. Agenda formal que cubra puntos importantes, e informal para que se desarrolle
un flujo de ideas.