DETERMINAR LAS METRICAS DE PLANEACION DE UN PRODUCTO DE SOFTWARE A PARTIR DE LAS HERRIMENTAS DE LA INGENIERIA DE SOFTWARE

UNIDAD 3

DETERMINAR LAS METRICAS DE PLANEACION DE UN PRODUCTO DE SOFTWARE A PARTIR DE LAS HERRIMENTAS DE LA INGENIERIA DE SOFTWARE

3.3 SELECCIÓN DE METRICAS DE PLANIFICACION DE TIEMPOS Y RECURSOS EN EL PROYECTO

Métricas, Estimación y Planificación en Proyectos de Software

Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad.

De las Métricas

En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad. El principio, podría parecer que la necesidad de la medición e s algo evidente. Después de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión.

La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software.

Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas.

Hay varias razones para medir un producto.

1. Para indicar la calidad del producto.

2. Para evaluar la productividad de la gente que desarrolla el producto.

3. Par evaluar los beneficios en términos de productividad y de calidad, derivados del uso de nuevos métodos y herramientas de la ingeniería de software.

4. Para establecer una línea de base para la estimación

5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.

Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y medidas indirectas.

Medidas Directas. En el proceso de ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo.

Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.

MÉTRICAS DEL SOFTWARE.

Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.

MÉTRICAS TÉCNICAS: Se centran en las características de software por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.

MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.

MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.

MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.

MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar.

MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.

Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software.

RECURSOS

• La segunda tarea de la planificación es la estimación de recursos necesarios para completar el esfuerzo de desarrollo de software

• Tipos de recursos

• Personal

• Número, habilidades, ubicación

• Entorno

• Herramientas de software, de hardware y de red

• Software reutilizable

• Cada recurso se especifica con 4 características

• Descripción del recurso, informe de disponibilidad, cuándo se requerirá y por cuánto tiempo (ventana de tiempo)

• Recursos humanos

• Se evalúa el ámbito

• Se determinan las habilidades requeridas para completar el desarrollo

• Se especifica la posición organizacional (gestor, ingeniero de software ejecutivo, diseñador) y la especialidad (telecomunicaciones, base de datos, java)

• En proyectos relativamente pequeños (pocas personas-mes) un solo individuo puede realizar todas las tareas de ingeniería de software y consultar con especialistas conforme se requiera

• En equipos mayores, el recurso humano puede estar geográficamente distribuido. Aquí se especifica la ubicación de cada recurso

• El número de personas se determina después de hacer la estimación de esfuerzo de desarrollo (persona-mes)

• Entorno de la ingeniería del software incorpora hardware y software

• El administrador del proyecto debe prescribir la ventana de tiempo requerida por el hardware y el software y verificar que estos recursos estarán disponibles

• Cuando se requiere hardware especial el planificador del proyecto debe especificar cada elemento de hardware

3.1 DEFINICION DE UN PRODUCTO DE SOFTWARE Y SUS ELEMENTOS

Son programas usados para dirigir las funciones de un sistema de computación los cuales son de gran ayuda para las personas o diferentes organizaciones.

Productos genéricos.

Productos que son producidos por una organización para ser vendidos al mercado.

 Productos hechos a medida.

Sistemas que son desarrollados bajo pedido a un desarrollador específico.

 La mayor parte del gasto del software es en productos genéricos, pero hay más esfuerzo en el desarrollo de los sistemas hechos a medida.

Elementos del proceso de software (no encontré como tal de proyecto)

- Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.

- Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto.

- Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

3.2 PLANEACION DEL DESARROLLO DE UN PRODUCTO DE SOFTWARE

FASES DE LA PLANEACION

• Consta de cinco grandes fases:

• Estimación

• Programa de trabajo

• Análisis de riesgos

• Planificación de la gestión del cambio

• Estimación

• Intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto específico basado en software

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado. No se analizara la planeación que implica a la estimación de la necesidad de un sistema de software y la habilidad de producir tal sistema, la asignación de prioridad al proceso de su producción.

Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación, sin embargo estos puntos son válidos también para sistemas pequeños.

Panorama. Hace una descripción general del proyecto detalle de la organización del plan y resume el resto del documento.

Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que especifique cuando se debe terminar estas fases y una indicación de cómo se pueden solapar las distintas fases del proyecto.

Plan de organización. Se definen las responsabilidades específicas de los grupos que intervienen en el proyecto.

Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas, procedimientos y responsabilidades para realizar las pruebas del sistema.

Plan de control de modificaciones. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema.

Plan de documentación. Su

...