Escuela Universitaria Politécnica Grado en Ingeniería Informática Ingeniería del Software IITema 2: Gestión del Proyecto Boletín Ejercicios CUESTIONES (1) ¿Cuál es la diferencia entre medida, métrica e indicador? Apoye la explicación en algún ejemplo. • Medida: Indicación cuantitativa de un atributo Ejemplo: Un programa tiene 10.000 LDC (líneas de código). • Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo Ejemplo: La productividadde este proyecto fue de 500 (LDC/persona-mes). • Indicador: Métrica o combinación de métricas que proporcionan una visión profunda del proceso, del proyecto o del producto. Ejemplo: La productividad media de nuestra empresa es de 500(LDC/pm) y en el último proyecto ha sido de 250(LDC/pm). (2) ¿Qué es una medida indirecta? Las medidas indirectas estan orientadas a medir aspectos como calidad, complejidad, eficiencia, funcionalidad, etc. ¿Su uso es común en el trabajo con métricas del software? Las medidas indirectas vienen determinadas por una o más métricas básicas. (3) El equipo A encontró 342 errores durante el proceso de ingeniería del software antes de la liberación. El equipo B encontró 184 errores. ¿Qué medidas adicionales tendrían que realizarse a los proyectos A y B para determinar cuál de los equipos eliminó errores de manera más eficiente? Una medida de los defectos encontrados después de liberarlos. ¿Qué métricas propondría para ayudar a realizar esta determinación? Una métrica errores/LDC o defectos/LDC o errores/defectos ¿Qué datos históricos pueden ser útiles? Informes de cada una de las versiones en las que aparezcan todos los datos. (4) Explique las similitudes y diferencias entre las medidas basadas en líneas de código (LDC) y puntos de función (PF). Las medidas basadas en líneas de código son medidas orientadas al tamaño, las cuales nos proporcionaran los datos que usaremos. entorno.) 5. software…) y de las necesidades del proyecto (descripción. la fiabilidad… 2. ¿En qué momento debería “medirse” la calidad de un proyecto software? Debemos medir la calidad de un proyecto continuamente para poder hacer cambias que la mejoren si en algún momento empeora. cuyo objetivo es medir aspectos que tengan que ver con la funcionalidad. con el obtendremos las funciones y características de nuestro proyecto.. (7) Indique dos tipos de métricas que permitan medir la calidad de un proyecto software. Las medidas basadas en puntos de función son medidas orientadas a la función. proceso y herramienta software. Definir recursos requeridos Debemos hacer un listado de nuestros recursos (personal. Analizar riesgos También debemos comprobar los riesgos que vamos a asumir al realizar el proyecto. 3. . tiempo medio uso.. (5) Justifique brevemente la veracidad o falsedad de la siguiente afirmación: “El uso de LDC como medida del software es adecuado en proyectos que han sido desarrollados empleando diversas tecnologías”. 4. cuanto capital y cuanto tiempo nos va a llevar. Antes de planificar el proyecto debemos preveer una estimación. fechas. Determinar la factibilidad Hay que comprobar que realizar el proyecto es factible. Son más justas. cuantos recursos. a la hora de que miden la funcionalidad de un software.) ¿Por qué son importantes este tipo de métricas? Porque hoy en dia la calidad es un marcador importante en cualquier producto y midiendo la calidad podemos construir un producto software de alta calidad que satisfaga las necesidades del cliente. ya que puede no ser viable por falta de medios o por ser un proyecto inviable en la época actual. Estimar costo y esfuerzo . el rendimiento. Son medidas indirectas. la medida de las líneas de código puede ser injusta para comparar software desarrollado en lenguajes de programación distintos puesto que la misma tarea en un lenguaje puede llevar muchas más líneas de código que en otro. con ella podemos constatar cuanto esfuerzo. Como se comentaba en la anterior pregunta.Número promedio de acciones del usuario por cada tarea . Establecer ámbito del proyecto: El ámbito es una descripción del problema. Debido a que para implementar la misma tarea en un lenguaje de programación se necesitan más líneas de código que en otro. disponibilidad.el tamaño o capacidad de nuestro software Son medidas directas.Análisis de uso de aplicación (frecuencia uso del menú “Ayuda”. Proceso de planificación de un proyecto: 1. esta medida puede ser un poco injusta. (6) Explique las diferencias entre método. etc. Idem que boletín 1. (8) Describa brevemente las diversas etapas que se deben seguir para cubrir el proceso de planificación de un proyecto software. La entrevista deberá tener una serie de puntos. Ésta debe ser flexible. ellos son los que deben proporcionar toda la información sobre el proyecto ya que dependerá de ellos. (10)Explique en qué consisten las técnicas de estimación de esfuerzo proyectos software. pues que es difícil saber qué nos encontraremos. ¿Cuál es la unidad de medida más común? El esfuerzo se suele medir como personas-mes (PM).Por supuesto hay que estimar el coste y el esfuerzo para poder organizarse de forma coherente. abierta y dinámica. por tanto debemos tener muy claros los puntos a tratar. Aunque no es una ciencia exacta nos pueden proporcionar valores confiables. Desarrollar un calendario Por último debemos desarrollar un calendario según el cual basarnos en nuestros plazos de proyecto y entregas. (9) Argumente la veracidad o falsedad de la siguiente afirmación: “Una entrevista con el cliente es fundamental para recabar información sobre el problema. Las técnicas de estimación de esfuerzo de proyectos software nos darán una medida del esfuerzo y coste. 6. ¿Qué tipos de mecanismos conoce? • Tipos de mecanismos de estimación de esfuerzo: – Técnicas de descomposición para generar estimaciones de coste y esfuerzo • Estimación basada en problema • Estimación basada en proceso – Modelos empíricos para cálculos de costes y esfuerzo • COCOMO (COnstructive COst MOdel) Boletín ejercicios tema 2 Ingeniería del Software II .” Por supuesto que las entrevistas con el/los cliente/s son fundamentales. Se recomienda realizar la estimación una vez comenzado el proyecto ya que se conocerán más detalles. si fuera demasiado abierta y flexible nos perderíamos en cosas que no nos interesan. los sensores detectan la entrada del vehículo y a continuación. el cliente recibe el GizMo en su domicilio. los valores de dominio (parámetros PF) pueden reducirse un 30% (optimista). así como una foto del conductor. en el mejor de los casos. al que denominaremos “Gizmo”. se levanta la barrera de control y se carga el correspondiente importe en la cuenta del cliente. Par adquirir un “Gizmo”. Dentro de un peaje de una autopista. pueden incrementarse un 20% (pesimista). otros sensores tratan de leer la información del GizMo. se pide realizar una estimación basada en problema de PF del proyecto. Cada vez que el cliente entra en un peaje automático. bancarios y matrícula del vehículo. El importe del peaje se muestra al conductor en una pantalla luminosa adyacente a la barrera de control del peaje. y posiblemente destrozados. se pide calcular los puntos de función (PF) asociados al mismo. En este caso se toman 5 fotografías en 5 instantes diferentes de tiempo y no se levanta la barrera de control. proporcionando sus datos personales. Si el vehículo está autorizado. se enciende una luz verde. se enciende una luz roja y se toman fotografías tanto del conductor como de la matrícula del vehículo. con objeto de evitar posibles fraudes y poder atender debidamente potenciales reclamaciones. Respecto al valor PF que se puede calcular a partir de las actuales especificaciones (probable) se considera que. Esta información también se guarda en la base de datos del sistema. (2) El ingeniero software responsable del proyecto de desarrollo del sistema de telepago para automóviles (descrito en el ejercicio anterior) se encuentra en una fase temprana de ejecución del proyecto y debe asumir cierta inestabilidad en los requisitos de la aplicación. se informa del hecho a la policía. el dueño de un vehículo debe solicitarlo vía web. se destinan uno o más puestos de control al telepago. el vehículo debe disponer de un dispositivo especial. Para efectuar el telepago. . En el peor de los casos. En caso de que los sensores de la barrera detectan que esta se ha atravesado. destinado principalmente al pago automático en los peajes de las autopistas. Se trata de un sistema de telepago para automóviles.EJERCICIOS PRÁCTICOS (1) A partir de la descripción que se proporciona a continuación de un sistema software. A continuación. Si el vehículo no estuviese autorizado. Dada esta problemática. Aunque las anteriores estimaciones de coste se consideran las más probables. respectivamente.LDC) que se indica en la siguiente tabla: Módulo Visión (VI) Control Movimiento (CM) Planificador de Tareas (PT) Monitorización (MO) Coordinación (CO) Se pide: LDC 5000 2500 5000 3000 8700 a.(3) Suponga que usted es el gerente de proyecto de una compañía que construye software para robots caseros. Además. según el modelo básico. asuma que una persona puede producir 150 LDC al mes. . en el peor y mejor de los casos éstas podrían variar un 10% y 20%. En este caso. empleando la técnica de estimación basada en problema. teniendo cada uno el coste (en líneas de código . asumiremos que se trata de un proyecto de tipo “Empotrado”. Realizar una estimación de esfuerzo (PM) y tiempo (en meses) aplicando el modelo COCOMO I. Realizar una estimación del esfuerzo (PM) necesario para llevar a cabo el proyecto. determina que la aplicación estará integrada por 5 módulos. Tras realizar una primera entrevista con el cliente. b.