Gestin de Proyectos

1
Gestión de Proyectos

• Pontificia Universidad Católica de Chile
• Departamento de Ciencia de la Computación
• IIC3552 Sistemas Embebidos de Tiempo Real
• Gerardo León Pablo Straub

2
Objetivo

• Conocer cómo planificar y controlar la ejecución
  de un proyecto
• Conocer técnicas que reducen el riesgo y mejoran
  la calidad
• En esta clase veremos
• Planificación de proyectos de software embebido
• Seguimiento de proyectos
• Gestión de riesgos
• Gestión de configuración
• Revisión por pares

3
Planificación de proyectos

• El objetivo es establecer planes razonables para
  desarrollar y administrar de forma adecuada los
  proyectos de Ingeniería de software
• Esto involucra básicamente tres tipos de
  actividades
• Desarrollar estimaciones de rendimiento de
  trabajo
• Establecer todos los acuerdos que sean necesarios
  para llevar a cabo el trabajo
• Definir un plan de desarrollo para efectuar el
  trabajo

4
Planificación de proyectos

• Ciclo de Vida
• Fases
• Actividades
• Procesos
• Salidas
• Criterios de Términos

• Plan del Projecto
• Actividades
• Requeridas para el ciclo de vida
• Requeridas pare el proyecto
• Fechas (Estimada/Actual)
• Responsable idividual

5
Planificación de proyectos

• El proceso de Planificación de Projectos contiene
  las siguientes actividades
• Derivar una Estructura de Descomposición de
  Trabajo (WBS)
• Calendario Inicial del Projecto
• Analisis de Recursos y Costos
• Evaluación de Riesgo

6
Derivar una Estructura de Descomposición de
Trabajo (WBS)

• Work Breakdown Structure
• Estructura de tareas y sub-tareas
• Permite identificar todas las actividades
  relacionadas

7
Calendario Inicial del Projecto

• Se estima duración de las tareas
• Las tareas son distribuidas en el tiempo
• Las tareas son asignadas a recursos
• Es recomendable negociar con las personas
  involucradas los plazos para las tareas

8
Analisis de Recursos y Costos

• Se calculan costos
• Se analiza uso de recursos

9
Evaluación de Riesgo

• Se identifican los riesgos
• Se decide que riesgos requiren seguimiento
  especial

10
Seguimiento de proyectos

• llevar a cabo reuniones periódicas en las cuales
  los participantes informan del status de las
  tareas, el progreso o los problemas encontrados
• determinar si las metas estan siendo cumplidas
  de acuerdo a lo programado (checkpoints)
• especificaciones de módulos completa y aprobada
• diseño de módulos completo e inspeccionado
• plan de pruebas de módulos completo, revisado y
  aprobado
• codificación completa y primera compilación
  limpia
• inspección de módulos completa, correcciones
  listas

11
Seguimiento de proyectos

• comparar tiempos planeados con reales para las
  distintas tareas

12
Seguimiento de proyectos
13
Seguimiento de proyectos

• Al detectar problemas con la programación
• asignar mas recursos a area afectada
• readecuar el personal en general
• cambiar la programación del proyecto
• usar técnicas de time-box
• básicamente estrategia de tipo incremental
• se define entrega del primer incremento y luego
  se reajustan todas las tareas acorde a este
  incremento
• al llegar al límite de tiempo de la tareaa para
  ese incremento esa tare se detiene y comienza la
  siguiente
• aunque una tarea no este completa muchas veces
  es posible postergar la última parte para el
  siguiente incremento

14
Gestión de riesgos

• El riesgo siempre involucra dos características
  incertidumbre (el evento puede o no puede
  suceder), y pérdidas (si el riesgo se hace
  realidad)
• estrategia de manejo de riesgo de tipo reactivo
• Indiana Jones dont worry Ill think of
  something
• tambien llamado apagando incendios
• estrategia de manejo de riesgo proactiva
• se identifican los riesgos potenciales mucho
  antes que se inicie el desarrollo
• probabilidad e impacto son caracterizados
• se priorizan en importancia
• se desarrollan planes de contingencia

15
Gestión de riesgos

• Diferentes categorías de riesgo
• riesgos del proyecto (si se hacen realidad
  proyecto se atrasa o cuesta mas)
• riesgos técnicos (implementación se hace muy
  dificil o imposible)
• riesgos del negocio
• nadie quiere el producto
• los vendedores no pueden venderlo
• fuera del marco de productos de la empresa

16
Gestión de riesgos

• tamaño del producto
• grado de confianza en estimación
• tamaño relativo comparado con proyectos previos
• número de cambios (antes y despues de entrega)
• cantidad de componentes a reusar
• impacto en el negocio
• importancia del producto en las ventas
• fechas de término razonables o no
• sofisticación de los usuarios finales
• costos asociados por producto defectuoso

17
Gestión de riesgos

• relacionado con el cliente
• se ha trabajado antes con ese cliente o no
• tiene una idea clara de lo que quiere
• destinará tiempo a desarrollar los requisitos
• está dispuesto a participar en revisiones
• sabe lo que es proceso de software
• riesgos del Proceso
• se ha desarrollado una descripción escrita del
  proceso a ser usado en el proyecto ?
• están todos los miembros dispuestos a seguirlo ?
• se usa el mismo proceso para otros proyectos ?
• se usan métodos específicos para pruebas
• se usan herramientas de software para monitoreo

18
Gestión de riesgos

• Riesgos tecnológicos
• es tecnología nueva para la organización
• es necesario crear nuevos algoritmos
• hay demasiadas restricciones de desempeño
• se deben usar métodos no convencionales (AI,
  neural networks, etc)

19
Gestión de riesgos

• Riesgos asociados al ambiente de desarrollo
• existen herramientas de control de proyectos
• existen compiladores apropiados
• hay herramientas para pruebas
• hay herramientas de control de configuración
• Riesgos asociados con el personal
• es la mejor gente
• tienen la combinación adecuada de habilidades
• hay suficiente gente
• están comprometidos por la duración del proyecto
• han recibido el entrenamiento necesario

20
Gestión de riesgos

• Se intenta evaluar cada riesgo en dos planos la
  probabilidad que el evento realmente ocurra
  (riesgo es real) y las consecuencias o problemas
  si así sucede efectivamente
• establecer escala que refleje la probabilidad que
  ocurra
• delinear las consecuencias
• estimar el impacto en el proyecto
• anotar la precisión de la estimación

21
Gestión de riesgos
22
Gestión de configuración

• muchas personas trabajando sobre muchos
  artefactos
• código fuente
• documentos de especificación
• programación de tareas
• documentos de diseño
• etc.
• artefactos evolucionan (cambian) durante el
  proyecto
• sin SCM gt CONFUSION !!

23
Gestión de configuración

• SCM
• El arte de identificar, organizar y controlar las
  modificaciones en un producto de software que
  está siendo construido por un equipo de personas
  de modo de minimizar la confusión
• Configuración (de Software)
• Todos los items producidos en el proceso
  (programas, documentos, datos)

24
Gestión de configuración

• Configuración base (Baseline)
• Conjunto de items de configuración aprobados que
  sirven como base de referencia para posibles
  modificaciones. Los cambios a estos items son
  cuidadosamente controlados a traves de los
  mecanismos de control de configuración.
• Típicamente tendremos baselines de
• documento de requisitos
• documento de diseño
• código fuente
• planes
• tests
• manual de usuario
• estandars y procedimientos

25
Problemas sin SCM

• problema de información compartida
• mas de una persona accesando y modificando el
  mismo código
• modificaciones de uno pueden afectar a otro
  interfiriendo asi con el progreso del proyecto
• modificación a veces es errónea !
• idea usar copias locales para modificar

26
Problemas sin SCM

• problema de la doble mantención
• el tener mas de una copia hace muy fácil olvidar
  modificar alguna de ellas cuando una de las
  copias es modificada
• por que tener mas de una copia ? ver problema
  anterior
• otra idea
• dividir programa en varios archivos (módulos)
• programador hace una copia local de archivo a
  modificar
• programador se asegura que modificación esté
  correcta antes de reponer la copia en el código
  general compartido
• probabilidad de que el equipo sea afectado por
  arreglos defectuosos disminuye, pero

27
Problemas sin SCM

• problema de la actualización simultánea
• cuando dos o mas personas están modificando
  simultáneamente el código es posible que los
  cambios de uno sean perdidos
• errores que fueron arreglados ayer de pronto
  aparecen nuevamente

28
Pricipales actividades de SCM

• Identificación
• los objetos de interés deben ser identificados y
  organizados (ponerles nombre si es necesario)
• Control de Versión
• los objetos no existen en una sola forma sino en
  varias variantes (versiones)
• SCM debe permitir especificar las versiones de
  los diversos objetos para generar diversas
  configuraciones

29
Pricipales actividades de SCM

• Control de Cambios
• control de acceso
• sincronización

30
Identificación

• objetos básicos y agregados
• agregado es una colección de objetos básicos y
  otros agregados
• cada objeto tiene una serie de atributos que lo
  identifica en forma única
• nombre
• string de caracteres que identifica al objeto
• descripción
• lista de items con el tipo (documento, programa,
  dato)
• identificador del proyecto e informasión de
  cambios y versiones

31
Identificación

• sistema de identificación debe reconocer que los
  objetos evolucionan durante el proceso (nombres
  de versiones, etc)

32
Control de versiones

• configuraciones alternativas del sistema mediante
  selección de versiones apropiadas
• a cada versión se le asocian atributos
• configuración puede especificarse describiendo el
  set de atributos deseados
• atributo puede ser
• un número de versión
• un set de descriptores (por ejemplo boolean) que
  indican cambios funcionales específicos

33
Control de cambios

• Control de Acceso
• Quien tiene autoridad para accesar y modificar
  determinado objeto
• Sincronización
• Asegurar que cambios paralelos realizados por
  distintas personas no se escriban uno sobre otro

34
Revisión por pares

• Actividad de SQA llevada a cabo por los
  ingenieros de software con la siguiente
  finalidad
• descubrir errores (función, lógica o
  implementación)
• verificar que el software satisface los
  requisitos
• asegurar que se cumplen los estandares
  predefinidos
• lograr software desarrollado en forma uniforme
• hacer mas manejable los proyectos
• Las revisiones constituyen una de las actividades
  mas importantes de SQA

35
Revisión por pares

• Se eliminan errores en forma relativamente
  temprana (barato y fácil de corregir)
• Puede hacerse con
• documentos de diseño
• código fuente (listo para ser compilado)
• tests (asegurar buena cobertura)
• Cada revisión se conduce en forma de una reunión
  cuidadosamente planeada y controlada

36
Revisión por pares

• entre 3 y 5 personas
• preparación previa (2 horas por persona)
• duración máxima 2 horas (lento pero cansador)
• foco en un segmento específico pequeño (1 módulo
  o grupo)
• participan los revisores (uno actúa de jefe) y el
  productor
• Precondiciones
• no debe usarse para evaluación del personal
• dispuesto a aceptar costos extra (ahorro es en
  largo plazo)

37
Revisión por pares

• La reunión comienza con una breve introducción
  por parte del productor
• A continuación se realiza el walktrough
  detallado y los revisores hacen sus observaciones
  y preguntas
• Al encontrarse problemas el scretario (uno de los
  revisores) registra los detalles
• Al finalizar el grupo decide si aceptar el
  producto sin modificaciones, rechazarlo debido a
  errores severos o aceptarlo provisionalmente
  (errores menores)

38
Revisión por pares

• Ventajas
• se considera mas efectivo que las pruebas para
  encontrar bugs (encuentra la causa del error en
  lugar del síntoma)
• los programadores escriben sus programas sabiendo
  que otros los revisarán gt fácil de entender y
  leer y mas cuidadosos
• anula el efecto de puntos ciegos (programador
  es incapaz de ver ciertos errores)
• reduce dramáticamente tiempo de pruebas

39
Revisión por pares

• Dificultades
• problemas de personalidad
• persona con buenas ideas no se expresa
• persona con malas ideas se expresa mucho
• algunas personas odian discutir o estar en
  desacuerdo
• fácil de perderse en cosas triviales (punto y
  coma)
• es agotador (pierde efectividad después de un par
  de horas o menos)
• se debe tener cuidado en evaluar el producto y no
  el productor