Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Gestion de Proyectos
Gestion de Proyectos
Proyectos
I N G E N IE R Í A D E S O F T WA R E I I
Gestión de Proyectos
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)
3
Alcance
Alcance del producto (final):
◦ sus características
◦ Se mide contra requerimientos.
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
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.
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
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
Contrato Comunica-
ciones
Finanzas Riesgo
Calidad Alcance
Recursos
Planificación
Definición del á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
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 Reasignación/
Infraestructura Adquisición de Recursos
Creación del Plan de Proyecto
Componentes - Gestión Comunicaciones
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.
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.
0 5
No importante absolutamente esencial
sin influencia fuerte influencia