ADMINISTRACIÓN DE PROYECTOS DE SOFTWARE

1. ADMINISTRACIÓNDEPROYECTOS DE SOFTWARE UNIDAD 2 Ing. Francisco M. Salgado Garza

2. Contenido • Administración de Proyectos de Software • 2.1Principios de la administración de proyectos. • 2.2 Definición del alcance. • 2.3 Planificación del proyecto • 2.4 Análisis y administración de riesgos. • 2.5 Aseguramiento de la calidad. • 2.6 Administración de la Configuración del Software.

3. 2.1Principios de la administración de proyectos de software

4. ¿Por qué fallan los proyectos? • establecimiento de una fecha de entrega no realista • cambio de los requerimientos del usuario • honesta subestimación del esfuerzo • riesgos predecibles y/o impredecibles • dificultades técnicas • no comunicación entre los miembros del proyecto • fallas en la administración del proyecto

5. Relaciones a la Administración de Proyectos ¿calidad del producto? ¿administración de riesgos? ¿métrica? ¿estimación de costos? ¿calendarización del proyecto? ¿comunicación con el usuario? ¿staffing? ¿otros recursos? ¿monitoreo del proyecto?

6. Las 4 P’s • Personas — el elemento más importante para el éxito de un proyecto • Producto — el software a ser construido • Proceso — el conjunto de actividades del framework y las tareas de ingeniería de software para completar el trabajo • Projecto — todo el trabajo requerido para hacer un producto real

7. Puntos criticos • Análisis formal de riesgos • Estimación empírica de costos y calendarios • Administración de proyectos basada enmétricas • Seguimiento de optimización • Seguimiento de defectos contra objetivos de calidad • Personal preparado de la administración del proyecto

8. 2.2 Definición del alcance

9. Entender el Alcance ... • Comprender las necesidades del cliente • comprender el contexto del negocio • comprender las restricciones del proyecto • comprender la motivación del cliente • comprender las probables alternativas de cambio • comprender que... ¡Aunque hayas comprendido, nada está garantizado!

10. Definir el problema • Establecer el alcance – una narrativa que limite elproblema • Descomposición – establece la fragmentación funcional

11. Definir conjuntos de tareas • determinar el tipo de proyecto • valorar el grado de rigor requerido • identificar el criterio de adapación • calcular el valor de Task Set Selector (TSS) • interpretar el TSS para determinar el grado de rigor • seleccionar las tareas de ingeniería de softwre apropiadas

12. Crear Matriz de Actividades Obtenida del “Framework de proceso” actividades del fw funciones de aplicación Esfuerzo requerido para completar cada actividad del framework para cada función de aplicación

13. . Combinar el Problema y el Proceso análisis de riesgos ACTIVIDADES DELFRAMEWORK DEPROCESO COMÚN comunicación con el cliente planeaci{on ingeniería Tareas de Ingeniería de Sw Funciones del producto Entrada de texto Edición y Formateo Edición de copia automática Estructura de capacidades Indexación aut. y TOC Administración de archivos Producción de documentos

14. 2.3 Plan del proyecto Estrategia de solución

15. ¿Por qué los Proyectos se entregan tarde? • establecimiento de una fecha de entrega irreal por entidades externas al grupo de desarrollo de software • cambios en los requerimientos del cliente que no se reflejan en los cambios de calendario • una honesta subestimación de la cantidad de esfuerzo y/o número de recursos que serán requeridos para el trabajo • riesgos predecibles y/o impredecibles que no son considerados al inicio del proyecto • dificultades técnicas que no pueden ser previstas • dificultades humanas que no pueden ser previstas • falta de comunicación entre el personal de los proyectos reflejándose en retrasos • falla en la administración del proyecto en reconocer que el proyecto está fuera de calendario y la carencia de acción para corregir el problema.

16. Obtener la esencia del proyecto • ¿Por qué a ser desarrollado el sistema? • ¿Qué se va a hacer?¿Para cuándo? • ¿Quién es el responsable para una función? • ¿Dónde se ubican organizativamente? • ¿Cómo va a ser hecho y administrado técnicamente el proyecto? • ¿Cuánto de cada recursos se requiere? (v.g. personal, software, herramientas, bases de datos) Barry Boehm

17. Principios de Planificación • división – definir tareas distintas • interdependencia – indicar y validar la interrelación entre tareas asegurándose de la disponibilidad de los recursos • definir responsabilidades – asignación del personal • definir los resultados – cada tarea debe tener una salida • definir los hitos – revisión para calidad

18. Ejemplo I2. Planeación preeliminar del concepto I3. Evaluación de los riesgos de tecnología Planeación Ingeniería/ Construcción Definición del proyecto I1. Alcance del concepto. I4. Prueba del Concepto Desarrollo del concepto Desarrollo de la Nueva Aplicación Mejora de la Aplicación Mantenimiento de la Aplicación Reingeniería I6. Reacción del cliente I5. Implementación del concepto Evaluación del cliente Liberación Tareas de desarrollo utilizando un modelo evolutivo

19. 2.4Análisis y Administración de Riesgos

20. Riesgos del Proyecto ¿Qué puede salir mal? ¿Cuál es la probabilidad? ¿Cuál sería el daño? ¿Qué hacer al respecto?

21. Administración Reactiva de Riesgos • el equipo del proyecto reacciona a los riesgos cuando estos occur • mitigación – plan para recursos adicionales para anticipar ‘la extinción del fuego’ • corregir la falla – se consiguen los recursos y se aplican cuando ocurren • administración de la crisis – la falla no responde a los recursos aplicados y el proyecto se encuentra en un dilema

22. Administración Proactiva de Riesgos • Se realiza un análisis de riesgos formal • La organización corrige de raíz las causas del riesgo • Se aplica • Administración de Calidad Total • TQM • Aseguramiento de Calidad de Software (Estadístico) • Statistical SQA • examinación de las fuentes del riesgo que recaen más allá de los límites del software • desarrollar las competencias para adminsitrar los cambios

23. Paradigma de Administración de Riesgos Controlar Seguir RIESGO Identificar Proyectar Estimar Analizar

24. 2.5Aseguramiento de la Calidad del Software

25. Conceptos de Calidad • objetivo general: reducir la “variación entre muestras”... pero ¿cómo se aplica esto al software? • control de calidad: serie de inspecciones, revisiones, pruebas • aseguramiento de calidad: análisis, auditoría y actividades de reporteo • costo de la calidad • Costos Calculados • Costos de Falla • Costos de Falla Externa

26. Revisiones e Inspecciones ...no hay una razón particular en la que por qué tu amigo o colga no sea también tu más rudo crítico. Jerry Weinberg

27. ¿Qué son las Revisiones? • una reunión conducida por personal técnico para personal técnico • el establecimiento técnico de un producto de trabajo creado durante el proceso de ingeniería de software • un mecanismo SQA • un área de entrenamiento

28. Qué no son las Revisiones No son: un resumen del presupuesto del proyecto el establecimiento de un itinerario un reporte de progreso general un mecanismo de represión o intriga política

29. Los Actores Líder de Revisión standards bearer (SQA) productor mantenimiento revisor registrador/ notario representante del usuario

30. Conducción de la Revisión estar preparado – evaluar el producto antes de la revisión 1. revisar el producto, no el productor 2. mantener un tono suave, hacer preguntas en lugar de hacer acusaciones 3. ajustarse a la agenda de revisión 4. 5. encontrar aspectos, no resolverlos 6. evitar las discusiones de estilo – a la corrección técnica 7. calendarizar las revisiones como tareas de proyecto 8. registrar y reportar todos los resultados de las revisiones

31. Matriz de Opciones de Revisión * IPR WT IN RRR líder entrenado agenda establecida revisores preparados (antelación) productor presenta producto “lector” presenta producto registrador toma notas checklist para encontrar errores categorización de errores creación de lista de punto equipo firma el resultado IPR—informal peer review WT—Walkthrough IN—inspección RRR—revisión round robin sí sí sí no sí sí sí sí sí sí sí sí sí no no sí no no sí tal vez no tal vez tal vez tal vez no tal vez no no no no sí sí sí sí no sí no no sí sí *

32. SQA Estadísca • colectar información de todos los defectos • encontrar las causas de los defectos Producto y Proceso • actuar para proveer de mejoras al proceso medición ... un entendimiento de cómo para mejorar la calidad ...

33. 2.6Administración de la Configuración del Software

34. La “Primera Ley” No importa donde te encuentres en el ciclo de vida del sistema, el sistema cambiará, y el deseo de cambiarlo persistirá a través del ciclo de vida Bersoff, et al, 1980

35. ¿Cuáles son estos Cambios? Cambios en los requerimientos de negocio Cambios en los requerimientos técnicos Cambios en los requerimientos del usuario otros docuementos modelos de Sw Plan de Proyecto datos Prueba código

36. Configuración deSoftware programas documentos Las piezas datos

37. Cambios y SCM Ingeniería de Software SCM • identificación herramientas • control de versión métodos • control de cambios procedimientos • auditoría un cimiento TQM • reporteo • construcción

38. Control de Cambios ALTO

39. Auditoría Plan SQA Requerimientos de Cambio SCIs Auditoría SCM

40. Auditoría de Estado (Status) Reportes de Cambio Reqs. de Cambio ECOs SCIs Auditoría de Estado Reporteo