El documento describe los principales métodos para estimar el tiempo y esfuerzo requeridos para proyectos de software, incluyendo el método SLIM desarrollado por Putnam y la ecuación del software. Esta ecuación relaciona el producto (medido en líneas de código), el esfuerzo (medido en personas-mes) y el tiempo (medido en meses) usando parámetros de productividad y habilidad obtenidos de datos históricos de proyectos anteriores. El método se utiliza determinando primero una estimación del tamaño del product
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.
Modelo de estimación de proyectos david vOzzy Rocker
El modelo de estimación de Putnam proporciona una ecuación para estimar el tamaño de software en líneas de código en función del esfuerzo y el tiempo de desarrollo. La distribución del esfuerzo a lo largo del proyecto sigue una curva de Rayleigh-Norden. La ecuación permite calcular el esfuerzo total necesario para el desarrollo en función del tamaño del software y el tiempo de desarrollo.
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.
Los modelos de estimación describen tres modelos (básico, intermedio y detallado) para estimar el esfuerzo y tiempo requerido para proyectos de desarrollo de software. El modelo básico considera tres modos de desarrollo (orgánico, semiencajado y empotrado) y usa ecuaciones con constantes diferentes para cada modo. El modelo intermedio introduce 15 atributos relacionados con el producto, hardware, personal y proyecto para ajustar mejor las estimaciones. El modelo detallado mejora al intermedio al hacer las estimaciones sensibles a la f
Este documento describe los lenguajes de simulación, incluyendo su desarrollo inicial en los años 1950 utilizando lenguajes de propósito general y lenguajes especializados diseñados posteriormente. También discute las características comunes requeridas para la simulación discreta y provee ejemplos de lenguajes específicos de simulación como MIDAS, DYSAC, GPSS y SIMULA.
medolos tradicionales de desarrollo de software ( cascada - espiral)Cristhian Aguilar
El documento describe dos metodologías tradicionales de desarrollo de software: el método en cascada y el modelo espiral. El método en cascada sigue un proceso lineal de requisitos, diseño, implementación, pruebas y mantenimiento. Funciona mejor cuando los requisitos son claros y estables. El modelo espiral es un enfoque cíclico para reducir riesgos a través de iteraciones de análisis de riesgos, desarrollo y pruebas, y es más adecuado para proyectos complejos que evolucionan.
Este documento presenta cuatro ejercicios relacionados con diagramas causales. El primer ejercicio explica los elementos básicos de un diagrama causal y provee un ejemplo de cómo modelar la dinámica de una población afectada por nacimientos y muertes. Los ejercicios 2 y 3 piden construir diagramas causales para modelar el control de inventarios en un almacén y el proceso de llenar un vaso. El ejercicio 4 propone construir un diagrama causal para comprender la dinámica de la criminalidad basada en la desc
El documento describe los principales métodos para estimar el tiempo y esfuerzo requeridos para proyectos de software, incluyendo el método SLIM desarrollado por Putnam y la ecuación del software. Esta ecuación relaciona el producto (medido en líneas de código), el esfuerzo (medido en personas-mes) y el tiempo (medido en meses) usando parámetros de productividad y habilidad obtenidos de datos históricos de proyectos anteriores. El método se utiliza determinando primero una estimación del tamaño del product
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.
Modelo de estimación de proyectos david vOzzy Rocker
El modelo de estimación de Putnam proporciona una ecuación para estimar el tamaño de software en líneas de código en función del esfuerzo y el tiempo de desarrollo. La distribución del esfuerzo a lo largo del proyecto sigue una curva de Rayleigh-Norden. La ecuación permite calcular el esfuerzo total necesario para el desarrollo en función del tamaño del software y el tiempo de desarrollo.
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.
Los modelos de estimación describen tres modelos (básico, intermedio y detallado) para estimar el esfuerzo y tiempo requerido para proyectos de desarrollo de software. El modelo básico considera tres modos de desarrollo (orgánico, semiencajado y empotrado) y usa ecuaciones con constantes diferentes para cada modo. El modelo intermedio introduce 15 atributos relacionados con el producto, hardware, personal y proyecto para ajustar mejor las estimaciones. El modelo detallado mejora al intermedio al hacer las estimaciones sensibles a la f
Este documento describe los lenguajes de simulación, incluyendo su desarrollo inicial en los años 1950 utilizando lenguajes de propósito general y lenguajes especializados diseñados posteriormente. También discute las características comunes requeridas para la simulación discreta y provee ejemplos de lenguajes específicos de simulación como MIDAS, DYSAC, GPSS y SIMULA.
medolos tradicionales de desarrollo de software ( cascada - espiral)Cristhian Aguilar
El documento describe dos metodologías tradicionales de desarrollo de software: el método en cascada y el modelo espiral. El método en cascada sigue un proceso lineal de requisitos, diseño, implementación, pruebas y mantenimiento. Funciona mejor cuando los requisitos son claros y estables. El modelo espiral es un enfoque cíclico para reducir riesgos a través de iteraciones de análisis de riesgos, desarrollo y pruebas, y es más adecuado para proyectos complejos que evolucionan.
Este documento presenta cuatro ejercicios relacionados con diagramas causales. El primer ejercicio explica los elementos básicos de un diagrama causal y provee un ejemplo de cómo modelar la dinámica de una población afectada por nacimientos y muertes. Los ejercicios 2 y 3 piden construir diagramas causales para modelar el control de inventarios en un almacén y el proceso de llenar un vaso. El ejercicio 4 propone construir un diagrama causal para comprender la dinámica de la criminalidad basada en la desc
El documento describe el modelo de prototipos desarrollado por Kristen Nygaard y Ole-Johan Dahl en la década de 1950. El modelo involucra iteraciones de planificación, diseño, construcción y evaluación de prototipos para definir los requisitos del sistema. El proceso termina cuando los prototipos dejan de ser más baratos que continuar el desarrollo sin ellos. El modelo tiene ventajas como reducir costos y ajustarse mejor a cambios de requisitos, pero también riesgos como querer continuar desarrollando prototipos en lugar de pasar a la
Este documento presenta información sobre el objetivo de una materia de desarrollo de aplicaciones distribuidas. Explica conceptos clave como arquitectura, aplicación distribuida, capas de interfaz de usuario, manejo de datos y procesamiento de datos. También discute temas como integración de sistemas heredados, distribución de elementos de una aplicación y tecnologías heterogéneas y homogéneas.
Las Líneas de Producto Software (LPS) pueden por tanto englobarse dentro de ese
anhelo recurrente dentro de la Ingeniería del Software que es la reutilización. Pero nos han
recordado que mejorar la reutilización no lleva necesariamente a reducir los costes
globales de desarrollo debido a los costes adicionales de desarrollar (y gestionar)
precisamente estos artefactos re-usables. Las LPS han vuelto a recordarnos que la
reutilización eficaz no es sólo un problema técnico, sino también de procesos y
organización. El proceso determina cuándo y dónde se debe realizar el esfuerzo de reutilización.
La decisión no es baladí. De hecho, muchos de los fracasos en el desarrollo
basado en componentes (también orientado a la reutilización) se deben a fallos en el
proceso, más que en las técnicas que se utilizaban: se invertían esfuerzos en hacer el
componente reutilizable para determinadas situaciones que finalmente no se presentaban.
El documento describe el modelo de madurez CMM (Capability Maturity Model), el cual clasifica a las empresas de software en 5 niveles de madurez en sus procesos de desarrollo de software. Explica cada uno de los 5 niveles - Inicial, Repetible, Definido, Gestionado y Optimizado - así como los procesos clave que deben implementarse en cada nivel para alcanzar mayor madurez.
Este documento presenta una introducción al prototipado de software, incluyendo sus definiciones, formas de uso, beneficios y desafíos. Explica que un prototipo es una versión inicial de un sistema que se utiliza para demostrar conceptos y probar opciones de diseño. Los prototipos pueden usarse en análisis, diseño y pruebas para validar requisitos, explorar soluciones y verificar la viabilidad de un diseño.
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.
Este documento describe varias técnicas para estimar los costos de proyectos de software. Presenta métricas como líneas de código y puntos de función que pueden usarse para estimar el tamaño de un proyecto. También describe factores que afectan los costos como la capacidad de los programadores, la complejidad del producto y el tiempo disponible. Finalmente, resume técnicas como el juicio experto y Delphi para realizar estimaciones.
El documento habla sobre la gestión de redes. Define la gestión de redes y su objetivo de garantizar un nivel de servicio en los recursos gestionados con el mínimo coste. Explica el modelo FCAPS de gestión de redes funcionales definido por la UIT-T y la ISO, el cual cubre las áreas de fallas, configuración, contabilidad, rendimiento y seguridad. Luego describe las tareas asociadas a cada una de estas áreas funcionales de gestión.
El documento introduce conceptos clave sobre métricas técnicas de software, incluyendo factores de calidad como los definidos por McCall, FURPS e ISO 9126. Explica la importancia de medir atributos internos del software como la modularidad y la independencia funcional para predecir la calidad. También describe métricas para medir modelos de análisis y diseño, como los puntos de función y la complejidad estructural, de datos y del sistema.
Este documento describe el análisis de riesgos como parte de la planificación de un proyecto. Explica que existen riesgos del proyecto, del producto y empresariales, y que estos tipos de riesgos se superponen. También detalla seis tipos comunes de riesgos y las cuatro etapas del proceso de gestión de riesgos: identificación, análisis, planeación y monitoreo. El objetivo es anticipar riesgos que podrían afectar el proyecto y tomar acciones para evitarlos o minimizar
Introduccion a la administracion de los procesos y el procesador (S.O)Javier Alvarez
El documento habla sobre los conceptos básicos de procesos y administración de procesadores. Explica que un proceso es un programa en ejecución que tiene estado, entrada y salida. Los procesos pueden estar en ejecución, listos o bloqueados. También describe los estados de los procesos y cómo son creados, destruidos y suspendidos. Además, cubre temas como interrupciones, el núcleo del sistema operativo y la planificación de procesos.
Este documento describe los archivos virtuales y reales. Los archivos virtuales son archivos temporales creados durante la ejecución de un sistema y utilizados para almacenar información de manera temporal, siendo borrados una vez finalizada la ejecución. Los archivos con extensión .tmp son un ejemplo común de archivos virtuales. Por otro lado, los archivos reales contienen programas, datos u otros elementos, mostrando el espacio real que ocupan en un disco duro.
El documento presenta el caso práctico de levantamiento de requisitos de software para el máster en dirección estratégica en ingeniería de software. Incluye información sobre la estudiante, objetivos del caso que involucran analizar técnicas de levantamiento de requisitos, dificultades y los principios de JAD. También presenta diferentes técnicas como entrevistas, prototipado y marcos como UML, ISO 25010, RUP y SOA Reference.
El documento describe el modelo de casos de uso y sus elementos. Explica que el modelo de casos de uso describe los requerimientos funcionales de un sistema a través de casos de uso, actores y su interacción. Define conceptos clave como actor, caso de uso, flujo básico y flujo alternativo para la descripción de casos de uso. Además, explica cómo construir un modelo de casos de uso identificando actores, casos de uso y diagramando su interacción.
Este documento presenta el plan de un sistema de trámite documentario para la Universidad Nacional de Moquegua. Actualmente, la universidad lleva los procesos de documentación de forma manual, lo que requiere mucho tiempo. El sistema propuesto automatizará la gestión de documentos entrantes para agilizar los procesos y reducir errores. El documento incluye un análisis de factibilidad técnica, económica y legal, así como los requisitos, actores y casos de uso del sistema. Finalmente, propone el uso de herramientas como ERwin y Microsoft
Modelos de programacion lineal y modelos dinamicos (2)Bruce Dávila
El documento clasifica los modelos según su estructura. Menciona que los modelos pueden ser determinísticos o estocásticos, lineales o no lineales, estáticos o dinámicos, continuos o discretos. Luego describe la programación lineal, indicando que optimiza una función objetivo lineal sujeta a restricciones lineales también. Finalmente, explica brevemente los diagramas causales y de Forrester, que representan las relaciones entre las variables de un modelo dinámico.
Etapas del Proceso de la Ingeniería del SoftwareT.I.C
El documento describe las principales etapas del proceso de ingeniería de software: 1) Planificación y análisis de requisitos, 2) Implementación, pruebas y documentación, 3) Despliegue y mantenimiento. Explica que la planificación incluye obtener requisitos del cliente y especificar el alcance del proyecto. La implementación involucra programación, pruebas para detectar errores, y documentación interna. El despliegue distribuye el código en producción y el mantenimiento corrige problemas e incorpora mejoras continuas.
Modelo espiral de boehm CALIDAD DE SOFTWAREJhOnss KrIollo
El documento describe el modelo en espiral de desarrollo de software propuesto por Boehm. Este modelo tiene en cuenta los riesgos y permite el desarrollo incremental de versiones de software a través de iteraciones o "vueltas" de la espiral. Cada vuelta incluye actividades de planificación, análisis de riesgos, ingeniería y evaluación. El modelo se ha modificado para incluir seis regiones de tareas y se enfoca en reducir riesgos y permitir la adaptación del software a lo largo del tiempo.
Este documento presenta 25 estándares de calidad de software según el IEEE. Algunos de los estándares cubren temas como la gestión de configuración, planes de aseguramiento de calidad, medición de fiabilidad, documentación de pruebas, procesos del ciclo de vida, requisitos de calidad y pruebas, gestión de riesgos, métricas de calidad, clasificación de anomalías, y verificación y validación de procesos y software. El documento proporciona una breve descripción de cada estándar.
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.
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
El documento describe el modelo de prototipos desarrollado por Kristen Nygaard y Ole-Johan Dahl en la década de 1950. El modelo involucra iteraciones de planificación, diseño, construcción y evaluación de prototipos para definir los requisitos del sistema. El proceso termina cuando los prototipos dejan de ser más baratos que continuar el desarrollo sin ellos. El modelo tiene ventajas como reducir costos y ajustarse mejor a cambios de requisitos, pero también riesgos como querer continuar desarrollando prototipos en lugar de pasar a la
Este documento presenta información sobre el objetivo de una materia de desarrollo de aplicaciones distribuidas. Explica conceptos clave como arquitectura, aplicación distribuida, capas de interfaz de usuario, manejo de datos y procesamiento de datos. También discute temas como integración de sistemas heredados, distribución de elementos de una aplicación y tecnologías heterogéneas y homogéneas.
Las Líneas de Producto Software (LPS) pueden por tanto englobarse dentro de ese
anhelo recurrente dentro de la Ingeniería del Software que es la reutilización. Pero nos han
recordado que mejorar la reutilización no lleva necesariamente a reducir los costes
globales de desarrollo debido a los costes adicionales de desarrollar (y gestionar)
precisamente estos artefactos re-usables. Las LPS han vuelto a recordarnos que la
reutilización eficaz no es sólo un problema técnico, sino también de procesos y
organización. El proceso determina cuándo y dónde se debe realizar el esfuerzo de reutilización.
La decisión no es baladí. De hecho, muchos de los fracasos en el desarrollo
basado en componentes (también orientado a la reutilización) se deben a fallos en el
proceso, más que en las técnicas que se utilizaban: se invertían esfuerzos en hacer el
componente reutilizable para determinadas situaciones que finalmente no se presentaban.
El documento describe el modelo de madurez CMM (Capability Maturity Model), el cual clasifica a las empresas de software en 5 niveles de madurez en sus procesos de desarrollo de software. Explica cada uno de los 5 niveles - Inicial, Repetible, Definido, Gestionado y Optimizado - así como los procesos clave que deben implementarse en cada nivel para alcanzar mayor madurez.
Este documento presenta una introducción al prototipado de software, incluyendo sus definiciones, formas de uso, beneficios y desafíos. Explica que un prototipo es una versión inicial de un sistema que se utiliza para demostrar conceptos y probar opciones de diseño. Los prototipos pueden usarse en análisis, diseño y pruebas para validar requisitos, explorar soluciones y verificar la viabilidad de un diseño.
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.
Este documento describe varias técnicas para estimar los costos de proyectos de software. Presenta métricas como líneas de código y puntos de función que pueden usarse para estimar el tamaño de un proyecto. También describe factores que afectan los costos como la capacidad de los programadores, la complejidad del producto y el tiempo disponible. Finalmente, resume técnicas como el juicio experto y Delphi para realizar estimaciones.
El documento habla sobre la gestión de redes. Define la gestión de redes y su objetivo de garantizar un nivel de servicio en los recursos gestionados con el mínimo coste. Explica el modelo FCAPS de gestión de redes funcionales definido por la UIT-T y la ISO, el cual cubre las áreas de fallas, configuración, contabilidad, rendimiento y seguridad. Luego describe las tareas asociadas a cada una de estas áreas funcionales de gestión.
El documento introduce conceptos clave sobre métricas técnicas de software, incluyendo factores de calidad como los definidos por McCall, FURPS e ISO 9126. Explica la importancia de medir atributos internos del software como la modularidad y la independencia funcional para predecir la calidad. También describe métricas para medir modelos de análisis y diseño, como los puntos de función y la complejidad estructural, de datos y del sistema.
Este documento describe el análisis de riesgos como parte de la planificación de un proyecto. Explica que existen riesgos del proyecto, del producto y empresariales, y que estos tipos de riesgos se superponen. También detalla seis tipos comunes de riesgos y las cuatro etapas del proceso de gestión de riesgos: identificación, análisis, planeación y monitoreo. El objetivo es anticipar riesgos que podrían afectar el proyecto y tomar acciones para evitarlos o minimizar
Introduccion a la administracion de los procesos y el procesador (S.O)Javier Alvarez
El documento habla sobre los conceptos básicos de procesos y administración de procesadores. Explica que un proceso es un programa en ejecución que tiene estado, entrada y salida. Los procesos pueden estar en ejecución, listos o bloqueados. También describe los estados de los procesos y cómo son creados, destruidos y suspendidos. Además, cubre temas como interrupciones, el núcleo del sistema operativo y la planificación de procesos.
Este documento describe los archivos virtuales y reales. Los archivos virtuales son archivos temporales creados durante la ejecución de un sistema y utilizados para almacenar información de manera temporal, siendo borrados una vez finalizada la ejecución. Los archivos con extensión .tmp son un ejemplo común de archivos virtuales. Por otro lado, los archivos reales contienen programas, datos u otros elementos, mostrando el espacio real que ocupan en un disco duro.
El documento presenta el caso práctico de levantamiento de requisitos de software para el máster en dirección estratégica en ingeniería de software. Incluye información sobre la estudiante, objetivos del caso que involucran analizar técnicas de levantamiento de requisitos, dificultades y los principios de JAD. También presenta diferentes técnicas como entrevistas, prototipado y marcos como UML, ISO 25010, RUP y SOA Reference.
El documento describe el modelo de casos de uso y sus elementos. Explica que el modelo de casos de uso describe los requerimientos funcionales de un sistema a través de casos de uso, actores y su interacción. Define conceptos clave como actor, caso de uso, flujo básico y flujo alternativo para la descripción de casos de uso. Además, explica cómo construir un modelo de casos de uso identificando actores, casos de uso y diagramando su interacción.
Este documento presenta el plan de un sistema de trámite documentario para la Universidad Nacional de Moquegua. Actualmente, la universidad lleva los procesos de documentación de forma manual, lo que requiere mucho tiempo. El sistema propuesto automatizará la gestión de documentos entrantes para agilizar los procesos y reducir errores. El documento incluye un análisis de factibilidad técnica, económica y legal, así como los requisitos, actores y casos de uso del sistema. Finalmente, propone el uso de herramientas como ERwin y Microsoft
Modelos de programacion lineal y modelos dinamicos (2)Bruce Dávila
El documento clasifica los modelos según su estructura. Menciona que los modelos pueden ser determinísticos o estocásticos, lineales o no lineales, estáticos o dinámicos, continuos o discretos. Luego describe la programación lineal, indicando que optimiza una función objetivo lineal sujeta a restricciones lineales también. Finalmente, explica brevemente los diagramas causales y de Forrester, que representan las relaciones entre las variables de un modelo dinámico.
Etapas del Proceso de la Ingeniería del SoftwareT.I.C
El documento describe las principales etapas del proceso de ingeniería de software: 1) Planificación y análisis de requisitos, 2) Implementación, pruebas y documentación, 3) Despliegue y mantenimiento. Explica que la planificación incluye obtener requisitos del cliente y especificar el alcance del proyecto. La implementación involucra programación, pruebas para detectar errores, y documentación interna. El despliegue distribuye el código en producción y el mantenimiento corrige problemas e incorpora mejoras continuas.
Modelo espiral de boehm CALIDAD DE SOFTWAREJhOnss KrIollo
El documento describe el modelo en espiral de desarrollo de software propuesto por Boehm. Este modelo tiene en cuenta los riesgos y permite el desarrollo incremental de versiones de software a través de iteraciones o "vueltas" de la espiral. Cada vuelta incluye actividades de planificación, análisis de riesgos, ingeniería y evaluación. El modelo se ha modificado para incluir seis regiones de tareas y se enfoca en reducir riesgos y permitir la adaptación del software a lo largo del tiempo.
Este documento presenta 25 estándares de calidad de software según el IEEE. Algunos de los estándares cubren temas como la gestión de configuración, planes de aseguramiento de calidad, medición de fiabilidad, documentación de pruebas, procesos del ciclo de vida, requisitos de calidad y pruebas, gestión de riesgos, métricas de calidad, clasificación de anomalías, y verificación y validación de procesos y software. El documento proporciona una breve descripción de cada estándar.
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.
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
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).
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 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.
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.
How to Make Awesome SlideShares: Tips & TricksSlideShare
Turbocharge your online presence with SlideShare. We provide the best tips and tricks for succeeding on SlideShare. Get ideas for what to upload, tips for designing your deck and more.
SlideShare is a global platform for sharing presentations, infographics, videos and documents. It has over 18 million pieces of professional content uploaded by experts like Eric Schmidt and Guy Kawasaki. The document provides tips for setting up an account on SlideShare, uploading content, optimizing it for searchability, and sharing it on social media to build an audience and reputation as a subject matter expert.
Este documento describe el modelo de estimación de Putnam para estimar el tamaño y esfuerzo requerido para proyectos de desarrollo de software. El modelo se basa en la curva de Rayleigh-Norden para relacionar el número de líneas de código, el esfuerzo y el tiempo de desarrollo. El modelo puede usarse para estimar el esfuerzo requerido en personas-año para un proyecto de software de diseño asistido por computadora (CAD).
Este documento presenta el Modelo de Estimación de Putnam, el cual es un modelo multivariable dinámico que asume una distribución específica del esfuerzo a lo largo de la vida de un proyecto de software. El modelo utiliza la curva de Rayleigh-Norden para relacionar el número de líneas de código con el esfuerzo y tiempo de desarrollo, donde Ck es una constante que refleja el estado de la tecnología. El documento también explica cómo calcular el esfuerzo de desarrollo a partir de esta ecuación
El documento describe el modelo SLIM (Software Life Cycle Management) de estimación de proyectos de software desarrollado por Lawrence Putnam. El modelo de Putnam estima el esfuerzo requerido para completar un proyecto de software basado en su tamaño mediante dos ecuaciones que relacionan el esfuerzo de desarrollo y el calendario. El modelo es empírico y ajusta datos históricos de esfuerzo y tamaño de proyectos a una curva estadística para estimar futuros proyectos.
Este documento introduce conceptos básicos sobre la evaluación del rendimiento de sistemas informáticos. Explica que la evaluación del rendimiento mide la capacidad de los sistemas para proporcionar prestaciones a los usuarios. También describe cómo medir el rendimiento mediante el tiempo de ejecución de programas de prueba y cómo comparar el rendimiento y coste entre sistemas. Además, presenta la ley de Amdahl, la cual establece que la mejora global del rendimiento de un sistema está limitada por aquellas partes del sistema
Modelo de estimación de proyectos david vOzzy Rocker
El modelo de estimación de Putnam proporciona una ecuación para estimar el tamaño de software en líneas de código en función del esfuerzo y el tiempo de desarrollo. La distribución del esfuerzo a lo largo del proyecto sigue una curva de Rayleigh-Norden. La ecuación permite calcular el esfuerzo total necesario para el desarrollo en función del tamaño del software y el tiempo de desarrollo.
Este documento trata sobre la administración de proyectos de software. Explica que la administración comienza antes del desarrollo técnico y continúa hasta que el software es descontinuado. Detalla elementos clave como la definición de objetivos, estimaciones, análisis de riesgos, calendarización y seguimiento. También cubre temas como mediciones, métricas, descomposición de tareas y estimación de esfuerzo.
Este documento discute diferentes métodos para estimar el esfuerzo y costo en proyectos de desarrollo de software. Presenta cuatro enfoques comunes como juicio de expertos, estimación por analogía, descomposición del proyecto y modelos de estimación. También describe dos métodos basados en la funcionalidad del sistema: el método de puntos por función desarrollado por Albrecht y Gaffney y el método Mk-II FP mejorado por Symons. Ambos métodos calculan el tamaño del proyecto en términos de "puntos por
El documento describe las diferencias entre COCOMO II y COCOMO 81, dos modelos de estimación de esfuerzo de desarrollo de software. COCOMO II incluye varios submodelos que producen estimaciones más detalladas que COCOMO 81. Los submodelos son composición de aplicaciones, diseño temprano, reuso y post-arquitectura. COCOMO II también toma en cuenta factores como la volatilidad de requerimientos, reuso de código y madurez del proceso de desarrollo.
El documento describe varias técnicas para estimar el esfuerzo, costo y tiempo requeridos para completar proyectos de desarrollo de software. Explica que la estimación es una predicción probabilística basada en datos de proyectos anteriores. Presenta modelos como COCOMO y los puntos de función que estiman el esfuerzo en función del tamaño del proyecto y factores de ajuste. También cubre técnicas como la descomposición del proyecto y el análisis de regresión.
Antes de comenzar un proyecto de software, el gerente de proyecto y el equipo deben estimar el trabajo requerido, los recursos necesarios y el tiempo de duración del proyecto. Se describen varias técnicas para estimar estos factores, incluidos los modelos COCOMO que utilizan líneas de código como variable de entrada para calcular meses-persona, tiempo de desarrollo y número de personas requeridas. También se mencionan otros atributos como la confiabilidad, el tamaño de la base de datos y la complejidad del product
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 el modelo COCOMO II para la estimación de proyectos de software. El modelo COCOMO II incluye tres submodelos: el modelo ACM para aplicaciones, el modelo EDM para diseño inicial y el modelo PAM para post-arquitectura. El modelo ACM se utiliza principalmente en las primeras etapas y se basa en puntos de objeto para estimar el esfuerzo requerido para aplicaciones diversificadas mediante el uso de prototipos. El documento proporciona un ejemplo de cómo aplicar el modelo ACM para estimar el esfuerzo en persona-
El documento describe un proyecto para desarrollar un nuevo robot industrial llamado RAMOV. Se lista las actividades del proyecto y su duración. Se construye una red CPM para el proyecto y se identifica la ruta crítica, que determina que el proyecto tomará 63 días en completarse.
Este documento describe varios modelos empíricos para estimar el esfuerzo de desarrollo de software. Explica el modelo COCOMO de Boehm, que estima el esfuerzo en función del tamaño del proyecto y factores de complejidad. También describe la ecuación del software de Fenton, que considera el tamaño, duración y productividad del proyecto. Por último, introduce el modelo CMM para evaluar la madurez del proceso de desarrollo de una organización en 5 niveles.
Este documento presenta el modelo COCOMO (COnstructive COst MOdel) para estimar el esfuerzo, costo y duración de proyectos de desarrollo de software. COCOMO consiste en tres modelos de complejidad creciente: básico, intermedio y detallado. El modelo intermedio toma en cuenta factores como el tamaño del proyecto, la experiencia del equipo, herramientas utilizadas y calidad requerida para calcular el esfuerzo. Aplica fórmulas que involucran líneas de código, coeficientes y un
Este documento describe el modelo COCOMO (Constructive Cost Model) para estimar los costos de desarrollo de software. Explica la historia y evolución del modelo COCOMO original de 1981 al COCOMO II de 1995, el cual considera factores como reusabilidad, objetos y librerías. También resume los diferentes modos y fórmulas del COCOMO para calcular el esfuerzo requerido en función del tamaño y complejidad de un proyecto de software.
Este documento describe modelos empíricos para estimar el esfuerzo, duración y recursos de proyectos de desarrollo de software. Presenta la Ecuación del Software, un modelo multivariable dinámico que asigna el esfuerzo a lo largo del tiempo de un proyecto en función de parámetros como las líneas de código, la productividad y habilidades requeridas. Explica cómo aplicar la ecuación para estimar el esfuerzo y duración mínima de un proyecto de software para diseño asistido por computadora.
El documento habla sobre la estimación de proyectos de software. Explica que es importante hacer una estimación precisa del costo, tiempo y recursos necesarios antes de comenzar un proyecto. Describe diferentes técnicas para estimar el tamaño y complejidad del software como líneas de código, puntos de función o componentes estándar. También presenta el modelo COCOMO que utiliza factores como la fiabilidad, complejidad y experiencia del equipo para calcular el esfuerzo requerido.
Planificación de proyectos de softwarerubenleiva21
Este documento describe los conceptos clave de la planificación de proyectos de software. Explica que la planificación tiene como objetivo estimar los recursos, costos y tiempo de un proyecto de software. Detalla las etapas de definición del alcance, estimación de recursos humanos y herramientas, y métodos comunes de estimación como los modelos empíricos y COCOMO.
Este documento presenta el modelo COCOMO II para la estimación del esfuerzo de proyectos de desarrollo de software. COCOMO II incluye tres modelos: Composición de Aplicación, Diseño Temprano y Post-Arquitectura. El modelo de Diseño Temprano estima el esfuerzo usando puntos de función y siete factores de costo. El modelo Post-Arquitectura usa puntos de función, líneas de código o ambos, y diecisiete factores de costo. COCOMO II mejora el modelo original considerando nuevas técnic
El curso de Texto Integrado de 8vo grado es un programa académico interdisciplinario que combina los contenidos y habilidades de varias asignaturas clave. A través de este enfoque integrado, los estudiantes tendrán la oportunidad de desarrollar una comprensión más holística y conexa de los temas abordados.
En el área de Estudios Sociales, los estudiantes profundizarán en el estudio de la historia, geografía, organización política y social, y economía de América Latina. Analizarán los procesos de descubrimiento, colonización e independencia, las características regionales, los sistemas de gobierno, los movimientos sociales y los modelos de desarrollo económico.
En Lengua y Literatura, se enfatizará el desarrollo de habilidades comunicativas, tanto en la expresión oral como escrita. Los estudiantes trabajarán en la comprensión y producción de diversos tipos de textos, incluyendo narrativos, expositivos y argumentativos. Además, se estudiarán obras literarias representativas de la región latinoamericana.
El componente de Ciencias Naturales abordará temas relacionados con la biología, la física y la química, con un enfoque en la comprensión de los fenómenos naturales y los desafíos ambientales de América Latina. Se explorarán conceptos como la biodiversidad, los recursos naturales, la contaminación y el desarrollo sostenible.
En el área de Matemática, los estudiantes desarrollarán habilidades en áreas como la aritmética, el álgebra, la geometría y la estadística. Estos conocimientos matemáticos se aplicarán a la resolución de problemas y al análisis de datos, en el contexto de las temáticas abordadas en las otras asignaturas.
A lo largo del curso, se fomentará la integración de los contenidos, de manera que los estudiantes puedan establecer conexiones significativas entre los diferentes campos del conocimiento. Además, se promoverá el desarrollo de habilidades transversales, como el pensamiento crítico, la resolución de problemas, la investigación y la colaboración.
Mediante este enfoque de Texto Integrado, los estudiantes de 8vo grado tendrán una experiencia de aprendizaje enriquecedora y relevante, que les permitirá adquirir una visión más amplia y comprensiva de los temas estudiados.
Examen de Selectividad. Geografía junio 2024 (Convocatoria Ordinaria). UCLMJuan Martín Martín
Examen de Selectividad de la EvAU de Geografía de junio de 2023 en Castilla La Mancha. UCLM . (Convocatoria ordinaria)
Más información en el Blog de Geografía de Juan Martín Martín
http://blogdegeografiadejuan.blogspot.com/
Este documento presenta un examen de geografía para el Acceso a la universidad (EVAU). Consta de cuatro secciones. La primera sección ofrece tres ejercicios prácticos sobre paisajes, mapas o hábitats. La segunda sección contiene preguntas teóricas sobre unidades de relieve, transporte o demografía. La tercera sección pide definir conceptos geográficos. La cuarta sección implica identificar elementos geográficos en un mapa. El examen evalúa conocimientos fundamentales de geografía.
SEMIOLOGIA DE HEMORRAGIAS DIGESTIVAS.pptxOsiris Urbano
Evaluación de principales hallazgos de la Historia Clínica utiles en la orientación diagnóstica de Hemorragia Digestiva en el abordaje inicial del paciente.
2. Técnica de estimación de costes de proyecto de
software, desarrollada por Lawrence H. Putnam en
1978.
Fue desarrollada para estimar los costes de los
grandes proyectos de software.
3. Producto: representa cierta medida sobre el
funcionamiento del mismo. La medida SLOC suele
ser una medida habitual de la funcionalidad.
Esfuerzo: representa el trabajo humano, medido en
persona-meses o personas-años.
Tiempo: representa la duración del trabajo.
Constante: es un factor de proporcionalidad.
LA ECUACIÓN BÁSICA
4. PRODUCTIVIDAD DEL PROCESO
La ecuación anterior tiene mayor sentido si la
expresamos como:
Putnam estudia una base de datos: 750 sistemas
procedentes de la Air Force Electronic Systems
Division,Rome Air Development Center y otros
sistemas de procedencia diversa.
Se deduce que la relación entre los términos no es
lineal.
5. LA ECUACIÓN DEL SOFTWARE
Producto: se mide en SLOC
Parámetro de productividad (PP): se suele derivar
de datos históricos aplicando la ecuación.
Esfuerzo: Hombres-año / hombres-mes
B: es un parámetro de habilidad depende del
tamaño del producto.
Tiempo: de desarrollo en años o meses
7. OBTENIENDO EL FACTOR PRODUCTIVIDAD
Se obtiene por calibración a partir de sistemas ya
concluidos.
Por ejemplo: dado un sistema de 30.000 líneas de
Cobol, finalizado en 17 meses con un gasto de
recursos de 146 personas-mes, tenemos:
9. UTILIZACIÓN DE LA ECUACIÓN PARA LA
ESTIMACIÓN
La utilización al estimar tiempo y esfuerzo al
comienzo de un nuevo proyecto.
La ecuación del software debe estimar el tiempo e
desarrollo (T) y esfuerzo de desarrollo (E).
Soluciones:
Determinista.
Simulación
Programación Lineal
Se deben conocer el (PI) PP de la organización
mediante proyectos anteriores y una estimación del
Producto (LDC).
10. SOLUCIÓN DETERMINISTA
Basándose en datos históricos, se estudiaron 20
proyectos, Norden comprobó que:
Los procesos de desarrollo tienen 5 fases
Tienen un comportamiento, en cuanto a la producción
similar a una curva de Rayleigh.
La cola de la curva se debe al mantenimiento.
12. SLIM: CASO PRÁCTICO
Se tiene que desarrollar un nuevo sistema para la
ubicación, registro, distribución de unidades
móviles de una empresa que brinda el servicio de
taxi.
Se pretende estimar el tiempo y esfuerzo para
desarrollar el software.
Segundo:
13. PRIMERO
Se recolectan los datos de los registros de
sistemas anteriores u sistemas similares externos
para obtener el parámetro de productividad.
Se tienen los siguientes datos:
SLOC Lenguaje Personas/M
es
Tiempo
(meses)
50000 Cobol 156 14
65000 C++ 150 17
53000 Pascal 95 14
70000 C++ 145 16
14. SEGUNDO
Obtenemos una estimación de la cantidad de
líneas de código de acuerdo a registros anteriores.
El software será desarrollado con un lenguaje C++,
y poseerá 60000 SLOC.
Tomando el dato histórico del sistema de 70000
SLOC
PP=6508
Entonces el valor de B: 0.37
15. DOS VARIABLES
Tiempo y Esfuerzo: dos variables con las que se
puede estimar el esfuerzo (personas) y tiempo
(meses)