sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Soy el cliente de la aplicación que deseo Eres el jefe de proyecto de la aplicación Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías qué y cómo preguntarme, en qué orden y hasta qué nivel de detalle y cuándo?

  • ¿Cuál sería el formato adecuado del resultado de las reuniones?

  • ¿Cómo repartirías las tareas de requisitos entre las personas del equipo de desarrollo? ¿Con cuántas personas empezarías?

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

¿Qué?

  • Disciplina de Gestión: flujo de trabajo (realización de casos de uso que incluye trabajadores, actividades y diagramas) cuyo principal propósito es proporcionar un marco para la gestión de proyectos de software intensivo con directrices prácticas para la planificación, dotación de personal, …, ejecución y seguimiento de los proyectos

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible

  • Gestionar el contrato con proveedores y clientes

  • Gestionar los presupuestos con su definición y asignación

  • Dirigir al personal en contratación, formación, asesoramiento

  • Planificar y seguir la evolución de un proyecto iterativo a través del ciclo de vida y de cada una iteración particular, con sus mediciones

  • Proporcionar un marco para la gestión de riesgos

¿Cómo?

height32

height32

height32

height32

height32

height32

height32

height32

Actividades

Estimación del Desarrollo Software:

  • Compromisos entre la plantilla, planificación y ámbito: puedes usar un modelo de costes (p.e. COCOMO) para validar que tienes las relaciones correctas entre el esfuerzo, el tiempo y la plantilla pero recuerda:
“Si se toman nueve meses para que una mujer tenga un niño, ¿por qué no podemos tomar nueve mujeres para tener uno en un mes? … Añadir más potencia al final de un proyecto software hace que se retrase”
— Brooks
Evaluar el Ámbito y Riesgo del Proyecto Planificar Fases e Iteraciones

height32

  • Debes dar forma al perfil de esfuerzos y afinar las fechas de los hitos, tomando en cuenta las circunstancias de tu proyecto

  • La duración de las iteraciones depende primeramente al tamaño de la organización de desarrollo

  • Número de iteraciones debe encajar en 6±3 según el volumen del proyecto

height32
Gestionar el principio, fin y revisión de cada iteración Cerrar fase asegurando Seguimiento del Desarrollo Software

  • Adquirir los recursos necesarios para realizar la iteración

  • Asignar el trabajo a realizar

  • Evaluar los resultados de la iteración

  • El estado de todos los artefactos es conocida

  • Cualquier problema de implementación fue abordado

  • Todos los grandes temas de la iteración anterior se resuelven

  • Los artefactos necesarios se han distribuido a los implicados (p.e. clientes, usuarios, …)

  • Las finanzas del proyecto están estables si el contrato actual se termina

  • Gestionar con las solicitudes de cambio y su implantación para las iteraciones actuales o futuras

  • Monitorizar continuamente el proyecto en términos de riesgo activo y mediciones objetivas de progreso y calidad

  • Enfrentarse a los problemas a medida que se descubren y conducir éstos a cierre de acuerdo con el plan de resolución de problemas

  • Informar del estado de los proyectos con regularidad

Entrevista:

Armando Robles

Síntesis

sintesis

Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

  • Proyectando las últimas medias aritméticas de las iteraciones pasadas sobre las actividades restantes de las posteriores iteraciones

  • Media aritmética de proporción de casos de uso comprometidos en cada iteración satisfecha en cada iteración

  • Asignando volúmenes de horas de áreas desacopladas: vistas, controladores, modelos, DAO, dispatchers, …​

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Unified Software Development Process

    • Grady Booch, Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (1999)

height32

  • Rational Unified Process Made Easy, The: A Practitioner’s Guide to the RUP

    • Grady Booch, , Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (2003)

height32

  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

    • Craig Larman

    • Pearson; (2004)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Benjamin Cummings; (1995)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson; (2005)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley; (2003)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM