Anda di halaman 1dari 14

Ingeniera de Software II Final

1. Defina mtricas del proceso y del producto/objetivas y subjetivas.

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

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

c) MEDIDAS OBJETIVAS: Pueden ser computadas en forma precisa por un algoritmo. Su valor no
cambia 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 producto
de 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 <= Fi <= 5 Se mide: Productividad = PF/persona_mes. Calidad = errores/PF. Costo = $/PF. Punto caracterstica: A las entradas, salidas, consultas, almacenamientos internos, interfaces externas sumamos el nmero de algoritmos. Punto funcin extendida para sistemas de tiempo real: A las entradas, salidas, consultas, almacenamiento interno e interfaces externas se suman nmero de entradas y salidas de control. 6. Diferencie mtricas vlidas y confiables. a) Confiabilidad: Es la consistencia al aplicar las mismas mtricas usando los mismos mtodos sobre los mismos campos. Si los valores obtenidos son iguales a la confiabilidad esa alto. Indice de variacin = desviacinEstandard / promedio. Cuanto menos es el indice de variacin, ms confiable es la medicin. b) Validez: De construccin: validez terica de la mtrica. Relacionada con el criterio: validez predictiva de la mtrica.

De contenido: validez de la mtrica para cubrir todos los significados. Una mtrica puede ser: Confiable pero no vlida. Vlida pero no confiable. Debe ser confiable y vlida. 7. Defina mtricas directas e indirectas. a) Mtricas directas: Se obtienen del proceso o producto siendo observado y no dependen de otras medidas. Entre las medidas directas del proceso se encuentran el costo y el esfuerzo del producto, las lineas de cdigo, la eficiencia en tiempo del cdigo, el tamao del memoria requerido, los defectos observados en un periodo de tiempo. b) Mtricas indirectas: Dependen de medidas ms elementales. Entre ellas e encuentran la funcionalidad, complejidad, eficiencia, confiabilidad, facilidad de mantenimiento. 8. Explique las mtricas orientadas al tamao. La ms comn es la lnea de cdigo o LDC, que es una medida directa del software y proceso. a) LDC tiene como caractersticas que: Depende del lenguaje. Hay muchas formas de contarlas, requiere de una clara definicin de qu es una lnea de cdigo.

No mide tamao de un programa, sino lneas no comentadas. 9. Describa los tipos de planificacin organizativa que conozca. a) ESTRUCTURA DE PROYECTO

2/14

Ingeniera de Software II Final


DE PROYECTO: integracin de un equipo de personas que llevan a cabo el proyecto de principio a fin. FUNCIONAL: equipos distintos de personas que realizan cada fase del proyecto.

MATRICIAL: cada proyecto de desarrollo tiene un administrador. Cada persona trabaja en uno o ms proyectos bajo la supervisin del administrador correspondiente. b) ESTRUCTURA DE GRUPO DEMOCRATICOS: el liderazgo rota de un miembro a otro dependiendo de las tareas que se realicen.

CON JERARQUIA: muy estructurados.

CON JERARQUIA Y COMUNICACIN EN LOS NIVELES.

10. Que es el modelo MOI? MOI son las siglas de Motivacin, Organizacin e Innovacin. Cada uno de estos conceptos es explicados a continuacin: a) Motivacin: Para conseguir motivacin tenemos que conseguir que la gente se sienta involucrada en lo que hace, que sus comentarios son escuchados y tenidos en cuenta, que sus esfuerzos son reconocidos, que son autnomos y que pueden hacer las cosas por si mismos. Se sienten responsables de lo que hacen porque se les da esa responsabilidad y se confa en ellos. b) Organizacin: Para conseguir organizacin debemos crear una estructura para que las ideas puedan ser canalizadas y no se pierdan. Que sea fcil cooperar entre los miembros del equipo, que los recursos estn lo ms disponible posible para todos, conseguir que la informacin fluya evitando sobre todo la burocracia y el papeleo innecesario. Evitar cualquier traba o problema que haga que la gente se sienta frustrada ya que esto mata la motivacin. c) Innovacin o Ideas: Para conseguir innovacin o ideas tenemos que quitarnos la mala costumbre de criticar. Criticar una idea es lo ms fcil del mundo, cualquier tonto puede criticar (asesinos de ideas), por otro lado tener una idea es difcil y requiere un esfuerzo considerable. En un ambiente innovador las ideas no se critican, se escuchan, se proponen mejoras entre todos, se barajan alternativas, se prueba a mezclar ideas para dar otras nuevas. Para esto tiene que haber un ambiente generoso, abierto y respetuoso, en el que la idea por ser tuya no es mejor que las dems. 11. Que aspectos deben tenerse en cuenta en la planificacin? Expliquelos. a) Relacin gente-trabajo: Depende de los tiempos disponibles.

3/14

Ingeniera de Software II Final


La inclusin de ms personas en el desarrollo no siempre genera aumento en la productividad.

Los retrasos en la agenda no se solucionan con la ampliacin del equipo de desarrollo. b) Definiciones de tareas y paralelismos. Cuando un proyecto involucra ms de una persona en su desarrollo es posible realizar actividades en paralelo. El planificador debe determinar la dependencia entre tareas.

El director de proyecto debe saber que tareas estn en el camino crtico. c) Distribucin de esfuerzos.

Prueba Codificacin Planificacin

Prueba Otros Codificacin

Ilustracin 1: Distribucin de Objetos de Brooks d) d) Mtodos de planificacin temporal.

Ilustracin 2: Distribucin de Objetos de Yourdon

Estas tcnicas desarrollan una red de tareas a realizarse desde el principio hasta el fin del proyecto. La lista de tareas se denomina Estructura de descomposicin de trabajo.

Adems se describe el secuenciamiento de las tareas en una lista de restricciones. Para llevar a cabo esto se utiliza el mtodo PERT. e) Seguimiento y control del proyecto. Realizar reuniones peridicas para informar progresos y problemas. Evaluar revisiones.

Comparar que los hitos se hayan realizado en fecha. 12. Describa los tipos de planificacin temporal que conoce. a) PERT Se utiliza para controlar la ejecucin de proyectos con gran nmero de actividades que implican investigacin, desarrollo y pruebas. b) CPM

Se utiliza en proyectos en los que hay poca incertidumbre en las estimaciones. El camino crtico es el camino de longitud mxima que va desde el vrtice que representa el suceso inicio del proyecto al vrtice que representa el suceso fin del proyecto. Pert y Cpm son tcnicas dirigidas por la informacin ya desarrollada en actividades anteriores de la planificacin del proyecto: Estimaciones de esfuerzo, descomposicin de la funcin del producto, seleccin del modelo de proceso adecuado y del conjunto de tareas como as tambin la descomposicin de tareas.

c) Diagramas de barras o de Gantt: Representacin grfica de las tareas sobre una escala de tiempos.
Las tareas se representan en forma de barra sobre dicha escala manteniendo la relacin de proporcionalidad entre sus duraciones y su representacin grfica, y su posicin respecto del punto origen del proyecto.

d) Red de tareas: representacin mediante una estructura en red de las tareas e hitos del proyecto. Una
red de tareas, tambin llamada red de actividades, es una representacin grfica del flujo de tareas de un proyecto. 13. Qu hara cuando una tarea se sale de la agenda?

a) Revisar el impacto sobre la fecha de entrega. Cuando la fecha de entrega es ajustada, se puede
aplicar el time-boxing (tiempo encajonado). Esta estrategia reconoce que quizs no se pueda entregar todo el producto completo para la fecha predefinida. Por lo que se elige el paradigma incremental y se crea una planificacin para cada entrega. b) Reasignar recursos.

4/14

Ingeniera de Software II Final


c) Reordenar tareas. d) Modificar entregas. 14. Qu es un riesgo? Un riesgo es un evento no deseado que tiene consecuencias negativas. Implica cambios y elecciones. Los gerentes deben determinar si pueden presentarse eventos no bienvenidos durante el desarrollo o el mantenimiento, y hacer planes para evitar estos eventos, o si estos son inevitables, minimizar sus consecuencias negativas. 15. Como es el proceso de administracin de riesgos? a) Identificacin del riesgo. Enumerar los verdaderos riesgos. Elaborar una lista de comprobacin de elementos de riesgo para estimar el impacto del riesgo. Clasificacin de los riesgos. del proyecto. del producto.

del negocio. b) Proyeccin del riesgo. Establecer una escala que refleje las probabilidades de ocurrencia de un riesgo. Bastante Improbable (< 10%). Improbable (10%-25%). Moderado (25%-50%). Probable (50%-75%). Bastante Probable (>75%).

Definir las consecuencias de un riesgo (depende de la naturaleza del riesgo, del alcance y de la duracin). Catastrfico. Serio. Tolerable.

Insignificante. c) Evaluacin del riesgo Definir los niveles de referencia. Predecir como afectaran al nivel de referencia las combinaciones de los mismos Riesgos Conocidos: Surgen de la evaluacin del proyecto. Riesgos predecibles: Utilizan experiencia de proyectos anteriores.

Riesgos impredecibles. d) Gestin de riesgos. Para realizar la gestin de riesgos se utiliza la cuaterna: [riesgo, probabilidad, impacto, pasos de gestin] e) Estrategia para la reduccin del riesgo. Evitar el riesgo. Transferir el riesgo. Asumir el riesgo (aceptndolo y controlandolo). Categoras de las estrategias. de anulacin. de disminucin.

de contingencia. f) Supervisin de los riesgos Priorizar aproximadamente el 20% de los riesgos. Detectar la ocurrencia de un riesgo que fue previsto. Asegurar que se estn cumpliendo los pasos definidos para cada riesgo.

5/14

Ingeniera de Software II Final


Recopilar informacin para el futuro.

Re-evaluar peridicamente los riesgos. 16. Cules son las actividades del anlisis de riesgo? Las actividades son:

Elaborar una lista de comprobacin de elementos de riesgo. Clasificacin de los riesgos, pueden ser del proceso, del producto o tcnicos y del negocio. Establecer una escala que refleje las probabilidad observada de un riesgo (bastante improbable < 10%, improbable 10-25%, moderado 25-50%, probable 50-75%, bastante probable >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 Final


Permiten 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 Final


Incremental: 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 Final


b) 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 Final


extremos 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 Final


El 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 Final


Requisitos 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