Medir Complejidad Estructura • Supongamos que para solucionar todas las instancias de un problema particular un algoritmo requiere f (n) cálculos. • La estructura del producto es importante no solo para el desarrollo sino también para el mantenimiento. • Decimos que f (n) es asintóticamente óptima si para todo algoritmo con complejidad g que soluciona el problema, f es O(g). • Dividimos la estructura en: • 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 factible. Administración y Gestión de Proyectos de Software, UNS 239 Medir Complejidad... Administración y Gestión de Proyectos de Software, UNS 241 Estructura del Flujo de Control • P: la clase de todos los problemas factibles. • NP: la clase de programas cuya factibilidad es desconocida. Parecieran no admitir solución, pero hay métodos (algoritmos acotados polinómicamente) para chequear una solución. • Las mediciones de flujo de control son usualmente modeladas a partir de grafos dirigidos, llamados grafos de control de flujo flowgraphs. • Nodo: Secuencia de programa. programa. Enumeran las sentencias del • Arco: Flujo de control de una sentencia a otra. Muestran el patrón de control. • NP-completo: subconjunto de programas mas complejos. • La jerarquı́a de clases de complejidad está dada por P, NP y NP-completo. Administración y Gestión de Proyectos de Software, UNS 1. Estructura del Flujo de Control: apunta a la secuencia en las cuales se ejecutan las instrucciones. 2. Estructura del Flujo de Datos: sigue el rastro de los items de datos como son creados o manejados por el programa. 3. Estructura de Datos: la organización de los datos en sı́ misma, independiente del programa. 240 • Dado un programa A, llamamos interpretación razonable F (A) al grafo de control de flujo de A. No siempre es posible mapear A en F (A). Administración y Gestión de Proyectos de Software, UNS 242 Estructura del Flujo de Control: Ejemplo Grafo de Flujo de Control • Grafo: conjunto de puntos (o nodos) y segmentos. Ver figura 8-1. • Grafo Dirigido: cada segmento tiene asignada una dirección indicada por una flecha, llamada arco. Conjunto de nodos y arcos. Cada arco conecta un par de nodos. • Arco: par ordenado < x, y > donde x e y son los nodos de los extremos. La dirección del arco es de x a y. • Grado-in: número de arcos que llegan a un nodo. • Grado-out: número de arcos que dejan un nodo. Administración y Gestión de Proyectos de Software, UNS 243 Administración y Gestión de Proyectos de Software, UNS Estructura del Flujo de Control... Grafo de Flujo de Control • Idea: 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 =⇒ 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. Administración y Gestión de Proyectos de Software, UNS 245 244 • Camino: secuencia de arcos consecutivos. Puede haber duplicados en la secuencia. • Camino Simple: camino sin arcos repetidos. • Ejemplo: 1. Nodo 50 Grado-in: 1 2. Nodo 50 Grado-out: 2 3. Camino: < 30, 40 >, < 40, 50 >, < 50, 60 >, < 60, 40 >, < 40, 50 >, < 50, 80 > No es camino simple, ya que repite < 40, 50 > Administración y Gestión de Proyectos de Software, UNS 246 Grafo de Flujo de Control Grafo de Flujo de Control... • Grafo de Flujo: es un grafo dirigido en los cuales dos nodos, el nodo inicial y el nodo final tienen propiedades especiales. El nodo final tiene grado-out = 0 y cada nodo del grafo está en alún camino desde el nodo inicial al nodo final. • El nodo inicial y el nodo final se distinguen con • • Grafo de flujo Parametrizado: cuando se asocia con el código actual que representa. Ejemplo: D2(A, X) significa D2 con parámetros A y X. Notación para la estructura while A do X. Si se habla solo de D2 significa la estructura de control genérica while-do. • El grafo de flujo es un ejemplo de máquina de estados finitos. • La mayorı́a de los programas imperativos utilizan construcciones de control prediseñadas. Pero esto no siempre es la realidad. • Nodos de Procedimiento: nodos con grado-out = 1. • Ejemplo: • Nodos de Predicado: nodos con grado-out > 1. Administración y Gestión de Proyectos de Software, UNS 247 Grafo de Flujo de Control: Ejemplos Administración y Gestión de Proyectos de Software, UNS 249 Secuencia y Anidamiento Ver figura 8.2 • Hay dos operaciones básicas que se pueden utilizar para construir un grafo de flujo: secuencia y anidamiento • Sean F1 y F2 grafos de flujos. La secuencia F1 y F2 es el grafo formado por intercalar el nodo final de F1 con el nodo inicial de F2. El grafo resultante es F1; F2 o seq(F1, F2) o P2(F1, F2) • Ejemplo: Figura 8.4 Administración y Gestión de Proyectos de Software, UNS 248 Administración y Gestión de Proyectos de Software, UNS 250 Secuencia y Anidamiento... Secuencia y Anidamiento... • La operación de secuencia de grafos de flujo corresponde a la operación de secuencia (concatenación) de los LP imperativos. • Supongamos que A y A son dos bloques de código de programa: F (A; A) = F (A); F (A) • Sea A un programa en el cual el procedimiento A es llamado por un parámetro X. F (A con A sustituido por X) = F (A)(F (A) en X) • El grafo del programa secuencia es igual a la secuencia de grafos. • El grafo de flujo de la sustitución es igual al anidamiento de grafos de flujos. • Sean F1 y F2 grafos de flujos. Supongamos que F1 tiene un nodo de procedimiento X. Anidar F2 en F1 en X es el grafo formado por F1 reemplazando el arco que sale de X con todo F2. El grafo de flujo resultante es F 1(F 2 en X). Si no hay ambiguedad F 1(F 2) • En general, sean F1, F2, . . . , Fn grafos de flujos con n nodos de procedimientos especı́ficos X1, X2, · · · , Xn. El grafo resultante es F (F 1 en X1, F2 en X2, · · · , Fn en Xn) Si los nodos no son relevantes F (F1, F2, · · · , Fn) Administración y Gestión de Proyectos de Software, UNS 251 Secuencia y Anidamiento... Administración y Gestión de Proyectos de Software, UNS 253 Secuencia y Anidamiento: Ejemplo 8.6 • La operación de anidamiento de grafos de flujos corresponde a la operación de sustitución de procedimientos en LP imperativos. • Ejemplo: Figura 8.5 Administración y Gestión de Proyectos de Software, UNS 252 Administración y Gestión de Proyectos de Software, UNS 254 Nociones de Estructurado Nociones de Estructurado... • Grafo de Flujo Primo: grafos de flujos que no pueden ser descompuestos de manera no trivial en secuencias y anidamientos • Bohm y Jacopini: Cualquier algoritmo puede ser implementado usando las construcciones de secuencia, selección y anidamiento. • Objetivo: Considerando solo el grafo de flujo determinar si un algoritmo es estructurado o no. • Los elementos de S son S − graf os. Se llaman S − graf os básicos • Se puede elegir que bloques constituyen los S − graf os. Ejemplo: 1. Para S = {P1}, S − graf os = {P1, P2, · · · , Pn, · · ·} 2. S d = {P1, D0, D2} son los grafos D − estructurados 3. Para S = {D1, D2}, los siguiente son S − graf os: Fig.8.7 • Se introduce el concepto de familia S de grafos de flujo primos. Administración y Gestión de Proyectos de Software, UNS 255 Administración y Gestión de Proyectos de Software, UNS Nociones de Estructurado... 257 Descomposición Prima • Se dice que una familia de grafos es S − estructurada (o que los miembros de la familia son S − graf os) si satisface las siguientes reglas recursivas: • Se puede asociar con cualquier grafo de flujo un árbol de descomposición. 1. Cada miembro de S es S − estructurado 2. Si S y S son S − graf os =⇒ F ; F es S − graf o F (F ) es S − graf o (siempre que esté definido el anidamiento de F en F 3. Ningún otro grafo es un S − graf o a menos que se pueda mostrar que es generado en un número finito de veces por la aplicación de los puntos anteriores. • El árbol es construı́do a partir de secuencias y anidamiento de grafos primos. Administración y Gestión de Proyectos de Software, UNS 256 • Ejemplo: Administración y Gestión de Proyectos de Software, UNS 258 Ejemplo de Descomposición Descomposición Prima • Teorema de Descomposición Prima: Todo grafo tiene una única descomposición en una jerarquı́a de grafos primos. • Existen herramientas que lo hacen automáticamente. • El teorema provee una forma simple para determinar si un grafo es S − estructurado para una familia de primos S. • Procedimiento: 1. Se calcula el árbol. 2. Si todo nodo es un elemento de S o es un Pn =⇒ el grafo es un S − graf o. Administración y Gestión de Proyectos de Software, UNS 259 Ejemplo de Descomposición Administración y Gestión de Proyectos de Software, UNS 261 Medidas Jerárquicas • La descomposición prima definida de manera única es una descomposición definitiva de la estructura de control de un programa. • Medir formalmente la profundidad de anidamiento de un programa: Sea F el grafo de un programa. α la profundidad de anidamiento de F . Podemos expresar α en términos de primos, secuencias y anidamientos: 1. Primos: α(P1) = 0 y ∀ F primo = P1 α(F ) = 1 2. Secuencia: la profundidad de anidamiento de la secuencia F1, F2, · · · , Fn es la máxima profundidad de anidamiento de los Fi α(F1; F2; · · · ; Fn) = max(α(F1), · · · , α(Fn)) Administración y Gestión de Proyectos de Software, UNS 260 Administración y Gestión de Proyectos de Software, UNS 262 Medidas Jerárquicas... Medir Longitud 3. Anidamiento: la profundidad de anidamiento de F (F1 · · · Fn) es la máxima profundidad de anidamiento de los Fi + 1 α(F (F1, · · · , Fn) = 1 + max(α(F1), · · · , α(Fn)) • Ejemplo: α(F ) = α(D1((D0; P 1; D2), D0(D3))) α(F ) = 1 + max(α(D0; P1; D2), α(D0(D3))) α(F ) = 1 + max(max(α(D0 ), α(P1), α(D2)), 1 + α(D3)) α(F ) = 1 + max(max(1, 0, 1), 2) α(F ) = 1 + max(1, 2) α(F ) = 3 Administración y Gestión de Proyectos de Software, UNS • Deseamos medir formalmente la longitud v que indique el número de sentencias en un programa, cuando este se modela como un grafo. 1. M1: v(P1) = 1 Si F = P1 → v(F ) = n + 1 donde n es el número de nodos de procedimientos en F 2. M2: v(F1; · · · ; Fn) = Σv(Fi ) 3. M3: v(F (F1, · · · , Fn)) = 1 + Σv(Fi ) para cada primo F = P1 • v(D0) = 1 + 1 = 2 v(D1) = 2 + 1 = 3 v(D2) = 1 + 1 = 2 v(D3) = 1 + 1 = 2 263 Medidas Jerárquicas... Administración y Gestión de Proyectos de Software, UNS 265 Ejemplo de Medir Longitud • Sea S un conjunto arbitrario de primos. Decimos que m es una medida jerárquica si puede definirse en el conjunto de S − graf os especificando: 1. Regla M1: m(F ) ∀F ∈ S 2. Regla M2: la(s) función(es) de secuencia 3. Regla M3: las funciones de anidamiento hf ∀F ∈ S v(F ) = v(D1(D0; P1; D2), D0(D3))) v(F ) = 1 + v(D0; P1; D2) + v(D0(D3))) v(F ) = 1 + (v(D0) + v(P1) + v(D2)) + (1 + v(D3)) v(F ) = 1 + (2 + 1 + 2) + (1 + 2) v(F ) = 1 + 5 + 3 v(F ) = 9 • Se puede calcular la medida jerárquica de un programa una vez que conocemos las reglas M1, M2, M3 y el árbol de descomposición. Administración y Gestión de Proyectos de Software, UNS 264 Administración y Gestión de Proyectos de Software, UNS 266 Medida de Complejidad Ciclomática de Mc Cabe Medida de Complejidad Ciclomática de Mc Cabe... • Para un programa con grafo F , el número ciclomático es: v(F ) = a − n + 2 donde F tiene a arcos y n nodos. • La complejidad de las componentes anidadas en un primo F es la complejidad del primo F mas la suma de las complejidades de las componentes menos el número de componentes. • El número ciclomático mide el número de caminos linealmente independientes de F . • Desde la teorı́a de las mediciones, es dudoso que cualquiera de estas afirmaciones corresponda a relaciones intuitivas sobre complejidad. • Para cualquier grafo F , v(F ) = 1 + d, donde d es el número de nodos predicados de F . • Por eso, v no puede ser usada como una medida general de complejidad. • La medida es objetiva y útil para medir los caminos linealmente independientes, pero no es claro que refleje de manera completa y exacta la complejidad de un programa. • El número ciclomático es un indicador útil de la dificultad para probar y mantener un programa o módulo. Si v > 10 = problemático. Administración y Gestión de Proyectos de Software, UNS 267 Medida de Complejidad Ciclomática de Mc Cabe... Administración y Gestión de Proyectos de Software, UNS 269 Medida de Complejidad Esencial de Mc Cabe... • v puede ser definida como una medida jerárquica: 1. M1: v(F ) = 1 + d para cada primo F donde d:cantidad de nodos predicados de F . 2. M2: v(F1; · · · ; Fn) = Σv(Fi ) − n + 1 3. M3: v(F (F1, · · · , Fn)) = v(F ) + Σv(Fi ) − n para cada primo F • Mc Cabe tambien propone una medida para capturar el nivel general de estructuración de un programa. • Para un programa con grafo F , define: complejidad esencial: ev(F ) = v(F ) − m donde m es el número de subgrafos de F que ∈ {D0, D1, D2, D3} • La complejidad de los primos depende sólo del número de nodos predicado que tengan. • La complejidad de la secuencia es igual a la suma de las complejidades de las componentes menos el número de componentes mas uno. Administración y Gestión de Proyectos de Software, UNS 268 Administración y Gestión de Proyectos de Software, UNS 270 Ej.: Medida de Complejidad Esencial de Mc Cabe Medidas de Cubrimiento de Tests • La estructura de un módulo está relacionada con la dificultad para testearlo. • Sea P un programa, S la especificación de P , e i un input a P . Definimos: Caso de test: (i, S(i)). El interés es chequear que P (i) = S(i) • Las estrategias para testear software pueden ser: 1. Pruebas de caja negra: los casos de test se derivan de la especificación sin referencias al código. 2. Pruebas de caja blanca: los casos de test se seleccionan basados en el conocimiento de la estructura interna del programa. Administración y Gestión de Proyectos de Software, UNS 271 Medida de Complejidad Esencial de Mc Cabe... Administración y Gestión de Proyectos de Software, UNS 273 Medidas de Cubrimiento de Tests... • Mc Cabe afirma que la complejidad esencial indica el grado hasta el cual el grafo puede ser “reducido” descomponiéndolo en todos los subgrafos que son D − primos. • En estrategias de caja blanca, los casos de test se seleccionan de tal manera que toda sentencia de programa se ejecute al menos una vez (cobertura de sentencias). • La complejidad esencial mide el número ciclomático de lo que queda luego de descomponer todos los subgrafos estructurados. • En términos de grafos de programas la cobertura de sentencias se logra encontrando un conjunto de caminos de tal forma que todo nodo esté en al menos un camino. • Una idea más intuitiva de la complejidad esencial puede ser el número ciclomático del primo más grande en el árbol de descomposición. Administración y Gestión de Proyectos de Software, UNS 272 Administración y Gestión de Proyectos de Software, UNS 274 Ejemplo: Medidas de Cubrimiento de Tests Medidas de Cubrimiento de Tests... • Ninguna estrategia de caja blanca puede asegurar por sı́ misma un adecuado testeo del software. Ejemplo: La ejecución del camino ABDEFG para ”9” fue correcta. Qué pasa con el input 11? Ejecuta el mismo camino y el resultado es erróneo. • El conocer todos los caminos que satisfacen una estrategia no significa conocer cómo definir los casos de test. • Asociado con toda estrategia de test, existen dos medidas: 1. El mı́nimo número de casos de test. 2. El ratio de efectividad del test. Administración y Gestión de Proyectos de Software, UNS 275 Medidas de Cubrimiento de Tests... 277 Número Mı́nimo de Casos de Test • Una alternativa para tests de caja blanca es seleccionar casos de test de tal manera que cada rama (arco) sea ejecutada al menos una vez (cobertura de arcos). • La estrategia de caja blanca mas exhaustiva es seleccionar casos de test de tal forma que todo camino posible del programa sea ejecutado al menos una vez (cobertura de caminos). Prácticamente imposible. • Existe un impedimento básico en las estrategias de caja blanca: Camino No Factible: es un camino del programa que no puede ser ejecutado por ningún input. Ejemplo: ABCEFG Administración y Gestión de Proyectos de Software, UNS Administración y Gestión de Proyectos de Software, UNS 276 • Es importante no sólo diseñar la estrategia, sino también el número mı́nimo de casos de test. • El teorema de descomposición nos permite calcular el NMCT. • Un caso de test corresponde a un camino a través del grafo F . • Para calcular el NMCT, debemos calcular el número mı́nimo de caminos m(F ) requeridos para satisfacer la estrategia. • Podemos calcular m(F ) a partir del árbol, conociendo m(F ) para los primos, la secuencia y el anidamiento. Administración y Gestión de Proyectos de Software, UNS 278 Número Mı́nimo de Casos de Test: Ejemplo Ratio de Efectividad de Test... • Dada una estrategia T que requiere cubrir una clase de objetos (sentencias, caminos,...), para un programa dado y un conjunto de casos de prueba, se define el Ratio de Efectividad del Test: RETT =número de objetos de T usados al menos una vez / número total de objetos de T • Los gerentes asumen que normalmente RET es del 100%. experiencia dice que no supera el 40%. La • Se testea correctamente el software? Administración y Gestión de Proyectos de Software, UNS 279 Ratio de Efectividad de Test 281 Métricas Orientadas a Objetos • Para un programa y un conjunto de casos de test, deseamos conocer en que grado los casos de prueba satisfacen una estrategia particular de test. • Ejemplo: Ejecutamos con 2 casos de prueba: ”6” y ”9”. Los casos de test cubren dos caminos: ABDEG y ABDEFG y cubren 6 de las 7 sentencias, 7 de los 8 arcos y 2 de los 4 caminos. Decimos que cubrimiento de sentencias es 86%, cubrimiento de arcos es 87,5% y cubrimiento de caminos es 50%. Administración y Gestión de Proyectos de Software, UNS Administración y Gestión de Proyectos de Software, UNS 280 • Métricas propuestas por Shyam R.Chidamber y Chris F.Kemerer 1. Definición de Objetos y Relaciones entre Objetos – 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) 2. Atributos y Propiedades de Objetos – Respuesta para una clase (RFC: Response for a Class) – Falta de cohesión en los métodos (LCO: Lack of Cohesion) 3. Comunicación entre Objetos – RFC – Acoplamiento entre clases (CBO: Coupling Between Objects) Administración y Gestión de Proyectos de Software, UNS 282 Métodos Ponderados por Clase : WMC Número de Descendientes : NOC • W M C = Σci, donde ci es una medida de complejidad del método i. • El número de métodos y su complejidad es un predictor de cuanto tiempo y esfuerzo es necesario para desarrollar y mantener la clase. • Cuanto más métodos mayor impacto en los hijos (herencia). • Definida como el número inmedidato de subclases. • 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. • Clases con más métodos son mas especı́ficas, limitando el reuso. • Un gran número de hijos también es un indicador de la influencia potencial de una clase en el diseño. Administración y Gestión de Proyectos de Software, UNS 283 Profundidad del Arbol de Herencia : DIN 285 Acoplamiento entre Clases : CBO • La cantidad de clases con las cuales está acoplada. • La longitud máxima desde el nodo hasta la raı́z del árbol. • 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. Administración y Gestión de Proyectos de Software, UNS Administración y Gestión de Proyectos de Software, UNS 284 • Una clase está acoplada con otra si usa métodos o variables de instancia de la otra. • Un valor alto decrementa 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 se presenta mas riguroso debe ser el testing. Administración y Gestión de Proyectos de Software, UNS 286 Respuesta para una Clase : RFC Métricas propuestas por Lorenz y Kidd • 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. • Tamaño de la clase (TC): – Número de Operaciones (heredadas + privadas) – Número de Atributos (heredados + privados) • Aumenta el esfuerzo de testeo y mantenimiento. • Puede surgir el interrogante de si la clase está modelada correctamente. Administración y Gestión de Proyectos de Software, UNS • Dividen las métricas en cuatro categorı́as: tamaño (recuento de atributos y operaciones), herencia (reutilización del código a lo ancho y alto de la jerarquı́a de clases), valores internos (cohesión y análisis de código) y valores externos (acoplamiento y reuso). 287 Falta de Cohesión en los Métodos : LCO • Número de Operaciones Invalidadas por una Subclase (NOI) – Invalidación: cuando una subclase substituye una operación heredada por una versión especializada para su propio uso. Administración y Gestión de Proyectos de Software, UNS 289 Métricas propuestas por Lorenz y Kidd... • 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. • Número de Operaciones Agregadas por una Subclase (NOA) – Las subclases se especializan agregando atributos y operaciones privadas. • Indice de Especialización (IE) = (N OI ∗ nivel)/Mtotal . – nivel= nivel de la jerarquı́a de clases donde reside la clase. – Mtotal=número total de métodos para la clase. • La falta de cohesión implica que una clase debiera dividirse en dos o más clases. Administración y Gestión de Proyectos de Software, UNS 288 Administración y Gestión de Proyectos de Software, UNS 290 Métricas Orientadas a Operaciones Métricas para Pruebas OO (Binder)... • Propuestas por Lorenz y Kidd. 2. Herencia • Número de Clases Raı́z (NCR): Cantidad de jerarquı́as de clases. • Admisión (ADM): medida de herencia múltiple. Si ADM > 1 la clase hereda de más de una clase raı́z. • Número de Descendientes (NOC) y Profundidad del Arbol de Herencia (DIN). • Tamaño Medio de Operación: (T OAvg ). – LOC – Cantidad de mensajes enviados por la operación. • Complejidad de Operación (CO): se calcula mediante cualquier métrica de complejidad. • Número medio de parámetros por operación (N Pavg ). Administración y Gestión de Proyectos de Software, UNS 291 Métricas para Pruebas OO (Binder) 293 Métricas para Proyectos OO (Lorenz y Kidd) • Número de Guiones de Escenario (NGE) 1. Encapsulamiento • Carencia de Cohesión en Métodos (LOC). • Porcentaje Público y Protegido (PPP): Los atributos públicos se heredan de otras clases. Los atributos protegidos son una especialización y privados de una clase especı́fica. Esta métrica indica el ratio entre ambos. • Acceso Público a Datos Miembros (APD): Indica el número de clases (o métodos) que pueden acceder a los atributos de otra clase, violando el encapsulamiento. Administración y Gestión de Proyectos de Software, UNS Administración y Gestión de Proyectos de Software, UNS 292 – Guión de Escenario: es una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación. • Número de Clases Claves (NCC) – Clase Clave: Clase central al dominio del problema. • Número de Subsitemas (NSUB) – Proporciona una idea de la asignación de recursos, de planificación y de esfuerzo de integración. Administración y Gestión de Proyectos de Software, UNS 294