Métricas del software. Calidad en el Desarrollo de Software. Métricas para el presupuesto. Métricas del software - resumen. Métricas del software
|
|
- Ramón Serrano Peña
- hace 8 años
- Vistas:
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 (AGPS6) El tamaño del software puede ser descripto con tres atributos: 1. Longitud: mide tamaño físico del producto.
Más detallesMé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 detallesPROGRAMACIÓ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 detallesCALIDAD 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 detallesCapí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 detallesPRUEBAS 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 detallesMé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 detallesUNIDAD 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 detallesElementos 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 detallesDiseñ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 detallesFundamentos 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 detallesIntroducció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 detallesEstá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 detallesProcesos 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 detallesINSTRUCTIVO 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 detallesCiclo 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 detalles2. 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 detalles3.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 detallesSISTEMAS 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 detallesCAPITULO 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 detallesProgramació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 detallesSISTEMAS 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 detallesUNIVERSIDAD 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 detallesCiclo 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 detallesIngenierí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 detallesProceso 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 detallesDISEÑ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 detallesAná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 detallesEntidad 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 detallesWBS: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 detallesFigura 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 detallesH 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 detallesEstas 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 detallesIAP 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 detalles4. 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 detallesDISEÑ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 detallesIntroducció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 detallesPROCEDIMIENTO 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 detallesIntroducció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 detallesArquitectura 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 detalles2.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 detallesPRODUCTIVIDAD 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 detallesSalud 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 detallesCapitulo 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 detallesTEMA 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 detallesCalidad. 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 detallesDE 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 detallesPROGRAMACIÓ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 detallesEstimació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 detallesMÉ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 detallesA 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 detallesTema 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 detalles1.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 detallesDeterminació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 detallesIntroducció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 detallesPREPARADO 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 detallesCMMI (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 detallesSIIGO 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 detallesApp 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 detallesEn 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 detallesDIAGRAMA 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 detallespunto, 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 detallesCMM - 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 detallesPreliminares. 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 detallesCapí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 detallesActividades 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 detallesTé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 detallesMaxpho 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 detallesPatrones 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 Miguel Alfonso Flores Sánchez 1, Fernando Sandoya Sanchez 2 Resumen En el presente artículo se
Más detallesWorkflows? 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 detallesM 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 detallesGestió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 detallesCalidad 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 detallesComplejidad - 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 detalles6 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 detallesCAPITULO 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 detallesIngenierí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 detallesWorkflow, 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 detallesGENERACIÓ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 detallesUNIDAD 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 detallesTALLER 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 detalles7. 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 detallesPlan 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 detallesNovedades 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 detallesArquitectura 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 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 detallesDiseñ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 detallesANÁ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 detalles2 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 detallesTema 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 detallesTecnologí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 detallesforma 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 detallesIngenierí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 detallesINGENIERÍ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 detallesMé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 detallesSSTQB. 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 detallesManejo 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 detallesCopyright 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