Software Project Management EAN

SSD10- Software Project
Organization & Management
iCarnegie

Part I. Software Management
Renaissance
Framework que introduce aproximaciones modernas a
problemas convencionales del desarrollo de software.

Problemas de los proyectos:
Finalizar a tiempo, en costo y con la calidad
esperada.

Chapter 1. Administración
convencional del Sw

Flexibilidad del software:

– Ventajas: Se puede programar cualquier cosa
– Desventajas: Difícil de planear y monitorear su desarrollo.

CRISIS DE DESARROLLO DE SOFTWARE

Chapter 1. Administración convencional
del Sw

• Análisis del estado de la industria de Software (90’s)
• Indicador de éxito de proyectos es muy bajo
• Conclusiones:
– Desarrollo de software es aun altamente impredecible.
10% de los proyectos de software son entregados
exitosamente en el costo y tiempo planeados.
– El nivel de retrabajo es un indicador de un proceso
inmaduro

Chapter 1. Administración convencional del Sw

• Solamente 1/3 de PMs consideran como una prioridad
terminar el proyecto en el tiempo y costo planeado. (PM
Network, Junio 2007)

(PM Network)

Chapter 1. Modelo en cascada
– 1ª Parte: Dos pasos básicos para construir sw

1970: “Managing the Development of Large Scale Software Systems”.
Winston Royce

• Dos pasos esenciales en el
desarrollo de programas de
computador
Estado de
ingeniería • Necesidad de administrar y
controlar la libertad intelectual

Estado de
Producción

– 2ª Parte: Aproximación sistema de gran escala

• Pruebas al final del
ciclo de vida

- 3ª parte: 5 Mejoras

1. El diseño del programa viene primero
2. Documente el diseño
3. Hágalo dos veces
4. Planee, controle y monitoree las pruebas
5. Involucre al usuario

Práctica del modelo Cascada
(Conventional Software management approach)

Síntomas frecuentes de problemas:
– Integración prolongada y cambios tardíos en el diseño
– Resolución tardía de riesgos
– Descomposición funcional de requerimientos
– Relaciones difíciles con los stakeholders
– Enfoque en documentos y reuniones de revisión


– Integración prolongada y cambios tardíos en el
diseño
5% 10% 30% 40%

Costo por Actividad: Management: 5%, Deployment: 5%, Environment: 5%

– Resolución tardía de riesgos

Chapter 1. Métricas de la
industria de SW
1987-Barry Boehm’s: “Industrial Software Metrics Top 10 List”

1. Encontrar un error y arreglarlo una vez liberado el
producto cuesta 100 veces mas que en etapas
tempranas.
2. Máximo nivel de compresión del cronograma: 25%
3. Por cada peso ($1) gastado en desarrollo se gastarán 2
($2) en mantenimiento.
4. El costo del Desarrollo y mantenimiento de SW están en
función de SLOC

Chapter 1. Métricas de
la industria de SW

5. Variaciones entre skill del equipo está relacionado con
diferencias en la productividad (producción/recursos).
6. Proporción de costos de SW:HW es: 15:85 en 1955 y
85:15 en 1985.
7. 15% del esfuerzo de desarrollo es de programación.
8. Productos y sistemas de software cuestan 3 veces mas
por línea de código que programas individuales de
software.
9. Walkthroughs encuentran el 60% de los errores

Chapter 1. Métricas de la
industria de SW

10. 80% de las contribuciones vienen del 20% de los
contribuyentes

80% 20%
Ingeniería es consumido por requerimientos
Costos de software son consumidos por componentes
Defectos radican en Procesos
Retrabajo y scrap son causados por errores

Renaissance
Evolution of Software Economics

Chapter 2. Evolución de la
economía del Sw
• Ingeniería del Software
– Actividad intelectual
– Resolver problemas de gran complejidad
– Gran cantidad de variables desconocidas

• Generaciones de Ingeniería de Software
– 60s-70s: Actividad artesanal. Procesos y Herramientas hechos en casa.
– 80s-90s: Actividad mas ingenieril con una fuerte actividad
investigativa y deseconomía de escala
– Siguiente generación: Actividad productiva dominada por la
automatización y economía de escala.

Chapter 2. Economía del Software
• Modelos de costos: 1 Función con 5 parámetros
PROCESO para producir
el producto final Re-trabajo,
Habilidad del proceso para evitar Burocracia
actividad que no añaden valor

SLOC – FP
Habilidades en ingeniería
TAMAÑO del producto final de SW de las PERSONAS
¿Como puede ser cuantificado? Problemas de ing de SW y
dominio de la aplicación

Ecuación de
estimación del costo

Características,
ReqNF

AMBIENTE para soportar
CALIDAD requerida
el desarrollo del SW
del producto
Herramientas y técnicas disponibles

Chapter 2. Economía del Software

• Modelos de costos paramétricos
Esfuerzo =
(Personas)(Ambiente)(Calidad)(Tamaño Proceso)

• Esfuerzo & Tamaño = deseconomía de Escala
• Deseconomía de Escala del software:
– Entre mas software se construya, Mayor será su costo por
unidad.
– Complejidad en las relaciones interpersonales
– Característica de proyectos de investigación.

Chapter 2. Generaciones de
Economía de SW

Chapter 2. Estimaciones pragmáticas
Datos poco
Falta de casos de Homogeneizar datos de
comparables y
estudio diferentes proyectos,
poco consistentes
documentados para diferentes organizaciones,
proyectos con diferentes tecnologías,
metodologías de lenguajes.
desarrollo
iterativas. Problemas
Se debe usar la
misma definición de
Frecuentes debates sobre modelos de la unidad de
estimación de costos: medida (SLOC,
– ¿Cuál Modelo de estimación de costos FP)?
usar?
– ¿Líneas de código o Function Points?
– ¿Qué constituye una buena estimación?

Chapter 2. ¿SLOC o Function Point?
Fácil de automatizar
Métrica ambigua para desarrollos
Mas aceptada por
basados en componentes y con
desarrolladores SLOC herramientas automatizadas.
Etapas avanzadas del proyecto

Método independiente de la tecnología
Definición abstracta. No se puede
Unidad mas primitiva
automatizar
de comparación entre Function
proyectos y IFPUG: International Function
organizaciones. Points
Point User’s Group. 1984
Etapas tempranas del proyecto

“The use of some measure is better than none at all”

Chapter 2. Proceso de estimación
de costos
• Modelo de Costos: Bottom up mas usado que Top Down
• Mantener en mente riesgos y objetivos de los
stakeholders
• Lección Aprendida: Estimaciones realizadas con el
equipo de desarrollo

Chapter 2. Atributos de una buena
estimación
 Concebida y soportada por PM, equipo de arquitectura,
equipo de desarrollo, equipo de pruebas
 Aceptada por todos los stakeholders
 Ambiciosa pero realizable
 Basada en experiencia de proyectos anteriores
 Tiene suficiente detalle para entender riesgos
 Refinada cuando se tiene mas conocimiento del
proyecto.

Preguntas?

Ir Agenda

Renaissance
Improving Software Economics

Chapter 3. Mejorando la
economía del Sw
• Mejora en Economía de desarrollo de SW
– Difícil de alcanzar
– Difícil de Medir
– Difícil de Verificar

• Para una mejora en el proceso de desarrollo de software que
sea significativa se requiere un ataque balanceado a través de
varias dimensiones interrelacionadas.

Chapter 3. Balance entre dimensiones
Métodos y
Técnicas
PROCESOS
Tecnologías de Mejorar el proceso de desarrollo
Abstracción y
Componentes Factores
humanos

TAMAÑO PERSONAS
Reducir el tamaño o Usar personal con mejor skill
complejidad del producto y mejores equipos de trabajo

Ecuación de

Rendimiento, Herramientas y
confiabilidad, tecnologías de
exactitud, control automatización
estadístico

CALIDAD
AMBIENTE
ISO 9126 Hacer concesiones
Mejorar el ambiente
o abandonar calidad

Mejoras
constantes de Hw
Ejemplo

Chapter 3. Reduciendo el tamaño
del producto
• Producto que cumpla los requerimientos con la
mínima cantidad de código generada por el equipo.

– Desarrollo basado en componentes
– Lenguajes de alto nivel
– Generadores automáticos de código
– Reutilización de componentes comerciales
– Tecnologías orientadas a objetos

del producto

• Reducir la cantidad de
código generado por el
equipo reduce el tamaño
del equipo y el tiempo de
desarrollo.

• Tecnologías de alto nivel de
abstracción tienden a
degradar el rendimiento.

del producto
• Métodos orientados a objetos y Modelamiento Visual
– UML
– Aumenta productividad y calidad del SW.

Ventajas
Mejora comunicación:
Incentiva el uso de
vocabulario común Primera arquitectura: La
entre los usuarios y los continua integración Arquitectura orientada a
desarrolladores. permite reconocer objetos permite
oportunamente los separación de elementos
riesgos y correcciones de sistema (Alta
iterativas cohesión, bajo
acoplamiento)

del producto
• Reuso
– Reuso de arquitecturas comunes, procesos comunes,
experiencia previa, ambientes comunes.
– Reuso como una razón económica: Piense en el costo de
hacer un componente reutilizable.

Chapter 3. Mejorando el proceso
de desarrollo
Perspectivas del proceso:

Políticas, procedimientos y practicas de
Metaprocesos la organización. Línea de negocio.

Políticas, procedimientos y practicas del
Macroprocesos
proyecto. Producto de Software.

Políticas, procedimientos y practicas del
Microprocesos equipo de trabajo. Artefacto del
proceso de software.

Chapter 3. Mejorando el proceso
de desarrollo
• Proceso de proyecto = Actividades productivas +
actividades de overhead
– Actividades productivas: Se obtiene un progreso tangible.
– Actividades adicionales: Intangible impacto en el producto
final
• Mejoramiento de procesos: Maximizar asignación de
recursos a labores productivas.
– Mejorar la eficiencia de cada paso
– Eliminar algunos pasos
– Mas concurrencia: Hacer actividades en paralelo o mas
recursos por actividad.

Chapter 3. Mejorando la efectividad
de los equipos
Administración de equipo:
– Un equipo bien manejado puede ser éxito con un
equipo de ingenieros promedio.
– Una buena arquitectura del sistema puede ser
construida con un grupo de ingenieros promedio.

5 Principios de
administración de staff:
Buscar un Balance del equipo
buen equipo y asignación
adecuada del
trabajo

Chapter 3. Mejorando la automatización
Herramientas Mejora del 20%
de al 40% en el
automatización esfuerzo.

Ambientes de alta integración:
Facilitan e impulsan el control del
proceso.
Mejora la productividad
Mejora la calidad del software
Acelera la adopción de técnicas
modernas.

Automatización
de tareas Round-trip engineering:
manuales que Capacidad del ambiente
están propensas para soportar procesos
a errores. iterativos.

Chapter 3. Alcanzando la calidad
requerida
• Prácticas claves que mejoran la calidad del software
– Requerimientos
• Enfocarse sobre los casos de uso críticos al inicio
• Enfocarse en la completitud y trazabilidad de los requerimientos mas
adelante
• Durante todo del proyecto mantener el balance en la evolución de
los requerimientos, diseño y plan.
– Usar métricas e indicadores para el progreso y calidad de la arquitectura.
– Proporcionar un ambiente integrado para soportar los distintos
procesos.
– Usar modelamiento visual, leguajes de alto nivel, reuso.
– Evaluaciones basadas en demostración para mitigar riesgos de
performance.

Renaissance
The old way and the new

Chapter 4. The Old Way & the New

• Framework que introduce aproximaciones modernas a
problemas convencionales del desarrollo de software.

• Problemas de los proyectos:
– Finalizar a tiempo, en costo y con la calidad esperada.

Chapter 4. Puntos claves
• La ingeniería de software convencional tiene numerosos principios que
están bien establecidos. Muchos son aun válidos pero otros ya son
obsoletos.

• Un proceso de administración moderna de software incorpora muchos
principios del proceso convencional pero hace transición a otros nuevos
acercamientos, tomando como base:
– Experiencias de proyectos exitosos
– Avances en tecnologías de ingeniería de software

Y motivado en:
– Necesidad de producir mas características mas rápidamente.
– Presión por reducir costos.

Chapter 4. Principios de ingeniería
de software convencional

1. Haga de la calidad lo primero
2. Alta calidad del software es posible
3. Entregar productos a los clientes de forma temprana
4. Determinar el problema antes de escribir los requerimientos
5. Evaluar las alternativas de diseño
6. Utilizar un modelo de proceso apropiado
7. Utilizar diferentes lenguajes para diferentes fases

Basado en Davis, 1994


8. Minimizar la distancia intelectual
9. Anteponer las técnicas antes que las herramientas
10.Hacerlo bien, antes de hacerlo rápido
11.Inspeccionar el código
12.Una buena administración es mas importante que una buena
tecnología
13.La gente es la clave del éxito
14.Siga con cuidado
15.Asuma responsabilidad



16.Entienda las prioridades del cliente
17.Entre mas ve el cliente, mas el necesita
18.Planee descartar
19.Diseñe para el cambio
20.Diseñar sin documentación es no diseñar
21.Use herramientas, pero sea realista
22.Evite los trucos
23.Encapsule



24.Use los principios de acoplamiento y cohesión
25.Use la métrica de complejidad de McCabe (ciclomática)
26.No pruebe su propio software
27.Analice las causas de error
28.Incremento de entropía en el software
29.Gente y tiempo no son intercambiables
30.Espere excelencia


# Principios que se mantienen Framework del proceso moderno

3 Entregar productos a los clientes de forma Principio del Framework moderno
temprana (determina las necesidades reales)

6 Utilizar un modelo de proceso apropiado Framework de procesos (clases de procesos
flexibles)
7 Utilizar diferentes lenguajes para diferentes fases -

8 Minimizar la distancia intelectual (Acercamiento Técnicas orientadas a objetos, desarrollo basado en
entre estructura de software y del mundo real) componentes, modelado visual

10 Hacerlo bien, antes de hacerlo rápido (Programa Se necesita ejecuciones tempranas para entender la
que corra rápido vs programa que rápido trabaje) complejidad del balance de performance

# Principios que se mantienen Framework del proceso moderno)
12 Una buena administración es mas importante -
que una buena tecnología
Siga con cuidado (evaluar aplicabilidad de una
14 solución previa en su ambiente) Dificultad para distinguir tecnologías nuevas
Entienda las prioridades del cliente
16 (Funcionalidad clave) -

Diseño basado en componentes, orientado a objetos,
23 Encapsule notaciones para diseño y programación.

Dificultad para aplicar.
Mantenibilidad y adaptabilidad se miden a través de
24 Use los principios de acoplamiento y cohesión los síntomas (re-trabajos y scrap)
Gente y tiempo no son intercambiables (tiene
poco sentido medir un proyecto únicamente
29 con base en personas-mes) -

# Principios modificados Framework del proceso moderno

1 Haga de la calidad lo primero Convencional: No es fácil al inicio del proyecto
(cuantificada, motivada) Moderno: Balance entre triple restricción de forma temprana

4 Determinar el problema antes de Convencional: Problema de proceso de especificación
escribir los requerimientos convencional
Moderno: Evolución conjunta del problema y la solución

9 Anteponer las técnicas antes que las Convencional: Solo aplica para ingenieros poco disciplinados
herramientas Moderno: Automatización de buenas técnicas

Moderno: Entre mas el usuario ve, mas entienden. Resultados
intermedios para sincronizar expectativas. Tener datos
17 Entre mas ve el cliente, mas el necesita objetivos para negociar solicitudes de cambio

# Principios modificados Framework del proceso moderno
Moderno: Complejo de aplicar pero se intenta predecir pequeños
19 Diseñe para el cambio cambios (administración del riesgo)

Convencional: Aproximación dirigida por documentos
Moderno: Los artefactos de software deberían estar en su mayoría,
Diseñar sin documentación es auto-documentados. Modelamiento visual. Documentos de
20 no diseñar arquitectura de alto nivel.
Convencional: Se ha detectado por exceso de análisis y diseño en
papel (que son medidas preventivas de calidad)
Analice las causas de error Moderno: En estado de ingeniería se pueden generar errores. Se
27 (también prevención) analiza la causa de error en la fase de producción

Chapter 4. Principios de ingeniería de
software convencional
# Principios generales Framework del proceso moderno
Sobrevalorado. Pocas veces descubre problemas de
arquitectura.
11 Inspeccionar el código Moderno: Agrega análisis y pruebas automatizadas.
13 La gente es la clave del éxito Experiencia, skill, entrenamiento
15 Asuma responsabilidad -
30 Espere excelencia Tener altas expectativas del equipo

# Principios que ya no aplican Framework del proceso moderno
2 Alta calidad del software es posible (usar técnicas) Principio redundante

5 Evaluar las alternativas de diseño (después de Convencional: Problema de modelo en cascada
acordados los requerimientos) Moderno: Análisis de arquitecturas paralelo con
especificación de requerimientos. Sus artefactos
están desacoplados

18 Planee descartar (iniciar un producto nuevo) Moderno: Evolucionar un producto.

Moderno: Importancia del ambiente de desarrollo.
Procesos maduros: Bien establecidos,
21 Use herramientas, pero sea realista automatizados e instrumentados.
Límite difuso entre un truco y una solución
22 Evite los trucos innovadora

# Principios que ya no aplican Framework del proceso moderno
Use la métrica de complejidad de McCabe
(Complejidad ciclomática del SW, Identifica
25 componentes que requieren atención) Usado en ambientes académicos

Perspectiva objetiva vs necesidad de apropiarse de la
calidad del producto.
26 No pruebe su propio software Moderno: Mezcla de ambas visiones

Incremento de entropia en el software Convencional: Arquitecturas pobres.
(continuos cambios incrementan Moderno: Integridad de interfaces. Cambios pueden ser
28 complejidad y desorganización) incorporados con estable y predecible resultados.

Acoplamiento Encapsulamiento
y cohesión Inspección Código
Modelo Análisis causas -error
Proceso
Calidad Primero Alternativas
Adecuado Diferentes lenguajes en Diferentes Fases
Alcanzar
diseño Utilizar
Evaluar Minimizar Distancia intelectual
E Priorizar Hacerlo bien, antes de
n R
Determinar
Técnicas antes e hacerlo rápido
Alta t
c
Calidad:
r que herramientas Buena administración
e 1.Problema o
más importante que
r
Posible g
2.Requerimiento d buena tecnología
a
r a
r Gente = clave del éxito
Al Cliente Tempranamente
Siga con cuidado
Prioridades Asuma responsabilidad
Entender
del cliente Old Way & The New Evite los trucos
Entre mas ve el No pruebe su propio sw
cliente, mas el Planee descartar
Incrementar
necesita
No
Esperar Usar métrica de
Para el intercambiar
complejidad
Diseñar
cambio Entropía Herramientas, de McCabe
Gente y en el sw Excelencia pero sea (ciclomática)
Y documentar tiempo realista

Chapter 4. Principios de administración
moderna del software
1. Aproximación de primera arquitectura (architecture-first)
2. Proceso de ciclo de vida iterativo
3. Desarrollo basado en componentes
4. Ambiente de administración del cambio
5. Ingeniería de Round-trip

6. Notación basada en modelos
7. Control cualitativo de objetivos
8. Aproximaciones basados en demostración
9. Evolucionar en niveles de detalle
10. Procesos configurables

1. Base del proceso en un enfoque de primera arquitectura (architecture-
first)
– Balance entre levantamiento de requerimientos, decisiones de arquitectura,
y planes

2. Establecer un proceso de ciclo de vida iterativo que enfrente de forma
temprana los riesgos
– Iteraciones que refinan el entendimiento del problema
– Tratamiento balanceado de todos los objetivos de los stakeholders
– Manejo temprano de riesgos incrementa la predictibilidad y evita re-trabajos.

3. Métodos de diseño para enfatizar el desarrollo basado en componentes
– Conjunto cohesivo de líneas de código (fuente o ejecutable) con una interfaz
y comportamiento predefinido.
– Reduce la cantidad de código fuente generado.

4. Establecer un ambiente de configuración del cambio
– Equipos trabajando en diferentes flujos de trabajo, compartiendo
artefactos
– Control de líneas base
– Scope Creep: Tendencia de los requerimiento a cambiar sobre el curso del
proyecto.

5. Soportar la libertad para hacer cambios a través de herramientas que
soporten ingeniería de round-trip
– Ambiente soportado en sincronización y automatización de información
– Reduce ciclos de iteración manejando marcos de tiempo

Primero diseñar e integrar, luego producir y probar.
Architecture-first approach Balance entre levantamiento de requerimientos, decisiones de
arquitectura, y planes
Diseño central

Control de riesgos en cada incremento. Iteraciones que refinan el
Iterative life-cycle process entendimiento del problema, Tratamiento balanceado de los
objetivos de los stakeholders, Manejo temprano de riesgos
Administración de riesgos

Métodos OO, notaciones, modelos visuales. Conjunto cohesivo de
Component-based development líneas de código con una interfaz y comportamiento predefinido.
Reduce la cantidad de código fuente generado.
Tecnología

Métricas, tendencias, instrumentos. Equipos trabajando en
Change management environment diferentes flujos de trabajo, compartiendo artefactos. Control de
líneas base. Scope Creep
Control

Herramientas complementarias, ambientes integrados. Ambiente
Round-trip engineering soportado en sincronización y automatización de información .
Reduce ciclos de iteración manejando marcos de tiempo.
Automatización

6. Capturar los artefactos de diseño en una rigurosa notación basada en
modelos
– Rica semántica gráfica (ejemplo: UML).
– Notación con lenguaje procesable por maquina.
– Revisiones automáticas (No solo peer-review).

7. Proporcionar instrumentos en el proceso para controlar los objetivos de
calidad y evaluar el progreso.
– Integración de evaluación de progreso y calidad integrados al proceso.
– Métricas obtenidas directamente de la evolución de los artefactos e integradas
a las actividades.
– Métricas manuales son susceptibles a inconsistencias y a manipulación.

8. Usar un enfoque basado en la demostración para evaluar artefactos
intermedios
– Demostraciones ejecutables de escenarios relevantes.
– Estimula la integración y el entendimiento de problemas de diseño y de
arquitectura..

9. Planear releases intermedios por grupos de escenarios de uso que
evolucionarán su nivel de detalle
– Tempranos y continuas demostraciones.
– Incrementos proporcionales al nivel del entendimiento de los requerimientos y
la arquitectura.
– Escenarios cohesivos es un mecanismo para definir iteraciones, evaluar
implementaciones y organizar pruebas de aceptación.


10. Establecer un proceso configurable que sea escalable económicamente

– Framework de proceso configurable para diferentes aplicaciones.
– Tener en cuenta economía de escala y retorno de inversión.
– Que pueda mantener y reutilizar el espíritu del proceso, las herramientas de
automatización, patrones y componentes comunes de la arquitectura.

Model-based notation Evolución de la notación gráfica.
UML

Objective quality control El mejor mecanismo de evaluación es tener métricas bien definidas y
actividades integradas a las demás del equipo de proyecto.
Evaluación de progreso

Transición del estado de producto en demostraciones ejecutables de
Demonstration-based approach escenarios relevantes para simular integración , tener un mejor
Simulaciones ejecutables entendimiento y eliminar defectos desde temprano

Evolución de incrementos y generaciones. Primer mecanismo para
Evolving levels of detail organizar requerimientos, definir contenido de iteraciones: tener
Planear hitos intermedios escenarios cohesivos y utilizables.

El proceso debe asegurar economía de escala y retorno de la
Configurable process inversión explotando el espíritu de proceso, excesiva automatización
y patrones de arquitectura y componentes
Framework de procesos

Chapter 4. Riesgos mitigados
Recursos de
Abandonos Desgaste desarrollo
tardíos y del inadecuados Stakeholders
excesivo re- personal opositores
trabajo clave

Introducción Parálisis
de Énfasis en el
tecnología análisis Rendimiento
exagerado inadecuado
necesaria en los del sistema
artefactos

Funcionamiento
inadecuado del Crecimiento de
sistema requerimientos

Chapter 4. Beneficios económicos.
Comparación con factores de COCOMO
• Application precedentedness (proceso iterativo)
– En sistemas sin precedentes se requiere iteraciones para reducir riesgos y
establecer precedentes.

• Process Flexibility (administración del cambio y procesos configurables)
– Continua incorporación de cambios.
– Inherentes al entendimiento del problema, al espacio de solución o a la
planeación.

• Architecture risk resolution (Enfoque de primera arquitectura, desarrollo
basado en componentes y evaluación basada en demostración)
– Desarrollar y estabilizar una arquitectura antes de desarrollar todos los
componentes.
– Tomar decisiones como comprar o hacer.
– Actividades de integración y verificación en etapas tempranas.

Chapter 4. Beneficios económicos.
Comparación con factores de COCOMO

• Team Cohesion (diseño basado en modelos y ingeniería round-trip)
– Equipos cohesivos evitan la turbulencia originada básicamente por fallas de
comunicación soportada en documentos.
– Tecnologías para un mejor entendimiento.

• Software process maturity (control objetivo de la calidad)
– Evitar riesgos de desarrollo y explotar los activos y lecciones aprendidas de la
organización.
– Proceso maduro se obtiene a través de un ambiente integrado con un
apropiado nivel de automatización.

Part II. A Software Management
Process Framework
Life-Cycle Phases

Chapter 5. Estados del ciclo de vida
• Adecuado balance.
• Hito bien definido para la
transición entre los dos estados:
– Plan de producción aceptado
por todos.
Estado de – Suficiente entendimiento del
investigación
problema y de la solución

Estado de ingeniería
• Proceso de fabricación de
software, impulsado por las
mejoras tecnológicas en la
automatización de procesos y en
el desarrollo basado en
componentes


• Proceso de desarrollo de SW moderno
– Evolución de los artefactos con puntos de
sincronización bien definidos.
– Administración del riesgo
– Métricas de progreso y cualidad
– Evolución de las capacidades del sistema
(demostraciones)

• Actividades de investigación y desarrollo
• Menos predecible
• Pequeños equipos
Estado de • Actividades de diseño y síntesis
Ingeniería • Fases de Inicio y Elaboración

• Actividades de producción
• Mas predecible
• Equipos mas grandes
Estado de • Actividades de construcción, pruebas y despliegue
Producción • Fases de Construcción y de transición

Chapter 5. Ciclo de vida convencional

• Las fases tiene el nombre de las actividades primarias
• Proceso secuencial
• Desarrollo secuencial de artefactos

Chapter 5. Modelo en espiral

• Proceso iterativo
Inicio (Idea) • Cada fase incluye todas las
actividades en diversas
Elaboración
(Arquitectura) proporciones
Construcción
(Releases • Inercia
Beta)
• Tiempo de reacción para
Transición
(Productos) manejar los cambios.

Chapter 5. Rational Unified Process

Chapter 5. Fase de inicio

• Objetivos Primarios
– Establecer alcance y condiciones límites
– Detectar casos de uso críticos y escenarios primarios de operación
– Generar al menos una arquitectura candidata
– Estimar costos y schedule para proyecto
• Actividades
– Formular el alcance del proyecto
– Sintetizar la arquitectura
– Planear y preparar un caso de negocio

• ¿Cuáles son los criterios de evaluación básicos?

Chapter 5. Fase de elaboración
– Generar una línea base de arquitectura
– Generar una línea base de la visión
– Generar una línea base del plan para la fase de construcción
– Demostrar que la línea base de arquitectura soporta la visión con unos
costos y tiempos razonables
• Actividades
– Elaborar la visión
– Establecer el proceso y la infraestructura para la fase de construcción
– Elaborar la arquitectura y los componentes seleccionados


Chapter 5. Fase de construcción
– Minimizar los costos de desarrollo, optimizando recursos y evitando
re-trabajos
– Alcanzar la calidad adecuada tan rápido como sea posible
– Alcanzar versiones útiles tan rápido como sea posible

• Actividades
– Administración y control de recursos y optimización de proceso
– Completar el desarrollo y pruebas de componentes
– Evaluación de productos según los criterios de aceptación


Chapter 5. Fase de transición
– Alcanzar un producto que pueda ser soportado por el usuario
– Alcanzar la aceptación sobre la completitud y consistencia de la línea
base de despliegue
– Minimizar el desarrollo de costos, optimizando recursos y evitando re-
trabajos

• Actividades
– Sincronización e Integración de incrementos de construcción en líneas
bases de despliegue
– Actividades específicas de despliegue
– Evaluación de las líneas base contra la visión y criterios de aceptación


Process Framework
Artifacts of the process

Chapter 6. Artefactos del Proceso
• Enfoque: Desarrollo secuencial de
artefactos.
Proyectos Convencionales • Proceso para escalas pequeñas
de Software
• No funciona para sistemas
actuales de sw

• Enfoque: Desarrollo iterativo de
artefactos.
• Existen muchos componentes
Proyectos Modernos de (propios, comerciales, reusables)
Software
• Plataformas heterogéneas
• Requiere diferente secuencia de
artefactos
• Alcance diferente de trazabilidad

Cuál es el impacto de desarrollar iterativamente los artefactos?

Chapter 6. Conjunto de artefactos

• Set: Artefactos relacionados que tienen un formato
de representación uniforme. Representan un
completo aspecto de un sistema

• Artefacto: Representa una información cohesiva
que es desarrollada y revisada como una entidad
simple.
– En cada etapa aumenta el nivel de precisión
– Mantener niveles compatibles de detalle
– Mantener consistencia y trazabilidad
– Poco retorno de inversión al inicio

Chapter 6. Como evaluar un set de
artefactos
• Analizar consistencia y calidad con documentos previos
• Analizar consistencia interna (entre documentos del set)
• Verificar el traslado de información a los sets siguientes para
evaluar consistencia y completitud
• Analizar cambios entre versiones
• Revisión subjetiva de otras dimensiones de calidad

• De forma adicional para deployment
– Pruebas contra requerimientos (escenarios y atributos de calidad
– Pruebas replicas, particionamiento, tipología, asignación en recursos
físicos
– Pruebas de escenarios del manual de usuario

Chapter 6. Artefactos de Ingeniería

• Requerimientos • Implementación
– Documento de Visión – Líneas base de código Fuente
– Modelo de Requerimientos – Archivos compilados
– Componentes ejecutables
• Diseño
– Modelo de diseño • Despliegue
– Modelo de pruebas – Producto ejecutable
– Descripción de la arquitectura integrado
de software – Archivos run-time
– Manual de usuario

•¿Qué herramientas se usan en cada set de artefactos?
•¿Qué temas son tratados en despliegue y no en implementación?

Administración y
Control de
Cambios

Chapter 6. Artefactos de administración

• Planeación • Operacionales
– WBS – Descripción de releases
– Caso de negocio – Evaluación de releases
– Especificaciones de – Evaluaciones de status
versiones – Bases de datos de
– Plan de desarrollo de ordenes de cambios
software – Documentos de
despliegue
– Ambiente

Chapter 6. Inconvenientes culturales

Las personas Las personas
quieren revisar quieren revisar
información pero información
no entienden el pero no tienen
lenguaje de los acceso a
artefactos herramientas

Deben usar
notación
rigurosa que
Artefactos sea completa,
electrónicos consistente
son fáciles
Documentación
de cambiar
utilizable

Process Framework
Model-Based Software Architectures

Chapter 7. Arquitecturas de Sw

•Arquitectura:
(Concepto intangible del diseño) Es el diseño del sistema no
de los componentes.
•Línea Base:
Parte de información de artefactos que satisfacen la visión.
Puede ser alcanzada con los parámetros del caso de negocio.
•Descripción:
Es un subconjunto organizado de información extraída del
modelo de diseño. Notación gráfica y texto necesaria para
clarificar

Arquitectura: Perspectiva Administrativa

Chapter 7. Arquitecturas de Sw

•Diseño:
Estructuras y funciones del modelo de diseño.
•Proceso:
Concurrencia y control de las relaciones entre vistas de
diseño, componentes y despliegue.
•Componente:
Estructura del set de implementación.
•Despliegue:
Estructura del set de despliegue.

Arquitectura: Perspectiva Técnica-Vistas

Process Framework
Workflows of the process

Chapter 8. Flujos de Trabajo del proceso
Flujo de Artefactos Énfasis del ciclo de vida
Trabajo
Administración •Caso de Negocio •Inicio: Preparar caso de negocio y visión
•Plan de desarrollo de Sw •Elaboración: Plan de desarrollo
•Evaluación de estado •Construcción: Monitorear y controlar desarrollo
•Visión •Transición: Monitorear y controlar desarrollo
•WBS
Ambiente •Ambiente •Inicio: Definir ambiente de desarrollo e
•Solicitud de cambio de BD infraestructura de cambios
•Elaboración: Instalar ambiente desarrollo y
establecer bd de cambios
•Construcción: Mantener ambiente desarrollo y bd
de cambios
•Transición: Ambiente de mantenimiento y bd de
cambios

Requerimientos •Set de Requerimientos •Inicio: Definir concepto operacional.
•Especificaciones •Elaboración: Definir objetivos de arquitectura.
•Vision •Construcción: Definir objetivos de la iteración.
•Transición: Refinar objetivos de hitos.

Chapter 8. Flujos de Trabajo del proceso
Flujo de Artefactos Énfasis del ciclo de vida
Trabajo
Diseño •Set de diseño •Inicio: Formular concepto arquitectura
•Descripción de •Elaboración: Alcanzar línea base de arquitectura
arquitectura •Construcción: Diseño de componentes
•Transición: Refinar arquitectura y componentes
Implementación •Set de implementación •Inicio: Soportar prototipos de arquitectura
•Set de despliegue •Elaboración: Producir línea base de arquitectura
•Construcción: Producir componentes
•Transición: Mantener componentes

Evaluación •Especificaciones de •Inicio: Evaluar planes, visión, prototipos
entrega •Elaboración: Evaluación de la arquitectura
•Descripciones de entrega •Construcción: Evaluación entregas intermedias
•Manual usuario •Transición: Evaluación entregas del producto
•Set de despliegue
Despliegue •Set Despliegue •Inicio: Analizar comunidad de usuarios
•Elaboración: Definir manual de usuario
•Construcción: Preparar materiales de transición
•Transición: Entregar producto al usuario

Chapter 8. Iteraciones
Administración Administración
Requerimientos Requerimientos
Diseño Diseño
Implementación Implementación
Evaluación Evaluación
Despliegue Despliegue
Fases de Inicio y Elaboración Fase de Construcción

Administración
Requerimientos
Diseño
Implementación
Evaluación
Despliegue
Fase de Transición

Chapter 8. Secuencia típica de
construcción

Process Framework
Checkpoints of the process

Chapter 9. Puntos de chequeo del proceso

– Tener visibilidad en el ciclo de vida, discutir progreso.
– La propuesta de estos puntos no es solo demostrar que tan
bien se está ejecutando el proyecto sino lograr lo siguiente:

 Sincronizar expectativas de stakeholders y alcanzar concurrencia
entre: requerimientos, diseño y plan.
 Sincronizar artefactos hacia un estado consistente y balanceado
 Identificar los riesgos importantes, inconvenientes, aspectos y
condiciones de tolerancia.
 Ejecutar una evaluación global del ciclo de vida, no solo de la situación
actual sino una perspectiva y tendencia del producto.

Chapter 9. Revisiones a través del proceso
 Al final de cada Fase
 Proveen visibilidad de aspectos e inconvenientes,
Hitos Mayores
sincronizar perspectivas de administración e ingeniería
 Verificar que se hayan alcanzado los objetivos
propuestos

 Eventos por cada iteración
Hitos Menores
 Revisar contenido de la iteración
 Autorizar continuar con el trabajo

Evaluación de  Eventos periódicos
estatus  Proveen a la administración progreso regular

Chapter 9. Secuencia Puntos Control

Chapter 9. Hitos Mayores
Hitos Planes Espacio de Espacio de Solución
Entendimiento del del problema (Producto
problema de sw)
(Requerimientos)
Hito: •Definición •Visión de línea base, atributos •Demostración de funcionalidad
Objetivos responsabilidades de calidad y prioridades •Acuerdos de
Stakeholders •Modelo de cu reuso/compra/realización
•Plan inicial •Modelo inicial de diseño
•Plan avanzado
de Elaboración
Hito: •Plan avanzado •Visión estable y modelo de cu •Set estable de diseño
Arquitectura de Construcción •Criterios de evaluación para •Decisiones de
•Plan inicial entrega de construcción reuso/compra/realización
Transición •Borrador de manual usuario •Prototipos componentes críticos
Hito: Inicio •Plan avanzado •Criterios aceptación para •Set estable de implementación
Operacional de Transición entrega del producto •Core y funcionalidad crítica
•Manual de usuario de la •Objetivos de calidad del
entrega producto
Hito: Entrega •Plan siguiente •Manual final de usuario •Set estable de despliegue
del producto generación del •Funcionalidad completa
producto •Cumplimiento de calidad

Chapter 9. Hitos Menores

Al final de cada
iteración evaluar
Al inicio de cada iteración
cumplimiento de
para revisar y preparar el
objetivos, resultados,
plan y criterios de
pruebas, e impacto
evaluación
para iteración siguiente

Chapter 9. Evaluación periódica de estado

Personal Tendencias
Financieras

Top 10 de Progreso
Riesgos Técnico

Alcance total Planes y
del Producto Resultados de
Hitos Mayores

Part III. Software Management
Disciplines
Iterative Process Planning

Introducción a la Unidad

• Flujo de trabajo para una administración efectiva:
– Disciplinas:
• Planeación: Plan que logre balancear los recursos disponibles
teniendo en cuenta las expectativas de todos los stakeholders.
• Organización: Administración de la gente en equipos y asignación
de responsabilidades.
• Automatización: Desarrollo de procesos con un repositorio
electrónico para los artefactos.
• Control: Evaluar la salud del plan, la calidad de los artefactos y
necesidades de cambios.
– Ajustar el proceso a las específicas necesidades del
proyecto

Chapter 10. Introducción
• Planeación: Requiere un proceso iterativo
• Plan:
– Pieza intangible de propiedad intelectual
– Definición de cómo los requerimientos serán transformados en un producto
teniendo en cuenta las restricciones de negocio.
– Estado de ingeniería: El plan es desarrollado
– Estado de producción: El plan es ejecutado
– Realista, actualizado, producto del equipo, entendido por los stakeholders y
debería ser usado (análisis y comunicación)
– Mas exacto a medida que las iteraciones y el proyecto avanza

• Documento de planeación no es muy útil como ítem final, pero el acto de
planear es importante para el éxito del proyecto

• Documento abierto y visible: No sólo para administradores

Chapter 10. WBS
• WBS: Work Breakdown structures
• EDT: Estructura de Descomposición del Trabajo

• WBS es dependiente del estilo de administración, cultura organizacional,
preferencias del cliente, restricciones financieras, etc.

• Jerarquía de elementos que descomponen el plan del proyecto en tareas
de trabajo discretas.

Enmarca todo el trabajo significativo

Framework para seguimiento Descompone tareas
de cronograma y para asignación de
presupuesto responsabilidades

Chapter 10. WBS
• Tipos de descomposición: por subsistemas, por
componentes, por fases, etc.
• WBS es la base para el plan financiero

• Problemas del WBS convencional
Estructura temprana
alrededor del diseño
del producto

Descomposición temprana con
mucho o muy poco detalle

Específico para un proyecto,
haciendo difícil comparación
entre proyectos.

Chapter 10. Problemas del WBS
convencional
1. Estructura temprana • Ejemplo:
alrededor del diseño del
– Administración
producto:
– Requerimientos y diseño del sistema
– Sólo es convenientes si hay – Subsistema {N}
suficiente madurez en la – Componente {M}
arquitectura y en el plan – Requerimientos
– Estructura difícil y costoso – Diseño
de cambiar – Codificación
– No es fácil cambiar – Pruebas
componentes que pueden – Documentación
– Integración y pruebas
cambiar
– Otras áreas de soporte

convencional
2. Descomposición temprana con mucho o muy poco detalle:
• Prematuramente descompuesto, planeado y
presupuestado
– Proyectos grandes:
• Exceso de planeación.
• 6 niveles o mas niveles de detalle desde el inicio.
• No permite una evolución real del plan
– Proyectos pequeños:
• Falta de planeación
• Un nivel de detalle
• Mejor practica
– 2 o 3 niveles de detalle
– Proyectos grandes: mas niveles en etapas avanzadas

convencional
3. Específico para un proyecto, haciendo difícil
comparación entre proyectos
– Estructura definida por el PM
– Dificulta la comparación entre proyecto
• Planes
• Datos financieros
• Datos de cronograma
• Eficiencia de la organización
• Tendencias de costos, productividad y calidad

Chapter 10. WBS moderno
Administración, ambiente, requerimientos, diseño,
Workflows implementación, evaluación y despliegue
• Asignado a un equipo
• Planeación y Comparación con otros proyectos

Inicio, elaboración, construcción y transición
Fases • Fidelidad del plan
• Evolución mas natural con el nivel de entendimiento de los
requerimientos y la arquitectura

Actividades que produce el artefacto en cada fase
Actividades • Mas bajo nivel de la jerarquía que recolecta los costos de
artefactos discretos
• Descompuesto en un nivel mas bajo


• Organizado alrededor del proceso y no del
producto (Workflows, fases, actividades)
• Mejor manejo de los cambios
• Entender los mas importantes atributos, estructura
y prioridades del plan de proyecto
• Planear por paquetes y no solo por actividades que
requiere mayor detalle desde el inicio


• Plantilla que debe ser ajustada dependiendo de:

– Tamaño del proyecto
– Estructura organizacional (contratistas, múltiples organizaciones)
– Grado del desarrollo personalizado (proyectos de reingeniería,
desarrollo completo desde ceros)
– Contexto del negocio (proyectos contractuales, productos
comerciales, sistemas distribuidos)
– Experiencia anterior (WBS ya existente, estándares de la
organización)

• Adaptar las guías y plantillas de acuerdo a las necesidades y
características particulares del proyecto.

Chapter 10. Guías para realizar
la planeación
• Asignación de costos (no esfuerzo) para primer nivel del WBS:
Costo
Administración 10%
Ambiente 10%
Requerimientos 10%
Diseño 15%
Implementación 25%
Assessment 25%
Despliegue 5%

• Tiene en cuenta los costos según el skill de personal (ejemplo:
administración, requerimientos y diseño son mas costosos)
• Costos de ambiente incluye HW y software para soportar el proceso de
automatización y el desarrollo del equipo de trabajo.

Chapter 10. Guías para realizar
la planeación
• Asignación de costos para segundo nivel del WBS:

Fase Esfuerzo Schedule
Inicio 5% 10%
Elaboración 20% 30%
Construcción 65% 50%
Transición 10% 10%


• Planes de proyecto derivados de dos perspectivas:
- Una aproximación ayuda a validar y refinar los resultados de la otra
- Evolucionar el plan a través de varias iteraciones

– Forward-looking, top-down
Entendimiento general de Macro nivel de Descomposición en Hitos
los requerimientos y Presupuesto y de Presupuesto y
restricciones Cronograma cronograma de mas bajo
nivel

– Backward-looking, bottom-up
Tener el final en mente Analizar a nivel micro el Sumar todos los elementos
presupuesto y para definir hitos de
cronograma presupuesto y cronograma

• Forward-looking, top-down
1. Caracterización del tamaño, proceso, ambiente, gente y calidad
requerida para el proyecto
2. Estimación a un nivel macro del esfuerzo y schedule total usando un
modelo de estimación de costos
3. Dividir el esfuerzo de estimación según guías de planeación. Definir
hitos principales.
4. Descomponer cada elemento en los niveles mas bajos de igual
forma que en los pasos anteriores.
• Planes muy optimistas
• Uso dominante durante el estado de ingeniería: No hay
suficiente detalle, ni estabilidad en las tareas
• Técnica de evaluación global


• Backward-looking, bottom-up
1. Detallar tareas de los elementos de nivel mas bajos. Definir
presupuesto y schedule
2. Combinar e integrar en un mas alto nivel el presupuesto y schedule.
Homogeneizar las bases de estimación con base en negociación
3. Comparar presupuestos y cronograma para detectar diferencias y
realizar ajustes. Diferencias entre top-down y bottom-up
• Planes muy pesimistas
• Uso dominante durante el estado de producción: Ya existe
experiencia y fidelidad de la planeación

Chapter 10. Planeación de las
iteraciones
• Planear el contenido y Schedule de los hitos
mayores y de sus iteraciones intermedias.
• Iteraciones: Sincronización a través del
proyecto. Evaluación global y bien
orquestada de todas la línea base del
proyecto

Chapter 10. Planeación de las iteraciones
• Énfasis de la planeación en el • Énfasis de la planeación en el
estado de ingeniería: estado de producción
– Estimación de tareas a nivel – Estimación de tareas a nivel
micro para artefactos en estado micro para artefactos en estado
de ingeniería de producción
– Estimación de tareas a nivel – Estimación de tareas a nivel
macro para artefactos en estado macro para artefactos de
de producción mantenimiento
– Acuerdo entre los stakeholders – Acuerdo entre stakeholders
– Análisis de varianza entre costos – Análisis detallado de varianza
planeados y actuales (no entre costos planeados y
detallado) actuales
– Ajustar al proyecto los
lineamientos Top-down de
planeación
– Definición y elaboración del
WBS.


• Número de iteraciones por fase:
– Inicio:
• 1 (por defecto: Prototipo de arquitectura)
• 2 (proyectos Grandes, desarrollos personalizados)
– Elaboración:
• 2 (por defecto: Prototipo de arquitectura y Línea base
de arquitectura)
• Mas de 2 (proyectos sin arquitecturas precedentes)
• 1 (proyectos con arquitecturas bien establecidas)


• Número de iteraciones por fase:
– Construcción:
• 2 (por defecto: release alfa y beta para liberar el 70%
y 95% del producto respectivamente)
• 2 adicionales (manejo de riesgos y optimizar
recursos)
– Transición:
• 1 (por defecto: release del producto final)
• Mas iteraciones informales para resolver defectos o
mejoras de performance.


• Proyecto estándar: 6 Iteraciones

• Proyectos con arquitectura previa bien definida o
de pequeña escala: 4 iteraciones
– 1 iteración que combina las fases de inicio y elaboración

• Proyectos grandes, sin experiencia similar o con
muchos stakeholders: 9 iteraciones
– 1 iteración adicional de inicio
– 2 iteraciones adicionales de construcción

Tareas en MsProject
• Ingreso de Tareas de Resumen
1. Ver, Diagrama de Gantt
2. Click en celda de Nombre
3. Escribir el nombre de la tarea
4. Agregar, si se desea, Notas de Tareas
5. Oprimir Enter para ir a la siguiente tarea

• Ingreso de Tareas de Detalle
1. Click en la línea donde se desee ingresar la tarea
2. Insertar, Nueva Tarea u oprimir Insert
3. Click en celda de Nombre
4. Escribir el nombre de la tarea
5. Si es necesario, incrementar la sangría de la tarea para mostrar
dependencia

Tareas en MsProject
• Ingreso de Hitos
1. En el menú Ver, hacer clic en Diagrama de Gantt.
2. Escribir 0 en el campo Duración de la tarea
3. Presionar Enter. Al introducir el valor 0 como duración. Hito: punto
de referencia que marca un evento importante en un proyecto y se
utiliza para controlar el progreso del proyecto.
4. Toda tarea con una duración cero se muestra automáticamente
como hito.
5. También se puede marcar cualquier otra tarea de cualquier
duración como hito
6. Click en “Información de la tarea” en la barra estándar, y especificar:
Marcar la tarea como hito. En el Gantt aparece un hito en la fecha
de inicio.

Tareas en MsProject
• Tareas Repetitivas
1. En el menú Ver, haga clic en Diagrama de Gantt.
2. En el campo Nombre de tarea, seleccione la fila debajo de la cual desea que
aparezca la tarea repetitiva.
3. En el menú Insertar, haga clic en Tarea repetitiva.
4. En el cuadro Nombre de tarea, escriba el nombre de la tarea.
5. En el cuadro Duración, escriba o seleccione la duración de una realización de
la tarea.
6. En Patrón de repetición, haga clic en Diariamente, Semanalmente,
Mensualmente o Anualmente.
7. Especifique la frecuencia de la tarea y active la casilla de verificación situada
junto al día de la semana en el que deba tener lugar la tarea.
8. En Intervalo de repetición, escriba la fecha de comienzo en el cuadro
Comienzo y, a continuación, haga clic en Terminar después de o Terminar el.
9. Si ha hecho clic en Terminar después de, escriba o seleccione el número de
apariciones de la tarea. Si ha hecho clic en Terminar el, escriba o seleccione
la fecha en la que desea que termine la tarea repetitiva.

Tareas en MsProject
• Practicar:
1. Aumentar la sangría de varias tareas
2. Disminuir la sangría de varias tareas
3. Ocultar tareas de detalle
4. Mostrar tareas de detalle
5. Ocultar todas las tareas de detalle
6. Revelar el siguiente nivel de detalle
7. Mostrar un nivel determinado
8. “Lo que se le haga al padre se le hace a toda la familia”
9. Borrar tareas
10.Copiar tareas
11.Mover tareas

Tareas en MsProject
• Cronogramas Dinámicos
1. Tareas enlazadas mediante relaciones lógicas
2. Minimización de fechas específicas
3. Si algo cambia, todo el cronograma se ajustará automáticamente
4. Se ahorrará mucho esfuerzo en mantenimiento

Tareas en MsProject
• Dependencia
1. Relación entre el fin (o comienzo) de una actividad y el comienzo (o
fin) de otra
2. Refleja la relación de causa-y-efecto entre las dos tareas
3. Tipos de Dependencias:
– Fin a comienzo (FC)
– Fin a fin (FF)
– Comienzo a comienzo (CC)
– Comienzo a fin (CF)

Tareas en MsProject
• Tipos de Dependencias
Fin a comienzo (FC) Comienzo a Comienzo (CC)
A
A B

B
La actividad B no puede iniciar hasta
que haya terminado la actividad A La actividad B no puede iniciar hasta
que haya iniciado la actividad A
Fin a fin (FF) Comienzo a Fin (CF)
A
A
B
B
La actividad B no puede terminar hasta
La actividad B no puede terminar hasta que haya iniciado la actividad A
que haya terminado la actividad A

Tareas en MsProject
• Aplicación de Adelantos y Posposiciones
1. Absolutos
1. FC + 5d
2. FC – 3d
2. Relativos
1. FC + 50%
2. FC – 30%

Tareas en MsProject
• Utilizando el diálogo de Información de la Tarea
1. Seleccionar la tarea sucesora
2. Click en el icono Información de la tarea
3. Click Predecesoras
4. En el campo de tarea, buscar la predecesora deseada, o ingresar el
ID en el campo correspondiente
5. Seleccionar el tipo de dependencia
6. Ingresar adelanto o retraso en su campo
7. Click Aceptar

Tareas en MsProject
• Utilizando la Forma de Tarea
1. Ventana, Dividir
2. Click derecho y seleccionar Predecesoras y Sucesoras
3. Seleccionar la tarea sucesora
4. En la forma, seleccionar la tarea sucesora mediante su ID, o
escogiendo el nombre de la tarea
5. Seleccionar el tipo de dependencia
6. Ingresar adelanto o retraso en su campo
7. Click Aceptar

Tareas en MsProject
• Ingresar Estimación
1. Los estimados se hacer en términos de
1. Duración de una tarea
2. Esfuerzo para realizar una tarea

Duración:
1. Se especifica en el campo de Duración
2. Se expresa en días hábiles (días laborales)
3. Si se expresa en otra unidad, se realiza la conversión de acuerdo con lo
especificado en Herramientas, Opciones, Calendario
Esfuerzo:
1. Se especifica en el campo de Trabajo
2. Se expresa en horas-persona
3. Si se expresa en otra unidad, se realiza la conversión de acuerdo con lo
especificado en Herramientas, Opciones, Calendario

Tareas en MsProject
• Herramientas, Opciones, Programación

Tareas en MsProject
• ¿Cómo calcula MS Project?
1. Duración = cuántos días se utilizan para realizar el trabajo
2. Unidades = cuántas unidades del recurso harán el trabajo
3. Trabajo = cuántos días-persona tomará hacer el trabajo
4. A MS Project se le informan dos de las tres variables, y él calcula la
tercera

Tareas en MsProject
• Recursos:
1. Gente
2. Edificios
3. Máquinas
4. Materiales necesarios para crear el producto del proyecto
5. Generalmente, cada actividad requiere, al menos, un recurso
6. Recursos ≠ Responsables
7. Los responsables se pueden asignar en diferentes formas:
8. Asignarlos a un hito (como la duración es cero, el esfuerzo es cero)
9. Asignarlos a tareas de resumen, especificando Unidades como 0%
10.Especificarlos en campos de texto

Tareas en MsProject
• Recursos Humanos
1. Aquellos cuyo esfuerzo se acumula el campo Trabajo
2. Se ingresan como un recurso Trabajo
3. La cantidad de trabajo por semana debe ser, como máximo, su
disponibilidad
4. Tienen un costo, que debe especificarse como $xxx/hr, $xxx/día,
$xxx/sem, $xxx/ms
5. Ingresar nombres genéricos o cargos

Tareas en MsProject
• Planilla de Ingreso de Recursos
1. Ver, Hoja de recursos
2. Ver, Tabla: Entrada (Si no está en Entrada, cambiarla la tabla a
Entrada)

Tareas en MsProject
• Campos de la Planilla de Recursos
1. Indicador: Despliega indicadores para diferentes situaciones
2. Nombre del recurso: [requerido] Adoptar un estándar para evitar
repeticiones involuntarias. Se sugiere utilizar: Apellido-Nombre
3. Tipo: [requerido] Puede ser Trabajo (predeterminado) para
Recursos Humanos o Material para materiales, equipos y edificios.
4. Etiqueta de Material: [opcional] Indica la unidad de medida del
material
5. Iniciales: [opcional]
6. Grupo: [opcional] Puede utilizarse para indicar el Departamento al
cual pertenece el recurso
7. Capacidad máxima [requerido para Tipo Trabajo]

Tareas en MsProject
• Campos de la Planilla de Recursos [CONTINUACIÓN]
1. Representa la máxima disponibilidad de la persona.
2. 100% representa tiempo completo. 50% representa medio tiempo.
Para un recurso consolidado, representa la cantidad de miembros
del equipo de trabajo.
3. Tasa Estándar [opcional] Representa la tarifa estándar. 25500/h
representa $25,500 por hora.
4. Tasa horas extras: [opcional] Debe ser utilizada solamente para
recursos de tipo Trabajo, y solo si se admite trabajo en horas extras
y se reconoce una tarifa mayor que la estándar
5. El trabajo en horas extras se hace realidad únicamente si:
6. Se pagan horas extras en vez de “compensación”
7. La tasa de horas extras es mayor que la tasa estándar
8. En cada asignación se especifica cuánto tiempo es estándar y
cuánto es horas extras.

Tareas en MsProject
• Campos de la Planilla de Recursos [CONTINUACIÓN]
1. Costo/Uso:[opcional] Se utiliza si se paga ese costo por cada vez
que se utilice el recurso y por cada tarea.
2. Acumular: [opcional] Seleccionar {Comienzo, Prorrateo, Fin} para
indicar la forma como se incurre en el costo. Solamente para Tasa
estándar y Tasa horas extras.
3. Calendario base: [opcional] Permite seleccionar un calendario base
para el recurso

Tareas en MsProject
• Calendarios de Recursos
1. Se parte de un calendario base
2. Doble click en el recurso, para abrir el diálogo Información del
recurso
3. Seleccionar la pestaña Horario de trabajo y allí escoger el
calendario deseado:
4. Horas de trabajo; medio tiempo; etc.
5. Días de la semana
6. Trabajo en festivos

Tareas en MsProject
• Vista de Uso de Recursos
• Vista de Uso de Tareas

Tareas en MsProject
• ¿Cómo calcula MS Project?
1. Duración = cuántos días se utilizan para realizar el trabajo
2. Unidades = cuántas unidades del recurso harán el trabajo
3. Trabajo = cuántos días-persona tomará hacer el trabajo
4. A MS Project se le informan dos de las tres variables, y él calcula la
tercera
5. Tipos de tareas de detalle
– Duración fija
– Unidades fijas
– Trabajo fijo

Tareas en MsProject
• Duración Fija
1. Cuando el primer estimado es la duración
2. Cuando la duración no cambia al adicionar recursos
3. Tareas que siempre tienen un grupo asignado (reuniones,
entrenamiento)
4. Si la fecha límite de terminación es crítica, la duración es primordial
5. Cuando la carga de trabajo no es nuestra responsabilidad (el
trabajo corresponde a un subcontratista o un consultor)

Tareas en MsProject
• Unidades Fijas
1. Cuando la cantidad de recursos para la tarea es lo primero que se
conoce
2. Cuando es imposible obtener más recursos
3. Cuando se quiere cambiar la duración o el trabajo, manteniendo fija
la cantidad de recursos (unidades de asignación)
4. Cuando se desea tener un recurso trabajando en una tarea un
cierto porcentaje de sus horas laborales

• Trabajo Fijo
1. Cuando lo primero que se estima es el esfuerzo
2. Cuando el esfuerzo requerido es lo más fácil de estimar

Tareas en MsProject
• ¿Cómo mantener MS Project fácil y amigable?
1. Ingresar un estimado de trabajo o de duración, fijando el tipo de
tarea en consecuencia
1. Estimado de trabajo Tipo: Trabajo fijo
2. Estimado de duración Tipo: Duración fija
2. Suministrar el segundo valor de la fórmula y dejar que MS Project
calcule el tercero
3. ¡Antes de realizar un cambio en cualquiera de los tres valores,
considerar el tipo de tarea requerido!

Tareas en MsProject
Después de asignar recursos, cada tarea se programa de acuerdo con
la fórmula:

Tareas en MsProject
• Formato del Diagrama de Gantt

Disciplines
Project Organizations and
Responsibilities

Chapter 11. Introducción a la Unidad

• Flujo de trabajo para una administración efectiva:
– Disciplinas:
• Planeación: Plan que logre balancear los recursos disponibles
teniendo en cuenta las expectativas de todos los stakeholders.
• Organización: Administración de la gente en equipos y asignación
de responsabilidades.
• Automatización: Desarrollo de procesos con un repositorio
electrónico para los artefactos.
• Control: Evaluar la salud del plan, la calidad de los artefactos y
necesidades de cambios.
– Ajustar el proceso a las específicas necesidades del
proyecto

Chapter 11. Introducción
• Líneas de negocio de software
– Motivador: retorno de inversión, diferenciación en nuevos negocios,
diversificar el mercado, ganancia

• Equipos de proyectos de software
– Motivador: costo, schedule y calidad de entregables específicos.

• Pasado: Foco en los proyectos. Los proyectos tienen intereses
egoístas, raramente invierten en investigación de una
tecnología o servicio que no impacte directamente en los
entregables del proyecto.

Chapter 11. Organizaciones de línea
de negocio
• Definición y mantenimiento del proceso es específico a una
línea de negocio
• Automatización del proceso igual de importante que
definición de procesos
• Roles pueden ser cubiertos por una persona o por diferentes
equipos dependiendo del tamaño de la organización

de negocio

de negocio

SEPA:
•Facilita el intercambio de
información y guías del proceso.
•Evaluación de la madures del
proceso y planear futuras
mejoras.
•Ayuda a iniciar y evaluar
periódicamente los procesos del
proyecto
•Debe entender la mejora
deseada y el contexto del
proyecto.

de negocio

PRA:
•Asegurar que el proyecto de
software cumple con todas las
políticas, practicas y estándares
de la línea de negocio y de la
organización junto con las
obligaciones contractuales del
proyecto.

de negocio

SEEA:
•Automatizar el proceso de la
organización, mantener los
estándares del ambiente
•Entrenar en el uso del ambiente
•Mantener los valores de la
organización
•Necesario para alcanzar retorno de
inversión para un proceso común:
Costos amortizados entre proyectos
Institucionalizar el proceso (80% de la
solución por defecto)

de negocio

SEEA:
•Proporciona soporte a
recursos humanos,
investigación, desarrollo
independiente de los
proyectos.
•Componentes típicos:
•Administración de
proyectos
•Centro de skills de
ingeniería
•Desarrollo profesional

de negocio
• Equipo de administración del proyecto es un equipo activo
• Equipo de arquitectura es responsable de los artefactos reales
y de la integración de componentes
• Equipo de desarrollo posee los componentes de construcción
y las actividades de mantenimiento
• Equipo de assessment está separado del equipo de desarrollo

Chapter 11. Organizaciones por
proyectos

•Balancear condiciones
favorables para todos los
stakeholders (Continuas
negociaciones de triple
restricción)
•Planeación de esfuerzo y
administración del plan
(adaptación al cambio)

proyectos

restricción)
•Actividades en el ciclo de vida
del proyecto (Pág. 160)

proyectos

proyectos

restricción)

proyectos

•Divididos en subgrupos por
componentes que requieren un
skill común: Componentes
comerciales, DB, GUI,
Sistemas operativos y redes,
dominio de la aplicación.
•Responsable de la calidad de
un componente individual.

proyectos
•Asegurar la calidad desde una
perspectiva independiente.
•Explotar la concurrencia de
actividades.
•Debería ser orientado a casos de
uso y utilizar release specification y
release description
•Responsables de la calidad de cada
línea base liberada con respecto a
los requerimientos y expectativas del
cliente.
•Actividades en el ciclo de vida del
proyecto (Pág. 164)

Chapter 11. Evolución del proyecto

Disciplines
Process Automation

RECORDANDO….Balance
entre dimensiones
Métodos y
Técnicas
PROCESOS
Tecnologías de Mejorar el proceso de desarrollo
Abstracción y
Componentes Factores
humanos

TAMAÑO PERSONAS
Reducir el tamaño o Usar personal con mejor skill
complejidad del producto y mejores equipos de trabajo

Ecuación de

Rendimiento, Herramientas y
confiabilidad, tecnologías de
exactitud, control automatización
estadístico

CALIDAD
AMBIENTE
ISO 9126 Hacer concesiones
Mejorar el ambiente
o abandonar calidad

Mejoras
Ejemplo
constantes de Hw

RECORDANDO….Niveles
del proceso
– Metaprocesos: Políticas, procedimientos y practicas de la
organización. Línea de negocio.

– Macroprocesos: Políticas, procedimientos y practicas del
proyecto. Producto de Software.

– Microprocesos: Políticas, procedimientos y practicas del
equipo de trabajo. Artefacto del proceso de software.

RECORDANDO….Estados
del ciclo de vida
• Actividades de investigación y desarrollo
• Menos predecible
• Pequeños equipos
Estado de • Actividades de diseño y síntesis
Ingeniería • Fases de Inicio y Elaboración

• Actividades de producción
• Mas predecible
• Equipos mas grandes
Estado de • Actividades de construcción, pruebas y despliegue
Producción • Fases de Construcción y de transición

RECORDANDO… Principios de
administración moderna
Architecture-first approach Primero diseñar e integrar, entonces
producir y probar
Diseño central

Iterative life-cycle process Control de riesgos en cada
incremento
Administración de riesgos

Component-based development Métodos OO, notaciones, modelos
visuales
Tecnología

Change management environment Métricas, tendencias, instrumentos
Control

Round-trip engineering Herramientas complementarias,
ambientes integrados
Automatización

RECORDANDO… Flujos de proceso
de software
• Microprocesos o Workflows
– Administración: Controla el proceso y asegura las condiciones de
ganancia para todos los stakeholders
– Ambiente: Automatiza el proceso y evoluciona el ambiente de
mantenimiento
– Requerimientos: Analiza el espacio del problema y evoluciona los
artefactos de requerimientos
– Diseño: Modela la solución y evoluciona los artefactos de
arquitectura y diseño
– Implementación: Programa los componentes y evoluciona los
artefactos de implementación y despliegue
– Assessment: Evalúa las tendencias en la calidad del proceso y del
producto
– Despliegue: Entrega el producto final al usuario

RECORDANDO… WBS moderno

Administración, ambiente, requerimientos, diseño,
Workflows implementación, evaluación y despliegue
• Asignado a un equipo
• Planeación y Comparación con otros proyectos

Inicio, elaboración, construcción y transición
Fases • Fidelidad del plan
• Evolución mas natural con el nivel de entendimiento de los
requerimientos y la arquitectura

Actividades que produce el artefacto en cada fase
Actividades • Mas bajo nivel de la jerarquía que recolecta los costos de
artefactos discretos
• Descompuesto en un nivel mas bajo

Software Project Management EAN

Software Project Management EAN

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (7)

Similaire à Software Project Management EAN

Similaire à Software Project Management EAN (20)

Dernier

Dernier (20)

Software Project Management EAN