Ingeniera de Software II Final1. Defina mtricas del proceso y del producto/objetivas y subjetivas.

a) METRICAS DEL PROCESO: Son aquellas que cuantifican atributos del proceso de ingeniera desoftware y del equipo de desarrollo.

b) METRICAS DEL PRODUCTO: Son aquellas que se aplican al producto software resultante delproceso de desarrollo de software.

c) MEDIDAS OBJETIVAS: Pueden ser computadas en forma precisa por un algoritmo. Su valor nocambia con el tiempo, lugar u observador.

d) MEDIDAS SUBJETIVAS: Sus valores dependen de apreciaciones personales de quienes las aplican. 2. Qu son las mtricas post mortem y cuales las tempranas? a) Mtricas post-mortem: Son aquellas que se obtienen una vez finalizado el producto de software.Sirven para:

Conformar una lnea base para futuras estimaciones. Ayudar al mantenimiento conociendo la complejidad lgica, tamao, flujo de informacin identificando mdulos crticos. Ayudar en los procesos de reingeniera.

b) Mtricas tempranas: Se obtienen en etapas tempranas es decir antes de la finalizacin del productode software. 3. Para qu sirven las mtricas? NO SE PUEDE CONTROLAR LO QUE NO SE PUEDE MEDIR. De Marco Las mtricas son la clave tecnolgica para el desarrollo y mantenimiento exitoso del software. Son la base para realizar buenas estimaciones. Permiten evaluar calidad. Permiten evaluar productividad. Permiten controlar el proyecto.

Permiten evaluar beneficios del uso de nuevos mtodos. Nunca deben utilizarse las mediciones para evaluar, premiar o castigar el rendimiento individual. 4. Defina la diferencia entre mtricas y estimacin. Enumere las estimaciones que conoce. a) Mtrica: Es la utilizacin de mediciones. Una medicin, es la indicacin de algn atributo del proceso o producto. Las mtricas son actividades importantes que no deben descuidarse. Proporcionan una perspectiva histrica. Ayudan en el desarrollo. Son la base de todas las dems actividades de planificacin del proyecto. b) Estimaciones: Se intenta obtener valores aproximados acerca de alguna variable. Las mtricas son la base para realizar las estimaciones. Para obtener estimaciones confiables generalmente se usan varias tcnicas y se comparan y concilian resultados. La estimacin no es una ciencia exacta.

Modificaciones en la especificacin hacen peligrar las estimaciones. Requiere experiencia, acceso a informacin histrica y decisin para convertir informacin cualitativa en cuantitativa. Hay varios tipos de estimaciones. Estimaciones de recursos (humanos, de software reutilizable, de hardware y herramientas de software, etc.). Costos y tiempos. Los factores que influyen en la estimacin son la complejidad, el tamao, la estructuracin del proyecto. Juicio experto: jerrquica hacia abajo, basada en la experiencia.

Tcnicas de estimacin:

1/14

Ingeniera de Software II Final Tcnica Delphi: Coordinador y expertos. Divisin de trabajo: Jerrquica hacia arriba.

MODELOS EMPIRICOS DE ESTIMACION

Utilizan frmulas derivadas empricamente para predecir costos o esfuerzo requerido en el desarrollo del proyecto. Ej.: MODELO COCOMO de Boehm (modelo constructivo de costos). 5. Explique la mtrica de punto funcin. Puntos de funcin: Mide la cantidad de funcionalidad de un sistema descripto en una especificacin (tiene en cuenta entradas, salidas, consultas, almacenamientos internos e interfaces externas). PF = Total * (0,65 + 0,01 * Sum(Fi)); i = 1 a 14; 0 75%) Definir las consecuencias del riesgo, estimar el impacto en el proyecto (depende de la naturaleza del riesgo, del alcance y de la duracin): catastrfico, serio, tolerable o insignificante.

generar la tabla de riesgo (se coloca la informacin en una tabla se ordenan segn el impacto y la probabilidad de ocurrencia. Luego se establece una lnea de corte para indicar hasta que riesgos se van a tratar). Un factor de riesgo que tenga gran impacto pero poca probabilidad de que ocurra, no debera absorber un tiempo significativo. Los riesgos de gran impacto con una probabilidad de moderada a alta y los riesgos de poco impacto pero con gran probabilidad deberan tomarse en cuenta. 17. Qu tipos de estrategia de reduccin de riesgos conoce? Explique. a) Estrategias de anulacin: con esta estrategia, se busca eliminar el riesgo. Ej.: Reemplazar posibles componentes defectuosas con los comprados de fiabilidad conocida. b) Estrategias de disminucin: con esta estrategia se intenta prevenir el riesgo o atenuar el impacto. Ej.: Generar equipos para que varios comprendan distintos trabajos a fin de reorganizar las tareas en caso de enfermedad del personal. c) Planes de contingencia: es una estrategia para abordar el problema Ej.: Documento que demuestre las contribuciones ante problemas organizativos/financieros. 18. Describa los fundamentos del Diseo. a) Modularidad Es el atributo que permite que un programa sea manejable de manera intelectual. En un diseo modular las componentes tienen entradas y salidas claramente definidas y cada componente tiene un propsito claramente establecido. De esta forma es fcil examinar cada componente separadamente de las otras, para determinar si implementa las tareas requeridas. Los componentes modulares estn organizados en una jerarqua, como resultado de la descomposicin o abstraccin, de modo que puede investigarse el sistema de a un nivel por vez. Razones para utilizar Modularidad: Se subdivide el problema y reduce la complejidad. El software monoltico no se entiende. La subdivisin est indefinida y comienzan a tener peso otras variables costo . Se debe evitar la modularidad excesiva o insuficiente.

Un diseo modular reduce la complejidad, facilita los cambios, facilita la implementacin. b) Niveles de abstraccin. En la descomposicin del diseo, los componentes ubicados en un nivel refinan los conceptos asociados a los componentes del nivel superior. Se considera que el nivel ms alto es el ms abstracto y se dice que los componentes estn organizados segn niveles de abstraccin. Abstraccin procedimental: Se trata de una secuencia dada de instrucciones que tiene una funcin especfica y limitada.

Abstraccin de datos: Es una coleccin determinada de datos que describen un objeto de datos. c) Ocultamiento de la informacin. Los mdulos deben disearse de manera que la informacin (procedimientos y/o datos) que esta dentro del mdulo sea inaccesible para otros mdulos. Los niveles superiores ms abstractos ocultan los detalles de los componentes funcionales o de datos. Cada componente oculta de los dems sus decisiones de diseo. d) Independencia de los componentes.

6/14

Ingeniera de Software II FinalPermiten una comprensin y noficicacin mas facil. Para reconocer y medir el grado de interdependencia de los componentes de un diseo se aplican dos conceptos: Cohesin: Es el grado de adhesivo interno con el que se ha construido el componente. Un componente es cohesivo si todos sus elementos estn orientados a la realizacin de una nica tarea y son esenciales para llevarla a cabo. Los sistemas basados en objetos casi siempre tienen diseos altamente cohesivos, dado que el mismo proceso de composicin fuerza a ubicar las acciones junto con los objetos a los que afectan. El concepto de cohesin en este caso esta ligado a que todo atributo, mtodo y accin sea esencial para el objeto. Acoplamiento: Se dice que dos componentes estn altamente acoplados cuando existe mucha dependencia entre ellos. La dependencia de un componente respecto de otro puede establecerse de distintas formas: Las referencias hechas de un componente a otro. El grado de control que un componente tiene sobre otro. La cantidad de datos pasados de un componente a otro.

El grado de complejidad de la interfaz entre los componentes. Por lo general, los componentes en un diseo orientado a objetos tienen poco acoplamiento, dado que cada objeto contiene las definiciones de las acciones que realiza o son realizadas por l. 19. Qu es la cohesin funcional? Es el grado de cohesin en el cual todos los elementos que componen un mdulo estn relacionados en el desarrollo de una nica funcin. Es el mejor grado de cohesin, Ej.: funciones matemticas cos (x). 20. Qu es la independencia funcional? El concepto de independencia funcional es una derivacin directa del concepto de modularidad y el de abstraccion y ocultamiento de informacin. La independencia funcional de asdquiere desarrollando mduclos con una clara funcin y una interfaz sencilla. La independencia funcional es importante porque: Desarrollamos mdulos independientes. Son fciles de desarrollar, de mantener, de probar. Se reduce la propagacin de errores.

Se fomenta la reautilizacin de mdulos. La independencia funcional es la clave de un buen diseo, y el diseo es la clave dal calidad el software. La independencia se mide con dos criterios: acoplamiento y cohesin. 21. Describa el concepto de acoplamiento y cohesin y sus respectivos grados. a) Grados de acoplamiento. Sin acoplamiento: Un modulo llama a otro y cuando este termina su ejecucin, le devuelve el control al primero. No hay pasaje de parmetros. Por datos: Hay paso de parmetros sin estructura interna. Por estructuras de datos: el modulo llamado depende de la estructura del que llama. Por control: el modulo que llama pasa un dato que controla el comportamiento interno del modulo llamado. Externo: Por base de datos. Global: Varios mdulos utilizan una misma rea de datos de mbito global.

Por contenido o PATOLOGICO: Un modulo necesita o accede a una parte de otro, rompiendo la jerarqua de funcionalidad. Un mdulo modifica algn elemento local de otro mdulo, por ejemplo el mdulo A toca una variable global del mdulo B. b) Grados de Cohesin:

7/14

Ingeniera de Software II Final Funcional: todos los elementos que componen un mdulo estn relacionados en el desarrollo de una nica funcin. Ej.: funciones matemticas, cos (x). Secuencial: El mdulo realiza diversas tareas de forma secuencial (importa el orden). La salida de uno es la entrada de otro. Ej.: Formatear registro = Leer registro + aplicar formato registro. Comunicacional: igual que el anterior pero el orden en que se ejecutan sus actividades no es importante. Varias tareas que se realizan de forma paralela. Utilizan los mismos datos de entrada y/o salida. Ej.: Obtener detalles cliente (num_cta, nombre_cli, saldo_prestamo). Procedural: Las tareas de un mdulo realizan actividades diferentes y posiblemente sin relacionar. El orden de realizacin es secuencial. Existe poca relacin entre los datos de entrada y salida de las tareas. Ej.: Mdulo Detectar error, corregirlo y reanudar la ejecucin. Temporal: cuando los elementos del mdulo estn implicados en actividades relacionadas en el tiempo. Ejemplo, mdulos de inicializacin, finalizacin y todos aquellos que representen unas acciones que deban ejecutarse secuencialmente en el tiempo. No importa el orden de realizacin. Lgica: cuando existen relaciones lgicas entre los elementos de un mdulo. Ej.: rutina general de E/S.

Coincidental: cuando entre los elementos que lo componen no existe ninguna relacin con sentido. Las tareas del mdulo no estn relacionadas de forma significativa. Ocurre cuando se intenta englobar un conjunto de instrucciones parecidas, que no se van a ejecutar a la vez, dentro de un mismo mdulo. 22. Describa diferentes formas de presentar la informacin. a) Mantener separado el software para la presentacin y la informacin misma. Directa. Grfica. b) Se deben conocer los usuario y como utilizarn el sistema: Informacin precisa o relacin entre los valores? Es necesario presentar inmediatamente los cambios?.

El usuario realiza acciones en funcin de los cambios?. 23. Que es una pruebas? Objetivos. Es un elemento crtico para la garanta de calidad del software y representa una visin final de las especificacines del diseo y de la codificacin. Objetivos de la prueba: La prueba es un proceso de ejecucin de un programa con la intencin de descubrir errores. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.

Una prueba tiene xito si descubre un erro nodetectado hasta entonces. 24. Defina la diferencia entre verificacin y validacin. a) Verificacin: Se valida si estamos construyendo el producto correctamente. b) Validacin. Se tiene que validar que estamos construyendo el producto correcto para cumplir los requerimientos del usuario. 25. Describa las estrategias de integracin. La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. Estrategias de integracin: No incremental (Big bang): Se combinan todos lo mdulos por anticipado. Se prueba todo el programa en conjunto. La correccion de errores se hace muy difcil.

8/14

Ingeniera de Software II FinalIncremental: El programa se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y corregir (top-down, bottom-up). 26. Enumere las pruebas de integracin que conoce. La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar los mdulos probados mediante la prueba de unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. Durante la integracin, las tcnicas que ms prevalecen son las de diseo de casos de prueba de caja negra, aunque se pueden llevar a cabo algunas pruebas de caja blanca con el fin de asegurar que se cubren los principales caminos de control. a) Integracin incremental. Top-down. Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal. Los mdulos subordinados al mdulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primeroen-anchura. Bottom-up. Empieza la construccin y la prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardos.

Mezcla.

Se mezclan las dos anteriores como otra alternativa para hacer una prueba de integracin incremental. b) Integracin no incremental. Big Bang. Se combinan todos los mdulos por anticipado y se prueba todo el programa en su conjunto. Esto hace difcil la correccin de errores, dado que es complicado determinar las causas al tener todo el programa entero. c) Integracin descendente. en profundidad. en anchura. d) Integracin ascendente. En Arquitecturas Orientadas a Objetos: Debido a que software orientado a objetos no tiene una estrategia obvia de control jerrquico, tiene poco significado las estrategias de integracin descendente y ascendente tradicionales. Pruebas basadas en subprocesos (para responder a una entrada o evento). Pruebas basadas en el uso (clases independientes, luego dependientes). Pruebas de grupo (colaboracin entre las clases).

Se usan conductores y resguardos 27. Enumere las tcnicas de validacin que conozca. a) Las pruebas de funcin evalan si el sistema ejecuta la funcionalidad de la especificacin. (Requerimientos Funcionales). b) Las pruebas de desempeo evalan si el sistema cumple con todos los requerimientos (Requerimientos No funcionales). Ejemplos: De estrs, de volumen, de compatibilidad, de seguridad, de temporizacin, de calidad, de recuperacin, de mantenimiento, de documentacin, de factores humanos, etc. Las pruebas de validacin en general utilizan tcnicas de caja negra. 28. Enumere las tcnicas de verificacin que conozca. a) Las pruebas de unidad verifican que el componente funciona correctamente a partir del ingreso de distintos casos de prueba. Se realiza en ambiente controlado. En general se utilizan pruebas de caja blanca. En las orientadas a objetos se prueban las Clases encapsuladas (operaciones y comportamiento).

9/14

Ingeniera de Software II Finalb) Las pruebas de integracin verifican que los componentes trabajan correctamente en forma conjunta. Durante la integracin, las tcnicas que ms prevalecen son las de diseo de casos de prueba de caja negra, aunque se pueden llevar a cabo algunas pruebas de caja blanca con el fin de asegurar que se cubren los principales caminos de control. 29. Haga un ejemplo de la prueba de particin equivalente.

30. Enumere que tipo de pruebas conoce a) Pruebas de unidad: verifican que el componente funciona correctamente a partir del ingreso de distintos casos de prueba. b) Pruebas de integracin: verifican que los componentes trabajan correctamente en forma conjunta. c) Pruebas de funcin: evalan si el sistema ejecuta la funcionalidad de la especificacin. d) Pruebas de desempeo: evalan si el sistema cumple con todos los requerimientos. e) Pruebas de aceptacin: se ejecutan con el cliente. f) Pruebas de instalacin: Se ejecutan en el ambiente donde ser utilizado el software. 31. Describa las pruebas de caja negra y ejemplifique alguna. La pruebas de caja negra son diseadas para validar los requisitos funcionales sin fijarse en el funcionamiento interno de un programa. Se buscan los siguientes errores. Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento.

Errores de inicializacin y de terminacin. Las tcnicas de pruebas de caja negra se centran en el mbito de la informacin de un programa de forma que se proporciones una cobertura completa de la prueba. Particin Equivalente: Se orienta a la definicion de casos de prueba que descubran errores. Se basa en una definicion de clases de equivalencia. Una clase de equivalencia representa un conjunto de estados validos o no validos para condiciones de entrada. Una condicion de entrada es un valor especifico , un rango de valores , un conjunto de valores o una condicion logica. Si una condicion de entrada especifica un rango, se define una clase de equivalencia valida y dos no validas. Si una condicion de entrada especifica un valor especifico, se define una clase de equivalencia valida y dos no validas. Si una condicion de entrada especifica un elemento de un conjunto, se define una clase de equivalencia valida y una no valida. Si una condicion de entrada es logica, se define una clase de equivalencia valida y una no valida.

Anlisis de Valores Lmites: los errores tienden a darse ms en los lmites del campo de entrada que en el centro. Por ello, se ha desarrollado el anlisis de valores lmites (AVL) como tcnica de prueba. El anlisis de valores lmite es una tcnica de diseo de casos de prueba que complementa a la particin equivalente. El AVL lleva a la eleccin de casos de prueba en los

10/14

Ingeniera de Software II Finalextremos de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL obtiene casos de prueba tambin para el campo de salida. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben disear casos de prueba para los valores a y b, y para los valores justo por debajo y justo por encima de a y b, respectivamente. Aplicar las directrices 1 y 2 a las condiciones de salida. Si las estructuras de datos internas tienen lmites preestablecidos, hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos en sus lmites.

Grafos de Causa y Efecto: es una tcnica de casos de prueba que proporciona una concisa representacin de las condiciones lgicas y sus correspondientes acciones. La tcnica sigue cuatro pasos: Listar para cada mdulo entradas y acciones. Desarrollar el grafo. Convertir el grafo a una tabla de decisin. Convertir las reglas en casos de prueba.

Validacin de Datos: Para sistemas conducidos por rdenes se deben especificar casos de prueba con: Ordenes con sintaxis incorrecta. Ordenes sintcticamente correctas pero fuera de secuencia. Ordenes incompletas. Pulsar RETURN. Orden correcta con ms parmetros. Generar interrupcin despus de la orden. Probar delimitadores. Orden sin delimitadores. Orden con delimitador incorrecto. Distinto delimitador a izquierda y derecha. Sustituir delimitador vlido por otro.

No aparear delimitadores. 32. Describa las pruebas de caja blanca y ejemplifique alguna. a) Las pruebas de caja blanca son mtodos de diseo de casos de prueba que usa la estructura de control de diseo procedimental para obtener casos de prueba. Mediante la caja blanca, se pueden obtener casos de prueba que: Garanticen que se ejercuta por lo menos una vez todos los caminos independientes de cada mdulo. Ejercuten todos lo deciciones lgicas en sus vertienes verdaderas o falsas. Ejecuten todos lo bucles en sus lmites y con sus lmites operacionales. Ejecuten las estrucuta internas de datos para segurar su validez.

Algnas tcnidas de caja blanca son: Camno bsico: Garantiza la ejecucin de al menos una vez todas las sentenciasd el programa. Mtodo de prueba: Construir un grafo de flujo a partir del diseo o cdigo fuente. Determinar la complejidad ciclomtica. Determinar el conjunto de caminos independientes. Preparar los casos de prueba.

Prueba de bucles: Se centra exclusivamente en la validez de las construcciones o bucles (simples, anidados, concatenados, no estructurados). 33. Qu tipos de mantenimiento conoce?

11/14

Ingeniera de Software II FinalEl mantenimiento es la atencin del sistema a lo largo de la evolucin despues de que el sistema sea entregado. a) Mantenimiento correctivo: Diagnstico y correccin de errores. b) Mantenimiento adaptativo: Modificacin del software para interaccionar correctamente con el entorno. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las caractersticas externas de productos) para el que se desarroll el software. c) Mantenimiento perfectivo: Mejoras al sistemas. Lleva al software ms all de sus requisitos funcionales originales. d) Mantenimiento preventivo: Se efecta antes que haya una peticin, para facilitar el futuro mantenimiento. Se aprovecha el conocimiento sobre el producto. 34. Defina ingeniera inversa y reingeniera. a) Ingeniera Inversa: Parte del cdigo fuente y recupera el diseo y en ocasiones la especificacin, para aquellos sistemas en los que no hay documentacin. b) Reingeniera: Es un proceso que reconstruye el sistema tratando de mejorar la calidad, para aquellos sistemas difciles de mantener, obsoletos, ineficientes. Puede combinarse la Reingeniera con un proceso de Ingeniera Inversa previo en aquellos caso que sea necesario. 35. Qu es la barrera de mantenimiento? Por norma general, el porcentaje de recursos necesarios en el mantenimiento se incrementa a medida que se genera ms software. A esta situacin se le conoce como Barrera de Mantenimiento. Es decir llega un punto en el cual es menos costoso hacer un desarrollo nuevo, que arreglar un software viejo. Su consecuencia es la disminucin de otros desarrollos (dado que se llego al lmite de recursos). Las modificaciones pueden provocar disminucin de la calidad total del producto. Las tareas de mantenimiento generalmente provocan reiniciar las fases de anlisis, diseo e implementacin (una de las principales razones por la cual es tan costoso). Mantenimiento estructurado vs. No estructurado. Involucra entre un 40% a 70% del costo total de desarrollo. Los errores provocan insatisfaccin del cliente.

Pueden existir efectos secundarios sobre cdigo, datos, documentacin. 36. Qu tipo de mantenimiento conoce y cual es el flujo segn el tipo? Los tipos de mantenimiento son: correctivo: El flujo es el siguiente A, B, E, G (si es crtico sigue por J, de lo contrario por K), L, M, N (puede volver a L) y finaliza en . preventivo: Se efecta antes que haya una peticin, para facilitar el futuro mantenimiento. adaptativo: El flujo es el siguiente A, B, C, L, M, N (puede volver a L) y finaliza en . perfectivo: El flujo es el siguiente A, B, D, F (si No procede sigue por H, de lo contrario por I), L, M, N (puede volver a L) y finaliza en .

37. Qu es la gestin de la configuracin? Defina lnea base y ejemplifique. Es la GESTION DEL CAMBIO. Arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de desarrollo.

El objetivo es maximizar la productividad, minimizando los errores. Pasos de la gestin de la configuracin (GCS): Identificar el cambio.

12/14

Ingeniera de Software II Final Controlar el cambio. Garantizar que el cambio se implementa adecuadamente.

Informar del cambio a todos aquellos a los que les afecte. Lnea base: Es un punto de referencia en el desarrollo que queda marcado por el envo y aprobacin del elemento de configuracin mediante una revisin tcnica formal. Nos ayuda a controlar los cambios que se realizan aplicando un procedimiento formal para evaluar y verificar cada modificacin.

38. Cuales son los aspectos claves para la transeferencia exitosa del producto del desarrollador al usuario? Descrbalos. El entrenamiento y la documentacin son dos aspectos clasves para la transferencia exitosa de productos al usuario. a) Entrenamiento de usuario: funciones del sistema a las que el usuario debe acceder. De operaciones: como poner en marcha y ejecutar el nuevo sistema y como dar soporte a los usuarios. b) Documentacin. Manuales de usuario. Manuales de operador Tutoriales. Guas del programador. Asistencia en lnea.

Gua de mensajes de error. 39. Relacin entre el desarrollo y niveles de prueba.

13/14

Ingeniera de Software II FinalRequisitos de usuario Prueba de aceptacin El usuario comprueba que el sistema hace lo especificado en el contrato

Especificacin de requisitos

Pruebas de sistema

Sistema (cumplimiento de objetivos) Validacin (desajustes entre el softw are y los requisitos)

Diseo modular

Pruebas de integracin

Agrupamiento de mdulos Interfaces

Especificacin y lgica de mdulo

Pruebas de unidad

Lgica de mdulos (caja blanca) Funciones (caja negra)

Cdigo

14/14