SSD10- Software ProjectOrganization & Management         iCarnegie
Part I. Software Management              RenaissanceFramework que introduce aproximaciones modernas aproblemas convenciona...
Chapter 1. Administración                    convencional del SwFlexibilidad del software:   – Ventajas: Se puede programa...
Chapter 1. Administración convencional     del Sw• Análisis del estado de la industria de Software (90’s)• Indicador de éx...
Chapter 1. Administración convencional del Sw• Solamente 1/3 de PMs consideran como una prioridad  terminar el proyecto en...
Chapter 1. Modelo en cascada– 1ª Parte: Dos pasos básicos para construir sw1970: “Managing the Development of Large Scale ...
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 dis...
Chapter 1. Modelo en cascadaPráctica del modelo Cascada(Conventional Software management approach)Síntomas frecuentes de p...
Chapter 1. Modelo en cascada–   Integración prolongada y cambios tardíos en el    diseño                 5%        10%    ...
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”  ...
Chapter 1. Métricas de                   la industria de SW1987-Barry Boehm’s: “Industrial Software Metrics Top 10 List”  ...
Chapter 1. Métricas de la                      industria de SW1987-Barry Boehm’s: “Industrial Software Metrics Top 10 List...
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   – Reso...
Chapter 2. Economía del Software• Modelos de costos: 1 Función con 5 parámetros                                   PROCESO ...
Chapter 2. Economía del Software• Modelos de costos paramétricos                      Esfuerzo =    (Personas)(Ambiente)(C...
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 da...
Chapter 2. ¿SLOC o Function Point?                       Fácil de automatizar                                          Mét...
Chapter 2. Proceso de estimación             de costos• Modelo de Costos: Bottom up mas usado que Top Down• Mantener en me...
Chapter 2. Atributos de una buena             estimación Concebida y soportada por PM, equipo de arquitectura,  equipo de...
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 alca...
Chapter 3. Balance entre dimensiones                                                                                      ...
Chapter 3. Reduciendo el tamaño               del producto• Producto que cumpla los requerimientos con la  mínima cantidad...
Chapter 3. Reduciendo el tamañodel producto          • Reducir la cantidad de            código generado por el           ...
Chapter 3. Reduciendo el tamaño                      del producto  • Métodos orientados a objetos y Modelamiento Visual   ...
Chapter 3. Reduciendo el tamaño            del producto• Reuso  – Reuso de arquitecturas comunes, procesos comunes,    exp...
Chapter 3. Mejorando el proceso              de desarrolloPerspectivas del proceso:                     Políticas, procedi...
Chapter 3. Mejorando el proceso             de desarrollo• Proceso de proyecto = Actividades productivas +  actividades de...
Chapter 3. Mejorando la efectividad              de los equiposAdministración de equipo:   – Un equipo bien manejado puede...
Chapter 3. Mejorando la automatización   Herramientas                                  Mejora del 20%        de           ...
Chapter 3. Alcanzando la calidad               requerida• Prácticas claves que mejoran la calidad del software   – Requeri...
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 desarrol...
Chapter 4. Puntos claves• La ingeniería de software convencional tiene numerosos principios que  están bien establecidos. ...
Chapter 4. Principios de ingeniería                        de software convencional1.   Haga de la calidad lo primero2.   ...
Chapter 4. Principios de ingeniería                        de software convencional8. Minimizar la distancia intelectual9....
Chapter 4. Principios de ingeniería                        de software convencional16.Entienda las prioridades del cliente...
Chapter 4. Principios de ingeniería                        de software convencional24.Use los principios de acoplamiento y...
Chapter 4. Principios de ingeniería                          de software convencional#    Principios que se mantienen     ...
Chapter 4. Principios de ingeniería                          de software convencional#    Principios que se mantienen     ...
Chapter 4. Principios de ingeniería                          de software convencional#    Principios modificados          ...
Chapter 4. Principios de ingeniería                        de software convencional#    Principios modificados         Fra...
Chapter 4. Principios de ingeniería de              software convencional#    Principios generales             Framework d...
Chapter 4. Principios de ingeniería                        de software convencional#    Principios que ya no aplican      ...
Chapter 4. Principios de ingeniería                        de software convencional#    Principios que ya no aplican      ...
Acoplamiento       Encapsulamiento                        y cohesión                   Inspección Código                  ...
Chapter 4. Principios de administración          moderna del software1.    Aproximación de primera arquitectura (architect...
Chapter 4. Principios de administración        moderna del software1. Base del proceso en un enfoque de primera arquitectu...
Chapter 4. Principios de administración            moderna del software4.       Establecer un ambiente de configuración de...
Chapter 4. Principios de administración                 moderna del software                                              ...
Chapter 4. Principios de administración          moderna del software6. Capturar los artefactos de diseño en una rigurosa ...
Chapter 4. Principios de administración            moderna del software8.   Usar un enfoque basado en la demostración para...
Chapter 4. Principios de administración           moderna del software10. Establecer un proceso configurable que sea escal...
Chapter 4. Principios de administración               moderna del softwareModel-based notation                            ...
Chapter 4. Riesgos mitigados                                       Recursos deAbandonos             Desgaste          desa...
Chapter 4. Beneficios económicos.         Comparación con factores de COCOMO• Application precedentedness (proceso iterati...
Chapter 4. Beneficios económicos.           Comparación con factores de COCOMO• Team Cohesion (diseño basado en modelos y ...
Preguntas?
Part II. A Software Management        Process Framework         Life-Cycle Phases
Chapter 5. Estados del ciclo de vida                                       • Adecuado balance.                            ...
Chapter 5. Estados del ciclo de vida• Proceso de desarrollo de SW moderno   – Evolución de los artefactos con puntos de   ...
Chapter 5. Estados del ciclo de vida             •   Actividades de investigación y desarrollo             •   Menos prede...
Chapter 5. Ciclo de vida convencional• Las fases tiene el nombre de las actividades primarias• Proceso secuencial• Desarro...
Chapter 5. Modelo en espiral                   • Proceso iterativo  Inicio (Idea)    • Cada fase incluye todas las        ...
Chapter 5. Rational Unified Process
Chapter 5. Fase de inicio• Objetivos Primarios   –   Establecer alcance y condiciones límites   –   Detectar casos de uso ...
Chapter 5. Fase de elaboración• Objetivos Primarios   –   Generar una línea base de arquitectura   –   Generar una línea b...
Chapter 5. Fase de construcción• Objetivos Primarios   – Minimizar los costos de desarrollo, optimizando recursos y evitan...
Chapter 5. Fase de transición• Objetivos Primarios   – Alcanzar un producto que pueda ser soportado por el usuario   – Alc...
Preguntas?
Part II. A Software Management        Process Framework       Artifacts of the process
Chapter 6. Artefactos del Proceso                                  • Enfoque: Desarrollo secuencial de                    ...
Chapter 6. Conjunto de artefactos•       Set: Artefactos relacionados que tienen un formato        de representación unifo...
Chapter 6. Como evaluar un set de                artefactos• Analizar consistencia y calidad con documentos previos• Anali...
Chapter 6. Artefactos de Ingeniería• Requerimientos                      • Implementación   – Documento de Visió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                       – Descripc...
Chapter 6. Inconvenientes culturales  Las personas       Las personas quieren revisar    quieren revisarinformación pero  ...
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 ...
Chapter 7. Arquitecturas de Sw     •Diseño:     Estructuras y funciones del modelo de diseño.     •Proceso:     Concurrenc...
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  ...
Chapter 8. Flujos de Trabajo del proceso   Flujo de            Artefactos                     Énfasis del ciclo de vida   ...
Chapter 8. IteracionesAdministración                              Administración   Requerimientos                         ...
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...
Chapter 9. Revisiones a través del proceso                  Al final de cada Fase                  Proveen visibilidad d...
Chapter 9. Secuencia Puntos Control
Chapter 9. Hitos Mayores   Hitos            Planes                Espacio de                    Espacio de Solución       ...
Chapter 9. Hitos Menores                                Al final de cada                                iteración evaluarA...
Chapter 9. Evaluación periódica de estado Personal         Tendencias                  Financieras   Top 10 de      Progre...
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 ...
Chapter 10. Introducción• Planeación: Requiere un proceso iterativo• Plan:    – Pieza intangible de propiedad intelectual ...
Chapter 10. WBS• WBS: Work Breakdown structures• EDT: Estructura de Descomposición del Trabajo• WBS es dependiente del est...
Chapter 10. WBS•   Tipos de descomposición: por subsistemas, por    componentes, por fases, etc.•   WBS es la base para el...
Chapter 10. Problemas del WBS                   convencional1. Estructura temprana                • Ejemplo:   alrededor d...
Chapter 10. Problemas del WBS                       convencional2.       Descomposición temprana con mucho o muy poco deta...
Chapter 10. Problemas del WBS                   convencional3. Específico para un proyecto, haciendo difícil   comparación...
Chapter 10. WBS moderno              Administración, ambiente, requerimientos, diseño, Workflows       implementación, eva...
Chapter 10. WBS moderno•   Organizado alrededor del proceso y no del    producto (Workflows, fases, actividades)•   Mejor ...
Chapter 10. WBS moderno•       Plantilla que debe ser ajustada dependiendo de:    –      Tamaño del proyecto    –      Est...
Chapter 10. Guías para realizar                    la planeación• Asignación de costos (no esfuerzo) para primer nivel del...
Chapter 10. Guías para realizar                 la planeación• Asignación de costos para segundo nivel del WBS:       Fase...
Chapter 10. Proceso de estimación• Planes de proyecto derivados de dos perspectivas:   - Una aproximación ayuda a validar ...
Chapter 10. Proceso de estimación•    Forward-looking, top-down    1.   Caracterización del tamaño, proceso, ambiente, gen...
Chapter 10. Proceso de estimación•    Backward-looking, bottom-up    1.   Detallar tareas de los elementos de nivel mas ba...
Chapter 10. Planeación de las             iteraciones•   Planear el contenido y Schedule de los hitos    mayores y de sus ...
Chapter 10. Planeación de las iteraciones• Énfasis de la planeación en el          • Énfasis de la planeación en el  estad...
Chapter 10. Planeación de las iteraciones•   Número de iteraciones por fase:    –   Inicio:        •   1 (por defecto: Pro...
Chapter 10. Planeación de las iteraciones•   Número de iteraciones por fase:    –   Construcción:        •   2 (por defect...
Chapter 10. Planeación de las iteraciones•       Proyecto estándar: 6 Iteraciones•       Proyectos con arquitectura previa...
Preguntas?
Tareas en MsProject•    Ingreso de Tareas de Resumen1.   Ver, Diagrama de Gantt2.   Click en celda de Nombre3.   Escribir ...
Tareas en MsProject•  Ingreso de Hitos1. En el menú Ver, hacer clic en Diagrama de Gantt.2. Escribir 0 en el campo Duració...
Tareas en MsProject• Tareas Repetitivas1. En el menú Ver, haga clic en Diagrama de Gantt.2. En el campo Nombre de tarea, s...
Tareas en MsProject• Practicar:1. Aumentar la sangría de varias tareas2. Disminuir la sangría de varias tareas3. Ocultar t...
Tareas en MsProject•    Cronogramas Dinámicos1.   Tareas enlazadas mediante relaciones lógicas2.   Minimización de fechas ...
Tareas en MsProject• Dependencia1. Relación entre el fin (o comienzo) de una actividad y el comienzo (o   fin) de otra2. R...
Tareas en MsProject  • Tipos de Dependencias  Fin a comienzo (FC)                    Comienzo a Comienzo (CC)             ...
Tareas en MsProject• Aplicación de Adelantos y Posposiciones1. Absolutos   1. FC + 5d   2. FC – 3d2. Relativos   1. FC + 5...
Tareas en MsProject•  Utilizando el diálogo de Información de la Tarea1. Seleccionar la tarea sucesora2. Click en el icono...
Tareas en MsProject•  Utilizando la Forma de Tarea1. Ventana, Dividir2. Click derecho y seleccionar Predecesoras y Sucesor...
Tareas en MsProject• Ingresar Estimación1. Los estimados se hacer en términos de   1. Duración de una tarea   2. Esfuerzo ...
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.   Uni...
Tareas en MsProject• Recursos:1. Gente2. Edificios3. Máquinas4. Materiales necesarios para crear el producto del proyecto5...
Tareas en MsProject•  Recursos Humanos1. Aquellos cuyo esfuerzo se acumula el campo Trabajo2. Se ingresan como un recurso ...
Tareas en MsProject• Planilla de Ingreso de Recursos1. Ver, Hoja de recursos2. Ver, Tabla: Entrada (Si no está en Entrada,...
Tareas en MsProject• Campos de la Planilla de Recursos1. Indicador: Despliega indicadores para diferentes situaciones2. No...
Tareas en MsProject• Campos de la Planilla de Recursos [CONTINUACIÓN]1. Representa la máxima disponibilidad de la persona....
Tareas en MsProject• Campos de la Planilla de Recursos [CONTINUACIÓN]1. Costo/Uso:[opcional] Se utiliza si se paga ese cos...
Tareas en MsProject• Calendarios de Recursos1. Se parte de un calendario base2. Doble click en el recurso, para abrir el d...
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 ...
Tareas en MsProject•  Duración Fija1. Cuando el primer estimado es la duración2. Cuando la duración no cambia al adicionar...
Tareas en MsProject• Unidades Fijas1. Cuando la cantidad de recursos para la tarea es lo primero que se   conoce2. Cuando ...
Tareas en MsProject• ¿Cómo mantener MS Project fácil y amigable?1. Ingresar un estimado de trabajo o de duración, fijando ...
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ó...
Chapter 11. Introducción• Líneas de negocio de software   – Motivador: retorno de inversión, diferenciación en nuevos nego...
Chapter 11. Organizaciones de línea             de negocio• Definición y mantenimiento del proceso es específico a una  lí...
Chapter 11. Organizaciones de líneade negocio
Chapter 11. Organizaciones de líneade negocio                 SEPA:                 •Facilita el intercambio de           ...
Chapter 11. Organizaciones de línea            de negocioPRA:•Asegurar que el proyecto desoftware cumple con todas laspolí...
Chapter 11. Organizaciones de líneade negocio             SEEA:             •Automatizar el proceso de la             orga...
Chapter 11. Organizaciones de línea            de negocioSEEA:•Proporciona soporte arecursos humanos,investigación, desarr...
Chapter 11. Organizaciones de línea               de negocio• Equipo de administración del proyecto es un equipo activo• E...
Chapter 11. Organizaciones por                    proyectos•Balancear condicionesfavorables para todos losstakeholders (Co...
Chapter 11. Organizaciones por                    proyectos•Balancear condicionesfavorables para todos losstakeholders (Co...
Chapter 11. Organizaciones porproyectos
Chapter 11. Organizaciones por                    proyectos•Balancear condicionesfavorables para todos losstakeholders (Co...
Chapter 11. Organizaciones por                    proyectos•Divididos en subgrupos porcomponentes que requieren unskill co...
Chapter 11. Organizaciones porproyectos            •Asegurar la calidad desde una            perspectiva independiente.   ...
Chapter 11. Evolución del proyecto
Preguntas?
Part III. Software Management            Disciplines       Process Automation
RECORDANDO….Balance                                      entre dimensiones                                                ...
RECORDANDO….Niveles               del proceso– Metaprocesos: Políticas, procedimientos y practicas de la  organización. Lí...
RECORDANDO….Estados                      del ciclo de vida             •   Actividades de investigación y desarrollo      ...
RECORDANDO… Principios de                               administración modernaArchitecture-first approach                 ...
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Software Project Management EAN
Próxima SlideShare
Cargando en…5
×

Software Project Management EAN

2.317 visualizaciones

Publicado el

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

0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
2.317
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Software Project Management EAN

  1. 1. SSD10- Software ProjectOrganization & Management iCarnegie
  2. 2. 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.
  3. 3. 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
  4. 4. 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
  5. 5. 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)
  6. 6. 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
  7. 7. Chapter 1. Modelo en cascada– 2ª Parte: Aproximación sistema de gran escala • Pruebas al final del ciclo de vida
  8. 8. 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
  9. 9. 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
  10. 10. 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%
  11. 11. Chapter 1. Modelo en cascada– Resolución tardía de riesgos
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Part I. Software Management Renaissance Evolution of Software Economics
  16. 16. 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.
  17. 17. 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
  18. 18. 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.
  19. 19. Chapter 2. Generaciones deEconomía de SW
  20. 20. Chapter 2. Generaciones deEconomía de SW
  21. 21. 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?
  22. 22. 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”
  23. 23. 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
  24. 24. 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.
  25. 25. Preguntas? Ir Agenda
  26. 26. Part I. Software Management Renaissance Improving Software Economics
  27. 27. 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.
  28. 28. 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
  29. 29. 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
  30. 30. 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.
  31. 31. 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)
  32. 32. 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.
  33. 33. 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.
  34. 34. 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.
  35. 35. 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
  36. 36. 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.
  37. 37. 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.
  38. 38. Preguntas? Ir Agenda
  39. 39. Part I. Software Management Renaissance The old way and the new
  40. 40. 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.
  41. 41. 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.
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 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) -
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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.
  53. 53. 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
  54. 54. 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
  55. 55. 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.
  56. 56. 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
  57. 57. 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
  58. 58. 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.
  59. 59. 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.
  60. 60. 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.
  61. 61. 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
  62. 62. 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
  63. 63. 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.
  64. 64. 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.
  65. 65. Preguntas?
  66. 66. Part II. A Software Management Process Framework Life-Cycle Phases
  67. 67. 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
  68. 68. 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)
  69. 69. 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
  70. 70. Chapter 5. Ciclo de vida convencional• Las fases tiene el nombre de las actividades primarias• Proceso secuencial• Desarrollo secuencial de artefactos
  71. 71. 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.
  72. 72. Chapter 5. Rational Unified Process
  73. 73. 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?
  74. 74. 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?
  75. 75. 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?
  76. 76. 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?
  77. 77. Preguntas?
  78. 78. Part II. A Software Management Process Framework Artifacts of the process
  79. 79. 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?
  80. 80. 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
  81. 81. 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
  82. 82. 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?
  83. 83. Ejemplo: RUP
  84. 84. Modelamientode Negocio
  85. 85. Requerimientos
  86. 86. Análisis y Diseño
  87. 87. Implementación
  88. 88. Pruebas
  89. 89. Despliegue
  90. 90. Administración yControl deCambios
  91. 91. Ambiente
  92. 92. 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
  93. 93. 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
  94. 94. Preguntas?
  95. 95. Part II. A Software Management Process Framework Model-Based Software Architectures
  96. 96. 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
  97. 97. 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
  98. 98. Preguntas?
  99. 99. Part II. A Software Management Process Framework Workflows of the process
  100. 100. 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.
  101. 101. 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
  102. 102. 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
  103. 103. Chapter 8. Secuencia típica deconstrucción
  104. 104. Preguntas?
  105. 105. Part II. A Software Management Process Framework Checkpoints of the process
  106. 106. 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.
  107. 107. 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
  108. 108. Chapter 9. Secuencia Puntos Control
  109. 109. 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
  110. 110. 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
  111. 111. 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
  112. 112. Preguntas?
  113. 113. Part III. Software Management Disciplines Iterative Process Planning
  114. 114. 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
  115. 115. 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
  116. 116. 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
  117. 117. 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.
  118. 118. 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
  119. 119. 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
  120. 120. 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
  121. 121. 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
  122. 122. 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
  123. 123. 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.
  124. 124. 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.
  125. 125. 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%
  126. 126. 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
  127. 127. 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
  128. 128. 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
  129. 129. 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
  130. 130. 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.
  131. 131. 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)
  132. 132. 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.
  133. 133. 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
  134. 134. Preguntas?
  135. 135. 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
  136. 136. 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.
  137. 137. 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.
  138. 138. 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
  139. 139. 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
  140. 140. 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)
  141. 141. 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
  142. 142. Tareas en MsProject• Aplicación de Adelantos y Posposiciones1. Absolutos 1. FC + 5d 2. FC – 3d2. Relativos 1. FC + 50% 2. FC – 30%
  143. 143. 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
  144. 144. 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
  145. 145. 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
  146. 146. Tareas en MsProject• Herramientas, Opciones, Programación
  147. 147. 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
  148. 148. 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
  149. 149. 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
  150. 150. 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)
  151. 151. 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]
  152. 152. 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.
  153. 153. 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
  154. 154. 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
  155. 155. Tareas en MsProject• Vista de Uso de Recursos• Vista de Uso de Tareas
  156. 156. 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
  157. 157. 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)
  158. 158. 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
  159. 159. 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!
  160. 160. Tareas en MsProjectDespués de asignar recursos, cada tarea se programa de acuerdo con la fórmula:
  161. 161. Tareas en MsProject• Formato del Diagrama de Gantt
  162. 162. Preguntas?
  163. 163. Part III. Software Management Disciplines Project Organizations and Responsibilities
  164. 164. 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
  165. 165. 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.
  166. 166. 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
  167. 167. Chapter 11. Organizaciones de líneade negocio
  168. 168. 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.
  169. 169. 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.
  170. 170. 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)
  171. 171. 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
  172. 172. 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
  173. 173. 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)
  174. 174. 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)
  175. 175. Chapter 11. Organizaciones porproyectos
  176. 176. 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)
  177. 177. 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)
  178. 178. 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)
  179. 179. Chapter 11. Evolución del proyecto
  180. 180. Preguntas?
  181. 181. Part III. Software Management Disciplines Process Automation
  182. 182. 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
  183. 183. 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.
  184. 184. 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
  185. 185. 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

×