Estimación para proy_soft-caja_b_y_n

  • 133 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
133
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. “Año de la Inversión para el Desarrollo Rural y la Seguridad Alimentaria” UNIVERSIDAD PRIVADAD SAN PEDRO Asignación: Calidad de Software Docente: Ing. Valverde Bellodas Julio Cesar Ciclo: VIII Integrantes: - Díaz Pereyra Luis Manuel Enrique - Romero Cahuana Natalie Ruby - Risco Fernandez Jhon Roberth 2013
  • 2. ESTIMACIÓN PARA PROYECTOS DE SOFTWARE Estimación “Apreciar, poner precio, evaluar algo” Estimación de proyectos de software “Actividad de la planificación del proyecto de SW que intenta determinar cuánto dinero, esfuerzo, recursos y tiempo tomará construir un sistema o producto SW”. DEFINICIÓN La gestión del proyecto de software comienza con un conjunto de actividades que en grupo se denominan planificación de proyecto.Antes de que que el proyecto comience el gestor del proyecto y el equipo de software deben estimar el trabajo que habrá de realizarse, los recursos que se requerirán y el tiempo que transcurrirá desde el principio hasta el final. Una vez que se completen estas actividades, el equipo de software debe estableces un plan del proyecto que defina las tareas y fechas clave de ingenieria del software, que identiiquen quien es responsable de dirigir cada tarea y especifique las dependencias entre tareas que pueden ser determinantes en el progreso. OBSERVACIÓN La Planificacion requiere que los gestores técnicos y los miembros del equipo de software establezcan un compromiso inicial, aun cuando sea probable que este “compromiso” pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta automáticamente algún grado de incertidumbre.
  • 3. EL PROCESO DE PLANIFICACIÓN DEL PROYECTO El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costos y rpograma de trabajo. Además, las estimaciones deben intentar definir los escenarios de mejor y peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre, el equipo de software se embarca en un plan establecido como consecuencia de las tareas de planificación. Por lo tanto, el plan se debe adaptar y actualizar conforme avance el proyecto. En las secciones siguientes se estudiará cada una de las actividades asociadas con la planificación del proyecto de software. ÁMBITO DEL SOFWARE Y FACTIBILIDAD El ambito de software describe las funciones y caracteristicas que se entregarán a los usuarios finales, los datos que son entrada y salida, el “contenido” que se presenta a los usuarios como consecuencia de emplear el software, así como el desempeño, las restricciones, las interfases y la confiabilidad que acotan el sistema. El ámbito se define al usar de las dos técnicas siguientes: 1. Despues de una comunicación con todos los participantes se desarrolla una descripción narrativa del ámbito del software. 2. Los usuarios finales desarrollan un conjunto de casos de uso. RECURSOS La segunda tarea de la planificación es la estimación de los recursos necesarios para completar el esfuerzo de desarrollo del software “imagen” muestra las tres grandes categorías de los recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software). Cada recurso se especifica con cuatro caracteristicas: descripción de recursos; un informe de disponibilida; cuándo se requerirá el recurso; tiempo durante el cual se aplicar. Las últimas dos caracteristicas se pueden ver como una ventanade tiempo. La disponibilidad del recurso para una ventana especifica debe establecerse lo más pronto posible.
  • 4. TÉCNICAS DE DESCOMPOSICIÓN La estimación del proyecto de software es una forma de resolver problemas; en la mayoria de los casos, el problema que debe resolverse (es decir, el desarrollo de una estimación de costo y esfuerzo para un proyecto de software) es muy complejo como para considerarlo una sola pieza. Por esta razón se descompone el problema, recaracterizandolo comon un conjunto de problemas más pequenñños (y, esperanzandoramente, mas manejable). Tamaño del Software: La precisión de la estimación de un proyecto de software se manifiesta en varios factores 1. El grado con el cual el planificador ha estimado adecuadamente el tamaño del producto que se construirá 2. La habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero (una función de la disponibilidad de las metricas de software confiables a partir de proyectos previos). 3. El grado en el cual el plan del proyecto refleja las habilidades del equipo de software. 4. La estabilidad de los requisistos del producto y el entorno que soporta el esfuerzo de la Ingenieria de Software Estimación basada en el problema Las estimaciones de LDC y PF son distintas técnicas de estimación, aunque ambas tienen varias caracteristicas en común. EL planificador del proyecto comienza con un enfoque acotado del ámbito del software y a partir de ahí internta descomponer el software en funciones problema que puedan estimarse individualmente. Entonces se estiman las LDC o PF (Las variables de estimación) para cada función. De manera alternativa, el planificador puede elegir otro componente para tamaño, como clases u objetos, cambios o procesos de negocio afectados.
  • 5. Estimación basada en el proceso La tecnica mas comun para estimar un proyecto es basr la estimación en el proceso que se empleara. Esto es, el proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea.
  • 6. Estimación con casos de uso o Los casos de uso representan una visión externa (la visión del usuario) del software y con frecuencia están escrito con diferentes grados de abstracción. o Los casos de uso no abordan la complejidad de las funciones ni de las caracteristicas que se describen o Los casos de uso no describen el comportamiento complejo (por ejemplo: interacciones) que involucran muchas funciones y características. Reconciliación de estimaciones Las técnicas de estimaciones estudiadas en las secciones precedentes dan por resultado múltiples estimaciones que deben reconciliarse para producir una sola estimación de esfuerzo, duración del proyecto o costo. ELABORACIÓN La estimación es un proceso continuo. A medida que el proyecto avanza, más se conoce de él, y por lo tanto más parámetros están disponibles para introducir en un modelo de estimación. La estimación continua nos permite el uso de un único modelo coherente que pueda capturar y utilizar la información sobre el proyecto a medida que éste se conozca. El proceso de estimación comienza usando unas pocas variables claves para proveer las «macro características» de un proyecto, y evoluciona incorporando información de más bajo nivel para producir las «micro-características» del proyecto. FORMAS DE ABORDAR LAESTIMACIÓNDECOSTES: Opinión deexpertos: Un desarrollador o gestor describe los parámetros del proyecto y los expertos hacen estimacionesbasadasen suexperiencia. TécnicaDelphi: Permite sistematizar y mejorar la opinión de los expertosconsultados. Analogía: Enfoque más formal que el de la opinión de experto s. Los expertos comparan el proyecto propuesto con uno o más proyectos anteriores intentando encontrar similitudes y diferencias particulares.
  • 7. BaseHistóricade proyectos Técnicasdedescomposición: Las estimaciones se hacen sobre cada componente en que sedescompone el softwareo sobre tareas de bajo nivel enque se descomponen las tareas. Las estimaciones de bajo nivel se combinan para producir una estimación delproyecto completo. Es decir, el coste total del proyecto es el resultado de sumar las estimaciones de todos los componentesen los que seha divididoel proyecto. Modelos empíricos: Técnicasque identifican los factores clave que contribuyen al esfuerzoy generan una fórmula matemática que relaciona esos factorescon el esfuerzo. Los modelos se basan normalmente enexperiencias pasadas. Simuladores: Están basados en modelos dinámicos. Permiten simular el comportamiento del proyecto a lo largo del tiempo.
  • 8. PRUEBA DE CAJA BLANCA Definición: o Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente o La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba. o Las pruebas de caja blanca intentan garantizar que:  Se ejecutan al menos una vez todos los caminos independientes de cada módulo  Se utilizan las decisiones en su parte verdadera y en su parte falsa  Se ejecuten todos los bucles en sus límites  Se utilizan todas las estructuras de datos internas o En esta prueba se realiza:  Un examen minucioso de los detalles procedimentales, comprobando los caminos lógicos del programa, comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos.  Analiza por módulos  testea lo que el programa hace, se testea en base al conocimiento de la lógica del sistema y en base al estudio de la estructura del algoritmo.  A primera vista, la prueba de caja blanca profunda nos llevaría a tener "programas 100 por cien correctos", es decir: Definir todos los caminos lógicos Desarrollar casos de prueba para todos los caminos lógicos Evaluar los resultados PRUEBA DEL CAMINO BÁSICO: Permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba que garanticen que cada camino se ejecuta al menos una vez. o Los pasos a seguir son:  Elaborar el Grafo de flujo.  Determinar la complejidad ciclomática  Determinar un conjunto básico de caminos linealmente independientes.  Preparar casos de prueba que ejecutan todos los caminos del punto 3. PRUEBAS DE LA CAJA BLANCA: La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba. o Prueba del camino básico El método del camino básico (propuesto por McCabe) permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba
  • 9. que garanticen que cada camino se ejecuta al menos una vez. o Notación del grafo de flujo o grafo del programa o o En el grafo de flujo:  Cada nodo representa una o más sentencias procedimentales  Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una decisión  Las flechas (aristas) representan el flujo de control Complejidad ciclomática:  Es una medida que proporciona una idea de la complejidad lógica de un programa.  La complejidad ciclomática coincide con el número de regiones del grafo de flujo  La complejidad ciclomática, V(G), de un grafo de flujo G, se define como V(G) = Aristas - Nodos + 2  Ejemplo:  A partir del grafo de flujo mostrado anteriormente, la complejidad ciclomática sería: Como el grafo tiene cuatro regiones, V(G) = 4 Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 + 2 = 4 En el ejemplo, el número de caminos independientes es 4, y los caminos independientes son:  1-11  1-2-3-4-5-10-1-11  1-2-3-6-7-9-10-1-11  1-2-3-6-8-9-10-1-11 o Pasos del diseño de pruebas mediante el camino básico:  Obtener el grafo de flujo, a partir del diseño o del código del módulo  Obtener la complejidad ciclomática del grafo de flujo  Definir el conjunto básico de caminos independientes
  • 10.  Determinar los casos de prueba que permitan la ejecución de cada uno de los caminos anteriores  Ejecutar cada caso de prueba y comprobar que los resultados son los esperados PRUEBA DE BUCLES: Se centra en la validez de las construcciones de bucles en un programa. Dentro de los bucles tenemos cuatro clases: o Bucles simples: A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de pruebas siguientes:  Saltar el bucle  Pasar sólo una vez por el bucle  Pasar dos veces por el bucle  Hacer m pasos del bucle con m < n  Hacer n-1, n y n+1 pasos por el bucle o Bucles anidados: El conjunto de pruebas sugerido es: empezar en el bucle más interior y disponer de los demás bucles en sus valores mínimos; pruebas de bucles simples con este bucle interior; progresión hacia fuera, llevando a cabo pruebas para el siguiente bucle y manteniendo los bucles exteriores con sus valores mínimos; estos pasos se repiten hasta haber probado todos los bucles.
  • 11. o o o Bucles concatenados: Si cada uno de los bucles es independiente, se pueden seguir los pasos descriptos para los bucles simples, de lo contrario, se seguirán los pasos sugeridos para los bucles anidados. Bucles no estructurados: siempre que sea posible, esta clase de bucles se debe rediseñar para que se ajuste a las construcciones de programación estructurada. PRUEBA DE CONDICIÓN: o Es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa. Estas condiciones pueden ser simples o compuesta. o Condición simple: es una variable lógica o una expresión relacional, posiblemente precedida con un operador NOT. o Condición compuesta: está formada por dos o más condiciones simples, operadores lógicos y paréntesis. (operadores lógicos permitidos: OR, AND, NOT)
  • 12. Caja Negra Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea, entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz y no se precisa definir ni conocer los detalles internos de su funcionamiento. Justificación Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente. ¿Qué son las pruebas de caja negra? Las pruebas de caja negra, también denominadas pruebas de comportamiento son pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba. Estas pruebas se denominan de varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas por datos, los sinónimos son muchos y muy variados.
  • 13. Descripción de las pruebas de caja negra Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo o sección específica de un software, es decir, es una manera de encontrar casos específicos en ese modulo que atiendan a su especificación. Las pruebas de caja negra se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior. Éstas, principalmente, se centran en módulos o charters de interfaz de usuario pero suelen ser útiles en cualquier módulo ya que todos o la mayoría tienen datos de entrada y salida que se pueden comprobar y verificar. Como cualquier otra prueba, las de caja negra se apoyan y basan en la especificación de requisitos y documentación funcional, estos requisitos suelen ser más complejos que los internos, para ello realizaremos una “cobertura de especificación” que será muy recomendable para conseguir probar el mayor campo posible. Las pruebas de caja negra tratan de encontrar errores en las siguientes categorías: - Funciones incorrectas o faltantes. - Errores de interfaz. - Errores en estructura de datos o en acceso a bases de datos externas. - Errores de comportamiento o desempeño. - Errores de inicialización y término. Métodos a) Métodos gráficos de prueba El primer paso en la prueba de caja negra es comprender los objetos modelados en el software y la relación entre ellos. Una vez que se ha logrado, el siguiente paso consiste en definir la serie de pruebas que verifiquen que “todos los objetos tienen la relación esperada entre sí”. La prueba empieza al crear una gráfica de objetos importantes y sus relaciones, luego idear una serie de pruebas que cubran la gráfica de tal
  • 14. manera que se ejercite cada objeto y relación y que se descubran los errores. Para dar estos pasos, el ingeniero de software empieza creando una gráfica: - Una colección de nodos que representan objetos. - Enlaces que representan la relación entre objetos. - Pesos de nodo que describen las propiedades de un nodo. - Pesos de enlace que describen alguna característica de un enlace. Ejemplo: Selección del menú Acrchivo La selección del menú genera ventana Documento ( tiempo de generación<1.0 seg) Es representada como Permite la edición de Contiene Atributos: Dimensión inicial Color de fondo Texto Documento Color de texto En la figura se muestra una representación simbólica de una gráfica. Los nodos se representan como círculos conectados por enlaces que toman un número diferente de formas. Un enlace directo (representado por una flecha) indica que una relación se mueve en una sola dirección. Un enlace bidireccional, también denominado enlace simétrico, indica que la relación se aplica en ambas direcciones. Los enlaces paralelos se emplean cuando se establece un número deferentes relaciones entre los nodos de la gráfica. Se describen varios métodos de prueba de comportamiento que usan gráficas: - Modelado del fujo de transacción: Los nodos representan pasos de alguna transacción y los enlaces representan la conexión lógica entre los pasos.
  • 15. - Modelo de estado infinito: Los nodos representan los diferentes estados que el usuario observa en el software y los enlaces representan las transiciones que ocurren para ir de un estado a otro. - Modelo de flujo de datos: los nodos son objetos de datos y los enlaces son las transformaciones que ocurren para traducir un objeto de datos en otro. b) Partición equivalente Es un método de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos a partir de las cuales pueden derivarse casos de prueba. Un caso de prueba ideal de manejo simple descubre una clase de errores (por ejemplo, procesamiento incorrecto de todos los datos de caracteres). Se basa en la evaluación de las clases de equivalencia para una condición de entrada que representa a un conjunto de estados válidos o inválidos para las condiciones de entrada con la siguiente tabla: Condiciones Clases de equivalencia Clases de equivalencia externas válidas inválidas A continuación se siguen estas directrices: - Si una condición de entrada especifica un rango de valores, se definen una clase de equivalencia válida y dos no válidas. - Si una clase de equivalencia requiere un valor se definen una clase de equivalencia válida y dos no válidas. - Si una condición de entrada es especifica un miembro de un conjunto, se definen una clase de equivalencia válida y otra no válida. - Si una condición de entrada es booleana se definen una clase de equivalencia válida y otra no válida. Limitaciones de las pruebas de caja negra Lo más deseable a la hora de realizar pruebas de caja negra es realizar una cobertura completa, pero, en la mayoría de los casos no es suficiente, siempre hay que combinarlas con pruebas de integración, ya que por mucho que funcionen los datos de entrada/salida, por dentro o en terceros sistemas,
  • 16. pueden existir defectos que no se están teniendo en cuenta. Estos defectos pueden no acarrear problemas a corto plazo, pero a lo largo del tiempo aparecerán. Por eso siempre se recomienda que se realicen todos los tipos de pruebas, tanto de caja negra, como de integración así como unas buenas pruebas de regresión y de compatibilidad. Siempre las pruebas funcionales tienen que estar completas y cubrir todas las funcionalidades posibles, solo así, se conseguirá una verdadera calidad del software y clientes que podrán respirar tranquilos.