Construcción de Software

Presentación del tema: "Construcción de Software"— Transcripción de la presentación:

1 Construcción de Software
Gestión de Proyectos

2 Marco de la Gestión de Proyectos
Sistemas/proyectos mas complejos Imperativo mejorar la predicción y control de dichos sistemas/proyectos Utilizar técnicas para el desarrollo de las especificaciones y diseño no es suficiente. El proceso de construcción de software tiene que ser gestionado y dirigido de manera rigurosa y cuantitativa.

3 Enfoque en el Proyecto y Procesos
Claves del éxito en las gestión del desarrollo de software: Gestión del proyecto de desarrollo de SW “Utilización de técnicas y actividades de gestión requeridas para obtener un producto software de alta calidad, de acuerdo a las necesidades de los usuarios, dentro de un presupuesto y con una planificación de tiempos establecidos previamente” Gestión del proceso de software “Conjunto de técnicas y actividades que permiten una adecuación de los procesos personales del los constructores y de los productos que participan en el proyecto”

4 Gestión de Proyectos Estimación de duración, coste y esfuerzo
Planificación Seguimiento

5 Estimación-Planificación-Seguimiento
DESARROLLO

6 Estimación Diccionario: Según Larry Putman
Es un conjunto de aproximado de valores para algo que ha de ser hecho.” Según Larry Putman Estimación es la actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas: Cuánto costará? Cuánto tiempo llevará hacerlo?

7 Complejidad No existe modelo universal
Muchos factores y personas implicadas que precisan estimaciones Estimaciones particulares a la etapa Generalmente son superficiales Difícil de formular estimaciones claras, completas y precisas Proceso del software es dinámico Tecnología avanza rápidamente Falta de personal con experiencia Los desarrolladores tienden a subestimar

8 Complejidad (cont.) Estimaciones basadas en niveles de capacidad y experiencia supuestamente iguales para todos los desarrolladores. Mala interpretación en las relaciones lineales entre la capacidad requerida por unidad de tiempo y el tiempo disponible. Tendencia a reducir estimaciones Existen varios “disparadores” de los costos difíciles de determinar.

9 Requisitos de un buen estimador
Debe ser profesional, independiente del proyecto. Su objetivo principal debe ser el de obtener estimaciones de calidad Debe poseer formación y experiencia profesional. Debe poseer una posición en la organización que le permita adoptar una posición independiente. Debe utilizar herramientas adecuadas Relacionar su experiencia a cada situación Debe ser capaz de documentar su estimación

10 Cuándo efectuar la estimación?
La estimación es un proceso continuo. Al inicio es una estimación a grosso modo llamada Macro-estimación A medida que el proyecto avanza las estimaciones se hacen mas precisa

11 Métricas de Software Clasificación Métricas de Producto
Complejidad del diseño Tamaño del producto final Documentación producida Métricas de proceso Tiempo de desarrollo Esfuerzo en días/hombre Nivel medio de experiencia de programadores.

12 Métricas de Producto Tamaño Lineas de Código
Linea de texto de un programa que no es comentario ni linea en blanco (NCLOC) También se cuentan las lineas de comentario para obtener otros indicadores (CLOC) No se debe utilizar esta medida directamente en la estimación de esfuerzo o productividad.

13 Métricas de Producto Funcionalidad
Cantidad de funciones que un producto proporciona Método mas conocido: Function Point Analysis La funcionalidad es un atributo muy importante y es la mejor aproximación existente hasta la fecha

14 Estimación mediante “Puntos de Función”
Objetivos Medir lo que el usuario pide y recibe Independiente de las tecnologías a utilizarse Proporciona una métrica de tamaño que dé soporte al análisis de la calidad y productividad Medio para la estimación del software Factor de normalización para comparar distintos software.

15 Estimación mediante “Puntos de Función”
Cinco parámetros básicos: Entradas (EI, External input) Salidas (EO, External Output) Consultas (EQ, External Queries) Grupos de datos lógicos internos (ILF, Internal Logic Files) Grupos de datos lógicos externos (EIF, External Interface Files) Con estos parámetros estimamos el número de puntos de función no ajustados Posteriormente se aplica a este valor un factor de ajuste obtenido en base a valoraciones subjetivas (características generales del sistema).

16 Complejidad Para cada uno de los parámetros se establece su complejidad: Baja Media Alta Se utiliza los siguientes valores (pesos)

17 Ajuste con 14 factores de complejidad del proyecto
1- Comunicación de datos 2- Funciones distribuidas 3- Rendimiento 4- Configuraciones fuertemente utilizadas 5- Frecuencia de transacciones 6- Entrada on-line de datos 7- Diseño para la eficiencia del usuario final 8- Actualización on-line 9- Procesos complejos 10- Utilización de otros sistemas

18 Ajuste con 14 factores de complejidad del proyecto (cont.)
11- Facilidad de instalación 12- Facilidad de operación 13- Instalación en múltiples sitios 14- Facilidad de cambio Se valorar estos factores de 0 a 5, la sumatoria es el grado de influencia (Total Degree of Influence - TDI) Calculamos el Factor de Ajuste: AF = (TDI x 0.01) El valor de Puntos de Función ajustados será: FPA = FP x AF

19 Estimaciones Adicionales
Utilizando cifras obtenidas con respecto al: - Numero promedio de instrucciones por PF - Productividad en PF por programador/mes se puede estimar el tamaño y tiempo de desarrollo de la aplicación. Utilizar tabla proporcionada para estimaciones.

20