Métricas del software. Calidad en el Desarrollo de Software. Métricas para el presupuesto. Métricas del software - resumen. Métricas del software

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Métricas del software. Calidad en el Desarrollo de Software. Métricas para el presupuesto. Métricas del software - resumen. Métricas del software"

Transcripción

1 Métricas del software Métricas del software Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur You can t control what you can t measure Tom DeMarco Segundo Cuatrimestre 2007 Métricas del software - resumen objetivo: maximizar la cantidad de funciones entregables por unidad de costo, considerando el costo total (todo el tiempo de vida) del sistema costo total del sistema: costo de desarrollo + costo de producción + costo de mantenimiento

2 Pasos a seguir Modelización del problema pasos a seguir: 1 formular un sólo indicador de medida de éxito vs el objetivo. BPB: Bang per Buck (impacto por peso) 2 coleccionar datos en una muestra de proyectos para establecer estándares de performance de BPB 3 buscar y evaluar predictores para aquellas partes de medida del BPB que influyen a futuro 4 motivar al personal para mejorar el BPB. El personal debe estar informado de cómo se calcula el BPB 5 publicar el BPB proyectado durante el proyecto, y el real luego de 6 meses de la implementación un modelo consiste de una partición, junto con un registro de las interfaces entre las piezas de la partición se necesitan tres perspectivas para especificar la mayoría de los sistemas: modelo funcional: visión particionada de lo que hace el sistema modelo de datos retenidos: visión particionada de lo que el sistema recuerda modelo de comportamiento: visión de los diferentes estados de comportamiento que caracterizan al sistema Métricas de especificación Componentes primitivas de un modelo la confección de un modelo formal provee tres beneficios: el modelo de especificación es público. Puede ser corregido y refinado por miembros del proyecto o usuario el modelo de especificación tiene características medibles que pueden ser relacionadas con performance observada el modelo de especificación es terminado en forma temprana durante el proyecto, provee oportunidad para corregir las estimaciones el modelo de especificación describe los requerimientos en sí mismo, no la forma de satisfacerlos. un análisis cuantitativo del modelo provee una medida de las funciones componente primitiva: no se descompone en componentes subordinadas dependiendo de lo que se particione, se obtienen seis clases de primitivas: Elemento Particiona Produce primitivas DFD requerimientos del sistema primitivas funcionales DD datos del sistema datos elementales diag. objetos datos retenidos objetos diag. objetos datos retenidos relaciones diag. estados características de control estados diag. estados características de control transiciones

3 Métricas a partir de las primitivas Métricas a partir de las primitivas analizar las primitivas provee métricas básicas para medir el Bang: PF: número de primitivas funcionales automáticas PFM: número de primitivas funcionales manuales modificables DE: número de datos elementales dentro del sistema automático DEI: número de datos elementales de input DEO: número de datos elementales de output DER: número de datos elementales retenidos métricas básicas para medir el Bang (cont.): OB: número de objetos retenidos RE: número de relaciones en el modelo de datos retenido ST : número de estados en el modelo de comportamiento TR: número de transiciones en el modelo de comportamiento TC i : número de data tokens en la primitiva i RE i : número de relaciones que involucran al objeto i Formulación de una teoría de costos Indicador principal bang tentativo bang = PF (FactorDePesoParaPF)+DE (FactorDePesoParaDE)+... para caracterizar el bang se elige uno de los indicadores como el principal y se usan los otros para modificarlo en la mayoría de los sistemas administrativos PF es el principal indicador hay sistemas altamente orientados a funciones y otros a datos, dependiendo de esto es el indicador que se deberá considerar como principal se pueden analizar dos razones en función de PF (primitivas funcionales) y RE (relaciones entre objetos): RE/PF < 0,7 sistema orientado a funciones RE/PF > 1,5 sistema orientado a datos la razón DEO/PF es una medida de cuánto el sistema está dedicado a cálculos o a administración de datos

4 Clasificación de proyectos Particiones uniformes para determinar el criterio de hasta donde se debe particionar se puede usar TC avg = TC i /PF i regla de partición uniforme: dejar una componente como primitiva sólo si no es posible una partición o si la nueva partición no reduce el TC avg I II las primitivas se pueden clasificar de acuerdo a su función en: separación: dividen los datos de input merge: combinan los datos de input dirección de datos: dirigen datos de acuerdo a una variable de control actualización simple: actualiza uno o mas datos en almacenamientos administración de almacenamientos: analiza datos almacenados y actúa basado en el estado de los datos clasificación de primitivas (cont.) edición: evalúa nuevos datos en frontera hombre-máquina verificación: chequea e informa inconsistencias manipulación de textos: administra textos sincronización: decide cuándo actuar o decide por otras generación de output: formatea nuevos flujos de datos (no tabulares) display: construye outputs tabulares (2 dimensiones) aritméticas: realiza cálculos inicialización: setea valores para datos almacenados

5 III clasificación de primitivas (cont.) computación: cálculos matemáticos complejos administración de dispositivos: controla dispositivos los factores dependen del contexto: tipos de sistemas herramientas, lenguajes de programación en los sistemas orientados a datos el peso depende de los RE i de los objetos existen factores de corrección en función de los RE i el bang es un indicador cuantitativo de las funciones útiles netas desde el punto de vista del usuario. Independiente de la implementacion en sistemas híbridos se aconseja manejar dos bangs, el funcional y el de datos. No se puede generalizar una fórmula que los relacione objetivos de calcular el bang: se usa como un predictor fuerte y anticipado del esfuerzo se usa para calcular eficiencia productiva: BPB se deben usar otras métricas para otras actividades, como por ejemplo conversión de la base de datos, etc funcional orientado a datos bang ::= 0 para cada primitiva funcional f[i] del modelo TC[i] ::= sumatoria de data token de f[i] PFC[i] ::= corrección(tc[i] clasificar f[i] buscar PesoCorr[i] en tabla de corrección y de acuerdo al tipo de primitiva bang ::= bang + PFC[i] * PesoCorr[i] bang ::= 0 para cada objeto del modelo de datos calcular RE[i] OBC[i] ::= corrección(re[i]) bang ::= bang + OBC[i]

6 Tamaño del software Medición del tamaño en software, el tamaño no es lo que importa ya que en general no considera esfuerzo: no tiene en cuenta redundancia y complejidad productividad: no consideran funcionalidad costo: no contabiliza reuso el tamaño del software puede ser descripto con tres atributos: longitud: mide tamaño físico del producto funcionalidad: mide las funciones provistas por el producto complejidad: puede ser interpretada de distintas maneras del problema a resolver del algoritmo utilizado, eficiencia del software estructural: mide la estructura del SW implementada cognitiva: esfuerzo requerido para entender el SW Consideraciones Productos hay consenso en medir longitud de programas, pero no de especificaciones existen trabajos para medir funcionalidad de especificaciones existen pocos avances en medición de complejidad los tres productos mas importantes cuyo tamaño sería importante medir son: especificaciones diseño código la medida mas comúnmente usada son las líneas de código: LOC se debe tener en cuenta: líneas en blanco, líneas de comentarios, declaración de datos y líneas que contienen varias instrucciones

7 Líneas de código Líneas de código Conte, Dunsmore & Shen: cualquier línea de texto de programa que no es comentario o línea en blanco, independientemente del número de sentencias o fragmentos de sentencias en la línea Hewlett-Packard: una sentencia de código fuente no comentada; cualquier sentencia excepto comentarios o líneas en blanco NCLOC - CLOC: non commented line of code - commented line of code ELOC: effective line of code longitud total LOC = NCLOC + CLOC es posible distinguir entre la cantidad de código entregado (DSI Delivered Source instructions) y la cantidad de código desarrollado formula de Halstead: volumen = longitud log 2 (vocabulario) otro enfoque es medir longitud de acuerdo a: número de bytes de almacenamiento requerido para el texto del programa número de caracteres (CHAR) en el texto del programa Líneas de código de especificaciones en programación visual, entornos de ventanas, orientación a objetos lenguajes de cuarta generación, cambian las nociones de tamaño surgen dos nuevos objetivos de medición: cómo se tienen en cuenta objetos no textuales? cómo medimos componentes construidas externamente? Pfleeger: contar objetos y métodos conduce a estimaciones mas precisas las especificaciones y diseños consisten de textos y diagramas se deben medir diferentes objetos atómicos los objetos atómicos para DFD: procesos, entidades externas, flujos de datos, almacenamientos. las entidades atómicas para especificaciones algebraicas son clases, funciones, operaciones y axiomas intuitivamente: se predice la longitud para tratar de relacionar la longitud de productos de etapas posteriores con la longitud de productos ya construidos

8 de especificaciones Reuso razón de expansión α: tamaño de diseño / tamaño de código LOC = a i = 1 n S i, donde S i es el tamaño del módulo i Walston & Felix: D documentación medida en páginas L longitud del programa D = 49L 1,01 para estimaciones precisas, se deben recolectar datos para entornos específicos el reuso mejora la productividad y la calidad. Es difícil de definir formalmente grados de reuso publicado por NASA/Goddard s Software Engineering Lab reuso verbatim: reusado sin cambio ligeramente modificado: se reusó modificando menos del 25 % LOC extensamente modificado: se reusó modificando más del 25 % LOC nuevo: ninguna línea proviene de un componente previo razón de reuso r = LineasReusadas/LOC Puntos de función de Albrecht existen tres enfoques para medir funcionalidad: puntos de función de Albrecht COCOMO II peso de especificación de De Marco idea intuitiva: si un programa P es la implementación de la especificación S, entonces P y S deberían tener la misma funcionalidad los puntos de función (PFA) intentan medir la cantidad de funcionalidad de un sistema, descripta en la especificación pasos: 1 identificar inputs externos outputs externos consultas archivos externos archivos internos

9 Puntos de función de Albrecht pasos (cont.) 1 determinar complejidad subjetiva a cada ítem: simple, media, compleja y asignarle un peso según la tabla 2 calcular PFNA: PFNA = 15 i=1 # tipo i Peso i 3 calcular el factor de complejidad técnico (FCT ): FCT = 0,65 + 0,01 14 F i i=1 donde F i es la valoración de 14 posibles factores de complejidad en el rango de 0 a 5. El resultado es tal que 0,65 FCT 1,35 4 calcular PFA PFA = PFNA FCT Puntos de función de Albrecht - peso de cada categoría de items Item Factor de Peso simple medio complejo inputs externos outputs externos consultas archivos externos archivos internos Componentes del Factor de Técnico Evaluación de los puntos de función de Albrecht F 1 confiabilidad de backup y recuperación F 2 comunicacion de datos F 3 funciones distribuidas F 4 performance F 5 dependencia de la configuración F 6 entrada de datos online F 7 facilidad de operación F 8 actualización online F 9 interface compleja F 1 0 procesamiento complejo F 1 1 reusabilidad F 1 2 facilidad de instalación F 1 3 sitios múltiples F 1 4 facilidad de cambio los puntos de función forman una base para la estimación del esfuerzo Albrecht los propone como medida de tamaño independiente de la tecnología presentan varios problemas: subjetividad en FCT, variación del 35 % contar las cosas 2 veces valores no intuitivos: F i = 3 FCT = 1 pero F i = 3 FCT = 1,07 problemas con exactitud: el FCT no mejora significativamente la estimación de recursos

10 Evaluación de los puntos de función de Albrecht COCOMO II problems con PFA (cont) no se puede usar anticipadamente: requiere la especificación completa problemas con cambios de requerimientos: variaciones de 400 % a 2000 % luego de implementación problemas con dominios de aplicación: funciona bien para sistemas de información administrativos, no en sistemas de tiempo real o en aplicaciones científicas problemas de dependencia de tecnología: no es independiente de los métodos de análisis y diseño usados el modelo original de COCOMO desarrollado por Boehm resultó muy exitoso, sin embargo su aplicación no es práctica para entornos modernos de desarrollo de este modo, surge COCOMO II, cuyos objetivos son: desarrollar modelos de costos y de estimación acordes a las prácticas actuales desarrollar bases de datos de costos y herramientas que soporten una mejora continua del modelo proveer un framework analítico cuantitativo, y un conjunto de herramientas y técnicas para evaluar los efectos de las mejoras en los costos de ciclos de vida y en las planificaciones Modelos del COCOMO II Métricas básicas de COCOMO II COCOMO II está compuesto por tres modelos: modelo de la aplicación: basado en puntos objeto modelo de diseño temprano: usado para obtener estimaciones de costo y duración antes de finalizar el diseño de la arquitectura modelo post-arquitectura: el modelo más detallado, con nuevos conductores de costos, y nuevas ecuaciones COCOMO II provee un modelo para estimar costos en base a: KLOC puntos objeto (PO) puntos función (PF )

11 Cálculo de puntos objeto Cálculo de puntos objeto pasos para el cálculo de PO 1 estimar el número de pantallas, reportes y componentes 3GL 2 clasificar la complejidad de los mismos en simple, medio o difícil Vistas fuentes de datos Secciones fuentes de datos de total < 4 total < 8 total > 7 de total < 4 total < 8 total > 7 pantalla (<2 servidor, (2-3 servidor, ( >3 servidor, reporte (<2 servidor, (2-3 servidor, ( >3 servidor, <2 cliente) 3-5 cliente) >5 cliente) <2 cliente) 3-5 cliente) >5 cliente) <3 simple simple medio 0-1 simple simple medio 3-7 simple medio difícil 2-3 simple medio difícil >7 medio difícil difícil >3 medio difícil difícil pasos para el cálculo de PO (cont.) 3 pesar los objetos de acuerdo a su complejidad Objeto simple medio difícil pantalla reporte componente 3GL determinar PO mediante la sumatoria de los pesos de todos los objetos encontrados Cálculo de puntos objeto Cálculo de puntos función pasos para el cálculo de PO (cont.) 5 estimar el porcentaje de reuso que se espera y calcular los nuevos puntos objeto (NPO) NPO ::= PO(100 %reuso)/100 NPO se utiliza a continuación en COCOMO II para estimar el esfuerzo necesario para el desarrollo del proyecto, teniendo en cuenta la productividad del personal y de las herramientas CASE a utilizar pasos para el cálculo de PF : 1 contar inputs externos (IE) outputs externos (OE) consultas externas (CE) archivos internos (AI) archivos de interface externos (AE)

12 Cálculo de puntos función Cálculo de puntos función pasos para el cálculo de PF (cont.): 2 clasificar los objetos de acuerdo a su complejidad en simple, medio, o complejo para AI y AE datos para OE y CE datos registros >50 archivos > 20 1 simple simple medio 0-1 simple simple medio 2-5 simple medio difícil 2-3 simple medio difícil >5 medio difícil difícil >3 medio difícil difícil para IE datos archivos > simple simple medio 2-3 simple medio difícil >3 medio difícil difícil pasos para el cálculo de PF (cont.): 3 aplicar pesos de complejidad según la tabla puntos función complejidad simple medio complejo inputs externos outputs externos consultas externas archivos internos archivos externos calcular los puntos de función no ajustados (PFNA), sumando los puntos de función por su peso de complejidad Cálculo de puntos función pasos para el cálculo de PF (cont.): 5 convertir PFNA en líneas de código estimadas (SLOC) de acuerdo a la siguiente tabla: Lenguaje SLOC por PFNA Lenguaje SLOC por PFNA Ada 71 Java 53 Basic (comp.) 91 Lisp 64 Basic (int.) 128 Modula 2 80 C 128 Pascal 91 C++ 29 Prolog 64 Cobol Generador reportes 80 Fortran Planilla de cálculo 6 los puntos de función de Albrecht miden el problema. Un problema puede tener varias soluciones de distinta complejidad complejidad de la solución complejidad del problema complejidad del problema: cantidad de recursos requeridos para una solución óptima del problema complejidad de la solución: cantidad de recursos necesarios para implementar una solución particular la complejidad de la solución generalmente se mide en dos aspectos: tiempo y espacio

13 en tiempo y en espacio Ejemplo el tiempo mide el tiempo de la computadora necesario para el problema o para la solución particular el espacio mide la memoria de la computadora extra (aparte de los datos de entrada) necesario para el problema o para la solución particular para medir la complejidad de un problema, siempre se tiene en cuenta un algoritmo optimal que lo soluciona problema: encontrar la posición de un elemento en un arreglo ordenado solución 1: búsqueda secuencial, con complejidad en tiempo de n comparaciones y de espacio 1 solución 2: búsqueda binaria, con complejidad en tiempo de log 2 (n) comparaciones y de espacion de 1 se puede demostrar que el problema tiene complejidad en tiempo de log 2 (n) y en espacio de 1. Por lo que búsqueda binaria es optimal en tiempo y espacio, pero búsqueda secuencial es optimal sólo en espacio. siempre se mide el peor caso para todas las instancias de tamaño n, dada la imposibilidad práctica de medir en cada instancia en particular Eficiencia Características de medir eficiencia el medir tiempo de ejecución es una medida de eficiencia externa. Depende de factores externos. idea intuitiva: identificar un pequeño número de operaciones aritméticas primitivas relevantes del algoritmo. Ejemplo: en búsquedas / ordenamiento: comparaciones usando esa información medir en términos del número de operaciones requeridas para un input dado se mide el producto y no el proceso no es dependiente de la máquina o de la implementación es específica de un input con respecto al algoritmo en la mayoría de los problemas los inputs pueden caracterizarse por un solo parámetro de tamaño n ejemplo: algoritmo de búsqueda. Input: lista de elementos e ítem a buscar. La eficiencia del algoritmo depende de la longitud de la lista

14 Notación asintótica Objetivos mide el número de operaciones primitivas requeridas para cualquier algoritmo es f(n). Ejemplo: log 2 (n), n 2, n,... idea: definir una relación empírica: más eficiente no es claro que pares están en la relación. Ejemplo: n 2 >??100 n para precisarlo se usa un formalismo matemático notación O(), el orden de una función no interesa conocer los valores absolutos de las funciones. permitir una caracterización simple de la eficiencia de un algoritmo y comparar las performances relativas de distintos algoritmos. independizar el análisis de los algoritmos de condiciones específicas de implementación: lenguaje de programación, compilador, equipo, etc. Notación O( ) se aplica a funciones de tiempo de ejecución o de espacio de memoria de algoritmos en base a la longitud de la entrada: f(n) : N R +. se denomina asintótica porque analiza el comportamiento de las funciones en el límite, es decir su tasa de crecimiento. O(g(n)) = {f(n) : c R +, n 0 N,tal que f(n) cg(n) para todo n n 0 } determina una cota superior en la tasa de crecimiento de una función, dentro de un factor constante. ejemplos: 6n 3 O(n 3 ) ya que se cumple la definición con c = 6,n 0 = 1. 3logn O(n) ya que se cumple la definición con c = 1,n 0 = 4.

15 Notación Ω( ) Ejemplos: 300n 2 O(n 2 ) 5n 4 4n n O(n 4 ) log b n O(log a n), a,b 2 n O(n!) n O(0,00001n 2 ) 0,000001n 2 O(500000n) n! O(2 n ) Ω(g(n)) = {f(n) : c R +, n 0 N,tal que f(n) cg(n) para todo n n 0 } determina una cota inferior en la tasa de crecimiento de una función, dentro de un factor constante. ejemplos: 6n 3 Ω(n 3 ) ya que se cumple la definición con c = 1,n 0 = 1 1/3n Ω(logn) ya que se cumple la definición con c = 1/3,n 0 = 1. Clasificación de problemas según su complejidad Ejemplos: 3n 5 + 4n 3 8n n Ω(n 4 ) log b n Ω(log a n), a,b n! Ω(2 n ) 0,00001n 2 Ω(50000n) 50000n Ω(0,00001n 2 ) 2 n Ω(n!) de acuerdo al estado de conocimiento de sus algoritmos cerrado abierto de acuerdo a los recursos indispensables para su solución tratables intratables

16 un problema se dice cerrado si se han encontrado algoritmos que lo resuelven y se ha demostrado que esos algoritmos son óptimos en cuanto al O() del tiempo de ejecución BÚSQUEDA en un arreglo ordenado y ORDENAMIENTO de un arreglo son problemas cerrados ÁRBOL DE CUBRIMIENTO MINIMAL para un grafo es un problema abierto, dado que su cota inferior demostrada es de Θ(a), mientras que el mejor algoritmo conocido no es lineal (pero mejor que Θ(a logn)) para cerrar un problema se puede hacer: encontrar un algoritmo asintóticamente mejor que los que se conocen. demostar una cota asintóticamente superior de las que se conocen. de un problema Supongamos que para solucionar todas las instancias de un problema particular un algoritmo requiere f(n) cálculos Decimos que f(n) asintóticamente óptima si para todo algoritmo con complejidad g que soluciona el problema, f es O(g) complejidad de un problema: es el orden del algoritmo asintóticamente óptimo para la solución del problema un problema que tiene una solución acotada polinómicamente se dice tratable o factible en general, los distintos grados de tratabilidad son muy subjetivos (varían mucho de acuerdo al modelo computacional, los recursos disponibles, las variantes de las estructuras de datos, etc.) por lo tanto un objetivo primario del estudio de la complejidad es definir cuáles problemas son tratables, y cuáles no. Recién después de esto se pueden considerar distintos grados de tratabilidad o intratabilidad por ejemplo, se puede afirmar que la mayoría de los problemas vistos en la materia son tratables: o sea tienen solución para instancias grandes, y una mejora algorítmica o una mejora en el HW produce una gran ampliación en el conjunto de instancias que se pueden resolver en cambio, hay problemas que no son tratables: el problema de las torres de Hanoi, o el problema del viajante, en la práctica sólo se resuelven para instancias pequeñas.

17 Estructura del flujo de control la estructura del producto es importante no solo para el desarrollo sino también para el mantenimiento podemos dividir la estructura en: estructura del flujo de control: apunta a la secuencia en las cuales se ejecutan las instrucciones estructura del flujo de datos: sigue el rastro de los items de datos, cómo son creados o manejados por el programa estructura de datos: la organización de los datos en sí misma, independiente del programa las mediciones de flujo de control son usualmente modeladas a partir de grafos dirigidos, llamados grafos de control de flujo (flowgraphs) el grafo está compuesto por: nodos: corresponden a las sentencias del programa arcos: muestran el flujo de control de una sentencia a otra dado un programa A, llamamos interpretación razonable F(A) al grafo de control de flujo de A no siempre es obvio cómo mapear A en F(A) Ejemplo grafo de control de flujo Medidas de un grafo de control de flujo si m es una medida estructural definida en términos del modelo F(A), y si el programa A es estructuralmente mas complejo que B, entonces m(a) >> m(b se trata de introducir un enfoque independiente de cualquier visión de programación estructurada la técnica permite mostrar que cualquier programa tiene una única descomposición estructural definida por componentes primitivas se utilizan conceptos de grafos

18 Métricas CK de objetos y relaciones entre objetos métricas propuestas por Shyam R. Chidamber y Chris F. Kemerer definición de objetos y relaciones entre objetos atributos y propiedades de objetos comunicación entre objetos métricas propuestas por Mark Lorenz y Jeff Kidd de tamaño: número de atributos y métodos de herencia: reuso de los métodos en la jerarquía internas: relacionadas con la cohesión de la clase externas: relacionadas con el acoplamiento entre clases métodos ponderados por clase (WMC weighted methods per class) profundidad del árbol de herencia (DIN depth of inheritance) número de descendientes (NOC number of children) Métodos ponderados por clase (WMC) Profundidad del árbol de herencia (DIN) WMC = c i i, donde ci es una medida de complejidad del método i el número de métodos y su complejidad es un predictor de cuánto tiempo y esfuerzo es necesario para desarrollar y mantener la clase cuanto más métodos mayor impacto en los hijos (herencia) clases con más métodos son mas específicas, limitando el reuso esa longitud máxima desde el nodo hasta la raíz del árbol de herencia cuanto más profunda está una clase en una jerarquía, mayor número de métodos hereda, haciendo más complejo predecir su comportamiento una jerarquía de clases profunda lleva también a una mayor complejidad de diseño ya que involucra más clases por otro lado, los valores grandes de esta medida implican que se pueden reutilizar muchos métodos

19 Número de subclases (NOC) Métricas CK de atributos y propiedades de objetos definida como el número de subclases inmedidatas a medida que crece el número de descendientes se incrementa la reutilización puede darse una mayor posibilidad de una incorrecta abstracción y mayor complejidad de la clase padre un gran número de hijos puede requerir mayor testing de los métodos de la clase un gran número de hijos también es un indicador de la influencia potencial de una clase en el diseño respuesta para una clase (RFC response for a class) falta de cohesión en los métodos (LCO lack of cohesion) Respuesta para una clase (RFC) Falta de cohesión en los métodos (LCO) es el número de métodos que pueden ser invocados en respuesta a un mensaje enviado a un objeto de la clase un valor muy alto indica que la clase es compleja y probablemente altamente acoplada aumenta el esfuerzo de testeo y mantenimiento puede surgir el interrogante de si la clase está modelada correctamente es el número de pares de métodos cuya similitud es cero menos el número de pares de métodos cuya similitud es distinta de cero. Si el valor es negativo, se asume cero similitud: si dos pares de métodos acceden a uno o más de los mismos atributos la cohesión de los métodos dentro de una clase es deseable ya que promueve el encapsulamiento la falta de cohesión implica que una clase debiera dividirse en dos o más clases

20 Métricas CK de comunicación entre objetos Acoplamiento entre objetos de clase(cbo) respuesta para una clase (RFC) acoplamiento entre objetos (CBO coupling between objects) es la cantidad de clases con las cuales está acoplada una clase está acoplada con otra si usa métodos o variables de instancia de la otra un valor alto disminuye el diseño modular y dificulta el reuso el acoplamiento debe mantenerse mínimo para mejorar modularidad y encapsulamiento una medida de acoplamiento es útil para determinar cuanto de complejo será el diseño de testing cuanto más acoplamiento presenta el diseño más riguroso debe ser el testing Algunas métricas LK Tamaño de una clase (CS) tamaño de clase (CS) número de operaciones redefinidas en una clase (NOO) número de operaciones agregadas en una clase (NOA) índice de especialización (SI) es el número total de métodos (heredados + propios) más el número total de atributos (heredados + propios) se puede dar mayor peso a atributos y métodos públicos y heredados un valor bajo indica mayor potencial de reuso

21 Número de operaciones redefinidas en una clase (NOO) Número de operaciones agregadas en una clase (NOA) un NOO elevado es índice de no respeto a la abstracción implícita en la superclase es decir, de una jerarquía frágil involucra mayor dificultad en el testing y mantenimiento al crecer el NOA la clase se aleja de la abstracción representada por la superclase también es índice de una jerarquía frágil, que conlleva dificultades en testing y mantenimiento en general, al crecer el DIN el NOA debería disminuir Índice de especialización (SI) Medidas de atributos internos vs externos la especialización se da agregando, redefiniendo o eliminando métodos de la superclase se define SI = (NOO nivel)/m donde nivel es el nivel de la clase en la jerarquía y M es el número total de métodos en la clase valores elevados de SI indican baja conformidad con la abstracción de la superclase la medición de atributos externos no es tan difundida como la de los internos la principal razón es que los atributos internos se consideran predictores razonables de aquellos externos y además los internos estan disponibles antes para su medición también, no es fácil la medición de atributos externos la medición cuidadosa de atributos externos requiere recursos extra que no todos los administradores de proyectos desean comprometer

22 Medidas basadas en defectos Medidas de usabilidad la densidad de defectos del software se define como la razón entre el número de defectos conocidos y el tamaño del producto pero no existe consenso sobre lo que es un defecto algunos reemplazan el tamaño del código por el tiempo de ejecución, resultando en tasa de defectos otra medida es la de desperdicios del sistema, definida como la razón entre el tiempo (o costo) de reparar defectos post-entrega sobre el tiempo (o costo) total del sistema usabilidad es la medida en que el software es conveniente y práctico para usar (user-friendliness) una posible medida es la probabilidad de que el operador no experimente un problema en la interface del usuario el problema de esta medida es que requiere una recolección de datos intensiva y cuidadosa también se puede medir indirectamente contando manuales, buen uso de menues y gráficos, mensajes de errores informados, invocaciones a funciones de ayuda e interfaces consistentes Medidas de mantenibilidad para cualquier producto, el tiempo medio para una reparación (MTTR) se mide como el promedio que toma a un equipo de mantenimiento reparar el sistema este tiempo puede involucrar factores externos al producto, como tiempos administrativos m se ha estudiado que ciertas combinaciones de factores internos tienen más probabilidad de generar errores

Medición de Atributos Internos. Tamaño. Administración y Gestión de Proyectos de Software. Medición de Atributos Internos. Tamaño

Medición de Atributos Internos. Tamaño. Administración y Gestión de Proyectos de Software. Medición de Atributos Internos. Tamaño Medición de Atributos Internos. Tamaño Administración y Gestión de Proyectos de Software (AGPS6) El tamaño del software puede ser descripto con tres atributos: 1. Longitud: mide tamaño físico del producto.

Más detalles

Métricas para mantener el Presupuesto. Administración y Gestión de Proyectos de Software. Métricas para mantener el Presupuesto

Métricas para mantener el Presupuesto. Administración y Gestión de Proyectos de Software. Métricas para mantener el Presupuesto Métricas para mantener el Presupuesto Administración y Gestión de Proyectos de Software Objetivo: Maximizar la cantidad de funciones entregables por dólar del costo total (todo el tiempo de vida) del sistema.

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP. 2008 TEMA 8 MÉTRICAS DEL SOFTWARE

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP. 2008 TEMA 8 MÉTRICAS DEL SOFTWARE TEMA 8 MÉTRICAS DEL SOFTWARE 1. MÉTRICAS E INDICADORES DE LA CALIDAD 1.1 Medida del tamaño 01 [Feb. 2005] Cuál de las siguientes medidas sirven para cuantificar el tamaño de una aplicación? a) Errores.

Más detalles

Capítulo 12: Indexación y asociación

Capítulo 12: Indexación y asociación Capítulo 12: Indexación y asociación Conceptos básicos Índices ordenados Archivos de índice de árbol B+ Archivos de índice de árbol B Asociación estática Asociación dinámica Comparación entre indexación

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Métricas. Valentin Laime. Calidad de Software

Métricas. Valentin Laime. Calidad de Software Calidad de Software: Métricas Valentin Laime Calidad de Software 10/29/2014 1 Métricas Que miden Beneficios Medidas Productividad Calidad Futuras Estimaciones Directas Indirectas Defecto/fallo Vs. Error

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Diseño orientado al flujo de datos

Diseño orientado al flujo de datos Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

Procesos Críticos en el Desarrollo de Software

Procesos Críticos en el Desarrollo de Software Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine

Más detalles

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INDICE Introducción...2 Frontera de la aplicación...3 Cuenta de Puntos Función sin ajustar...3 Funciones de Datos...4 Funciones Transaccionales...4 Mecanismo...5

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

2. Métricas del Producto

2. Métricas del Producto Medición 52 Programa 1. Medición ió y experimentación ió en Ingeniería del Software Introducción Teoría representacional de la medición. Experimentación en Ingeniería del software. 2. Medidas del Producto

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR

Más detalles

CAPITULO 4 JUSTIFICACION DEL ESTUDIO. En este capítulo se presenta la justificación del estudio, supuestos y limitaciones de

CAPITULO 4 JUSTIFICACION DEL ESTUDIO. En este capítulo se presenta la justificación del estudio, supuestos y limitaciones de CAPITULO 4 JUSTIFICACION DEL ESTUDIO En este capítulo se presenta la justificación del estudio, supuestos y limitaciones de estudios previos y los alcances que justifican el presente estudio. 4.1. Justificación.

Más detalles

Programación Genética

Programación Genética Programación Genética Programación Genética consiste en la evolución automática de programas usando ideas basadas en la selección natural (Darwin). No sólo se ha utilizado para generar programas, sino

Más detalles

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: CICLO DE VIDA DE DESARROLLO DE SI FASES GENÉRICAS DEL CICLO DE VIDA DE DESARROLLO DE SI VISIÓN TRADICIONAL DEL CICLO DE VIDA DE DESARROLLO DE SI DE DESARROLLO DE SI: ANÁLISIS Material diseñado

Más detalles

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

Ciclo de vida del software

Ciclo de vida del software Ciclo de vida del software Definición El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Confiable,

Más detalles

Ingeniería de Software Avanzada

Ingeniería de Software Avanzada Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Avanzada Dr. Marcello Visconti Z. Origen : Allan Albrecht, IBM Suma ponderada de parámetros básicos para dimensionar

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

DISEÑO DE FUNCIONES (TRATAMIENTOS)

DISEÑO DE FUNCIONES (TRATAMIENTOS) DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se

Más detalles

Análisis y cuantificación del Riesgo

Análisis y cuantificación del Riesgo Análisis y cuantificación del Riesgo 1 Qué es el análisis del Riesgo? 2. Métodos M de Análisis de riesgos 3. Método M de Montecarlo 4. Modelo de Análisis de Riesgos 5. Qué pasos de deben seguir para el

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

WBS:Work Breakdown Structure. WBS - Work Breakdown Structure. WBS - Work Breakdown Structure. WBS:Work Breakdown Structure...

WBS:Work Breakdown Structure. WBS - Work Breakdown Structure. WBS - Work Breakdown Structure. WBS:Work Breakdown Structure... WBS - Work Breakdown Structure WBS:Work Breakdown Structure WBS: es una descripción jerárquica del trabajo que se debe realizar para completar el proyecto. El trabajo se divide en actividades. Las actividades

Más detalles

Figura 4.1 Clasificación de los lenguajes de bases de datos

Figura 4.1 Clasificación de los lenguajes de bases de datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Este capítulo describen los distintos lenguajes para bases de datos, la forma en que se puede escribir un lenguaje

Más detalles

H E R R A M I E N T A S D E A N Á L I S I S D E D A T O S HERRAMIENTAS DE ANÁLISIS DE DATOS

H E R R A M I E N T A S D E A N Á L I S I S D E D A T O S HERRAMIENTAS DE ANÁLISIS DE DATOS H E R R A M I E N T A S D E A N Á L I S I S D E D A T O S HERRAMIENTAS DE ANÁLISIS DE DATOS Una situación que se nos plantea algunas veces es la de resolver un problema hacia atrás, esto es, encontrar

Más detalles

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

Más detalles

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) Introducción 1. Como se indica en la Norma Internacional de Auditoría 401, "Auditoría en un contexto informatizado", los objetivos globales

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Introducción. Por lo que existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad.

Introducción. Por lo que existe una creciente preocupación por lograr que los productos software cumplan con ciertos criterios de calidad. Introducción En la actualidad, el software se encuentra en muchos campos de la actividad humana: la industria, el comercio, las finanzas, gobierno, salud, educación, etc. Por lo que existe una creciente

Más detalles

PROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0

PROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0 Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. PROYECTO

Más detalles

Introducción: Modelos, Escalas y Métricas. Valentin Laime. Calidad de Software

Introducción: Modelos, Escalas y Métricas. Valentin Laime. Calidad de Software Calidad de Software: Introducción: Modelos, Escalas y Métricas Valentin Laime Calidad de Software 10/28/2014 1 Modelos Un modelo es una abstracción de la realidad, que permite abstraer detalles y visualizar

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

2.1 Clasificación de los sistemas de Producción.

2.1 Clasificación de los sistemas de Producción. ADMINISTRACION DE OPERACIONES Sesión 2: La Administración de operaciones II Objetivo específico 1: El alumno conocerá la clasificación de los sistemas de producción, los sistemas avanzados de manufactura

Más detalles

PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES

PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES Raúl Palma G. y Guillermo Bustos R. Escuela de Ingeniería Industrial Universidad Católica de Valparaíso Casilla

Más detalles

Salud de Activos Reflejo de la Estrategia de Mantenimiento

Salud de Activos Reflejo de la Estrategia de Mantenimiento Salud de Activos Reflejo de la Estrategia de Mantenimiento Mucho se ha dicho y escrito acerca de como medir la efectividad de una estrategia de mantenimiento, sin embargo, al momento solo porciones de

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

TEMA 3 PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ 2 3. PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

TEMA 3 PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ 2 3. PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS 1 1 BASES DE DATOS DISTRIBUIDAS TEMA 3 PROFESOR: M.C. ALEJANDRO GUTIÉRREZ DÍAZ 2 3. PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS 3.1 Metodología del procesamiento de consultas distribuidas 3.2 Estrategias de

Más detalles

Calidad. Preparado por: Amelia Soriano. Referencias. Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation

Calidad. Preparado por: Amelia Soriano. Referencias. Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Calidad Preparado por: Amelia Soriano Referencias Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Curso Rational Unified Process Rational University Curso

Más detalles

DE VIDA PARA EL DESARROLLO DE SISTEMAS

DE VIDA PARA EL DESARROLLO DE SISTEMAS MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Estimación de Tamaño de Software: Puntos Funcionales. Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes

Estimación de Tamaño de Software: Puntos Funcionales. Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Estimación de Tamaño de Software: Puntos Funcionales Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Puntos de Función Métrica para cuantificar la funcionalidad de un

Más detalles

MÉTRICAS DE SOFTWARE. Presentado por: Jhon Alexander Guamanga Cyntia Mileidy Herrera Andrés Felipe Orejuela

MÉTRICAS DE SOFTWARE. Presentado por: Jhon Alexander Guamanga Cyntia Mileidy Herrera Andrés Felipe Orejuela MÉTRICAS DE SOFTWARE Presentado por: Jhon Alexander Guamanga Cyntia Mileidy Herrera Andrés Felipe Orejuela Qué son las métricas de software? El concepto de métrica es el término que describe muchos y muy

Más detalles

A partir de este capítulo se introducen términos, probablemente nuevos para el

A partir de este capítulo se introducen términos, probablemente nuevos para el CAPITULO 3. PSP 0 Y PSP 0.1 A partir de este capítulo se introducen términos, probablemente nuevos para el lector que tienen que ver en su totalidad con PSP. También se dan a conocer los formatos, "scripts

Más detalles

Tema 3 Metodologías de Desarrollo de Software

Tema 3 Metodologías de Desarrollo de Software Ingeniería del Software Ingeniería del Software de Gestión Tema 3 Metodologías de Desarrollo de Software Félix Óscar García Rubio Crescencio Bravo Santos Índice 1. Definiciones 2. Objetivos 3. Conceptos

Más detalles

1.1.- Objetivos de los sistemas de bases de datos 1.2.- Administración de los datos y administración de bases de datos 1.3.- Niveles de Arquitectura

1.1.- Objetivos de los sistemas de bases de datos 1.2.- Administración de los datos y administración de bases de datos 1.3.- Niveles de Arquitectura 1. Conceptos Generales 2. Modelo Entidad / Relación 3. Modelo Relacional 4. Integridad de datos relacional 5. Diseño de bases de datos relacionales 6. Lenguaje de consulta estructurado (SQL) 1.1.- Objetivos

Más detalles

Determinación del nivel de influencia

Determinación del nivel de influencia Determinación del nivel de influencia Aquí se describirán cada una de las características mencionadas y cómo analizar su grado de influencia en la determinación del factor de ajuste. - Comunicación de

Más detalles

Introducción a la Programación 11 O. Humberto Cervantes Maceda

Introducción a la Programación 11 O. Humberto Cervantes Maceda Introducción a la Programación 11 O Humberto Cervantes Maceda Información del profesor Humberto Cervantes Maceda T 138 www.humbertocervantes.net/cursos Acerca de ustedes Nombre Carrera Qué experiencia

Más detalles

PREPARADO POR: FECHA DE EMISIÓN: 20-05-05 FECHA DE VALIDACIÓN: 20-05-05

PREPARADO POR: FECHA DE EMISIÓN: 20-05-05 FECHA DE VALIDACIÓN: 20-05-05 3. MONITORÍA Y EVALUACIÓN DE LA GESTIÓN SS-UPEG-3 PREPARADO POR: EQUIPO CONSULTOR FECHA DE EMISIÓN: 20-05-05 FECHA DE VALIDACIÓN: 20-05-05 VERSIÓN Nº: 1 Secretaría de Salud de Honduras - 2005 PÁGINA 2

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

SIIGO PYME PLUS. Proceso de Recuperación. Cartilla I

SIIGO PYME PLUS. Proceso de Recuperación. Cartilla I SIIGO PYME PLUS Proceso de Recuperación Cartilla I Tabla de Contenido 1. Presentación 2. Qué es el Proceso de Recuperación? 3. Cuál es el Objetivo del Proceso de Recuperación? 4. Cuáles son los Pasos que

Más detalles

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6 2. MÉTODO, METODOLOGÍA Y MÉTRICA 2.1 MÉTODO Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

punto, es que los criterios de evaluación de las medidas antes citadas se ajustan a las medidas señaladas para la toma del indicador VTD.

punto, es que los criterios de evaluación de las medidas antes citadas se ajustan a las medidas señaladas para la toma del indicador VTD. CONSULTA Para esta Comisión es muy importante conocer los comentarios sectoriales relacionados con el contenido del entregable presentado por la firma Iteco en el marco del Contrato 038 de 2014, para avanzar

Más detalles

CMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM

CMM - Capability Maturity Model. Estructura de CMM... Componentes de CMM. Estructura de CMM CMM - Capability Maturity Model Estructura de CMM... Es un marco que describe los elementos claves de un proceso de software efectivo. Describe un camino de mejora evolutivo desde un proceso ad hoc inmaduro

Más detalles

Preliminares. Tipos de variables y Expresiones

Preliminares. Tipos de variables y Expresiones Preliminares. Tipos de variables y Expresiones Felipe Osorio Instituto de Estadística Pontificia Universidad Católica de Valparaíso Marzo 5, 2015 1 / 20 Preliminares Computadoras desarrollan tareas a un

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos. Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas

Más detalles

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de

Más detalles

Maxpho Commerce 11. Gestión CSV. Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd

Maxpho Commerce 11. Gestión CSV. Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd Maxpho Commerce 11 Gestión CSV Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd Índice general 1 - Introducción... 3 1.1 - El archivo CSV... 3 1.2 - Módulo CSV en Maxpho... 3 1.3 - Módulo CSV

Más detalles

Patrones para persistencia (I) Ingeniería del Software II

Patrones para persistencia (I) Ingeniería del Software II Patrones para persistencia (I) Ingeniería del Software II 1 Patrones para la construcción del esquema relacional En todos los ejemplos realizaremos transformaciones del siguiente diagrama de clases: Figura

Más detalles

"Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios

Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios "Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios Miguel Alfonso Flores Sánchez 1, Fernando Sandoya Sanchez 2 Resumen En el presente artículo se

Más detalles

Workflows? Sí, cuántos quiere?

Workflows? Sí, cuántos quiere? Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

Gestión de calidad en el software. Calidad en el Desarrollo de Software. Spoilage. Spoilage

Gestión de calidad en el software. Calidad en el Desarrollo de Software. Spoilage. Spoilage Gestión de calidad en el software Calidad de software Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Segundo Cuatrimestre 2007 primer problema: los errores se aceptan. Esto

Más detalles

Calidad Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007

Calidad Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007 Calidad Calidad Definición de diccionario: Conjunto de Cualidades que constituyen la manera de ser de una persona o cosa. En términos generales podemos definir la calidad como conjunto de características

Más detalles

Complejidad - Problemas NP-Completos. Algoritmos y Estructuras de Datos III

Complejidad - Problemas NP-Completos. Algoritmos y Estructuras de Datos III Complejidad - Problemas NP-Completos Algoritmos y Estructuras de Datos III Teoría de Complejidad Un algoritmo eficiente es un algoritmo de complejidad polinomial. Un problema está bien resuelto si se conocen

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

CAPITULO III MARCO METODOLÓGICO. Desde la perspectiva de Hurtado de Barrera (2008), el tipo de

CAPITULO III MARCO METODOLÓGICO. Desde la perspectiva de Hurtado de Barrera (2008), el tipo de CAPITULO III MARCO METODOLÓGICO 1. TIPO DE INVESTIGACIÓN Desde la perspectiva de Hurtado de Barrera (2008), el tipo de investigación que propone soluciones a una situación determinada a partir de un proceso

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

Más detalles

GENERACIÓN DE ANTICIPOS DE CRÉDITO

GENERACIÓN DE ANTICIPOS DE CRÉDITO GENERACIÓN DE ANTICIPOS DE CRÉDITO 1 INFORMACIÓN BÁSICA La aplicación de generación de ficheros de anticipos de crédito permite generar fácilmente órdenes para que la Caja anticipe el cobro de créditos

Más detalles

UNIDAD EJECUTORA DE CONSERVACION VIAL MANUAL DEL USUARIO DEL SISTEMA INTEGRAL DE CONTROL DE PROYECTOS

UNIDAD EJECUTORA DE CONSERVACION VIAL MANUAL DEL USUARIO DEL SISTEMA INTEGRAL DE CONTROL DE PROYECTOS UNIDAD EJECUTORA DE CONSERVACION VIAL MANUAL DEL USUARIO DEL SISTEMA INTEGRAL DE CONTROL DE PROYECTOS Guatemala, Julio de 2008 Índice Gestión de equipos...4 Programación física...5 Trabajos por Administración...6

Más detalles

TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos

TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos 1. La base de datos se puede considerar como una unificación de varios archivos de datos independientes, cuyo propósito básico es evitar la

Más detalles

7. Conclusiones. 7.1 Resultados

7. Conclusiones. 7.1 Resultados 7. Conclusiones Una de las preguntas iniciales de este proyecto fue : Cuál es la importancia de resolver problemas NP-Completos?. Puede concluirse que el PAV como problema NP- Completo permite comprobar

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Novedades en Q-flow 3.02

Novedades en Q-flow 3.02 Novedades en Q-flow 3.02 Introducción Uno de los objetivos principales de Q-flow 3.02 es adecuarse a las necesidades de grandes organizaciones. Por eso Q-flow 3.02 tiene una versión Enterprise que incluye

Más detalles

Arquitectura de sistema de alta disponibilidad

Arquitectura de sistema de alta disponibilidad Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los

Más detalles

Área Académica: Licenciatura Sistemas Computacionales. Profesor: Lic. Virginia Arguelles Pascual

Área Académica: Licenciatura Sistemas Computacionales. Profesor: Lic. Virginia Arguelles Pascual Área Académica: Licenciatura Sistemas Computacionales Materia: Gestión de Proyectos Profesor: Lic. Virginia Arguelles Pascual Periodo: Julio-Diciembre Tema: El proceso de software y métricas del proyecto.

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

2 EL DOCUMENTO DE ESPECIFICACIONES

2 EL DOCUMENTO DE ESPECIFICACIONES Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir

Más detalles

Tema 2 Conceptos básicos de programación. Fundamentos de Informática

Tema 2 Conceptos básicos de programación. Fundamentos de Informática Tema 2 Conceptos básicos de programación Fundamentos de Informática Índice Metodología de la programación Programación estructurada 2 Pasos a seguir para el desarrollo de un programa (fases): Análisis

Más detalles

Tecnología de la Información. Administración de Recursos Informáticos

Tecnología de la Información. Administración de Recursos Informáticos Tecnología de la Información Administración de Recursos Informáticos 1. Recursos informáticos: Roles y Responsabilidades 2. Áreas dentro del Departamento de Sistemas 3. Conceptos asociados a proyectos

Más detalles

forma de entrenar a la nuerona en su aprendizaje.

forma de entrenar a la nuerona en su aprendizaje. Sistemas expertos e Inteligencia Artificial,Guía5 1 Facultad : Ingeniería Escuela : Computación Asignatura: Sistemas expertos e Inteligencia Artificial Tema: SISTEMAS BASADOS EN CONOCIMIENTO. Objetivo

Más detalles

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

Más detalles

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones Univ. Cantabria Fac. de Ciencias Patricia López Modelo de Casos de Uso vs Modelo de Análisis Modelo de Casos de Uso Modelo de Análisis Descrito con el

Más detalles

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

Métricas, Estimación y Planificación en Proyectos de Software Métricas, Estimación y Planificación en Proyectos de Software Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software

Más detalles

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

Más detalles

Manejo de versiones 392

Manejo de versiones 392 Manejo de versiones 392 El desarrollo de software es un trabajo en equipo y cierto grado de confusión es inevitable. No puedo reproducir el error en esta versión! Qué pasó con el arreglo de la semana pasada?

Más detalles

Copyright 2011 - bizagi. Gestión de Cambios Documento de Construcción Bizagi Process Modeler

Copyright 2011 - bizagi. Gestión de Cambios Documento de Construcción Bizagi Process Modeler Copyright 2011 - bizagi Gestión de Cambios Bizagi Process Modeler Tabla de Contenido Gestión de Cambios... 4 Descripción... 4 Principales factores en la Construcción del Proceso... 5 Modelo de Datos...

Más detalles