Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Apunte GPDS
Apunte GPDS
Computación
Facultad de Ingeniería
Universidad de Concepción
Contenidos.
0. Presentación. .............................................................................................................................. 3
1. Gestión. ....................................................................................................................................... 4
2. Los problemas y errores comunes..........................................................................................10
3. Ciclo de Vida del Software. ......................................................................................................22
4. Estimación de Costo y Plazos para la Planificación. .............................................................33
5. Organización del Proyecto.......................................................................................................43
6. Selección de personas para conformar el equipo..................................................................50
7. Una Guía para la Definición del plan.......................................................................................57
8. Control del avance....................................................................................................................69
9. Reglas para la dirección exitosa de proyectos. ......................................................................76
10. Bibliografía.................................................................................................................................81
Gestión de Proyectos de Desarrollo de Software Página 3
Marcela Varas C.
0. Presentación.
1. Gestión.
Gestión son todas las actividades y tareas ejecutadas por una o más personas con el propósito
de planificar y controlar las actividades de otros para alcanzar un objetivo o completar una
actividad que no puede ser realizada por otros actuando independientemente.
Gestión
Nivel
Top
Nivel Medio
Primer
Nivel:
Supervisión
Habilidades
Gestión Top Conceptuales y
de Diseño
Supervisor
Habilidades
Técnicas
Involucra desarrollar una estructura organizacional efectiva y eficiente para asignar y completar
las tareas del proyecto y establecer las relaciones de autoridad y responsabilidad entre las
tareas.
Los principales problemas en la organización de un proyecto de ingeniería de software
incluyen los siguientes:
• Es difícil determinar la mejor estructura organizacional para una organización y/o ambiente
particular (por ejemplo tipo proyecto, funcional o matriz) para gestionar el proyecto.
• Una estructura organizacional puede dejar responsabilidades para algunas actividades y
tareas del proyecto poco claras o indefinidas.
• Mucho personal de desarrollo de software no acepta una organización matricial.
• Muchos líderes de equipo esperan desarrollarse tanto técnicamente como en la gestión de
su equipo de trabajo.
Consiste en todas aquellas actividades que involucran llenar (y mantener llenos) los puestos
que fueron establecidos en la estructura organizacional del proyecto. Esto incluye selección de
candidatos, entrenamiento y otros.
Los principales problemas en esta etapa son:
• Los jefes de proyecto son frecuentemente seleccionados por su habilidad para programar
o realizar tareas de ingeniería en vez de su habilidad de gestión (pocos ingenieros son
buenos gerentes)
• La productividad de los programadores, analistas e ingenieros de software varía mucho de
individuo en individuo.
• Hay grandes cambios en el equipo de un proyecto software, especialmente en aquellos
organizados matricialmente.
• Las universidades no están produciendo un número suficiente de ingenieros que entiendan
el proceso de la ingeniería de software o gestión de proyectos.
• Los planes de entrenamiento para desarrolladores individuales de software no se
desarrollan o mantienen.
proyecto entiende y contribuye a alcanzar los objetivos del proyecto. Una vez que los
subordinados son entrenados y orientados, el jefe de proyecto tiene una responsabilidad
continua por clarificar sus asignaciones, guiándolos hacia la mejora de la productividad, y
motivándolos a trabajar con entusiasmo y confianza hacia las metas del proyecto.
Los principales problemas en la dirección son:
• Fallas para tener una comunicación efectiva entre las entidades del proyecto y aquellas
que no pertenecen al proyecto.
• El dinero no es un motivador suficiente para los desarrolladores de software.
• Las compañías y los jefes no poseen las técnicas y herramientas apropiadas para motivar
a los ingenieros de software.
• Los clientes y gerentes no reconocen el impacto potencial en el software causado por un
aparentemente cambio trivial, por ejemplo, ellos creen que es “sólo un problema simple de
programación”.
3. ¿Existen problemas potenciales que causen retrasos en alcanzar los requerimientos dentro
del presupuesto y plazo?
Los principales problemas en el control son:
• Muchos métodos de control de proyectos de desarrollo de software confían en los gastos
del presupuesto para medir el “progreso” sin considerar el trabajo que lo acompaña.
• La visibilidad del progreso en un proyecto de software es difícil de medir.
• La calidad no es requerida, monitoreada o controlada.
• A menudo los estándares para el desarrollo de software no están escritos o, si lo están, no
se fuerzan.
• El cuerpo de conocimiento llamado métricas de software (usadas para medir productividad,
calidad, y progreso de un producto software) no está completamente desarrollado.
Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las
decisiones que toman, y la apariencia seductora de los errores clásicos es una de las razones
de que esos errores se cometan tan a menudo. Pero debido a que se han cometido muchas
veces, sus consecuencias se han hecho fáciles de predecir. Y los errores rara vez producen
los resultados que la gente espera.
2.1 Personas
A continuación aparecen algunos de los errores clásicos relacionados con las personas.
Gestión de Proyectos de Desarrollo de Software Página 11
Marcela Varas C.
1: Motivación débil. Estudio tras estudio ha mostrado que la motivación probablemente tiene
mayor efecto sobre la productividad y la calidad que ningún otro factor (Boehm 1981). Ejemplo:
directivos que a lo largo de todo el proyecto toman medidas que minan la moral: como dar
ánimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones
mientras el equipo esta trabajando incluso los días de fiesta, para dar recompensas al final del
proyecto que resultan ser de menos de un dólar por cada hora extra.
5: Añadir más personal a un proyecto retrasado. Este es quizás el más clásico de los
errores clásicos. Cuando un proyecto se alarga, añadir más gente puede quitar más
productividad a los miembros del equipo existente de la que añaden los nuevos miembros.
Fred Brooks compara añadir gente a un proyecto retrasado con echar gasolina en un fuego
(Brooks, 1975).
7: Fricciones entre los clientes y los desarrolladores. Las fricciones entre los clientes y los
desarrolladores pueden presentarse de distintas formas. A los clientes pueden parecerles que
los desarrolladores no cooperan cuando rehusan comprometerse con el plan de desarrollo que
desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede
parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en
los requerimientos después de que éstos hayan sido fijados. Pueden ser simplemente
conflictos de personalidad entre dos grupos.
8: Expectativas pocos realistas. Una de las causas más comunes de fricciones entre los
desarrolladores y sus clientes o los directivos son las expectativas poco realistas. Ejemplo, no
tener razones técnicas para pensar que un software se podrá desarrollar en 6 meses, pero ése
es el plazo en que lo quiere el comité ejecutivo de la compañía. La incapacidad del jefe de
proyecto para corregir esta expectativa irreal será la principal fuente de problemas.
9: Falta de un promotor efectivo del proyecto. Para soportar muchos de los aspectos del
desarrollo rápido es necesario un promotor del proyecto de alto nivel, incluyendo una
planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo.
Sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa puede
forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto.
El consultor australiano Rob Thomstt afirma que la falta de un promotor efectivo garantiza
virtualmente el fracaso del proyecto (Thomstt, 1995).
10: Falta de participación de los implicados. Todos los principales participantes del esfuerzo
de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores,
ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios
finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperación estrecha sólo
se produce si se han implicado todos los participantes, permitiendo una coordinación precisa
del esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena participación.
11: Falta de participación del usuario. La inspección de Standish Group descubrió que la
razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la
Gestión de Proyectos de Desarrollo de Software Página 14
Marcela Varas C.
implicación del usuario (Standish Group, 1994). Los proyectos que no implican al usuario
desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto,
y son vulnerables a que se consuma tiempo en prestaciones que más tarde retrasarán el
proyecto.
12: Política antes que desarrollo. Larry Constantine indicó que si hay cuatro tipos diferentes
de orientaciones políticas (Constantine, 1995a). Los "políticos" están especializados en la
"gestión", centrándose en las relaciones con sus directivos. Los "investigadores" se centran en
explorar y reunir la información. Los "aislacionistas" están solos, creando fronteras para el
proyecto que mantienen cerradas a los que no son miembros del equipo. Los "generalistas"
hacen un poco de todo: establecen relaciones con sus directivos, realizan investigaciones y
exploran actividades, y se coordinan con otros equipos como parte de su modo de trabajo.
Constantine indicó que inicialmente los equipos políticos y generalistas están bien vistos por
los directivos de alto nivel. Pero después de un año y medio, los equipos políticos llegan a la
muerte súbita. Primar la política en vez de los resultados es fatal para el desarrollo orientado a
la velocidad.
13: Ilusiones. Muchos problemas del desarrollo del software se deben a la ilusión. Cuántas
veces hemos escuchado cosas como éstas a distintas personas:
"Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de
acuerdo con el plan que tienen, pero piensan que quizás si trabajan duro, y nada va mal, y
tienen un poco de suerte, serán capaces de concluir con éxito".
"Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las
distintas partes del producto, pero tenemos una buena comunicación para otras cosas, y las
interfaces son relativamente simples, así que probablemente sólo necesitaremos un día o dos
para eliminar los errores"
"Sabemos que contamos con un desarrollador externo de poco talento para el subsistema de
la base de datos, y que es difícil ver cómo va a acabar el trabajo con los niveles de personal
que ha especificado en su propuesta. No tienen tanta experiencia como algunos de los demás
desarrolladores externos, pero puede que compensen con energía lo que les falta en
experiencia. Probablemente acaben a tiempo"
Gestión de Proyectos de Desarrollo de Software Página 15
Marcela Varas C.
"No necesitamos reflejar la última lista de cambios en el prototipo para el cliente. Estoy seguro
de que por ahora sabemos lo que quiere."
"El equipo está diciendo que realizará un esfuerzo extraordinario para cumplir con la fecha de
entrega, y que no han llegado a su primer hito por pocos días, pero creo que alcanzarán éste a
tiempo."
Las ilusiones no son sólo optimismo. Realmente consisten en cerrar los ojos y esperar que
todo funcione cuando no se tienen las bases razonables para pensar que será así. Las
ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo
una planificación coherente y pueden ser la raíz de más problemas en el software que todas
las otras causas combinadas.
2.2 Proceso
Los errores relacionados con el proceso malgastan el talento y el esfuerzo del personal. A
continuación se muestran algunos de los peores errores relacionados con el proceso.
14: Planificación excesivamente optimista. Los retos a los que se enfrenta alguien que
desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta
alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente
optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la
planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el análisis
de requerimientos o el diseño. También supone una excesiva presión para los desarrolladores,
quienes a largo plazo se ven afectados en su moral y su productividad.
16: Fallos de los contratistas. Las compañías a veces contratan la realización de partes de
un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los
Gestión de Proyectos de Desarrollo de Software Página 16
Marcela Varas C.
contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla
al no coincidir con las especificaciones (Boehm, 1989). Riesgos como requerimientos
inestables o interfaces mal definidas pueden ser enormes cuando un contratado entre en
escena. Si las relaciones con los contratados no se gestionan cuidadosamente, la utilización
de desarrolladores externos pueden retardar el proyecto en vez de acelerarlo.
18: Abandono de planificación bajo presión. Los equipos de desarrollo hacen planes y
rutinariamente los abandonan cuando se tropiezan con un problema en la planificación
(Humphrey, 1989). El problema no está en el abandono del plan, sino más bien en fallar al no
crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir.
Ejemplo, un equipo abandona su plan después de fallar en la primera entrega, y esto es lo
habitual. A partir de este punto, el trabajo no tiene coordinación ni elegancia.
19: Pérdida de tiempo en el inicio difuso. El "inicio difuso" es el tiempo que transcurre antes
de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y
hacer el presupuesto. No es poco común que un proyecto desperdicie meses o años en un
inicio difuso, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil y barato
y menos arriesgado suprimir unas pocas semanas o meses del inicio difuso en vez de
comprimir el plan de desarrollo en ese mismo tiempo.
20: Escatimar en las actividades iniciales. Los proyectos se aceleran intentando acortar las
actividades "no esenciales", y puesto que el análisis de requerimientos, la arquitectura y el
diseño no producen código directamente, son los candidatos fáciles.
Los resultados de este error, también conocido como "saltar a la codificación", son todos
demasiado predecibles. Los proyectos que normalmente escatiman en sus actividades
iniciales tendrán que hacer ese trabajo en otro momento, con un costo de 10 a 100 veces
superior a haberlo hecho bien inicialmente (Fagan, 1976; Boehm y Papaccio, 1988). Si no
podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez, ¿cómo
vamos a encontrar 50 para hacerlo correctamente más tarde?
Gestión de Proyectos de Desarrollo de Software Página 17
Marcela Varas C.
22: Escatimar en el control de calidad. En los proyectos que se hacen con prisa se suele
cortar por lo sano, eliminando las revisiones del diseño y del código, eliminando la planificación
de las pruebas y realizando sólo pruebas superficiales. Acortar en un día las actividades de
control de calidad al comienzo del proyecto probablemente supondrá de 3 a 10 días de
actividades finales (Jones, 1994).
23: Control insuficiente de la directiva. Poco control de la directiva para detectar a tiempo
los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se
abandonan cuando el proyecto comienza a tener problemas. Antes de encarrilar un proyecto,
en primer lugar debemos ser capaces de decir si va por buen camino.
Otro tipo de error es la reestimación que se debe a cambios en el producto. Si el producto que
estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiará
también. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se
alcanzará la fecha de entrega.
27: Programación a destajo. Algunas organizaciones creen que la codificación rápida, libre,
tal como salga, es el camino hacia el desarrollo rápido. Piensan que si los desarrolladores
están lo suficientemente motivados, pueden solventar cualquier obstáculo. Este enfoque
muchas veces se presenta como un enfoque "empresarial" al desarrollo de software, pero
realmente es sólo la envoltura del viejo paradigma a destajo combinado con una planificación
ambiciosa, y esta combinación raras veces funciona. Es un ejemplo de que dos negaciones no
constituyen una verdad.
2.3 Producto
A continuación se muestran los errores clásicos relacionados con la forma en la que se define
el producto.
28: Exceso de requerimientos. Algunos proyectos tienen más requerimientos de los que
necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo que
es necesario, y puede generar una planificación del software innecesariamente larga. Los
usuarios tienden a interesarse menos en las prestaciones complejas que en las de las
secciones de marketing o de desarrollo, y las prestaciones complejas alargan
desproporcionadamente el plan de desarrollo.
Gestión de Proyectos de Desarrollo de Software Página 19
Marcela Varas C.
29: Cambio de las prestaciones. Incluso si hemos evitado con éxito los requerimientos
excesivos, los proyectos sufren como media sobre un 25 por 100 de cambios en los
requerimientos a lo largo de su vida (Jones, 1994). Un cambio de este calibre puede producir
un aumento en el plan de al menos un 25 por 100, lo que puede ser fatal para los proyectos.
Si el producto tiene objetivos que pretenden aumentar los conocimientos existentes, como
algoritmos, velocidad, utilización de la memoria y demás, debemos asumir que la planificación
es altamente especulativa. Si queremos mejorar el estado del arte y tenemos algún otro punto
débil en el proyecto, recortes de personal, debilidades en el personal, requerimientos vagos,
interfaces inestables con contratados externos, etc., podemos tirar por la ventana la
Gestión de Proyectos de Desarrollo de Software Página 20
Marcela Varas C.
planificación prevista. Si queremos superar el estado del arte por todos los medios, hagámoslo.
¡Pero no debemos esperar hacerlo rápidamente!
2.4 Tecnología
El resto de los errores clásicos están relacionados con el uso correcto o incorrecto de la
tecnología moderna.
34: Sobreestimación de las ventajas del empleo de nuevas herramientas o métodos. Las
organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuántas
nuevas herramientas o métodos empleen o lo bueno que sean. Los beneficios de las nuevas
técnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y
aprender a utilizar nuevas técnicas para aprovecharlas al máximo lleva su tiempo. Las nuevas
técnicas también suponen nuevos riesgos, que sólo descubriremos usándolas. Más bien
experimentaremos mejoras lentas y continuas en un pequeño porcentaje por proyecto en lugar
de grandes saltos.
35: Cambiar de herramientas a mitad del proyecto. Es un viejo recurso que funciona
raramente. A veces puede tener sentido actualizar incrementalmente dentro de la misma línea
de productos, de la versión 3 a la 3.1, o incluso a la 4. Pero cuando estamos a la mitad de un
proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con
una herramienta totalmente nueva, normalmente anulan cualquier posible beneficio.
Gestión de Proyectos de Desarrollo de Software Página 21
Marcela Varas C.
36: Falta de control automático del código fuente. Un fallo en la utilización del control
automático del código fuente expone a los proyectos a riesgos innecesarios. Sin él, si dos
desarrolladores están trabajando en la misma parte del programa, deben coordinar su trabajo
manualmente. Deberían ponerse de acuerdo para poner la última versión de cada archivo en
el directorio maestro y verificarlos con los demás antes de copiarlas en este directorio. Pero
invariablemente alguno sobreescribirá el trabajo del otro. Se desarrolla nuevo código con
interfaces desfasadas, y después se tiene que rediseñar el código al descubrir que se ha
utilizado una versión equivocada de la interfaz. Los usuarios avisan de errores que no
podemos reproducir porque no hay forma de volver a crear los elementos que han utilizado.
Como media, los cambios manual del código fuente no deberían crecer (Jones, 1994).
Gestión de Proyectos de Desarrollo de Software Página 22
Marcela Varas C.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un
proyecto de desarrollo de software.
El primer ciclo de vida del software, “Cascada”, fue definido por Winston Royce a fines del 70.
Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya
desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a
que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software. En su lugar,
muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que
pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma
más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos
rápidos.
Requerimientos
Diseño
Codificación y Test
Unitario
Integración del
Sistema
Operación y
Mantención
Una de las contribuciones más importantes del modelo cascada es para los administradores,
posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.
Requerimientos
Requerimientos
Diseño Diseño
Operación y Operación y
Mantención Mantención
Requerimientos Requerimientos
Modelo Evolutivo.
Prototipado
Requerimientos
Diseño
Codificación y Test
Unitario
Integración del
Sistema
Operación y
Mantención
Requerimientos
Prototipado Prototipado
Costo
Modelo Espiral
Análisis de
Riesgo
Progreso Evaluación
de
Alternativas,
Análisis de
Identificación
Riesgo
y
S l ió d
Determinación de
Objetivos, Análisis de
Alternativas Riesgo
Análisis
Prototipo
Prototipo 1 Prototipo 2 Prototipo 3 Operacional
Revisió
Requerimien Simulaciones, Modelos y
Concepto
tos
de Requerimien
tos Software
Diseño
Diseño
Validación Producto
Desarrollo
Requerimient
Códig
Integración Test
y Test Validación y de
Verificación
Planificación
del Diseño Integració
Próximas Monitoreo
n y Test
Test de Desarrollo,
Implementaci Aceptació Verificación, Producto
supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no
ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien
definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser
posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el
diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en
forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de
todos los componentes.
En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente.
Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al
mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está
haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y
especificación de requisitos sobre un componente 5.
En todos estos casos, diversas actividades están ocurriendo simultáneamente. Eligiendo
seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento
del estado verdadero en el que se encuentra el proyecto.
En muchos casos, los paradigmas pueden y deben combinarse de forma que puedan utilizarse
las ventajas de cada uno en un único proyecto. El paradigma del modelo en espiral lo hace
directamente, combinando la creación de prototipos y algunos elementos del ciclo de vida
clásico, en un enfoque evolutivo para la ingeniería de software.
No hay necesidad por tanto de ser dogmático en la elección de los paradigmas para la
ingeniería de software: la naturaleza de la aplicación debe dictar el método a elegir.
Gestión de Proyectos de Desarrollo de Software Página 33
Marcela Varas C.
Una de las actividades cruciales del proceso de gestión es la planificación, la cual se basa en
una buena estimación del esfuerzo requerido para realizar el proyecto, duración cronológica
del proyecto y el costo (en miles de pesos o dólares).
La técnica más utilizada para realizar estimaciones de costos y plazos es la que denomino
“juicio experto”, donde el administrador del proyecto recurre a alguien que haya desarrollado
aplicaciones similares para que realice una estimación de los recursos y tiempo a necesitar
para el desarrollo.
Otra técnica muy natural es utilizar descomposición. Esto es, dividir el problema en partes más
pequeñas y estimar cada una por separado, utilizando un juicio experto o algún método más
formal (como estimar sobre la base del tamaño en una métrica formal).
Además, se suele realizar una estimación optimista (EO), otra más probable (EMP) y una
pesimista (EP), y asignarle una probabilidad a cada una, obteniendo así nuestra estimación
mediante:
4.2 Métricas
Las métricas del software orientadas al tamaño son medidas directas del software y el proceso
de software.
Si en una organización se realizan registros como en la tabla siguiente, se puede obtener
alguna información interesante.
Supongamos que contamos con la siguiente información:
Proyecto KLOC Esfuerzo Documentación # personas errores Costo
(personas- (# páginas) total
mes) (US$)
Proy1 12,1 26 370 3 29 180
Proy2 27,8 60 1200 5 86 450
Proy3 20 43 1050 6 64 320
Con los datos contenidos en esta tabla, se pueden desarrollar un conjunto de métricas de
productividad y calidad orientadas al tamaño.
Productividad = KLOC/Esfuerzo
Calidad=Errores/KLOC
Coste= Costo/KLOC
Tasa Documentación Documentación/KLOC
Para efectos de la estimación del esfuerzo de desarrollo como base de la planificación, las
métricas orientadas al tamaño han sido utilizadas en varias propuestas. La mayoría de ellas
son lo que se llaman modelos de estimación, que en este caso son funciones de las líneas de
código o de las miles de líneas de código que tendrá el software a desarrollar.
Los principales problemas de utilizar líneas de código como métrica son la falta de una
definición universal de línea de código, su dependencia con el lenguaje de desarrollo y la
dificultad de estimar en fases tempranas del desarrollo la cantidad de líneas que tendrá una
aplicación para efectos de estimación del esfuerzo.
Gestión de Proyectos de Desarrollo de Software Página 36
Marcela Varas C.
Las métricas de software orientadas a la función son medidas indirectas del software y el
proceso por el cual se desarrolla. En lugar de calcular las líneas de código, éstas se centran en
la funcionalidad o utilidad del software.
La primera propuesta de este tipo fue los puntos de función, realizada por Albrecht, métrica
que hasta hoy es muy utilizada. De los puntos de función de Albrecht han salido algunas
variacionestales como los puntos de característica y los puntos de función para estimación
temprana.
En resumen, los puntos de función aparecen con ventajas sustanciales por sobre las líneas de
código, para fines de estimación temprana del tamaño del software. Además es una medida
ampliamente utilizada, y con éxito, en muchas organizaciones que desarrollan software en
forma masiva.
Debido a que el análisis por Puntos de Función fue diseñado para software de negocios y no
es fácil de generalizar a aplicaciones científicas, de tiempo real y otras, Caper Jones propuso
ampliaciones al método que denominó Puntos de Característica, que da cabida a aplicaciones
cuya complejidad algorítmica es alta.
Este método considera los mismos elementos que considera Albrecht en su método de
análisis por puntos de función, sólo que añade la variable número de algoritmos y elimina los
niveles de complejidad.
.Complejidad de proceso.
Característica GI ID Característica GI
C1 Comunicación de Datos ___ C8 Actualización en Línea ___
C2 Funciones Distribuidas ___ C9 Complejidad de procesos ___
C3 Desempeño ___ C10 Reusabilidad del Software ___
C4 Esfuerzo para la Configuración ___ C11 Facilidad de instalación ___
C5 Tasa de Transacciones ___ C12 Facilidad de operación ___
C6 Entrada de Datos en Línea ___ C13 Múltiples lugares ___
C7 Eficiencia del Usuario ___ C14 Facilidad de cambios ___
PC Total Grado de Influencia
. Valores de GI.
0: No está presente o no influencia 3: Influencia promedio
1: Influencia insignificante 4: Influencia significativa
2: Influencia moderada 5: Influencia fuerte, en todo
Una vez que conocemos como obtener la métrica por puntos de función, estamos interesados
en su utilización como apoyo a la etapa de planificación. Para ello deseamos utilizar esta
medida para estimar costos y plazos.
Para obtener medidas consistentes del tamaño del software, la métrica a utilizar debe ser
independiente de la tecnología de desarrollo, esto es, metodologías, hardware, herramientas
de programación.
Nos interesa medir el software para poder compararlo con otros, conocer cuanto produce una
organización o utilizarlo para obtener otras medidas de interés, como productividad, tasa de
errores, estimación del costo, estimación de plazos.
El conocimiento del tamaño de la aplicación es vital para poder hacer un dimensionamiento del
desarrollo, además el tener una medida del tamaño como puntos de función tiene la gran
ventaja de ser comparable, tanto dentro de la misma organización, como con otras.
Observemos que de los requisitos funcionales se obtienen las Cuentas de Función, ya que es
en este capítulo donde aparecen las Entradas, Salidas, Consultas y Archivos Lógicos. Se
recomienda cohesionar los requisitos funcionales según algún criterio consistente, por ejemplo
por conjunto de información. Los Archivos Lógicos Internos se pueden obtener sin
aproximaciones a partir de un modelo conceptual de datos, pero personas con experiencia
podrán visualizar desde los requisitos funcionales conjuntos cohesionados de datos que con
una probabilidad muy alta pasarán a formar parte de un archivo lógico interno.
Gestión de Proyectos de Desarrollo de Software Página 40
Marcela Varas C.
5.1 Introducción.
Esta es la forma de organización más común, y se basa en una estructura jerárquica básica.
El organigrama de este tipo de organización tiene forma piramidal, encontrándose en el parte
superior a los grados mas altos de dirección, con los grados de dirección medio y bajo
distribuyéndose hacia abajo de la pirámide. Esta organización generalmente se descompone
en varias unidades funcionales diferentes, como por ejemplo ingeniería, contabilidad,
administración.
La razón de ser de esta estructura radica en las teorías de administración basadas en la
especialización, las cuales consideran que es más fácil dirigir a especialistas si estos son
agrupados según su especialidad y el jefe de departamento tiene conocimientos de esa
disciplina en particular.
Este tipo de organización posee ventajas que descansan sobre su centralización de recursos
similares, ya que, por ejemplo, brinda caminos de integración claros y bien definidos para
especialistas jóvenes y además, la ayuda mutua es fácilmente encontrada gracias a la
proximidad física.
Sin embargo, este tipo de organización posee debilidades. Por ejemplo, cuando se trabaja en
proyectos múltiples, generalmente surgen problemas por el uso de los recursos. Otro ejemplo
Gestión de Proyectos de Desarrollo de Software Página 44
Marcela Varas C.
a citar es el de que cada departamento funcional pone énfasis en su especialidad mas que en
los objetivos del proyecto.
Pese a esto, la mayoría de las compañías usan este tipo de organización no sólo para sus
proyectos, sino para todas sus actividades.
Jefe
son utilizados de forma ineficiente. Otro problema serio radica en que se produce inestabilidad
laboral luego de terminado el proyecto temporal.
La organización jerárquica está estructurada alrededor de entradas técnicas. La organización
de proyecto estructura un propósito único construido alrededor de las salidas del proyecto.
Estas son estructuras unidimensionales en un mundo multidimensional. El problema de cada
una es conseguir un balance apropiado entre los objetivos a largo plazo de los departamentos
funcionales en formar técnicos expertos y los objetivos a corto plazo del proyecto.
Jefe
El director de proyecto a menudo siente que no posee la autoridad suficiente sobre los
departamentos funcionales. Por otro lado, el jefe del departamento funcional a menudo siente
que el coordinador de proyecto esta interviniendo en su territorio.
Jefe
Ing de Ing de Sw
Proyecto A Ing de Sw Ing de V&V Ing SQA
Sistemas
Ing de Ing de Sw
Proyecto B Ing de Sw Ing de V&V Ing SQA
Sistemas
Ing de Ing de Sw
Proyecto C Ing de Sw Ing de V&V Ing SQA
Sistemas
Ing de Ing de Sw
Proyecto D Ing de Sw Ing de V&V Ing SQA
Sistemas
Es también posible ocupar las tres estructuras en una misma compañía, en diferentes
proyectos. También todas estas estructuras pueden ser utilizadas en un mismo proyecto en
diferentes niveles –por ejemplo, una organización global de matriz con estructura funcional en
ingeniería y una organización de proyecto dentro de otra sub área funcional.
Gestión de Proyectos de Desarrollo de Software Página 48
Marcela Varas C.
No es posible decidir el diseño organizacional sin definir también quien será seleccionado
como el jefe de proyecto y que tipo de diseño se quiere para los sistemas de reporte y
planeamiento. Por ejemplo, una organización de proyecto exitosa requiere un jefe de proyecto
con amplia capacidad para la dirección general. Debe combinar conocimiento técnico en la
materia además de habilidades de dirección antes de poder dirigir a todo el personal del
proyecto. No tiene sentido elegir una forma de organización de proyecto si tal jefe de proyecto
no se encuentra.
Los sistemas de reporte y planeamiento en una organización de proyecto pueden ser bastante
simples ya que el equipo trabaja con una gran proximidad. Lo opuesto es cierto en la dirección
de proyectos a través de una organización funcional. Por esto, un sistema de planeamiento y
reporte mas sofisticado es necesario en una organización funcional que en una organización
de proyecto.
5.8 Resumen.
No existe una estructura organizacional perfecta para manejar los distintos tipos de proyecto.
La organización funcional, la de proyecto y la matricial tienen todas fuerzas y debilidades. La
elección final deberá venir luego de considerar varios factores de la naturaleza de la tarea a
realizar, las necesidades de la organización y el ambiente del proyecto.
La estructura funcional funcionara para muchos proyectos, en muchas organizaciones,
especialmente si las comunicaciones laterales son reforzadas a través de mecanismos de
integración.
Si se escoge una estructura de matriz, toda la organización deberá poner gran empeño para
que esta funcione. En particular, el director de proyecto debe ser cuidadosamente escogido y
entrenado. Sus habilidades interpersonales son más importantes que sus habilidades técnicas.
En muchas situaciones, una organización de proyecto puede parecer la solución más simple
desde la perspectiva del director de proyecto. Sin embargo, los directores funcionales y la alta
administración tal vez no la consideren como la mejor solución a largo plazo o la decisión más
estratégica.
Gestión de Proyectos de Desarrollo de Software Página 50
Marcela Varas C.
6.1 La Entrevista.
La entrevista ayudará a encontrar las personas adecuadas a los cargos definidos en un equipo
de desarrollo. Además de definir la personalidad de los postulantes, ayudará a establecer
cuales son las capacidades del individuo frente al trabajo de equipo, adaptación a la
organización y resto del equipo, capacidad de liderato y soportar presiones al acabarse los
plazos de entrega o frente a problemas en el desarrollo, es decir, capacidad de aceptar cierta
dosis de stress. Definir la personalidad del postulante permitirá definir cual es la orientación en
la cual se puede clasificar. Esto permite poder establecer ubicaciones dentro del grupo y
reconocer cuales personalidades entran en conflicto y como puede lograrse un trabajo
armónico, principal preocupación del jefe de proyecto, ya que un trabajo armónico posibilita
una mayor productividad y calidad del trabajo.
A grandes rasgos los individuos pueden clasificarse en tres tipos:
a) Orientados al trabajo: El individuo esta motivado por el trabajo mismo, inducido por
un desafío intelectual.
b) Auto-orientados: Está motivado por un éxito personal, buscando alcanzar sus
propias metas. Generalmente calzan en la parte administrativa de la organización.
c) Orientados a la interacción: Está motivado por la presencia y acción de sus colegas.
Se tiene que destacar que esta clasificación no es fija, y la personalidad puede variar
en el tiempo de un tipo hacia otro.
La entrevista propiamente tal debe programarse con anterioridad, debiendo ser los
entrevistadores lo mas objetivos posible, tratando de encontrar impresiones del candidato a lo
largo de la entrevista y no formarse primeras impresiones en los primeros minutos de la
entrevista. Estas son, por lo general, incorrectas. A continuación se describe algunos pasos
que debe tener una entrevista. Es decir un modelo de la entrevista destinada a seleccionar al
mejor candidato.
1. Preparando la entrevista:
• Buscar un lugar adecuado y cómodo.
• Evitar el uso del teléfono e interrupciones.
• Mantener en mente el seguimiento de estas acciones.
• Tener, por escrito, unas cuatro o cinco preguntas que ayuden a definir el potencial,
habilidades, temperamento y otros atributos del candidato.
Gestión de Proyectos de Desarrollo de Software Página 52
Marcela Varas C.
• Revisar los requerimientos de candidato y descripción del cargo que debe ser
llenado (alto o bajo requerimiento de calidad).
• Revisar el curriculum del candidato.
2. Estructuración de la entrevista:
• Usar varios entrevistadores en forma separada. Esto aumenta las visiones objetivas
del candidato.
• Realizar anotaciones cortas.
• Acordar preguntar a todos los candidatos el mismo tipo de preguntas.
3. Conduciendo la entrevista:
• Conocer que los primeros minutos de la entrevista son críticos en la formación de
impresiones, tanto de parte del entrevistado como del entrevistador.
• Recibir amistosamente al candidato.
• Establecer una conversación y discusión sobre puntos en común. Esto puede
determinarse a partir del curriculum del candidato.
• Hablar en una forma relajada y afable, tratando de mantener una sonrisa en todo
momento.
• Tratar de llevar una conversación cara a cara, evitando mesas o escritorios entre el
entrevistado y entrevistador.
• Empezar conversando sobre aspectos generales para relajar al candidato. Después
de esto, entrar a temas más específicos.
• Realizar preguntas abiertas que permitan al candidato hablar a lo menos un 50% de
lo conversado. Es decir, no obligar con una pregunta larga a responder solamente
un 'sí' o 'no'.
• Mientras sea posible, dar al candidato felicitaciones por su experiencia y habilidad
basándose en el curriculum.
• Usar pausas para permitir responder al candidato. Sin embargo, establecer
claramente que las respuestas deben ser concisas y breves.
• Terminar la entrevista explicando quien será el próximo entrevistador, o quien se
comunicará con él y cuando. Encaminarlo hacia el siguiente entrevistador.
• Agradecer al candidato por su tiempo e interés.
4. Después de la entrevista:
• Escriba o almacene las respuestas a las preguntas y primeras impresiones del
candidato mientras estén frescas en su mente.
Gestión de Proyectos de Desarrollo de Software Página 53
Marcela Varas C.
• Organice una reunión con los otros entrevistadores a fin de comparar y discutir
acerca de todos los candidatos
• Enviar comunicaciones citando a los candidatos seleccionados y notificaciones a los
candidatos no seleccionados. Esta última debería provenir del administrador de
proyectos, explicando el porqué de la decisión de no seleccionarlos. Es de sentido
común hacer esta notificación, diciendo además que de todas formas pueden ser
seleccionados en una futura necesidad de empleados.
Entre las consecuencias positivas de la rotación de los integrantes de los equipos de trabajo se
pueden mencionar:
antiguos, pago de pensiones y beneficios, etc. En todo caso, la organización debe evaluar a
conciencia el sacrificar experiencia por la disminución de costos de trabajo.
• Innovación y adaptabilidad: La contratación de nuevos individuos puede traer consigo
nuevos puntos de vista en el uso de la tecnología y experiencia ganada de otra
organización. De esta forma, la organización tendría un método rápido de adaptación al uso
de nuevas tecnologías y de ambientes cambiantes en el área de desarrollo de sistemas.
• Ascensos internos crecientes: Cuando los integrantes mayores e importantes de los
equipos de desarrollo abandonan la organización se abre la posibilidad de una movilidad
interna que permita a integrantes de inferior grado ascender en la escala interna de
responsabilidades y sueldos. Esto puede considerarse como un premio al esfuerzo
demostrado al desarrollar junto al equipo.
• Moral creciente: Cuando existe un conflicto al interior de un equipo, la productividad decae
debido a una baja anímica o moral del resto de los integrantes del equipo. Cuando un
individuo no cumple con los plazos, o la calidad de su trabajo es menor a la esperada,
resiente la calidad del trabajo del resto. Por ello la separación del equipo de esta persona
hace elevar la moral del trabajo. Esta separación de una persona que no cumple con las
metas de la organización puede elevar las opiniones de que la organización valora el
trabajo de alta calidad.
• Eliminación de los malos comportamientos: La rotación de personas infelices dentro del
equipo termina con conductas contrarias a la organización. Se ha observado que estos
individuos descontentos no abandonan la organización por su propia cuenta e incurren en
conductas impropias, tales como, ausentismo, baja calidad del trabajo, e incluso sabotaje.
Este sabotaje, incluso, puede ser peligroso a la organización, cuando el individuo tiene
acceso a la seguridad o programación de los sistemas en los cuales se está trabajando.
Para ello se utiliza una matriz Calidad-Reemplazo que ayuda a determinar al jefe de proyecto,
cual es la real necesidad de los individuos dentro de los equipos de desarrollo. Como ayuda a
esta tarea se debe mantener una clasificación, dinámica en el tiempo, de la categoría del
individuo dentro de la organización y de su integración. Es importante decir que, aparte de
mantener relaciones estables de los integrantes dentro del equipo, esta clasificación está
orientada a mantener y aumentar la calidad y productividad del trabajo de desarrollo.
Junto a las clasificaciones anteriores, el jefe de proyecto debe realizar una serie de actividades
que permitan el buen desarrollo del trabajo en equipo y un adecuado manejo de los recursos
humanos, tarea que contribuye a solidificar la posición de la organización en el área de la
Ingeniería de Software.
Gestión de Proyectos de Desarrollo de Software Página 57
Marcela Varas C.
Un proyecto sw. cubre por entero el esfuerzo técnico y administrativo requerido para entregar
un producto o un conjunto de productos a un cliente, tales que satisfacen los términos de
acuerdo del proyecto. Ese esfuerzo en el proyecto debe ser planeado, iniciado, monitoreado y
controlado para asegurar un seguimiento de los planes, presupuesto y criterios de calidad.
Un proyecto sw. tiene una duración, consumo de recursos y produce productos específicos.
Algunos de los producto son entregados al cliente; aquellos corresponden a los productos
entregables (deliverables) del proyecto.
El acuerdo del proyecto es un documento o conjunto de documentos de acuerdo entre el
desarrollador y el cliente que define el alcance, duración, costo y productos a entregar del
proyecto. Un acuerdo de proyecto típicamente toma la forma de un contrato, una declaración
de trabajo, una especificación de sistema ingenieril, una especificación de requerimiento, un
plan de negocio, o una carta de proyecto.
Desde el punto de vista del jefe, la variedad de esfuerzos requeridos para completar un
proyecto de sw. puede ser categorizadas como funciones, actividades y tareas del proyecto.
Una tarea es la más pequeña unidad de manejo de responsabilidad, esto es por lo tanto a la
unidad atómica de planificación para un proyecto sw. Las tareas tienen duración finita,
Gestión de Proyectos de Desarrollo de Software Página 58
Marcela Varas C.
1. Parte Frontal: Incluye la página de título, una hoja de revisión que contiene la
historia de vida del SPMP, un prefacio que resume el alcance y propósito del SPMP,
una tabla de contenidos y una lista de figuras y tablas.
7. Procesos Técnicos: Especifica planes para administrar el alcance del producto, los
métodos técnicos, herramientas y técnicas usadas para entregar el producto
especificado y planes de documentación del sw.
Pagina de Título
Carta de Revisión
Prefacio
Tabla de Contenidos
Lista de Figuras
Lista de Tablas
1 Introducción
1.1 Alcance
1.2 Propósito
1.3 Acuerdo del proyecto
1.4 Evolución de SPMP
2 Referencias
3 Definiciones
4 Organización del Proyecto
4.1 Modelo de Proceso
4.2 Estructura Organizacional
4.3 Limites e Interfaces Organizacionales
4.4 Responsabilidades del Proyecto
5 Procesos Administrativos
5.1 Objetivos y Prioridades Administrativas
5.2 Dependencias, Restricciones y Supuestos.
5.3 Procesos Integrales
5.4 Gestión del Alcance Administrativo
5.5 Planes de gestión del Itinerario
5.6 Plan de gestión del Presupuesto
5.7 Plan de gestión de los Recursos
5.8 Planes de gestión de la Calidad
5.9 Planes de gestión de Riesgos
Gestión de Proyectos de Desarrollo de Software Página 62
Marcela Varas C.
La página de título contiene el título de y una nota de revisión para identificar unívocamente el
documento.
La carta de revisión es una hoja separada que contiene el número de versión del documento,
la fecha de revisión, firma de aprobación, una lista de las páginas que han sido modificadas en
la actual versión y una lista de los números de versión y fechas de revisión para cada una de
las versiones previas del SPMP.
El prefacio indica el alcance de las actividades del SPMP.
La tabla de contenido y las listas de figuras y tablas proveen los títulos y los números de
página.
7.3.1 Introducción
Esta parte provee una revisión tanto del proyecto como del producto a ser confeccionado. El
alcance del proyecto y el producto, una lista de la entrega del proyecto y las consideraciones
de evolución para e SPMP.
7.3.1.1 Alcance
Esta parte definiría el alcance tanto del proyecto como del producto a ser entregado.
Gestión de Proyectos de Desarrollo de Software Página 63
Marcela Varas C.
7.3.1.2 Propósito
Aquí se provee una resumida declaración de las necesidades del negocio a ser satisfechas por
el proyecto, con un conciso resumen de los objetivos del proyecto.
7.3.2 Referencias
Se provee una completa lista de todos los documentos y otros recursos de información
referenciados en el SPMP. Cada documento puede ser identificado por el título, número de
edición, fecha, autor, y organización editora. Otros recursos, como los archivos electrónicos,
deben ser identificados de una manera no ambigua usando identificadores como la fecha y
número de versión.
7.3.3 Definiciones
Se puede definir o provee referencias de la definición de todos los términos y acronismos
requeridos para interpretar adecuadamente el SPMP.
7.3.8.1 Anexo
Incluiría detalles específicos del personal, detalles de los costos estimados, detalles de las
estructuras de trabajo “breakdown” e información suplementaria para una adecuada
comprensión del SPMP
Gestión de Proyectos de Desarrollo de Software Página 69
Marcela Varas C.
Mucho se habla de cómo establecer parámetros para determinar avances en los proyectos de
SW y más aún cuando este proyecto se encuentra con problemas. Cuando tal situación se
presenta una revisión del proyecto puede ayudar.
A continuación se presenta el QUIÉN, QUÉ, CUANDO, DONDE, POR QUÉ y el CÓMO la
administración del proyecto de SW revisa, incluyendo las herramientas adecuadas para el
equipo de revisión, además de como esto permite descubrir las fortalezas y debilidades de un
proyecto. La revisión ayuda a identificar los problemas de la organización que carecen de una
disciplina de administración. Esta revisión entrega el estado del proyecto en algún instante.
El equipo de revisión debe ser sensible al clima de la organización y respecto de lo que
concierne a la línea de manejo. Uno de los aspectos más importantes es que el equipo de
revisión no debe sobredimensionar los problemas de la organización ya que el proceso de
revisión podría destruir el proyecto. Otro problema menos importante pero que puede ser
desastroso a la larga es cuando la administración del proyecto se comporta en forma defensiva
debido al método de alta administración del equipo de revisión y rechazar las
recomendaciones aún cuando estas puedan ser útiles.
Las revisiones de la administración de proyectos de SW pueden cambiar la forma en la cuál un
proyecto es manejado. Además, con la participación en una revisión, los revisores pueden
relacionar la teoría de administración de proyectos SW a situaciones reales sin exponerse a
capacitaciones. Un equipo de revisión tiene "El efecto de lograr del grupo que esta siendo
revisado piense más en donde ellos están, que necesitan hacer y dar al personal una
oportunidad de expresar sus temores y problemas sin trabas de admitir fallas a sus
supervisores "
Además, aquellos que han sido revisados a menudo se sienten halagados cuando consultan
su opinión, estas personas al estar trabajando en el proyecto casi siempre saben que cosas
están bien, cuáles están mal y cuáles se pueden mejorar. El equipo de revisión hace la función
de catalizador para obtener recomendaciones escondidas de la organización, para esto los
revisores deben establecer un nivel de confianza con aquellos que están en el proyecto y así
estos puedan hablar libremente.
Gestión de Proyectos de Desarrollo de Software Página 70
Marcela Varas C.
Los administradores top no deberían considerar la revisión como una forma de reparar, ya que
no es una vista completa del estado del proyecto. Existen tentaciones para poner a alguién en
el equipo de revisión, el cual más tarde será transferido al proyecto como un administrador
clave. Esto puede originar desconfianza del nuevo administrador simplemente porque la
confidencialidad del proceso de revisión es quebrantada cuando el revisador se une al
proyecto.
La revisión debe instituirse cuando se necesita, y no debiera planificarse como parte del ciclo
de vida del proyecto. La revisión es más efectiva en una área del proyecto donde hay una falla
real o potencial.
Aquí se presentan algunas pistas para encontrar los problemas del proyecto. Hay que
centrarse en los siguientes aspectos.
1. Factores en desacuerdo entre administradores
2. Desacuerdo con clientes , especialmente en lo entregado
3. Afirmaciones como "Las cosas obtenidas no son lo que originalmente fueron proyectadas,
"Los usuarios no han sido capacitados, esa es la razón de ..."
4. La gente clave está siendo cambiada de crisis en crisis
5. La gente clave se aleja del proyecto.
6. Roles no definidos de los administradores y desarrolladores y una pobre relación
interorganizacional
7. Se establece poco compromiso y los que se asumen, no se comunican a los miembros del
proyecto
Gestión de Proyectos de Desarrollo de Software Página 71
Marcela Varas C.
8. Se embarcan en la primera situación antes que las pruebas estén completas y a situaciones
adicionales sin el tiempo para un adecuado afiatamiento
10. Los puntos críticos no están siendo chequeados, por ejemplo no existe fijado un día para
entregar el SW a una prueba
11. Listados de programas ilegibles, demasiados comentarios o muy pocos
12. Una preocupación en dar énfasis a forzar el uso de estándares más que en su utilidad
13. Errores encontrados tardíamente en el ciclo de vida del SW
14. Programas de administración ignorados
15. Una variedad de enfoques al diseño de SW y ninguna correlación aparente entre diseño de
SW y los programas
El proyecto puede estar en serios problemas cuando el administrador del proyecto dice " La
carga es el doble de lo que esperábamos y necesitamos una maquina más grande", "El cliente
está retrasado con los requerimientos".
Las revisiones han identificado donde hay una falta de herramientas de desarrollo, cuando el
almacenamiento y el tiempo real obliga a contar con diseño y donde una revisión del diseño de
planes de prueba o código de revisión no existe con la poca visión por parte de los
administradores del proyecto de las consecuencias de estos defectos.
Un equipo de revisión de un proyecto extenso emplea sobre 100 personas y toma de 4 a 6
días. Esto debería ser ocupado en la planta de desarrollo, con cada sesión durando 2 días. Las
sesiones deben realizarse con 2 semanas de diferencia.
Para mantener la revisión en vigencia , es esencial que la propaganda sea eliminada. Esto
puede ser realizado antes de la reunión teniendo información distribuida a los revisadores
acerca del estado del proyecto y la función que el proyecto se supone realiza, incluyendo
cualquier información de marketing que este disponible.
Las revisiones encuentran los problemas tempranamente. Cuando los planes , objetivos y/o
asignación de recursos parecen irreales , la revisión puede ser usada para socorrer el llamado
de ayuda de los administradores del proyecto. Por otro lado la revisión puede ser usada para
alejar a administradores negativos.
Gestión de Proyectos de Desarrollo de Software Página 72
Marcela Varas C.
La herramienta más importante que el equipo de revisión puede usar es escuchar a los no
directivos. Es esencial escuchar cuidadosamente lo que la gente esta diciendo y tratar de
obtener de sus discusiones los temas comunes.
Una segunda herramienta es el cuestionario en el apéndice A que provee un plan de entrevista
estructurada y que se focaliza en las conclusiones de la administración las cuales pueden ser
de poco agrado de discutir para el desarrollador. Es mucho más agradable hablar de que hará
el proyecto , que es hablar de cómo las personas trabajan juntos , particularmente cuando hay
conflictos.
La tercera herramienta es usar un conjunto de de entrevistas. Personas de todos los niveles
deberían ser seleccionadas para la entrevista y dando la oportunidad de discutir el cuestionario
y cualquier otro punto que llegue a ser importante.
Gestión de Proyectos de Desarrollo de Software Página 73
Marcela Varas C.
La cuarta herramienta es elogio público y simpatía. Esto es útil para los revisadores, para
indicar cuando ellos están enfrentando los mismos problemas en sus proyectos. Pregunte a las
personas en forma aleatoria que están haciendo y por qué. Los revisadores pueden obtener
rápidamente un sentimiento de cuan bien los procedimientos están siendo seguidos y cuando
obedece a los estándares existentes.
A continuación se dan algunos comentarios de las personas que han sido entrevistadas , "Me
siento bien al ser capaz de decir lo que había estado en mi mente "," Nunca nadie me pregunto
antes", "Nosotros estamos más tranquilos al oír que otros proyectos tienen problemas", "esto
nos ha ayudado a ser más reflexivos".
Durante la entrevista es importante que cada persona diga algo y que algunas preguntas sean
dirigidas a aquellos que son más callados. El equipo de revisión debe proporcionar un clima de
participación y no dejar que ninguna persona domine la discusión.
B. Como fue el proyecto dotado de personal como una función del tiempo (incluyendo
proyecciones en el futuro) ? (Incluya nivel de experiencia de la gente inicial tanto de
administradores como personal) .¿ Hay problemas de staffing.?
C. Que programas de capacitación tiene para los nuevos empleados.
D. Tiene alguna organización especial propia del staff ? Si es así , cuál es su rol ?
E. Cuanto sobre tiempo se trabajo?
V. Controles de proyecto y seguimientos
A. Cuales son y quienes los monitorean ? Para
1. Planes
2. Hitos (Incluye hitos iniciales y planes actuales)
3. Diseño de documentación de registros
4. Documentación del usuario
5. Técnicas de desarrollo
B. Cuales parámetros del proyecto son seguidos ? Por ejemplo :
1. Planes
2. Tiempo real
3. Uso de memoria
4. Uso de ancho de banda para los I/O
C. Cómo son controlados los cambios
D. Cómo son descubiertos y tratados los problemas
E. Cuánto tiempo se pasa estimando estados
F. Quién es el administrador de más alto nivel que siempre lee los códigos ?
G. Quién es el administrador de más alto nivel que frecuentemente lee los códigos ?
VI. Estableciendo decisiones
A. Cómo son establecidas las decisiones claves ?
B. Cómo fue resuelta la crisis más significativa ?
C. Qué nivel de aprobación es requerido para qué tipo de decisiones (Quién se
encarga de qué?)
D. Cuál es el rol de la fuerza de trabajo y comités
VII. Comunicaciones
A. Cómo son manejadas las comunicaciones al interior del proyecto (verbal y escritas)
?
1. Entre cada organización
2. Verticalmente a través de la línea de mando
Gestión de Proyectos de Desarrollo de Software Página 75
Marcela Varas C.
1. Los objetivos que se establecen a través del diálogo descomponen la meta del proyecto en
tareas específicas y comprometen a sus miembros con cada una de ellas.
2. Los objetivos le ayudan a identificar quién debe estar en el grupo del proyecto y
contribuyen a crear una sensación de propiedad entre los miembros del grupo.
3. Evite concentrarse en forma demasiado estrecha en los objetivos y perder de vista la meta
global del proyecto.
4. Formule recompensas que estén ligadas tanto al éxito global del proyecto como al de los
objetivos.
5. Asegúrese de que la responsabilidad por el éxito de un proyecto genera la autoridad
correspondiente.
1. Desarrolle el cuerpo de su proyecto definiendo los puntos de control que señalen los
progresos, las actividades que llevan a la realización del proyecto, las relaciones entre
actividades y las estimaciones de tiempo (costos y otros recursos) para cada una de ellas.
Gestión de Proyectos de Desarrollo de Software Página 77
Marcela Varas C.
1. Las fallas de comunicación en los proyectos se deben a una serie de obstáculos que
pueden superarse. La clave son los bloques organizacionales que intervienen debido a la
naturaleza misma del proyecto o del contingente de trabajo: personas de diferentes
departamentos que trabajan en una misma tarea, única e interrelacionada.
Gestión de Proyectos de Desarrollo de Software Página 79
Marcela Varas C.
2. Para transmitir su mensaje más efectivamente, a) toque a los demás allí donde están, b)
dígales por qué su mensaje tiene importancia para ellos, c) manténgalos informados
regularmente y d) comuníquese afirmativamente.
3. Escuchar es aún más importante que hablar. Los pasos críticos para saber escuchar
incluyen concentrarse en el mensaje, escuchar sin hablar, escuchar hasta que el otro
termine y fijarse en las señales verbales tanto como en las no verbales.
1. Aprender a manejar los conflictos, en lugar de evitarlos, puede ayudar al líder de un equipo
a alcanzar sus objetivos. Los conflictos representan un compromiso emotivo con un
proyecto y cuando se mantienen bajo control pueden llevar a los miembros del equipo a
solucionar los problemas en forma cooperativa.
2. Generalmente, en el ciclo de vida de un proyecto o de un contingente de trabajo surgen
diferentes fuentes de conflicto. Saber cuándo y por qué se originan estos conflictos
permiten aprender a canalizar las energías de los miembros del equipo.
3. Para resolver estos conflictos se requiere crear un terreno común, ampliar las áreas de
acuerdo, recoger información y concentrarse en los problemas y no en las personas.
4. Al mediar en un conflicto, recuerde que ambas partes deben quedar satisfechas, no sólo
racional sino también emotivamente.
9.9 Regla número 9: Aumente el poder: tanto el suyo como el de los demás
1. Gran parte del poder real que tienen los gerentes de proyecto y los líderes de contingentes
de trabajo proviene del poder personal derivado de tres fuentes: poder: de referencia, de
experto y de relaciones.
2. Cuando los líderes comparten el poder con los miembros del equipo, puede lograrse un
mayor nivel de compromiso y participación.
3. La gente busca en sus líderes cuatro características personales: honestidad, competencia,
visión y capacidad para ser fuente de inspiración.
Gestión de Proyectos de Desarrollo de Software Página 80
Marcela Varas C.
9.10 Regla número 10: Atrévase a acercarse con creatividad a los problemas
1. Contrario a lo que mucha gente cree, es posible enseñar creatividad a las personas.
2. Antes de que las personas puedan permitirse ser creativas, su trabajo es eliminar los
obstáculos potenciales para la toma de riesgos.
3. Las metas y las fechas límite pueden ayudar a estimular la creatividad.
4. Cuatro estrategias para alentar la creatividad son la sensibilidad, la fluidez en las ideas, la
originalidad y una mayor flexibilidad.
Gestión de Proyectos de Desarrollo de Software Página 81
Marcela Varas C.
10. Bibliografía.
• Richard Thayer ed., "Software Engineering Project management", IEEE Computer Society,
1998.
• Marcela Varas C., "Apuntes de clases: Gestión de Proyectos de Ingeniería de Software",
Universidad de Concepción, 1998 (en colaboración con Ximena Hormazábal, Luis
Monsalve, Jorge Muñoz, César Olivares, Rodrigo Oviedo y Carmen Wolff).
• Ricardo Contreras, "Apuntes de clases: Ingeniería de Software", Universidad de
Concepción, 1997
• Steve McConnell, "Desarrollo y Gestión de Proyectos Informáticos", McGraw Hill 1996
• W. Alan Randolph, Barry Posner, "Gerencia de Proyectos", Mc Graw Hill 1993
• Watts Humphrey, "Managing the Software Process", Addison Wesley 1990
• Barry Boehm, "Software Engineering Economics", Prentice Hall 1981