Gestión de

Proyectos
I N G E N IE R Í A D E S O F T WA R E I I
 Gestión de Proyectos

Aplicación de conocimientos, habilidades, herramientas y técnicas a las

actividades de un proyecto, para satisfacer los requisitos (las necesidades y
expectativas) de un proyecto.

Disciplina en sí misma

Incluye:
◦ Identificar requisitos
◦ Establecer objetivos claros y factibles
◦ Equilibrar demandas del cliente, alcance, tiempo y costos
◦ Considerar expectativas de stakeholders

2
 Stakeholders
(accionistas o interesados)

Personas u organizaciones que:

◦ están activamente involucrados en el proyecto
◦ o sus intereses pueden ser afectados positiva o negativamente por la ejecución o el
éxito del proyecto.

Tiene diferentes intereses que pueden estar en conflicto.

3
 Alcance
Alcance del producto (final):
◦ sus características
◦ Se mide contra requerimientos.

Alcance del proyecto:

◦ trabajos incluidos (y no)
◦ Se mide contra el plan.

4
 Alcance y Expectativas

Necesidades
Expectativas Calidad
Balancear
Alcance

Restricciones
Necesidades
Expectativas

Proceso
5
 Relación con otras disciplinas
Administración General
Comprende planificar, organizar, asignar personal, ejecutar y controlar las
operaciones de una empresa de operación continua

Áreas de Aplicación
Categorías de proyectos donde hay prácticas generalmente aceptadas que no
aplican a todo tipo de proyectos.
Definidas por:
◦ Elementos Técnicos
(Pe. desarrollo de SW)
◦ Elementos Administrativos
(Pe. licitaciones públicas)
◦ Ramas de la Industria
(Pe. automotriz)
6
Áreas de Aplicación

Gestión de
Proyectos

Administración Áreas de
General Aplicación
 Áreas de experiencia
Fundamentos de Dirección de Proyectos
Conocimiento del área de aplicación
Comprensión del entorno del proyecto:
◦ cultural y social
◦ internacional y político
◦ físico
Habilidades de dirección general
Habilidades interpersonales

8
 Habilidades interpersonales
Comunicación efectiva
Influencia en la organización
Liderazgo
Motivación
Negociación y gestión de conflictos
Resolución de problemas

9
 Aspectos clave
La naturaleza intangible del SW causa problemas de gestión.
Las principales actividades de los gestores se centran en:
◦ Panificación
◦ Estimación
◦ Control y Seguimiento

10
 Procesos y actividades de la Administración

El trabajo del administrador varía de acuerdo a la organización y al

producto de software a ser desarrollado, por lo que es imposible una
descripción de trabajo estándar, sin embargo algunos de los aspectos a
considerar se describen a continuación.
Procesos y actividades de la Administración

Actividades de responsabilidad de un administrador de software son:

Redacción de propuestas de desarrollo
◦ Objetivos del proyecto y cómo se va a desarrollar
◦ Incluye estimaciones de coste, tiempo, asignación a equipos,...

Planificación y calendario del proyecto: identificación de actividades,

hitos y entregas del proyecto
Estimación económica del proyecto
Procesos y actividades de la Administración

Supervisión y revisión del proyecto

◦ Actividad continua
◦ Conocimiento del progreso
◦ Comparación de progreso y coste con lo planificado
◦ Mecanismos formales e informales
Selección y evaluación del personal
Redacción y presentación de informes
◦ Informes para el cliente, organizaciones contratantes e internos
◦ Documentos concisos y coherentes
◦ Presentaciones en las revisiones de progreso
◦ Administrador: necesidad de comunicación efectiva oral y escrita
 Grupo de Procesos Procesos
Modelado del ciclo de • Selección de un modelo de ciclo de vida
vida
Administración del o Inicio del proyecto
proyecto o Supervisión y control del proyecto
o Administración de la calidad del software
Pre-desarrollo • Exploración de conceptos
• Asignación del sistema
Desarrollo o Análisis: Se hacen modelos del sistema y
o establecen requerimientos.
o Diseño: Se separa el sistema en componentes.
o Codificación: Codificación de cada componente.
Pos-desarrollo • Instalación
• Operación y soporte
• Mantenimiento
• Retiro
Procesos integrados o Verificación y validación
o Administración de la configuración del software.
o Desarrollo de la documentación
o Entrenamiento
Funciones del Administrador
La administración puede verse como un proceso. Según Fayol,
está compuesto por funciones básicas:
PLANIFICACION: procedimiento para establecer objetivos y un
curso de acción adecuado para lograrlos.
ORGANIZACION: proceso para comprometer a dos o más
personas que trabajan juntas de manera estructurada, con el
propósito de alcanzar una meta o una serie de metas
específicas.
Funciones del Administrador
DIRECCIÓN: función que consiste en dirigir e influir en las
actividades de los miembros de un grupo o una organización
entera, con respecto a una tarea.
COORDINACIÓN: integración de las actividades de partes
independientes de una organización con el objetivo de
alcanzar las metas seleccionadas.
CONTROL: proceso para asegurar que las actividades reales se
ajusten a las planificadas.
Elementos que debe Coordinar el Administrador de
Proyecto de Software
Los administradores de software son responsables de la
planificación y temporalización del desarrollo de los proyectos.

◦ Supervisan el trabajo asegurando que se lleve a cabo conforme

a los estándares requeridos.
◦ Supervisan el progreso comprobando que el desarrollo se
ajusta el tiempo previsto y al presupuesto.

La administración es necesaria debido a que la Ingeniería de

Software siempre esta sujeta a restricciones organizacionales de
tiempo y presupuesto.
Elementos que debe Coordinar el Administrador
de Proyecto de Software

Elementos:
Equipos . Participantes que trabajan en un problema común.
Roles. Responsabilidades.
Productos de trabajo. Productos finales e intermedios a entregar de un
proyecto (resultados visibles).
Tareas. Son el resultado de separar el trabajo en función de pasos
secuenciales para generar uno o más productos.
Calendarios . Correspondencia entre un modelo de tareas y una línea de
tiempo.
Dificultades en la Administración
Los administradores de software hacen el mismo tipo de
trabajo que otros administradores, pero existen diferentes
aspectos los que lo hace difícil.

El producto es intangible:
◦ No se puede ver ni tocar.
◦ Los administradores no pueden ver el progreso.
◦ Confían en otros para elaborar la documentación.
Dificultades en la Administración
No existen procesos del software estándar.
◦ Los procesos de software varían de una organización a otra.

Los proyectos grandes son únicos.

◦ Los proyectos grandes son diferentes a proyectos previos.
◦ Aunque se cuente con experiencia no es suficiente para anticipar los
problemas.
◦ Los cambios tecnológicos y comunicaciones hacen parecer obsoleta la
experiencia previa.
Una gestión eficaz se centra en 4P’s
1. PERSONAL
El factor humano siempre será el más importante en el desarrollo de
soluciones software, muchos empresarios famosos, líderes de empresas
tecnológicas, coinciden que el éxito que han alcanzado sus empresas no
se debe a las herramientas que utilizan, es la gente y el trabajo en
equipo.
4P’s del Administrador de Proyectos de Software

2. PRODUCTO
Muchas veces cuando un cliente pide que le construyan una
solución, siempre pregunta. ¿Cuánto me va a costar? Pues
bien, todo producto requiere:
◦ Estimaciones cuantitativas y una adecuada planificación.
◦ Una adecuada recolección de información y un análisis detallado
de los requerimientos.
Con una buena planificación se puede estimar el tiempo que
tomará desarrollar o construir el producto y redimensionar el
valor cuantitativo del producto.
 4P’s del Administrador de Proyectos de Software

3. PROCESO
Proporciona un marco de trabajo desde el cual se puede
establecer un plan detallado para la construcción del software.
El gestor del proyecto debe elegir el modelo de procesos
adecuado para ser aplicado para:
◦ Los clientes que han solicitado el producto y el personal que hará el
trabajo.
◦ Las características del producto.
◦ El ambiente del proyecto en el que trabaja el equipo de desarrollo del
software.
4P’s del Administrador de Proyectos de Software

4. PROYECTO
Cuando se gestiona un proyecto exitoso, es necesario
entender que este puede llegar a fracasar. Según John Reel,
existen 10 razones :
1. El personal de software no entiende las necesidades del cliente.
2. El ámbito del producto está mal definido.
3. Los cambios se gestionan mal.
4. La tecnología elegida cambia.
5. Las necesidades comerciales cambian.
4P’s del Administrador de Proyectos de
Software

6. Los plazos de entrega no son realistas.

7. Los usuarios se resisten a la utilización del software.
8. Se pierde el patrocinio.
9. El equipo del proyecto carece de personal con las habilidades apropiadas.
10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.

Para tener éxito es necesario comenzar con pie derecho, esto se lo logra trabajando
duro para entender el problema y dar una solución adecuada.
Creación del Plan de
Proyecto
Creación del Plan de Proyecto
• Finalidad: ser conscientes de que antes de iniciar la
ejecución del proyecto es necesario haber creado la
versión inicial del Plan, y que dicho Plan es la herramienta
para la gestión del mismo a lo largo de su ciclo de vida.

. Componentes del Plan de Proyecto

• Definición del ámbito del Proyecto, y gestión de
expectativas y requerimientos
• . Gestión Riesgos
• Gestión Calidad
• Gestión Planificación
• Gestión Equipo Trabajo
• Gestión Comunicaiones
• Gestión Económíca
 Componentes del Plan de Proyecto

• El Plan de Proyecto es un conjunto de planes para cada elemento a gestionar,

controlados cada uno bajo su propio “versionado”, cada plan tiene anexados
un conjunto de documentos que demuestran la aplicación del mismo.

Contrato Comunica-
ciones

Finanzas Riesgo

Calidad Alcance

Recursos
Planificación
 Definición del ámbito del Proyecto

• Determinar la dimensión de los tres ejes que definen el objetivo de un

proyecto. Se debe tomar como punto de partida el contrato con el
Cliente (si existe), o en su defecto el acta de la reunión de
lanzamiento/aprobación del proyecto.

• Han de quedar perfectamente identificados COSTE

los objetivos de negocio que han decidido la
realización de dicho proyecto:
OBJETIVO
– Expectativas y Requisitos del cliente
– Fecha límite de implantación asociada a motivos
de negocio. TIEMPO
– Presupuesto aprobado para este proyecto. REQUISITOS

• Sobre todo, objetivos que no son misión de este

proyecto su consecución
 Creación del Plan de Proyecto
Ámbito del proyecto

• Ejemplos:
• OBJETIVOS de negocio para realizar el proyecto
– Obtener una solución orientada única y exclusivamente a los requisitos
del “cliente”
– Facilitar el acceso a la información
– Unificar y racionalizar la información
– Mejorar el rendimiento del sistema
• NO son Objetivos
– Modelo de datos y acceso a ala información muy costoso
– No estandarización de los procesos
 Creación del Plan de Proyecto
Gestión Expectativas

• Quien tiene la única visión válida de si un proyecto ha sido exitoso o no, es el

“cliente/s destinatario/s” (muchas veces no coincide con el usuario final)
• En consecuencia, es fundamental que el Gestor del Proyecto tenga
explicitadas, dentro de lo posible, las expectativas del “cliente/s”.
• Para ello debería ser posible el crear una matriz donde:
– Definir cada expectativa en términos de negocio del “cliente”
– Identificar la prioridad de su cumplimiento
– Identificar el parámetro objetivamente medible que indica el valor actual,
el valor objetivo, así como cuando se prevé obtener dicho valor
– Medir periódicamente el valor de dicho parámetro
– Definir acciones/responsables asociados al seguimiento de dichas
expectativas
Creación del Plan de Proyecto

Gestión Requerimientos

• Recoger de una manera formal los requerimientos del cliente que conforman
el objeto del proyecto, así como cuales han sido los cambios posteriormente
solicitados y aprobados de estos requerimientos originales, son la base que
facilita una gestión exitosa.
 Creación del Plan de Proyecto
Gestión Riesgos

• Definiciones
– Riesgo
• Un posible evento futuro que, si ocurre, puede provocar resultados inesperados.
– Riesgos del Proyecto
• Efecto acumulado de los sucesos con resultado incierto que afectan
negativamente a los objetivos del proyecto.
– Gestión del riesgo
• Conjunto de actividades realizadas para la identificación, análisis y control de los
riesgos de un proyecto.
 Creación del Plan de Proyecto
Gestión Equipo Trabajo

• Este capítulo del Plan de Trabajo se encontrará condicionado por la política de RR.HH. que
impere en la empresa. No obstante, en mayor o menor medida, será indispensable detallar
los siguientes aspectos del proyecto:

Definición de Roles y
Roles y Responsabilidades
Responsabilidades ‘Organizational Breakdown
Structure’

Plan de Recursos (Personas)

Requerimientos Relación de Conocimientos
de Plantilla Plan de Desarrollo del Equipo
Plan de Reconocimiento

Plan de Reasignación/
Infraestructura Adquisición de Recursos
 Creación del Plan de Proyecto
Componentes - Gestión Comunicaciones

TRABAJO EN GRUPO - elementos de un plan de comunicación

Roles de un Proyecto de
Software.
¿Qué es un Rol?
Función que una persona desempeña en un lugar o en una situación.
Importancia del rol
El hecho de que en un grupo de desarrollo no se tengan claro los roles
y sus responsabilidades y actividades asociadas, hace que se
produzcan problemas.
Roles en el desarrollo de
Software
Los Roles que tenemos en el desarrollo de un
proyecto de software.
Administrador de proyecto, Analista, Diseñador, Programador, Tester,
Asegurador de calidad, Administrador de Desarrollo, Documentador,
Ingeniero de manutención, Ingeniero de validación y verificación,
Administrador de la configuración, Clientes
Estimación de
Recursos
 Introducción
Los administradores del proyecto son responsables de
controlar el presupuesto.
Deben estimar cuanto va costar el desarrollo de
software o parte de ese desarrollo.
Esta actividad es llevada a cabo con la calendarización
del proyecto. Los principales componentes del costo en
un proyecto son:
◦ Costos de Hardware
◦ Costos de viajes y entrenamiento
◦ Costo de esfuerzo (pago a los ingenieros de sistemas)
De estos el costo dominante es el costo del esfuerzo
La relación entre el costo del
proyecto y el precio
La relación entre el costo del proyecto y el precio no es simplemente el
costo estimado más una utilidad, sino que debe considerar el alcance
de la organización, su economía, política y el negocio.
El costo del proyecto es una actividad continua desde la etapa que se
hace la propuesta hasta todo el ciclo de vida del proyecto
Formas de realizar la estimación del
costo
Bohem existen 7 diferentes formas:
1. Modelo de costos algorítmico:
2. Juicio experto
3. Estimación por analogía:
4. Ley de parkinson
5. Precio ganador
6. Estimación Top-Down
7. Estimación Buttom – Up
Estimación de costos
Modelo de costos algorítmico
◦ Se desarrolla un modelo usando información de
costos históricos que están relacionados con alguna
métrica de software (generalmente su tamaño) del
costo del proyecto. Se hace un estimado para que
esa métrica y el modelo calcule el esfuerzo
requerido.
Juicio experto
◦ uno o varios expertos en técnicas de desarrollo de
software son consultados. Cada uno estima el costo
del proyecto y el costo final estimado es alcanzado
por consenso.
Estimación de costos
Estimación por analogía:
◦ Esta técnica es aplicable con otros proyectos en el mismo
dominio de aplicación han sido completados. El costo de un
nuevo proyecto es estimado por analogía con estos proyecto
completos.

Ley de parkinson: El trabajo se extiende hasta tomar el

tiempo disponible. Lo que significa que el costo de
software está dado por los recursos disponibles en
lugar del logro o aseguramiento de objetivos.
Estimación de costos
Precio ganador:
◦ El costo de software es estimado de acuerdo a la
disponibilidad de presupuesto del cliente y no sobre la
base de su funcionalidad.
Estimación Top-Down:
◦ Un costo es estimado considerando la funcionalidad total
del producto y como esa funcionalidad es provista por la
interacción de subfunciones. La estimación de costos es
hecha sobre la base de funciones lógicas en lugar de los
componentes que implementan la función
Estimación de costos
Estimación Bottom – Up:
◦ El costo de cada componente es estimado. Todos estos
costos son añadidos para producir un estimado final.
Cada técnica tiene sus ventajas y desventajas. Lo
más importante es que no existe una técnica mejor
o pero que otra.
Para grandes proyecto varias técnicas pueden ser
usadas en paralelo y comparar sus resultados
Factores que afectan la asignación de precios al software

Oportunidad Una organización de desarrollo podría

de mercado cotizar un bajo precio debido a que desea
moverse a un nuevo mercado de software.
Aceptar un bajo beneficio en un proyecto
podría darle la oportunidad de obtener mas
beneficios posteriormente.
Incertidumbre Si una organización esta insegura de
en la su costo estimado, por alguna
estimación contingencia puede incrementar su
de costos precio por encima del beneficio
normal.
Términos Un cliente puede estar dispuesto a
contractuales permitir que el desarrollador retenga la
propiedad del código y que reutilice
dicho código en otros proyectos.
El precio cargado podría ser menor que
cuando el código fuente del software es
entregado al cliente

Volatilidad de Si es probable que los requerimientos

los cambien, una organización puede
reducir los precios para ganar un
requerimientos
contrato después de que el contrato se
asigna, se cargan precios altos a los
cambios en los requerimientos.
Salud Los desarrolladores en
financiera dificultades financieras podría
bajar sus precios para
obtener un contrato.
Es mejor tener beneficios
más bajos que los normales o
incluso quebrar antes que
quedar fuera de los negocios.
Productividad
Medidas relacionadas con el tamaño:
◦ Estas se relacionan con el tamaño de alguna salida de una
actividad, y la más común es la relacionada con las líneas
de código fuente entregadas
Medidas relacionadas con la función.
◦ Estas se relacionan con la funcionalidad total del software
entregado.
◦ La productividad se expresa en términos de la cantidad
de funcionalidad útil producida en un tiempo dato.
◦ Los puntos de función y los puntos de objeto son las
medidas mas conocidas es este tipo.
Productividad
Existen muchos tipos de medidas y una alternativa a las
líneas de código es el conteo de puntos de función,
propuesto por Albrecht(1979) y refinado en 1983.
Los puntos de función son independientes del lenguaje
por lo que se puede comparar la productividad en los
diferentes lenguajes de programación.
La productividad se expresa en función de Número de
Puntos de Función producidos por Personas Mes.
Puntos de función
Cada punto de función es una combinación de
características del programa y el número total de
esto se calcula midiendo las siguientes
características del programa.
◦ Elementos de Entradas
◦ Elementos de Salidas externas.
◦ Interacciones con el usuario (peticiones)
◦ Interfaces externas
◦ Archivos utilizados por el sistema
 Valores de los puntos de función
Parámetros de medición Factor de ponderación
Cuenta Simple Medio Complejo
Número de entradas Usr. x 3 4 6 =
Número de salidas de Usr x 4 5 7 =
Número de peticiones Usr x 3 4 6 =
Número de archivos x 7 10 15 =
Núm. de interfaces externas x 5 7 10 =
Cuenta Total (UFP)

El conteo de los puntos de función no ajustados (UFP) se

calcula multiplicando los conteos por el peso (Factor de
ponderación) estimado y sumando todos lo valores.
UFP = (número de elementos de algún tipo dado) * peso
Ejemplo:
Estimaciones del Factor de
número de PF ponderación medio

Valor de dominio de Optim Proba Pesimi Cuenta Peso Cuenta

información ista ble sta estimada PF
Nro de PF

Número de entradas Usr 20 24 30 24 4 96

Número de salidas de Usr 12 15 22 16 5 80
Número de peticiones Usr 16 22 28 22 4 88
Número de archivos 4 4 5 4 10 40
Núm. de interfaces externas 2 3 3 2 7 14
Cuenta Total (UFP) 318
Y luego este valor es reajustado por factores que se basan en la complejidad
total del proyecto. Para lo que se toma en cuenta:
◦ Grado de procesamiento distribuido
◦ La cantidad de reutilización,
◦ El desempeño
◦ Etc.

PF = UCF x [0,65 + 0,01 x (Fi)]

Fi (i=1 a 14) son valores de ajuste de la complejidad según las respuestas a las
siguientes 14 preguntas:
Factores técnicos para calcular PF
1. ¿ Requiere el sistema copias de seguridad y de recuperación fiables
?
2. ¿ Se requiere comunicación de datos ?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿ Es crítico el rendimiento?
5. ¿ Se ejecutará el sistema en un entorno operativo existente y
fuertemente utilizado?
Factores técnicos para calcular PF
6. ¿ Requiere el sistema entrada de datos interactiva?
7. ¿ Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre
múltiples pantallas u operaciones?
8. ¿ Se actualizan los archivos maestros de forma
interactiva?
9. ¿ Son complejas las entradas, las salidas, los
archivos o las peticiones?
10. ¿ Es complejo el procesamiento interno?
Factores técnicos para calcular PF
11. ¿ Se ha diseñado el código para ser reutilizable?
12. ¿ Están incluidas en el diseño la conversión y la
instalación?
13. ¿ Se ha diseñado el sistema para soportar
múltiples instalaciones en diferentes
organizaciones?
14. ¿ Se ha diseñado la aplicación para facilitar los
cambios y para ser fácilmente utilizada por el
usuario ?
Factores técnicos para calcular PF
Cada una de las preguntas anteriores es respondida
usando una escala con rangos desde 0 a 5:

0 5
No importante absolutamente esencial
sin influencia fuerte influencia

Una vez hecho esto se usa de forma complementaria

las LDC, para normalizar medidas de productividad,
calidad y otros atributos del software.
 Luego se estiman cada uno de los factores técnicos
de la complejidad:
1. ¿ Copias de seguridad y de recuperación fiables ? 4
2. ¿ Se requiere comunicación de datos? 2
3. ¿ Existen funciones de procesamiento distribuido? 0
4. ¿ Es crítico el rendimiento? 4
5. ¿ Entorno operativo existente y fuertemente utilizado? 3
6. ¿ Requiere el sistema entrada de datos interactiva? 4
7. ¿ Transacciones de entrada en múltiples pantallas? 5
8. ¿ Archivos maestros actualizados en línea? 3
9. ¿ Complejidad de valores del dominio de información? 5
10. ¿ Es complejo el procesamiento interno? 5
11. ¿ Se ha diseñado el código para ser reutilizable? 4
12. ¿ Están incluidas en el diseño la conversión y la instalación? 3
13. ¿ Instalaciones múltiples? 5
14. ¿ Aplicación diseñada para facilitar los cambios ? 5
Cálculo del PFestimado
PFestimado = UFP x Factor de ajuste de la complejidad
PFestimado = UFP x [0,65 + 0,01 x (Fi)]
PFestimado = 318 x [0,65 + 0,01 x 52]
PFestimado = 318 x 1.17
PFestimado = 372
 Resultados
PF Productividad Costo Costo de c/PF Costo total del Esfuerzo
estimada en la personal / proyecto personas/mes
empresa de mes
puntos de función
por personal/mes

372 6.5 4000 Bs. 4000/6.5=615.385Bs. 58*4000= 372/6.5=

232000 Bs. 57.23  58
personas/mes
Bibliografía
Ingeniería de Software, Somerville
Ingeniería de Software, Pressman