Este documento describe el proceso de estimación de puntos de función (PF) para calcular el esfuerzo, duración y presupuesto de un proyecto de desarrollo de software. Se identifican los componentes del sistema, se cuentan sus elementos y complejidad, y se calculan los PF sin ajustar usando tablas de ponderación. Luego, se obtienen los PF ajustados considerando factores de complejidad técnica. Finalmente, se usan los PF ajustados para estimar el esfuerzo en horas-persona, la duración del proyecto en
Este documento describe el proceso de estimación de puntos de función (PF), una métrica para medir el tamaño funcional de un sistema de software. El proceso implica identificar los componentes del sistema, como entradas, salidas, consultas e información lógica interna y externa. Luego se asignan pesos a cada componente según su complejidad para calcular los PF sin ajustar. Finalmente, se realizan ajustes para obtener los PF ajustados finales. El documento también proporciona un ejemplo de cálculo de PF para un sistema de
El documento describe un sistema de punto de venta diseñado para realizar altas, bajas y consultas de proveedores y productos. El sistema permite el registro de entradas y salidas de productos y proveedores. Sus funciones principales incluyen dar de alta, modificar y consultar datos de proveedores y productos. El análisis de puntos de función determinó que el tamaño del sistema es de 41.34 puntos de función.
El documento presenta una introducción al uso de métricas como Puntos de Función y Puntos de Casos de Uso para estimar el esfuerzo requerido en proyectos de desarrollo de software. Explica que los Puntos de Función miden el tamaño funcional del software basado en los requerimientos del usuario, mientras que los Puntos de Casos de Uso también consideran la complejidad de las funcionalidades. Además, proporciona detalles sobre cómo calcular ambas métricas y cómo pueden usarse para mejorar la precisión de las estimaciones
El documento describe un sistema de software para una papelería que registrará productos, proveedores y clientes. El sistema se desarrollará en PHP y tendrá una base de datos. Incluirá funciones como registrar productos y proveedores, listarlos y consultarlos. El sistema solo podrá ser usado por el personal autorizado.
Este documento presenta el plan de trabajo para desarrollar un sistema para automatizar el proceso de registro de alumnos y solicitud de equipos en un laboratorio de Cisco Systems. Incluye una descripción del problema actual, un cronograma de actividades, los requerimientos del sistema, y una estimación del costo y tiempo de desarrollo usando el modelo COCOMO. El objetivo del sistema es agilizar los procesos manuales actuales y permitir el registro de alumnos, profesores, equipos, y generar estadísticas.
Este documento introduce Verilog y el entorno de diseño XILINX para realizar prácticas de laboratorio sobre diseño de sistemas digitales. Los objetivos son familiarizarse con Verilog, conocer el entorno de diseño XILINX y desarrollar el proceso de diseño y simulación. Se describen dos circuitos, un decodificador 4 a 16 y un contador de 4 bits, para ser simulados. También se explican los pasos para crear un proyecto en XILINX, añadir los ficheros Verilog, y simular y verificar los diseños.
El documento describe el funcionamiento de una pila, incluyendo su definición como una estructura de datos LIFO, sus operaciones básicas como insertar, eliminar y recorrer elementos, y nuevas funciones como contar elementos, calcular el promedio y otras. Explica el mecanismo interno de una pila a través de nodos, punteros y variables, y provee código de ejemplo para implementar las distintas operaciones.
El documento explica el funcionamiento de una pila. Una pila es una estructura de datos donde los elementos se insertan y eliminan por un extremo llamado cabeza, siguiendo el orden LIFO (último en entrar, primero en salir). Describe las operaciones básicas de una pila como inicializarla, insertar elementos, eliminar elementos y recorrerlos. También presenta nuevas funciones como contar los elementos de una pila y calcular el promedio de los valores almacenados.
Este documento describe el proceso de estimación de puntos de función (PF), una métrica para medir el tamaño funcional de un sistema de software. El proceso implica identificar los componentes del sistema, como entradas, salidas, consultas e información lógica interna y externa. Luego se asignan pesos a cada componente según su complejidad para calcular los PF sin ajustar. Finalmente, se realizan ajustes para obtener los PF ajustados finales. El documento también proporciona un ejemplo de cálculo de PF para un sistema de
El documento describe un sistema de punto de venta diseñado para realizar altas, bajas y consultas de proveedores y productos. El sistema permite el registro de entradas y salidas de productos y proveedores. Sus funciones principales incluyen dar de alta, modificar y consultar datos de proveedores y productos. El análisis de puntos de función determinó que el tamaño del sistema es de 41.34 puntos de función.
El documento presenta una introducción al uso de métricas como Puntos de Función y Puntos de Casos de Uso para estimar el esfuerzo requerido en proyectos de desarrollo de software. Explica que los Puntos de Función miden el tamaño funcional del software basado en los requerimientos del usuario, mientras que los Puntos de Casos de Uso también consideran la complejidad de las funcionalidades. Además, proporciona detalles sobre cómo calcular ambas métricas y cómo pueden usarse para mejorar la precisión de las estimaciones
El documento describe un sistema de software para una papelería que registrará productos, proveedores y clientes. El sistema se desarrollará en PHP y tendrá una base de datos. Incluirá funciones como registrar productos y proveedores, listarlos y consultarlos. El sistema solo podrá ser usado por el personal autorizado.
Este documento presenta el plan de trabajo para desarrollar un sistema para automatizar el proceso de registro de alumnos y solicitud de equipos en un laboratorio de Cisco Systems. Incluye una descripción del problema actual, un cronograma de actividades, los requerimientos del sistema, y una estimación del costo y tiempo de desarrollo usando el modelo COCOMO. El objetivo del sistema es agilizar los procesos manuales actuales y permitir el registro de alumnos, profesores, equipos, y generar estadísticas.
Este documento introduce Verilog y el entorno de diseño XILINX para realizar prácticas de laboratorio sobre diseño de sistemas digitales. Los objetivos son familiarizarse con Verilog, conocer el entorno de diseño XILINX y desarrollar el proceso de diseño y simulación. Se describen dos circuitos, un decodificador 4 a 16 y un contador de 4 bits, para ser simulados. También se explican los pasos para crear un proyecto en XILINX, añadir los ficheros Verilog, y simular y verificar los diseños.
El documento describe el funcionamiento de una pila, incluyendo su definición como una estructura de datos LIFO, sus operaciones básicas como insertar, eliminar y recorrer elementos, y nuevas funciones como contar elementos, calcular el promedio y otras. Explica el mecanismo interno de una pila a través de nodos, punteros y variables, y provee código de ejemplo para implementar las distintas operaciones.
El documento explica el funcionamiento de una pila. Una pila es una estructura de datos donde los elementos se insertan y eliminan por un extremo llamado cabeza, siguiendo el orden LIFO (último en entrar, primero en salir). Describe las operaciones básicas de una pila como inicializarla, insertar elementos, eliminar elementos y recorrerlos. También presenta nuevas funciones como contar los elementos de una pila y calcular el promedio de los valores almacenados.
Métrica de punto de función y lineas de codigoJesús E. CuRias
Este documento describe varios métodos para medir el tamaño y la complejidad del software, incluida la métrica de punto de función y la métrica de líneas de código. La métrica de punto de función mide la funcionalidad entregada al usuario independientemente de la tecnología subyacente, mientras que la métrica de líneas de código proporciona una medida aproximada del tamaño pero no es confiable para medir la productividad o la complejidad. El documento también discute las ventajas y desventajas de estas
El documento discute las dificultades en la estimación de proyectos de software, las técnicas de estimación tradicionales y ágiles, y cómo las diferencias individuales entre proyectos en términos de requisitos, equipo, cliente y otros factores afectan la precisión de las estimaciones. También cubre la importancia de administrar los riesgos y los diferentes tipos de contratos utilizados en la industria del software.
El modelo SLIM estima el esfuerzo y tiempo requerido para proyectos de software. Se basa en dos ecuaciones que relacionan el esfuerzo de desarrollo con el tamaño del proyecto y el tiempo. La ecuación principal estima que el esfuerzo es proporcional al cubo del tamaño e inversamente proporcional a la cuarta potencia del tiempo. El modelo fue creado por Putnam y es útil para proyectos grandes de más de 70,000 líneas de código.
El documento describe el modelo SLIM (Software Lifecycle Management) de estimación de proyectos de software desarrollado por Lawrence Putnam. El modelo SLIM se basa en dos ecuaciones que relacionan el esfuerzo de desarrollo con el tamaño del proyecto y el tiempo de desarrollo. El documento explica cómo aplicar las ecuaciones del modelo SLIM para estimar el esfuerzo requerido para un proyecto de software dado su tamaño medido en líneas de código.
El modelo SLIM estima el esfuerzo y tiempo requerido para proyectos de software. Se basa en dos ecuaciones que relacionan el esfuerzo de desarrollo con el tamaño del proyecto y el tiempo. La ecuación principal estima que el esfuerzo es proporcional al cubo del tamaño e inversamente proporcional a la cuarta potencia del tiempo. El modelo fue creado por Putnam y es útil para proyectos grandes de más de 70,000 líneas de código.
Medición y Estimación de Software con Puntos de FunciónSoftware Guru
En esta sesión de Lunch & Learn se presena la principal herramienta para la medición funcional de productos de sofware desde el punto de vista del usuario: Análisis de Puntos de Función (APF).
Este documento presenta diferentes modelos para estimar los costes y tiempos de proyectos de software. Describe métodos como la opinión de expertos, estimación por analogía, descomposición y modelos algorítmicos como SLIM y COCOMO. Recomienda usar juicio de expertos inicialmente y refinar las estimaciones con modelos algorítmicos una vez se tengan especificaciones detalladas, desarrollando ecuaciones locales basadas en la experiencia propia.
El modelo COCOMO es un modelo empírico de estimación de costos creado por Barry Boehm para estimar el esfuerzo, tiempo y personal requerido para desarrollar proyectos de software. Incluye tres submodelos (básico, intermedio y avanzado) que consideran factores como el tamaño del proyecto, la complejidad, las herramientas utilizadas y la experiencia del equipo. El modelo estima las variables clave como meses-hombre requeridos, meses totales de desarrollo y costo del proyecto en función de líneas de
El modelo COCOMO estima el esfuerzo y tiempo requerido para desarrollar proyectos de software. Existen tres niveles de COCOMO - Simple, Moderado e Incrustado - que reflejan el detalle del análisis y la complejidad del proyecto. El modelo estima el esfuerzo utilizando líneas de código y puntos de función como métricas. Proporciona fórmulas, coeficientes y ejemplos para realizar estimaciones.
Este documento describe varios métodos para determinar la saturación de fluidos como agua, petróleo y gas en muestras de roca como núcleos y tapones. Estos incluyen el método de la retorta, extracción por destilación usando Dean-Stark, lavado con solvente y titulación de Karl-Fischer, y análisis de núcleos con presión retenida. La saturación se define como la fracción del volumen poroso ocupado por cada fluido y es importante para estimar las reservas de hidrocarburos en un yacimiento
El documento describe el proceso de estimación de puntos de función (PF), una métrica para medir el tamaño de un sistema de software. Explica cómo identificar los componentes de un sistema, asignar pesos basados en complejidad, calcular los PF sin ajustar y ajustados, y estimar el esfuerzo, duración y presupuesto de un proyecto basado en los PF.
Este documento describe el método de puntos de función (PF), una métrica para cuantificar el tamaño de un producto de software desde la perspectiva del usuario. Se basa en asignar pesos a los componentes de una aplicación como entradas, salidas, consultas e ILF/EIF. Luego se suman los puntos de función simples y ajustados por factores como complejidad y reusabilidad para estimar el esfuerzo de desarrollo.
Calculo de esfuerzo en puntos de funcion finalOmar Ordoñez
Este documento explica el método de puntos de función para estimar el esfuerzo requerido para un proyecto de software. Describe cómo se calculan los puntos de función sin ajustar contando elementos como entradas, salidas, consultas y archivos. Luego explica cómo usar factores de ajuste para calcular los puntos de función ajustados basados en características del proyecto. El objetivo es poder estimar de manera temprana el tamaño, costo y duración de un proyecto de desarrollo de software.
Este documento describe el método de análisis de puntos de función para estimar el esfuerzo, duración y costo de proyectos de software. El método implica identificar las funciones del software, asignarles puntos de función según su tipo y complejidad, calcular los puntos de función ajustados y luego estimar el esfuerzo en horas-hombre, la duración del proyecto en meses y el costo total basado en los sueldos y otros costos.
Este documento describe el Análisis de Puntos de Función (FPA), una técnica para medir el tamaño funcional de software. Explica cómo dividir los requisitos funcionales del usuario en categorías como entradas, salidas, consultas y archivos lógicos internos. También cubre cómo calcular los puntos de función ajustados y cómo usarlos para estimar el esfuerzo y el presupuesto de un proyecto de software.
El documento presenta un análisis de factores para estimar el esfuerzo requerido para un proyecto de desarrollo de software que involucra 5 actores y 8 casos de uso. Calcula factores como la complejidad técnica, el ambiente y la productividad para estimar un esfuerzo total de 961,80 horas-hombre, equivalente a 8 meses de desarrollo con dos personas. También incluye un cálculo del costo total del proyecto de 222.808,05 bolívares considerando materiales, recursos humanos y gastos de of
Este documento presenta un proyecto para desarrollar un sistema de control de alumnos. Incluye un alcance que se centra en el registro, modificación y eliminación de datos de alumnos. También incluye un plan de riesgos, limitaciones, costos y un cronograma. El análisis de puntos de función estima que se requerirán 3 personas durante 7.5 meses para completar el proyecto con un costo total de 409,134 pesos.
Este documento presenta un análisis de puntos de función para estimar el esfuerzo requerido para desarrollar un sistema de gestión de cursos en línea. Identifica los componentes del sistema, como entradas, salidas, consultas y archivos lógicos internos. Luego calcula la complejidad funcional en términos de puntos de función ajustados, considerando factores como el rendimiento, la entrada de datos en línea y la actualización de archivos maestros. Estimó que el proyecto requeriría alrededor de 91 puntos de
Este documento describe una práctica de análisis de carga y operacional que incluye nueve problemas. El objetivo es resolver problemas de análisis de carga y operacional aplicando métodos estadísticos como clustering y componentes principales. Los estudiantes deben presentar las soluciones a los nueve problemas de forma detallada y entregar el trabajo en formato PDF antes de una fecha límite.
El documento describe el Modelo COCOMO (Constructive Cost Model), un modelo matemático utilizado para estimar los costos de desarrollo de software. Explica que COCOMO tiene tres submodelos de estimación (básico, intermedio y detallado) que ofrecen diferentes niveles de detalle. También describe los factores que se consideran en cada submodelo como el tamaño del programa, atributos del producto, hardware, personal y proyecto.
El documento discute diferentes métricas para medir el desempeño de sistemas computacionales. Explica que las métricas más útiles son el tiempo de ejecución y los benchmarks, ya que consideran factores como la tecnología, la arquitectura y el software. También introduce conceptos como CPI, aceleración y la ley de Amdahl para predecir ganancias de desempeño.
Métrica de punto de función y lineas de codigoJesús E. CuRias
Este documento describe varios métodos para medir el tamaño y la complejidad del software, incluida la métrica de punto de función y la métrica de líneas de código. La métrica de punto de función mide la funcionalidad entregada al usuario independientemente de la tecnología subyacente, mientras que la métrica de líneas de código proporciona una medida aproximada del tamaño pero no es confiable para medir la productividad o la complejidad. El documento también discute las ventajas y desventajas de estas
El documento discute las dificultades en la estimación de proyectos de software, las técnicas de estimación tradicionales y ágiles, y cómo las diferencias individuales entre proyectos en términos de requisitos, equipo, cliente y otros factores afectan la precisión de las estimaciones. También cubre la importancia de administrar los riesgos y los diferentes tipos de contratos utilizados en la industria del software.
El modelo SLIM estima el esfuerzo y tiempo requerido para proyectos de software. Se basa en dos ecuaciones que relacionan el esfuerzo de desarrollo con el tamaño del proyecto y el tiempo. La ecuación principal estima que el esfuerzo es proporcional al cubo del tamaño e inversamente proporcional a la cuarta potencia del tiempo. El modelo fue creado por Putnam y es útil para proyectos grandes de más de 70,000 líneas de código.
El documento describe el modelo SLIM (Software Lifecycle Management) de estimación de proyectos de software desarrollado por Lawrence Putnam. El modelo SLIM se basa en dos ecuaciones que relacionan el esfuerzo de desarrollo con el tamaño del proyecto y el tiempo de desarrollo. El documento explica cómo aplicar las ecuaciones del modelo SLIM para estimar el esfuerzo requerido para un proyecto de software dado su tamaño medido en líneas de código.
El modelo SLIM estima el esfuerzo y tiempo requerido para proyectos de software. Se basa en dos ecuaciones que relacionan el esfuerzo de desarrollo con el tamaño del proyecto y el tiempo. La ecuación principal estima que el esfuerzo es proporcional al cubo del tamaño e inversamente proporcional a la cuarta potencia del tiempo. El modelo fue creado por Putnam y es útil para proyectos grandes de más de 70,000 líneas de código.
Medición y Estimación de Software con Puntos de FunciónSoftware Guru
En esta sesión de Lunch & Learn se presena la principal herramienta para la medición funcional de productos de sofware desde el punto de vista del usuario: Análisis de Puntos de Función (APF).
Este documento presenta diferentes modelos para estimar los costes y tiempos de proyectos de software. Describe métodos como la opinión de expertos, estimación por analogía, descomposición y modelos algorítmicos como SLIM y COCOMO. Recomienda usar juicio de expertos inicialmente y refinar las estimaciones con modelos algorítmicos una vez se tengan especificaciones detalladas, desarrollando ecuaciones locales basadas en la experiencia propia.
El modelo COCOMO es un modelo empírico de estimación de costos creado por Barry Boehm para estimar el esfuerzo, tiempo y personal requerido para desarrollar proyectos de software. Incluye tres submodelos (básico, intermedio y avanzado) que consideran factores como el tamaño del proyecto, la complejidad, las herramientas utilizadas y la experiencia del equipo. El modelo estima las variables clave como meses-hombre requeridos, meses totales de desarrollo y costo del proyecto en función de líneas de
El modelo COCOMO estima el esfuerzo y tiempo requerido para desarrollar proyectos de software. Existen tres niveles de COCOMO - Simple, Moderado e Incrustado - que reflejan el detalle del análisis y la complejidad del proyecto. El modelo estima el esfuerzo utilizando líneas de código y puntos de función como métricas. Proporciona fórmulas, coeficientes y ejemplos para realizar estimaciones.
Este documento describe varios métodos para determinar la saturación de fluidos como agua, petróleo y gas en muestras de roca como núcleos y tapones. Estos incluyen el método de la retorta, extracción por destilación usando Dean-Stark, lavado con solvente y titulación de Karl-Fischer, y análisis de núcleos con presión retenida. La saturación se define como la fracción del volumen poroso ocupado por cada fluido y es importante para estimar las reservas de hidrocarburos en un yacimiento
El documento describe el proceso de estimación de puntos de función (PF), una métrica para medir el tamaño de un sistema de software. Explica cómo identificar los componentes de un sistema, asignar pesos basados en complejidad, calcular los PF sin ajustar y ajustados, y estimar el esfuerzo, duración y presupuesto de un proyecto basado en los PF.
Este documento describe el método de puntos de función (PF), una métrica para cuantificar el tamaño de un producto de software desde la perspectiva del usuario. Se basa en asignar pesos a los componentes de una aplicación como entradas, salidas, consultas e ILF/EIF. Luego se suman los puntos de función simples y ajustados por factores como complejidad y reusabilidad para estimar el esfuerzo de desarrollo.
Calculo de esfuerzo en puntos de funcion finalOmar Ordoñez
Este documento explica el método de puntos de función para estimar el esfuerzo requerido para un proyecto de software. Describe cómo se calculan los puntos de función sin ajustar contando elementos como entradas, salidas, consultas y archivos. Luego explica cómo usar factores de ajuste para calcular los puntos de función ajustados basados en características del proyecto. El objetivo es poder estimar de manera temprana el tamaño, costo y duración de un proyecto de desarrollo de software.
Este documento describe el método de análisis de puntos de función para estimar el esfuerzo, duración y costo de proyectos de software. El método implica identificar las funciones del software, asignarles puntos de función según su tipo y complejidad, calcular los puntos de función ajustados y luego estimar el esfuerzo en horas-hombre, la duración del proyecto en meses y el costo total basado en los sueldos y otros costos.
Este documento describe el Análisis de Puntos de Función (FPA), una técnica para medir el tamaño funcional de software. Explica cómo dividir los requisitos funcionales del usuario en categorías como entradas, salidas, consultas y archivos lógicos internos. También cubre cómo calcular los puntos de función ajustados y cómo usarlos para estimar el esfuerzo y el presupuesto de un proyecto de software.
El documento presenta un análisis de factores para estimar el esfuerzo requerido para un proyecto de desarrollo de software que involucra 5 actores y 8 casos de uso. Calcula factores como la complejidad técnica, el ambiente y la productividad para estimar un esfuerzo total de 961,80 horas-hombre, equivalente a 8 meses de desarrollo con dos personas. También incluye un cálculo del costo total del proyecto de 222.808,05 bolívares considerando materiales, recursos humanos y gastos de of
Este documento presenta un proyecto para desarrollar un sistema de control de alumnos. Incluye un alcance que se centra en el registro, modificación y eliminación de datos de alumnos. También incluye un plan de riesgos, limitaciones, costos y un cronograma. El análisis de puntos de función estima que se requerirán 3 personas durante 7.5 meses para completar el proyecto con un costo total de 409,134 pesos.
Este documento presenta un análisis de puntos de función para estimar el esfuerzo requerido para desarrollar un sistema de gestión de cursos en línea. Identifica los componentes del sistema, como entradas, salidas, consultas y archivos lógicos internos. Luego calcula la complejidad funcional en términos de puntos de función ajustados, considerando factores como el rendimiento, la entrada de datos en línea y la actualización de archivos maestros. Estimó que el proyecto requeriría alrededor de 91 puntos de
Este documento describe una práctica de análisis de carga y operacional que incluye nueve problemas. El objetivo es resolver problemas de análisis de carga y operacional aplicando métodos estadísticos como clustering y componentes principales. Los estudiantes deben presentar las soluciones a los nueve problemas de forma detallada y entregar el trabajo en formato PDF antes de una fecha límite.
El documento describe el Modelo COCOMO (Constructive Cost Model), un modelo matemático utilizado para estimar los costos de desarrollo de software. Explica que COCOMO tiene tres submodelos de estimación (básico, intermedio y detallado) que ofrecen diferentes niveles de detalle. También describe los factores que se consideran en cada submodelo como el tamaño del programa, atributos del producto, hardware, personal y proyecto.
El documento discute diferentes métricas para medir el desempeño de sistemas computacionales. Explica que las métricas más útiles son el tiempo de ejecución y los benchmarks, ya que consideran factores como la tecnología, la arquitectura y el software. También introduce conceptos como CPI, aceleración y la ley de Amdahl para predecir ganancias de desempeño.
Estimacion de Proyectos, Ingeniería de SoftwareMarvin Romero
Este documento describe diferentes técnicas para estimar los recursos, costos y tiempo necesarios para completar un proyecto de software. Explica cómo determinar los requisitos funcionales y no funcionales del software, y estimar los recursos humanos y materiales requeridos. Luego, detalla tres opciones para realizar estimaciones: basadas en proyectos similares, mediante descomposición del problema o usando modelos empíricos como COCOMO. El documento ilustra estas técnicas con ejemplos de estimaciones basadas en líneas de código y puntos
Estimación de costos y actividades para Sistema de Control de ProducciónIleana Garza Ibarra
Estimación de costos y actividades para Sistema de Control de Producción en Artefacto de Visión como parte de la materia de Ingeniería de Software de la Universidad Politécnica de Victoria
El documento describe la estructura interna de una computadora. Explica que la CPU está compuesta de una unidad de control, una unidad aritmética y lógica (ALU), y registros. La unidad de control dirige el funcionamiento de la CPU al decodificar e interpretar las instrucciones y generar las señales de control necesarias para ejecutar cada instrucción. La CPU se comunica con la memoria principal, memoria secundaria y periféricos a través de buses.
El documento describe varias técnicas para estimar los costos de desarrollo de software, incluyendo modelos algorítmicos, juicio de expertos, estimación por analogía, y la ley de Parkinson. También explica los métodos de estimación bottom-up y top-down, y las métricas como líneas de código, puntos de función y FFP que se pueden usar para estimar el tamaño de un proyecto de software.
Este documento describe los principios básicos de la programación en STEP7, incluyendo la estructura de los programas, los tipos de módulos, y los tipos de procesamiento. Explica que los programas en una CPU consisten en un sistema operativo y un programa de usuario, y que STEP7 permite dividir programas de usuario en módulos funcionales como bloques de función y funciones. También cubre conceptos como la ejecución cíclica, las prioridades de los módulos de organización, y la profundidad de anidamiento.
Este documento describe cómo utilizar el Analizador de Datos de Entrada y el Analizador de Procesos en Arena para analizar datos y simular escenarios. Explica cómo preparar archivos de datos, ajustar los datos a distribuciones, definir controles y variables de respuesta, ejecutar escenarios, y generar gráficos y estadísticas. También presenta un ejemplo de un sistema de producción de 4 procesos en serie y cómo recolectar métricas como el número de llegadas y tiempos entre eventos.
Este documento describe tres utilerías comunes: Ping, Ipconfig y Netstat. Ping comprueba la comunicación entre hosts mediante paquetes ICMP. Ipconfig muestra la configuración de red TCP/IP y actualiza DHCP y DNS. Netstat muestra conexiones de red activas entrantes y salientes usando protocolos como TCP y UDP.
Este documento presenta las técnicas de estimación de puntos de función y puntos de casos de uso. Incluye un caso práctico de la estimación de dos casos de uso de un sistema bibliotecario utilizando estas técnicas. Calcula factores como la complejidad técnica, factores ambientales y horas hombre requeridas para cada caso de uso, concluyendo que la aplicación de estas técnicas proporciona una estimación concreta del esfuerzo requerido.
Este documento presenta las técnicas de estimación de puntos de función y puntos de casos de uso. Incluye un caso práctico de la estimación de dos casos de uso diferentes para un sistema bibliotecario utilizando estas técnicas. Calcula factores como la complejidad técnica, factores ambientales y horas hombre requeridas para cada caso de uso. Concluye que seguir estos pasos de las técnicas de estimación es la manera más concreta de definir el tiempo necesario para ejecutar diferentes casos de uso.
Este documento presenta las técnicas de estimación de puntos de función y puntos de casos de uso. Incluye un caso práctico de la estimación de dos casos de uso de un sistema bibliotecario utilizando estas técnicas. El resumen concluye que la aplicación de los pasos de estas técnicas permite estimar de manera concreta las horas necesarias para implementar casos de uso.
2. Qué son los Puntos de Función Es una métrica que permite traducir en un número el tamaño de la funcionalidad que brinda un producto de software desde el punto de vista del usuario, a través de una suma ponderada de las características del producto. Componentes: EI : Procesos en los que se introducen datos y que suponen la actualización de cualquier archivo interno. EO: Procesos en los que se envía datos al exterior de la aplicación. EQ: Procesos consistentes en la combinación de una entrada y una salida, en el que la entrada no produce ningún cambio en ningún archivo y la salida no contiene información derivada. ILF: Grupos de datos relacionados entre sí internos al sistema. EIF: Grupos de datos que se mantienen externamente.
3. Tabla de ponderaciones para EI, EQ y EO Una vez obtenidos los diferentes elementos del sistema se utilizan las siguientes tablas para asignar pesos en función del número de atributos que tengan y el número de archivos a los que afecte. Fundación Universitaria Konrad Lorenz
5. Proceso de Estimación Mediante PF No. Entradas al Sistema (EI) No. Salidas del Sistema (EO) No. Consultas BD (EQ) No. Ficheros (ILF - EIF) Factor Corrección por Complejidad: No. Atributos de Entradas x Factor Corrección por Complejidad: No. Atributos de Salidas x Factor... x Factor Corrección por Complejidad: No. Atributos de Ficheros x + Puntos de Función Sin Ajustar Puntos de Función Ajustados Ajuste de Complejidad Técnica Estimación del Esfuerzo Estimación del Tiempo de Desarrollo Datos de Productividad del Equipo Escala de 14 Factores de Complejidad Estimación del Presupuesto
6. Cálculo de los Puntos de Función Sin Ajustar Por tanto los PFSA (Puntos de Función Sin Ajustar) se calculan como la suma de los productos de cada componente por su peso determinado en la tabla correspondiente. PFSA = PFTe + PFTo + PFTq + PFTif + PFTef Componente Bajo Medio Alto Total EI Eb * 3 = _ Em * 4 = _ Ea * 6 = _ PFTe EO Ob * 4 = _ Om * 5 = _ Oa * 7 = _ PFTo EQ Qb * 3 = _ Qm * 4 = _ Qa * 6 = _ PFTq ILF IFb * 7 = _ IFm * 10 = _ IFa * 15 = _ PFTif EIF EFb * 5 = _ EFm * 7 = _ EFa * 10 = _ PFTef PFSA
7. Descripción de Totales por componente PFTe : Total Puntos de Función para las entradas del sistema. PFTo : Total Puntos de Función para las salidas del sistema. PFTq: Total Puntos de Función para las consultas del sistema. PFTif: Total Puntos de Función para los archivos internos del sistema. PFTef: Total Puntos de Función para los archivos externos del sistema.
8. Descripción del problema ejemplo Para mostrar la métrica de Puntos de Función se tomó como ejemplo las condiciones de un sistema de gestión de un hotel, en el cual se tuvieron en cuenta los subsistemas, Gestión de cocina, Gestión de mostrador, Gestión de administración y la Gestión de configuración del sistema. En este sistema se consideran 8 archivos internos (platos del menú, pedidos de cocina, clientes, habitaciones, reservas, estancias, configuración y usuarios). El diagrama de contexto y el diagrama de flujo de datos nivel 0 se describen a continuación.
9. Obtener Información del Sistema Se requiere conocimiento global del sistema y construir un Modelo de entidades primarias. Ejemplo: 1
10. Obtener Información del Sistema Se requiere conocimiento global del sistema y construir un Modelo de entidades primarias. Ejemplo: 1
11.
12. Calcular No. Elementos y su Complejidad Contar los Elementos de cada Componente y su Complejidad 3 Componentes Identificados Salidas Entradas Consultas Ficheros Lógicos Internos Ficheros Externos Cantidad Complejidad Cantidad Complejidad
13. Definición de los Componentes del Sistema Salidas: 9 salidas de complejidad alta y 1 de complejidad media para el subsistema mostrador, 3 salidas de complejidad alta y 1 de complejidad baja para el subsistema cocina, 2 salidas de complejidad baja, 4 salidas de complejidad media y 3 salidas de complejidad alta para el subsistema administración y sólo una salida de complejidad baja para el subsistema configuración. Entradas: 9 entradas de complejidad alta para el subsistema mostrador, 3 entradas de complejidad alta para el subsistema cocina, 2 entradas de complejidad baja y 4 entradas de complejidad media para el subsistema administración y 4 entradas de complejidad baja para el subsistema configuración. Consultas: 2 consultas de complejidad baja para el subsistema mostrador, 3 consultas de complejidad baja para el subsistema cocina, 1 consulta de complejidad baja y 3 de complejidad alta para el subsistema administración y finalmente una consulta de complejidad baja para el subsistema configuración. Ficheros Lógicos Internos: 8 almacenes intermedios de datos de complejidad alta. Ficheros Externos: No se utilizaron almacenes externos de datos.
15. Obtener los PF Sin Ajustar Asignar los Puntos de Función a cada Componente de acuerdo a las tablas 4 Componentes Identificados Salidas Entradas Consultas Ficheros Lógicos Internos Ficheros Externos Cantidad Complejidad PFSA Tablas Correspondientes a cada Componente
16. Obtener los PF Ajustados Obtener PF Ajustados 5 Componentes Identificados Entradas PFSA = 306 PFA=PFSA* [0.65+[0.01*ACT]] Obtención ACT Puntaje Factor de Ajuste Min Max Comunicación de Datos 0 5 Proceso Distribuido 0 5 Objetivos de Rendimiento 0 5 Configuración de Explotación Compartida 0 4 Tasa de transacciones 0 5 Entrada de Datos en Línea 0 5 Eficiencia con el Usuario Final 0 5 Actualizaciones en Línea 0 5 Lógica de Proceso Interno Compleja 0 5 Reusabilidad del Código 0 5 Conversión e Instalación contempladas 0 5 Facilidad de Operación 0 5 Instalaciones Múltiples 0 5 Facilidad de Cambios 0 5
17. Obtener los PF Ajustados Obtener Ajuste de la Complejidad Técnica 5 El sistema para determinar la valoración de uno de los Factores de Ajuste: Ej: Comunicación de Datos: Los datos usados en el sistema se envían o reciben por líneas de comunicaciones. La valoración para este factor se determina a través de la elección de las siguientes alternativas: a) 0 = Sistema Aislado del exterior (sólo usuarios directos) b) 1 = Aplicación batch con entrada de datos remota o (exclusiva) utilización de periféricos de salida remotos. c) 2 = Aplicación batch con entrada de datos remota y utilización de periféricos de salida remotos. d) 3 = Aplicación de captura de datos En-Línea o hay un sistema de teleproceso que pasa los datos a la aplicación batch o sistema de consulta. e) 4 = Varios teleprocesos pero con el mismo protocolo de comunicaciones. (para el presente caso) f) 5 = Hay teleproceso con varios protocolos de comunicación. Sistema Abierto y con interfaces de todo tipo al exterior. NOTA: (la sumatoria de las valoraciones de los 14 factores dará el valor para el ACT Nº de Factor Nº de Factor Valor 0..5 1 Comunicación de Datos 4 2 Proceso Distribuido 4 3 Objetivos de Rendimiento 1 4 Configuración de Explotación Compartida 1 5 Tasa de transacciones 3 6 Entrada de Datos en Línea 5 7 Eficiencia con el Usuario Final 2 8 Actualizaciones en Línea 3 9 Lógica de Proceso Interno Compleja 1 10 Reusabilidad del Código 1 11 Conversión e Instalación contempladas 0 12 Facilidad de Operación 1 13 Instalaciones Múltiples 2 14 Facilidad de Cambios 4 Ajuste de Complejidad Técnica (ACT) 32
18. Cálculo del Esfuerzo Cálculo del Esfuerzo 6 PFA = 296.82 Esfuerzo horas/persona = PFA / [1 / 8 persona / hora)] = 296.82 / 0.125 = 2374.5 horas/persona LÍNEAS DE CÓDIGO = PFA * (LINEAS POR PF) Cambiar horas/efectivas por horas productivas estimadas Esfuerzo Entorno y Lenguaje Líneas de Código por PF Horas por PF Lenguajes 2GL: Ensamblador, C,… 300 20 a 30 Lenguajes 3GL: Cobol 100 10 a 20 Lenguajes 4GL: VisualXX 20 5 a 10
19. Cálculo de la Duración del Proyecto Cálculo de la Duración del Proyecto 7 DURACIÓN DEL PROYECTO EN HORAS = 2374.5 horas/persona / 5 personas = 474.91 horas por miembro DURACIÓN EN MESES = 474.91 horas / 100 horas/mes = 4 meses 15 dias HORAS POR PERSONA = 2374.5 Horas/mes productivas estimadas en el proyecto Calculadas de 20 días laborables y De 5 horas productivas estimadas de las 8 de la jornada laboral normal diaria Se asigna la cantidad de participantes en el proyecto
20. Cálculo del Presupuesto del Proyecto Cálculo del Presupuesto del Proyecto 8 Costo Total del Proyecto = sueldos 1 participante del proyecto * 5 participantes * 5 meses + Otros costos necesarios durante la realización del proyecto = 2000 * 5 * 5 = 50000 DURACIÓN DEL PROYECTO EN MESES = 5 meses Participante 1: Sueldo Participante 2: Sueldo Participante n: Sueldo En la práctica se deben especificar Otros costos de operación para determinar el presupuesto total del proyecto