Software Planning

1. Software Planning Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares Social Network: Facebook, LinkedIn. Hi5

2. Clase Pasada • Obtener los requerimientos del Problema del Poker Planning • Expresarlos en el documento de definición y especificación de requerimientos • Aplicar otras técnicas de requerimientos a parte de casos de uso (especificarlo) • Programar la especificación de la función conciliar()

3. Clase pasada • Analizar diferentes tipos de requerimientos • ¿Para especificar requerimientos se tiene que hacer un análisis? • Retomar programa orientado a aspectos • Analizar requermientos de proyectos con casos de uso.

4. ¿Qué es esto?

5. Especificación Formal • Es la mejor forma de indicar requerimientos, el detalle es que se requiere de un nivel de abstracción muy alto a veces más díficil de expresar el propio problema. • Requerimiento: método de ordenamiento de forma ascendente. • Entradas: dos arreglos de tamaño n: p y q, donde p es el arreglo original y q el resultado.

6. Especificación Formal • Salida: q[o] < q[1] < q[2] … < … q[n] • ¿cuál es el problema? • Es válido lo siguiente: public int [] ordenar(int p[]){ int q[] = new int [p.length]; for(int i=0; i<p.length; i++) q[i]=0; Return q;}

7. Planificación del tiempo • Para asegurar que un proyecto de software se realice de manera exitosa es necesario realizar la gestión del proyecto. • La gestión de proyectos se compone como cualquier proceso administrativo de cuatro etapas claves: planeación, organización, control y dirección. • Entre los recursos disponibles, el tiempo es la principal restricción de un sistema.

8. Planificación del tiempo • Aunque la administración del tiempo sea prioritario en el desarrollo de proyectos de software, los recursos humanos y materiales deben ser gestionados de forma adecuada. Todos estos recursos implican el uso de recursos económicos. • La planeación es el primer acercamiento a la construcción de soluciones. Típicamente se compone de tres fases: Estimación, Itinerario, Seguimiento.

9. Planificación del tiempo • La estimación es la parte más difícil de la planeación dado que se tiene que definir • Existen diferentes tipos de planeación en función al tiempo: operativa (táctica) y estratégica. • ¿qué tipo de planeación se realiza cuando se desarrolla software? • Planeación operativa.

10. Planificación del tiempo • La planificación de proyectos de software es complicada por que es un producto intangible y no hay un “proceso” estándar definido. • La planeación parte del pleno entendimiento de lo que es el problema. • La planeación tiene como finalidad el logro de objetivos: en nuestro caso el desarrollo exitoso de productos de software.

11. Planificación del tiempo • La planeación es un proceso que nos permite ver donde estamos, hacia donde queremos llegar y que se va a hacer para lograrlo (realización de un plan). • Un plan generalmente es un documento escrito que sirve de guía de desarrollo para cumplir las metas del proyecto. • Es un proceso iterativo el cual termina hasta que el proyecto mismo haya terminado.

12. Planificación del tiempo • El éxito o fracaso de un proyecto de software depende en gran parte de la planificación, ya que con ayuda de ésta se pueden evitar problemas como: • Retraso de tiempo de entrega • Sobrepasar el presupuesto • Baja calidad del producto • Alto costo de mantenimiento, etc.

13. Planificación Planificación del tiempo (calendarización) • GESTION DE • PROYECTOS • Propuesta • Planificación • Supervisión • Personal • Informal PLANIFICACIÓN Estimación de costos (esfuerzo) Gestión de riesgos y control de calidad Gestión de la configuración de sw

14. Gestión de Proyectos • El proceso de gestión de proyectos consiste básicamente en: Establecer las prioridades de un proyecto Hacer la valoración inicial de las actividades del proyecto Definir los hitos del proyecto y productos a entregar Mientras el proyecto no se haya terminado o cancelado repetir Bosquejar la programación en el tiempo del proyecto Iniciar actividades conforme a la programación

15. Gestión de Proyectos Esperar (por un momento) Revisar el progreso del proyecto Revisar los estimados de los parámetros del proyecto Actualizar la programación del proyecto Renegociar las restricciones del proyecto y los productos a entregar Si surgen problemas entonces Iniciar la revisión técnica Fin si Fin mientras

16. Gestión de Proyectos • Durante la recolección de requerimientos, se listan todos los elementos que se deben entregar del proyecto: actividades e hitos. • Los hitos se convierten en la métrica fundamental que permite medir el grado de avance del proyecto. Más que los hitos son los “entregables del proyecto”. Un hito es un punto de control.

17. Planificación del Proyecto Entregables del proceso de Planificación

18. Planificación del Proyecto • Ejemplo de una actividad de planeación: Instalar un Sistema de cómputo. • ¿Qué se puede Observar? • Que es incorrecta • ¿Por qué? Cada actividad realizada debe tener asignada un recurso humano responsable de hacerlo, recursos materiales (infraestructura) y financieros para llevarlo acabo.

19. Planificación del Proyecto • Reformulando la actividad: Instalar un sistema de control computarizado en el Departamento de Control Escolar de cada Escuela, Unidad o Centro para el 31 de diciembre de 2006, que no requiera más de 500 horas de trabajo de análisis de sistemas y operaciones con más de 10% de paro durante los tres primeros meses. El responsable de esta actividad es el Ing. Fernando Martínez

20. Planificación del Proyecto • Existen varias formas de representar una planeación: • Pueden representarse como una lista de actividades priorizadas, como un programa de actividades, como un calendario de actividades, como una matriz de responsabilidades, etc. • Lo importante es la especificación de las actividades a realizar así como los recursos utilizados y productos esperados.

21. Planificación del Proyecto • Generalmente se inicia con lo que se conoce como diagrama de planeación, el cual es otra técnica de organización en la cual nos centramos en cada tarea. También recibe el nombre de diagrama de actividades. • En esta etapa se debe definir que actividades se pueden realizar sin depender de ninguna, que actividades para realizarse dependen de otras y finalmente que actividades pueden realizarse simultáneamente (en paralelo).

22. Diagrama de Planeación • Los diagramas de actividades se pueden resumir en una matriz de tiempos, en donde básicamente se debe indicar las tareas, la estimación de tiempo y las relaciones con otras tareas (entregables representados con las letras M).

23. Matriz de Tiempo • La matriz del tiempo debe contener al menos los siguientes campos: EDT/WBS (Código de la actividad), el nombre de la actividad y la duración en días. • La duración del tiempo puede ser estimada o fija. Se considera que un tiempo es fijo aquel que no puede realizarse en menos tiempo o que tiene que realizarse en una fecha indicada.

24. Matriz de Tiempo • El tiempo puede ser calculado en base a la siguiente fórmula: • En donde: • te = Tiempo estimado • to = Tiempo optimista • tm = Tiempo promedio • tp = tiempo pesimista • Esta matriz del tiempo puede ser expresada de mejor forma de forma gráfica y de manera conjunta con un diagrama de Gantt.

25. Diagrama de Gantt • Se recomienda usarlos cuando son menos de 20 actividades y el tiempo es breve.

26. Diagrama de Planeación • Se deben considerar siempre la asignación de recursos humanos a las actividades.

27. Diagrama PERT • El manejo de redes de actvidades con PERT permite utilizar mejores modelos matemáticos de estimación.

28. Time Boxing • Se tiene bien definido las fechas de entrega y a partir de allí se realiza una planeación hacia atrás. • En metodologías ágiles se cuenta con un tiempo predeterminado, por ejemplo, los sprints en scrum son de 21 días.

29. WBS • Es una técnica de planeación en la cual se puede describir y cuantificar la cantidad de trabajo a realizar. • Es una estructura tipo árbol en la cual se esquematizan y jerarquizan cada una de las actividades a realizar. • Es muy parecido a un organigrama con la diferencia que aquí los nodos son tareas.

30. WBS • Se debe cumplir la regla de que todas los nodos hijos de un padre la suma de sus ponderaciones dan 100% las actividades del padre. • Las tareas de WBS llevan una numeración que indica su orden y anidamiento, muy parecido a un índice temático.

31. WBS • Las ramas de cada árbol se les llama paquete y deben ser totalmente independientes de otros paquetes. • Las actividades de mayor nivel (de preferencias todas) deben ser medibles para poder cuantificar el grado de avance. • Las actividades deben presentar resultados tangibles.

32. WBS

33. WBS

34. Evaluación del costo beneficio • En todo proyecto que se desarrolle siempre es importante conocer si es realmente es costo-efectivo el desarrollo de software tanto a nivel de cliente como a nivel de desarrollo. • Para poder evaluar un proyecto se necesita que esté terminado. Generalmente la evaluación se da antes de que comience el proyecto de allí la importancia que tiene la estimación en el desarrollo de software

35. Evaluación del costo beneficio • Para poder estimar, se necesita medir. Para poder medir se necesita de un patrón de comparación denominado métrica. Las métricas del software son amplias y variadas.

36. Métricas del Software • Las métricas además de ayudarnos a medir nos sirve de base para la calidad. • Las métricas son la base de la estimación.

37. Métricas del Software • Cuando se recopila un solo aspecto de los datos se está hablando de medidas. Ejemplo: número de líneas de código o número de errores.

38. Métricas del Software • Un ingeniero de software recopila medidas y desarrolla métricas para obtener indicadores. • Un indicador: es una métrica o una combinación de métricas que proporcionan un visión profunda del proceso y proyecto del software o del producto en si mismo. • Hay dos tipos de indicadores o métricas: Indicadores de proceso e indicadores del proyecto

39. Métricas del Software • Las carácterísticas deseables para las métricas son: • Objetiva. • Sencilla, definible con precisión para que pueda ser evaluada. • Fácilmente obtenible (a un coste razonable). • Válida, la métrica debería medir exactamente lo que se quiere medir y no otra cosa. • Robusta. Debería de ser relativamente insensible a cambios poco significativos en el proceso o en el producto.

40. Métricas del Software • Las Métricas de producto pueden medir la complejidad del diseño, el tamaño del producto final (fuente u objeto) o el número de páginas de documentación producida. • Las Métricas de proceso, son tiempo de desarrollo total, esfuerzo en días/hombre o meses/hombre de desarrollo del producto, tipo de metodología utilizada o nivel medio de experiencia de los programadores.

41. Métricas del Software • Existen otras formas de clasificación por ejemplo basadas en propiedades objetivas y subjetivas:. • Por ejemplo, el tamaño del producto medido en líneas de código (LOC) es una medida objetiva del producto, y una medida subjetiva sería el nivel de experiencia de un programador es una medida subjetiva.

42. Métricas Orientadas al Tamaño • Las Líneas de Código (LOC) son la medida más utilizada para determinar la longitud del código fuente. La definición más común es la siguiente: • Una línea de código es cualquier línea de un texto de un programa que no es un comentario o línea en blanco, sin tener en cuenta el número de instrucciones o parte de instrucciones en la línea. Esta medida se suele representar por NCLOC (No Comentary Lines of Code).

43. Métricas Orientadas al Tamaño • Si queremos conocer la longitud real del programa esta sería: LOC = NCLOC + CLOC • donde CLOC es el número de líneas de comentarios • Una medida indirecta de la densidad de comentarios sería: CLOC / LOC

44. Métricas Orientadas al Tamaño • ¿Es malo tener tantos comentarios? • No. Se debe tener una buena documentación. Los comentarios deben de ser como notas taquigráficas. • El problema es considerar los comentarios como métrica para estimar el desarrollo de software. Aunque una buena documentación sea en código o no tiene su costo.

45. Otras métricas • Cuando se habla de otras partes del desarrollo del ciclo de vida del software también se pueden cuantificar su proyecto: • Realizando un buen modelado los costos son calculados de mejor forma. Visión Diagrama Elemento básico Funcional Diagrama de FD Burbuja Diccionario de datos Dato elemental Datos Diagrama E/R Objetos y Relac. Estado Diagrama de Trans. Estados Estado y transiciones

46. Otras métricas • La tarea de determinar costos de un proyecto de software no es tan fácil como parece. • En general el costo total de un software está determinado por dos indicadores clave: • Esfuerzo para completar una actividad • Tiempo calendario se necesita para completar una actividad.

47. Mét. Orientadas a la Función • Es un método para cuantificar el tamaño y la complejidad de un sistema software en términos de las funciones que el usuario desarrolla o desarrollará. • Se entiende por funciones a las entradas, salidas, archivos, etc. • La métrica por función mejor conocida es el punto de función aunque suelen manejarse muchas métricas como los Puntos de Caso de Uso y Objetos.

48. Más Métricas • Existen otras métricas para determinar el tamaño y la complejidad del software. • Por ejemplo SIZE1 muestra el número de líneas con “;” que para lenguajes que tienen este terminador de instrucciones funciona de buena forma. • La métrica más exacta en cuanto al tamaño es la Complejidad Ciclomática

49. Más Métricas • La Complejidad Ciclomática de McCabe (V(G)) evalua la complejidad del software en base a considerar el flujo de un programa como un grafo. • V(G)= A – N + 2 • Donde A es el número de arcos y N el número de nodos del grafo. • Se deben de tomar en cuenta las condicionales

50. Más Métricas x x x • Estructuras de Decisión Hacer ... hasta x Mientras x hacer... Secuencia Si x entonces...