“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

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.

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.

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.

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.

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.

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.

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

que garanticen que cada camino se ejecuta al menos una vez.

o Notación del grafo de flujo o grafo del programa

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

o 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

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.

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.

o 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.

o 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)

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.

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

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:

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.

Selección

del menú

Acrchivo

ventana

Documento

Texto

Documento

La selección del menú genera

( tiempo de generación<1.0 seg)

Permite la edición de

Es representada

como Contiene Atributos:

Dimensión inicial

Color de fondo

Color de texto

- 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

externas

Clases de equivalencia

válidas

Clases de equivalencia

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,

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.