• Save
Software Project Management EAN
Upcoming SlideShare
Loading in...5
×
 

Software Project Management EAN

on

  • 2,082 views

Presentación del curso.

Presentación del curso.
EAN Feb 2011. - Curso de Gerencia de Proyectos de Software, Especialización de Gerencia Informática.

Statistics

Views

Total Views
2,082
Views on SlideShare
2,082
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Project Management EAN Software Project Management EAN Presentation Transcript

  • SSD10- Software ProjectOrganization & Management iCarnegie
  • Part I. Software Management RenaissanceFramework que introduce aproximaciones modernas aproblemas 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 SwFlexibilidad 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 sw1970: “Managing the Development of Large Scale Software Systems”. Winston Royce • Dos pasos esenciales en el desarrollo de programas de computadorEstado deingeniería • Necesidad de administrar y controlar la libertad intelectual Estado de Producción
  • Chapter 1. Modelo en cascada– 2ª Parte: Aproximación sistema de gran escala • Pruebas al final del ciclo de vida
  • Chapter 1. Modelo en cascada- 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
  • Chapter 1. Modelo en cascadaPrá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
  • Chapter 1. Modelo en cascada– Integración prolongada y cambios tardíos en el diseño 5% 10% 30% 40%Costo por Actividad: Management: 5%, Deployment: 5%, Environment: 5%
  • Chapter 1. Modelo en cascada– Resolución tardía de riesgos
  • Chapter 1. Métricas de la industria de SW1987-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 SW1987-Barry Boehm’s: “Industrial Software Metrics Top 10 List” 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 SW1987-Barry Boehm’s: “Industrial Software Metrics Top 10 List” 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
  • Part I. Software Management 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 deEconomía de SW
  • Chapter 2. Generaciones deEconomía de SW
  • Chapter 2. Estimaciones pragmáticas Datos pocoFalta de casos de Homogeneizar datos de comparables yestudio diferentes proyectos, poco consistentesdocumentados para diferentes organizaciones,proyectos con diferentes tecnologías,metodologías de lenguajes.desarrolloiterativas. Problemas Se debe usar la misma definición deFrecuentes 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 puedeUnidad mas primitiva automatizarde comparación entre Functionproyectos y IFPUG: International Functionorganizaciones. 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
  • Part I. Software Management 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 estimación del costo Rendimiento, Herramientas y confiabilidad, tecnologías de exactitud, control automatización estadístico CALIDAD AMBIENTEISO 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
  • Chapter 3. Reduciendo el tamañodel 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.
  • Chapter 3. Reduciendo el tamaño del producto • Métodos orientados a objetos y Modelamiento Visual – UML – Aumenta productividad y calidad del SW. VentajasMejora comunicación:Incentiva el uso devocabulario común Primera arquitectura: Laentre los usuarios y los continua integración Arquitectura orientada adesarrolladores. permite reconocer objetos permite oportunamente los separación de elementos riesgos y correcciones de sistema (Alta iterativas cohesión, bajo acoplamiento)
  • Chapter 3. Reduciendo el tamaño 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 desarrolloPerspectivas 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 equiposAdministració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 equipobuen 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 ambienteestá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.
  • Preguntas? Ir Agenda
  • Part I. Software Management 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 convencional1. Haga de la calidad lo primero2. Alta calidad del software es posible3. Entregar productos a los clientes de forma temprana4. Determinar el problema antes de escribir los requerimientos5. Evaluar las alternativas de diseño6. Utilizar un modelo de proceso apropiado7. Utilizar diferentes lenguajes para diferentes fasesBasado en Davis, 1994
  • Chapter 4. Principios de ingeniería de software convencional8. Minimizar la distancia intelectual9. Anteponer las técnicas antes que las herramientas10.Hacerlo bien, antes de hacerlo rápido11.Inspeccionar el código12.Una buena administración es mas importante que una buena tecnología13.La gente es la clave del éxito14.Siga con cuidado15.Asuma responsabilidadBasado en Davis, 1994
  • Chapter 4. Principios de ingeniería de software convencional16.Entienda las prioridades del cliente17.Entre mas ve el cliente, mas el necesita18.Planee descartar19.Diseñe para el cambio20.Diseñar sin documentación es no diseñar21.Use herramientas, pero sea realista22.Evite los trucos23.EncapsuleBasado en Davis, 1994
  • Chapter 4. Principios de ingeniería de software convencional24.Use los principios de acoplamiento y cohesión25.Use la métrica de complejidad de McCabe (ciclomática)26.No pruebe su propio software27.Analice las causas de error28.Incremento de entropía en el software29.Gente y tiempo no son intercambiables30.Espere excelenciaBasado en Davis, 1994
  • Chapter 4. Principios de ingeniería de software convencional# Principios que se mantienen Framework del proceso moderno3 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 visual10 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
  • Chapter 4. Principios de ingeniería de software convencional# 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 una14 solución previa en su ambiente) Dificultad para distinguir tecnologías nuevas Entienda las prioridades del cliente16 (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 de24 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 únicamente29 con base en personas-mes) -
  • Chapter 4. Principios de ingeniería de software convencional# Principios modificados Framework del proceso moderno1 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 temprana4 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ón9 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 datos17 Entre mas ve el cliente, mas el necesita objetivos para negociar solicitudes de cambio
  • Chapter 4. Principios de ingeniería de software convencional# Principios modificados Framework del proceso moderno Moderno: Complejo de aplicar pero se intenta predecir pequeños19 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 de20 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. Se27 (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, entrenamiento15 Asuma responsabilidad -30 Espere excelencia Tener altas expectativas del equipo
  • Chapter 4. Principios de ingeniería de software convencional# Principios que ya no aplican Framework del proceso moderno2 Alta calidad del software es posible (usar técnicas) Principio redundante5 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 desacoplados18 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ón22 Evite los trucos innovadora
  • Chapter 4. Principios de ingeniería de software convencional# Principios que ya no aplican Framework del proceso moderno Use la métrica de complejidad de McCabe (Complejidad ciclomática del SW, Identifica25 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 ser28 complejidad y desorganización) incorporados con estable y predecible resultados.
  • Acoplamiento Encapsulamiento y cohesión Inspección Código Modelo Análisis causas -error ProcesoCalidad 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ápidoAlta t cCalidad: r que herramientas Buena administración e 1.Problema o más importante que rPosible g 2.Requerimiento d buena tecnología a r a r Gente = clave del éxitoAl Cliente Tempranamente Siga con cuidadoPrioridades Asuma responsabilidad Entenderdel cliente Old Way & The New Evite los trucosEntre mas ve el No pruebe su propio swcliente, mas el Planee descartar Incrementarnecesita 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 software1. Aproximación de primera arquitectura (architecture-first)2. Proceso de ciclo de vida iterativo3. Desarrollo basado en componentes4. Ambiente de administración del cambio5. Ingeniería de Round-trip6. Notación basada en modelos7. Control cualitativo de objetivos8. Aproximaciones basados en demostración9. Evolucionar en niveles de detalle10. Procesos configurables
  • Chapter 4. Principios de administración moderna del software1. Base del proceso en un enfoque de primera arquitectura (architecture- first) – Balance entre levantamiento de requerimientos, decisiones de arquitectura, y planes2. 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.
  • Chapter 4. Principios de administración moderna del software4. 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
  • Chapter 4. Principios de administración moderna del software 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 elIterative 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 deComponent-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 enChange management environment diferentes flujos de trabajo, compartiendo artefactos. Control de líneas base. Scope Creep Control Herramientas complementarias, ambientes integrados. AmbienteRound-trip engineering soportado en sincronización y automatización de información . Reduce ciclos de iteración manejando marcos de tiempo. Automatización
  • Chapter 4. Principios de administración moderna del software6. 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.
  • Chapter 4. Principios de administración moderna del software8. 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.
  • Chapter 4. Principios de administración moderna del software10. 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.
  • Chapter 4. Principios de administración moderna del softwareModel-based notation Evolución de la notación gráfica. UMLObjective 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 deDemonstration-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 paraEvolving 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 laConfigurable 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 deAbandonos Desgaste desarrollo tardíos y del inadecuados Stakeholdersexcesivo re- personal opositores trabajo claveIntroducció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.
  • Preguntas?
  • 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 delinvestigació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
  • Chapter 5. Estados del ciclo de vida• 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)
  • Chapter 5. Estados del ciclo de vida • Actividades de investigación y desarrollo • Menos predecible • Pequeños equiposEstado de • Actividades de diseño y síntesisIngeniería • Fases de Inicio y Elaboración • Actividades de producción • Mas predecible • Equipos mas grandesEstado de • Actividades de construcción, pruebas y despliegueProducció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• Objetivos Primarios – 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• ¿Cuáles son los criterios de evaluación básicos?
  • Chapter 5. Fase de construcción• Objetivos Primarios – 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• ¿Cuáles son los criterios de evaluación básicos?
  • Chapter 5. Fase de transición• Objetivos Primarios – 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• ¿Cuáles son los criterios de evaluación básicos?
  • Preguntas?
  • Part II. A Software Management 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 trazabilidadCuá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?
  • Ejemplo: RUP
  • Modelamientode Negocio
  • Requerimientos
  • Análisis y Diseño
  • Implementación
  • Pruebas
  • Despliegue
  • Administración yControl deCambios
  • Ambiente
  • 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 revisarinformació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
  • Preguntas?
  • Part II. A Software Management 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 clarificarArquitectura: 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
  • Preguntas?
  • Part II. A Software Management Process Framework Workflows of the process
  • Chapter 8. Flujos de Trabajo del proceso Flujo de Artefactos Énfasis del ciclo de vida TrabajoAdministració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 •WBSAmbiente •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 cambiosRequerimientos •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 TrabajoDiseñ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 componentesImplementació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 componentesEvaluació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 despliegueDespliegue •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. IteracionesAdministración Administración Requerimientos Requerimientos Diseño Diseño Implementación Implementación Evaluación Evaluación Despliegue DespliegueFases 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 deconstrucción
  • Preguntas?
  • Part II. A Software Management 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ónHitos 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 funcionalidadObjetivos 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ónHito: •Plan avanzado •Visión estable y modelo de cu •Set estable de diseñoArquitectura 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íticosHito: Inicio •Plan avanzado •Criterios aceptación para •Set estable de implementaciónOperacional de Transición entrega del producto •Core y funcionalidad crítica •Manual de usuario de la •Objetivos de calidad del entrega productoHito: Entrega •Plan siguiente •Manual final de usuario •Set estable de desplieguedel producto generación del •Funcionalidad completa producto •Cumplimiento de calidad
  • Chapter 9. Hitos Menores Al final de cada iteración evaluarAl inicio de cada iteración cumplimiento depara revisar y preparar el objetivos, resultados,plan y criterios de pruebas, e impactoevaluación para iteración siguiente
  • Chapter 9. Evaluación periódica de estado Personal Tendencias Financieras Top 10 de Progreso Riesgos TécnicoAlcance total Planes ydel Producto Resultados de Hitos Mayores
  • Preguntas?
  • 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 convencional1. 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
  • Chapter 10. Problemas del WBS convencional2. 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
  • Chapter 10. Problemas del WBS convencional3. 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 faseActividades • Mas bajo nivel de la jerarquía que recolecta los costos de artefactos discretos • Descompuesto en un nivel mas bajo
  • Chapter 10. WBS moderno• 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
  • Chapter 10. WBS moderno• 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%
  • Chapter 10. Proceso de estimación• 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
  • Chapter 10. Proceso de estimación• 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
  • Chapter 10. Proceso de estimación• 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.
  • Chapter 10. Planeación de las iteraciones• 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)
  • Chapter 10. Planeación de las iteraciones• 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.
  • Chapter 10. Planeación de las iteraciones• 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
  • Preguntas?
  • Tareas en MsProject• Ingreso de Tareas de Resumen1. Ver, Diagrama de Gantt2. Click en celda de Nombre3. Escribir el nombre de la tarea4. Agregar, si se desea, Notas de Tareas5. Oprimir Enter para ir a la siguiente tarea• Ingreso de Tareas de Detalle1. Click en la línea donde se desee ingresar la tarea2. Insertar, Nueva Tarea u oprimir Insert3. Click en celda de Nombre4. Escribir el nombre de la tarea5. Si es necesario, incrementar la sangría de la tarea para mostrar dependencia
  • Tareas en MsProject• Ingreso de Hitos1. En el menú Ver, hacer clic en Diagrama de Gantt.2. Escribir 0 en el campo Duración de la tarea3. 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 hito6. 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 Repetitivas1. 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 tareas2. Disminuir la sangría de varias tareas3. Ocultar tareas de detalle4. Mostrar tareas de detalle5. Ocultar todas las tareas de detalle6. Revelar el siguiente nivel de detalle7. Mostrar un nivel determinado8. “Lo que se le haga al padre se le hace a toda la familia”9. Borrar tareas10.Copiar tareas11.Mover tareas
  • Tareas en MsProject• Cronogramas Dinámicos1. Tareas enlazadas mediante relaciones lógicas2. Minimización de fechas específicas3. Si algo cambia, todo el cronograma se ajustará automáticamente4. Se ahorrará mucho esfuerzo en mantenimiento
  • Tareas en MsProject• Dependencia1. Relación entre el fin (o comienzo) de una actividad y el comienzo (o fin) de otra2. Refleja la relación de causa-y-efecto entre las dos tareas3. 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 BLa actividad B no puede iniciar hastaque 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 hastaLa actividad B no puede terminar hasta que haya iniciado la actividad Aque haya terminado la actividad A
  • Tareas en MsProject• Aplicación de Adelantos y Posposiciones1. Absolutos 1. FC + 5d 2. FC – 3d2. Relativos 1. FC + 50% 2. FC – 30%
  • Tareas en MsProject• Utilizando el diálogo de Información de la Tarea1. Seleccionar la tarea sucesora2. Click en el icono Información de la tarea3. Click Predecesoras4. En el campo de tarea, buscar la predecesora deseada, o ingresar el ID en el campo correspondiente5. Seleccionar el tipo de dependencia6. Ingresar adelanto o retraso en su campo7. Click Aceptar
  • Tareas en MsProject• Utilizando la Forma de Tarea1. Ventana, Dividir2. Click derecho y seleccionar Predecesoras y Sucesoras3. Seleccionar la tarea sucesora4. En la forma, seleccionar la tarea sucesora mediante su ID, o escogiendo el nombre de la tarea5. Seleccionar el tipo de dependencia6. Ingresar adelanto o retraso en su campo7. Click Aceptar
  • Tareas en MsProject• Ingresar Estimación1. Los estimados se hacer en términos de 1. Duración de una tarea 2. Esfuerzo para realizar una tareaDuración:1. Se especifica en el campo de Duración2. 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, CalendarioEsfuerzo:1. Se especifica en el campo de Trabajo2. Se expresa en horas-persona3. 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 trabajo2. Unidades = cuántas unidades del recurso harán el trabajo3. Trabajo = cuántos días-persona tomará hacer el trabajo4. A MS Project se le informan dos de las tres variables, y él calcula la tercera
  • Tareas en MsProject• Recursos:1. Gente2. Edificios3. Máquinas4. Materiales necesarios para crear el producto del proyecto5. Generalmente, cada actividad requiere, al menos, un recurso6. Recursos ≠ Responsables7. 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 Humanos1. Aquellos cuyo esfuerzo se acumula el campo Trabajo2. Se ingresan como un recurso Trabajo3. La cantidad de trabajo por semana debe ser, como máximo, su disponibilidad4. Tienen un costo, que debe especificarse como $xxx/hr, $xxx/día, $xxx/sem, $xxx/ms5. Ingresar nombres genéricos o cargos
  • Tareas en MsProject• Planilla de Ingreso de Recursos1. Ver, Hoja de recursos2. Ver, Tabla: Entrada (Si no está en Entrada, cambiarla la tabla a Entrada)
  • Tareas en MsProject• Campos de la Planilla de Recursos1. Indicador: Despliega indicadores para diferentes situaciones2. Nombre del recurso: [requerido] Adoptar un estándar para evitar repeticiones involuntarias. Se sugiere utilizar: Apellido-Nombre3. 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 material5. Iniciales: [opcional]6. Grupo: [opcional] Puede utilizarse para indicar el Departamento al cual pertenece el recurso7. 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ándar5. 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ándar8. 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 Recursos1. Se parte de un calendario base2. Doble click en el recurso, para abrir el diálogo Información del recurso3. 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 semana6. 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 trabajo2. Unidades = cuántas unidades del recurso harán el trabajo3. Trabajo = cuántos días-persona tomará hacer el trabajo4. A MS Project se le informan dos de las tres variables, y él calcula la tercera5. Tipos de tareas de detalle – Duración fija – Unidades fijas – Trabajo fijo
  • Tareas en MsProject• Duración Fija1. Cuando el primer estimado es la duración2. Cuando la duración no cambia al adicionar recursos3. 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 primordial5. Cuando la carga de trabajo no es nuestra responsabilidad (el trabajo corresponde a un subcontratista o un consultor)
  • Tareas en MsProject• Unidades Fijas1. Cuando la cantidad de recursos para la tarea es lo primero que se conoce2. Cuando es imposible obtener más recursos3. 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 Fijo1. Cuando lo primero que se estima es el esfuerzo2. 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 fija2. Suministrar el segundo valor de la fórmula y dejar que MS Project calcule el tercero3. ¡Antes de realizar un cambio en cualquiera de los tres valores, considerar el tipo de tarea requerido!
  • Tareas en MsProjectDespués de asignar recursos, cada tarea se programa de acuerdo con la fórmula:
  • Tareas en MsProject• Formato del Diagrama de Gantt
  • Preguntas?
  • Part III. Software Management 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
  • Chapter 11. Organizaciones de líneade negocio
  • Chapter 11. Organizaciones de líneade 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.
  • Chapter 11. Organizaciones de línea de negocioPRA:•Asegurar que el proyecto desoftware cumple con todas laspolíticas, practicas y estándaresde la línea de negocio y de laorganización junto con lasobligaciones contractuales delproyecto.
  • Chapter 11. Organizaciones de líneade 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)
  • Chapter 11. Organizaciones de línea de negocioSEEA:•Proporciona soporte arecursos humanos,investigación, desarrolloindependiente de losproyectos.•Componentes típicos: •Administración de proyectos •Centro de skills de ingeniería •Desarrollo profesional
  • Chapter 11. Organizaciones de línea 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 condicionesfavorables para todos losstakeholders (Continuasnegociaciones de triplerestricción)•Planeación de esfuerzo yadministración del plan(adaptación al cambio)
  • Chapter 11. Organizaciones por proyectos•Balancear condicionesfavorables para todos losstakeholders (Continuasnegociaciones de triplerestricción)•Planeación de esfuerzo yadministración del plan(adaptación al cambio)•Actividades en el ciclo de vidadel proyecto (Pág. 160)
  • Chapter 11. Organizaciones porproyectos
  • Chapter 11. Organizaciones por proyectos•Balancear condicionesfavorables para todos losstakeholders (Continuasnegociaciones de triplerestricción)•Planeación de esfuerzo yadministración del plan(adaptación al cambio)•Actividades en el ciclo de vidadel proyecto (Pág. 161)
  • Chapter 11. Organizaciones por proyectos•Divididos en subgrupos porcomponentes que requieren unskill común: Componentescomerciales, DB, GUI,Sistemas operativos y redes,dominio de la aplicación.•Responsable de la calidad deun componente individual.•Actividades en el ciclo de vidadel proyecto (Pág. 162)
  • Chapter 11. Organizaciones porproyectos •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
  • Preguntas?
  • Part III. Software Management 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 estimación del costo Rendimiento, Herramientas y confiabilidad, tecnologías de exactitud, control automatización estadístico CALIDAD AMBIENTEISO 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 equiposEstado de • Actividades de diseño y síntesisIngeniería • Fases de Inicio y Elaboración • Actividades de producción • Mas predecible • Equipos mas grandesEstado de • Actividades de construcción, pruebas y despliegueProducción • Fases de Construcción y de transición
  • RECORDANDO… Principios de administración modernaArchitecture-first approach Primero diseñar e integrar, entonces producir y probar Diseño centralIterative life-cycle process Control de riesgos en cada incremento Administración de riesgosComponent-based development Métodos OO, notaciones, modelos visuales TecnologíaChange management environment Métricas, tendencias, instrumentos ControlRound-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 faseActividades • Mas bajo nivel de la jerarquía que recolecta los costos de artefactos discretos • Descompuesto en un nivel mas bajo
  • Chapter 12. 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 12. Introducción• Importante: Definición y Adaptación del proceso pero también se requiere cierto nivel de automatización de los procesos. Manejo de actividades concurrentes y evaluación tangible del proceso y la calidad.• Estado de Ingeniería: Tareas de Automatización del ambiente de desarrollo y Establecimiento de una infraestructura que soporte los flujos de trabajo del proyecto.• Evolucionar el ambiente de desarrollo en el ambiente de mantenimiento.• Ambiente: Flujo de trabajo de primera clase. Artefacto tangible que es critico para los costos del ciclo de vida del sistema que está siendo desarrollado.
  • Chapter 12. Niveles de procesos• Cada nivel tiene un cierto grado de automatización soportada: – Metaprocesos: Nivel de automatización: INFRAESTRUCTURA: Inventario de herramientas preferidas, plantillas de artefactos, etc. – Macroprocesos: Nivel de automatización: AMBIENTE: Colección de herramientas para producir un conjunto específico de artefactos gobernados por un plan de proyecto específico. – Microprocesos: Nivel de Automatización: HERRAMIENTA: Incluye herramientas de administración de requerimientos, modelado visual, automatización de métricas, etc.
  • Chapter 12. Disciplinas de Ambiente• 4 Disciplinas importantes en administración que son críticas para el éxito de un proceso de desarrollo iterativo moderno: – INGENIERÍA ROUND –TRIP : Consistencia y Trazabilidad. – ADMINISTRACIÓN DE CAMBIOS: Manejo de múltiples iteraciones y libertad de cambio. – INFRAESTRUCTURA: Ambiente del proyecto derivado de una base común de procesos y herramientas. Consistencia, Reusabilidad. – AMBIENTE DE LOS STAKEHOLDERS: Menos intercambio de papeles y mas efectiva revisión de los artefactos.
  • Chapter 12. Herramientas (Microproceso)• Administración: Planeación y control de proyecto. Estimación de costos, WBS, Administración de flujos de trabajo, recolección y reporte de métricas.• Ambiente: Administración de la configuración, Control de versiones (medidas de cambios).• Requerimientos: automatización de documentos integrada, modelamiento visual para capturar especificaciones textuales, modelos de casos de uso, trazabilidad.
  • Chapter 12. Herramientas (Microproceso)• Diseño: Modelamiento visual, presentación en formato humano y traslado a código fuente.• Implementación: Ambiente de programación, integración con herramientas de control de cambios, modelado visual, automatización de pruebas.• Evaluación y Despliegue: automatización y administración de pruebas, automatización de documentación, Seguimiento de defectos, automatización de cambios, métricas y control de liberación de líneas base.
  • Chapter 12. Ambiente del proyecto (Macroproceso)• Ambiente de generación de prototipos: Banco de pruebas de arquitectura. Configuración informal de herramientas. Evaluar los trade-offs: Rendimiento, riesgos técnicos, hacer o comprar, estudio de productos comerciales, tolerancia a fallos.• Ambiente de desarrollo: Incluye una suite completa de herramientas de desarrollo para soportar los flujos del proceso y ingeniería round-trip.• Ambiente de mantenimiento: Debería coincidir con una versión madura del ambiente de desarrollo. Podría incluir un subconjunto del ambiente de desarrollo donde se liberan los productos del proyecto.
  • Chapter 12. Ambiente del proyecto (Macroproceso)• Ingeniería Round-Trip – Mayor eficiencia – Mayor consistencia: Menor cantidad de errores durante la transición de datos de un set a otro. – Control de la configuración – Revisar necesidad de trazabilidad bidireccional – Traducción parcial de un set de artefactos a otros.
  • Chapter 12. Ambiente del proyecto (Macroproceso)• Administración de cambios – Es tan crítico como la planeación. – Ayuda a entender las tendencias en el progreso y en la calidad – Artefactos evolucionan en múltiples generaciones. – Ordenes de cambio: Software Change Orders (SCO) – Líneas base de configuración: Configuration Baseline – Comité de control de cambios: Configuration Control Board (CCB)
  • Chapter 12. Ambiente del proyecto (Macroproceso) Comité de Ordenes de Línea base de control deCambio (SCO) configuración cambios (CCB) Colección de componentes de Equipo de personas que tienen Unidad atómica de trabajo software y su documentación decisión sobre el contenido de autorizado las líneas base Sujeta a administración de cambios como una unidad. Equipo interdiciplinario.Crear, modificar, o eliminar por Dos clases de líneas base:obsolescencia componentes de Externas e Internas (N.M.X) una línea base. Control riguroso sobre la admón de cambios. Paquete de intercambio entre grupos.Información a contener: Titulo, descripción, métricas, Estados (propuesto, aceptado,desarrollo, pruebas, disposición Categorías de cambios: Critico, rechazado, en progreso, en defecto, cambio, otros. evaluación, cerrado)
  • Chapter 12. Infraestructura (Metaproceso)• Política de la organización: Estándares del proceso de desarrollo de software. Enfocarse en las líneas de negocio. • ¿Qué hacer? (Actividades y Artefactos) • ¿Cuándo hacerlo? (Fases del ciclo de vida e hitos) • ¿Quién lo hace? (Roles y Responsabilidades del equipo) • ¿Cómo evaluamos? (Puntos de chequeo, métricas, estándares de performance)• Ambiente de la organización: Inventario de herramientas desde las cuales el ambiente del proyecto puede configurarse de forma económica y eficientemente. • Estándar de selección de herramientas, • Estándar de notación de artefactos • Plantillas de actividades y artefactos • Otros componentes útiles: Librería de referencia, casos de estudio, ejemplos, Framework de evaluación.
  • Chapter 12. Ambientes de los stakeholders• Soporte del proceso en la automatización no debería ser restringido al ambiente de desarrollo.• Se requiere que todos los stakeholders representativos también puedan acceder a los recursos del ambiente de desarrollo.• Evitar intercambio de información vía papel. Promover el uso de Recursos disponibles electrónicamente vía online: Feedback mas eficiente
  • Preguntas?
  • Part III. Software Management Disciplines Project Control & Process Instrumentation
  • Chapter 13. Introducción• Características básicas de unas buenas métricas: – Tiene sentido para todos los stakeholders. – La definición es objetiva y no es ambigua. Representación numérica y unidades de medida bien definida. – Muestra una tendencia. – Es derivada naturalmente de los productos del proceso. No genera mas artefactos o carga de actividades. – Se puede automatizar.
  • Chapter 13. Automatización de métricas• El uso de métricas no reemplaza la toma de decisiones. Sólo proporciona datos que ayudan a hacer las preguntas correctas, entender el contexto para tomar decisiones objetivas.• Software Project Control Panel Dashboard del proyecto Integrar los datos desde múltiples fuentes para mostrar el estadoRoles: Monitor y Administrador actual de algún aspecto del proyecto Proporcionar alertas, tendencias
  • Chapter 13. Las 7 métricas Principales• Características de las 7 métricas: – Simples, objetivas, fáciles de recopilar y de interpretar – Fáciles de automatizar y no son intrusivas – Evaluación consistente a través del ciclo de vida y su fidelidad mejora a través del mismo. – Derivadas de la evolución de las líneas base del producto. – Útiles para comunicar el progreso y la calidad tanto al grupo de gerencia como al de ingeniería.
  • Chapter 13. Las 7 métricas Principales• Indicadores Gerenciales – Trabajo y progreso (trabajo ejecutado en el tiempo) – Costo presupuestado y gastado (costo incurrido en el tiempo) – Staff y dinámica de los equipos (cambios en el personal en el tiempo)• Indicadores de Calidad – Frecuencia de cambios y estabilidad (Frecuencia de cambios en el tiempo) – Breakage y Modularidad (Promedio de breakage por cambio en el tiempo) – Retrabajos y adaptabilidad (Promedio de retrabajo por cambio en el tiempo) – Tiempo medio entre fallas (MTBF) y madurez (rata de defectos en el tiempo)
  • Chapter 13. Las 7 métricas Principales
  • Chapter 13. Indicadores Gerenciales• Trabajo y progreso (trabajo ejecutado en el tiempo)• Medir el trabajo planeado estimado contra el progreso actual• Métricas para cada equipo: – Equipo de arquitectura: Casos de uso demostrados – Equipo de desarrollo: SLOCs desarrollados y SCOs cerrados. – Equipo de evaluación: SCOs cerrados, horas de pruebas ejecutadas, criterios de evaluación encontrados. – Equipo de administración: Hitos completados.
  • Chapter 13. Indicadores Gerenciales• Costo presupuestado y gastado (costo incurrido en el tiempo) – Planear a detalle solo las actividades e iteraciones cercanas. Gráficas tomadas de PMI. Practice Standard for Earned Value Management
  • Chapter 13. Indicadores Gerenciales• Costo presupuestado y gastado (costo incurrido en el tiempo) Tomado de Royce Walker. Software Project Management Pág. 194. Tomado de PMI. Practice Standard for Earned Value Management
  • Chapter 13. Indicadores Gerenciales• Staff y dinámica de los equipos (cambios en el personal en el tiempo) – Low attrition of good people is a sign of success.Equipo pequeño.Resolver riesgos
  • Chapter 13. Indicadores de Calidad• Frecuencia de cambios y estabilidad (Frecuencia de cambios en el tiempo) – Tendencia del schedule e indicador de que también el proceso es ejecutado. – Frecuencia de cambios: Número de Ordenes de cambio abiertas y cerradas en el ciclo de vida. Puede ser por tipo de cambio, release, equipo, componente, entre otros. – Estabilidad: Relación entre SCOs Abiertas versus Cerradas.
  • Chapter 13. Indicadores de Calidad• Breakage y Modularidad (Impacto por cambio en el tiempo) – Breakage: Impacto en el producto resultado de un cambio en requerimientos. Cantidad de SLOC u otra medida de la línea base de software que necesita ser re-trabajada. – Modularidad: Tendencia de breakage en el tiempo Para un proyecto se espera una tendencia a disminuir o por lo menos a ser estable.
  • Chapter 13. Indicadores de Calidad• Retrabajos y adaptabilidad (Promedio de retrabajo por cambio en el tiempo) – Retrabajo: Costos promedio de el cambio. Incluye el esfuerzo para analizar, resolver y volver a probar todos los cambios de la línea base. – Adaptabilidad: Tendencia del retrabajo en el tiempo. Para un proyecto se espera una tendencia a disminuir o por lo menos a ser estable. Si el comportamiento es diferente puede significar poca mantenibilidad
  • Chapter 13. Indicadores de Calidad• Tiempo medio entre fallas (MTBF) y madurez (rata de defectos en el tiempo) – MTBF: Tiempo de uso promedio entre fallas. – Madurez: Tendencia de MTBF en el tiempo. Errores deterministicos (Bohr-bugs) y Errores no deterministicos (Heisen-bugs) Bohr-bugs represent a class of errors that always result when the software is stimulated in a certain way way. Heisen-bugs are software faults that are coincidental with a certain probabilistic occurrence of a given situation.
  • Preguntas?
  • Part III. Software Management Disciplines Tailoring the Process
  • Chapter 14. Introducción• Adaptar el proceso a necesidades específicas del proyecto• La escala del proyecto –tamaño- direcciona la configuración del proceso• Otros factores críticos son las relaciones entre involucrados, flexibilidad, madurez del proceso, riesgos de arquitectura y experiencia.
  • Chapter 14. Diferencias del proceso• Dimensiones de factores: Técnico y Administración
  • Chapter 14. Escala• Formas de medir la escala: Numero de líneas de código Numero de puntos funcionales Numero de casos de uso Numero de dólares o pesos• Para la perspectiva de adaptación del proceso la medida principal de escala es el tamaño del equipo de trabajo.
  • Chapter 14. Escala• Prioridades de la adaptación del proceso
  • Chapter 14. Escala Proyectos enormes Proyectos - 625 personas largos - Varios PM’s y Proyectos sub PM’s de tamaño - 125 personas -Madurez en Proyectos moderado - Notable artefactos pequeños Administración - Cambios:Proyectos de - 5 personas - 25 personas - Madurez en replaneacióntamaño trivial artefactos - Rendimiento - Muy Poca - Administración Administración Moderada - Hitos formales y del proyecto - No - Hitos fáciles - Comunicación cambios costosos depende de administración - Madurez media de - Rendimiento entre - Poca necesaria personas depende de involucrados documentación - Ambiente - Madurez skills - Hitos formales - Mayor integrado obligatoria - Madurez no - Madurez tiene dependencia de - Alta tiene valor skills experiencia importancia
  • Chapter 14. Cohesión y Competencia de Involucrados Cohesión • Equipos Cohesivos: Objetivos comunes, skills complementarios, buena comunicación • Equipos Rivales: ProblemasCompetencia comunes, skills incompletos o rivalidades, mucha menos comunicación
  • Chapter 14. Cohesión y Competencia de Involucrados• Diferencias del proceso que resultan en diferencias de cohesión de involucrados
  • Chapter 14. Flexibilidad o Rigor del proceso• El grado de rigor, formalidad, y libertad de cambio de un contrato específico tienen impacto en la implementación del proceso del proyecto• Para un contrato holgado, por ejemplo implementar un software comercial en un área de negocio de una empresa, la complejidad administrativa es mínima.• Para un contrato riguroso, por ejemplo la autorización de un cambio en el plan de entrega puede tardar meses.
  • Chapter 14. Flexibilidad o Rigor del proceso• Diferencias del proceso que resultan en diferencias de flexibilidad del proceso
  • Chapter 14. Madurez del proceso• La madurez del proceso es definida por el SEI (Sw Engineering Institute) como una clave de la complejidad administrativa. Administrar un proceso maduro (Nivel 3 o mayor) es más simple que manejar un proceso inmaduro (Nivel 1 y 2).• Adaptar un proceso maduro de una organización en un proyecto específico es generalmente una tarea más sencilla.
  • Chapter 14. Madurez del proceso• Diferencias del proceso que resultan en diferencias de madurez del proceso
  • Chapter 14. Riesgos de arquitectura y Dominio o Experiencia • Fuentes comunes de riesgos: utilización de recursos,Riesgos de incorporación de nuevasArquitectura tecnologías, tiempos de respuesta, inclusión de nueva funcionalidad, adaptación a condiciones dinámicas de la operación, tolerancia de fallos • La experiencia gobierna la habilidad Dominio o de tener una arquitectura aceptableExperiencia en el menor numero de iteraciones, menos retrabajo, menos administración de riesgos, menos frecuencia en avance del proyecto
  • Chapter 14. Distribución de tiempo• Diferencias en distribución de tiempo entre fases entre un proyecto pequeño y largo Dominio Inicio Elaboración Construcción TransiciónProyectos 10% 20% 50% 20%comercialespequeñosProyectos 15% 30% 40% 15%largos,complejos
  • Preguntas?
  • Part IV. Looking Forward Modern Project Profiles
  • Chapter 15. Perfil de Proyectos Modernos Alcance de Integración prolongada Enfocar arquitectura-primero y cambios tardíos en el diseño RiesgosRealizar Tener Resolver tarde Descomposición funcional deIntegración dentro Inconvenientes de requerimientosdel estado de proyectos Aplicaringeniería convencionales Profundizar en Tener Documentos y Foco Detalle dereuniones de revisión en Relaciones requerimientos a difíciles con los lo largo de las Reemplazar con stakeholders entregas Resultados demostrables, Proveer artefactos bien definidos, Resultados objetivos notación, automatización y tangibles
  • Chapter 15. Integración Continua• Diferencias de costo
  • Chapter 15. Resolución temprana de Riesgos• Perfil de riesgo – proyectos modernos
  • Chapter 15. Evolución de Requerimientos• Organización de componentes de sw - proyectos modernos
  • Chapter 15. Trabajo en Equipo• Resultado de Hitos mayores – proyectos modernos
  • Chapter 15. Top 10 Proceso Desarrollo Iterativo Ambiente de basado en Administración componentes Alcance: de cambiosArquitectura- primero Ingeniería Principios de Actualizada Proceso Administración configurable de Software Notación basada en Desarrollar modelamiento niveles de detalle Control de Alcance basado calidad en demostración objetivo
  • Chapter 15. 9 Mejores Prácticas Riesgo Acuerdos Inspecciones s con formales Interfaces Cuidado de las personas Administración y Administración planeaciónAdministración de Software basada enconfiguración métricas Seguimiento dedefectos respecto Seguimiento Establecimiento criterios de de progreso de Hitos calidad vs planeación
  • Preguntas?
  • Parte IV. Looking ForwardNext-Generation Software Economics
  • Chapter 16. Perfil de Proyectos ModernosPuntos Clave: Las siguientes generaciones de software debenreflejar mejores economías de escala y retorno de lainversión Los Modelos de costo necesitan basarse en mejoresunidades base que vengan de notaciones de ingeniería desoftware bien estructuradas como UML Los avances de tecnología en round-trip engineeringson críticos para realizar el siguiente salto en la economíadel software.
  • Chapter 16. Modelos de CostoCómo el modelo de costo debe estructurarse para soportar la estimación de un proceso de software moderno?• Separar la arquitectura de la producción de la aplicación.• El costo de diseñar, producir, probar y mantener la línea base de arquitectura es una función de escala, calidad, tecnología, proceso y skills del equipo de trabajo.
  • Chapter 16. Modelos de Costo
  • Chapter 16. Modelos de CostoCómo el modelo de costo debe estructurarse para soportar la estimación de un proceso de software moderno?• Estimar arquitecturas de estala-larga con economías de escala. A medida que el proyecto sea largo, mas oportunidades de automatización, reutilización de procesos, componentes y arquitecturas.• Alcanzar niveles de automatización y estandarización para soportar overhead en actividades de planeación del proyecto, control y administración de cambios.• Reutilizar procesos comunes a través de múltiples iteraciones, entregas y proyectos, que mitiguen muchas de las causas de la economía de escala, como retrabajo y basura.
  • Chapter 16. Modelos de CostoCómo el modelo de costo debe estructurarse para soportar la estimación de un proceso de software moderno?• Establecer planes confiables y trabajables, basados en normas del proyecto, métricas y resultados.• Reutilizar componentes reduce el esfuerzo de desarrollar el tamaño. Reutilizar procesos, herramientas y experiencia impacta directamente en la escala de la economía.• La escala debe ser medida en términos de elementos significativos de arquitectura (clases, componentes, procesos).• El tamaño debe ser medido en SLOC o Puntos funcionales.• Utilizar una notación rigurosa para artefactos de diseño.
  • Chapter 16. Modelos de CostoDos grandes mejoras para la siguiente generación: Separar estado de ingeniería del estado de producción para diferenciar entre arquitectura e implementación, y permitir mayor precisión y certeza en las estimaciones. Utilizar notación rigurosa en el diseño (ej. UML) para definir unidades de medida más estándar, automatizar y controlar.
  • Chapter 16. Automatización del procesode construcción
  • Chapter 16. Economía Moderna del SwEncontrar y Ajustar problemas de sw después de la entrega cuesta 100veces más que encontrar y ajustar problemas en fases tempranas de diseño.Usted puede comprimir cronogramas de desarrollo de sw en 25%, pero noen más.Por cada $1 gastado en desarrollo, usted va a gastar $2 en mantenimiento.El costo del desarrollo y mantenimiento de sw está en función del número delíneas de código.Las variaciones entre personas se deben considerar para las mayoresdiferencias en la productividad del sw.La proporción general del costo entre sw y hw va creciendo. En 1955 15:85;en 1985 85:15.
  • Chapter 16. Economía Moderna del SwSólo cerca del 15% del esfuerzo en desarrollo de sw es programación.Sistemas y productos de sw típicamente cuentan 3 veces más por SLOC queprogramas individuales de sw. Productos de Sistemas de sw cuestan 9 vecesmás.Walkthroughts capturan 60% de los errores.80% de la contribución viene del 20% de los contribuyentes.
  • Preguntas?
  • Parte IV. Looking Forward Modern Process Transitions
  • Chapter 17. Transición a Procesos ModernosPuntos Clave La transición a procesos modernos de sw requiere cambios severos que no son fáciles de alcanzar. Las lecciones aprendidas en la transición de una organización a un proceso moderno exponen muchos temas recurrentes de éxito que representan los cambios culturales de una práctica convencional. Una transición significativa debe intentarse en un proyecto significativo. Los proyectos piloto generalmente no atraen talentos top, lo cual es crucial para el éxito de cualquier transición significativa.
  • Chapter 17. Transición a Procesos Modernos Niveles bajo y Requerimientos Fomentar medio de y diseño son Organizaciones Demostraciones administración fluidos ybuenas de sw deben ambiciosas son prácticos tangibles ser más rentables IdentificarInconvenientes en el tempranamente el rendimiento crecen rendimiento tempranamente Cambios bueno/malo de los culturales proyectos Es necesaria la inversión en Incrementos automatización tempranos van a ser inmaduros El aseguramiento Los inconvenientes Los artefactos son menos de la calidad es reales son generales y importantes temprano, y más un trabajo de resueltos importantes después todos sistemáticamente
  • Chapter 17. ConclusiónProceso Convencional Proceso Moderno Iterativo Proceso Secuencial  Round-trip engineering desde Alcanza 100% de completitud requerimientos hasta pruebas para cada artefacto en cada  Alcanza alto entendimiento de los estado de ciclo de vida lineamientos (20%) tan temprano Trata todos los requerimientos, y práctico como sea posible artefactos, componentes de igual  Desarrolla artefactos en forma profundidad basado en Alcanza alta trazabilidad entre prioridades de administración de todos los artefactos de cada riesgos. estado en el ciclo de vida  Pospone análisis de completitud y consistencia hasta tarde en los ciclos de vida
  • Chapter 17. Conclusión
  • Preguntas?