Unidad6-GestionDeProyectos

Vista previa del material en texto

CONTENIDO 
 
 TEMAS A DESARROLLAR FUENTE BIBLIOGRÁFICA 
 - Sommerville I., Cap. 22, 23 
 - Pressman, R., Cap. 24,26,27,28 
 
 
 
 
 
 
 
 
 
“El trabajo del administrador del proyecto es asegurarse de que el proyecto software 
cumpla y supere las restricciones, además de que entregue software de alta 
calidad.” 
 “La buena gestión no puede garantizar el éxito del proyecto, pero una 
mala gestión puede hacer que el software se entregue tarde, cueste 
más de lo estimado originalmente o no cumplir las expectativas de los 
clientes” 
“Los proyectos necesitan administrarse porque la ingeniería de software 
profesional está sujeta siempre a restricciones organizacionales de presupuesto 
y fecha” 
1- Entregar el software al cliente en el tiempo acordado. 
2- Mantener los costos dentro del presupuesto general. 
3- Entregar software que cumpla con las expectativas del cliente. 
4- Mantener un equipo de desarrollo óptimo y con buen 
funcionamiento. 
“Los criterios de éxito para la gestión del proyecto varían de un proyecto a otro, 
aunque para la mayoría de los proyectos las metas importantes son:” 
1- El producto es intangible: un administrador de proyectos de ingeniería 
civil, por ejemplo, puede ver el producto conforme se desarrolla. 
2- Los grandes proyectos de software con frecuencia son excepcionales: 
los vertiginosos cambios tecnológicos pueden volver obsoleta la 
experiencia de un administrador . 
3- Los procesos de software son variables y específicos de la 
organización: los procesos de software varían considerablemente de 
una organización a otra. 
La ingeniería de software es diferente en algunas formas a otros tipos de 
ingeniería que hacen a la gestión del software particularmente desafiante. 
Algunas de estas diferencias son: 
1- Planeación del proyecto: los administradores son responsables de la planeación, 
estimación y calendarización del desarrollo del proyecto y de la asignación de tareas 
a las personas. 
2- Informes: los administradores de proyectos son responsables de informar el avance 
de un proyecto a los clientes y administradores de la empresa que desarrolla el 
software . 
3- Gestión del riesgo: los administradores del proyecto deben valorar los riesgos que 
pueden afectar un proyecto, monitorizarlos y emprender acciones cuando surjan 
problemas. 
4- Gestión del personal: los administradores del proyecto son responsables de 
administrar un equipo de personas. 
5- Redactar propuestas: la primera etapa en un proyecto de software puede implicar 
escribir una propuesta (objetivos y cómo se realizará) para obtener un contrato de 
trabajo. 
 
Los administradores, en alguna etapa, toman la responsabilidad de varias o todas 
de las siguientes actividades: 
La gestión efectiva de un proyecto de software depende de planificar 
completamente el progreso del proyecto 
El gestor del proyecto debe anticiparse a los problemas que puedan surgir, así 
como preparar soluciones a esos problemas. 
Además de un plan de proyecto los gestores tienen que preparar otros tipos de 
planes. 
Los panes incluyen por lo regular las siguientes secciones: 
1- Introducción: objetivos y restricciones (presupuesto, tiempo, etc.) 
2- Organización del proyecto: refiere la forma en que está organizado 
el equipo de desarrollo, las personas implicadas y sus roles 
3-Análisis de riesgo: detalla los posibles riesgos, la probabilidad que 
surjan y las estrategias para reducirlo. 
4-Requerimientos de recursos de hardware y software: detalla el 
Hardware y Software de soporte requeridos para realizar el desarrollo. 
Los panes incluyen por lo regular las siguientes secciones: 
5- División del trabajo: establece la división del proyecto en 
actividades e identifica plazos y las entregas asociadas a cada 
actividad. 
6- Calendario del proyecto: indica las dependencias entre las 
actividades, el tiempo estimado requerido para alcanzar cada plazo y 
la asignación del personal a las actividades 
 7- Mecanismos de monitorización y reporte: define los informes 
administrativos que deben producirse, cuando tienen que elaborarse 
y los mecanismos de monitorización del proyecto que se usarán 
Conviene desarrollar algunos planes complementarios para apoyar otras 
actividades del proceso, como las pruebas y la administración 
Complementos del Plan de proyecto 
La planificación es un proceso iterativo que sólo se termina cuando el 
proyecto se concluye y que comienza con la fase de arranque del proyecto. 
El plan debe revisarse regularmente. 
Las metas globales del negocio deben considerarse cuando se formula el plan 
de proyecto. Cuando cambien se hará necesario cambios en el proyecto. 
El proceso de planeación del proyecto 
La calendarización de proyectos es el proceso de decidir cómo se organizará el 
trabajo en un proyecto como tareas separadas, cuando y cómo se ejecutarán 
Los gestores estiman el tiempo y los recursos requeridos para completar las 
actividades y organizarlas en una sucesión coherente. 
Si el proyecto es similar a otro anterior, el calendario de éste puede utilizarse 
como estimación. 
Realizar el calendario implica separar todo el trabajo en actividades y 
considerar el tiempo requerido para completar dichas actividades. 
El proceso de calendarización del proyecto 
Algunas actividades se pueden desarrollar en paralelo. 
Deben evitarse situaciones en que el proyecto se retrase debido a que no se 
ha terminado una actividad crítica. 
Las actividades deben durar por lo menos una semana y no deben durar más 
de diez. 
Los gestores deben estimar los recursos necesarios para completar cada tarea. 
Una regla práctica consiste en estimar como si todo fuera bien y luego agregar 
tiempos teniendo en cuenta los problemas previstos. 
-Se debe agregar un factor extra de contingencia. 
-El factor de contingencia tiene que ver con el tipo de proyecto, los 
parámetros del proceso (fecha de entrega, estándares, etc.) y de la calidad y 
experiencia de los ingenieros de software que trabajen en el proyecto. 
 
Como regla general debe agregarse un 30% a la estimación original para lo 
previsto y 20% para lo no previsto. 
El calendario del proyecto se presenta como un conjunto de gráficos que 
muestran la división del trabajo, las dependencias de las actividades y la 
asignación de personal. 
Existen Dos tipos de representación que se usan normalmente: 
1- Gráficos de barras (GB): muestran quién es responsable de cada actividad y 
cuándo debe comenzar y finalizar ésta. 
2 - Redes de actividad (RA): muestran las dependencias entre las diferentes 
actividades que conforman un proyecto. 
Los GB y las RA generalmente se generan automáticamente a partir de una 
base de datos de la información del proyecto utilizando una herramienta de 
gestión de proyectos 
Las actividades de proyecto son el elemento de planeación básico. 
Cada Actividad cuenta con: 
 
1- Una duración en días o meses calendario. 
2 – Una estimación del esfuerzo, la cual refleja el número de días-hombre o 
meses-hombre para completar el trabajo. 
3- Un plazo dentro del cual debe completarse la actividad. 
4- Un punto final bien definido, el cual representa el resultado tangible de 
completar la actividad (documento, ejecución exitosa de las pruebas, etc.) 
Cuando se planee un proyecto, también deberá, definirse los hitos , es decir, 
cada etapa del proyecto donde pueda realizarse una valoración del avance. 
Cada Hito debe documentarse mediante un breve reporte que compendie el 
avance realizado y el trabajo efectuado. 
Los hitos pueden asociarse con una ´sola tarea o con grupos de actividades 
relacionadas. 
Un tipoespecial de hito es la producción de un entregable del proyecto, que 
es el resultado de una fase significativa del proyecto como la especificación o el 
diseño. 
Tareas, duraciones y dependencias. 
Tomando como base la relación entre tareas, duraciones y dependencias, se 
puede representar el calendario del proyecto en forma gráfica. 
. 
Se trata de un gráfico de barras que muestra un calendario de proyecto y las 
fechas de inicio y terminación de las actividades. 
Al leerse de izquierda a derecha, la gráfica de barras señala claramente cuando 
comienzan y terminan las tareas. 
Gráfica de barras de actividad 
Además de planear el calendario de entregas para el software, los 
administradores de proyecto deben asignar recursos a las tareas 
El recurso más importante es el personal que desarrollará las tareas y deben 
ser asignadas a las actividades del proyecto. 
La asignación de recurso puede integrarse a las herramientas de administración 
del proyecto y a una gráfica de barras generadas, que describen cuando el 
personal trabaja en el proyecto. 
Gráfica de asignación del personal 
Es difícil realizar la estimación del calendario del proyecto 
Es probable que haya que realizar estimaciones iniciales sobre la base de una 
definición de requerimientos de usuario de alto nivel. 
El software puede ejecutarse en computadoras no familiares o utilizar nueva 
tecnología de desarrollo. 
Existe tanta incertidumbre que es imposible estimar con precesión los costos 
de desarrollo del sistema durante las primeras etapas de un proyecto. 
La estimación se utiliza para definir el presupuesto del proyecto, y el producto 
se ajusta para que se cumpla la cifra del presupuesto. 
Un proyecto que está dentro de presupuesto puede lograr esto a expensas de 
las características en el software a desarrollar. 
Las organizaciones necesitan hacer evaluaciones de esfuerzo y costo del 
software. 
Para hacer evaluaciones de esfuerzo y costo del software, existen dos tipos de 
técnicas: 
1- Técnicas basadas en la experiencia: la estimación de los requerimientos de 
esfuerzo futuro se basan en la experiencia del administrador del proyecto. 
 
2 – Modelado algorítmico de costo: se utiliza un enfoque basado en fórmulas 
En ambos casos es necesario utilizar el juicio para evaluar el esfuerzo 
directamente, estimar el proyecto y las características del producto. 
Para hacer evaluaciones de esfuerzo y costo del software, existen dos tipos de 
técnicas: 
1- Técnicas basadas en la experiencia: la estimación de los requerimientos de 
esfuerzo futuro se basan en la experiencia del administrador del proyecto. 
 
2 – Modelado algorítmico de costo: se utiliza un enfoque basado en fórmulas 
En ambos casos es necesario utilizar el juicio para evaluar el esfuerzo 
directamente, estimar el proyecto y las características del producto. 
Durante la planeación del desarrollo, las estimaciones se vuelven cas vez más 
precisas conforme avanza el proyecto. 
Incertidumbre de estimación 
X=meses de esfuerzo 
El modelado algorítmico de costos utiliza una fórmula matemática para 
predecir los costos del proyecto con base en estimaciones del tamaño del 
proyecto, el tipo de software a desarrollar y otros factores de equipo, proceso y 
producto. 
Un modelo algorítmico de costo puede elaborarse al analizar los costos y 
atributos de los proyectos completados y encontrar la fórmula de ajuste más 
cercana a la experiencia real. 
 
Los modelos algorítmicos de costo se usan principalmente para hacer 
estimaciones de los costos de desarrollo de software. 
Los modelos algorítmicos poseen inconvenientes similares: 
 
1- Es difícil estimar el Tamaño en una etapa del proyecto, cuando sólo está 
disponible la especificación. 
 
2 – Las estimaciones de los factores que contribuyen a B y M son subjetivas, 
varían de una persona a otra, dependiendo de la experiencia con el tipo de 
sistema que se desarrolla. 
 
 
 
 
 
 
 
Si se utiliza un modelo algorítmico de estimación de costos, hay que 
desarrollar un rango de estimaciones (peor, esperado y mejor) en lugar de 
una sola estimación y aplicar la fórmula de costo a todas ellas. 
 
 
 
Los modelos algorítmicos para estimar el esfuerzo en un proyecto de software 
se basan principalmente en la siguiente fórmula: 
 
 Esfuerzo= A x Tamaño B x M 
 
A= factor constante que depende las prácticas locales de la organización y el tipo de 
software que se desarrolla. 
Tamaño= una valoración del tamaño del código de software o una estimación de la 
funcionalidad expresada en puntos de función o aplicación. 
B= una valor que se encuentra entre 1 y 1,5. Aumenta normalmente con el tamaño y la 
complejidad del sistema. Esto refleja el hecho que los costos no aumentan con regularidad 
lineal al tamaño del sistema. 
M= un multiplicador que se integra al combinar atributos de procesos, producto y desarrollo 
(tales como los requerimientos de confiabilidad para el software y la experiencia del equipo) 
 
 
Es un modelo empírico que se derivó al recopilar datos a partir de un gran 
número de proyectos de software. 
Los datos se analizaron para descubrir qué fórmulas se ajustaban mejor con 
las observaciones. 
 
Las fórmulas vinculan el tamaño del sistema y los factores del producto, 
proyecto y equipo, con el esfuerzo para desarrollar el sistema. 
COCOMO II soporta el modelo en espiral de desarrollo, e incrusta submodelos 
que producen estimaciones cada vez más detalladas. 
 
Submodelos de estimación de COCOMO 
 
Apoya la estimación del esfuerzo en proyectos en los cuales el software se 
desarrolla mediante la composición de los componentes existentes 
(componentes de reutilización). 
 
Las estimaciones del tamaño del software se basan en puntos de aplicación. 
 
El N° de puntos de puntos de aplicación en un programa es una estimación 
ponderada de: 
-El N° de pantallas separadas que se despliegan. 
-El N° de informes que se producen. 
-El N° de módulos en lenguajes de programación imperativa(Java) 
-El N° de líneas de lenguaje de escritura de guiones (Scripting) o código de 
programación de Base de Datos. 
 
Niveles de Productividad de punto de aplicación sugeridos por los 
desarrolladores de COCOMO. 
 
La fórmula para calcular el esfuerzo de un prototipo o sistema es: 
 
PM= (NAP x (1-%reutilización / 100) /PROD 
 
PM = estimación del esfuerzo en meses-hombre 
NAP= N° de puntos de aplicación 
% reutilización= estimación de la cantidad de código de reutilización en el 
desarrollo. 
PROD= productividad del punto de aplicación 
 
Este modelo se usa durante etapas tempranas del diseño del sistema 
después de establecer los requerimientos. 
 
La estimación se basa en la fórmula de estimación estándar con un 
conjunto simplificado de siete multiplicadores. 
 
-Las estimaciones se basan en puntos de función que luego se convierten a 
N° de líneas de código fuente. 
-Los puntos de función son una forma independiente de lenguaje para 
cuantificar la funcionalidad del programa. 
-El N° total de puntos de función en un programa se calcula al medir o 
estimar el N° de entradas y salidas externas, las interacciones de usuario, las 
interfaces externas y las tablas o bases de datos que usa el sistema. 
La estimación se basa en la fórmula de estimación estándar : 
 Esfuerzo= A x Tamaño B x M 
A= 2.94 (propuesto por Boehm). 
Tamaño= se expresa en KSLOC, N° de miles de líneas de código fuente. Se calculan al estimar 
el N° de puntos de función en el software. 
B= refleja el esfuerzo creciente requerido conforme aumenta el tamaño del proyecto. Puede 
variar entre 1.1 a 1.24 dependiendo de la novedad del proyecto, flexibilidad del desarrollo, 
procesos de resolución de riesgos utilizados, cohesión del equipo de desarrollo y nivel de 
madurez del proceso. 
M= PERS * RCPX * RUSE * PDIF * PREX * FCIL *SCED (Los valores para dichos atributos se 
estimanmediante una escala de seis puntos dónde 1 = “muy bajo” y 6= “muy alto” ) 
PERS=Habilidad personal, RCPX=Fiabilidad y complejidad del producto, RUSE= Reutilización 
requerida, PDIF= Dificultad de plataforma, PREX= Experiencia personal, FCIL=Facilidades de 
soporte, SCED=calendario. 
 
 
El modelo además ofrece una base para calcular el N° equivalente de líneas de 
código nuevo (ESLOC). Éste se basa en el numero de líneas de código de reutilización 
que deben cambiarse y un multiplicador que refleja la cantidad de trabajo que es 
necesario hacer para reutilizar los componentes . 
 
Para calcular el N° de líneas equivalentes de código fuente se utiliza la sgte, fórmula: 
 
ESLOC= ASLOC x AAM 
ESLOC = N° equivalente de líneas de nuevo código fuente. 
ASLOC= N° de líneas de código en los componentes que deben cambiarse. 
AAM= Multiplicador de ajuste de adaptación.=> AAF + SU + AA 
AAF=costos de hacer cambios al código de reutilización, SU= costos para comprender 
el código a reutilizar, varia de 50 a 10, AA=costos de tomar la decisión de reutilizar, 
varía de 0 a 8. 
 
Si alguna adaptación al código puede hacerse de forma automática , esto reduce el 
esfuerzo requerido, por lo tanto la estimación se ajusta al evaluar el porcentaje de 
código adaptado automáticamente (AT) y utilizar esto para ajustar ASLOC. 
 
En consecuencia la fórmula final es: 
 
ESLOC= ASLOC x (1-AT/100) x AAM 
 
Una vez diseñada la arquitectura del sistema puede hacerse una estimación 
más precisa del tamaño del software. 
 
Este modelo utiliza la fórmula estándar para la estimación de costo. 
 
Incluye un extenso conjunto de 17 multiplicadores que reflejan 
características de capacidad personal, del producto y del proyecto. 
La estimación se basa en la fórmula de estimación estándar : 
 PM= A x Tamaño B x M 
 
-Para esta etapa del proceso, hay que hacer una estimación más precisa del tamaño del 
proyecto conforme se conoce como se dividirá el sistema en objeto o módulos. 
- Estas estimaciones del tamaño del código se hacen mediante tres parámetros: 
 
1. Una estimación del N° total de líneas de código nuevo a desarrollar (SLOC) 
2- Una estimación de los costos de reutilización, con base en un N° equivalente de líneas de 
código fuente (ESLOC), calculadas mediante el modelo de reutilización 
3- Una estimación del N° de líneas de código que es probable se modifiquen debido a 
cambios a los requerimientos del sistema 
 
Los valores de estos parámetros se suman para calcular el tamaño del código total, en 
KSLOC, que se emplea en la fórmula de cálculo de esfuerzo. 
 
El componente final en la estimación, el N° de líneas de código modificado, 
refleja el hecho de que los requerimientos de software siempre cambian. 
 
-El término exponente (B) en la fórmula de cálculo de esfuerzo se relaciona con 
los niveles de complejidad del proyecto. 
-Conforme los proyectos se hacen más complejos, los efectos de aumentar el 
tamaño del sistema se hacen más significativos., 
-El valor del exponente B se basa en cinco factores, los que se clasifican en un 
escala de 6 puntos, de 0 a 5, donde 0 significa ”extra alto” y 5 significa "muy 
bajo”. 
-- Para calcular B se suman las clasificaciones, se dividen entre 100 y los 
resultados se suman a 1.01 para obtener el exponente B que debe usarse. 
 
 
Factores de escala empleados en el cálculo del exponente B en el modelo post-arquitectónico 
-La estimación del esfuerzo global, se perfecciona usando un conjunto extenso 
de 17 atributos ( CONTROLADORES DE COSTO) del producto, del proceso y la 
organización, en lugar de los 7 atributos usados en el modelo de diseño 
temprano. 
 
- Los atributos del controlador de costos pueden influir en las estimaciones del 
esfuerzo. 
 
 
 
 
 
Efecto de los controladores de costos sobre las estimaciones del esfuerzo 
Los administradores del proyecto también deben estimar cuanto tardará 
el software en desarrollarse, y cuando el personal necesitara trabajar en 
el proyecto . 
Cada vez más las organizaciones demandan calendarios de desarrollo 
mas cortos, de forma que sus productos puedan llegar al mercado antes 
que los de sus competidores. 
El modelo COCOMO incluye una fórmula para estimar el tiempo 
calendario, requerido para completar un proyecto (TDEV): 
 
TDEV= 3 x (PM) (0.33 + 0.2 * (B – 1.01)) 
TDEV = es el calendario nominal para el proyecto, en meses calendario, que ignora 
cualquier multiplicador relacionado con el calendario del proyecto. 
PM= es el esfuerzo calculado por el modelo COCOMO. 
B= es el exponente relacionado con la complejidad. 
Si B=1.17 y PM= 60 entonces 
TDEV= 3 x (60) 0.36= 13 meses 
“Se puede considerar un riesgo como algo que es 
preferible que no ocurra.” 
 “Los riesgos pueden amenazar el proyecto, el software que se 
desarrolla o la organización” 
“La gestión del riesgo implica anticipar riesgos que pudieran alterar el 
calendario del proyecto o la calidad del software a entregar y posteriormente 
tomar acciones para evitar dichos riesgos” 
1- Riesgos del proyecto: son riesgos que alteran el calendario o 
los recursos del proyecto. 
2- Riesgos del producto: son riesgos que afectan la calidad o el 
rendimiento del software a desarrollar. 
3- Riesgos empresariales: son riesgos que afectan a la 
organización que desarrolla o adquiere el software. 
 
Existen tres categorías relacionadas al riesgo: 
Ejemplos de riesgos comunes para el proyecto, el producto y la empresa 
1- Identificación del riesgo: hay que identificar los posibles 
riesgos para el proyecto, el producto y la empresa. 
2- Análisis del riesgo: se debe valorar la probabilidad y las 
consecuencias de los riesgos. 
3- Planeación del riesgo: es indispensable elaborar planes para 
enfrentar el riesgo, evitarlo o minimizar sus efectos. 
4- Monitorización del riesgo: hay que valorar regularmente el 
riesgo y los planes para atenuarlo, y revisarlos cuando se 
aprenda más sobre el riesgo 
 
El proceso de gestión del riesgo comprende varias etapas: 
El proceso de gestión del riesgo 
El Plan de gestión de riesgos incluirá: 
1-Un estudio de los riesgos que enfrenta el 
proyecto. 
2-Un análisis de dichos riesgos 
3-Información de cómo se gestionará el riesgo 
cuando es probable que se convierta en una 
problema 
“Es preciso documentar los resultados del proceso de gestión del riesgo en un 
plan para gestionar el riesgo” 
1. Una vez desarrollado el plan de gestión del 
riesgo inicial, se monitoriza la situación para 
detectar riesgos emergentes. 
2. Conforme está disponible más información 
referente a los riesgos, habrá que analizarlos y 
decidir si se cambió la prioridad del riesgo. 
3. En este último caso quizás sea necesario 
cambiar los planes para evitar el riesgo y 
gestionar la contingencia. 
“El proceso de gestión del riesgo es un proceso iterativo que continúa 
a lo largo del proyecto” 
“La identificación del riesgo puede ser un proceso de equipo en el 
que éste último se reúne para pensar en posibles riesgos. o el 
administrador del proyecto, en base a su experiencia identifica los 
riesgos más probables o críticos.” 
 “Para iniciar la identificación del riesgo, se recomienda utilizar una 
lista de verificación de diferentes tipos de riesgos” 
“La identificación del riesgo se ocupa de identificar los riesgos que 
pudieran plantear una mayor amenaza al proceso de ingeniería de 
software, al software a desarrollar o a la organización que lo 
desarrolla” 
1. Riesgos tecnológicos: se derivan de las tecnologías de software o 
hardware utilizadas para desarrollar el sistema. 
2. Riesgos personales: se asocian con las personas en el equipo de 
desarrollo 
3. Riesgos organizacionales: se derivan del entorno organizacional donde 
se desarrolla el software. 
4. Riesgos de herramientas: resultan de las herramientas de software y 
otro software de soporte que se usa para desarrollar el sistema. 
5. Riesgos de requerimientos: proceden de cambios a los requerimientos 
del cliente y delproceso de gestionarlos. 
6. Riesgos de estimación: surgen de estimaciones administrativas de los 
recursos para construir el sistema. 
Existen al menos seis tipos de riesgos que pueden incluirse en una lista de 
verificación: 
Ejemplos de diferentes tipos de riesgos 
“El análisis de riesgos se debe apoyar en el juicio propio 
y en la experiencia obtenida de proyectos anteriores 
y los problemas que surgieron en ellos” 
 “No es posible hacer una valoración precisa y numérica de las 
probabilidad y gravedad de cada riesgo” 
“Durante el proceso de análisis de riesgos, hay que considerar cada riesgo 
identificado y realizar un juicio acerca de la probabilidad y gravedad de dicho 
riesgo” 
1- La probabilidad del riesgo puede valorarse como: 
 Muy baja (<10%) - Baja (del 10% al 25%) -Moderada (del 25% al 
50%) - Alta(del 50% al 75%) - Muy alta (>75%) 
 
2- Los efectos del riesgo pueden estimarse como: 
 Catastróficos (amenazan la supervivencia del proyecto) Graves 
(causarían grandes demoras) - Tolerables (demoras dentro de la 
contingencia permitida) - Insignificantes 
Hay que asignar el riesgo a una de ciertas bandas: 
“La valoración de la probabilidad y la seriedad son arbitrarias” 
 “Para hacer la valoración se necesita información detallada del proyecto, 
el proceso, el equipo de desarrollo y la organización” 
“Posteriormente hay que tabular los resultados de este proceso de análisis 
mediante una tabla clasificada de acuerdo con la gravedad del riesgo” 
“Tanto la probabilidad como la valoración de los efectos de un riesgo 
pueden cambiar conforme se disponga de más información acerca del 
riesgo y a medida que se implementa en planes de gestión del riesgo. 
” 
Tipos de riesgos y efectos 
“Una vez analizados y clasificados los riesgos, se debe valorar cuales son los 
más significativos” 
 “Un juicio de valor, deberá depender de una combinación de la probabilidad de 
que el riesgo surja junto con los efectos de dicho riesgo” 
“La Tabla de gravedad del riesgo, debe ser actualizada durante cada iteración 
del proceso de riesgo” 
“El número correcto de riesgos a identificar y monitorizar debe depender 
del proyecto y ser manejable para trabajarlos (entre 5 a 15)” 
“Para cada uno de los riesgos se debe considerar las acciones que puede tomar 
para minimizar la perturbación del proyecto si se produce el problema 
identificado en el riesgo” 
 “También se debe pensar en la información que tal vez se necesite recopilar 
mientras se observa el proyecto para poder anticipar los problemas” 
“El proceso de planeación del riesgo considera cada uno de los riesgos clave 
identificados y desarrolla estrategias para manejarlos” 
“No existe un proceso simple que pueda seguirse para la planeación de 
contingencias, todo se basa en el juicio y experiencia del 
administrador del proyecto” 
 
1- Estrategias de evitación: siguiendo estas estrategias significa que se reducirá la 
probabilidad de que surja el riesgo. 
2- Estrategias de minimización: seguir estas estrategias significa que se reducirá el 
efecto del riesgo. 
3- Planes de contingencia: implica que se está preparado para lo peor y se tiene 
una estrategia para hacer frente a ello 
Las estrategias de gestión del riesgo se establecen en tres categorías: 
Estrategias para ayudar a gestionar el riesgo 
La monitorización del riesgo es el proceso para comprobar que no han 
cambiado las suposiciones sobre riesgos del producto, el proceso y la empresa. 
Se debe evaluar regularmente cada uno de los riesgos identificados para decidir 
si este riesgo se vuelve más o menos probable. 
Se tiene que considerar si los efectos del riesgo han cambiado o no 
Existen factores, como el N° de peticiones de cambio de requerimientos, que 
brindan una pista acerca de la probabilidad del riesgo y sus efectos. 
Indicadores de riesgo 
Los factores o indicadores potenciales, dependen claramente del riesgo 
Los riesgos deben monitorizarse permanentemente en todas las etapas del 
proyecto. 
En cada revisión administrativa, es necesario reflexionar y estudiar cada uno de 
los riesgos clave por separado. 
Además hay que decidir si es más o menos probable que surja el riesgo y si 
cambiaron la gravedad y las consecuencias del riesgo. 
1) Las personas que trabajan en una organización 
son los activos más importantes de una empresa. 
2) Cuesta mucho dinero y esfuerzo reclutar y 
retener al buen personal 
3) En las compañías y economías exitosas esto se 
logra respetando a las personas y asignándoles 
responsabilidades que reflejen sus habilidades y 
experiencia 
 
 
 
 
1) Los buenos Ingenieros de software (IS) no 
necesariamente son buenos administradores 
de personal. 
2) Los IS carecen de habilidades que les 
permitan motivar y dirigir un equipo de 
desarrollo de proyecto. 
3) Como administradores de proyectos , se 
deben desarrollar habilidades de gestión de 
recursos humanos. 
 
 
 
Existen cuatro factores críticos en la gestión de personal: 
1) Consistencia: Todas las personas del grupo de trabajo deben 
recibir un trato similar. 
2) Respeto: las personas poseen diferentes habilidades, y el 
administrador debe respetar esas diferencias 
3) Inclusión: las personas contribuyen mejor cuando sienten 
que son escuchadas y sus propuestas se toman en cuenta. 
4) Honestidad: como administrador se debe ser honesto 
reconociendo que se hace bien y mal en el equipo de 
desarrollo. 
 
 
 
 
“La gestión de personal es algo que debe 
basarse en la experiencia” 
 
 
“Motivación, significa organizar el trabajo y el 
ambiente laboral para alentar a los individuos a 
desempeñarse tan efectivamente como sea posible” 
 
- Si las personas no están motivadas trabajarán con 
lentitud cometiendo errores y sin contribuir con las 
metas más amplias del equipo o la organización. 
-Los administradores de proyectos necesitarán motivar 
a las personas con quienes trabaja, para que éstas 
contribuyan con lo mejor de sus habilidades. 
-Las personas se sienten motivadas para cubrir 
distintas necesidades propias. 
 
 
 
 
 
 
 
 
De Estima 
Sociales 
De Seguridad 
Fisiológicas 
Jerarquía de necesidades humanas 
- Las personas que trabajan en el desarrollo de 
software necesitan que se cubran sus 
necesidades sociales , de estima y de 
autorrealización. 
 
1- Sociales: es preciso dar a las personas tiempo para 
reunirse con sus compañeros de trabajo y proporcionarles 
lugares de socialización. 
2-Estima: es necesario demostrar a las personas que son 
valoradas en la organización. 
3-Autorrealización: es necesario dar a las personas 
responsabilidad por su trabajo, asignarles tareas 
demandantes (pero no imposibles) y ofrecer un programa 
de capacitación donde pueda desarrollar sus habilidades 
 
-El tipo de personalidad influye en la motivación: 
1- Personas orientadas a las tareas: motivadas 
por el reto intelectual de desarrollar software. 
Prefieren trabajar individualmente. 
2- Personas orientadas hacia sí mismas: 
motivadas por el éxito y reconocimiento 
personales. 
3- Personas orientadas a la interacción: 
motivadas por la presencia y las acciones de los 
compañeros de trabajo. Disfrutan trabajar en 
grupo. 
 
“El administrador de proyectos deberá conformar un grupo que 
tenga el equilibrio justo de habilidades técnicas, experiencia y 
personalidades” 
-En un grupo cohesivo, los miembros piensan que el equipo es más 
importante que los individuos que lo integran. 
Los beneficios de crear un grupo cohesivo son: 
1- El grupo puede establecer sus propios estándares de 
calidad. 
2- Los individuos aprenden de los demás y se apoyan 
mutuamente. 
3- El conocimiento se comparte. 
4- Se alientan la refactorización y el mejoramiento continuo. 
 
Existen tres factores que afectan el trabajo en 
grupo: 
1- Las personas en el grupo: se necesita una 
combinación de personas para desarrollar un 
software en equipo. 
2- La organización grupal: el grupo debe 
organizarsede manera que los individuos puedan 
contribuir con sus habilidades 
3- Comunicación técnica y administrativa: es 
esencial una óptima comunicación entre el equipo 
de trabajo. 
 
La labor del administrador o líder de equipo es crear un grupo cohesivo y 
organizar a los miembros del grupo para que puedan trabajar en conjunto de 
manera efectiva. 
 
 
 
 
 
 
Esto implica crear un grupo con el equilibrio correcto de habilidades técnicas y 
personales, así como organizarlo para que los miembros trabajen 
adecuadamente en conjunto. 
 
 
 
 
 
En ocasiones se contrata a personas externas a la organización , aunque con 
mayor frecuencia, los grupos de ingeniería de software se componen de 
empleados actuales que tienen experiencia adquirida en otros proyectos. 
 
 
 
Los administradores pocas veces tienen absoluta libertad en la elección del 
equipo, con frecuencia deben recurrir a las personas que estén disponibles en la 
empresa, aunque no sean ideales para el puesto. 
 
La labor del administrador o líder de equipo es crear un grupo cohesivo y 
organizar a los miembros del grupo para que puedan trabajar en conjunto de 
manera efectiva. 
 
 
 
 
 
 
Esto implica crear un grupo con el equilibrio correcto de habilidades técnicas y 
personales, así como organizarlo para que los miembros trabajen adecuadamente 
en conjunto. 
 
 
 
 
 
En ocasiones se contrata a personas externas a ala organización , aunque con 
mayor frecuencia, los grupos de ingeniería de software se componen de 
empleados actuales que tienen experiencia adquirida en otros proyectos. 
 
 
 
Los administradores pocas veces tienen absoluta libertad en la elección del 
equipo, con frecuencia deben recurrir a las personas que estén disponibles en la 
empresa, aunque no sean ideales para el puesto. 
 
Un grupo con personalidades complementarias puede trabajar mejor que un 
grupo seleccionado exclusivamente por la habilidad técnica . 
 
 
 
 
 
 
Las personas que están motivadas por el trabajo son las más fuertes técnicamente . 
 
 
 
 
 
 
Las personas orientadas a sí mismas tal vez serán mejores para impulsar el 
trabajo hacia adelante para terminar la tarea. 
 
 
 
 
 
Las personas orientadas a la interacción ayudan a facilitar las 
comunicaciones dentro del grupo , debido a que les gusta hablar con los 
demás y son capaces de detectar tensiones y diferencias en etapas 
tempranas, antes que tengan serias repercusiones sobre el grupo. 
 
 
Composición de grupo . 
 
Al crear un grupo para el desarrollo de tecnología de apoyo, Alice está 
consciente de la importancia de seleccionar miembros con personalidades 
complementarias. cuando entrevista a miembros potenciales del grupo, trata de 
valorar si están orientados a las tareas, hacia sí mismos u orientados a la 
interacción. Ella siente que su personalidad está orientada hacia sí misma 
porque considera que el proyecto es una forma hacerse notar ante los altos 
ejecutivos y buscar una promoción. Por ende busca una o dos personalidades 
orientadas a la interacción e individuos orientados a las áreas para completar el 
equipo. La valoración final a la que llegó fue: 
 
Alice: orientada hacia sí misma . 
Brian. orientado tareas. 
Bob: orientado a tareas. 
Carol: orientada a la interacción. 
Ed: orientado a la interacción. 
Fred: orientado a tareas. 
En ocasiones es imposible elegir un grupo con personalidades complementarias , si 
es así el administrador del proyecto tiene que controlar el grupo de modo que las 
metas individuales no se antepongan a los objetivos de la organización y del grupo. 
 
 
 
 
 
 
Este control es más sencillo de lograr si todos los miembros del 
grupo, participan en cada etapa del proyecto. 
 
 
 
 
 
La iniciativa individual es más factible cuando los miembros del grupo reciben 
instrucciones sin estar al tanto de la parte que desempeña su tarea en el 
proyecto individual. 
 
La forma en que se organiza un grupo influye en: 
- Las decisiones que toma dicho grupo 
- Las maneras como se intercambia la información 
- Las interacciones entre el grupo de desarrollo y los participantes 
externos del proyecto. 
 
 
 
 
 
Las preguntas organizacionales importantes para los administradores del 
proyecto, incluyen: 
1 – ¿El administrador del proyecto debe ser el líder técnico del grupo? El líder 
técnico o arquitecto del sistema es el responsable de las decisiones técnicas 
críticas tomadas durante el desarrollo del software. Puede ser el administrador 
del proyecto o a veces un Ingeniero del proyecto con mucha experiencia. 
2- ¿Quién se encargará de tomar las decisiones técnicas y cómo se tomarán? 
¿Las decisiones las tomará e administrador del proyecto, el arquitecto del 
sistema o se llegará a un consenso entre un rango más amplio de miembros 
del equipo? 
3- ¿Cómo se manejarán las interacciones con los participantes externos y los 
altos directivos de la empresa? Generalmente el administrador del proyecto 
asistido por el arquitecto del sistema serán los encargados de realizar tal 
interacción. 
 
 
Las preguntas organizacionales importantes para los administradores del 
proyecto, incluyen: 
 
4- ¿Cómo es posible que los grupos logren integrar a personas que no se 
localizan en el mismo lugar? Con las TIC ahora se puede tener grupos de 
trabajo ubicados en diferentes lugares, y tomar decisiones grupales. 
5- ¿Cómo puede compartirse el conocimiento a través del grupo? 
La organización del grupo afecta el intercambio de información, 
pues determinadas formas de organización son mejores que otras 
para compartir información. 
 
 
 
 
Los grupos de programación pequeños por lo general, están organizados en una 
forma bastante informal. 
 
 
 
 
 
 
El líder del grupo participa en el desarrollo del software con los otros miembros 
del grupo. 
 
 
 
 
 
 
En un grupo informal, todo el equipo analiza el trabajo a realizar y las tareas se 
asignan según la habilidad y la experiencia. 
 
 
 
 
 
 
Los miembros del grupo con mayor jerarquía pueden ser responsables del diseño 
arquitectónico, no obstante el diseño y la implementación detallados son 
compromisos del equipo que se asigna a una tarea en particular. 
 
 
 
 
Los grupos informales pueden ser muy exitosos, en particular cuando la mayoría de 
los miembros del grupo son experimentados y competentes, en caso contrario la 
informalidad puede ser un obstáculo porque no existe autoridad definida para 
dirigir el trabajo. 
 
Los grupos jerárquicos son grupos que comparten una estructura jerárquica con 
el líder del grupo en la pate superior del escalafón. 
 
 
 
 
 
 
El líder tiene autoridad más formal que los miembros del grupo y así puede dirigir 
el trabajo. 
 
 
 
 
 
 
Existe una clara estructura organizacional y las decisiones se toman hacia la parte 
superior de la jerarquía y se aplican por las personas que están más abajo en la 
jerarquía . 
 
 
 
 
 
 
Las comunicaciones son instrucciones del personal ejecutivo y existe relativamente 
poca comunicación ascendente, es decir desde los niveles más bajos hacia los niveles 
superiores en la jerarquía. 
 
 
 
 
Este enfoque funciona bien cuando un problema puede descomponerse en 
subproblemas en los que las soluciones se desarrollan en diferentes partes de la 
jerarquía. 
 
Los grupos jerárquicos son pocos comunes en la ingeniería de software, debido 
a que: 
1- Los cambios al software requieren con frecuencia cambios en varias partes del 
sistema y esto conduce a una discusión y negociación en todos los niveles de la 
jerarquía. 
2- Las tecnologías de software cambian tan rápido que muchas veces el personal 
más joven conoce más la tecnología que el personal experimentado 
 
 
 
 
 
 
 
Las organizaciones grupales democráticas y jerárquicas no reconocen formalmente 
que pueden haber diferencias muy grandes de habilidad técnica entre los miembros 
del grupo.Tiene sentido aprovechar las capacidades de los mejores elementos en la forma 
más efectiva y brindarles tanto apoyo como sea posible . 
 
 
 
Uno de los primeros modelos que organizacionales que tenía la intención de 
trabajar de esta manera fue el denominado “Equipo Programador Jefe”. 
 
Es imprescindible que los miembros del grupo se comuniquen efectiva y 
eficientemente entre y con otras partes interesadas en el proyecto 
 
 
 
 
 
 
 
Los miembros del grupo deben intercambiar información acerca del estado de su 
trabajo y las decisiones que se tomaron 
 
 
 
 
 
 
Tienen que resolver los problemas que se resuelven e informar a los interesados 
sobre los cambios realizados. 
 
 
 
 
-La buena comunicación ayuda a fortalecer la cohesión del grupo. 
-Los miembros del grupo llegan a entender las motivaciones, fortalezas y 
debilidades de otras personas en el grupo. 
 
La efectividad y eficiencia de las comunicaciones están definidas por: 
 
1- Tamaño del grupo: conforme el grupo crece es más difícil la comunicación 
efectiva entre ellos. En N° de vínculos de comunicación de un canal es= n * (n-1), 
siendo n el tamaño del grupo. 
2 – Estructura del grupo: la organización informal posibilita una mejor 
comunicación que una organización jerárquica. Los integrantes de menor 
jerarquía difícilmente puedan comunicarse efectivamente con sus superiores. 
3- Composición del grupo: las personas con el mismo tipo de personalidad 
pueden chocar y como resultado las comunicaciones se inhiben. 
4 – El ambiente laboral físico: la organización del centro de trabajo es un factor 
importante para facilitar o inhibir las comunicaciones. 
5- Canales de comunicación disponibles: existen muchas formas diferentes de 
comunicación: cara a cara, correo electrónico, documentos formales teléfono, 
redes sociales y wikis. 
 
 
 
Los administradores de proyecto trabajan con escaso tiempo y se apoyan en 
reuniones y documentos formales para transmitir la información. 
 
 
 
 
 
 
 
Aunque tal vez éste sea un enfoque eficiente para la comunicación desde la 
preselectiva de un administrador de proyecto no es muy efectivo. 
 
 
 
 
 
 
La comunicación efectiva se logra cuando las comunicaciones son 
bidireccionales, las personas implicadas pueden discutir los conflictos y la 
información y establecer una comprensión común de las proposiciones y de los 
problemas. 
 
 
 
 
Esto se logra mediante reuniones, que suelen estar dominadas por las 
personalidades más poderosas.