c
 




 
 
Ê


i I. Proyectos
× Definición
× Gestión de proyectos
i II. Desarrollo de Software
× Problemática. 36 errores típicos
× 6 Mejores prácticas
Ê MA N
N 1

V
 Ê

¿QUÉ  UN V
 Ê


i £as organizaciones ejecutan trabajos, ya sea en

la forma de proyectos o de operaciones. Ambos
tienen en común:
× jecutados por personas
× Recursos restringidos
× Se planifican, ejecutan y controlan
i Se diferencian en:
× £as operaciones son continuas y repetitivas
× £os proyectos son únicos y temporales.
¿QUÉ  UN V
 Ê


Un proyecto es un esfuerzo temporal llevado a

cabo para crear un producto o servicio único.
Guía del V


 Vroject
anagement Institute

× Êemporal quiere decir que todo proyecto tiene un inicio y un

final definidos.
× nico quiere decir que el producto o servicio es diferente a
otros productos o servicios similares.
¿QUÉ  UN V
 Ê


× £os proyectos pueden ser ejecutados por 1

persona o por 10,000 personas.
× £os proyectos pueden tomar 100 horas o
10¶000,000 de horas.
× £os proyectos pueden involucrar a distintas áreas
de una organización.
¿QUÉ  UN V
 Ê


i jemplos de proyectos:
× Desarrollo de un nuevo producto o servicio
× £levar a cabo un cambio dentro de la organización
× Diseñar un nuevo vehículo de transporte
×
onstruir un edificio de viviendas.
× rganizar un congreso de estudiantes
× Desarrollar un software para el manejo de una
agencia bancaria
× Realizar un cambio organizacional
NÊU   Ê
V
  UN V
 Ê

i Êodo proyecto tiene un inicio y un fin.

i Se llega al fin cuando se cumplen los objetivos
del proyecto o cuando se determina que no se
pueden cumplir.
i Êemporal no quiere decir en un corto tiempo,
quiere decir que tiene una duración finita.
i £o temporal no aplica al servicio o producto
generado por el proyecto. jemplo: un
monumento nacional que será visitado por
muchos años.
V
UÊ


II
NI
I)
I)pp

i £os proyectos tienen que ver con hacer algo que

no se ha hecho antes, y por lo tanto es algo
único.
× Por ejemplo, la construcción de un edificio de oficinas
puede parecer repetitivo, pero para cada desarrollo
podemos tener un nuevo cliente, otro lugar, leyes
distintas, distinto contratista, etc..

i l hecho de ser único, requiere que las

características finales se van elaborando y
refinando poco a poco, mediante una buena
definición de los alcances
U V
 Ê

i £os proyectos se pueden dividir en componentes

más manejables, también llamados sub-
proyectos.
i £os sub-proyectos muchas veces se sub-
contratan a empresas externas o a otras
unidades funcionales en la organización
ejecutante.
ecursos del Vroyecto

m


m

 
 

 
 
  
ecursos del Vroyecto

V 




 
iderazgo del Vroyecto

i Necesidad del £iderazgo

× Dinámica cambiante del entorno
× Presiones de tiempo
×
omplejidad de los problemas
× Interacciones personales internas y externas
× Multiplicidad de factores intervinientes
iderazgo del Vroyecto

i Perfil del Gerente de Proyecto

× Visión integradora
×
apacidad conducción
× Planificador
× rganizador
×
apacidad determinar necesidades
× Negociador amplio
× Manejo de conflictos
×
apacidad técnica
× Motivador
0 c 

£    
    

 

 

       

    


 
      
  

   
        


Vroceso de Gestión del Vroyecto

£ 
  

  
      



V

  !
  
    " 

V

 V # "
   "   $ 


    $      
  

 
  $   

Vroceso de Gestión del Vroyecto

V

 

%     

& "
 
 
  
   
'  

 


   

V

     
   

  
  
 "  
   "  
ontexto de la Gestión del Vroyecto
structura enfocada a proyectos
à
     



i £os niveles de coste y RRHH son bajos al comienzo,

creciendo hasta el final del proyecto y cayendo
rápidamente en la conclusión del mismo.
i £a probabilidad de terminar con éxito el proyecto es
pequeña, con riesgos eincertidumbres, al comienzo.
i £a capacidad de los gestores para variar las características
del proyecto es mayor al principio, viéndose disminuida
según va avanzando el proyecto.
i l coste de los cambios y la corrección de posibles errores
es mayor según va progresando el proyecto.
Vroyecto exitoso

i
uando finaliza
× en el tiempo previsto
× cumpliendo el presupuesto
× con los resultados y especificaciones esperadas
× con la aceptación del cliente
× nos permite usar al cliente como referencia
× sin perturbar el flujo de trabajo de la organización
× sin conflictos con la cultura de la organización
¿QUÉ  G ÊIÓN  V
 Ê


s la aplicación de conocimientos, habilidades,

herramientas y técnicas a las actividades de un
proyecto para satisfacer los requisitos del
proyecto.
Guía del V


 Vroject
anagement Institute
Interfase de Gestión

i Relaciones humanas en la rganización del Proyecto

i Balance entre las funciones técnicas y de administración
i nfrentar los riesgos asociados al proyecto
i Superar las limitaciones de la rganización
Vrocesos en la Gestión de Vroyectos

Iniciación
Planeamiento

Control Ejecución

Cierre
¿QUÉ  G ÊIÓN  V
 Ê


i £a gestión de un proyecto incluye:

× Identificar los requisitos
× stablecer unos objetivos claros y posibles de realizar
× quilibrar las demandas concurrentes de calidad,
alcance, tiempo y costos.
× Adaptar las especificaciones, los planes y el enfoque a
las diversas inquietudes y expectativas de los diferentes
interesados.
¿QUÉ  G ÊIÓN  V
 Ê


i l conocimiento sobre gestión de Proyectos puede

organizarse en muchas maneras.
i l documento PMB está organizado en tres
grandes secciones:
× l Marco
onceptual de la Dirección de
Proyectos
× Norma para la Dirección de Proyectos de un
proyecto.
× £as Áreas de conocimiento de la Dirección de
Proyectos
Vroject
anagement Institute

i ´undado en 1969 por cinco miembros en Pennsylvania,

con el propósito de difundir las prácticas de Project
Management
i Durante 1980 se llevó a cabo el primer exámen para la
certificación PMP (Project Management Profesional) que
actualmente posee reconocimiento IS.
i n 1990 publicó los primeros estándares en PM: >

   
     



i Hoy circulan en el mundo más de 250000 copias
i Posee más de 100000 asociados en 125 paises
i Han certificado como PMPUs más de 10000 miembros
   
N
I
I NÊ
  G ÊIÓN  V
 Ê

á 
V á  


Gestión
de
Proyectos

Visión
Alcance
Integral

Tiempos Costos Calidad

mecursos Comunicación miesgos Adquisiciones

Humanos
á 
V á  


V

! 


(
   V   $    

#
 

"


 !









m 









m


ù



 IÓN I:
arco onceptual de la Gestión de Vroyectos

i Proporciona una estructura básica para entender

la dirección de proyectos.
× l apítulo 1, Introducción, define los
términos clave y proporciona una descripción
general del resto de la Guía del PMB.
× l apítulo ,
iclo de Vida del Proyecto y
rganización describe el entorno en el cual
operan los proyectos. l equipo de dirección
del proyecto debe comprender este amplio
contexto.
ección II: Norma para la Gestión de Vroyectos

i specifica todos los procesos de dirección de

proyectos que usa el equipo del proyecto para
gestionar un proyecto.
× l apítulo 3, describe los cinco Grupos de
Procesos de Dirección de Proyectos aplicables a
cualquier proyecto y los procesos de dirección
de proyectos que componen tales grupos.
× ste capítulo describe la naturaleza
multidimensional de la dirección de proyectos.
ección III: Áreas de onocimiento de la Gestión de
Vroyectos

i rganiza los 44 procesos de dirección de

proyectos de los Grupos de Procesos de Dirección
de Proyectos del
apítulo 3 en nueve Áreas de

onocimiento.
i £a introducción de la Sección III describe la
leyenda de los diagramas de flujo de procesos
que se usan en cada capítulo de Área de

onocimiento y en la introducción de todas las
Áreas de conocimiento.
ección III: Áreas de onocimiento de la Gestión de
Vroyectos

i l apítulo , Gestión de la Integración del Proyecto,

describe los procesos y actividades que forman parte de los
diversos elementos de la dirección de proyectos.
i l apítulo 5, Gestión del Alcance del Proyecto, describe
los procesos necesarios para asegurarse de que el proyecto
incluya todo el trabajo requerido, y sólo el trabajo
requerido, para completar el proyecto satisfactoriamente.
i l apítulo 6, Gestión del Êiempo del Proyecto, describe
los procesos relativos a la puntualidad en la conclusión del
proyecto.
i l apítulo 7, Gestión de los
ostes del Proyecto, describe
los procesos involucrados en la planificación, estimación,
presupuesto y control de costes de forma que el proyecto
se complete dentro del presupuesto aprobado.
ección III: Áreas de onocimiento de la Gestión de
Vroyectos

i l apítulo 8, Gestión de la
alidad del Proyecto, describe

los procesos necesarios para asegurarse de que el proyecto
cumpla con los objetivos por los cuales ha sido emprendido.
i l apítulo 9, Gestión de los Recursos Humanos del
Proyecto, describe los procesos que organizan y dirigen el
equipo del proyecto.
i l apítulo 1, Gestión de las
omunicaciones del
Proyecto, describe los procesos relacionados con la
generación, recogida, distribución, almacenamiento y
destino final de la información del proyecto en tiempo y
forma.
i l apítulo 11, Gestión de los Riesgos del Proyecto,
describe los procesos relacionados con el desarrollo de la
gestión de riesgos de un proyecto.
ección III: Áreas de onocimiento de la Gestión de
Vroyectos

i l apítulo 1, Gestión de las Adquisiciones del Proyecto,

describe los procesos para comprar o adquirir productos,
servicios o resultados, así como para contratar procesos de
dirección.
 Ê MA N
N 2

D SARR££ D S´Ê
AR :
£os 36 errores clásicos del
desarrollo del software
Ê
ÊI 
  

 

31% de los proyectos son cancelados

antes de completarse.

53% de los proyectos cuestan 190% del

costo estimado.

n las grandes empresas el costo se

desvía aprox. un 9%.

n las PYM S el costo se desvía aprox.

un 16%.
INÊ
GNÊ  N   

 

0Por qué se consume tanto 0Por qué no se identifican

tiempo en culminar los todos los errores del
sistemas informáticos? software antes de
entregarlo al cliente?

0Por qué es tan

elevado el costo de 0Por qué es tan difícil medir
los proyectos de el avance del desarrollo del
sistemas? software?

¿os usuarios finales están totalmente satisfechos

con los sistemas informáticos que utilizan
36
 ÁI


i Êipos:
× De la Gente
× Del Proceso
× Del Producto
× De la tecnología
G NÊ

i Baja motivación
i Personal débil
× Débil vs. Junior
i mpleados problemáticos no controlados
i Héroes
i Agregar gente a un proyecto atrasado
G NÊ

i Ruido, hacinamiento
i Roces con el cliente
i xpectativas no realistas
i Politización
i Soñadores
G NÊ

i ´alta de auspiciadores efectivos

i ´alta de Stakeholders interesados
i No tener el punto de vista del usuario
V
 

i Schedule optimista
i Manejo insuficiente del riesgo
i ´alla de proveedores
i Planeamiento Insuficiente
i Planes que ceden a la presión
V
 

i Êiempo desperdiciado al inicio

i Actividades fundamentales acortadas
i Diseño inadecuado
i Aseguramiento de la calidad recortado
V
 

i
ontrol insuficiente
i
onvergencia frecuente o prematura
i misión de tareas al estimar
i Planear recuperarse ³después´
i Programación ³
ode-like-hell´ (Ir directo a
codificar)
V
UÊ

i xceso en los requerimientos

i Plantear demasiados objetivos a la vez
i Desarrolladores ³dorados´ (fascinación por los
avances tecnológicos)
i Mala Negociación
i Desarrollo investigativo
Ê N

GI

i Síndrome de la Panacea
i Sobre-estimación de ahorros por nuevas
herramientas
×
apricho
× Snobismo
i
ambio de herramientas a mitad del proyecto
i ´alta de control de fuentes
 Ê MA N
N 2

D SARR££ D
S´Ê
AR :
£as 6 mejores prácticas
 6

 V ÁÊI



   



   !

 à 
à

à
 à

1.  
 
Ê IÊ ÊI

NÊ


   



   !

 à  à

à
 à

i
ada iteración resulta en un release ejecutable

 
 !
  
" 
  
  # 
 

#

$
#
1.  
 
Ê IÊ ÊI

NÊ

i £os desentendimientos importantes se evidencian

tempranamente
i Se alienta el feedback del usuario
i ´ocalización en los temas más críticos, sin
distracciones
i Êesting continuo e iterativo: evaluación objetiva
i Inconsistencias entre requerimientos, diseños e
implementaciones se detectan tempranamente
1.  
 
Ê IÊ ÊI

NÊ

i
arga de trabajo mejor repartida en el tiempo

i l equipo puede analizar las lecciones aprendidas
en las primeras iteraciones
i Integración progresiva en lugar de Big Bang
i videncias concretas a los sponsors
i Se facilita la reutilización
i Arquitectura más robusta
. 
INIÊ  
 QU I
I NÊ



   



   !

 à  à

à
 à

i Requirements Management, enfoque sistemático

que involucra:
× btener, organizar y documentar la funcionalidad y
restricciones requeridas a un sistema
× Analizar los cambios solicitados y evaluar impactos
× Registrar y documentar las alternativas y decisiones
tomadas
. 
INIÊ  
 QU I
I NÊ


i £os requerimientos pueden ser adecuadamente

capturados y comunicados a través de
asos de
Uso
i £os
asos de Uso son importantes instrumentos
de planificación
áppàpp

os asos de Uso direccionan

el trabajo desde el análisis $%
&  % "
hasta el test

ápp 
ápp
 
 ápp
. 
INIÊ  
 QU I
I NÊ


i £as comunicaciones están basadas en

requerimientos bien definidos
i £os requerimientos pueden ser priorizados,
filtrados y monitoreados
i s posible realizar evaluaciones objetivas acerca
del éxito de un proyecto
i £as inconsistencias se detectan fácilmente
i
on herramientas adecuadas: repositorio de
requerimientos, con atributos y relaciones
¿ómo son interpretados los requerimientos

Y

 



 

0à"#"
$
¿ómo son interpretados los requerimientos

0à"" 0à"  0à" !

%&$ $ &'$
¿ómo son interpretados los requerimientos

0à"  0à"  0à" 

($ $ $
¿ómo son interpretados los requerimientos

0à"  0 * 0 *)

)$ )"$ $

?
 
  
3. UÊII  QUIÊ ÊU   N 

V
N NÊ 


   



   !

 à  à

à
 à

i £a Arquitectura de Software representa el

conjunto de decisiones significativas sobre la
organización de un sistema de software
× Selección de los elementos estructurales, y sus
interfaces, por los cuales el sistema está compuesto
×
omportamiento, especificado como colaboraciones
entre los elementos
×
omposición en subsistemas de los elementos
estructurales y de comportamiento
× stilo de arquitectura que guía a la organización
3. UÊII  QUIÊ ÊU   N 

V
N NÊ 

i Un componente de software puede definirse

como una pieza no trivial de software, un módulo
o un subsistema que completa una función clara,
tiene límites claros y puede ser integrado en una
arquitectura bien definida

"

*

R 
pp )(
 p

  

'

'
%(
3. UÊII  QUIÊ ÊU   N 

V
N NÊ 

i Definir arquitecturas muy modulares e identificar, aislar,

diseñar, desarrollar y probar componentes bien formados
i Desarrollar componentes para ser reutilizados. ´ormar la
base de reuso de la organización
i Industria de infraestructura de componentes
×
M+ - Microsoft
omponent bject Model
×
RBA -
ommon bject Request Broker Architecture - MG
× JavaBeans - SUN
× Assemblys .N Ê
× Servicios
eb
 .

  
Ê
IU
NÊ


   



   !

 à  à

à
 à

#

a
odelización


isual eleva el nivel

de abstracción
*
 N II


i £os casos de uso permiten especificar comportamiento sin

ambigüedades
i Quedan expuestas las arquitecturas inflexibles o no
modulares
i l diseño refleja sus inconsistencias más rápidamente
i xisten herramientas que proveen soporte para la
modelización visual


pp


**

+
5.
I I  I   
Ê


   



   !

 à  à

à
 à

i £a actividad fundamental de esta práctica es el testing

i valuar continuamente la calidad de un sistema con
respecto a funcionalidad, confiabilidad, performance

ncontrar y reparar un à 

problema de software después
de la implementación puede
resultar de 1 a 1 veces
más costoso
ppppppppppppppppppppppp
 

 N II


i £a evaluación del estado del proyecto es objetiva,

se evalúan resultados de test.
i Se exponen inconsistencias en requerimientos,
diseños e implementaciones
i Se focaliza en las áreas de riesgo más alto
i £os defectos se identifican en forma temprana
i xisten herramientas automatizadas para el
testing de funcionalidad, confiabilidad y
performance
6. 
NÊ
 
 
I
  
Ê


   



   !

 à  à

à
 à

‘





 









 
 



 




 

  


 


 
6. 
NÊ
 
 
I
  
Ê

i
ontrolar, registrar y monitorear los cambios

para posibilitar el desarrollo iterativo
i stablecer ³workspaces´ seguros para cada
desarrollador
i Automatizar la integración y la administración de
construcciones.
 N II


i £as solicitudes de cambios formales facilitan la

claridad de comunicación
i £os espacios de trabajo aislados reducen la
interferencia entre los miembros del equipo que
trabajan en paralelo
i £as estadísticas de cantidad de cambios proveen
buenas métricas para evaluar objetivamente el
estado del proyecto
i £a propagación del cambio es evaluable y
controlable
i £os cambios pueden ser mantenidos en sistemas
automáticos