Administracion Proyectos SW

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical
Gestin de Recursos TI
Por Richard H. Thayer
Resumen.- Este artculo trata de identificar y describir un conjunto global de la administracin de un proyecto y la administracin
de un proyecto de ingeniera de software que debe ser hecho por cualquier gerente al cual se le da responsabilidad de manejar
un proyecto de ingeniera de software. El artculo cubre las discusiones sobre las funciones Gerenciales de planificacin,
organizacin, asignacin de personal, direccin y control, en detalle; y las tareas especificas de la administracin de un proyecto
de ingeniera de software, las que son necesarias para manejar con xito un proyecto de ingeniera de software.
El concepto de la universalidad de la administracin nos permite usar las funciones gerenciales y actividades del proyecto de
ingeniera de software. A travs de un anlisis de arriba hacia abajo se dividieron cada una de las cinco funciones principales de
la administracin en un conjunto de actividades administrativas detalladas de las cuales a su vez se derivaron las actividades y
tareas detalladas de la administracin del proyecto de ingeniera de software. Estas actividades administrativas en detalle son las
funciones caractersticas de los gerentes. Las actividades y tareas detalladas tal como se describen en este artculo son las
funciones y responsabilidades caractersticas de la parte de ingeniera y de la administracin de un proyecto de ingeniera de
software.
1.
Introduccin
Este trabajo trata sobre administracin, administracin de un proyecto de ingeniera de software, y el concepto de universalidad
de gerencia.
Gerencia puede ser definida como todas las actividades y tareas emprendidas por una o ms personas, con el propsito de
planificar y controlar las actividades de otros, para lograr cumplir un objetivo o completar una actividad que no podra lograrse si
las otras personas actuaran solas.
La administracin de un proyecto, a su vez, se define como un sistema de procedimientos, prcticas, tecnologas y
conocimientos del tema que permiten la planificacin, organizacin, designacin de personal, direccin y control necesarios, para
poder manejar con xito un proyecto de ingeniera. El conocimiento (know-how, "saber como") en este caso quiere decir la
habilidad, antecedentes y buen juicio para aplicar el conocimiento efectivamente en la prctica. Si el producto es un software,
entonces la accin de gerenciar un proyecto de software se llama administracin de un proyecto de desarrollo de software, o
como se le conoce recientemente, administracin de un proyecto de ingeniera de software (SEPM). El gerente de un proyecto de
software se llama gerente de proyecto de ingeniera, o, en este artculo se le llama solamente gerente del proyecto (PM).
Los proyectos de ingeniera de software son frecuentemente, parte de un sistema global, de mayor tamao, que incluye equipo
(hardware), instalaciones, personal y procedimientos, adems del software. Los ejemplos son sistemas de industria area,
sistemas contables, sistemas de radar, etc. Estos proyectos de ingeniera de sistema son tpicamente manejados por uno o ms
gerentes de proyectos de sistemas (algunas veces llamados gerentes de programa) quienes administran una organizacin que
comprende ingenieros tcnicamente calificados (de todo tipo), expertos en el campo de aplicacin, especialistas cientficos,
programados, personal de apoyo y otros. Si el software se va a producir como un sistema de software auto suficiente, es decir,
un sistema que no se conecta con ningn otro sistema, que se est desarrollando para, o en un computador existente o
comercial de uso abierto, el gerente del proyecto de ingeniera de software puede ser el gerente del proyecto del sistema.
El concepto de universalidad de gerencia, viene de los principios de las ciencias administrativas, y quiere decir que:
La gerencia ejecuta las mismas funciones, sin tener en consideracin su posicin en la organizacin, ni la empresa
que se est administrando.
Las funciones de gerencia y actividades fundamentales son tareas caractersticas de los gerentes; las prcticas
gerenciales, mtodos, actividades detalladas y tareas, son propias de la empresa o del trabajo que se est
administrando.
Por lo tanto, las funciones y actividades fundamentales de la administracin pueden ser aplicadas universalmente a la
administracin de cualquier organizacin o actividad. La aplicacin de este concepto nos permite aplicar muchos de los
principales esfuerzos y xitos en el campo de la administracin al SEPM.
PERT y CPM -mtodos de programacin desarrollados en los aos 1950s.
Estructura de fragmentacin del trabajo (WBS) - un mtodo jerrquico de representar las relaciones entre las partes
de un producto (ensambles, sub-ensambles, componentes, partes etc.) o actividad (proyecto, sub-producto, tareas,
sub-tareas, paquetes de trabajo etc). Se aplic por primera vez al desarrollo del software en los aos 1960s;
Organizaciones de matriz -un mtodo de organizacin de proyecto desarrollado a comienzos de los 60, para combinar
lo mejor de una organizacin funcional con lo mejor de una organizacin de proyecto;
Administracin por objetivos (MBO) una metodologa de motivacin temprana, de los aos 1950s;
Necesidades de jerarqua de Maslow (1954) - otro modelo de motivacin; y
Administracin de configuracin -la disciplina de identificar la configuracin de un sistema en puntos determinados en

el tiempo, con propsitos de controlar sistemticamente los cambios en esa configuracin y para mantener la
integridad y posibilidad de rastreo de esta configuracin a travs del ciclo de vida del sistema.

La importancia de este tpico se ilustra mejor con un prrafo del informe del Departamento de Defensa (DoD) sobre la iniciativa
de tecnologa de ingeniera de software llamada STARS (Tecnologa de software para sistemas adaptables y confiables), un
proyecto de investigacin de ingeniera de software de mltiples millones de dlares. Dice el informe de DoD:
El gerente cumple un rol importante en el desarrollo y apoyo de software y sistemas. La diferencia entre el xito o el
fracaso -entre un proyecto que est en horario y en presupuesto, y otros que estn tarde y sobregirado- es con
frecuencia una funcin de la efectividad del gerente.
En otras palabras, hoy en da SEPM es la llave del xito de un proyecto de ingeniera de software.
Este artculo intenta identificar y describir un conjunto global de funciones de administracin de proyectos y de administracin de
proyecto de ingeniera de software, que deben ser emprendidas por cualquier gerente al que se le da la responsabilidad de
administrar un proyecto de ingeniera de software. Cubre las funciones gerenciales de planificacin, organizacin, asignacin de
personal, direccin y control, y en detalle, las actividades y tareas especficas de administracin que son necesarias para la
administracin con xito un proyecto de ingeniera de software.
La seccin 2 analiza y hace una divisin de las funciones de gerencia en una lista de actividades detalladas de gerencia. Las
secciones 3 hasta 7, a su vez, dividen estas actividades de gerencia en las actividades y tareas detalladas de SEMP.
2.
Funciones y Actividades de la Administracin
Este informe toma un enfoque vertical para establecer un conjunto de responsabilidades, actividades y tareas de SEPM, que
deberan ser emprendidas por cualquier gerente al cual se le asigne La responsabilidad de administrar un proyecto de ingeniera
de software. El enfoque vertical, hacia abajo, involucra el dividir y asignar funciones de alto nivel a actividades y tareas de nivel
inferior.
El concepto de la universalidad de la administracin nos permite usar las funciones de administracin y actividades bsicas de
las principales corrientes de administracin, como las funciones y actividades de alto nivel del SEMP. La Figura 2.1 describe el
modelo de administracin clsico, auspiciado por autores tan conocidos en el campo de la administracin como Koontz y
O'Donnell, y otros.
En este modelo, la gerencia se parte en cinco funciones o componentes diferentes: planificacin, organizacin, dotacin de
personal, direccin y control (vea la Tabla 2.1 para las definiciones o explicaciones de esas funciones. Todas las actividades de la
administracin, tales como presupuestos, horarios, determinacin de las relaciones de autoridad, capacitacin, comunicacin,
monitoreo y etc., estn comprendidas en uno de estos cinco rubros.

Esto no quiere decir que las cinco funciones sean totalmente
independientes unas de otras.
Algunos ejemplos de las interrelaciones de las funciones de
administracin son:
(1) Planificaci6n para la organizacin de la actividad;
(2) Organizaci6n para la planificacin del proyecto;
(3) Control de la funci6n de planificaci6n;
(4) Organizaci6n del personal de la organizaci6n;
(5) Dotar de personal a la organizacin que se est planificando.
Sin embargo, a pesar de estas interrelaciones, cada actividad de un
gerente debe estar situada dentro de una y solamente una, de las
cinco funciones de administracin. Por ejemplo, el nmero ( 1) arriba
descrito, es una funcin de planificacin, (2) y (4) son funciones de
organizacin, (3) es una funcin de control y (5) es una funcin de
asignacin de personal.
Cada una de las principales cinco funciones de administracin de la
Figura 2.1 pueden ser nuevamente divididas en un conjunto de
actividades fundamentales de administracin detalladas (vea la Tabla
2.2), las que a su vez, se pueden dividir nuevamente en tareas ms
detalladas ( vea la Figura 2.2, que ilustra este flujo hacia abajo).
Estas actividades son las tareas caractersticas de los gerentes y
pueden ser aplicadas a la administracin de cualquier organizacin o
actividad. (Las definiciones o explicaciones de estas actividades se
encuentran en las Tablas 2.3 hasta 2.7).
Las actividades detalladas y tareas que son propias del proyecto de
ingeniera de software se discuten en las Secciones 3 al 7. Cada una
de esas secciones define y discute una de las cinco funciones junto
con algunos de los temas principales de esa funcin. Las actividades
de administracin de la Tabla 2.2 se dividen en uno o ms niveles de
detalles, llamados tareas (vea las Tablas 3.1, 4.1, 5.1, 6.1 y 7.1), las
que luego se discuten y/o ilustran en la seccin apropiada.

3.
Planificacin de un proyecto de ingeniera de Software
Introduccin y Definiciones
La planificacin de un proyecto de ingeniera de software consiste en todas las actividades administrativas que conduzcan a la
seleccin, entre alternativas, de futuros cursos de accin para el proyecto, y el programa para llevar a cabo las acciones.
La planificacin involucra seleccionar los objetivos y las metas del proyecto y planificar estrategias, polticas, programas y
procedimientos para lograrlos. "Planificacin es decidir, por adelantado, qu hacer y cmo hacerlo, cundo hacerlo y quin lo va
a hacer".
Es esencial reconocer que todos los proyectos exitosos de ingeniera de software comienzan con un buen plan. Las
incertidumbres del futuro y los cambios, tanto en el medio de ingeniera de software como por fuentes externas, hacen que la
planificacin sea una necesidad. La planificacin focaliza la atencin en los objetivos. El mismo acto de aclarar y documentar los
objetivos del proyecto, harn resaltar los objetivos y metas del proyecto.
El plan del proyecto debe ser eficiente, es decir, las contribuciones del plan deben ser mayores que los costos del plan y de otros
efectos colaterales indeseables. La funcin de planificacin, no es un esfuerzo rgido de una sola vez. La planificacin debe ser
dinmica, flexible, y sujeta a cambio, cuando el ambiente o el proyecto cambien.
Temas principales de la planificacin
Los mayores temas (problemas) en la planificacin para un proyecto de ingeniera de software son:
Los requerimientos de software (objetivos del proyecto) son difciles de escribir correctamente.
La planificacin de un programa de accin es frecuentemente incompleta y/o descuidada.
Los costos del software y los horarios son difciles (si no imposible) de preparar con exactitud.
No se tienen a mano los criterios para seleccionar la mejor o ms apropiada metodologa (procedimiento) para el
anlisis, diseo, prueba o administracin del proyecto.
Es difcil escribir correcta, completamente y sin ambigedades los requerimientos del software. Como resultado, un proyecto
puede tener objetivos poco claros e incompletos. Esta vaguedad puede dar como resultado malos estimados de costos y de
horario. Los costos y horarios son elementos esenciales en un programa de manejo o de accin.
Sin embargo, lo ms importante es que la planificacin, con frecuencia, o es deficiente, o no se hace. O, cuando se hace, la
planificacin no es tomada en cuenta y no se mantiene (actualiza) si es que cambian las condiciones.
La funcin de planificacin usualmente no se puede transferir slo los cdigos son transferibles. Por eso, a los gerentes les
parece que la planificacin presenta un costo innecesario y que es mejor descartarla y ahorrar el dinero para la programacin y
las pruebas. An en proyectos del tipo DoD, donde generalmente se necesita un documento de planificacin dentro los primeros
30das del proyecto, el documento slo se revisa
superficialmente y en muchos casos se deja en un estante olvidado una vez producido.
Los presupuestos y horarios de software son difciles para preparar con exactitud. Hoy, existen en el mercado muchos modelos
de costos y horarios de software, cada uno de ellos requiere que el usuario estime el tamao del proyecto usando lneas de
cdigo u otra forma de medida, para un sistema que an tienen que ser producido. Este estimado es muy difcil de hacer en las
primeras etapas del proyecto, y con frecuencia resulta en una inexactitud en presupuesto u horario para el proyecto.
A pesar del nmero de diferentes mtodos de desarrollo de ingeniera de software (a veces llamadas prcticas de programacin
modernas) y herramientas automatizadas, que se encuentran hoy en el mercado, casi no hay datos que indiquen cules son las
tecnologas mejores o ms costo-efectivas. Los PM de ingeniera de sistema se enfrentan con la tarea ms difcil: seleccionar
qu mtodos y/o herramientas usar, si se usan. Y otra tarea casi tan difcil es convencer a los jefes de su corporacin que su
eleccin es una aproximacin costo-efectiva. Esto es, en parte, una de las razones por las cuales la mayora de los proyectos de
desarrollo de software usan poco las herramientas de software (Vea el trabajo de RADC y NASNSEL, y la discusin a este
captulo, para los mtodos que ayudan en esta rea).
Planificacin Actividades y Tareas
La Tabla 3.1 proporciona un delineamiento de las actividades y tareas e SEPM, que deben ser hechas por los PMs en la
planificacin de sus proyectos. El gerente del proyecto es responsable de desarrollar numerosos tipos de planes. La Tab1a 3.2
contiene una lista de planes de gerencia generales, que se aplican para cualquier proyecto de software.
Esta seccin discute y proporciona mayor detalle en las actividades y tareas esbozadas en la Tabla 3.1.

Establezca objetivos y metas
El primer paso de planificacin para un PM de ingeniera de software es determinar qu es lo que el proyecto debe lograr, cundo
lo debe lograr y qu recursos son necesarios. Es tpico que en un proyecto de ingeniera de software esto comprenda el analizar
y documentar los requerimientos del sistema y software. Adems, el PM debe determinar los requerimientos y limitaciones de
administracin. Dentro de stas con frecuencia se encuentran las limitaciones de recursos y de horarios.
Los gerentes tambin tienen que establecer objetivos y criterios de xito para sus proyectos. Se puede aducir que los objetivos y
criterios de xito sern siempre la entrega de un sistema de software a tiempo y dentro de los costos, cumpliendo con los
requerimientos del proyecto. Esto no siempre es as. Por ejemplo, xito podra ser, no solamente entregar el sistema sino
tambin ganar un contrato para el desarrollo del seguimiento. Otros posibles objetivos para el PM pueden ser aumentar el
tamao del contrato o aumentar el margen de utilidades a travs de modificaciones hechas con el que contrata, o aumentar el
margen de utilidades ganando un premio de incentivo.
Desarrolle estrategias
Otra gran empresa del PM es desarrollar y documentar un conjunto de estrategias de manejo (a veces llamadas polticas
estratgicas), para un proyecto. Se definen a las estrategias, como metas a largo plazo y los mtodos para lograr esas metas.
Estas metas a largo plazo y los mtodos, son generalmente desarrollados a nivel de la corporacin; sin embargo, el PM tambin
puede tener planes estratgicos dentro de su proyecto. Esto es particularmente real si se trata de un proyecto grande. Un
ejemplo de un plan estratgico sera obtener una mayor parte del proyecto (una que se est compartiendo con otro contratista o
agencia) y hacer un plan para obtenerla.
Desarrolle polticas
Las polticas se ocupan de decisiones gerenciales predeterminadas. El PM establecer
polticas dentro de su proyecto para ayudar y guiar otros PMs, supervisores, y miembros individuales del equipo, para hacer
decisiones rutinarias. Estas polticas hacen ahorrar mucho tiempo. Reducen la necesidad de que el PM tenga participacin en
cada unos de las decisiones. Tambin proporcionan una sensacin de seguridad a los miembros del equipo.
En muchos casos el PM no desarrolla polticas nuevas para el proyecto, sino que selecciona entre las polticas establecidas por
su corporacin. Un ejemplo de un conjunto de polticas de desarrollo de software, a nivel de la corporacin es:
Poltica de Especificaciones de requerimientos de software
Los proyectos de software prepararn una especificacin de requerimientos de software para el control del funcionamiento,
rendimiento y requerimientos de conexin, para los productos terminales de software. Esta poltica requiere proyectos para:
Producir especificaciones de los requerimientos de software antes de la revisin de los requerimientos de software en
formatos especificados por contrato o por estndares de la corporacin.
Obtener aprobacin escrita del cliente para esta especificacin como base de la aceptacin de proyecto final de
programa de cmputo y base de datos.
Obtener aprobacin escrita por parte de la corporacin y del cliente para todos los subsecuentes cambios de las
especificaciones.
Determinar los cursos de las acciones
En la mayora de los proyectos hay ms de una forma de entregar con xito el proyecto- pero no con igual costo, igual horario o
igual riesgo. Es la responsabilidad del PM el determinar un nmero razonable de enfoque o programas, para poder efectivamente
implementar los requerimientos de software. Por ejemplo, una aproximacin podra ser muy costosa en trminos de mano de
obra y mquinas, pero recudir dramtica y efectivamente la calendarizacin. Otro punto de vista podra ser reducir tanto el costo
como el tiempo, pero tomar un gran riesgo de no poder entregar el sistema. Una tercera aproximacin podra alargar el tiempo, y
por lo tanto reducir el costo del proyecto. El gerente debe analizar cada curso de accin para determinar las ventajas,
desventajas, riesgos y beneficios (Vea el artculo de Boehm para la descripcin de un modelo de ciclo de vida del desarrollo de
software que incorpora anlisis de riesgo y toma de decisiones).
Tome decisiones
El PM toma las decisiones ms importantes para el proyecto. l junto a su cliente, determina el futuro rumbo del proyecto.
Determina cul de los muchos caminos es el ms apropiado para lograr las metas y objetivos del proyecto.
El PM es el responsable por las decisiones comerciales, que comprenden costos, calendarizacin, estrategias de diseo, y
riesgos (vea el artculo de Bunyard y Coward).
El PM tambin es el responsable de seleccionar (o su compaa selecciona por l a travs del uso de estndares) los mtodos
mediante los cuales su proyecto ser manejado y desarrollado. Por ejemplo, qu estrategias se usarn, si sern analizados los
requerimientos por mtodos de anlisis estructurado" o por diagramas de Warnier-Orr". Se harn las pruebas de arriba hacia
abajo, de abajo hacia arriba, de las dos formas? Qu herramientas, tcnicas y procedimientos se usarn para la planificacin de
un proyecto de desarrollo de software? PERT, CPM, diagramas de carga de trabajo, diagramas de parada de trabajo (WSS),
diagrama de Gantt etc., son ejemplos de herramientas de manejo de proyectos.

El seleccionar las herramientas y mtodos de desarrollo de software ms apropiados y ms costo-efectivos, es una tarea muy
difcil. Se describe ayuda en esta rea para el esfuerzo de investigacin que sigue.
Investigacin y desarrollo (R & D) las Metodologas de desarrollo de software
Tanto el Laboratorio de Ingeniera de Software (SEL) de NASA en el Centro Espacial de Goddard como el Centro de Desarrollo
Espacial de Roma (RADC) han hecho investigacin y desarrollo para determinar mtodos que puede usar el PM para seleccionar
el conjunto apropiado de herramientas, mtodos y metodologas de desarrollo de software.
Recientemente el personal del SEL ha estado conduciendo una investigacin para determinar la efectividad de las diferentes
tecnologas de ingeniera de software. Aunque NASA/SEL no ha podido encontrar ninguna mejora mensurable en la
productividad del software a partir del uso de las herramientas de desarrollo de software han encontrado incrementos en la con
fiabilidad del software mediante el uso de prcticas modernas de programacin y mediante un programa regular de garanta de
calidad. NASA tambin encontr que los principales factores tanto para la continuidad de la productividad como para confiabilidad
del software, sern la capacidad y rendimiento personal de la gente que desarrolla el software. Individualmente (vea la discusin
de la seccin 5).
RADC ha desarrollado un manual (un conjunto de procedimientos) para seleccionar la metodologa apropiada para el desarrollo
del software. Este manual es para gerente tcnicos y da pautas para la seleccin de metodologas apropiadas para
requerimientos y especificaciones de diseo para varios medios de desarrollo de software y tipos de software. El manual cubre el
anlisis de requerimientos de diseo arquitectnico y detalles de las fases de diseo del ciclo de vida del desarrollo del software.
Establezca los procedimientos y reglas
Al contrario que con las polticas los procedimientos establecen mtodos usuales para manejar futuras actividades y
proporcionan guas para tomar accin en vez de para tomar decisin. Los procedimientos detallan la manera exacta mediante la
cual se logra una actividad, y dan poco margen de accin. Una regla" aunque es algo similar, establece acciones especficas y
definidas para ser tomadas o no, con relacin a una situacin y no permite modificacin.
El PM establece los procedimientos y reglas para el proyecto. U n ejemplo de un procedimiento podra ser un mtodo para
analizar el requerimiento de software o una serie de pasos para potenciar un computador. Una regla podra ser, por ejemplo, el
requerimiento de tener dos personas haciendo turno en el cuarto de la mquina, en todo momento, o no permitir a los empleados
fumar en la cafetera.
Los estndares del proceso (en contraste a estndares del producto) se usan como procedimientos. Se pueden adoptar los
estndares de una corporacin de mayor tamao, o se pueden escribir para un proyecto en especial. Ejemplos de estndares
son mtodos de emitir informes, metodologas de desarrollo de software y requerimientos de preparacin de documentacin.
El siguiente es un ejemplo muy corto de un procedimiento para establecer un plan:
Procedimientos para el desarrollo de un plan:
(1) Establezca los objetivos de la operacin para la cual se est desarrollando el plan.
(2) Haga elucubraciones sobre lo que se espera del medio, en el futuro, en el cual operar el plan.
(3) Determine varios caminos alternativos que completaran con xito los objetivos de las tareas (sin embargo, no siempre
se hacen con el mismo costos y riesgo).
(4) Evala las alternativas. Determine cul es la que cumple con los criterios de aceptacin (costo ms bajo, riesgo ms
bajo, y/o menor tiempo de calendarizacin).
(5) Seleccione un curso de accin.
(6) Formule un plan detallado para el cumplimiento de los objetivos.
Desarrolle programas
Cuando un PM de ingeniera de software "Planifica" un proyecto, est desarrollando un programa de accin para su proyecto. El
programa de desarrollo (no confundir con el programa de cmputo) establece las acciones necesarias para entregar con xito un
proyecto.
Tpicamente, el gerente debe determinar:
(1) Las tareas que deben ser realizadas por el personal de desarrollo de software, para entregar el producto final de
software. Esto usualmente requiere dividir el producto del proyecto, o las actividades del proyecto, en tareas cortas
que se puedan medir. Una herramienta til para representar la divisin del proceso / producto en el WBS. (Por lo
general, se asigna cada tarea a un grupo pequeo de personal de desarrollo, llamado equipo de programacin).
(2) El costo y recursos necesarios para lograr con xito el programa.
(3) El calendario del programa, al determinar las prioridades de las acciones, estableciendo hitos que se deban alcanzar,
y creado el cronograma detallado necesario para alcanzar el hito y para lograr los objetivos del proyecto (Para una
mayor discusin de planificacin, vea a Miller, 1978).

Prediga las situaciones futuras
El PM es responsable de predecir y hacer elucubraciones sobre el futuro, con relacin al impacto que ste tendr en el proyecto
de ingeniera de software.
El predecir el futuro puede ser de dos maneras. Una primera forma es prediciendo eventos futuros, por ejemplo, la disponibilidad
de mano de obra prediciendo tasas de inflacin, o la disponibilidad de nuevo hardware de cmputo, y el impacto que esto tendr
en el proyecto de ingeniera de software.
El segundo mtodo es estimando cmo el proyecto de ingeniera de software cumplir con las expectativas y elucubraciones
sobre el futuro. Por ejemplo, los futuros gastos de recursos disponibles y de los fondos del proyecto versus el proyecto. El PM
tambin es responsable para estimar futuros riesgos y desarrollar planes de emergencia para contrarrestar esos riesgos.
Es decir, uno vaticina el futuro, y el otro estima cmo reaccionar el proyecto en ese futuro vaticinado.
Prepare un presupuesto
El poner cifras en el programa, se llama presupuestar .El PM es responsable de determinar el costo del proyecto y en asignar el
presupuesto a las tareas del proyecto o centros de costos. El presupuesto es el comn denominador para todas las cosas que
contiene el plan de administracin.
Los requerimientos para mano de obra, para cmputo, espacio de equipo de oficina y otros, slo pueden ser comparados y se
pueden hacer concesiones comerciales cuando se miden estos requerimientos en trminos de presupuesto.
El PM es responsable de asignar el presupuesto aprobado a varios elementos del proyecto. En algunos proyectos, cada entidad
del proyecto tiene su propia participacin en el presupuesto y la autoridad para gastarlo, para cumplir con sus metas.
Documente los planes del proyecto
El PM es responsable de documentar el plan del proyecto y tambin de preparar otros documentos tales como el plan de
garanta de calidad, el plan de configuracin, el plan de dotacin de personal y otros planes tales como documentos de prueba.
El plan del proyecto es el medio ms importante que tiene el PM para comunicarse con todas las agencias externas que se
interrelacionan con el proyecto y la manera de informarles qu es lo que el gerente espera hacer y qu es lo que el gerente
espera de ellos. Adems, otros planes (vea nuevamente la Tabla 3.2) debern ser documentados y actualizados conforme sea
necesario.
4.
Organizando un proyecto de ingeniera de software
Introduccin y definiciones
Organizar un proyecto de ingeniera de software es todas las actividades administrativas que resultan del diseo de una
estructura formal de tareas de ingeniera de software, y las relaciones de autoridad entre estas tareas.
Organizacin comprende determinar y dividir en items las actividades del proyecto que son necesarias para lograr los objetos del
proyecto de desarrollo de software, y arreglar estas actividades en grupos lgicos. Tambin involucra asignar dichos grupos de
actividades a una entidad de la organizacin (frecuentemente llamada un equipo del proyecto) dentro del proyecto y delegar
responsabilidad y autoridad para que el equipo lleve a cabo sus actividades.
El propsito de una estructura organizativa es "focalizar los esfuerzos de muchos en una meta seleccionada". El PM selecciona
la mejor estructura para el proyecto tomando en consideracin el ambiente existente del proyecto.
Puntos a considerarse cuando se organiza
Los puntos ms importantes (o problemas) cuando se hace la organizacin de un proyecto de ingeniera de software son:
Es difcil determinar la mejor estructura organizativa para el proyecto por ejemplo proyecto matriz o funcin.
Las responsabilidades para las actividades y tareas a veces no se definen o no son claras.
Las organizaciones funcionales de software y los miembros individuales del personal, no creen que la estructura
organizativa de tipo matriz sea beneficiosa para ellos.
Hay un espectro completo de tipos de organizacin de proyectos que van desde el tipo meramente funcional hasta el tipo de
proyecto "todo en uno". Es difcil determinar la mejor estructura de organizacin para el proyecto y para la organizacin que est
construyendo el proyecto. La organizacin del proyecto se ve como la mejor estructura organizativa para desarrollar un gran
sistema de software. Crea un control centralizado sobre el proyecto y hace que un gerente sea responsable por la entrega final
del producto de software. La gerencia ms alta y los clientes se sienten "cmodos" con este arreglo. Al contrario, la organizacin
funcional se ve como la estructura ptima para alentar a ingenieros de software que son altamente experimentados, difciles de
contratar y muy caros. Las personas individuales de desarrollo se sienten bien con este arreglo.
La organizacin de tipo matriz se acepta hoy en da como la mejor concesin entre las organizaciones del proyecto y funcional.
Pero debido a los conflictos que se originan en la organizacin de matriz (problema de dos jefes), y entre los gerentes de lnea
funcional, quienes proporcionan los ingenieros de software a la organizacin de matriz, y el PM del proyecto de matriz, muchos
gerentes ven a la organizacin de matriz como conflictiva para toda la organizacin en general.

Adems los ingenieros de software, individualmente, creen que la organizacin de matriz no les beneficia en sus carreras
individuales. La gente que est en la matriz pareciera que est siendo empujada de un proyecto a otro. Tienen que reportar tanto
al gerente funcional como al PM, y sienten que nadie vela por sus carreras. Esto es en efecto cierto, en el caso de gente de
software, quienes nunca avanzan a ser promovidos a PM, sino solamente son asignados a proyectos.
Los gerentes funcionales, particularmente cuando la organizacin de matriz es nueva, resienten el perder la responsabilidad por
la entrega del software. Resienten el tener que manejar una tienda de cuerpo para el beneficio de las organizaciones del
proyecto. Esto es cierto para el caso de matrices dbiles" donde el gerente de matriz comparte la responsabilidad con el gerente
funcional. A su vez, el PM resiente tener la responsabilidad funcional para las decisiones tecnolgicas, como por ejemplo
introduccin de estndares y tecnologa.
El conflicto se extiende ms cuando las designaciones de responsabilidades no estn claras entre las organizaciones (y la
gente). Esto es particularmente cierto en el caso de organizaciones de matriz. Uno de los principales problemas en cualquier
compaa es que si las responsabilidades no estn claramente identificadas, los conflictos ocurren cuando dos organizaciones
tratan de hacer el mismo trabajo, o peor an, se convierte en una situacin donde ninguna hace las tareas.
Los artculos de Fife, Youker, y Mantei proporcionan los criterios para seleccionar la estructura organizativa apropiada, para el
producto y proceso de software. Tanto Stuckenbruck como Youker indicaron la necesidad de que una alta gerencia produzca un
diagrama de proyecto claro (documento) para la organizacin de matriz, para as definir responsabilidades para el PM y tambin
para definir el rol de los departamentos funcionales.
Organizando actividades y tareas
La Tabla 4.1 proporciona los lineamientos de las actividades del SEPM que deben ser cumplidas por el PM, al organizar un
proyecto. El balance de esta seccin discute y proporciona ms detalles de las actividades y tareas delineadas en la Tabla 4.1.
Identifique y agrupe las tareas requeridas
El gerente es responsable de la revisin de los requerimientos del proyecto, definiendo las diferentes tareas que deben ser
cumplidas, determinando el tamao de esas tareas y agrupando de manera ptima esas tareas. Asigna nombres de puestos y
entidades organizativas para el conjunto de tareas; por ejemplo, la tarea de programador analista, sucursal de operaciones y
otras. Esta informacin permite entonces al PM decidir sobre la mejor estructura organizativa para el control mximo de esos
grupos. En la Tabla 4.2 se puede ver un ejemplo de esto.
El PM tambin tienen que identificar las tareas de apoyo necesarias tanto desde dentro o por fuera del proyecto. Los ejemplos de
tareas internas son el apoyo de secretara, apoyo de procesamiento de textos, monitoreo financiero, administracin del proyecto,
y control de proyecto. Por fuera del proyecto hay tareas asociadas con requerimientos de viajes, pools automotores, guardias de
seguridad, apoyo de funcionamiento de cmputo, etc.
Seleccione y establezca las estructuras organizativas
El software o los sistemas de software generalmente se construyen para un cliente por una organizacin temporal llamada
proyecto de desarrollo de software. El proyecto de desarrollo de software puede ser organizado de acuerdo a diferentes tipos
organizativos que se superponen. Por ejemplo:
Estructura organizativa convencional puede ser un tipo de organizacin de lnea o de personal.
Estructura de organizacin de proyecto -puede ser un tipo de organizacin funcional, de proyecto o de matriz.
Estructura de equipo -pueden ser equipos sin ego, de programador jefe, o de proyecto (jerrquico).
Muchos PMs no pueden darse el lujo de seleccionar el mejor tipo organizativo porque esto est determinado por la poltica a nivel
de compaa o de la corporacin. Sin embargo, independientemente de quin lo haga, de debe identificar el tipo y estructura
organizativa, que ser ms compatible con las necesidades y metas de la aplicacin y ambiente del proyecto.
Los siguientes prrafos describen estos tipos organizativos.
4.3.2.1 Estructuras organizativas convencionales.- Una organizacin de lnea tiene la responsabilidad y autoridad de realizar el
trabajo que representa la misin principal de la unidad organizativa ms grande. En contraste, la organizacin de personal es un
grupo de expertos funcionales que tienen la responsabilidad y autoridad para ejecutar actividades especiales que ayudan a la
organizacin de lnea a hacer su trabajo. Todas las organizaciones de una compaa son o de lnea o de personal.
4.3.2.2. Estructura organizativa de proyecto.- Una estructura organizativa de proyecto es una organizacin especial que se ha
establecido para el propsito de desarrollar y construir algo, que es demasiado grande para hacerlo por uno, o como mximo, por
algunos individuos. En un proyecto de ingeniera de software, el "algo" es un sistema de software. La estructura organizativa de
proyecto puede ser impuesta en la parte superior de una organizacin de lnea o de personal. Por ejemplo, una organizacin de
ingeniera de software funcional puede ser una organizacin de lnea o de personal (Ver Figura 4.1 para ilustrar el uso de las
cinco organizaciones de lnea que se usan en organizaciones funcionales de ingeniera de software). La Figura 4.1 es la
estructura organizativa del ejemplo de la Tabla 4.1.

Organizacin funcional de proyecto.- Un tipo de organizacin de proyecto es una organizacin funcional; una estructura de
proyecto construida alrededor de una funcin de ingeniera de software o grupo de funciones similares. Las organizaciones
funcionales generalmente son continuas.
Un proyecto se cumple ya sea dentro de la unidad funcional, o si es multifuncional, entre dos unidades funcionales o ms. Se
logra el proyecto pasando el proyecto de funcin a funcin a medida que el proyecto pasa a travs de las fases del ciclo de vida.
La Figura 4.2 ilustra las tareas y lneas de autoridad de una organizacin funcional, usada para desarrollar un proyecto.
En la figura, el anlisis y especificaciones de requerimientos de software se preparan por el grupo de ingeniera de sistemas de
software, bajo la supervisin del supervisor de grupo. Cuando est terminado (o se cree que est terminado) el grupo de
ingeniera de sistemas transfiere las especificaciones del software al grupo de aplicaciones de ingeniera de software, que est
ms al tanto de la aplicacin. El grupo de aplicaciones de ingeniera de software, usando las especificaciones de requerimientos,
disea el sistema de software bajo la supervisin del supervisor del grupo de aplicaciones de ingeniera de software, y as
sucesivamente. En nuestro ejemplo, el grupo de aplicaciones tambin programa el sistema de software, y luego pasa el cdigo
terminado al grupo de ingeniera de prueba de software para las pruebas.
Las herramientas y sistemas de apoyo son proporcionados por el grupo de apoyo de software de sistema. No hay un supervisor
general para todo el proyecto.
Para una mayor discusin del ejemplo ilustrado en la Figura 4.2, el Proyecto 1 est bajo el control y supervisin del gerente de
ingeniera de sistema, y el Proyecto 2 est bajo el monitoreo de un representante del usuario, quien reporta a la alta gerencia. El
representante del usuario no supervisa al personal ni controla el proyecto. El representante del usuario coordina el proyecto,
monitorea el progreso (reportando a la alta gerencia cuando las cosas no van de cuerdo al plan), y acta como un enlace comn
con el usuario. Note que un ingeniero del Grupo de Aplicacin SE 1 es compartido por dos proyectos -algo comn en el medio de
hoy.
Organizacin de proyecto.- Otro tipo de organizacin de proyecto se construye alrededor de un proyecto especfico; el gerente
tiene la responsabilidad, autoridad y recursos para completar el proyecto. (La organizacin de proyecto se llama a veces
organizacin proyectada, para no usar el trmino "organizacin de proyecto del proyecto"). El gerente debe cumplir sus metas
dentro de los recursos de la organizacin. Generalmente tiene la responsabilidad de contratar, despedir, entrenar y promover a la
gente dentro de su organizacin de proyecto. La Figura 4.3 muestra las tareas y lneas de autoridad de una organizacin de
proyecto que se usa para desarrollar un proyecto.
Organizacin de matriz de proyecto.- La tercera organizacin de proyecto es la organizacin matriz (a veces llamada
organizacin de matriz de proyecto), la cual es una concesin entre la organizacin funcional y la organizacin de proyecto. La
organizacin de matriz tambin se construye alrededor de un proyecto especfico. Los gerentes tienen la responsabilidad y
autoridad para completar el proyecto. Las funciones de lnea o de personal (usualmente llamadas las gerencias de recursos)
proporcionan los recursos cuando son necesarios. El PM generalmente no tiene la autoridad para contratar, despedir, entrenar o
promover al personal dentro de su proyecto. La Figura 4.4 ilustra la organizacin de matriz usada para desarrollar un proyecto.
Note la similitud entre el proyecto funcional y la organizacin de matriz (y tambin note las diferencias). En el ejemplo dado, el
Proyecto 1 est bajo el control y supervisin del gerente de ingeniera de software funcional, y el Proyecto 2 bajo el control de la
"alta gerencia". En el Proyecto2,la supervisin de los ingenieros asignados est compartida entre el gerente funcional y el
gerente de programa. Tpicamente, el gerente de programa y el gerente de proyecto de software son responsables de las
supervisiones diarias del grupo de ingeniera de software, y el gerente funcional es responsable de la carrera, entrenamiento, y
bienestar del mismo grupo de gente.
Note nuevamente que, tal como se muestra en la Figura 4.4, un (o ms de uno) ingenieros en el grupo de apoyo de sistema es
compartido por dos proyectos -un hecho comn en una organizacin de matriz.
4.3.2.3 Equipos de proyecto.- Adems de la estructura organizativa descrita antes, un proyecto de desarrollo de software tpico
se organiza alrededor de un equipo de ingeniera de software de 5 a 7 miembros. Los ejemplos de estas estructuras son los
equipos de programacin sin ego, equipos de programador jefe y equipos de proyecto (jerrquicos).
La estructura de equipo sin ego fue desarrollada por Weinberg. Un equipo tpico sin ego consiste de 10 a 12 miembros. Las
discusiones y decisiones se hacen por consenso. El liderazgo del grupo es rotativo; no hay autoridad central permanente.
Equipo de programador jefe.- El equipo de programador jefe fue usado por la IBM por primera ven en el ahora famoso Proyecto
Morgue de Nueva York. El equipo consiste de tres a cuatro miembros de equipo permanentemente asignados -el programador
jefe, el programador de respaldo y el programador bibliotecario- ms otros programadores auxiliares y/o analistas que se aaden
conforme sea necesario. El programador jefe maneja todos los aspectos tcnicos y hace las decisiones administrativas. El
bibliotecario mantiene los documentos, cdigos y datos al da, y ejecuta todo el trabajo administrativo.
Equipo de proyecto (jerrquico}.- El equipo de proyecto es una organizacin estructurada en la cual el jefe del proyecto maneja a
programadores senior y los programadores senior manejan a los programadores junior. El equipo de proyecto a veces se llama
jerrquico por su flujo de autoridad de arriba hacia abajo. Muchos equipos de proyecto practican revisiones sin ego (recorridos) y
usan una biblioteca de apoyo al programador. Los programadores senior aseguran la calidad del producto.
Fuerzas y debilidades de los tipos organizativos del proyecto.- Al seleccionar un proyecto funcional o una estructura organizativa
de matriz, es importante que el PM compatibilice las necesidades del proyecto con las diferentes fuerzas y debilidades del tipo de
proyecto. La Tabla 4.3 muestra las ventajas y desventajas de los seis tipos organizativos.

El proyecto de ingeniera de software es una organizacin de lnea o de personal. El PM debe decidir si el proyecto funcionar
como organizacin funcional de proyecto o de matriz y si el proyecto tendr equipos de tipo sin ego de programador jefe o de
proyecto. (Los equipos de programador jefe y sin ego estn casi extintos. Sin embargo, el concepto de bibliotecario del equipo de
programador jefe y las revisiones tcnicas (recorridos) del equipo sin ego, se usan frecuentemente en los muchos equipos de
proyecto de ingeniera de software).
La mayora de los proyectos de ingeniera de software de la industria aeroespacial usan la organizacin de matriz con equipos de
proyecto. Algunas pocas compaas usan el equipo de programador jefe solamente de nombre (con frecuencia el supervisor del
equipo no est calificado para ser un programador jefe).
Cree puestos organizativos
Una vez que las tareas se han identificado, se ha determinado su tamao y se han agrupado, y se han identificado las
conexiones entre estas tareas, el gerente debe crear nombres y descripciones de puestos para ellas. Es con estos nombres y
descripciones de puestos que la organizacin de personal reclutar y/o transferir a futuros miembros para este proyecto.
A continuacin se muestran algunos ejemplos cortos de nombres y descripciones de puestos de ingeniera de software tpicos:
Gerentes de proyectos -responsables del desarrollo e implementacin de sistema dentro de reas funcionales
importantes. Dirigen los esfuerzos de los ingenieros, analistas y programadores de software y de otro personal del
proyecto.
Ingeniero de software -disea y desarrolla software para impulsar los sistemas de cmputo. Desarrollan firmware,
unidades, software especializado como por ejemplo grficos, comunicaciones, controladores, operando sistemas y
aditamentos amigables para usuarios. Trabajan estrechamente con ingenieros de hardware y programadores de
aplicaciones y sistemas, y necesitan comprender todos los aspectos del producto.
Programadores cientficos de ingeniera, programadores analistas -ejecutan un diseo detallado del programa, cdigo,
pruebas, depuracin, documentacin de aplicaciones de cmputo cientficas de ingeniera y otras aplicaciones que
son de naturaleza matemtica.
Muchos ayudan a las especificaciones y diseo total del sistema.
Defina Las responsabilidades y autoridad
La autoridad puede ser definida como "el grado de discernimiento en los puestos organizativos, confiriendo a las personas que
ocupan este puesto el derecho de usar su criterio en la toma de decisiones. Se dice con frecuencia que la responsabilidad no
puede ser compartida ni delegada.
Koontz y O'Donnell apoyan este punto de vista al definir la responsabilidad como "la obligacin que tienen los subordinados con
sus supervisores para ejercer la autoridad delegada en ellos, para lograr los resultados esperados". Este artculo toma la posicin
de que la responsabilidad para las actividades o tareas organizativas sea asignada a al posicin organizativa (junto con la
autoridad correspondiente) al momento que se crea o se modifica el puesto. Se designa al PM. ya su vez se asigna la
responsabilidad y la correspondiente autoridad a los diferentes puestos organizativos agrupados de tareas dentro del proyecto.
El PM tambin establece las lneas de autoridad entre las tareas. Por lneas de autoridad se entiende qu tareas tienen
precedencia sobre otras, para lograr un objetivo. Por ejemplo, anlisis tienen autoridad sobre diseo, diseo sobre cdigo, etc.
Establezca las calificaciones del puesto
Se debe identificar las calificaciones para cada puesto de la organizacin. Qu tipo de persona quiere para su proyecto? Cunta
experiencia es necesaria en el rea de aplicacin: ninguna, una, dos, tres aos? Cunta educacin es requerida: Bachiller en
Ciencias en Computacin, Maestra en Ciencias en inteligencia artificial? Qu tipo de entrenamiento se requiere, ya sea antes o
despus de iniciado el proyecto? Es necesario saber FORTRAN, JAVA o algn otro lenguaje? El establecer las calificaciones
apropiadas y exactas para los puestos har posible que el gerente dote del personal apropiado al proyecto.
Algunos ejemplos cortos de calificaciones tpicas para puestos para nombres y puestos de ingeniera de software. se muestran
como ejemplo:
Gerentes de proyecto -antecedentes en implementacin exitosa de sistemas, conocimientos avanzados industriales,

conocimiento de tecnologa actualizada de cmputo, comprensin profunda de las operaciones y problemas del
usuario, y probada capacidad gerencial. Los requerimientos mnimos son cuatro aos de desarrollo de sistema
importante, y experiencia en manejo de proyecto.
Ingenieros de software -cuatro aos de experiencia en aplicaciones aeroespaciales, diseando sistemas de control de
tiempo real para computadores instalados. Preferentemente con experiencia en Ada. Bachiller en Ciencias, en
Ciencias de Cmputo, Ingeniera o disciplina relacionada.
Programadores cientficos de ingeniera, analista / programador -tres aos de experiencia en aplicaciones de
programacin aeroespacial, sistemas de control y/o grficos. Un ao como mnimo con FORTRAN, Assembler o
lenguajes de programacin C. Deseable experiencia con hardware a gran escala o mini-micro hardware, y de
programacin de software de sistema. Los requerimientos mnimos incluyen un grado universitario de ingeniera o
matemticas.
10

Documente las estructuras organizativas
La estructura organizativa de matriz, con sus lneas de tareas de autoridad y responsabilidad, debern estar documentadas en un
plan organizativo. Las justificaciones para las decisiones debern estar bien documentadas y estar disponibles para dotar de
personal al sistema en el futuro. Otros documentos incluyen descripciones de puestos, calificaciones de puestos y documentos
designando responsabilidades y la autoridad apropiada.
5.
Dotando de personal al proyecto de ingeniera de software
Dotar de personal a un proyecto de ingeniera de sistemas consiste en todas las actividades de administracin que involucra el
llenar y mantener ocupados los puestos que fueron establecidos para la estructura organizativa del proyecto. Esto incluye
seleccionar candidatos para los puestos y entrenamiento y otros, que desarrollen tanto a los candidatos como a los involucrados
a lograr sus tareas con eficiencia. El dotar de personal tambin involucra finalizar al personal asignado al proyecto, cuando sea
necesario.
El dotar de personal, no es organizativo. El asignar personal involucra a gente. Para dotar de personal es ocupar los roles
creados por la estructura organizativa del proyecto a travs de una seleccin efectiva, evaluacin y desarrollo de personal. El
objetivo de dotar de personal es asegurarse que los roles del proyecto sean ocupados por personas capaces que quieren
ocuparlos.
Temas ms importantes en relacin a dotar de personal
Los temas principales (o problemas) al dotar personal para un proyecto de ingeniera de software son:
o La productividad de los programadores, analistas e ingenieros de software no es predecible y vara mucho de un
individuo a otro.
o Las universidades no estn produciendo un nmero suficiente de graduados en ciencias de cmputo que puedan
entender el proceso de ingeniera de software.
o Con frecuencia, los gerentes de proyecto son seleccionados para puestos gerenciales sin tener el beneficio de
entrenamiento gerencial.
Uno de los principales puntos en la dotacin de personal es que la productividad de programadores e ingenieros de software no
es predecible y vara mucho entre individuos. En el estudio hecho hace tiempo por Sackman y otros, las diferencias de
productividad entre un programador y otro era tan alta como 26 a 1. En su libro Economa de Ingeniera de Software, Boehm
reporta diferencias en productividad en la capacidad del personal / equipo tan alta como 4 a 1. Esta imposibilidad de
compatibilizar de una manera exacta la productividad del personal a la productividad esperada de la estructura organizativa,
contribuye mucho a nuestra inhabilidad de determinar con exactitud el costo de un sistema de software.
Las universidades no estn produciendo un nmero suficiente de ingenieros de software. La mayora de los 2500 programas de
ciencias de cmputo en los Estados Unidos grada cientficos en computaci6n te6rica como mximo o solamente programadores
(codificadores) altamente calificados como mnimo. La mayora de personal industrial y gente involucrada en contratar a los
nuevos graduados universitarios indican que les gustara que los graduados de ciencias de cmputo tuviesen ms educaci6n y
experiencia en desarrollar sistemas grandes de software -es decir, habilidades de ingeniera de software.
Los gerentes de proyecto con frecuencia son designados a sus puestos sin tener el beneficio de entrenamiento gerencial. Es
comn hoy elevar a la posicin de gerente a aquellos programadores e ingenieros de software que han demostrado tener
capacidad como programadores e ingenieros de software. El principal problema hoy en da es proporcionar un grado aceptable
de entrenamiento a aquellos ingenieros de software evaluados, de tal manera que sean capaces de manejar un proyecto de
ingeniera de software.
Dotar de personal para actividades y tareas
La Tabla 5.1 proporciona una gua para todas las actividades y tareas de SEPN que deben ejecutarse por los PMs para dotar de
personal a sus proyectos. El balance de esta secci6n discute y proporciona mayor detalles de las actividades y tareas delineadas
en la Tabla 5.1
5.3.1. Llenar los puestos organizativos
El gerente es responsable de establecer los estndares de puestos, para los puestos que fueron establecidos durante la
organizacin de su proyecto. Debe poder asegurar que a travs de esos estndares podr obtener gerentes capaces y
productivos, ingenieros de software, analistas y programadores capaces y productivos y tambin las otras personas de apoyo
necesarias para dotar completamente de personal a un proyecto. El PM es directamente responsable de seleccionar y reclutar
gente calificada para su proyecto, y deber asegurarse de las calificaciones y experiencia de la gente seleccionada para sus
puestos.
Al dotar de personal a cualquier proyecto de software, se tendrn en consideracin los siguientes factores, al llenar la estructura
organizativa.
11

Una deficiencia en cualquiera de estos factores puede ser suplementada con refuerzos en otros factores. Por ejemplo,
deficiencias en la educacin pueden ser sobrepasada por una mejor experiencia, o un tipo de entrenamiento en particular, o por
entusiasmo en el trabajo. Las deficiencias serias deben ser causa de rechazo.
o Educacin. Tiene el candidato un nivel mnimo de educacin para el puesto? Tiene el candidato la educacin
apropiada para que mejore en el futuro, dentro de la compaa?
o Experiencia. Tiene el candidato un nivel aceptable de experiencia? Es del tipo correcto y de la variedad correcta de
experiencia?
o Entrenamiento. Tiene el candidato entrenamiento en el lenguaje y metodologa que se va a usar, en el equipo que se
va a usar, y en la aplicacin del sistema de software?
o Motivacin. Est el candidato motivado para hacer el trabajo, para trabajar en el proyecto, para trabajar en la
compaa, o para tomar el puesto?
o Compromiso. Demuestra el candidato lealtad para el proyecto, para la compaa, y para las decisiones hechas?
o Auto determinacin. Es el candidato alguien que comenz por l slo, que desea llevar a cabo el proyecto hasta el
final sin direccin excesiva?
o Afinidad de grupo. Encaja el candidato con el personal actual? Hay algn tipo de conflicto potencial que necesita ser
resuelto?
o Inteligencia. Tiene el candidato la capacidad de aprender, de tomar la responsabilidad de tareas difciles, y de
adaptarse a cambios de ambientes?
Fuentes de personal calificadas.- Se pueden encontrar a las personas calificadas para llenar los puestos de la organizacin a
travs de un nmero de fuentes. Una fuente es transfiriendo a los individuos desde dentro del proyecto en s. Es la prerrogativa
del PM el mover a la gente de una tarea a otra, dentro de un proyecto. Se reciben a otros ingenieros de software transferidos de
otros proyectos dentro de la misma compaa. Esto se puede hacer en cualquier momento pero generalmente sucede cuando
otro proyecto de ingeniera de software est ya sea entrando a otra fase o se est cancelando.
Otras fuentes de gente experimentada y calificada son nuevos contratos de gente de otras compaas, por mtodos como ferias
de trabajos, referencias, caza de talentos, publicidad de solicitud de empleos, o por currculo vitae no solicitado. Los nuevos
contratos de universitarios recin graduados se puede hacer ya sea a travs de entrevistas en el campus universitario, o a travs
de referencias de los graduados del ao anterior que estn ahora en la compaa.
Si el PM no puede obtener personal calificado para los puestos, puede contratar gente no calificada pero motivada, con potencial,
y entrenarlos para esas vacantes.
Seleccionando un personal de software productivo.- No es suficiente solamente seleccionar al personal; un gerente de proyecto
debe seleccionar el mejor personal y el ms productivo que sea posible.
Hay dos medidas que son indicativas de una alta productividad:
(1) Cantidad de experiencia: Un personal con experiencia es ms productivo que un personal inexperto. Algunas de las
mejores experiencias vienen de haber trabajado en sistemas grandes de software, similares al del proyecto se est
equipando.
(2) Diversidad de experiencia: Una diversidad de experiencia es un parmetro de productividad. Es mejor que los
individuos que se estn considerando hayan trabajado bien en diferentes puestos por un perodo de tiempo, en vez
que lo hayan hecho en solamente un puesto.
Otras cualidades que se necesitan para una alta productividad de un individuo son habilidades de comunicacin (tanto orales
como escritas), un grado acadmico (usualmente en un campo tcnico), que se hayan desenvueltos solos, y que tengan
experiencia en la aplicacin del proyecto.
Si no se encuentra personal experimentado, seleccione a una persona con un grado acadmico.
La experiencia y la observacin nos ensean que, en general, personas con grados acadmicos son ms verstiles y se adaptan
mas rpidamente a los nuevos puestos que las personas que no tienen experiencia universitaria. Otro indicador de personal de
alta productividad es la gente que ha pasado, por su propio esfuerzo, a travs de la universidad, haciendo trabajos y teniendo
puestos a medio tiempo.
5.3.2 Asimile al personal recin asignado
El gerente es responsable no solamente de contratar a la gente, sino tambin de familiarizarla con cualquier procedimiento,
facilidades y planes del proyecto, necesarios para asegurar su integracin efectiva en este proyecto. En breve, l es responsable
de introducir al nuevo empleado en la compaa, y de presentar la compaa al nuevo empleado. Muchas de las grandes
compaas tienen un programa de orientacin formal que demora varios das. Las orientaciones son frecuentemente al comienzo
de sus empleos. Una orientacin en ese momento hace bien al empleado y viene bien, cuando el empleado tiene tiempo libre.
Los programas de orientacin incluyen la caracterstica e historia de la compaa; los productos o servicios que son las
principales fuentes de rditos para la campaa, las polticas y procedimientos generales; organizacin, beneficios de la
compaa; la posibilidad de organizaciones de servicios dentro de la compaa.
12

5.3.3 Eduque o entrene al personal
No es siempre posible reclutar o transferir empleados que tengan exactamente las capacidades que son necesarias para un
determinado proyecto Por eso, el gerente es responsable para educar y entrenar al personal asignado, para asegurar se cumplan
con los requerimientos del proyecto.
La educacin difiere del entrenamiento. La educacin comprende ensear lo bsico, la teora y los conceptos subyacentes de
una disciplina con miras a largo plazo. El entrenamiento, por otra parte, significa ensear una habilidad, un conocimiento de
cmo usar , operar o hacer algo. Por lo general es algo que se necesita en el futuro inmediato y se logran resultados en corto
tiempo.
Los gerentes deben tener educacin en ciencias administrativas y en tcnicas empresariales. Deben tener entrenamiento en
tcnicas gerenciales y en las tareas de administracin. Los ingenieros, por otro lado tienen educacin formal en ciencias fsica y
matemticas pero necesitan entrenamiento en la aplicacin del proyecto en lo ms avanzado de las tcnicas y en los
procedimientos de ingeniera de software usados en el proyecto. El personal de apoyo tiene que entender con exactitud que es lo
que se supone que hagan. Todos deben estar familiarizados con los procedimientos herramientas tcnicas y equipo que operan y
usan.
Algunos de los mtodos de entrenamiento principales que se usan hoy son el entrenamiento a travs del propio trabajo, cursos
formales en la compaa, cursos a travs de universidades y escuelas locales, auto estudio y clases en casa, formales o
informales. Cada individuo dentro de una organizacin debe tener un plan de entrenamiento que muestre metas y los pasos que
debe tomar esa persona para lograr esas metas. La gerencia general debe apoyar activamente a un programa de capacitacin.
Una nueva tcnica en la capacitacin dentro de una compaa recientemente aparecida es reentrenar en la ingeniera de
sistemas (a veces llamada volver sobre los pasos ) a los empleados antiguos valiosos- con habilidades tcnicas pero algo
desactualizadas. Dos ejemplos de esta tcnica son los cursos en las compaas Israel Aircraft y Lockheed Missiles & Space
Company.
5.3.4 Provide for General Development
Uno de los propsitos de proporcionar un desarrollo general a los empleados es mejorar la efectividad de la compaa o de la
organizacin. Por ejemplo, un programa educacional en la universidad local en cualquier habilidad que valga la pena fundada por
la compaa mejorar la moral de los empleados, ayudar en retener a los empleados, y, en general ampliar la base de
capacidades disponibles en la compaa. Se deben incrementar an habilidades indirectas como mecanografa y comunicacin.
5.3.5 Evale y valorice al personal
Junto con los aspectos positivos de contratar a gente, el gerente tambin es responsable de evaluar y valorizar al personal. El
PM debe proporcionar valorizaciones peridicas de su personal de ingeniera de software. Una valorizacin proporcionar
retroalimentacin a los miembros del personal tanto en los aspectos positivos como negativos de su rendimiento. Este efecto de
retroalimentacin permite que los miembros del personal acenten sus mejores cualidades y minimicen sus aspectos negativos.
Una buena evaluacin debe ser hecha a intervalos regulares y debe concentrarse en el rendimiento del individuo y no en su
personalidad, a no ser que su personalidad interfiera en su rendimiento.
Una tcnica de evaluacin que es aplicable a la administracin del proyecto es manejar por objetivos. En el inicio del perodo
de evaluacin, el individuo y su PM establecen y concuerdan en un conjunto de objetivos verificables que el individuo piensa que
puede cumplir en el prximo perodo de informe. Estos objetivos mensurables son una meta verificable que ser la base de la
evaluacin del ao siguiente. Este enfoque es superior a una evaluacin o los rasgos personales y por las caractersticas de
trabajo, tales como rapidez, trabajo limpio, puntualidad, puntaje en golf. etc.
5.3.6 Compense
El gerente -a veces directa y otras indirectamente -es responsable de determinar la escala de salarios y beneficios de su
personal. Los beneficios toman varias formas. La mayora de los beneficios son monetarios o pueden ser equivalentes al dinero
como por ejemplo opiniones a acciones, un carro de la compaa, tickets de primera clase para viajes de toda la compaa, una
bonificacin a fin de ao. Algunos no son monetarios pero agradan a los empleados, porque aumentan su auto estima; ejemplos
son las medallas de combate de los militares, un sitio de parqueo en la planta de la compaa, o un ttulo impresionante en la
puerta.
Algunos ejemplos cortos de los salarios tpicos para los nombres y descripciones de puestos tpicos en ingeniera de software, se
muestran a continuacin.
o Gerentes de proyectos
Proyectos pequeos: $ 33.000- 52.000; promedio 37 .800
Proyectos mediano: $ 40.000- 65,000; promedio 46.700
Proyectos grandes : 45.000 .65.000; promedio 55,000
o Ingenieros de software
Con 1.2 aos de experiencia: 22,000030.100; promedio 27.000
Con 2.5 aos de experiencia: 27.500 -37.000; promedio 32.000
Con 5- 7 aos de experiencia: 31.500 -44,000; promedio 38.000
Con ms de 7 aos de experiencia: 35,000 .51,900; promedio 43.000
13

o
Programadores cientficos de ingeniera, programadores-analistas

Con 1- 2 aos de experiencia: 19.000 028.500; promedio 25.000
Con 2- 5 aos de experiencia: 25.500 -35.000; promedio 30.000
Con ms de 5 aos de experiencia: 31,000 -46.000; promedio 38.000
5.3.7 Termine las asignaciones

El gerente no solamente es responsable para contratar a gente sino que tambin es responsable para terminar las asignaciones.
El trmino terminar comprende reasignar al personal al final de un proyecto exitoso. Se puede dar una fiesta de despedida, y la
gente se va sonriente a sus nuevos puestos. Otras formas de terminar no son tan gratas, como por ejemplo que se cancele el
proyecto antes de tiempo y a la gente tenga que buscar otros trabajos. Tambin se puede terminar un trabajo despidiendo,
cuando se determina que un empleado es insatisfactorio. El PM entonces tiene que permitir que el empleado busque otro trabajo
dentro de su misma compaa o trabaje.
5.3.8 Documente las decisiones de dotacin de personal
Los PMs debern documentar su plan de dotacin de personal y su evaluacin y avance en las polticas, para que el resto las
lea. Cada individuo dentro de una organizacin debe tener un plan personal de entrenamiento que refleje el curso del trabajo
necesario y el progreso que se haga. Otros documentos que pueden producirse son planes y calendarios de re-orientacin,
programas salariales, y polticas de promocin. El gerente del proyecto y los empleados, individualmente, deben tener una copia
de los objetivos de rendimiento anuales del propio empleado, firmado por el empleado y por el supervisor.
6.
Dirigiendo un Proyecto de Ingeniera de Software
Dirigir un proyecto de ingeniera de software consiste en todas las actividades administrativas que tratan de los aspectos
interpersonales por el cual el personal del proyecto comprende y contribuye al logro de las metas del proyecto. Una vez que los
subordinados han sido entrenados y orientados' el PM tiene la contina responsabilidad de clarificar sus asignaciones, guiarlos
hacia un rendimiento mejor y motivarlos para trabajar con entusiasmo y confianza hacia las metas del proyecto.
La direccin, como la dotacin de personal, involucra a gente. Dirigir es algunas veces considerado como sinnimo de liderar
.Dirigir un proyecto significa proporcionar liderazgo para el proyecto, supervisin cotidiana al personal del proyecto, delegar
autoridad a la entidad organizativa ms baja posible, coordinando las actividades de los miembros del proyecto, facilitando las
comunicaciones entre los miembros del proyecto y aquellos que estn por fuera del proyecto, resolviendo conflictos, manejando
cambios y documentando cualquier decisin importante.
Puntos importantes en la direccin
Los puntos importantes (o problemas) en la direccin de un proyecto de ingeniera de software son:
o Los mtodos actuales de especificar requerimientos, disear sistemas o planificar proyectos a veces presentan una
barrera de comunicacin entre las organizaciones claves.
o El personal del desarrollo de software no est motivado a usar, ni interesado en las tcnicas modernas de ingeniera
de software (brecha de transferencia tecnolgica).
o Los beneficios, premios, o pagos que pueden motivar al personal de desarrollo del software para que sean ms
productivos, todava no han sido identificados.
Una de las mayores metas de la ingeniera de software es mejorar la comunicacin entre las muchas organizaciones qu estn
involucradas en el desarrollo de un sistema de software. La mayora de los documentos de ingeniera de software estn escritos
en Ingls, idioma que es notoriamente impreciso y ambiguo. La investigacin en ingeniera de sistema est tratando de
determinar las maneras de desarrollar ms y usar tcnicas y herramientas que hagan que las especificaciones de requerimientos
de ingeniera de software, los documentos de diseo y otros documentos de ingeniera de software comuniquen qu es lo que
quieren decir. Se han tomado ya pasos para mejorar esta situacin.
La transferencia de tecnologa de define como el intervalo de tiempo entre el desarrollo de un nuevo producto, herramientas o
tcnica, y su uso por los consumidores de ese producto, herramienta artculo Redwine y Riddle estiman que ese tiempo puede
estar en el orden de 15 -20 aos. La causa de esta brecha en la transferencia de tecnologa se puede ver desde dos puntos de
vista:
o Punto de vista de gerente de proyecto :
Los PMs, son renuentes a introducir herramientas y mtodos que no son familiares, que no se han usado
antes, y que pueden aumentar los riesgos a su proyecto.
El uso de mtodos no familiarizados puede hacer ms difcil al PM a estimar el tamao del proyecto, el
costo y el calendario.
14

-
Hay una alta probabilidad de que la primera vez que el equipo del proyecto use una nueva herramienta o
tcnica, se produzcan incrementos en costos y calendarios, en el proyecto.
Desde el punto de vista del quien desarrolla el software:

El que desarrolla el software no ve la necesidad del cambio; los viejos mtodos siempre trabajaron a su
satisfaccin y todava son los mejores.
Los que desarrollan software no quieren conocer nuevas tcnicas.
Muchos de los que desarrollan software creen que las nuevas metodologas impiden la creatividad; que los
estndares no se pueden aplicar verdaderamente.
La gente de afuera del proyecto realmente no entiende los problemas del proyecto.
(En el prrafo 6.3.8 se discute un plan para mejorar la transferencia de tecnologa. Maneje el cambio).
o
La mayora del personal de ingeniera de software estn bien pagados, trabajan en ambientes agradables y estn
razonablemente satisfechos con su posicin en la vida. Por lo tanto, de acuerdo con la jerarqua de Maslow de necesidades no
satisfechas, un ingeniero de software promedio est en un lugar alto en la escalera de necesidades satisfechas. La mayora de
los ingenieros de software estn en el nivel de estima y reconocimiento y ocasionalmente estn alcanzando el nivel de autoactualizacin. As, uno de los puntos que la gerencia enfrenta hoy en da es la cuestin de qu hacer para motivar a los
ingenieros de software a que produzcan ms y mejor software (llamado sicologa de software en algunos crculos), ya que el
dinero slo no parece ser suficiente.
Dirija actividades y tareas
La Tabla 6.1 proporciona los lineamientos de todas las actividades del SEPM y las tareas que deben lograr los PMs al aplicar la
direccin de sus proyectos. El balance de esta seccin discute y da ms detalles de las actividades y tareas delineadas en la
Tabla 6.1.
6.3.1 Proporcione liderazgo
El PM proporciona liderazgo a su equipo de administracin de proyecto. Su trabajo es interpretar los planes y requerimientos
para asegurar que todos en su equipo de proyecto trabajen para una meta comn. Liderazgo es una combinacin de poder del
lder y de su habilidad para guiar a individuos. El poder del PM proviene de su posicin (de liderazgo como PM (o lder del
equipo, programador jefe, etc); esto se llama poder posicional. O, el poder del PM proviene tambin de la propia simpata del
gerente, habilidad como gerente para motivar, o carisma; a esto se llama Poder Personal.
Un buen lder puede alinear las metas personales de sus subordinados con las metas del proyecto. Los problemas se presentan
cuando el PM que tiene el poder posicional entra en conflicto con un subordinado dentro del proyecto que tiene poder personal.
Para una discusin de los diferentes usos del poder por parte de gerentes, lea a Boyatzis.
6.3.2 Supervise al personal
El PM es responsable para vigilar e trabajo de los miembros del proyecto y proporcional supervisin diaria y direccin al personal
que se le ha asignado o al cual se le ha autorizado para ejercer control. Es su responsabilidad proporcionar una gua y, cuando
sea necesario. Disciplinar a estas personas para que cumplan con sus tareas asignadas.
Su responsabilidad de supervisin involucra tareas cotidianas como: tomar el horario de reloj a los empleados al comenzar el da,
aprobar tiempo de vacaciones, llamar la atencin a una persona por no cumplir con una cita, o probar un desvo de la poltica de
la compaa. Otras veces, el PM puede proporcionar una decisin crucial en un enfoque de diseo de software; hacer un a buena
presentacin de un punto a la gerencia superior que resulte en ms y en mejores herramientas y equipos; o es una persona que
necesariamente escucha los problemas personales de los miembros del proyecto.
6.3.3 Delegue autoridad
El PM de ingeniera de software es tambin responsable de delegar autoridad al personal del proyecto. Asigna funciones a los
sub-grupos, equipos e individuos, de manera que puedan lograr esas tareas correcta y aplicadamente. Tpicamente, un buen PM
siempre delegar autoridad hacia abajo, a los niveles ms bajos del proyecto.
La delegacin apropiada del tipo correcto de autoridad puede dejar tiempo libre a los gerentes por no tener que hacer
supervisiones de rutina y decisiones, y les deja concentrarse en las necesidades importantes de su proyecto El miembro
individual del proyecto deber entender qu autoridad se le est delegando, y para qu responsabilidad. Tambin deber
entender claramente el mbito, las limitaciones de la autoridad y las razones de la autoridad.
6.3.4 Motive al personal
El liderazgo comn, solamente, no es suficiente. El PM es responsable de motivar e inspirar al personal a hacer lo mejor que
puede. Se pueden aplicar muchas tcnicas motivacionales de la administracin en general, para los proyectos de ingeniera de
software. Tales como: administracin por objetivo, jerarqua de necesidades de
Maslow, factores de higiene de Herzberg, y algunas veces el carisma del gerente. El PM siempre debe dar la atencin especial
requerida a los ingenieros altamente calificados, tcnicamente entrenados y cientficos que forman parte de su proyecto. El
dinero atrae a buenos ingenieros de software a una compaa, pero los dlares no los mantienen. Ms discusin de motivacin
15

del personal de desarrollo de software en Fitz-enz. Otro artculo con un mtodo nico para motivar a la gente se encuentra en
Powell y Posner .
Los modelos de motivacin y las tcnicas de la Tabla 6.2 han sido desarrollados en los ltimos 50 aos, y debern ser revisados
por el PM para la preparacin de un proyecto de ingeniera de software. Los siguientes prrafos describen varias de estas
tcnicas de motivacin a mayor detalle:
o Necesidades de supervivencia biolgica -necesidades bsicas para sostener la vida humana -alimentos, agua, abrigo,
etc.
o Necesidades de seguridad -que la gente est libre de daos.
o Necesidades sociales -necesidad de pertenecer; de ser aceptado por otros.
o Necesidades de estima y reconocimiento-para maximizar el potencial de uno, y para lograr algo.
Factores de trabajo para el personal de cmputo.
La siguiente es una lista de factores, en orden de importancia, que motivan a personas que estn en busca de un trabajo hacia
tomar un empleo (deseable) y que hace ese empleo insatisfactorio para la persona (insatisfactorio):
Empleo Deseable
Salario
Posibilidad de mejora
Ambiente de trabajo
Ubicacin
Beneficios
Facilidades / equipamiento
Satisfaccin de trabajo
Administracin de la compaa
Responsabilidades de trabajo
Insatisfaccin con el trabajo
Mal manejo de la compaa
Pobre ambiente de trabajo
Sienten que no estn logrando resultados
Falta de reconocimiento
Salario inadecuado
No hay posibilidad de mejoras
No hay beneficios
Una pobre definicin de carrera en la compaa
Caso de estudio: La gente no se va por las mismas razones que llegaron
Un gerente llam a un empleado muy valioso, un ingeniero experto de software de vuelo, y se explic que estaba contratando a
una persona para que trabajara con l en su proyecto. La nueva persona contratada era un ingeniero bueno pero joven, con
menos experiencia que el ingeniero mayor. El gerente le dijo que el nuevo empleado iba a ganar ms que el ingeniero de mayor
edad. El gerente le explic que no tena otra opcin; necesitaba el nuevo contrato, el proyecto estaba atrasado, y esta era la
nica manera que poda hacer que el nuevo contratado viniera a trabajar en la compaa y en el proyecto. El gerente tuvo mucho
cuidado en explicar esto al empleado antiguo y esperaba que entendiera. El empleado antiguo reneg un poco pero pareci
haberlo aceptado y regres a trabajar: el gerente estaba tranquilo. Saba que aunque necesitaba un buen salario para atraer a un
nuevo empleado la gente de software realmente no dejaba el trabajo por problemas de dinero, sino por mala gerencia. Al explicar
al primer empleado del problema, pudo convencerlo que las decisiones gerenciales se hacan en beneficio de la compaa.
Teoras X e Y de McGregor.
McGregor present dos presunciones sobre la naturaleza del hombre, llamadas Teora X y Teora Y. Al contrario de lo que se
piensa popularmente, McGregor no favoreca una teora sobre la otra. No deca que la Teora y era mejor que la teora X sino que
eran simplemente dos teoras. El PM debe usar la mejor aproximacin para su proyecto
Presunciones de la Teora X
Un humano promedio tiene aversin al trabajo y tratar de evitarlo.
Debido a esta caracterstica humana de aversin al trabajo, la mayora de los humanos tienen que ser
empujados a l, controlados, dirigidos, y castigados para que hagan un esfuerzo adecuado hacia el cumplimiento
de los objetivos de la organizacin.
El humano promedio prefiere ser dirigido, quiere evitar responsabilidad, tienen relativamente poca ambicin, y lo
que ms quiere es seguridad.
16

Presunciones de la Teora y
El gasto del esfuerzo fsico y mental en el trabajo es tan natural como jugar o descansar.
El control externo y la amenaza de castigo no son las nicas maneras de hacer que una persona haga un
esfuerzo hacia los objetivos de la organizacin. Las personas ejercitarn auto direccin y auto-control en el
servicio de objetivos, cuando se sienten comprometidas.
El compromiso hacia los objetivos es una funcin de la recompensa asociada con su cumplimiento.
El humano promedio aprende, bajo condiciones adecuadas, no solamente a aceptar sino que busca el tener
responsabilidad.
Teora Z
La Teora Z es una combinacin de los estilos gerenciales americanos y japoneses. Los principios bsicos de la Teora Z son:
La gente necesita metas y objetivos. Si no pueden fcilmente poner obstculos en su propio progreso y en el
progreso de la compaa. Las metas ayudan a que uno siga en el camino correcto, mientras que se pierde un
mnimo de tiempo por falta de productividad.
La motivacin de trabajador es esencial para un buen rendimiento y deber ser reforzada tanto positiva como
negativamente. Motivacin opcional se deriva de un reconocimiento por parte de los colegas y por parte de los
colegas y por parte de la gerencia, y en menor grado, por incentivos de promocin y recompensa.
Solamente con metas y motivacin no se evitar que la gente cometa errores. Los gerentes deben corregir
conduciendo hacia los caminos que sean los mejores para los intereses de la compaa.
Los mejores intereses de cualquier compaa se obtienen cuando el trabajo de cada individuo es estandarizado
para asegurar que se logren metas similares por medios similares. A su vez, sugerencia que mejora una rea en
particular es asimilada automticamente en otras reas.
Las metas deben cambiar a medida que las condiciones de trabajo y necesidades de la corporacin cambian.
Anticipando a esos cambios, la teora Z da el mecanismo para un cambio gradual.
6.3.5 Coordine actividades
El PM es responsable de coordinar las actividades del proyecto para asegurar que la gente entienda y se comunique unos con
otros. El gerente quiere asegurar que el otro personal en contacto con su proyecto est al tanto de la estructura organizativa, las
tareas de su organizacin est haciendo y qu se espera de las otras organizaciones.
Por coordinar entendemos arreglar que las entidades del proyecto trabajen juntas hacia metas comunes con un mnimo de
friccin. Los documentos polticas, procedimientos etc., pueden ser vistos distinto por las diferentes personas. La tarea del PM es
reconciliar diferencias en enfoques, esfuerzos y horarios, y compatibilizar estas diferencias para beneficio del proyecto.
La coordinacin se usa a veces como sustituto de comunicacin ya que quiere decir la necesidad de informar a las
organizaciones que interviene qu acciones se han tomado, o se van a tomar, que efecten las organizaciones que estn en
contacto.
6.3.6 Facilite las comunicaciones
Junto con la coordinacin el PM es responsable de facilitar las comunicaciones tanto dentro de su proyecto, como entre su
proyecto y otras organizaciones. Comunicacin quiere decir los medios de intercambiar la informacin entre las entidades que
estn trabajando hacia una meta comn. A su vez, facilitar quiere decir hacer ms expedito, fcil, y ayudar al progreso de
comunicacin. Por ejemplo, el PM debe difundir los planes para dotar de personal y las polticas de promocin tan pronto como
sea prctico. Nada puede destrozar la moral de una organizacin ms rpidamente que rumores falsos que lleven a
equivocaciones. Un buen PM ver que el personal de su proyecto est bien informado para que los rumores se desvanezcan
rpido.
Crculos de calidad.- An cuando se considera una tcnica importante de motivacin, los crculos de calidad, constituyen un
excelente medio para mejorar las comunicaciones entre los miembros del proyecto y el PM. Una compaa us crculos de
calidad para hacer que los miembros del equipo de ingeniera de software para que seleccionen las mejores metodologas de
ingeniera de sistema para la compaa.
Aunque esta prctica de usar crculos de calidad se origin en la filosofa gerencial Norteamericana, se ha implementado bien
solamente en el Japn. En los crculos de calidad, los empleados se renen peridicamente en pequeos grupos para desarrollar
sugerencias para mejoras en la calidad y en la productividad. Los crculos de calidad proporcionan tierra frtil para crear un
ambiente favorable para la gerencia. Para implementar un crculo de calidad:
o
o
Entrene a los gerentes ya otros lderes del proyecto sobre la efectividad de los crculos de calidad. El entrenamiento
debe incluir aquellas tcnicas organizativas como agendas, hojas de trabajo, listas de chequeo, y ms importante,
participacin de grupo.
Encuntrense como parte de la agenda de trabajo de la compaa, durante el tiempo de la compaa y en las
instalaciones de la compaa. Esto refuerza el compromiso de las compaas para cada crculo y la necesidad de que
17

o
sea exitoso. La membresa del crculo de calidad debe ser voluntaria, si es que se quiere ver como una oportunidad
ms que como un requisito.
Organice la reunin de tal manera que no haga perder el tiempo de los miembros. Se debe tomar accin sobre las
sugerencias y aquellas ideas que parecen ser ms beneficiosas para mejorar la compaa deberan seguir
trabajndose.
Para una mayor discusin sobre crculos de calidad, aplicados a organizaciones de desarrollo de software, vea a Couger.
6.3.7 Resuelva conflictos
Es la responsabilidad del PM resolver conflictos entre los miembros del staff, y entre su personal y agencias externas, tanto en
asuntos tcnicos como de manejo. No se espera necesariamente que el PM sea un experto en todos los aspectos de su
proyecto. Sin embargo debe tener el buen juicio para reconocer el mejor enfoque para resolver un problema especial tcnico o
gerencial.
El PM debe reducir la oportunidad para conflictos futuros retirando fuentes potenciales de desacuerdo, siempre que sea posible,
por ejemplo, miembros del equipo que tengan posiciones ms o menos iguales, debern tener los mismos beneficios, acceso a
gerencia. sitios de parqueo, etc.
Otro tipo de conflicto que el PM debe evitar es el conflicto entre el empleado y l mismo. Cuando este conflicto alcanza
proporciones tpicas, se llama quema.
6.3.8 Maneje el cambio
El PM es responsable de alentar ideas independientes e innovaciones para lograr las metas del proyecto. Un buen gerente
siempre podr acomodarse a un cambio, cuando dicho cambio es costo-efectivo y beneficioso para el proyecto.
Es importante que el PM intente controlar el cambio y no eliminarlo. Est claro que los requerimientos cambiarn, el diseo
cambiar, y que la tecnologa para la cual se est construyendo el sistema de software cambiar. Tambin habr cambios
sociales. Lo que es aceptable construir, o los procedimientos para construirlo, que son aceptables en un momento, no sern
necesariamente aceptables en otro momento. La gente cambia, los nuevos grupos de ingenieros son ms despiertos, se les han
enseado nuevas maneras para desarrollar sistemas de software. La idea no es pues eliminar el cambio, sino controlarlo.
Yourdon presenta un plan simple, paso a paso, para la transferencia (cambio) de nueva tecnologa de software, dentro de una
organizacin de software:
o Explique los riesgos y beneficios de la nueva tecnologa.
o Proporcione entrenamiento para el equipo del proyecto.
o Haga un prototipo de la tcnica antes de usarla.
o Proporcione apoyo tcnico a travs de todo el proyecto.
o Escuche a las preocupaciones y problemas de usuario.
o Evite concentrarse en la tecnologa a expensas del proyecto.
Como otro ejemplo de controlar (es decir sacar la mejor ventaja) el cambio, en la mayora de organizaciones de software,
generalmente se considera un problema el recambio del personal. El trabajo de Bartol y Martin discute cmo tomar lo mejor del
recambio del personal y verlo como una buena cosa, y no al contrario.
6.3.9 Documente las decisiones de direccin
Documente todas las tareas, asignaciones de autoridad (a quin y para qu), y el resultado de la solucin de los conflictos.
Adems, documente todas las decisiones que implican lneas de comunicacin, coordinacin y solucin de conflictos.
7.
Controlando un Proyecto de Ingeniera de Software
Controlar un proyecto de ingeniera de software son todas las actividades de aseguren que las operaciones actuales van de
acuerdo a lo previsto. Mide el cumplimiento de las metas, planes; muestra cuando hay un desvo, y al imponer acciones para
corregir las desviaciones, ayuda al cumplimiento de los planes.
El proceso bsico de control involucra el establecimiento de planes y estndares, la medida del rendimiento versus estos planes
y estndares, y la correccin de las desviaciones.
18

El control es un sistema de retroalimentacin que proporciona informacin de un bien est marchando el proyecto. Est el
proyecto segn calendario? Estn dentro del presupuesto? Hay algunos problemas potenciales que pueden causar
impedimentos para cumplir con los requerimientos dentro del presupuesto y horario?
El proceso de control tambin requiere una estructura organizativa. Por ejemplo, quin es responsable para medir el progreso del
proyecto Quin tomar accin sobre los problemas reportados?
Los mtodos de control y las herramientas deber ser objetivos. Los mtodos y herramientas deben sealar las desviaciones de
los planes y estndares, sin considerar la gente o las posiciones que tienen. Los mtodos de control deben ser adaptados a los
ambientes individuales y gerentes individuales. Estos mtodos deben ser flexibles y deben poder copar con el ambiente de
cambio en la organizacin. Tambin, el control debe ser econmico. Debe producir un beneficio, y el costo del control no debe
sobrepasar ese beneficio.
El control debe conducir a medidas de correccin -ya sea regresar el proceso hasta su estndar, cambiar los estndares o, lo
menos deseable, terminar el proceso.
Puntos importantes en el control
Los puntos ms importantes (o problemas) al controlar un proyecto de ingeniera de software son:
o Muchos mtodos de control de un proyecto de software confan en gastos de presupuesto como medidas de
progreso.
o Los estndares de actividades de desarrollo de software o no estn escritos, o si lo estn, no se aplican.
o El grupo de conocimientos, llamado mtrica de software, que puede ser basado para medir la calidad de un producto
de software, no est totalmente desarrollado.
Los asuntos importantes de control comprenden problemas asociados a la confiabilidad de los gastos del presupuesto para medir
el progreso del proyecto. Por ejemplo, cuando a un PM se le pregunta por el status de su proyecto, mirar el presupuesto (o el
calendario) gastado. Si ha gastado tres-cuartas partes de sus fondos (o tiempo) responder sinceramente que est a 3/4 partes
del camino. El problema obvio es la relacin entre el dinero (tiempo calendario) gastado y el trabajo logrado es solamente una
medida burda en la mejor situacin, e incorrecta en el peor de los casos Una posible solucin es el mtodo de valor ganado para
monitorear proyectos de software. Howes hace una descripcin de este mtodo.
Muchos estndares por los cuales medimos progreso, o no estn escritos, o si no estn, no se toman en consideracin. La gente
engaa sobre los estndares, especialmente gente de cmputo. Se dejan de lado los estndares porque se consideran que van
en contra del proyecto de desarrollo de software al restringir la creatividad. Por lo tanto no es inusual que en proyectos enteros,
incluyendo al gerente, ignoren los estndares de la compaa y favorezcan un sistema de desarrollo de software local, ad hoc, y
con frecuencia inadecuada.
Lo que conocemos cmo mtrica de software, todava no ha sido desarrollado completamente. Las mtricas de calidad del
software mide la calidad de del software entregado, es decir, confiabilidad, servicios de mantenimiento, facilidad de uso,
economa y etc. Sin embargo, nuestra investigacin en ingeniera de software no ha progresado ms all de este punto.
Confiabilidad y capacidad de mantenimiento no pueden ser elementos del diseo de software, ni pueden ser medidos con
precisin en el momento de la entrega. Esto ha dado como resultado que el nfasis sea puesto en el proceso de ingeniera de
software creyendo que la calidad del producto viene de la calidad del proceso que se usa para crearlo.
Controlando actividades y tareas
La Tabla 7.1 proporciona un lineamiento de las actividades del SEPM que deben ser cumplidas por los PM al controlar sus
proyectos. El balance de esta seccin muestra en detalle las actividades y tareas que se delinean en la Tabla 7.1.
7.3.1 Desarrolle estndares de procedimiento
El PM es responsable por el desarrollo y la especificacin de estndares de rendimiento para su proyecto. Estos son estndares
de ingeniera de software para el proceso y producto de ingeniera de software. El PM desarrolla sus propios estndares y
procedimiento dentro del proyecto, adopta y usa los estndares desarrollados por su corporacin matriz, o quiz usa aquellos
desarrollados por fuera de su compaa (ver por ejemplo los estndares de Ingeniera de Software de IEEE).
7.3.1.1 Estndares.- Un estndar es un conjunto de criterios aprobados, documentados y disponibles, que se usan para
determinar la idoneidad de una accin o un objeto. Un estndar de ingeniera de software es un conjunto de (i) procedimientos
que definen los procesos para, y (2) las descripciones que definen la cantidad y calidad de un producto de un proyecto de
ingeniera de software.
Ambos, estndares de proceso y producto son en extremo importantes para la tarea de desarrollar software de alta calidad. Vea
a Buckley para una discusin de cmo implementar un estndar de ingeniera de software en una compaa. La ingeniera de
software se preocupa en primer lugar del proceso de desarrollar software, y no tanto con el producto en s. Esto es porque la
mtrica de calidad de software (las medidas de aquellos atributos como confiabilidad, capacidad de ser mantenido, portabilidad, y
19

otras posibilidades), no es una ciencia bien desarrollada, y las herramientas y tcnicas que harn un trabajo eficiente para medir
la calidad de un producto de software, no estn disponibles todava. Por eso, la mayora de los estndares de ingeniera de
software se concentran en el proceso de desarrollo del software, y no del producto.
Adems de proporcionar la medida del proceso de ingeniera de software, los estndares de ingeniera de software ofrecen un
ahorro sustancial de los costos de desarrollo de software. Por ejemplo:
o Ser poca la necesidad de re-entrenar a ingenieros, diseadores y programadores entre proyectos.
o Se pueden mejorar las comunicaciones entre los miembros del equipo.
o Se facilitar la transferencia de personal entre proyectos.
o Se compartir ms las experiencias e historia del proyecto, si el software desarrollado se basa en un mtodo comn.
o Se aplica uniformemente la mejor experiencia de proyectos exitosos.
o Se simplifica la implementacin y mantenimiento del software.
o Se pueden controlar los estndares, y el resultado es un desarrollo controlado.
o Se pueden aplicar estndares de procedimientos de garanta de calidad.
7.3.2.1 Garanta de calidad de software.- La garanta de calidad de software (SQA) es un patrn planificado y sistemtico de
todas las acciones necesarias para proporcionar confianza adecuada de que el tem o producto concuerde con los
requerimientos tcnicos establecidos. SQA incluye mtodos de desarrollo (requerimientos y diseo), estndares, mtodos de
manejo de configuracin, procedimientos de revisin, estndares de documentacin, verificacin y validacin, y especificaciones
y procedimientos de pruebas.
SQA es una de las tcnicas de control ms importantes, disponible a los PMs.
7.3.2 Establezca sistemas de monitoreo e informes
El PM es responsable de establecer los mtodos de monitorear el proyecto de ingeniera de software y reportar el status del
proyecto. Se debe elegir sistemas de monitoreo e informe, o estos sistemas debern ser desarrollados, para que se pueda
determinar el status del proyecto en cualquier momento. El PM necesita retroalimentarse en el progreso de su proyecto, para
asegurar que todo va de acuerdo a lo planeado. Deber establecer el tipo, frecuencia, responsable, y receptor de los informes de
proyectos. Debe establecer herramientas de informe de status para dar visibilidad al progreso, y no solamente reportar recursos
gastados y el tiempo transcurrido.
El PM tambin selecciona los mtodos de software, procedimientos, herramientas y tcnicas para medir la produccin. La Tabla
7.2 hace un listado de sistemas de monitoreo e informes de SEPM tpicos. Algunas de las herramientas que ayudan al control de
un proyecto de ingeniera de software son PERT y CMP, diagramas de carga de trabajo, diagramas de Gannt, etc.
El propsito del informe es proporcionar informacin del status para mantener informada a la gerencia. La Tabla 7.3 hace unos
listados de los tipos de informes que se pueden generar por un sistema de control. Tambin da la oportunidad de observar
condiciones fuera de lmite. Proporciona registros de los cuales el PM puede predecir el futuro. El gerente es responsable de
recolectar los datos del proyecto para desarrollar tcnicas que den mayor precisin de las predicciones futuras.
Uno de los mtodos ms efectivos de monitoreo e informe es el sistema de administracin de lnea bsica.
7.3.2.1 Sistema de manejo de lneas bsicas.- El paradigma de manejo de lneas bsicas es una estrategia de gerencia que se
usa para el control del desarrollo del software. El sistema de manejo de lnea bsica integra una serie de fases de ciclo de vida,
revisiones y documentos de lnea bsica en sistema de administracin de desarrollo de software (Vea la Figura 7.1 para un
ejemplo de un modelo de ciclo de vida de desarrollo de software que se usa con el paradigma de manejo de lneas bsicas).
Especficamente, un manejo de lneas de base:
o Est basado en el modelo de cascada.
o Divide el proyecto en fases manejables: requerimientos, diseo, implementacin y prueba.
o Establece hitos, documentos, revisiones al final de cada fase.
o Establece una lnea de base a intervalos genricos.
o Usa el manejo de configuracin para controlar las lneas de base.
Hitos y diagramas de hitos: Los hitos y diagramas de hitos juegan un rol importante en el Proceso de control. Un hito es un
evento discreto que deber ser tangible y cuya determinacin debe ser conocida con precisin. La calidad que se va a evaluar y
comentar debe ser importante. El problema es que los hitos tengan un final preciso, en trminos de tiempo o fecha. La
terminacin tambin debe ser demostrable; no debe haber duda que el hito ha sido completado.
El propsito de un hito es permitir que el PM divida su proyecto en unidades mensurables, cada una terminando en un punto fijo,
y cada uno de estos puntos debe ser completo y demostrar esa condicin. Ejemplos de puntos fijos o stos son la finalizacin de
la especificacin de requerimientos de software, la finalizacin de una revisin de diseo de software, la finalizacin de cdigo y
por supuesto, el hito mayor, la finalizacin del proyecto.
Revisiones formales (hitos): Las revisiones son procesos de anlisis de procesos del proyecto y productos por parte de clientes,
usuarios y manejo para evaluar el progreso. Una revisin formal (algunas veces llamada una revisin de hitos) es una revisin
20

del manejo y del progreso tcnico del proyecto de desarrollo de software. Por ejemplo una revisin preliminar de diseo (PDR)
que se lleva a cabo en la fase inicial de diseo.
Las revisiones de hitos son generalmente presididas por el cliente. El que desarrolla el producto presenta el status actual y su
progreso, el trabajo hecho hasta ese momento, el dinero gastado, el calendario transcurrido, y cualquier problema de manejo, o
problema tcnico que pueda haber ocurrido desde la ltima revisin La revisin es un xito cuando el cliente o la alta gerencia da
permiso para que el que est haciendo el desarrollo pase a la siguiente fase.
Concepto de lnea de base: Una lnea de base es un acuerdo sobre la configuracin tcnica en un punto del ciclo de vida de
desarrollo del software. Normalmente, se acuerdan las lneas de base entre los que desarrollan el producto y los clientes, y se
controlan y mantienen por sistema de manejo de configuracin de software. Las lneas de base comnmente usadas por DoD
son lneas de base funcional, asignada y de producto.
7.3.2.2 Manejo de configuracin de software: El manejo de configuracin de software (SCM) es un mtodo para controlar y
reportar el status del software. SCM es la disciplina de identificar la configuracin del un sistema en puntos discretos en el
tiempo, para propsitos de controlar sistemticamente los cambios a esta configuracin a travs del ciclo de vida del sistema.
7.3.3 Mida los resultados
El PM es responsable de los resultados del proyecto tanto durante como al final del proyecto. Por ejemplo, l debera medir lo
que se entrega en la fase actual, contra lo que se debera entregar segn el plan. Es responsable de determinar si el proyecto se
desva del plan del proyecto, estndares y otros requerimientos. Los resultados medidos pueden ser resultados manejables
(procesos) o resultados tcnicos (productos). Un ejemplo de un resultado de proceso sera si las especificaciones estn
interpretadas correctamente o no. Algunas de las herramientas y mtodos para medir los resultados se describen en los
siguientes prrafos.
7.3.3.1 Flderes de desarrollo de unidad: El folder de desarrollo de unidad (UDF) es una forma especfica de cuaderno que ha
probado ser eficiente y efectivo para recolectar y organizar los productos de software conforme se vayan produciendo. El
propsito del UDF es proporcionar una aproximacin ordenada para el desarrollo de una unidad de programa y para proporcionar
visibilidad de manejo v control sobre el proceso de
7.3.3.2 Sistemas de recorridos e inspecciones:
Los sistemas de recorridos e inspecciones son revisiones infonl1ales de un producto de software (especificacin de diseo,
cdigo, procedimientos de prueba, etc), conducidos por los colegas del grupo al cual se revisa. Los recorridos son una crtica al
producto de software por parte de los colegas para el nico propsito de encontrar errores. El sistema de inspeccin es otra
revisin por colegas, desarrollada por Michael Fagan de IBM en 1976. El sistema de inspeccin originalmente es mucho ms
fonl1al que el recorrido. Cambios recientes a los procedimientos de recorridos los han hecho ms fonl1ales. Aunque el trmino de
revisin por colegas (pares, gente del mismo nivel) es recorrido, el tnl1ino inspeccin se est popularizando.
7.3.3.3 Auditoria (independiente): La auditora del proyecto de ingeniera de software es una revisin independiente del proyecto
de ingeniera de software para detenl1inar el cumplimiento con los planes de requerimientos, especificaciones, lneas de base,
estndares, polticas y garanta de calidad del software.
Una auditoria independiente es una auditoria hecha por una organizacin de afuera, no asociada con el proyecto.
Ocasionalmente se considera apropiado traer un equipo independiente para el propsito de ayudar en la auditoria del proyecto.
El lado positivo es que un equipo independiente puede proporcionar una opinin sin juicios previos. Esto tendra como resultado
reducir enconos en la organizacin, ya que este equipo no representara un lado ni otro. En el caso de necesidad de un
conocimiento de experto, el equipo independiente puede complementar al talento existente.
El lado negativo de esto es que el equipo de auditoria tiene que hacerlo al ritmo del proyecto. Tienen que sobrepasar la curva de
aprendizaje. El equipo de auditoria requiere que haya actividad en ese momento, para as ser efectivo.
7.3.4.3.4 Verificacin y validacin: Dos mtodos para determinar si el producto es correcto son la verificacin y la validacin.
Verificacin es asegurar que cada fase del ciclo de vida interprete correctamente la especificacin del paso anterior. Validacin es
asegurar que cada producto de software entregado funcione tal como se prescribe por sus requerimientos.
7.3.3.5 Pruebas ( Unidad. /Integracin): La prueba es el ejercicio controlado del cdigo del programa para exponer errores. La
prueba de la unidad (a veces llamada depuracin) es la prueba de una unidad de cdigo (usualmente un mdulo) por el
programador que program la unidad.
La prueba de integracin es la prueba de que cada unidad o sub-elemento en combinacin con el sistema bajo prueba, pueda
mostrar la existencia de errores entre las unidades o sub-elementos del sistema.
7.3.3.6 Auditoria de configuracin del software: Auditorias de configuracin de software proporcionan el mecanismo para
determinar el grado al cual el estado actual del sistema de software, refleja al sistema de software contenido en el documento de
lnea de base y requerimientos.
21

7.3.4 Inicie acciones correctivas
Si no se cumplen los estndares y requerimientos, el PM debe iniciar una accin correctiva. Por ejemplo, el PM puede cambiar el
plan o estndar, puede insistir a travs de sobre tiempo y otros procedimientos en que el equipo regrese al calendario, o como
ltimo recurso, cambiar los requerimientos, es decir entregar menos.
El PM puede cambiar los planes y estndares si es aparente que los planes y estndares originales no van a ser logrados. Esto
podra requerir un mayor presupuesto, ms mano de obra o ms tiempo de control (Cmputo) en el computador de desarrollo.
Podra tambin requerir reducir los estndares (e indirectamente la calidad) al reducir el nmero de recorridos para revisar todos
los mdulos de software, y solamente revisar los mdulos crticos de software.
A veces es posible regresar a parte del trabajo del plan, al incrementando otra parte. Por ejemplo, es posible a veces (pero no es
probable) regresar a horario sin reducir el producto, aumentando sobre tiempo. Esto aumenta el plan de recursos. Tambin es
posible (pero no probable) mantenerse en presupuesto alargando el tiempo.
Un ejemplo de cambio en requerimientos involucra entregar el tener un complemento completo de documentos de software que
no cumpla con los requerimientos funcionales originales, que fueron expuestos en las especificaciones de requerimientos de
software.
7.3.5 Recompense y disciplina
El PM debe recompensar a la gente por cumplir sus estndares y planes, y disciplinar a aquellos que no lo pueden hacer sin
tener razn alguna. Esto no debe confundirse con compensacin (usualmente salario) que se da a los trabajadores por cumplir
con sus tareas asignadas: esa es una funcin de dotacin de personal. Este en un premio incentivo (bonificacin, da libre, una
palmada en el hombro) por cumplir con un plan o un estndar. El siguiente caso es un ejemplo para ilustrar este punto.
Caso de estudio: El plan de bonos del proyecto
Una pequea compaa de capital de riesgo trataba con empeo en competir con las grandes compaas en el desarrollo de
nuevo software para aplicaciones mdicas. Para mejorar las lneas de tiempo en los desarrollos de software, la compaa
implemento un plan de bonificaciones para todos los proyectos de desarrollo de software. A cada proyecto se le asign un da
para entregar el trabajo, un presupuesto y la bonificacin monetaria adelantada. Todos los miembros del proyecto compartan la
bonificacin de dinero si se lograban las metas del proyecto.
7.3.6 Documente los mtodos de control
El PM debe documentar el desarrollo de software y los mtodos de medicin para su proyecto. El PM debe publicar informes
peridicos y las desviaciones entre los resultados programados y los actuales. El PM tambin debe documentar las acciones
tomadas para la correccin de las desviaciones.
8.
RESUMEN
En este artculo y en muchos otros documentos, los trminos manejo de proyecto y manejo de
proyecto de ingeniera de software (SEPM) se usan de manera intercambiable. Ahora podemos
ver porqu. El manejo de un proyecto de ingeniera de software y otros proyectos requiere mucho
de las mismas herramientas tcnicas, enfoques y mtodos que la administracin en general.
Como se ha dicho al comienzo, la funcin y las actividades son las mismas; slo las actividades y
las tareas detalladas son diferentes.
Siguiendo o implementando todas las funciones, tareas e ideas del manejo del proyecto, que se
describen en este artculo, no garantiza el xito del proyecto. Un excelente gerente de proyecto
siempre puede solucionar o darle vuelta a las deficiencias en la organizacin, dotacin de
personal, presupuestos, estndares y otros inconvenientes.
Una mala gerencia cae en el problema real o imaginario, y ninguna regla, poltica, estndar o
tcnica lo ayudarn. Este artculo es para un gerente de proyecto promedio, quien con un poco de
suerte y un poco de conocimiento de qu tiene que hacer y cmo lo tiene que hacer, -entregar su
proyecto de software a tiempo, dentro de los costos ya satisfaccin del cliente.
22

Administracion Proyectos SW

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Administracion Proyectos SW

Cargado por

Copyright:

Formatos disponibles

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

PERT y CPM -mtodos de programacin desarrollados en los aos 1950s.

Necesidades de jerarqua de Maslow (1954) - otro modelo de motivacin; y

Administracin de configuracin -la disciplina de identificar la configuracin de un sistema en puntos determinados en

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Funciones y Actividades de la Administracin

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Planificacin de un proyecto de ingeniera de Software

La planificacin de un programa de accin es frecuentemente incompleta y/o descuidada.

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Organizando un proyecto de ingeniera de software

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Estructura organizativa convencional puede ser un tipo de organizacin de lnea o de personal.

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Gerentes de proyecto -antecedentes en implementacin exitosa de sistemas, conocimientos avanzados industriales,

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Dotando de personal al proyecto de ingeniera de software

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Programadores cientficos de ingeniera, programadores-analistas

5.3.7 Termine las asignaciones

Dirigiendo un Proyecto de Ingeniera de Software

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Desde el punto de vista del quien desarrolla el software:

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Controlando un Proyecto de Ingeniera de Software

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

Administracin de Proyecto de Ingeniera de Software - Un enfoque vertical

También podría gustarte